Infogérance

Containers

Les containers font beaucoup parler d'eux depuis quelques années, notamment deux projets phares de cet écosystème : Docker et Kubernetes. Pourtant, les conteneurs existent depuis plus de 15 ans, et de nombreux acteurs (notamment dans le monde de l'hébergement) les utilisent en production depuis presque aussi longtemps. Que signifie ce nouvel engouement ?

De VServer à Docker

Au début des années 2000, plusieurs solutions permettant de compartimenter un système UNIX voient le jour. Notamment, les jails (pour FreeBSD) et VServer (pour Linux) sont adoptés par un bon nombre d'hébergeurs afin de proposer des offres plus denses, et donc moins chères. En effet, sur une machine physique avec 512 MB de mémoire (une quantité fort honorable à l'époque!) il était tout à fait raisonnable de faire tourner une dizaine de serveurs virtuels ou VPS (Virtual Private Server), pour un prix bien inférieur à dix machines d'entrée de gamme. Chaque serveur virtuel pouvait ainsi disposer de son propre serveur SSH, sa propre installation d'Apache et PHP, avec les versions et configurations désirées par le client ; et son propre compte root— avec un niveau d'isolation raisonnable.

En 2005, la première offre d'hébergement d'Enix s'appuie sur l'hyperviseur Xen, mais nous mettons aussi en œuvre des conteneurs en interne, pour disposer facilement de plateformes de test ou d'environnements éphémères. Nous comptons à l'époque dans nos clients de nombreuses « web agencies » désireuses de combiner les avantages de la virtualisations et ceux des conteneurs, ce qui nous conduit à développer une expertise spécifique.

En 2008, une petite société française appelée dotCloud fait appel à Enix pour héberger des serveurs avec un cahier des charges bien spécifique : des machines virtuelles exécutant un noyau Linux intégrant simultanément les patches OpenVZ et AUFS (en plus des patches spécifiques à Xen). Tous les hébergeurs contactés par dotCloud à l'époque bottent en touche, et proposent des serveurs dédiés à la place. Nous relevons le défi, et c'est le début d'une collaboration fructueuse entre nos équipes. Quelques années plus tard, dotCloud déménage en Californie, et lève des fonds via l'incubateur YCombinator. Pourquoi parler de dotCloud ? Parce qu'en 2013, cette startup change de nom, et s'appelle désormais … Docker.

Ce n'est donc pas une coïncidence si, dès 2013, nous adoptons Docker pour nos développements internes, et accompagnons certains de nos clients dans leur démarche de modernisation numérique via l'adoption des conteneurs dans le cycle de développement de leurs applications.

De Docker à Kubernetes

Docker a fait évoluer la manière dont l'industrie logicielle conçoit, distribue, et exécute les applications serveur. Un an après Docker, en 2014, un autre projet open source apparaît : Kubernetes, créé à l'initiative d'une poignée d'ingénieurs chez Google, mais aujourd'hui aussi développé et supporté par Red Hat, Microsoft, et une pléthore d'acteurs de taille diverse et variée. Docker permet de facilement construire, livrer, et faire tourner des briques logicielles sur n'importe quelle machine moderne. Kubernetes permet d'orchestrer et ordonnancer ces briques logicielles, c'est-à-dire déterminer quel conteneur doit s'exécuter sur quelle machine et assurer la continuité du service en cas d'indisponibilité d'un serveur. Docker et Kubernetes peuvent fonctionner l'un sans l'autre, mais sont souvent (et logiquement) mis en œuvre de concert.

Nos équipes sont capables de vous accompagner notamment dans les missions suivantes :

  • déploiement et opération de Kubernetes on premises, sur vos propres serveurs en datacenter ;
  • déploiement et opération de Kubernetes sur cloud privé OpenStack ;
  • déploiement et opération de Kubernetes en environnement hybride, combinant vos ressources internes et celles d'un cloud public.

Des conteneurs à la démarche DevOps

De nombreuses équipes, surtout celles capables de prendre rapidement en main de nouveaux outils, ont adopté Docker et les conteneurs pour « faire du DevOps ». Chez Enix, nous pensons que les conteneurs sont des outils formidables, mais qu'ils doivent être utilisés à bon escient et dans les bonnes circonstances. « J'ai installé Docker » n'est pas synonyme de « mes applicatifs disposent d'une importante couverture de tests unitaires et fonctionnels, me permettant d'itérer rapidement car mon pipeline d'intégration continue m'avertit des régressions avant qu'elles n'impactent mes clients et mes utilisateurs ».

Si vous souhaitez utiliser les conteneurs pour moderniser votre « usine logicielle », voici la démarche que nous préconisons et dans laquelle nous pouvons travailler ensemble :

  1. Formation d'initiation à un container engine comme Docker, vous permettant de « containeriser » un premier service. Nous vous aidons à identifier un bon candidat pour être ce premier service. Typiquement, il s'agira d'un service ayant des dépendances logicielles et des processus de build complexes, car c'est précisément les scénarios pour lesquels Docker a été conçu, et cela permet donc d'en tirer le plus grand bénéfice.
  2. Adoption d'un outil comme Compose, vous permettant d'uniformiser le processus de développement pour une application complète, c'est-à-dire votre premier service et ses dépendances. À l'issue de cette phase, vos équipes sont capables de faire tourner cette application de manière identique sur n'importe quel poste de travail (macOS, Windows, Linux), réduisant les temps d'on-boarding et les effets de bords liés aux variations entre environnements.
  3. Mise en place d'un pipeline de CI/CD (intégration continue / déploiement continu) permettant l'exécution automatique des tests unitaires accompagnant votre code source, et le déploiement systématique du code dans des environnements de qualification (pré-production). Chaque modification apportée au code source peut ainsi être contrôlée avec un minimum d'effort avant de passer en production.
  4. Configuration d'un cluster régi par un orchestrateur comme Kubernetes, permettant d'étendre le processus de déploiement continu jusqu'à l'étape de production, avec les contraintes afférentes : haute disponibilité, métrologie, sauvegardes, observabilité ...

Chaque phase est indépendante des autres, et améliore intrinsèquement votre efficacité de manière significative. Cela veut dire que vous n'êtes pas obligé de vous engager dans un projet long et coûteux avant de réaliser un hypothétique retour sur investissement. Travaillons ensemble sur une des premières étapes listées ci-dessus, et vous pouvez ensuite choisir à votre rythme, selon les résultats obtenus, d'aller plus loin.