Pourquoi choisir un hébergement dockerisé ?

Les avantages d’un hébergement dockerisé

Après une première période ou Docker était considéré comme incompatible avec une production (la solution a mis du temps à se stabiliser), elle est rapidement devenue à la mode. Ce serait devenu un incontournable des équipes digitales. Est-ce le cas ?

La dockerisation peut être définie comme une forme de visualisation pour les applications. Elle repose sur la création et l’exécution de conteneurs. Est-ce vraiment si intéressant ? En quoi impliquent-elle de nombreux changements dans le travail de développement web ? Comment apporte-t-elle de la souplesse aux infrastructures ? Quels nouveaux usages sont apparus ? Favorise-t-elle le déploiement continu ?

Les prémisses des hébergements dockerisés

Virtualisation et data center

Le concept de virtualisation apparaît dès les années 60. Il s’agit alors pour plusieurs personnes d’utiliser une machine physique simultanément. Puis, dès 1964, IBM présente le CP-4. Le premier système d’exploitation à machine virtuelle et mémoire virtuelle est né.

Durant de nombreuses années, le partage d’une machine physique perdure. L’OS est le même pour tous les utilisateurs avec des ressources physiques partagées.

Dans les années 90, l’hébergement consiste à ranger des machines physiques dans des locaux d’abord peu propices à cet usage, puis ensuite à se professionnaliser. Les entreprises font massivement appel aux data centers. Le nombre de serveurs est proportionnel aux besoins, ce qui nécessite de nombreuses ressources. De plus, les systèmes d’exploitation sont souvent spécifiques et les équipes de développeurs ne bénéficient pas d’un environnement de travail équivalent à celui qui héberge l’application finale.

Un changement dans les habitudes d’hébergement

En 1998, la création de VMware instaure le partage d’OS sur une même machine grâce à VMware Workstation. Les ressources physiques sont partagées. L’OS n’a pas de notion de ce qui est existant physiquement car il n’a accès qu’à ce qui lui est attribué.

Des changements apparaissent dans les habitudes d’hébergement :

• Il est plus facile de gérer l’affectation des ressources (CPU, mémoire, disque) par rapport aux besoins ;
• Le nombre de serveurs et la taille des baies diminuent.

Quelques heures suffisent désormais pour disposer d’un nouvel environnement. Ils ne sont par contre toujours pas équivalents à ceux qu’utilisent les développeurs pour travailler. En effet, les mises à jour systèmes se font sur des rythmes différents par exemple.

L’avènement de AWS début 2 000 va commencer à changer les habitudes de travail des équipes digitales. L’interface de configuration de l’infrastructure n’est plus réservée qu’à des équipes réseau..

L’avènement de Docker et Kubernetes

En 2013, le conteneur apparaît et change la manière d’appréhender l’hébergement. Cette révolution se poursuit avec Docker et Kubernetes.

Le conteneur

Un conteneur n’est pas un OS complet. C’est ce qui le différencie de ce qu’on a l’habitude d’utiliser jusqu’ici. Il est capable d’utiliser directement de nombreux éléments du système qui l’héberge. Un conteneur est une description de l’environnement nécessaire pour exécuter l’application qui y est hébergée. Ce changement est majeur, l’équipe de développement peut décrire précisément les éléments qui sont nécessaires, les mêmes que ceux qu’elle a utilisés pour développer et tester l’application.
Il ne reste plus qu’à l’exécuter sur une machine hôte.

Docker : construire et exécuter des conteneurs

Docker est un logiciel qui permet d’exécuter les conteneurs. C’est lui qui permet au conteneur d’utiliser des ressources de la machine qui l’héberge, qui peut être une machine sous OS Windows, linux, ou même MacOS. On s’affranchit ainsi des contraintes des machines hôtes.
Mais il ne s’arrête pas à cette fonctionnalité puisqu’il aussi (entre autres) de :

• Construire un conteneur à partir d’une image (un fichier texte qui décrit le conteneur) ;
• Gérer un réseau entre plusieurs conteneurs ;
  Utiliser des d’annuaires d’images ;
• Regrouper plusieurs conteneurs pour les faire fonctionner comme une seule application.

Kubernetes : organiser et optimiser les conteneurs

Créé en 2014, ce projet à l’initiative de Google améliore l’organisation de multiples conteneurs. C’est un aspect qui était moins bien couvert par Docker. Mais Kubernetes ne se contente pas d’optimiser l’allocation des ressources aux ressources disponibles.
En plus de gérer tous les aspects réseaux, Kubernetes :

• Met à disposition un espace de stockage commun ;
• Centralise les logs et le monitoring.

Kubernetes comporte :

• Un pod : une application qui peut être composée de plusieurs conteneurs ;
• Un node : une machine physique ou virtuelle ;
• Le control plane : le binaire Kubernetes qui orchestre tous ces éléments.

Quels changements les hébergements dockerisés apportent-ils ?

Les hébergements dockerisés sont sources de nombreux changements dans la manière de travailler des développeurs.

L’infra as code

Une infrastructure peut être décrite en texte avec un langage comme terraform . Grâce aux fournisseurs d’hébergement, comme AWS, Azure ou GCP, aucune interaction avec l’interface d’administration n’est nécessaire. L’infrastructure évolue comme le code applicatif et peut :

• Être hébergée sur Github, Gitlab ;
• Avoir son gitflow ;
• Être testée ;
• Être intégrée à du déploiement continu.

Une démarche devops

Le devops se définit davantage comme un état d’esprit que comme un intitulé de poste ! Il s’inscrit dans une équipe projet où il rend visible et modifiable par les développeurs ce qui était géré par une équipe réseau et inversement.

La durée de vie limitée des conteneurs

Lors de mises à jour du code, un nouveau conteneur est déployé et le précèdent supprimé. L’auto scaling a un fonctionnement identique. Le développement de l’application doit donc prendre en compte cet aspect limité de son exécution. Elle sera relancée sur une autre instance, mais on doit savoir gérer cette fin de vie qui est récurrente.

Le conteneur doit être parallélisable

L’auto scaling, ou un processus de déploiement fonctionne en multipliant le nombre de conteneurs actifs au même moment. L’application doit être capable de le gérer. Parmi les impacts classiques, on peut citer :

• L’authentification qui doit être conservée quelle que soit l’instance qui prend en charge une demande
• Un fonctionnement qui ne doit pas dépendre de données locales au conteneur, au risque d’être perdues quand le conteneur disparaîtra

La décentralisation des logs

La durée d’un conteneur étant limitée, les logs doivent être conservés ailleurs pour ne pas être perdus. Grâce à une application comme Grafana, Loki ou Datadag (et d’autres) les logs doivent être centralisés. Ils pourront ensuite être utilisés en gardant la connaissance de leur instance d’origine.

Se passer du NFS

Le NFS (Network File system) est une solution pour répondre aux besoins d’un espace de stockage perpétuel et accessible par les conteneurs. Même s’il est présent sur Kubernetes, il révèle certains défauts :
La performance peut être impactée négativement par la virtualisation d’accès au disque physique (tout passe par du réseau) ;
La compatibilité avec des options natives de Kubernetes peut poser des problèmes de stabilité.

Par rapport au dernier point, de son côté, Kubernetes propose l’utilisation de CSI (Container Storage Interface). Ce dernier est compatible avec AWS EFS, Google, Azure, et Kubera.

Se passer de Crontab

Pour prendre en compte la durée de vie limitée d’une instance et l’impossibilité de prédire quand elle sera remplacée par une autre, il faut externaliser la programmation de tâches récurrentes.
Une bonne pratique est d’utiliser un orchestrateur de tâches. C’est cet outil qui aura la liste des tâches et leurs programmations. Dans une vision complètement dockerisée, chaque tâche est lancée avec sa propre instance de l’application. Quand la tâche se termine, l’instance est supprimée.

De nouveaux usages en hébergement dockerisé

Dans une CI (intégration continue), il est possible de :

• Créer un environnement éphémère (pour chaque branche, pour exécuter un test de charge, …)
• Gérer facilement le nombre d’environnements de recette / preprod selon les besoins ;
• Couper tous ces environnements quand on n’en a plus besoin (la nuit par exemple).

La souplesse de l’architecture

Dans ce type d’infrastructure souple, vous pouvez faire cohabiter plusieurs versions de PHP, NodeJS, JAVA sans problème.

Faciliter le rollback

La MEP (mise en production) autorise à lancer une nouvelle machine et à mettre la précédente de côté. Si un problème survient, le processus de rollback consiste à remettre en place la précédente instance. La procédure est simple, mais elle est surtout très sécurisée. Cette précédente instance fonctionnait avant, elle continuera à fonctionner.
Le rollback est ainsi une procédure dont on peut avoir confiance.

Le déploiement continu

Une MEP est sécurisée par :

• Une intégration continue qui automatise des vérifications ;
• Une procédure de déploiement totalement automatisée ;
• Une observabilité globale qui alerte quand des signaux négatifs sont repérés ;
• Un processus de rollback sans douleur ;

Il est alors possible de déployer régulièrement de petits incréments.

Conclusion :

Les hébergements dockerisés modifient en profondeur le travail de développement. Désormais, les conteneurs suppriment les problèmes de compatibilité des serveurs avec les applications. Une démarche devops et des outils comme Docker et Kubernetes, facilitent l’intégration et le déploiement continus. Il faut simplement être vigilant en termes d’auto scaling. Mal configuré et sans suivi, celui-ci peut en effet s’avérer très coûteux.