Automatiser la recréation de l'image en vigueur

[thbar]

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

https://github.com/etalab/transport-site/blob/b06638a7623718dfbca21cbee25c6d5f425bc375/Dockerfile#L1

Dans etalab/transport-site#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:

1. 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)
2. 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:

transport-ops/.github/workflows/docker.yml

Lines 62 to 70 in d5195b5

	# NOTE: the following tests rely on grep exit code (0 if match found)
	- name: Test that Node can start and has expected version
	run: docker run --rm ${{ env.TEST_TAG }} /bin/bash -c 'node --version' | grep '${{ env.TEST_EXPECTED_NODE_OUTPUT }}'
	- name: Test that Elixir can start and has expected version
	run: docker run --rm ${{ env.TEST_TAG }} /bin/bash -c 'elixir --version' | grep '${{ env.TEST_EXPECTED_ELIXIR_OUTPUT }}'
	- name: Test that Erlang can start and has expected version (major + minor + optional revision number)
	run: docker run --rm ${{ env.TEST_TAG }} /bin/bash -c "erl -eval '{ok, Version} = file:read_file(filename:join([code:root_dir(), \"releases\", erlang:system_info(otp_release), \"OTP_VERSION\"])), io:fwrite(Version), halt().' -noshell" | grep '${{ env.TEST_EXPECTED_ERLANG_OUTPUT }}'

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]

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

• la construction de l'image rapporte transport-tools au passage (

  transport-ops/transport-site/Dockerfile

  Line 2 in d5195b5

  FROM ghcr.io/etalab/transport-tools:v1.0.3 as transport-tools

  ) 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]

Tests en cours avec le workflow_dispatch event trigger.

[thbar]

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

rebuild-image.mp4

[thbar]

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