Files
postiz-helmchart/ROLLBACK.md
T
billisdead 104bc7a56f docs: add rollback guide to official GitHub chart
Covers 4 scenarios: normal ArgoCD rollback, Gitea outage emergency,
image rollback with/without DB restore, and rollback to a specific Gitea commit.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-16 18:06:42 +02:00

5.0 KiB

Rollback — Retour vers la chart officielle GitHub

Ce document couvre le retour de la source ArgoCD depuis ce fork Gitea (homegit.gyozamancave.fr/billisdead/postiz-helmchart) vers la chart officielle (github.com/gitroomhq/postiz-helmchart).


Contexte de référence

Paramètre Fork Gitea (actuel) Chart officielle (cible rollback)
repoURL https://homegit.gyozamancave.fr/billisdead/postiz-helmchart https://github.com/gitroomhq/postiz-helmchart
targetRevision main HEAD
path charts/postiz charts/postiz

Les values inline dans l'Application ArgoCD ne changent pas.


Scénario 1 — Rollback normal (ArgoCD accessible)

kubectl patch application postiz -n argocd --type='json' -p='[
  {"op": "replace", "path": "/spec/source/repoURL",        "value": "https://github.com/gitroomhq/postiz-helmchart"},
  {"op": "replace", "path": "/spec/source/targetRevision", "value": "HEAD"}
]'

kubectl annotate application postiz -n argocd \
  argocd.argoproj.io/refresh=hard --overwrite

Vérification :

kubectl get application postiz -n argocd \
  -o jsonpath='{"sync: "}{.status.sync.status}{"\nhealth: "}{.status.health.status}{"\nrevision: "}{.status.sync.revision}{"\n"}'

Résultat attendu : sync: Synced, health: Healthy, revision = dernier commit GitHub.


Scénario 2 — Gitea inaccessible (rollback d'urgence)

Si homegit.gyozamancave.fr est down et qu'ArgoCD est bloqué en erreur de fetch, appliquer le patch de la même façon — ArgoCD re-tentera depuis GitHub immédiatement.

# Même commande que le scénario 1 — ArgoCD abandonne le fetch Gitea dès que repoURL change
kubectl patch application postiz -n argocd --type='json' -p='[
  {"op": "replace", "path": "/spec/source/repoURL",        "value": "https://github.com/gitroomhq/postiz-helmchart"},
  {"op": "replace", "path": "/spec/source/targetRevision", "value": "HEAD"}
]'

Si ArgoCD lui-même ne répond plus, patcher le CRD directement via le control plane :

# Requiert un accès direct à k3s-master
KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl patch application postiz -n argocd \
  --type='json' -p='[
    {"op": "replace", "path": "/spec/source/repoURL",        "value": "https://github.com/gitroomhq/postiz-helmchart"},
    {"op": "replace", "path": "/spec/source/targetRevision", "value": "HEAD"}
  ]'

Scénario 3 — Rollback après upgrade image (ex. v2.11.2 → v2.21.8 cassé)

Le rollback de la source chart ne suffit pas si l'image Postiz a aussi été changée et que Prisma a migré le schéma DB. Dans ce cas, la séquence est :

3a. Rollback image seule (si DB non migrée)

Éditer les values inline de l'Application ArgoCD et remettre le tag d'origine :

image:
  tag: "v2.11.2"
# Puis forcer le sync
kubectl annotate application postiz -n argocd \
  argocd.argoproj.io/refresh=hard --overwrite

3b. Rollback image + restauration DB (si Prisma a migré)

Toujours faire un pg_dump avant tout upgrade.

# 1. Scale down pour éviter les écritures pendant la restauration
kubectl scale deployment postiz-postiz-app --replicas=0 -n default

# 2. Identifier le pod PostgreSQL
PGPOD=$(kubectl get pod -n default -l app.kubernetes.io/name=postgresql -o jsonpath='{.items[0].metadata.name}')

# 3. Vider le schéma (le dump pg_dump sans --clean ne contient pas de DROP TABLE)
kubectl exec -n default "$PGPOD" -- bash -c \
  'PGPASSWORD="<password>" psql -U postiz postiz -c \
  "DROP SCHEMA public CASCADE; CREATE SCHEMA public; \
   GRANT ALL ON SCHEMA public TO postiz; \
   GRANT ALL ON SCHEMA public TO public;"'

# 4. Restaurer depuis le backup local
kubectl exec -i -n default "$PGPOD" -- bash -c \
  'PGPASSWORD="<password>" psql -U postiz postiz' \
  < /path/to/postiz-backup-YYYYMMDD.sql

# 5. Remettre le tag image v2.11.2 dans les values ArgoCD, puis scale up
kubectl scale deployment postiz-postiz-app --replicas=1 -n default

Scénario 4 — Rollback vers un commit Gitea précis (pas GitHub)

Si le problème vient d'un commit spécifique sur le fork mais que la branche main reste valide, pointer sur le SHA du dernier commit stable :

# Trouver le SHA stable (ex. avant le commit problématique)
git -C /home/billisdead/gitea-trucs/postiz-helm log --oneline main | head -10

# Patcher vers ce SHA
kubectl patch application postiz -n argocd --type='json' -p='[
  {"op": "replace", "path": "/spec/source/targetRevision", "value": "<SHA>"}
]'

Vérification post-rollback (tous scénarios)

# Source effective
kubectl get application postiz -n argocd \
  -o jsonpath='{.spec.source.repoURL}{"\n"}{.spec.source.targetRevision}{"\n"}'

# État de santé
kubectl get application postiz -n argocd \
  -o jsonpath='{"sync: "}{.status.sync.status}{"\nhealth: "}{.status.health.status}{"\n"}'

# Pod toujours Running sans restart
kubectl get pods -n default -l "app.kubernetes.io/name=postiz-app"

# Logs démarrage (vérifier absence d'erreur Temporal/DB/Redis)
kubectl logs -n default deployment/postiz-postiz-app --tail=30