1. Accueil
  2. Blog
  3. Réorganisation de mes images Docker et mise en place builds automatisés

Réorganisation de mes images Docker et mise en place builds automatisés

Créé le 10/06/2018

Dernière mise à jour le 10/06/2018

Étiquettes

Hier, j'ai réorganisé mes images Docker. Cet article va résumer les changements et expliquer pourquoi de telles modifications.

C'est un commentaire d'Ines Wallon à propos du fait que le hub Docker peut être paramètré pour construire les images Docker automatiquement qui a déclenché cette réorganisation.

Pourquoi ?

En effet, jusqu'à présent, je reconstruisais mes images de temps en temps lorsque je faisais des modifications. Cela avait les désavantages suivants :

  • ça prend du temps : lancer manuellement les commandes de build pour les différentes images, une image après l'autre, puis les uploader est long. Surtout l'upload sur le hub, ayant une connexion internet assez lente,

  • moins bonne qualité : avec cette réorganisation, j'ai pu me rendre compte que l'image PHP (locale) utilisée comme base pour mes images n'était pas à jour (Debian 8 au lieu de Debian 9).

Avec le build automatisé :

  • il est plus facile d'avoir différentes versions d'une image et quelles soient toutes à jour,

  • les images construites ont leur parent à jour,

  • plus besoin d'upload.

Build automatisé Docker

Lorsque j'avais commencé à utiliser Docker, je n'avais pas regardé les options de build automatisé car :

  • je débutais en Docker et donc j'avais assez d'autres points à explorer

  • fonctionner manuellement dans un premier temps permet de voir les différents problèmes et de mieux comprendre pourquoi il peut y avoir telle ou telle organisation dans les images officielles ou personnelles d'autres personnes utilisant Docker.

  • j'avais eu l'impression que c'était réservé uniquement au compte Premium.

Pour les comptes gratuits, il y a une limitation à un build en simultané.

Ce n'est pas gênant pour mon utilisation, je n'ai pas 40 images à mettre à jour 10 fois quotidiennement.

Build automatisé ne veut pas nécessairement signifier build déclenché automatiquement.

Un build automatisé signifie que l'on crée une image Docker en renseignant un dépôt Git (Github ou Bitbucket) et que l'on précise :

  • la branche Git à utiliser,

  • le chemin vers le fichier Dockerfile,

  • le tag de l'image Docker produite.

Avec ces éléments, on a ensuite un bouton permettant de déclencher le build.

On peut bien sûr ensuite faire en sorte que les builds soient déclenchés automatiquement de plusieurs manières :

  • en liant les dépôts Docker : si des images sont construites sur un autre dépôt, cela déclenche la construction sur ce dépôt.

  • en activant des déclencheurs (Webhooks) puis en renseignant sur Github par exemple les URLs et clés d'accès pour déclencher ces Webhooks.

Note : il n'est pas possible de transformer un dépôt Docker en dépôt avec build automatisé (à moins que je n'ai pas vu l'option), on est obligé de supprimer le dépôt manuel puis en refaire un en mode build automatisé si l'on veut conserver le même nom d'image.

De même une fois un build automatisé branché sur un dépôt Git, il n'y a pas d'option pour changer de dépôt Git.

Réorganisation

Arborescence des images, https://github.com/FlorentTorregrosa/docker-drupal-project/tree/8.x/docker-images :

Avant :

  • php-apache-dev : docker-drupal-dev:php7, image pour le développement, PHP 7.1 avec Apache

    • le tag n'indique pas PHP 7.1

    • docker dans le nom de l'image

  • php-apache : docker-drupal:php7, image pour faire fonctionner Drupal, PHP 7.1 avec Apache

    • le tag n'indique pas PHP 7.1, ni Apache

    • docker dans le nom de l'image

  • php-dev : drupal-php-dev, image pour faire fonctionner Drupal avec outils de développement, PHP 7.0 sous Alpine

    • plus à jour

    • le tag ne comportait pas d'information

  • php : drupal-php, image pour faire fonctionner Drupal, PHP 7.0 sous Alpine

    • plus à jour

    • le tag ne comportait pas d'information

  • varnish : docker-varnish:latest, Varnish 4 sous Alpine

    • pas de tag

    • docker dans le nom de l'image

Après :

  • drupal-php :

    • 7.1

      • apache

    • 7.2

      • apache

  • drupal-php-dev :

    • 7.1

      • apache

    • 7.2

      • apache

  • varnish :

    • 4

      • alpine

    • 5

      • alpine

drupal-php :

  • image pour faire fonctionner Drupal,

  • reprise de l'arborescence de l'image PHP officielle,

  • prêt pour avoir les versions FPM s'il faut,

  • dossier racine correspondant au nom de l'image.

drupal-php-dev :

  • image pour faire fonctionner Drupal avec outils de développement,

  • reprise de l'arborescence de l'image PHP officielle,

  • prêt pour avoir les versions FPM s'il faut,

  • dossier racine correspondant au nom de l'image.

varnish :

  • image pour avoir un Varnish,

  • plusieurs versions de Varnish désormais. Pas de Varnish 6 car pour l'instant présent uniquement sur la version edge de Alpine,

  • prêt pour avoir des versions sur d'autres distributions Linux s'il faut,

  • dossier racine correspondant au nom de l'image.

Suppression des versions PHP FPM, car plus à jour et plus utilisées. Je les referai lorsque j'en aurai besoin.

J'en ai profité également pour retirer « docker » du nom des images car :

  • si ce sont des images Docker, on sait que ça a un lien avec Docker

  • il me semble avoir vu que la société Docker faisait attention à l'utilisation du mot Docker pour le réserver à des utilisations officielles.

Les dépôts Git et Docker suivants vont être/ont été supprimés :

Suppression car obsolètes et je n'aime pas laisser traîner des dépôts obsolètes, ça embrouille la lisibilité. C'est déroutant quand on parcourt des dépôts publiques pour voir comment les choses sont faîtes et qu'on se rend compte qu'ils ne sont plus utilisés.

Au niveau du paramètrage des builds automatisés, il y a désormais création des images avec tags par rapport au Dockerfile correspondant dans l'arborescence.

Il y aussi déclenchement des builds pour les images varnish et drupal-php lors de push sur le dépôt https://github.com/FlorentTorregrosa/docker-drupal-project.

Le build de l'image drupal-php-dev est déclenché automatiquement lorsque l'image drupal-php est buildée. Et comme drupal-php est buildée à chaque push dans le dépôt, même si elle n'est pas changée, cela va mettre drupal-php-dev à jour.

Effet de bord :

Lors de push sur https://github.com/FlorentTorregrosa/docker-drupal-project, ça déclenche les constructions des images, même si aucun fichier du dossier docker-images n'a été touché. Et cela même lors de push, sur une branche autre que la 8.x.

Heureusement, ce n'est pas critique, et au moins ça rafraîchira les images même si leur Dockerfile n'est pas touché.

Du coup, je comprends mieux pourquoi je vois les fichiers nécessaires aux images Docker dans des dépôts Git séparés des dépôts projets et chaque image dans son dépôt.

Peut être que j'en (re-)viendrai à cette organisation. Mais j'avais voulu mettre les images Docker dans le dépôt https://github.com/FlorentTorregrosa/docker-drupal-project afin que lorsqu'un changement de configuration était nécessaire et qu'il y avait à la fois changement dans une image et dans les fichiers de configuration, cela soit indiqué via un seul commit pour plus de lisibilité.

À voir, si je sortirai uniquement le dossier docker-images dans un dépôt à part ou si je passerai à un dépôt par image.

Problèmes rencontrés

Avec le passage à Debian 9, car les dernières versions des images officielles php:7.1-apache et php:7.2-apache sont sur Debian 9, j'ai eu les problèmes suivants :

  • le paquet libpng12-dev n'existe plus, utilisation de libpng-dev,

  • le paquet gnupg n'est pas déjà installé, j'ai dû le rajouter sinon cela poser problème lors de l'installation de NodeJs dans l'image de développement.

Le fait de construire des versions pour PHP 7.2 des images a permis de se rappeler que la librairie PHP mcrypt marquée comme deprecated en PHP 7.1, est complètement retirée en PHP 7.2. D'où son retrait des images.

Note : j'en ai profité pour faire un passage de Piwik à Matomo, maintenant qu'il y a une image officielle pour Matomo.

Prochaines étapes

Peut être rajouté des Readme.md dans les sous-dossiers de chaque image pour documenter leur fonctionnement. Actuellement le fonctionnement est visible via l'utilisation dans le dépôt https://github.com/FlorentTorregrosa/docker-drupal-project, mais si l'on va sur la page du hub Docker des images cela peut ne pas être évident.

Documentation :

Ajouter un commentaire

À propos des formats de texte