Docker: quoi de neuf et qu’est-ce qui s’en vient ?

Si vous utilisez DevOps, vous connaissez probablement Docker, une plateforme qui permet aux développeurs et aux administrateurs de systèmes de construire, livrer et exécuter des applications distribuées. Il y a quelques semaines, j’ai eu la chance de me rendre à Austin, au Texas, pour assister au DockerCon, une conférence regroupant des experts Docker d’un peu partout à travers la planète. C’était très stimulant et inspirant d’être entouré de tous ses passionnés de Docker et de les écouter parler du futur de la plateforme. J’avais hâte de pouvoir télécharger la nouvelle version !

En revenant de la conférence, j’ai pensé que ce serait une bonne idée de prendre un peu de temps pour discuter des nouveautés dans le monde de Docker et de ce qui s’en vient pour la plateforme. Commençons par le système de versionnage de Docker, qui vient tout juste d’être mis à jour pour standardiser les versions Entreprise et Community. Le versionnage utilise maintenant le format suivant : Année.Mois.Version, plus -ce (pour « Community Edition ») ou –ee (pour « Enterprise Edition »). Pour donner un exemple concret, une nouvelle version Community lancée en mars 2017 serait nommée « 17.03.0-ce ». Community Edition possède aussi deux variantes : « Regular » et « Edge ».

Les différences principales entre Entreprise Edition, Community Edition et Community Edge Edition sont la fréquence à laquelle des nouvelles versions sont lancées et la période de support. La variante Community Edge Edition, par exemple, est mise à jour chaque mois et supportée pendant quelques semaines seulement, donc vous devez télécharger la nouvelle version dès qu’elle est disponible. Pour des besoins de production, cette version n’est pas idéale, mais pour un système dev ou build, ça peut être une bonne façon de tester des nouvelles fonctions avant qu’elles soient ajoutées officiellement à la version Enterprise. Un bon exemple de cette approche est la fonction Multi Stage Build, dont nous allons discuter bientôt. Cette fonction va officiellement faire partie de la version 17.05, mais les usagers de la version Edge peuvent déjà tester ses possibilités.

En comparaison, la version Community Edition est lancée 4 fois par an et supportée pendant 4 mois, ce qui vous donne à peu près un mois pour télécharger la nouvelle version. La version Enterprise Edition est aussi lancée quatre fois par an, mais supportée pendant plus d’un an. Vous recevez également du support additionnel ainsi que des outils utiles.

Parlons maintenant de la fonction Multi Stage Build, qui va faire partie de la version 17.05. C’est une fonction que j’aurais aimé avoir il y a quelques mois, quand Askida avait des problèmes avec la taille de ses images. En fin de compte, nous avons utilisé une solution alternative en passant par Ansible, ce qui n’était pas idéal. Pendant la conférence « What’s Next » au DockerCon, une solution intéressante à ce problème, le Multi Stage Build, a été présentée devant tout le monde.

Le Multi Stage Build change complètement la façon dont les Images Docker sont construites. Pour construire un fichier Docker, nous procédons généralement de façon séquentielle, en commençant avec un énoncé « From » suivi d’une série d’instructions. Si vous avez 30 étapes au total et que vous décidez de modifier l’étape #4, vous devez recompiler de l’étape 4 jusqu’à la toute fin. De plus, tous les outils de développement sont conservés à l’intérieur du fichier Docker, ce qui peut rendre l’image finale très lourde et explique le besoin d’utiliser Ansible, des scripts bash ou plusieurs fichiers Docker pour produire une image finale plus légère et plus propre. Avec la fonction, Multi Stage Build, il est maintenant possible d’utiliser plusieurs énoncés « From », ce qui permet de séparer plusieurs grosses tâches en modules plus petits. Si vous modifiez un module, vous n’avez pas à recompiler tous les autres.

Si nous regardons l’application Go suivante, nous constatons que l’image finale a été réduite de 258 MB à seulement 6 MB, ce qui est très impressionnant lorsque l’on considère que l’application finale conserve toutes ses fonctionnalités.

Les instructions de service (« Service commands ») ont également été améliorées. Nous avons maintenant accès à :

Instructions simultanées : Lorsque nous créons un service, celui-ci ne sait pas exactement où il se situe. Nous ne connaissons pas toutes les étapes, donc nous recevons un ID en retour et c’est tout. Cette approche fonctionne dans la plupart des cas, mais si vous voulez avoir un script automatisé qui réagit selon le retour, vous devrez aller chercher l’état actuel. L’équipe Docker a ajouté les instructions simultanées (« Synchronous Service ») qui vous permettent de séquencer plusieurs actions simultanées. Lorsque le service est appelé, toutes les étapes sont décrites et le service se termine lorsqu’elles sont complétées. Visuellement, vous pouvez même voir un indicateur de progrès comme pour n’importe quelle autre application.

Retour en arrière automatique : Avant, avec Docker, nous pouvions seulement arrêter ou continuer lorsqu’une erreur se produisait pendant une mise à jour. Maintenant, nous pouvons ajouter une action de retour en arrière (« automatic rollback »), ce qui simplifie grandement les pipelines CICD. Une action peut même être scriptée selon une erreur ou un pourcentage d’erreurs. Dans certains cas, il est parfois acceptable de continuer avec une mise à jour même si 10% de celle-ci a échoué.

Registre des services : Puisque les services peuvent être représentés par un grand nombre de duplicatas, consulter le registre des services (« Service log ») est parfois laborieux. Bien sûr, vous pouvez utiliser un système de registre centralisé comme le système ELK (Elastic, Logtstash, Kibana), mais sans ceux-ci, le registre des services peut être un cauchemar. Heureusement, l’équipe de Docker a ajouté un registre des services qui peut aller chercher le registre de tous les conteneurs pour un service précis. Vous pouvez maintenant aller chercher un nombre de lignes précises ou même suivre une donnée particulière. Par contre, ceci fonctionne seulement avec les pilotes JSON ou Journald.

Placement selon le contexte : Il est normal de contrôler où les conteneurs sont placés puisque certains maillons de la chaîne ciblent un environnement technologique précis ou encore possèdent des interfaces de réseaux particulières. Il est possible de déclarer des contraintes pour forcer le conteneur à se placer sur un maillon d’un groupe précis. Par contre, si aucun de ces maillons est disponible, un échec aura lieu. Avec le placement selon le contexte (« topology-aware placement »), nous pouvons ajouter davantage de préférences pour faciliter le placement. Par exemple, disons que nous plaçons des maillons dans différentes zones, comme 2 à Montréal et 2 à Toronto. Avec le placement régulier, si nous demandons deux duplicatas, il est fort probable que l’on obtienne un conteneur sur chacun des deux maillons situés à Montréal. Si le groupe de Montréal a un problème, le système pourrait être inactif pendant plusieurs secondes ou mêmes minutes. Avec le placement selon le contexte, nous pouvons maintenant demander à Docker de répartir les conteneurs pour qu’un soit placé à Montréal et l’autre, Toronto.

La fonction Docker Compose (stack) : Docker a finalement amélioré la fonction « Docker Compose », maintenant appelée « Stack Now », qui nous permet de mélanger des conteneurs et des services dans le même système. Nous pouvons maintenant déployer en une seule instruction des conteneurs qui gèrent notre base de données ou envoient des messages à nos configurations de réseaux ou encore nos services. L’équipe Docker a également simplifié le mappage des ports (« Port mapping »), avec des messages plus clairs comme Targeted, Published et plus encore. Ces deux fonctionnalités vont grandement faciliter le développement avec Docker.

Image Frederick Sauvanet

Frederick Sauvanet

Frederick Sauvanet est un Architecte Java chez Askida // Frederick Sauvanet is a Java Architect at Askida