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,14 +1,14 @@
|
||||
# Federation Quickstart Guide [](https://slack.min.io) *Federation feature is deprecated and should be avoided for future deployments*
|
||||
# Federation Quickstart Guide *Federation feature is deprecated and should be avoided for future deployments*
|
||||
|
||||
This document explains how to configure MinIO with `Bucket lookup from DNS` style federation.
|
||||
This document explains how to configure Silo with `Bucket lookup from DNS` style federation.
|
||||
|
||||
## Get started
|
||||
|
||||
### 1. Prerequisites
|
||||
|
||||
Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
|
||||
Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
|
||||
|
||||
### 2. Run MinIO in federated mode
|
||||
### 2. Run Silo in federated mode
|
||||
|
||||
Bucket lookup from DNS federation requires two dependencies
|
||||
|
||||
@@ -17,32 +17,40 @@ Bucket lookup from DNS federation requires two dependencies
|
||||
|
||||
## Architecture
|
||||
|
||||

|
||||
```mermaid
|
||||
flowchart LR
|
||||
app["Application requests bucket.example.net"] --> dns["CoreDNS"]
|
||||
dns --> registry["etcd bucket records"]
|
||||
registry --> cluster1["Silo cluster 1"]
|
||||
registry --> cluster2["Silo cluster 2"]
|
||||
registry --> clustern["Silo cluster n"]
|
||||
dns --> app
|
||||
```
|
||||
|
||||
### Environment variables
|
||||
|
||||
#### MINIO_ETCD_ENDPOINTS
|
||||
|
||||
This is comma separated list of etcd servers that you want to use as the MinIO federation back-end. This should
|
||||
be same across the federated deployment, i.e. all the MinIO instances within a federated deployment should use same
|
||||
This is comma separated list of etcd servers that you want to use as the Silo federation back-end. This should
|
||||
be same across the federated deployment, i.e. all the Silo instances within a federated deployment should use same
|
||||
etcd back-end.
|
||||
|
||||
#### MINIO_DOMAIN
|
||||
|
||||
This is the top level domain name used for the federated setup. This domain name should ideally resolve to a load-balancer
|
||||
running in front of all the federated MinIO instances. The domain name is used to create sub domain entries to etcd. For
|
||||
running in front of all the federated Silo instances. The domain name is used to create sub domain entries to etcd. For
|
||||
example, if the domain is set to `domain.com`, the buckets `bucket1`, `bucket2` will be accessible as `bucket1.domain.com`
|
||||
and `bucket2.domain.com`.
|
||||
|
||||
#### MINIO_PUBLIC_IPS
|
||||
|
||||
This is comma separated list of IP addresses to which buckets created on this MinIO instance will resolve to. For example,
|
||||
a bucket `bucket1` created on current MinIO instance will be accessible as `bucket1.domain.com`, and the DNS entry for
|
||||
This is comma separated list of IP addresses to which buckets created on this Silo instance will resolve to. For example,
|
||||
a bucket `bucket1` created on current Silo instance will be accessible as `bucket1.domain.com`, and the DNS entry for
|
||||
`bucket1.domain.com` will point to IP address set in `MINIO_PUBLIC_IPS`.
|
||||
|
||||
- This field is mandatory for standalone and erasure code MinIO server deployments, to enable federated mode.
|
||||
- This field is mandatory for standalone and erasure code Silo server deployments, to enable federated mode.
|
||||
- This field is optional for distributed deployments. If you don't set this field in a federated setup, we use the IP addresses of
|
||||
hosts passed to the MinIO server startup and use them for DNS entries.
|
||||
hosts passed to the Silo server startup and use them for DNS entries.
|
||||
|
||||
### Run Multiple Clusters
|
||||
|
||||
@@ -52,7 +60,7 @@ hosts passed to the MinIO server startup and use them for DNS entries.
|
||||
export MINIO_ETCD_ENDPOINTS="http://remote-etcd1:2379,http://remote-etcd2:4001"
|
||||
export MINIO_DOMAIN=domain.com
|
||||
export MINIO_PUBLIC_IPS=44.35.2.1,44.35.2.2,44.35.2.3,44.35.2.4
|
||||
minio server http://rack{1...4}.host{1...4}.domain.com/mnt/export{1...32}
|
||||
silo server http://rack{1...4}.host{1...4}.domain.com/mnt/export{1...32}
|
||||
```
|
||||
|
||||
> cluster2
|
||||
@@ -61,10 +69,10 @@ minio server http://rack{1...4}.host{1...4}.domain.com/mnt/export{1...32}
|
||||
export MINIO_ETCD_ENDPOINTS="http://remote-etcd1:2379,http://remote-etcd2:4001"
|
||||
export MINIO_DOMAIN=domain.com
|
||||
export MINIO_PUBLIC_IPS=44.35.1.1,44.35.1.2,44.35.1.3,44.35.1.4
|
||||
minio server http://rack{5...8}.host{5...8}.domain.com/mnt/export{1...32}
|
||||
silo server http://rack{5...8}.host{5...8}.domain.com/mnt/export{1...32}
|
||||
```
|
||||
|
||||
In this configuration you can see `MINIO_ETCD_ENDPOINTS` points to the etcd backend which manages MinIO's
|
||||
In this configuration you can see `MINIO_ETCD_ENDPOINTS` points to the etcd backend which manages Silo's
|
||||
`config.json` and bucket DNS SRV records. `MINIO_DOMAIN` indicates the domain suffix for the bucket which
|
||||
will be used to resolve bucket through DNS. For example if you have a bucket such as `mybucket`, the
|
||||
client can use now `mybucket.domain.com` to directly resolve itself to the right cluster. `MINIO_PUBLIC_IPS`
|
||||
@@ -76,11 +84,11 @@ it is randomized which cluster might provision the bucket.
|
||||
|
||||
### 3. Test your setup
|
||||
|
||||
To test this setup, access the MinIO server via browser or [`mc`](https://silo.pgsty.com/reference/minio-mc/#quickstart). You’ll see the uploaded files are accessible from the all the MinIO endpoints.
|
||||
To test this setup, access the Silo server via browser or [`mc`](https://silo.pgsty.com/reference/minio-mc/#quickstart). You’ll see the uploaded files are accessible from the all the Silo endpoints.
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/)
|
||||
- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
|
||||
- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/)
|
||||
- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
|
||||
- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
Reference in New Issue
Block a user