Pour la restauration comme pour la sauvegarde, velero est utilisé.

#TL;DR

La restauration est déclenchée à la création d’un objet Velero Restore. L’objet Restore de référence est commité dans ce projet et devrait être adapté suite à chaque changement d’infrastructure applicative. Cet objet par défaut restaure seulement les namespaces central et cinecity, et concerne tous les objets Kubernetes (sauf configmap/secrets) ainsi que les volumes sauvegardés par la partie Backup. Avant tout Restore, il est nécessaire de supprimer la ressource ciblée, donc si l’objet Restore global est utilisé, il est nécessaire de supprimer les namespaces qual-cinecity et qual-central sur le cluster de qual.

En amont, vérifier d’avoir les configmaps / secrets de l’environnement cible, poussés et présents sur un repo gitlab/github.

#Détails du processus Velero

Lorsque le pod Velero déployé dans un cluster voit un nouvel objet Restore, il déclenche la restauration en regardant l’objet de Backup demandé, quels namespaces il s’agit (includedNamespaces), les éventuels labels d’application à restaurer seulement, un mapping pour mettre à jour le namespace de destination (après restauration) selon celui de source, etc…

Il est donc possible de ne restaurer qu’une seule application et non pas totalement un namespace grâce à des labels. Il est dans ce cas grandement conseillé de supprimer tout objet existant lié à cette application (StatefulSet, PVC, configMap, etc…). Voir l’exemple avec un restore de pgstats.

#Notes par namespace

#CENTRAL

#01 - Déploiement des fichiers kubernets

Configuration manquante à déployer :

• cineges-config
• cineges-secret

Certains déploiements doivent être redéployés manuellement pour éditer les bonnes configurations.

Déploiement :

• customer-photo-to-cinecity
• movie-to-cinecity
• report-from-kone
• minio.deploy

Pour déployer un objet kubernet via un fichier sur un namespace kube :

kubectl --context ${KUBE_CONTEXT} -n ${NAMESPACE} apply -f ${PATH_FILE_KUBE_OBJECT}

#02 - Création des topics

Depuis le dossier cineges-backend/tools, lancez la commande suivante :

./run-dev-central.sh nc.wdt.cineges.tools.kafka.EnsureKafkaTopicsExists

#03 - Vérifier les ingress

Vérifier les ingress, si il pointe vers le bon service (service de qual ou de prod).

#COMPLEXE

#01 - Déploiement des fichiers kubernets

Configuration manquante à déployer :

• cineges-config
• env-json
• cineges-secret
• hwproxy

Certains déploiements doivent être redéployés manuellement pour éditer les bonnes configurations.

Déploiement :

• minio
• minio-mirror-customer-photo-file-to-central

Pour déployer un objet kubernet via un fichier sur un namespace kube :

kubectl --context ${KUBE_CONTEXT} -n ${NAMESPACE} apply -f ${PATH_FILE_KUBE_OBJECT}

#02 - Création des topics

Depuis le dossier cineges-backend/tools, lancez la commande suivante :

./run-dev-complexe.sh nc.wdt.cineges.tools.kafka.EnsureKafkaTopicsExists

#03 - Création des base de données postgres non restauré.

Pour le bon fonctionnement de certains application, il faut créer des bases de données non restaurées.

Création de la base de donnée :

• logs

kubectl --context $KUBE_CONTEXT -n $NAMESPACE exec -it postgres-0 -- psql postgres odoo -c "CREATE DATABASE logs"
kubectl --context $KUBE_CONTEXT -n $NAMESPACE exec -it postgres-0 -- psql logs odoo -c "CREATE TABLE public.frontend_log (id serial4 NOT NULL,"level" int4 NULL,"timestamp" timestamptz NULL,hostname text NULL,session_id text NULL,basket_id text NULL,"data" jsonb NULL,CONSTRAINT frontend_log_pkey PRIMARY KEY (id))"
kubectl --context $KUBE_CONTEXT -n $NAMESPACE exec -it postgres-0 -- psql logs odoo -c "CREATE TABLE public.access_info_decrypt (id serial4 NOT NULL,user_id text NULL,"access" bool NULL,"date" timestamptz NULL,payment_id text NULL,payment_date timestamptz NULL,payment_amount text NULL,pament_hostname text NULL,uuid text NULL,CONSTRAINT access_info_decrypt_pkey PRIMARY KEY (id))"
kubectl --context $KUBE_CONTEXT -n $NAMESPACE delete pods release=logs-api

• cineges

kubectl --context $KUBE_CONTEXT -n $NAMESPACE exec -it postgres-0 -- psql postgres odoo -c "CREATE DATABASE cineges"
kubectl --context $KUBE_CONTEXT -n $NAMESPACE exec -it postgres-0 -- psql cineges odoo -c "CREATE TABLE public.baskets (id varchar NOT NULL,basket jsonb NULL,created_at timestamp NULL,updated_at timestamp NULL,status varchar NULL,message varchar NULL)"
kubectl --context $KUBE_CONTEXT -n $NAMESPACE delete pods release=cineges-caisse-jobs

#04 - Suppresion des cronjobs spécifique au namespace source

kubectl --context $KUBE_CONTEXT -n $NAMESPACE delete cronjobs.batch -l app.kubernetes.io/name=kioskctl

Les points 01, 03, 04 ont été scripté (ref: qualif-cinecity). Script à adapter selon le namespace cible.

#05 - Vérifier les ingress

Vérifier les ingress, si il pointe vers le bon service (service de qual ou de prod).

---

#Charts helm.

Vérifier que les charts helm ont pour namespace, le namespace cible et non le namespace source du backup.

Dans le cas ou, le namespace n’est pas le bon.

Il faut redéployer (uninstall and install) les charts pour avoir les bons namespaces.
Assurez-vous que les PVC ne se suppriment pas lors de la dé-installation pour ne pas perdre les données.

Redéloyer avec les mêmes values les charts.

Attention : certaines images de déploiement sont changées manuellement et la version du chart n’est pas forcément la même.

Source Git :

• infra
• apps

Script à adapter selon le namespace.