Jusqu'à présent j'utilisais pas mal d'alpine, et maintenant dès que je peux du distroless.
Disons que distroless pour embarquer du static, c'est un peu comme du scratch mais en mieux.
Alpine c'est sympa, mais ça finissait toujours par avoir besoin à un moment ou à un autre de la glibc (ou compat) donc l'intérêt se réduit franchement.
Ce que j'aime dans scratch/distroless c'est aussi une histoire de principe. J'aime voir les containeurs comme étant juste mon app/service avec ses dépendances et rien d'autre. Juste une sandbox. La plus petite possible, le reste étant superflus, inutile, source problème, de failles, de maintenance, etc.
Le contraire exact de "containers comme des VMs".
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é.
Si quelqu'un sait embarquer au build des dépendances python sur distroless, ça m'intéresse grandement :-)
Il y a pas mal de bonnes conférences sur pourquoi c'est bien d'avoir des images petites et comment faire (entre autre de Abby Fuller, par exemple https://www.youtube.com/watch?v=pPsREQbf3PA de mémoire)
Après tout dépend aussi du contexte, parfois ça peut se faire d'avoir des images plus lourdes avec un layer commun, partagé entre toutes les images et qui sera dispo sur toutes les machines. Dans certains contextes ça peut le faire, avec l'avantage de mutualiser certains problèmes de sécu, d'outils dispo, de version, etc.
L'avantage si tout est dans une image de base c'est qu'un docker pull ne téléchargera que les layers manquant, donc lui sera relativement rapide.
# distroless
Posté par CrEv (site web personnel) . En réponse au journal Une image de base docker. Évalué à 8.
Jusqu'à présent j'utilisais pas mal d'alpine, et maintenant dès que je peux du distroless.
Disons que distroless pour embarquer du static, c'est un peu comme du
scratchmais en mieux.Alpine c'est sympa, mais ça finissait toujours par avoir besoin à un moment ou à un autre de la glibc (ou compat) donc l'intérêt se réduit franchement.
Ce que j'aime dans scratch/distroless c'est aussi une histoire de principe. J'aime voir les containeurs comme étant juste mon app/service avec ses dépendances et rien d'autre. Juste une sandbox. La plus petite possible, le reste étant superflus, inutile, source problème, de failles, de maintenance, etc.
Le contraire exact de "containers comme des VMs".
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 installdurant le build du container. Je crois qu'on peut faire des choses avec BAZEL mais j'ai pas encore vraiment tenté.Si quelqu'un sait embarquer au build des dépendances python sur distroless, ça m'intéresse grandement :-)
Il y a pas mal de bonnes conférences sur pourquoi c'est bien d'avoir des images petites et comment faire (entre autre de Abby Fuller, par exemple https://www.youtube.com/watch?v=pPsREQbf3PA de mémoire)
Après tout dépend aussi du contexte, parfois ça peut se faire d'avoir des images plus lourdes avec un layer commun, partagé entre toutes les images et qui sera dispo sur toutes les machines. Dans certains contextes ça peut le faire, avec l'avantage de mutualiser certains problèmes de sécu, d'outils dispo, de version, etc.
L'avantage si tout est dans une image de base c'est qu'un docker pull ne téléchargera que les layers manquant, donc lui sera relativement rapide.