Disons que distroless pour embarquer du static, c'est un peu comme du scratch mais en mieux.
Tiens pourquoi tu privilégie distrless pour du statique ?
Le seul problème que j'ai pour le moment avec distroless (outre le manque d'une image ruby) c'est pour faire tourner du python avec du pip install durant le build du container. Je crois qu'on peut faire des choses avec BAZEL mais j'ai pas encore vraiment tenté.
Je ne connais vraiment pas bien le build python, mais ça peut pas être résolu par du multistage ? Tu fais ton build dans une image alpine/ubuntu/whatever, puis tu copie tes artefacts (ton code et ses dépendances) dans un distroless. C'est un peu minimaliste, mais leur exemple montre ce genre d'usage : https://github.com/GoogleContainerTools/distroless/blob/master/examples/python2.7/Dockerfile
Ce que j'aime dans scratch/distroless c'est aussi une histoire de principe.
Ça dépend de pleins de choses les containers ce n'est pas que des runners de prod, c'est aussi des runners en dev que tu va vouloir potentiellement plus verbeux, des builders que tu va utilliser en IC, voir des outils que tu va utiliser sur ta machine. Par exemple, je n'installe pas node sur ma machine, mais une image node, ce qui me permet de choisir facilement quelle version de node j'utilise par exemple. Mais ça devient vraiment intéressant quand tu utilise npm, qui demande un compilateur C et que tu veux un peu uniformiser le build dans une équipe. Au lieu de demander à chacun d'installer build-essential ou équivalent dans sa distribution en espérant que les versions de chaque paquet soient identiques et compilés avec les même options, tu peux partager une image qui fait déjà le job. Mais pour ça, alpine ou ubuntu ça marche bien :)
[^] # Re: distroless
Posté par barmic . En réponse au journal Une image de base docker. Évalué à 4.
Tiens pourquoi tu privilégie distrless pour du statique ?
Je ne connais vraiment pas bien le build python, mais ça peut pas être résolu par du multistage ? Tu fais ton build dans une image alpine/ubuntu/whatever, puis tu copie tes artefacts (ton code et ses dépendances) dans un distroless. C'est un peu minimaliste, mais leur exemple montre ce genre d'usage : https://github.com/GoogleContainerTools/distroless/blob/master/examples/python2.7/Dockerfile
Ça dépend de pleins de choses les containers ce n'est pas que des runners de prod, c'est aussi des runners en dev que tu va vouloir potentiellement plus verbeux, des builders que tu va utilliser en IC, voir des outils que tu va utiliser sur ta machine. Par exemple, je n'installe pas node sur ma machine, mais une image node, ce qui me permet de choisir facilement quelle version de node j'utilise par exemple. Mais ça devient vraiment intéressant quand tu utilise npm, qui demande un compilateur C et que tu veux un peu uniformiser le build dans une équipe. Au lieu de demander à chacun d'installer build-essential ou équivalent dans sa distribution en espérant que les versions de chaque paquet soient identiques et compilés avec les même options, tu peux partager une image qui fait déjà le job. Mais pour ça, alpine ou ubuntu ça marche bien :)