Docker est devenu un incontournable dans le paysage du développement applicatif, testé tant par les devs que par les ops. Avec un écosystème en plein croissance et des outils qui gagnent en maturité, se pose la question du déploiement de Docker en production et sur le Cloud. Pour sa troisième édition, le 6 Octobre 2017, TIAD Camp a réuni dev et ops pour débattre de tous les aspects de Docker en production : bonnes pratiques, sécurité, orchestrateurs, monitoring…

Les images Docker

Quels sont les premiers challenges rencontrés avec Docker en production ? Laurent Bernaille, qui sera speaker à la prochaine Docker Con a lancé la journée en partageant son retour d’expérience issu de deux années de projets clients. S’il est tout à fait possible de passer Docker en production, certains sujets complexes méritent néanmoins d’être pris en considération. À commencer par les images : ce n’est pas parce qu’elles fonctionnent en développement qu’il est aisé de passer en production. Les images sont le premier point de confrontation des équipes ops avec Docker, elles sont fournies par les équipes de développement. Les images doivent être légères (Laurent Bernaille cite l’exemple de micro services avec des images d’1,5 giga !).

On retiendra comme bonnes pratiques que les images doivent contenir le serveur et l’application, mais pas la configuration de l’application ni les outils de build comme Maven. Autre point essentiel, bien gérer les metadata si on ne veut pas avoir de nombreuses images en production sans aucune idée de ce qu’elles contiennent. Laurent Bernaille conseille d’utiliser les labels pour préciser les versions, et d’inclure le Dockerfile dans l’image. Mono process ou multi process, image plate ou multi couches… il faut aussi se poser ces questions. En termes de distribution, Laurent Bernaille recommande des distributions standard comme Ubuntu ou Debian pour commencer. Globalement, le sujet des images n’est pas à négliger et doit être pris en considération en incluant les équipes ops dans la réflexion.

Ensuite, il faut gérer le cycle de vie des images. Il est conseillé de faire la construction des images dans la chaîne d’intégration continue, et surtout d’utiliser le versioning : ne jamais nommer ses images « latest », il est ensuite très difficile de mettre à jour ! Il est essentiel de penser dès le début à gérer le nettoyage des images, manuellement ou avec un outil, pour ne pas accumuler les images et se trouver avec un filesystem full. Côté sécurité, il faut également veiller à scanner ses images grâce aux solutions fournies par Docker Enterprise ou CoreOS.

Starting the #bootcamp on #Docker Swarm.#TIADCamp pic.twitter.com/isKXdWgFwi

— Automation Day (@TIADParis) 6 octobre 2017

Quelle version de Docker ?

En production, il faut également considérer le choix de la version de Docker : la plus récente ? Celle supportée par la distribution ? Concernant l’OS de base, on pourra se limiter aux distributions standards, ou bien utiliser des distributions spécialisées pour les conteneurs comme LinuxKit, Moby Linux, CoreOS ou RancherOS. L’usage de ces distributions est une tendance forte sur le marché, mais cela implique de vrais changements en termes opérationnels. Le choix de l’OS déterminera aussi quel système de stockage utiliser.

Historiquement, les conteneurs Docker sont stateless, mais aujourd’hui on peut être amené à faire tourner des conteneurs avec des composants portant des données. Plusieurs stratégies sont possibles, la plus simple étant d’utiliser une solution comme NFS, mais dans le cas de bases de données avec beaucoup d’i/o cela peut dégrader les performances. Les orchestrateurs proposent aussi des plugin de stockage, mais ce sont des solutions encore très jeunes. Au final, il est encore un peu compliqué de faire tourner des conteneurs avec des données persistantes. Dans le cas d’infrastructures sur le Cloud, il est alors préférable d’utiliser les services managés pour les bases de données.

Les orchestrateurs

Pour déployer des conteneurs en production, on se posera aussi la question d’utiliser ou non un orchestrateur. Kubernetes, Swarm ou ECS apportent ainsi de nombreuses fonctionnalités et avantages mais également un inveau d’abstraction supplémentaire, ce qui peut rendre plus complexe les diagnostics. Laurent Bernaille cite l’exemple d’une application ralentie par un orchestrateur redémarrant des conteneurs des centaines de fois par jour. Chaque orchestrateur apporte ainsi de nombreux nouveaux concepts, et un agent pour les piloter. Les agents, Kubelet, Kube Proxy ou l’agent ECS mènent de nombreuses actions : par exemple l’agent ECS fait du nettoyage d’image par défaut, ce qui peut être gênant si on ne le sait pas. Pour Laurent Bernaille, il n’est pas nécessairement indispensable d’utiliser un orchestrateur. On peut aussi utiliser des outils de déploiement classiques comme Ansible ou Puppet pour assigner les conteneurs à des machines. Cette alternative n’offre pas toutes les fonctionnalités des orchestrateurs, mais dispense de la complexité qui leur est associée. Pour commencer Docker en production, Laurent Bernaille recommande de commencer sans orchestrateur pour bien comprendre le fonctionnement de Docker. Une fois l’expérience et les connaissances acquises, alors il est possible de passer aux orchestrateurs.

Communication entre conteneurs

Autre sujet à aborder, la communication entre les conteneurs : comment communiquer avec un service porté par plusieurs conteneurs, à quelle IP s’adresser ? Là encore il existe plusieurs solutions, apportées par Kubernetes, Swarm ou des outils externes comme Traefik, Istio/Envoy ou Consul, et toutes adressent la question de façon très différente. Globalement les problématique de communication et de réseau IP entre les conteneurs sont un sujet encore difficile (voir également le sujet Docker Overlay Networks), et s’il existe des solutions elles manquent encore de maturité. Quand c’est possible, il est conseillé d’attendre que ces solutions mûrissent et se standardisent.

Mise à jour de l’application

Laurent Bernaille aborde ensuite la question de la mise à jour de l’application. Tous les orchestrateurs proposent une solution de rolling update, mais il faut pouvoir garantir l’état de la nouvelle version de l’application. En effet, si ce n’est pas le cas, la nouvelle version de l’application ne fonctionne pas, et l’ancienne version n’est plus disponible ! Dans l’écosystème du Cloud public, la bonne pratique est de pratiquer le déploiement blue-green : on déploie la version blue, puis la nouvelle version (green), et si tous les tests fonctionnent on fait une bascule de DNS vers green. Malheureusement, il n’existe aujourd’hui pas de solution native pour utiliser cette méthode dans le monde des conteneurs.

Monitoring

Dernier sujet abordé, le monitoring. Evidemment il faut surveiller l’hôte, les conteneurs mais aussi les applications dans les conteneurs, ce qui est difficile dans le cas où on a un orchestrateur et des conteneurs qui bougent de machine en machine. Le fait d’être dans un environnement dynamique rend le monitoring complexe et l’agent de monitoring doit pouvoir s’adapter. En conclusion de cette intervention, Laurent Bernaille rappelle que si Docker en production fonctionne bien, il est essentiel de se lancer progressivement, et dans un premier temps de ne pas multiplier les solutions techniques « à la mode ». Il est préférable de commencer en se faisant la main sur les couches basses de Docker, et de comprendre son fonctionnement en termes d’isolation, de sécurité et de partage des ressources. Le talk suivant, de Quentin Adam (lire l’interview « Mythes et réalités de Docker« ), porte d’ailleurs sur ce sujet, en détaillant l’évolution des containers et leur histoire qui puise ses origines sur des principes fondateurs des systèmes dérivés d’UNIX (chroot, jails FreeBSD…), ainsi que leurs différences fondamentales avec la virtualisation logicielle et matérielle.

La question du monitoring a ensuite été approfondie lors du talk de Charly Fontaine, de Datadog. Charly Fontaine rappelle qu’aujourd’hui collecter de la donnée est relativement peu cher, mais il peut être coûteux de s’en priver ! Docker étant un sujet à la mode, en très forte croissance, et partagé par les équipes ops et dev, il est important de partager les mêmes métriques et mesures au sein des équipes pour éviter les malentendus. Le cycle de vie des conteneurs change la donne : en moyenne, la durée de vie d’un conteneur est cinq fois moins importante que celle d’une VM. Tout va très vite dans le monde des conteneurs, d’où l’importance de monitorer !

Cas d’usage : pipeline CI/CD avec Docker

Paul Bonnaud et Maxime Visonneau (Trainline) ont ensuite présenté la migration de leurs pipelines de build. Au début de cette aventure, une seule machine, administrée manuellement, servait à faire les builds de tous les projets. Docker a été choisi pour que les équipes projets puissent builder leurs applications facilement et isoler les dépendances. C’est l’exemple d’un très bon cas d’usage pour se lancer dans Docker : il est maintenant plus facile de  suivre l’évolution des projets et d’identifier les problématiques opérationnelles avant d’arriver en production. Les environnements sont déclarés de façon fiable et reproductible, chaque projet est isolé et rationnalisé, et l’infrastucture est scalable. Pour plus de détails, voir le sujet « Retour d’expérience de la migration Docker de Trainline« .

Stratégie, planning et gouvernance

Quels choix doit-on faire pour délivrer du conteneur à large échelle ? Quelles différences avec le management de VM ? Dans un talk issu du retour d’expérience de mises en production de ses clients, Stéphane Woillez (Docker) a abordé tous les points touchant à la stratégie de déploiement d’entreprise : choix d’infrastructure, gouvernance des images, sécurité de la plateforme, opération, migration des applications. Quand on parle de Docker en production, beaucoup se demandent aujourd’hui par où commencer. Stéphane Woillez retient deux approches, l’approche production IT qui consiste à construire la plateforme idéale et complète, dont on ouvre ensuite l’usage aux applications. Ou l’approche applicative, qui est de migrer des applications petit à petit puis de mutualiser. Stéphane Woillez recommande tirer parti des deux approches afin de mieux identifier les contraintes opérationnelles. Par ailleurs, les conteneurs catalysant la démarche DevOps, cela suppose un changement de culture et d’organisation. De fait, une initiative commune portée par les dev et par les ops est une bonne façon de démarrer.

Orchestrer Docker en production

Pour le dernier talk de la journée, Tarik Ihadjadene et Bastien Menesson ont choisir d’approfondir la question des orchestrateurs. Pour cadrer le sujet, le talk commence par un petit rappel des bases et notamment des concepts abordés durant les bootcamp de la journée : construire une image, pousser l’image, démarrer l’image et déployer avec Swarm ou ECS. On rappelle également les principes et avantages des infrastructures immuables, qui permettent notamment de simplifier les opérations, rendre les applications plus scalables et de pouvoir restaurer ou reproduire très facilement l’infrastructure.

Quel est le rôle des orchestrateurs ? Les orchestrateurs permettent de planifier le placement des conteneurs (l’orchestrateur connaît l’ensemble des machines faisant partie du cluster et choisit la plus apte), de s’assurer du bon fonctionnement des conteneurs (sealf healing, scaling), de gérer les mises à jour et le remplacement des conteneurs et de déployer sans downtime avec le rolling update. Durant la suite du talk, Tarik et Bastien ont ensuite comparé les principaux orchestrateurs du marché, Kubernetes, AWS ECS et Swarm au travers de différentes fonctionnalités : rolling update, autoscaling, service discovery, health check, haute disponibilité… pour plus de détails, nous vous recommandons de consulter les slides des talks (lien ci-dessous) ou les vidéos qui seront publiées prochainement. N’hésitez pas à suivre le compte Twitter du TIAD pour suivre notre actualité !

Retrouvez l’ensemble des présentations du TIADCamp Docker sur Slideshare