Les conteneurs sont un concept Unix qui permet de regrouper les applications avec toutes leurs dépendances requises dans une seule image facile à exécuter. Cela présente des avantages retentissants pour un flux de travail DevOps, mais vaut-il la peine supplémentaire?

Les conteneurs synchronisent les environnements de développement et de production

Avec les conteneurs, l'idée est qu'ils regroupent tout ce dont vous avez besoin pour exécuter votre code dans une image facilement distribuable. Cela signifie que tout ce qui est nécessaire pour exécuter l'image est de la télécharger et de l'exécuter docker run.

Il est révolu le temps de "cela ne fonctionne pas sur ma machine." Avec les conteneurs – à condition que tout le monde ait installé correctement Docker et sache comment l'utiliser – le conteneur doit fonctionner de façon très proche de la même chose sur votre machine comme il le fait pour tout le monde.

De plus, cela s'applique également à votre environnement de production. Vous pouvez activer quelques fonctionnalités de développement dans les versions de développement, mais pour la plupart, les conteneurs pourront être envoyés tels quels à vos serveurs de production. Vous ne devriez pas rencontrer de nombreux problèmes avec l'hébergement de conteneurs.

Les conteneurs permettent une mise à l'échelle efficace

Étant donné qu'il est si facile d'exécuter un conteneur, il existe de nombreux services qui les exécuteront pour vous. Ils sont généralement appelés outils d'orchestration, des outils qui gèrent l'exécution de plusieurs instances de conteneurs sur de nombreux serveurs.

AWS a son Service de conteneur élastique, qui gère l'exécution de vos conteneurs sur une flotte d'instances EC2, ou sur leur propre Fargate un service. Kubernetes est open source, et de nombreux fournisseurs de cloud fournissent des intégrations en l'utilisant.

Chaque service d'orchestration pourra surveiller l'intégrité de vos instances et en générer de nouvelles lorsque le trafic est important. Cela permet une mise à l'échelle efficace, ce qui peut vous faire économiser beaucoup d'argent sur les coûts d'hébergement (jusqu'à 90% sur AWS avec Auto Scaling et Instances ponctuelles) et signifie que vous n'avez pas à vous soucier trop de la croissance de votre infrastructure.

De plus, les conteneurs ne subissent pas la même dégradation des performances que celle associée à l'exécution de machines virtuelles, car ils n'ont pas à exécuter un système d'exploitation invité pour chaque application. Cela rend l'hébergement de conteneurs moins cher en général et beaucoup plus efficace.

Et tout cela est activé en raison de la nature des conteneurs, sans travail supplémentaire requis. Vous pouvez faire la même chose sur AWS en utilisant des AMI personnalisées, mais elles sont beaucoup plus difficiles à gérer que les conteneurs, et vous ferez de la même manière le même travail.

La version des conteneurs contrôle votre SysAdmin

La conséquence la plus cool des conteneurs est peut-être qu'ils sortent toute la configuration de votre serveur de la tête de votre SysAdmin et git, où il peut être géré et suivi. Étant donné que chaque nouveau package, fichier de configuration, script d'installation et dépendance se trouve dans le dossier de génération du conteneur, il est trivial de le connecter au contrôle de code source.

Les conteneurs s'intègrent particulièrement bien avec le côté Opérations d'un workflow DevOps. Ils vous permettent d'utiliser les mêmes systèmes de gestion de version et de test que vous avez en place pour gérer votre architecture de serveur. Et parce que tout le monde est synchronisé en utilisant le même environnement pour développer, construire et tester, cela devrait se dérouler très facilement.

De plus, Docker fonctionne bien avec les systèmes d'intégration continue. Les builds Docker sont faciles à automatiser, surtout si vous utilisez Azure Pipelines. Pousser une image Docker sur votre flotte de serveurs est aussi simple que de mettre à jour l'image dans le référentiel. Vous pouvez même déployer un nouveau conteneur sur un sous-ensemble de serveurs pour surveiller son état de santé avant de le déployer sur l'ensemble du parc, ce qui ne serait pas anodin à mettre en œuvre sans conteneurs.

L'inconvénient: le mal de tête est réel

Soyons réalistes: les conteneurs sont certainement la solution la plus élégante, mais ils sont beaucoup plus difficiles à configurer et à utiliser, par rapport au simple démarrage d'une nouvelle boîte Linux et à l'installation d'une heure de logiciel. Tout le monde a fait ce dernier, mais le premier prend globalement beaucoup plus de temps. (Cependant, si vous utilisez une tonne de serveurs, Docker ne doit être configuré qu'une seule fois.)

Si votre tâche n'est pas particulièrement compliquée, ou si vous n'avez pas beaucoup de demande, l'implémenter avec des conteneurs peut être exagéré. Il n'y a pas vraiment de raison de conteneuriser nginx et nœud si vous ne l'exécutez que sur une seule instance.

Et bien que les conteneurs facilitent la gestion de toutes les dépendances qui peuvent accompagner l'exécution de votre application, il est également beaucoup plus difficile d'exécuter Docker et de lier des ports chaque fois que vous souhaitez tester votre application, par rapport à seulement npm start ou quelque chose de similaire dans le répertoire de votre projet. Cela peut certainement être atténué avec les scripts de démarrage, mais si vous êtes sur macOS ou Windows, vous exécutez toujours une machine virtuelle entière juste pour charger votre application Web.

En fin de compte, si vous êtes un fan de Docker et de ses concepts, rien ne vous empêche de l'utiliser pour vos projets personnels. Mais les avantages de Docker ne commencent vraiment à l'emporter sur les maux de tête qu'une fois que vous travaillez dans une équipe plus grande. Dans un environnement d'équipe, tout entourant votre application dans vos systèmes de gestion de versions et le flux de travail DevOps permet un flux de production fluide.