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 отдельно:

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.

Установка

helm dependency update .helm
helm upgrade --install gitea .helm -n gitea --create-namespace

Если Secret создан уже после установки, перезапустить runner:

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:

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:

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 обратно.