Skip to content

Plan de reprise

Maxime Golfier edited this page Oct 11, 2023 · 28 revisions

Arbre de dépendances

flowchart BT
    cdtn-admin --> legi-data
    cdtn-admin --> kali-data
    cdtn-admin --> fiches-travail-data
    cdtn-admin --> fiches-vdd
    code-du-travail-numerique --> cdtn-admin
Loading

Chronologie des tâches de reprise

gantt
    dateFormat HH
    axisFormat %H
    
section EXT
    Récupération du code source de l'applicatif : gt1, 08, 5m
    Vérification des sources de données : gt2, after gt1, 5m
    Vérification des services annexes : gt3, after gt2, 5m
    Vérification des accès aux bases de données : gt4, after gt3, 5m

section ADMIN
    Déploiement via la CI : tt1, after gt4, 20m
    Restauration du backup : tt2, after tt1, 5m
    Ingestion des données externes : tt3, after tt2, 6m
    Mise à jour de la preprod : tt4, after tt3, 1h
    Mise à jour de la prod : tt5, after tt4, 1h

section FRONT
    Déploiement via la CI : tp1, after tt5, 20m
Loading

Pré-requis

  • Le service Github doit être accessible
  • La CI / CD doit être fonctionnelle (kontinuous + cluster en état de marche)
  • Un backup de la base de données de l'application d'administration
  • Les bases de données Elasticsearch et PostgreSQL doivent être accessibles, celle-ci peuvent être totalement vides
  • Poste configuré avec un accès au cluster de production

1er étape : Récupération du code source de l'applicatif

  1. Cloner le projet code du travail numérique
  2. Cloner le projet cdtn-admin

Estimation du temps : ~ 5 minutes

2ème étape : Vérification des sources de données

  1. https://github.com/SocialGouv/legi-data
  2. https://github.com/SocialGouv/kali-data
  3. https://github.com/SocialGouv/fiches-travail-data
  4. https://github.com/SocialGouv/fiches-vdd

De plus, comme j'ai pu l'indiqué précédemment dans les pré-requis, il nous faut absolument un backup de la base de données, afin de ne pas perdre toute la donnée utilisateur enregistré

Estimation du temps : ~ 5 minutes

3ème étape : Vérification des services annexes

  1. Il faudra vérifier que le projet recherche-entreprises soit bien disponible. https://api.recherche-entreprises.fabrique.social.gouv.fr
  2. Et aussi, le projet serving-ml soit bien disponible. https://serving-ml.fabrique.social.gouv.fr. Celui-ci est utilisé dans notre moteur de recherche pour l'aspect sémantique.
  3. De manière optionnel, vérifier que matomo pour l'analytics soit bien en route. https://matomo.fabrique.social.gouv.fr
  4. De manière optionnel, le faire aussi pour Sentry, afin de nous remonter des soucis sur l'applicatif https://sentry.fabrique.social.gouv.fr

Estimation du temps : ~ 5 minutes

4ème étape : Vérification des bases de données

Note : Ce processus est à effectuer si les credentials d'accès aux bases de données ont été modifiés

  1. Accéder à la base de données PostgreSQL afin que l'application d'administration puisse avoir des services qui se connecte à celle-ci
  2. Faire la même procédure pour la base de données Elasticsearch qui va être utilisée par le frontend

Les credentials d'accès doivent être de nouveau sceller sur l'application : https://socialgouv.github.io/sre-tools/, et ensuite être mis à jour dans les variables d’environnement du folder kontinuous

Estimation du temps : ~ 5 minutes

5ème étape : Lancement de l'administration

La première étape est la partie déploiement qui devrait être effective grace à la CI / CD. Nous utilisons kontinuous pour cela.

Estimation du temps : ~ 20 minutes

Une fois l'outil d'administration déployé et accessible, nous devons effectuer un pg_restore avec le backup

Estimation du temps : ~ 5 minutes

Lorsque le dernier backup est effectif au sein de PostgreSQL, nous pouvons lancer la commande suivante :

kubectl create job --from=cronjob/cron-ingester cron-ingester-manual

Estimation du temps : ~ 6 minutes

Le but est de tourner l'ingester, qui est un service qui va récupérer les dernières versions des fichiers issus des repositories Github de data.

Une fois cela effectué, il faudra se connecter à l'administration avec un compte précédemment utilisé dans les backups pour lancer une mise à jour de la preproduction, puis de la production.

Le but sous-jacent étant d'utiliser le service export-elasticsearch, qui permet d'exporter les données depuis PostgreSQL en passant par Hasura, vers Elasticsearch.

Estimation du temps : La durée de la mise à jour de la preproduction est d'environ 1 heure, le temps est similaire pour celui de la production.

6ème étape : Lancement du frontend

Lorsque les données sont à jours, il ne reste plus qu'à lancer le processus de CI / CD du frontend résumé dans ce wiki : https://github.com/SocialGouv/code-du-travail-numerique/wiki/D%C3%A9clencher-une-mise-en-production afin de déployer la dernière version du frontend.

Dans le cas où la CI / CD est fonctionnel, le frontend sera déployé sur les dernières données issues du backup de la base de données qui a été mis à jour avec les dernières données issues des repository Github de data.

Estimation du temps : ~ 20 minutes

7ème étape : Vérification du déploiement du site principal

Il faut se connecter sur https://code.travail.gouv.fr

Estimation total du temps : ~ 3 heures 30 minutes