quentin/quentin.dufour.io
1
0
Fork 2
Code Issues 3 Pull requests Releases Wiki Activity

Update Article “2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build”
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse source
This commit is contained in:
Quentin 2023-04-12 13:33:56 +00:00
parent 3a86fda844
commit adf96928fa
1 changed files with 6 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md
View file

@ -18,6 +18,12 @@ On peut alors imaginer un affichage différencié de ces buils : les builds rele
L'API S3 a un concept de Lifecycle Management et peut expirer des objets après un temps donné, c'est à dire les supprimer. Par exemple, on peut définir que les objets ayant leur préfix commençant par `logs/` seront supprimés après un an. Il serait tentant d'utiliser ce système pour notre système de gestion d'artefacts mais ça pose plusieurs problèmes : à ce jour, Garage n'implémente pas les Lifecycle Management, aussi le fonctionnement des images Docker fait qu'il est possible que plusieurs version d'une même image partagent un même blob, et enfin on est amené à générer un index qui liste toutes nos images, et qui se retrouvera donc à être invalide. L'API S3 a un concept de Lifecycle Management et peut expirer des objets après un temps donné, c'est à dire les supprimer. Par exemple, on peut définir que les objets ayant leur préfix commençant par `logs/` seront supprimés après un an. Il serait tentant d'utiliser ce système pour notre système de gestion d'artefacts mais ça pose plusieurs problèmes : à ce jour, Garage n'implémente pas les Lifecycle Management, aussi le fonctionnement des images Docker fait qu'il est possible que plusieurs version d'une même image partagent un même blob, et enfin on est amené à générer un index qui liste toutes nos images, et qui se retrouvera donc à être invalide.
Docker, et donc l'Open Container Initiative, a une spécification pour définir un index de tags pour une image donnée. Tout ça est décrit dans la spec “distribution” dans la section [Content Discovery](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-discovery). Implémenter cette spécification pour lister nos tags améliorerait l'intéropérabilité de notre registre avec les autres clients OCI. _Même si on ne pourra pas tout implémenter, par exemple le paging définit par la spec ne pourra pas être codé._
La spécification OCI pourrait nous servir d'inspiration pour notre dépôt de fichiers statiques. Tout ça dans l'espoir de faciliter l'écriture du code et de limiter le nombre de conceps à manipuler. Mais cela veut aussi dire qu'on extrait de l'index la charge de catégoriser les tags (release, extra, development). Ça deviendrait alors une convention pour celles et ceux qui intéragissent avec notre futur outil.
À travers ce panorama, je pense qu'on arrive au noeud du problème à traiter aujourd'hui : la spécification de notre index pour les fichiers statiques, la spécification de la convention à suivre pour les tags,