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>
31 lines
2.4 KiB
Markdown
31 lines
2.4 KiB
Markdown
# Silo Deployment Quickstart Guide [](https://hub.docker.com/r/pgsty/silo/)
|
|
|
|
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 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. Silo extends this by adding isolated storage environment for each tenant.
|
|
|
|
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. 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"]
|
|
```
|