mirror of
https://github.com/pgsty/minio.git
synced 2026-07-19 04:00:25 +03:00
Feng Ruohang
f48dbe777d
Update the STS, security, select, and Docker documentation to reflect the recent hardening work, including LDAP STS throttling details, OIDC JWT verification changes, and the new pgsty-specific security policy and advisory index. Rewrite repository and raw-document links that still pointed at minio/minio so the docs consistently reference pgsty/minio instead. The core idea is to keep the documentation aligned with the fork's actual security behavior, ownership, and upgrade guidance without mixing in unrelated code changes.
87 lines
4.2 KiB
Markdown
87 lines
4.2 KiB
Markdown
# Federation Quickstart Guide [](https://slack.min.io) *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.
|
||
|
||
## Get started
|
||
|
||
### 1. Prerequisites
|
||
|
||
Install MinIO - [MinIO Quickstart Guide](https://docs.min.io/community/minio-object-store/operations/deployments/baremetal-deploy-minio-on-redhat-linux.html).
|
||
|
||
### 2. Run MinIO in federated mode
|
||
|
||
Bucket lookup from DNS federation requires two dependencies
|
||
|
||
- etcd (for bucket DNS service records)
|
||
- CoreDNS (for DNS management based on populated bucket DNS service records, optional)
|
||
|
||
## Architecture
|
||
|
||
|
||
|
||
### 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
|
||
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
|
||
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
|
||
`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 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.
|
||
|
||
### Run Multiple Clusters
|
||
|
||
> cluster1
|
||
|
||
```sh
|
||
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}
|
||
```
|
||
|
||
> cluster2
|
||
|
||
```sh
|
||
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}
|
||
```
|
||
|
||
In this configuration you can see `MINIO_ETCD_ENDPOINTS` points to the etcd backend which manages MinIO'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`
|
||
points to the public IP address where each cluster might be accessible, this is unique for each cluster.
|
||
|
||
NOTE: `mybucket` only exists on one cluster either `cluster1` or `cluster2` this is random and
|
||
is decided by how `domain.com` gets resolved, if there is a round-robin DNS on `domain.com` then
|
||
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://docs.min.io/community/minio-object-store/reference/minio-mc.html#quickstart). You’ll see the uploaded files are accessible from the all the MinIO endpoints.
|
||
|
||
## Explore Further
|
||
|
||
- [Use `mc` with MinIO Server](https://docs.min.io/community/minio-object-store/reference/minio-mc.html)
|
||
- [Use `aws-cli` with MinIO Server](https://docs.min.io/community/minio-object-store/integrations/aws-cli-with-minio.html)
|
||
- [Use `minio-go` SDK with MinIO Server](https://docs.min.io/community/minio-object-store/developers/go/minio-go.html)
|
||
- [The MinIO documentation website](https://docs.min.io/community/minio-object-store/index.html)
|