Hello,
allez, un petit pour la route, tout frais d’hier soir.
Je dois upgrader Harbor en dernière version, via chart Helm.
Après un helm diff upgrade
, je remarque qu’il y a beaucoup de changements… modification des values pour corriger cela (cf harbor-helm/Upgrade.md at master · goharbor/harbor-helm · GitHub)
Maintenant tout semble OK, j’ai bien mes backups au cas où, l’upgrade s’est bien passée en environnement de pré-prod.
Vient le moment de l’upgrade:
- Tout se passe “presque” bien…
- Les pods redémarrent, la BDD migre, postgres démarre OK
- Bizarrement les applis n’arrivent pas à contacter la BDD, les bases “registry” and co sont inexistantes !!
A priori, le volume persistant qui héberge la BDD est trop juste, mais pas suffisamment pour remonter un alerte avant l’upgrade. Donc harbor/pg a tenter l’upgrade de la BDD, s’est foiré, a perdu les data. Youpi \m/
Obligé alors de sortir la restauration velero (sur un autre cluster “juste” pour avoir le dump de la bdd).
Manque de bol, coupure réseau lors de la restauration, je suis un peu fatigué, je refais, entrées en double dans la BDD, au redémarrage les applis se foirent de partout !
Biensur, un kubectl copy
ne fonctionne pas pour faire le dump en local car les conteneurs postgres n’ont pas tar
. Obligé de monter le volume via un autre pod pour la copy/restauration.
Les alertes commencent à tomber, sur les cronjobs qui pull régulièrement les images docker, oh joie…
On se calme, il est tard, je fais qq manips, au bout du compte la restauration est OK, les pods redémarrent, je vais pouvoir me coucher, et les utilisateurs le lendemain n’auront vu que du feu !
Bilan de l’intervention:
- toujours faire un backup de la BDD, mais ça tout le monde le sait (sauf ceux qui ont un peu trop confiance en eux)
- vérifier l’état des volumes persistants, qu’ils soient pas “juste” en taille pour éventuellement permettre un dump.
Allez, on se décourage pas, ce soir j’enchaine avec GitLab
Edit: upgrade GitLab est passée sans encombres !