mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +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:
@@ -1,4 +1,4 @@
|
||||
# MinIO Multi-Tenant Deployment Guide [](https://slack.min.io) [](https://hub.docker.com/r/minio/minio/)
|
||||
# Silo Multi-Tenant Deployment Guide [](https://hub.docker.com/r/pgsty/silo/)
|
||||
|
||||
This topic provides commands to set up different configurations of hosts, nodes, and drives. The examples provided here can be used as a starting point for other configurations.
|
||||
|
||||
@@ -8,35 +8,51 @@ This topic provides commands to set up different configurations of hosts, nodes,
|
||||
|
||||
## 1. Standalone Deployment
|
||||
|
||||
To host multiple tenants on a single machine, run one MinIO Server per tenant with a dedicated HTTPS port, configuration, and data directory.
|
||||
To host multiple tenants on a single machine, run one Silo Server per tenant with a dedicated HTTPS port, configuration, and data directory.
|
||||
|
||||
### 1.1 Host Multiple Tenants on a Single Drive
|
||||
|
||||
Use the following commands to host 3 tenants on a single drive:
|
||||
|
||||
```sh
|
||||
minio server --address :9001 /data/tenant1
|
||||
minio server --address :9002 /data/tenant2
|
||||
minio server --address :9003 /data/tenant3
|
||||
silo server --address :9001 /data/tenant1
|
||||
silo server --address :9002 /data/tenant2
|
||||
silo server --address :9003 /data/tenant3
|
||||
```
|
||||
|
||||

|
||||
```mermaid
|
||||
flowchart TB
|
||||
tenant1["Tenant 1 :9001"] --> silo1["Silo process 1"]
|
||||
tenant2["Tenant 2 :9002"] --> silo2["Silo process 2"]
|
||||
tenant3["Tenant 3 :9003"] --> silo3["Silo process 3"]
|
||||
silo1 --> disk["Shared host drive with isolated data directories"]
|
||||
silo2 --> disk
|
||||
silo3 --> disk
|
||||
```
|
||||
|
||||
### 1.2 Host Multiple Tenants on Multiple Drives (Erasure Code)
|
||||
|
||||
Use the following commands to host 3 tenants on multiple drives:
|
||||
|
||||
```sh
|
||||
minio server --address :9001 /disk{1...4}/data/tenant1
|
||||
minio server --address :9002 /disk{1...4}/data/tenant2
|
||||
minio server --address :9003 /disk{1...4}/data/tenant3
|
||||
silo server --address :9001 /disk{1...4}/data/tenant1
|
||||
silo server --address :9002 /disk{1...4}/data/tenant2
|
||||
silo server --address :9003 /disk{1...4}/data/tenant3
|
||||
```
|
||||
|
||||

|
||||
```mermaid
|
||||
flowchart TB
|
||||
tenant1["Tenant 1 :9001"] --> silo1["Silo process 1"]
|
||||
tenant2["Tenant 2 :9002"] --> silo2["Silo process 2"]
|
||||
tenant3["Tenant 3 :9003"] --> silo3["Silo process 3"]
|
||||
silo1 --> drives["Four shared drives with isolated tenant directories"]
|
||||
silo2 --> drives
|
||||
silo3 --> drives
|
||||
```
|
||||
|
||||
## 2. Distributed Deployment
|
||||
|
||||
To host multiple tenants in a distributed environment, run several distributed MinIO Server instances concurrently.
|
||||
To host multiple tenants in a distributed environment, run several distributed Silo Server instances concurrently.
|
||||
|
||||
### 2.1 Host Multiple Tenants on Multiple Drives (Erasure Code)
|
||||
|
||||
@@ -45,23 +61,31 @@ Use the following commands to host 3 tenants on a 4-node distributed configurati
|
||||
```sh
|
||||
export MINIO_ROOT_USER=<TENANT1_ACCESS_KEY>
|
||||
export MINIO_ROOT_PASSWORD=<TENANT1_SECRET_KEY>
|
||||
minio server --address :9001 http://192.168.10.1{1...4}/data/tenant1
|
||||
silo server --address :9001 http://192.168.10.1{1...4}/data/tenant1
|
||||
|
||||
export MINIO_ROOT_USER=<TENANT2_ACCESS_KEY>
|
||||
export MINIO_ROOT_PASSWORD=<TENANT2_SECRET_KEY>
|
||||
minio server --address :9002 http://192.168.10.1{1...4}/data/tenant2
|
||||
silo server --address :9002 http://192.168.10.1{1...4}/data/tenant2
|
||||
|
||||
export MINIO_ROOT_USER=<TENANT3_ACCESS_KEY>
|
||||
export MINIO_ROOT_PASSWORD=<TENANT3_SECRET_KEY>
|
||||
minio server --address :9003 http://192.168.10.1{1...4}/data/tenant3
|
||||
silo server --address :9003 http://192.168.10.1{1...4}/data/tenant3
|
||||
```
|
||||
|
||||
**Note:** Execute the commands on all 4 nodes.
|
||||
|
||||

|
||||
```mermaid
|
||||
flowchart TB
|
||||
tenant1["Tenant 1 :9001"] --> pool1["Distributed Silo pool for tenant 1"]
|
||||
tenant2["Tenant 2 :9002"] --> pool2["Distributed Silo pool for tenant 2"]
|
||||
tenant3["Tenant 3 :9003"] --> pool3["Distributed Silo pool for tenant 3"]
|
||||
pool1 --> nodes["Four nodes with isolated tenant data paths"]
|
||||
pool2 --> nodes
|
||||
pool3 --> nodes
|
||||
```
|
||||
|
||||
**Note**: On distributed systems, root credentials are recommend to be defined by exporting the `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD` environment variables. If no value is set MinIO setup will assume `minioadmin/minioadmin` as default credentials. If a domain is required, it must be specified by defining and exporting the `MINIO_DOMAIN` environment variable.
|
||||
**Note**: On distributed systems, root credentials are recommend to be defined by exporting the `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD` environment variables. If no value is set Silo setup will assume `minioadmin/minioadmin` as default credentials. If a domain is required, it must be specified by defining and exporting the `MINIO_DOMAIN` environment variable.
|
||||
|
||||
## Cloud Scale Deployment
|
||||
|
||||
A container orchestration platform (e.g. Kubernetes) is recommended for large-scale, multi-tenant MinIO deployments. See the [MinIO Deployment Quickstart Guide](https://silo.pgsty.com/operations/deployments/kubernetes/) to get started with MinIO on orchestration platforms.
|
||||
A container orchestration platform (e.g. Kubernetes) is recommended for large-scale, multi-tenant Silo deployments. See the [Silo Deployment Quickstart Guide](https://silo.pgsty.com/operations/deployments/kubernetes/) to get started with Silo on orchestration platforms.
|
||||
|
||||
Reference in New Issue
Block a user