Docker en production, les bonnes pratiques

Docker est largement utilisé en développement mais bien souvent les choses se compliquent en production :

• D’abord, l’application ne fonctionne pas toujours correctement en prod ;
• Les performances ne suivent pas ;
  
• Ensuite, on s’aperçoit que l’on a oublié de prendre en compte un certain nombre d’éléments indispensables en production : monitoring, scalabilité ou contraintes réseaux.

La facilité est alors de dire : Docker fonctionne bien en Dev mais n’est pas un outil adapté à la production. Bien au contraire, Docker en production doit permettre de faciliter et sécuriser les déploiements tout en rendant votre application scalable.

Mais pour cela, il faut bien fonctionner en mode DevOps et respecter un certain nombre de bonnes pratiques. C’est en tant que telle une compétence ou expertise Docker en production qu’il faut développer.

Enfin quand votre production atteint une certaine complexité, et que le nombre de conteneurs que vous gérez se compte en dizaines, il faut envisager de passer sur un orchestrateur de conteneurs.

Avec Docker, donnez davantage d’autonomie aux développeurs

L’un des atouts du conteneur est de donner davantage d’autonomie au développeur.

Ce dernier doit pouvoir travailler sur son application sans se soucier de la configuration de la machine sur laquelle il travaille : il doit pouvoir développer sur son poste de travail et pousser son conteneur sur un serveur de test, puis pré-production, et jusqu’en production sans rencontrer de difficultés.

Le développeur doit aussi pouvoir modifier son docker et en gérer les versions sans se préoccuper des conséquences pour la production.

En résumé, un des bénéfices du conteneur c’est qu’il doit pouvoir se déployer n’importe où en toute sécurité.

Petit lexique de Docker

• Docker Image 

C’est l’élément de base d’un docker, on utilise une Docker image à deux stades :

Au départ, on va chercher une image de base standard pour l’applicatif choisi (Nginx, Php, Redis), le plus souvent dans un repository public, on complète ensuite cette image standard des éléments de configuration de votre application, vous pouvez ensuite enregistrer la nouvelle image dans un repository public, ou privé,

• Docker file

C’est le fichier texte qui décrit la configuration de votre docker, en général , on part d’une image standard et on ajoute les éléments propres à la configuration de l’application que l’on veut déployer ; une fois le Dockerfile finalisé, on « build » le conteneur.

• Docker Compose 

Le docker compose est un fichier de configuration de l’ensemble des Dockers que vous souhaitez déployer pour votre application, il sert à les déployer et à gérer les liens entre les conteneurs ainsi que les volumes de data, Docker Compose est incompatible avec un orchestrateur ou vice et versa. Il faut choisir entre l’un ou l’autre mode de gestion des conteneurs.

• Orchestrateur de conteneurs

On l’expliquera plus en détail plus bas, mais l’orchestrateur est un peu au conteneur ce que vSphere/vCenter est à VMware pour des VM. C’est le logiciel de gestion de l’ensemble des conteneurs sur un pool de ressources serveurs,avec davantage de fonctionnalités que vSphere/vCenter. C’est en quelque sorte un PaaS pour les conteneurs.

Respecter le mode Devops !

Pour atteindre ce résultat, le pré-requis de base est de fonctionner en mode DevOps : donner davantage d’autonomie aux développeurs ne veut pas dire qu’ils peuvent faire ce qu’ils veulent sans se coordonner avec les Ops.

• Les conteneurs doivent être co-construits par les Dev et les Ops :
  • La configuration de base de données devra bien être validée et optimisée par les Ops, une erreur fréquente est que les Dev déploient une configuration par défaut de la BDD et que les paramètres ne soient pas adaptés à la situation de production.
  • La gestion des espaces partagés de données (fichier ou BDDs) doit être bien conçue, en production, à ce stade on va devoir en effet repasser sur le Docker Compose pour modifier les déclarations des volumes.
  • Les Ops doivent valider que les conteneurs embarquent bien tous les éléments de configuration qui leur permettront de se déployer sur un serveur standard de production.
  • La sécurité des accès doit être intégrée afin de restreindre ceux-ci au strict nécessaire en production.
  • L’intégration du load-balancing doit être bien prise en compte, les conteneurs doivent tendre au maximum vers du stateless.
• L’architecture logicielle doit être conçue et validée avec les Ops pour s’assurer que celle-ci :
  • Sera bien adaptée aux conditions de production (volumétrie, temps de réponse, disponibilité) ;
  • Pourra être déployée simplement sur plusieurs serveurs ;
  • Et sera bien scalable pour accompagner une montée en charge.
• Les Ops doivent se former pour maîtriser les conteneurs afin de les maîtriser en production. Ils doivent :
  • Comprendre un Dockerfile et être en mesure d’identifier comme d’analyser les modifications apportées entre deux versions d’un conteneur ;
  • Maîtriser le Docker Compose et le valider ;
  • Comprendre les interconnexions entre conteneurs.
• Le process de déploiement doit être défini et mis à jour afin de minimiser les interventions manuelles et les risques d’erreur humaine, et intégrer la méthode de retour arrière, pour cela il est important de gérer son repository d’images Docker.
• Le monitoring doit être pris en compte dans cette phase de conception, et superviser les applicatifs ainsi que les serveurs sur lesquels ils sont déployés, on ne monitore pas un conteneur en tant que tel, mais bien son applicatif.
• Le mode de sauvegarde/restauration doit aussi être prévu et testé.

C’est ce mode de co-construction en DevOps qui doit s’imposer dès le début de la démarche et assurer un fonctionnement homogène de l’application tout au long de la chaîne de déploiement.

A partir de quand utiliser un orchestrateur

Tant que l’on reste dans la limite de 20 ou 30 conteneurs, l’utilisation d’un orchestrateur ne s’impose pas. En dessous de cette limite, on déploiera le plus souvent son application sur un nombre limité de serveurs virtuels qui auront des rôles précis dans une architecture bien définie. La gestion du versionning restera assez simple, et les déploiements se feront simplement par les développeurs dans un mode opératoire validé par les Ops. On travaillera le plus souvent en Docker Compose.

Mais dès lors que l’on dépasse un volume de plusieurs dizaines de conteneurs, on va vouloir optimiser l’usage de son infrastructure et sécuriser les déploiements comme le réseau. C’est là qu’un Orchestrateur comme Kubernetes, Mesos , Swarm ou Rancher va devenir intéressant en :

• Assurant la scabilité de l’infra sur un pool de ressources gérées globalement, (stop, start, auto-scaling…) ;
• Facilitant et automatisant les déploiements, mais aussi les roll-back, en suivant les changement de configuration ;
• Gérant les liens entre conteneurs et les interconnexions réseaux.

Il faut choisir son moment pour passer sur un orchestrateur car cela implique une montée en compétences soutenue sur une nouvelle couche logicielle qui doit être parfaitement maîtrisée, et un niveau supérieur de complexité. Rappelons qu’un orchestrateur viendra remplacer Docker Compose.

Les déploiements à grande échelle, plusieurs centaines de conteneurs, voire des milliers comme pour Blablacar, s’appuient tous sur un orchestrateur.

Expertise Docker en production

Les soucis rencontrés avec Docker en production tiennent avant tout à l’insuffisance de la démarche DevOps : les Dev déploient en prod leurs conteneurs sans embarquer les contraintes de la production qui leur sont peu familières, les Ops ne sont pas à l’aise avec les conteneurs et les rejettent en rendant la techno responsable des difficultés.

Au contraire, dès lors que Dev et Ops se coordonnent bien dans la construction des modèles de conteneurs et sur l’architecture logicielle, Docker en production permet d’atteindre de vrais gains en rapidité, agilité et fiabilité de déploiement.