mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +03:00
build(helm): replace the minio chart with a silo chart that preserves identity
helm/minio becomes helm/silo: chart name silo, version 6.0.0 -> 7.0.0, the MinIO wordmark icon replaced with the project's own, image.repository and mcImage.repository pointing at pgsty/silo, and the container command changed to silo. User-visible titles, comments and documentation links are rebranded. The MINIO_* environment variables and every existing values key are kept - the first Silo chart is a rename, not a values-schema migration. The hard problem is that a chart rename normally rewrites Kubernetes resource identity, and a StatefulSet's selector and volumeClaimTemplate are immutable. An existing release upgraded carelessly would either fail or orphan its PVCs. Two things address that: - Templates no longer derive the container name from .Chart.Name. It comes from a helper, so nameOverride can pin it, which means an existing release can be upgraded with nameOverride=minio, fullnameOverride=<existing-fullname> and serviceAccount.name=minio-sa and render byte-stable identity while switching chart and image. - helm-migration-guard and verify-helm-migration.sh make that a gate rather than a documented hope. The script lints the chart, renders it in distributed and standalone modes plus the optional templates, then renders the legacy chart from a pinned commit and the new chart with those three overrides and compares resource identity. The guard additionally rejects any rendered container still pulling pgsty/minio or invoking /usr/bin/minio. It runs through a pinned alpine/helm image when helm is not installed locally, so the gate does not depend on the developer's machine. Currently green over 7 compared resources. Rollback is asymmetric and the README says so: the old chart with the new image survives via the entrypoint argv shim, but the new chart with an old MinIO image does not, because `silo server` is not a command that binary knows. Only `helm rollback` is supported, never an image-only downgrade. Not addressed here: the default image tag is pgsty/silo:RELEASE.2026-08-04T00-00-00Z, which does not exist yet. The chart must not be published until the first Silo image is pushed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Feng Ruohang
@@ -0,0 +1,141 @@
|
||||
# Silo Helm Chart
|
||||
|
||||
This chart installs Silo, an independently maintained, S3-compatible object
|
||||
storage server, on Kubernetes. It supports standalone and distributed modes.
|
||||
The chart and server are licensed under AGPL-3.0-or-later.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Kubernetes 1.19 or later
|
||||
- Helm 3
|
||||
- A PersistentVolume provisioner unless `persistence.enabled=false`
|
||||
|
||||
## Install
|
||||
|
||||
From this repository:
|
||||
|
||||
```bash
|
||||
helm install silo ./helm/silo \
|
||||
--namespace silo --create-namespace \
|
||||
--set rootUser=silo-admin \
|
||||
--set rootPassword='replace-with-a-long-random-secret'
|
||||
```
|
||||
|
||||
For a disposable standalone installation:
|
||||
|
||||
```bash
|
||||
helm install silo ./helm/silo \
|
||||
--namespace silo --create-namespace \
|
||||
--set mode=standalone \
|
||||
--set replicas=1 \
|
||||
--set persistence.enabled=false \
|
||||
--set resources.requests.memory=512Mi \
|
||||
--set rootUser=silo-admin \
|
||||
--set rootPassword='replace-with-a-long-random-secret'
|
||||
```
|
||||
|
||||
The default server and post-install image is `docker.io/pgsty/silo`. The image
|
||||
contains the `silo` server, `mcli`, and an `mc` compatibility symlink. It does
|
||||
not contain a `minio` server binary.
|
||||
|
||||
## Compatibility contract
|
||||
|
||||
The product and delivery names are Silo, while established interfaces remain
|
||||
compatible:
|
||||
|
||||
- `MINIO_*` environment variables and existing values keys are unchanged.
|
||||
- `/minio/*` API and metrics routes are unchanged.
|
||||
- `minio_*` Prometheus metrics and `x-minio-*` protocol headers are unchanged.
|
||||
- Existing storage, including `.minio.sys`, is used without conversion.
|
||||
- `nameOverride`, `fullnameOverride`, and `serviceAccount.name` can pin existing
|
||||
Kubernetes resource identities during an upgrade.
|
||||
|
||||
New installations default to Silo resource names and the `silo-sa` service
|
||||
account.
|
||||
|
||||
## Upgrade an existing release
|
||||
|
||||
Do not upgrade an existing release without first pinning its current resource
|
||||
names. Export the complete values and render the candidate chart offline:
|
||||
|
||||
```bash
|
||||
helm get values my-release -n my-namespace -a > values.before-silo.yaml
|
||||
SILO_TAG='<published-silo-release-tag>'
|
||||
|
||||
helm template my-release ./helm/silo \
|
||||
-n my-namespace \
|
||||
-f values.before-silo.yaml \
|
||||
--set nameOverride=minio \
|
||||
--set fullnameOverride=my-existing-fullname \
|
||||
--set serviceAccount.name=minio-sa \
|
||||
--set image.repository=pgsty/silo \
|
||||
--set mcImage.repository=pgsty/silo \
|
||||
--set-string image.tag="${SILO_TAG}" \
|
||||
--set-string mcImage.tag="${SILO_TAG}" \
|
||||
> rendered.silo.yaml
|
||||
```
|
||||
|
||||
Compare the old and new manifests. Stop if the candidate changes immutable
|
||||
selectors, StatefulSet or Service identity, PVC names, Secrets, or storage
|
||||
mounts. After review, upgrade the chart and image together:
|
||||
|
||||
```bash
|
||||
SILO_TAG='<published-silo-release-tag>'
|
||||
helm upgrade my-release ./helm/silo \
|
||||
-n my-namespace \
|
||||
-f values.before-silo.yaml \
|
||||
--set nameOverride=minio \
|
||||
--set fullnameOverride=my-existing-fullname \
|
||||
--set serviceAccount.name=minio-sa \
|
||||
--set image.repository=pgsty/silo \
|
||||
--set mcImage.repository=pgsty/silo \
|
||||
--set-string image.tag="${SILO_TAG}" \
|
||||
--set-string mcImage.tag="${SILO_TAG}"
|
||||
```
|
||||
|
||||
Rollback is chart-level: use `helm rollback`, not an image-only downgrade. The
|
||||
new chart invokes `silo server`; an old image does not provide that executable.
|
||||
The new image accepts a legacy first argv token of `minio` only to support old
|
||||
chart commands during the forward migration.
|
||||
|
||||
## Persistence and TLS
|
||||
|
||||
The default PersistentVolumeClaim mounts at `/export`. Use an existing claim
|
||||
with:
|
||||
|
||||
```bash
|
||||
helm install silo ./helm/silo --set persistence.existingClaim=PVC_NAME
|
||||
```
|
||||
|
||||
Create a TLS Secret containing `private.key` and `public.crt`, then set:
|
||||
|
||||
```bash
|
||||
helm upgrade --install silo ./helm/silo \
|
||||
--set tls.enabled=true \
|
||||
--set tls.certSecret=silo-tls
|
||||
```
|
||||
|
||||
Additional trusted CAs can be supplied through `trustedCertsSecret`.
|
||||
|
||||
## Existing Secrets and post-install resources
|
||||
|
||||
Set `existingSecret` to a Secret containing `rootUser` and `rootPassword`.
|
||||
Buckets, users, policies, service accounts, and custom commands can be created
|
||||
with the existing `buckets`, `users`, `policies`, `svcaccts`, and
|
||||
`customCommands` values. The post-install job uses `mcli` through its `mc`
|
||||
compatibility command. New custom commands should target `mysilo`; the legacy
|
||||
`myminio` target remains registered so existing values continue to work.
|
||||
|
||||
## Configuration
|
||||
|
||||
See [values.yaml](./values.yaml) for the complete values surface and the
|
||||
[Silo documentation](https://silo.pgsty.com/) for server operations.
|
||||
|
||||
To uninstall the chart:
|
||||
|
||||
```bash
|
||||
helm uninstall silo -n silo
|
||||
```
|
||||
|
||||
PersistentVolumeClaims may remain after uninstall; inspect them before any
|
||||
manual deletion.
|
||||
Reference in New Issue
Block a user