81 lines
4.2 KiB
Markdown
81 lines
4.2 KiB
Markdown
# Gitea Helm chart
|
||
|
||
Чарт лежит в `.helm`.
|
||
|
||
Зависимости:
|
||
|
||
- `universal-chart` `0.1.9` для `gitea-ci-worker`
|
||
- статический `Deployment` для `gitea`, потому что файловый backup должен жить sidecar-ом в том же pod-е, где смонтирован RWO PVC
|
||
- `postgresql-preprod` `16.4.8` из `oci://cr.yandex/crp3ccidau046kdj8g9q/charts`
|
||
|
||
HTTP-маршрутизации здесь нет: ни `Ingress`, ни `VirtualService`. VS управляется отдельным чартом.
|
||
|
||
## Секреты
|
||
|
||
В `values.yaml` нет чувствительных значений. Чарт создает `gitea-secret` через `lookup`: если Secret уже существует, значения сохраняются; если нет, создаются сгенерированные заглушки. С заглушками runner и S3 backup не заработают, пока Secret не будет заполнен реальными данными.
|
||
|
||
Перед установкой можно создать Secret отдельно:
|
||
|
||
```bash
|
||
kubectl create namespace gitea --dry-run=client -o yaml | kubectl apply -f -
|
||
|
||
kubectl -n gitea create secret generic gitea-secret \
|
||
--from-literal=runner-registration-token="$GITEA_RUNNER_REGISTRATION_TOKEN" \
|
||
--from-literal=aws-access-key-id="$AWS_ACCESS_KEY_ID" \
|
||
--from-literal=aws-secret-access-key="$AWS_SECRET_ACCESS_KEY" \
|
||
--from-file=kubeconfig=./runner/kubeconfig/config \
|
||
--from-file=docker-config.json=./runner/docker-config/config.json \
|
||
--dry-run=client -o yaml | kubectl apply -f -
|
||
```
|
||
|
||
PostgreSQL пароль живет в `postgresql-secret`, который создает PostgreSQL chart и сохраняет через `helm.sh/resource-policy: keep`. Gitea читает ключ `user-password`.
|
||
|
||
## Установка
|
||
|
||
```bash
|
||
helm dependency update .helm
|
||
helm upgrade --install gitea .helm -n gitea --create-namespace
|
||
```
|
||
|
||
Если Secret создан уже после установки, перезапустить runner:
|
||
|
||
```bash
|
||
kubectl -n gitea rollout restart deploy/gitea-ci-worker
|
||
```
|
||
|
||
## Backup
|
||
|
||
Backup включен по умолчанию:
|
||
|
||
- `gitea-files-backup`: sidecar внутри pod `gitea`, каждый день в `02:30` архивирует `/data` и кладет в `s3://gitops-gitea/gitops-backups/gitea-files/`. Отдельного pod-а с mount PVC нет, поэтому не возникает second attach/Multi-Attach для `gitea-data`.
|
||
- `gitea-postgresql-backup`: каждый день в `02:45`, делает `pg_dump | gzip` и кладет в `s3://gitops-gitea/gitops-backups/postgresql/`
|
||
|
||
Оба backup-процесса используют S3-ключи из `gitea-secret`. Если там сгенерированные заглушки, backup завершится с понятной ошибкой и ничего не загрузит.
|
||
|
||
## Restore
|
||
|
||
Restore не включен в обычную установку. Это разовый Job, который включается отдельным values-файлом.
|
||
|
||
1. Взять имена объектов из S3:
|
||
|
||
```bash
|
||
aws --endpoint-url "$AWS_ENDPOINT_URL" s3 ls s3://gitops-gitea/gitops-backups/gitea-files/
|
||
aws --endpoint-url "$AWS_ENDPOINT_URL" s3 ls s3://gitops-gitea/gitops-backups/postgresql/
|
||
```
|
||
|
||
2. Скопировать `.helm/restore-values.example.yaml`, указать реальные `giteaFilesKey` и/или `postgresqlDumpKey`.
|
||
|
||
3. Запустить restore:
|
||
|
||
```bash
|
||
helm upgrade --install gitea .helm -n gitea -f restore-values.yaml
|
||
```
|
||
|
||
Режимы restore:
|
||
|
||
- полный restore: `restore.files.enabled=true` и `restore.postgresql.enabled=true`
|
||
- только файлы: `restore.files.enabled=true`, `restore.postgresql.enabled=false`
|
||
- только база: `restore.files.enabled=false`, `restore.postgresql.enabled=true`
|
||
|
||
Restore Job при `restore.scaleGitea.enabled=true` сначала масштабирует deployment `gitea` в `0` и ждёт удаления pod-а. Это нужно, чтобы restore файлов не монтировал RWO PVC одновременно с Gitea. После успешного completion отдельный `gitea-restore-scale-up` Job возвращает replicas обратно.
|