Automatiser la recréation de l'image en vigueur

thbar commented 2 years ago

L'image de départ utilisée en production est spécifiée ici:

Dans https://github.com/etalab/transport-site/pull/2406, j'ai mis en place le scan de cette image via Trivy de façon hebdomadaire.

Nous pouvons ensuite aller à l'étape suivante, qui consiste à reconstruire cette même référence et à la re-publier.

Il faut pour cela:

Déterminer la bonne façon de re-déclencher une construction (pas depuis master, mais depuis le bon point de référence qui a servi à créer la release)
Avoir un processus automatisé de qualité suffisante pour pouvoir asserter que l'image sera fonctionnelle (car une fois que l'image est republiée sous la même référence, le prochain déploiement de l'application se fera dessus)

Sur le point 2., j'ai déjà implémenté des checks, qui seront potentiellement suffisants:

Je crée le ticket pour noter l'idée, et je vais aller mettre à jour autrement pour aujourd'hui, à savoir en créant une nouvelle image.

thbar commented 2 years ago

Notes supplémentaires pour la vérification automatisée :

la construction de l'image rapporte transport-tools au passage (https://github.com/etalab/transport-ops/blob/d5195b5e418c7e71fbfcb1e2731710a3cf0179dc/transport-site/Dockerfile#L2) et si on automatise, il faudrait vérifier ce point dans la cible (ici)
les parties associées peuvent inclure des failles
de façon générale, on pourrait avoir un seuil de vulnérabilités à la publication également (scan Trivy préalable à publication)

thbar commented 2 years ago

Tests en cours avec le workflow_dispatch event trigger.

thbar commented 2 years ago

Ca fonctionne bien, j'ai pu reconstruire l'image, capturé vite fait en vidéo comme ça tout le monde pourra le faire:

thbar commented 2 years ago

Prochaines étapes : s'inspirer de ça, trouver comment prendre "juste la latest" et redéclencher une fois par semaine pour avoir les patchs.

etalab / transport-ops