Le processus de créer une image Docker est toujours sujet à débat : il y a les pros Dockerfile et les antis, ceux qui pensent que c'est simple, et ceux qui ne comprennent pas pourquoi cette responsabilité devrait « shifter » vers eux. Et c'est vrai, créer une image Docker n'est pas si simple : on ne s'improvise pas expert en packaging du jour au lendemain. Par chance, il existe une alternative out-of-the-box au classique Dockerfile : les Buildpacks.
J'ai longtemps travaillé côté ops dans ma carrière, et honnêtement, je ne trouve rien à redire quand Docker prétend qu'un Dockerfile n'est rien de plus qu'un fichier texte dans lequel on place les instructions d'installation d'une application. Pourtant, durant les formations que j'ai pu donner, j'ai pu me rendre compte que cette « simplicité » n'avait rien d'évident en réalité et que la plupart des devs souffraient souvent du processus de création d'images, tandis que les ops n'en maîtrisaient pas toujours tous les enjeux. D'accord, après avoir googlé pendant quelques minutes il est facile d'avoir « un truc » qui marche ; mais ce truc qui marche est souvent bien loin d'être optimisé et risque de présenter bon nombre de failles de sécurité. C'est pourquoi j'ai toujours eu un faible pour les buildpacks : exit Dockerfile, il suffit de présenter au builder notre code et hop, ils se chargent de tout le reste. Dans cet article, je vais vous présenter aussi...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première