Docker est sans aucun doute l’une des technologies de développement les plus percutantes de la dernière décennie. Les conteneurs ont fourni une solution pour isoler les applications, les mettre à l’échelle sur des machines physiques et faire abstraction des différences entre les environnements.
De nombreuses organisations qui adoptent Docker ou une technologie de conteneurisation adjacente trouvent que cela augmente l’efficacité et accélère le processus de développement. Cependant, Docker n’améliore pas chaque système comme par magie. Dans cet article, nous examinerons certains scénarios où le déplacement vers des conteneurs pourrait être plus un obstacle qu’une aide.
Lorsque les performances sont essentielles
Docker n’est peut-être pas le meilleur choix pour les systèmes où les performances sont essentielles. La nature de la conteneurisation crée des frais généraux qui n’existent pas lorsque le logiciel est installé directement sur une machine hôte.
Bien sûr, Docker peut également contribuer à améliorer les performances, notamment en facilitant la mise à l’échelle horizontale de votre application. Il est donc important que ce jugement soit porté dans le contexte des exigences de votre système et de ses interactions avec le système d’exploitation sous-jacent.
Docker utilisera beaucoup moins de ressources qu’une machine virtuelle, mais c’est encore un autre processus qui doit s’exécuter sur l’hôte. Dans les environnements à ressources limitées, vous pouvez constater que les processus de conteneur ou le démon Docker lui-même sont ciblés par le tueur de mémoire insuffisante du système d’exploitation, provoquant des échecs en cascade lorsque des éléments de votre application sont expulsés.
Beaucoup de données persistantes
Les conteneurs Docker sont conçus pour être éphémères par défaut. Les données persistantes sont prises en charge par l’utilisation de volumes. Ceux-ci sont montés dans des conteneurs pour stocker des données ailleurs sur l’hôte.
Les performances du stockage de volume varient en fonction du pilote sélectionné et de l’environnement hôte. Même dans le meilleur des cas, il y a une surcharge supplémentaire par rapport à l’interaction directe avec le système de fichiers de l’hôte. Cela peut être important dans les cas où il y a un volume élevé de lectures ou d’écritures de fichiers.
Les données stockées dans des volumes peuvent être difficiles à gérer et à maintenir. Vous devez utiliser les commandes Docker pour interagir avec vos volumes. Les inspections de données sont mieux effectuées en plaçant un shell sur le conteneur et en énumérant le contenu du volume de l’intérieur.
Docker vous oblige à penser au stockage et à choisir votre propre stratégie de persistance. Il s’agit d’un changement par rapport à l’installation de packages de machines virtuelles et de systèmes d’exploitation où vous pouvez stocker des données en toute sécurité dans n’importe quel répertoire sans vous soucier de la façon dont vous les gérerez plus tard.
Docker est le plus logique lorsque vous créez des services de longue durée qui ont des dépendances que vous ne souhaitez pas installer dans chaque environnement. Un exemple courant pourrait être une application Web PHP s’exécutant derrière un serveur Web NGINX : il existe plusieurs composants, y compris un serveur d’arrière-plan que vous souhaitez démarrer à partir d’une seule commande.
Docker ajoute moins de valeur lorsque vous créez des outils à usage local tels que des programmes de bureau et des applications mobiles. Ce type de développement logiciel a tendance à produire des artefacts qui ne peuvent pas être exécutés dans des conteneurs ou qui ne seront généralement pas conteneurisés par les utilisateurs.
Vous pouvez toujours bénéficier de Docker dans ces situations en l’utilisant pour empaqueter le chaîne d’outils, plutôt que la sortie finale. Par exemple, vous pouvez créer une image Docker qui inclut Java et les outils de la plate-forme Android pour éviter aux nouveaux développeurs d’avoir à ajouter ces packages à leurs machines.
Cependant, cela a tendance à ajouter plus de complexité dans les disciplines qui sont pilotées par des IDE comme Android Studio, Visual Studio et Xcode. Les développeurs ont l’habitude d’installer l’IDE et de le laisser configurer leur environnement. Par conséquent, Docker a tendance à ajouter moins de valeur aux flux de travail de langage compilé que pour les langages interprétés où la version correcte de l’interpréteur peut être intégrée dans une image.
La sécurité est la priorité absolue
Docker pouvez augmentez la sécurité de votre pile, mais il faut du travail pour durcir correctement votre installation. Une erreur trop souvent commise consiste à supposer que Docker est sécurisé et prêt à l’emploi. Pour le dire franchement : ce n’est pas le cas.
Nous ne disons pas que la simple présence de Docker est un risque pour la sécurité, car ce n’est pas le cas non plus. Néanmoins, il est important de reconnaître que Docker comporte des risques uniques et qu’ils varient en fonction de votre utilisation de la technologie. Comme tout autre composant logiciel, vous devez prendre le temps de comprendre ces risques, comment ils affectent votre conformité aux normes de sécurité qui vous intéressent et ce que vous devez faire pour y faire face.
Il est trop facile d’entendre le discours des « applications isolées » et de supposer que cela s’étend à la sécurité au niveau du bac à sable. En réalité, une installation Docker standard exécute des processus de conteneur comme root et une rupture de conteneur pourrait compromettre votre hôte.
La sécurité Docker est un sujet à multiples facettes qui vous oblige à prendre en compte l’environnement hôte, le démon Docker et la manière dont vous créez et gérez vos images. Les développeurs ont également un rôle à jouer en minimisant les opérations risquées dans le code qui s’exécute dans des conteneurs.
Tout cela signifie que Docker n’est peut-être pas une excellente option pour les paramètres critiques pour la sécurité. Bien que Docker puisse fournir des protections de sécurité, vous devez avoir des membres d’équipe qualifiés et un état d’esprit soucieux de la sécurité pour vous assurer que vous traitez les nouveaux problèmes qu’il introduit.
Votre base de code est un monolithe
Vous avez probablement lu que les conteneurs vont de pair avec les microservices. Cette mentalité décrit le processus de découpage de votre système en composants indépendants qui peuvent être facilement conteneurisés. Une fois que vous avez divisé vos services, ils peuvent être mis à l’échelle individuellement et vous pouvez remplacer des pièces sans affecter les autres.
Lorsque votre application est un monolithe, vous ne pourrez pas voir ces avantages. Mais conteneuriser un système monolithique tel quel peut être une mauvaise approche. Une grande application héritée a tendance à acquérir des tonnes de dépendances et un long processus de construction qui peut rapidement gonfler votre image Docker. Cela entraîne des temps d’attente frustrants lors de la création d’images ainsi que des coûts de stockage et de bande passante excessifs.
Comme d’habitude, il y a cependant deux faces à cette médaille : la conteneurisation d’un monolithe est souvent la première étape vers la modernisation de votre pile et sa décomposition en services plus petits. C’est le point auquel vous séparez la base de code de l’environnement auquel elle est liée.
Pourtant, si vous conteneurisez sans avoir l’intention de poursuivre la refactorisation à l’avenir, il serait peut-être préférable de reconsidérer vos motivations. Les images de conteneur volumineuses qui incluent plusieurs composants fonctionnels sont un bon indicateur que vous ne respectez pas les meilleures pratiques en matière de conteneur. Au fil du temps, vous constaterez peut-être que l’approche vous retient et devient une partie du problème.
Vous essayez de réduire la complexité
Vous essayez de réduire la complexité ? Vous pensez que la conteneurisation apportera une nouvelle simplicité au développement et au déploiement ? Encore une fois, c’est un moment « ça dépend », mais nous vous déconseillons de sauter dans le train Docker avec la simplicité comme principale motivation.
Docker nécessite un changement de mentalité et une familiarisation avec de nouveaux outils et concepts. Vos développeurs seront-ils à l’aise avec cela et quel impact cela aura-t-il sur vos processus d’embauche ? Ce sont des questions qui peuvent être facilement négligées mais qui doivent être prises en compte dès le début.
Bien que Docker supprime de nombreuses formes de complexité, il a tendance à refaire surface sous différentes formes. Vous devrez écrire, documenter, maintenir et créer vos images Docker, soit localement sur des machines de développement, soit dans le cadre d’un pipeline CI. Les développeurs devront apprendre la CLI Docker, les principes fondamentaux de ce que sont les conteneurs et les problèmes potentiels à prendre en compte lors de la préparation des applications pour la conteneurisation.
Si vous envisagez d’exécuter des conteneurs en production, vous aurez également d’autres considérations à prendre en compte. Comment le trafic réseau va-t-il être acheminé vers les conteneurs ? Comment le système réagira-t-il si un conteneur s’arrête de manière inattendue ?
Les partisans de la mentalité « Docker est simple » ont tendance à se concentrer étroitement sur la facilité avec laquelle vous pouvez démarrer naïvement des instances d’images que vous avez déjà. Il est vrai que si vous voulez une nouvelle base de données MySQL sur votre ordinateur portable, c’est juste un docker run -d mysql:8 un moyen. Pourtant, il reste encore beaucoup à apprendre si vous souhaitez utiliser Docker avec succès pour créer et exécuter votre propre logiciel tout en respectant les meilleures pratiques et en évitant les pièges courants.
Vous ne savez pas pourquoi vous conteneurisez
Les conteneurs sont partout ; vous ne pouvez pas lire plus de quelques articles sur le développement de logiciels sans les rencontrer, et les partisans sont vocaux et enthousiastes. Cet attrait populaire peut créer une pression pour adopter Docker comme un outil «moderne» que d’autres ont trouvé utile.
Ce n’est pas une bonne raison de conteneuriser. Vous avez besoin d’un objectif plus concret, tel que « les développeurs doivent être capables de reproduire précisément la production localement » ou « nous devons pouvoir mettre à l’échelle horizontalement des répliques de nos services ». Si vous ne ressentez pas un cas d’utilisation précis pour Docker et que vous êtes satisfait de votre flux de travail actuel, la meilleure option pourrait être de vous en tenir à ce qui fonctionne. Un choix ennuyeux, cela peut sembler, mais Docker n’est pas une force de transformation impeccable et une adoption réussie n’est pas garantie.
L’ajout de Docker à vos processus peut nécessiter un investissement initial important. Vous devrez peut-être refactoriser votre base de code, écrire et tester vos Dockerfiles, donner aux développeurs le temps d’apprendre et effectuer une évaluation de sécurité. Lorsque les avantages qui en résultent ne sont pas clairs – et que vous n’avez pas identifié à quoi ressemblera le succès – l’effort peut être un fardeau qui nuit au travail productif sur votre système.
Conclusion
Docker est une technologie à juste titre populaire : pour de nombreuses équipes et développeurs, elle offre un équilibre idéal entre facilité d’utilisation, flexibilité et performances qui lui permet de simplifier les processus de développement réels. Docker n’est pas magique cependant : il y a des cas où cela ne peut pas fonctionner et beaucoup d’autres où cela ne fonctionnera pas, selon vos technologies, processus et état d’esprit existants.
Même si Docker ne convient pas parfaitement à vos projets aujourd’hui, vous pourrez peut-être encore tirer certains avantages en l’adoptant progressivement. Identifiez les défis de vos processus, puis évaluez si Docker peut vous aider dans ces domaines spécifiques. Par exemple, si les développeurs passent trop de temps à créer des instances de préproduction de votre API, dockeriser cette partie de votre pile pourrait résoudre le goulot d’étranglement même si vous n’êtes pas en mesure d’exécuter des conteneurs en production.
L’intérêt des conteneurs est de pouvoir empaqueter des parties de votre application en tant que composants isolés qui fonctionnent indépendamment. Cela ne signifie pas automatiquement que vous devez emballer tous composant en tant que conteneur. Restez objectif, recherchez des opportunités de conteneuriser là où cela a du sens, mais soyez prêt à reconnaître les situations où Docker n’ajoute pas de valeur à votre flux de travail existant.