Feng Ruohang
6613c2a3cb
The test and verification scripts invoked ./minio and pulled their tooling from upstream infrastructure with no integrity check. Every `curl | tar` of a client or an old server binary was an unverified execution path in a script that regularly runs as a privileged user, and several fetched a floating "latest". Two installers replace all of it: - install-mcli.sh resolves a pinned pgsty/mc release, downloads the archive and its checksum manifest, requires exactly one valid manifest entry for the asset, verifies it, and installs. MCLI_BIN with a mandatory MCLI_SHA256 lets an offline or air-gapped run supply its own binary, still checksum-checked. - install-verified-fixture.sh takes source, expected SHA-256 and target, and refuses anything that does not match. Sources may be a URL or a local file. Every script that previously downloaded mc now calls install-mcli.sh. The three places that genuinely need an upstream artifact - the old MinIO server binary for the LDAP IAM upgrade-import test, the 2021 mc for the three-site replication test, and the functional-tests.sh fixture - go through install-verified-fixture.sh with the digest recorded inline. Those dl.min.io URLs remain on purpose: they are historical upstream artifacts needed to prove upgrade compatibility, and they are now pinned and verified rather than trusted. The scripts otherwise switch to ./silo, silo.service, the silo container and compose service names, and SILO_CONFIG_DIR. run-multi-site-minio-idp.sh is renamed to run-multi-site-silo-idp.sh with the Makefile target following. buildscripts/minio-upgrade.sh keeps its name and its `minio server` argv - it exists to test the MinIO-to-Silo upgrade, so the old side must stay old - but it is now pinned to an image digest rather than a tag, and its `docker system prune` and `docker volume prune` calls are removed. Those ran unfiltered against the developer's whole Docker installation; the resiliency tests had the same problem and lose their prune and `docker ps -q` sweeps too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deploy MinIO on Docker Compose 
Docker Compose allows defining and running single host, multi-container Docker applications.
With Compose, you use a Compose file to configure MinIO services. Then, using a single command, you can create and launch all the Distributed MinIO instances from your configuration. Distributed MinIO instances will be deployed in multiple containers on the same host. This is a great way to set up development, testing, and staging environments, based on Distributed MinIO.
1. Prerequisites
- Familiarity with Docker Compose.
- Docker installed on your machine. Download the relevant installer from here.
2. Run Distributed MinIO on Docker Compose
To deploy Distributed MinIO on Docker Compose, please download docker-compose.yaml and nginx.conf to your current working directory. Note that Docker Compose pulls the MinIO Docker image, so there is no need to build MinIO from source when using Docker. For non-Docker deployments, MinIO community edition is now source-only and can be installed via go install github.com/minio/minio@latest. Then run one of the below commands
GNU/Linux and macOS
docker-compose pull
docker-compose up
or
docker stack deploy --compose-file docker-compose.yaml minio
Windows
docker-compose.exe pull
docker-compose.exe up
or
docker stack deploy --compose-file docker-compose.yaml minio
Distributed instances are now accessible on the host using the Minio CLI on port 9000 and the Minio Web Console on port 9001. Proceed to access the Web browser at http://127.0.0.1:9001/. Here 4 MinIO server instances are reverse proxied through Nginx load balancing.
Notes
-
By default the Docker Compose file uses the Docker image for latest MinIO server release. You can change the image tag to pull a specific MinIO Docker image.
-
There are 4 minio distributed instances created by default. You can add more MinIO services (up to total 16) to your MinIO Compose deployment. To add a service
- Replicate a service definition and change the name of the new service appropriately.
- Update the command section in each service.
- Add a new MinIO server instance to the upstream directive in the Nginx configuration file.
Read more about distributed MinIO here.