mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +03:00
Feng Ruohang
fd2ca1c6d2
README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE, code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue and pull request templates, and the docs/ tree all present Silo as the product. The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel titles and descriptions rebranded while every minio_* query, label and expression is left alone, so existing alerts and recording rules keep matching. The distinction the review demanded is applied per hit rather than by search-and-replace: - Product and command text becomes Silo and silo: install and run instructions, systemd examples, compose services, download links, badges. - Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and error names. - Attribution keeps MinIO and gains the fork's own: the AGPL obligations, original copyright, CREDITS and NOTICE stay, with the modification notice added alongside rather than replacing them. - Historical and third-party references are left as facts, not rewritten for brand tidiness. README and README_ZH each carry an explicit non-affiliation notice, document the side-by-side package migration including the /etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a legacy UID/GID, and state that recursive chown is never performed. The trademark attribution uses the policy's approved "based on MinIO technology" wording, not the shortened form the policy rejects. github.com/pgsty/minio links are left in place and labelled transitional. The repository has not been renamed, and rewriting them now would produce documented URLs that 404 until the cutover; they change in the cutover commit together with the goreleaser release target, the OCI source label and the raw-content branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
66 lines
2.7 KiB
Markdown
66 lines
2.7 KiB
Markdown
# Deploy Silo on Docker Compose [](https://hub.docker.com/r/pgsty/silo/)
|
|
|
|
Docker Compose allows defining and running single host, multi-container Docker applications.
|
|
|
|
With Compose, you use a Compose file to configure Silo services. Then, using a single command, you can create and launch all the Distributed Silo instances from your configuration. Distributed Silo 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 Silo.
|
|
|
|
## 1. Prerequisites
|
|
|
|
* Familiarity with [Docker Compose](https://docs.docker.com/compose/overview/).
|
|
* Docker installed on your machine. Download the relevant installer from [here](https://www.docker.com/community-edition#/download).
|
|
|
|
## 2. Run Distributed Silo on Docker Compose
|
|
|
|
To deploy distributed Silo with Docker Compose, download the local
|
|
[`docker-compose.yaml`](docker-compose.yaml) and [`nginx.conf`](nginx.conf) into
|
|
the same working directory. Compose pulls the Silo image, so no source build is
|
|
required. Then run one of the commands below.
|
|
|
|
### GNU/Linux and macOS
|
|
|
|
```sh
|
|
docker-compose pull
|
|
docker-compose up
|
|
```
|
|
|
|
or
|
|
|
|
```sh
|
|
docker stack deploy --compose-file docker-compose.yaml silo
|
|
```
|
|
|
|
### Windows
|
|
|
|
```sh
|
|
docker-compose.exe pull
|
|
docker-compose.exe up
|
|
```
|
|
|
|
or
|
|
|
|
```sh
|
|
docker stack deploy --compose-file docker-compose.yaml silo
|
|
```
|
|
|
|
The S3 API is accessible through the load balancer on port 9000 and the Silo
|
|
Console on port 9001. Open <http://127.0.0.1:9001/> in a browser. Four Silo
|
|
server instances are reverse proxied through Nginx.
|
|
|
|
### Notes
|
|
|
|
* By default the Docker Compose file uses the Docker image for latest Silo server release. You can change the image tag to pull a specific [Silo Docker image](https://hub.docker.com/r/pgsty/silo/).
|
|
|
|
* Four distributed Silo instances are created by default. You can add more
|
|
Silo services (up to 16 total) to the 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 Silo server instance to the upstream directive in the Nginx configuration file.
|
|
|
|
Read more about distributed Silo [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/).
|
|
|
|
### Explore Further
|
|
|
|
* [Overview of Docker Compose](https://docs.docker.com/compose/overview/)
|
|
* [Silo Docker Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/)
|
|
* [Silo Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
|