mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 07:43:29 +03:00
docs: rebrand the repository documentation, templates and dashboards
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>
This commit is contained in:
Feng Ruohang
@@ -1,21 +1,30 @@
|
||||
# MinIO Deployment Quickstart Guide [](https://slack.min.io) [](https://hub.docker.com/r/minio/minio/)
|
||||
# Silo Deployment Quickstart Guide [](https://hub.docker.com/r/pgsty/silo/)
|
||||
|
||||
MinIO is a cloud-native application designed to scale in a sustainable manner in multi-tenant environments. Orchestration platforms provide perfect launchpad for MinIO to scale. Below is the list of MinIO deployment documents for various orchestration platforms:
|
||||
Silo is a cloud-native application designed to scale in a sustainable manner in multi-tenant environments. Orchestration platforms provide perfect launchpad for Silo to scale. Below is the list of Silo deployment documents for various orchestration platforms:
|
||||
|
||||
| Orchestration platforms |
|
||||
|:---------------------------------------------------------------------------------------------------|
|
||||
| [`Kubernetes`](https://silo.pgsty.com/operations/deployments/kubernetes/) |
|
||||
|
||||
## Why is MinIO cloud-native?
|
||||
## Why is Silo cloud-native?
|
||||
|
||||
The term cloud-native revolves around the idea of applications deployed as micro services, that scale well. It is not about just retrofitting monolithic applications onto modern container based compute environment. A cloud-native application is portable and resilient by design, and can scale horizontally by simply replicating. Modern orchestration platforms like Kubernetes, DC/OS make replicating and managing containers in huge clusters easier than ever.
|
||||
|
||||
While containers provide isolated application execution environment, orchestration platforms allow seamless scaling by helping replicate and manage containers. MinIO extends this by adding isolated storage environment for each tenant.
|
||||
While containers provide isolated application execution environment, orchestration platforms allow seamless scaling by helping replicate and manage containers. Silo extends this by adding isolated storage environment for each tenant.
|
||||
|
||||
MinIO is built ground up on the cloud-native premise. With features like erasure-coding, distributed and shared setup, it focuses only on storage and does it very well. While, it can be scaled by just replicating MinIO instances per tenant via an orchestration platform.
|
||||
Silo is built ground up on the cloud-native premise. With features like erasure-coding, distributed and shared setup, it focuses only on storage and does it very well. While, it can be scaled by just replicating Silo instances per tenant via an orchestration platform.
|
||||
|
||||
> In a cloud-native environment, scalability is not a function of the application but the orchestration platform.
|
||||
|
||||
In a typical modern infrastructure deployment, application, database, key-store, etc. already live in containers and are managed by orchestration platforms. MinIO brings robust, scalable, AWS S3 compatible object storage to the lot.
|
||||
In a typical modern infrastructure deployment, application, database, key-store, etc. already live in containers and are managed by orchestration platforms. Silo brings robust, scalable, AWS S3 compatible object storage to the lot.
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
users["Applications and users"] --> gateway["Ingress or load balancer"]
|
||||
gateway --> silo1["Silo tenant A"]
|
||||
gateway --> silo2["Silo tenant B"]
|
||||
orchestrator["Kubernetes or another orchestrator"] --> silo1
|
||||
orchestrator --> silo2
|
||||
silo1 --> storage1["Dedicated persistent storage"]
|
||||
silo2 --> storage2["Dedicated persistent storage"]
|
||||
```
|
||||
|
||||
@@ -1,17 +1,20 @@
|
||||
# Deploy MinIO on Docker Compose [](https://slack.min.io) [](https://hub.docker.com/r/minio/minio/)
|
||||
# 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 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.
|
||||
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 MinIO on Docker Compose
|
||||
## 2. Run Distributed Silo on Docker Compose
|
||||
|
||||
To deploy Distributed MinIO on Docker Compose, please download [docker-compose.yaml](https://github.com/pgsty/minio/blob/master/docs/orchestration/docker-compose/docker-compose.yaml?raw=true) and [nginx.conf](https://github.com/pgsty/minio/blob/master/docs/orchestration/docker-compose/nginx.conf?raw=true) 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
|
||||
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
|
||||
|
||||
@@ -23,7 +26,7 @@ docker-compose up
|
||||
or
|
||||
|
||||
```sh
|
||||
docker stack deploy --compose-file docker-compose.yaml minio
|
||||
docker stack deploy --compose-file docker-compose.yaml silo
|
||||
```
|
||||
|
||||
### Windows
|
||||
@@ -36,24 +39,27 @@ docker-compose.exe up
|
||||
or
|
||||
|
||||
```sh
|
||||
docker stack deploy --compose-file docker-compose.yaml minio
|
||||
docker stack deploy --compose-file docker-compose.yaml silo
|
||||
```
|
||||
|
||||
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.
|
||||
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 MinIO server release. You can change the image tag to pull a specific [MinIO Docker image](https://hub.docker.com/r/minio/minio/).
|
||||
* 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/).
|
||||
|
||||
* 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
|
||||
* 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 MinIO server instance to the upstream directive in the Nginx configuration file.
|
||||
* Add a new Silo server instance to the upstream directive in the Nginx configuration file.
|
||||
|
||||
Read more about distributed MinIO [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/).
|
||||
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/)
|
||||
* [MinIO Docker Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/)
|
||||
* [MinIO Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
|
||||
* [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/)
|
||||
|
||||
@@ -1,21 +1,26 @@
|
||||
# Deploy MinIO on Kubernetes [](https://slack.min.io) [](https://hub.docker.com/r/minio/minio/)
|
||||
# Deploy Silo on Kubernetes [](https://hub.docker.com/r/pgsty/silo/)
|
||||
|
||||
MinIO is a high performance distributed object storage server, designed for large-scale private cloud infrastructure. MinIO is designed in a cloud-native manner to scale sustainably in multi-tenant environments. Orchestration platforms like Kubernetes provide perfect cloud-native environment to deploy and scale MinIO.
|
||||
Silo is a high performance distributed object storage server, designed for large-scale private cloud infrastructure. Silo is designed in a cloud-native manner to scale sustainably in multi-tenant environments. Orchestration platforms like Kubernetes provide perfect cloud-native environment to deploy and scale Silo.
|
||||
|
||||
## MinIO Deployment on Kubernetes
|
||||
## Silo Deployment on Kubernetes
|
||||
|
||||
There are multiple options to deploy MinIO on Kubernetes:
|
||||
There are multiple options to deploy Silo on Kubernetes:
|
||||
|
||||
- MinIO-Operator: Operator offers seamless way to create and update highly available distributed MinIO clusters. Refer [MinIO Operator documentation](https://github.com/minio/minio-operator/blob/master/README.md) for more details.
|
||||
- The Silo Helm chart in [`helm/silo`](../../../helm/silo) supports direct
|
||||
Kubernetes deployment. The upstream MinIO Operator is a separate project;
|
||||
using it with Silo requires explicit image, command, and compatibility
|
||||
validation.
|
||||
|
||||
- Helm Chart: MinIO Helm Chart offers customizable and easy MinIO deployment with a single command. Refer [MinIO Helm Chart documentation](https://github.com/pgsty/minio/tree/master/helm/minio) for more details.
|
||||
- See the chart's [migration notes](../../../helm/silo/README.md) before
|
||||
upgrading an existing release so selectors, names, and service accounts stay
|
||||
stable.
|
||||
|
||||
## Monitoring MinIO in Kubernetes
|
||||
## Monitoring Silo in Kubernetes
|
||||
|
||||
MinIO server exposes un-authenticated liveness endpoints so Kubernetes can natively identify unhealthy MinIO containers. MinIO also exposes Prometheus compatible data on a different endpoint to enable Prometheus users to natively monitor their MinIO deployments.
|
||||
Silo server exposes un-authenticated liveness endpoints so Kubernetes can natively identify unhealthy Silo containers. Silo also exposes Prometheus compatible data on a different endpoint to enable Prometheus users to natively monitor their Silo deployments.
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
|
||||
- [Silo Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
|
||||
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
|
||||
- [Helm package manager for kubernetes](https://helm.sh/)
|
||||
|
||||
Reference in New Issue
Block a user