arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

Update Article “2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build”

Browse source
This commit is contained in:
Quentin 2023-04-12 14:11:08 +00:00
parent 871f70f81c
commit 4ac5cfd5e8
1 changed files with 30 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -20,6 +20,34 @@ L'API S3 a un concept de Lifecycle Management et peut expirer des objets après
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é._ 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. 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. Et ça veut dire que si on ne garbage collect pas les nightly builds, cet index peut devenir bien grand…
À 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, et comment créer un outil qui facilite au maximum cette gestion.
## Créer un index pour un registre OCI
On peut regarder un peu ce que donne le registre Docker pour Garage :
```json
{
"name": "dxflrs/garage",
"tags": [
"02e8eb167efa1f08d69fe7f8e6192cde726c45aa",
"<skipped entries>",
"fcc5033466e58e3beec05ee7748d33522b6b32b0",
"v0.7.3",
"v0.8-rc2",
"v0.8.0",
"v0.8.0-beta1",
"v0.8.0-beta2",
"v0.8.0-rc1",
"v0.8.0-rc2",
"v0.8.1",
"v0.8.2"
]
}
```
À 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,