Docker est sans aucun doute l’une des technologies de développement les plus marquantes 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 constatent que cela augmente l’efficacité et accélère le processus de développement. Cependant, Docker n’améliore pas tous les systèmes comme par magie. Dans cet article, nous allons examiner certains scénarios dans lesquels le passage aux conteneurs peut être plus un obstacle qu’une aide.
Lorsque les performances sont essentielles
Docker n’est pas forcément le meilleur choix pour les systèmes où les performances sont critiques. La nature de la conteneurisation crée des frais généraux qui n’existent pas lorsqu’un logiciel est installé directement sur une machine hôte.
Bien entendu, 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 fait 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 VM, mais il s’agit toujours d’un autre processus qui doit être exécuté sur l’hôte. Dans les environnements à ressources limitées, il se peut que les processus de conteneurs ou le démon Docker lui-même soient pris pour cible par le tueur hors mémoire du système d’exploitation, provoquant des défaillances en cascade à mesure que 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 les conteneurs pour stocker les données ailleurs sur l’hôte.
Les performances du stockage en volume varient en fonction du pilote sélectionné et de l’environnement de l’hôte. Même dans le meilleur des cas, il y a une surcharge par rapport à une interaction directe avec le système de fichiers de l’hôte. Cela peut être significatif dans les cas où il y a un volume élevé de lectures ou d’écritures de fichiers.
Les données stockées dans les volumes peuvent être difficiles à gérer et à maintenir. Vous devez utiliser des commandes Docker pour interagir avec vos volumes. La meilleure façon d’inspecter les données est d’obtenir un shell dans le conteneur et d’énumérer le contenu du volume de l’intérieur.
Docker vous oblige à réfléchir au stockage et à choisir votre propre stratégie de persistance. Il s’agit d’une différence par rapport aux VM et à l’installation de paquets d’OS, où vous pouvez stocker des données en toute sécurité dans n’importe quel répertoire sans vous soucier de la manière dont vous les gérerez par la suite.
Développement d’outils et d’applications locaux
Docker prend tout son sens lorsque vous créez des services à longue durée de vie qui ont des dépendances que vous ne voulez pas installer dans chaque environnement. Un exemple courant est celui d’une application web PHP fonctionnant derrière un serveur web NGINX : il existe plusieurs composants, dont un serveur d’arrière-plan, que vous souhaitez démarrer à partir d’une seule commande.
Docker apporte moins de valeur ajoutée lorsque vous créez des outils destinés à un usage local, comme des programmes de bureau ou des applications mobiles. Ce type de développement logiciel tend à produire des artefacts qui ne peuvent pas être exécutés dans des conteneurs ou qui ne seront pas communément conteneurisés par les utilisateurs.
Dans ces situations, vous pouvez tout de même tirer profit de Docker en l’utilisant pour empaqueter la chaîne d’outils, plutôt que le résultat final. 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 paquets à leur machine.
Cependant, cela a tendance à ajouter plus de complexité dans les disciplines qui sont dirigé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. Docker a donc tendance à apporter moins de valeur ajoutée aux flux de travail des langages compilés qu’à ceux des langages interprétés, pour lesquels la version correcte de l’interpréteur peut être intégrée à une image.
La sécurité est une priorité absolue
Docker peut accroître la sécurité de votre pile, mais il faut travailler pour renforcer correctement votre installation. On commet trop souvent l’erreur de croire que Docker est sécurisé dès sa sortie de la boîte. Pour dire les choses franchement : ce n’est pas le cas.
Nous ne disons pas que la simple présence de Docker constitue 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, qui varient en fonction de l’utilisation que vous faites de la technologie. Comme pour 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 importent, et ce que vous devez faire pour y remédier.
Il est trop facile d’entendre le discours sur les « applications isolées » et de supposer que cela s’étend à la sécurité au niveau du bac à sable. En réalité, une installation standard de Docker exécute les processus de conteneur en tant que root et une rupture de conteneur pourrait compromettre votre hôte.
La sécurité de Docker est un sujet aux multiples facettes qui nécessite de prendre en compte l’environnement hôte, le démon Docker et la manière dont vous construisez et maintenez 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 les conteneurs.
Tout cela signifie que Docker n’est pas forcément une bonne option pour les environnements critiques en matière de sécurité. Bien que Docker puisse fournir des protections de sécurité, vous devez disposer de membres d’équipe compétents et d’un état d’esprit conscient 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 éléments sans affecter les autres.
Si votre application est monolithique, vous ne pourrez pas profiter de 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 rames de dépendances et un long processus de construction qui peut rapidement gonfler votre image Docker. Il en résulte des temps d’attente frustrants lors de la construction de l’image ainsi que des coûts excessifs de stockage et de bande passante.
Comme d’habitude, il y a deux côtés à 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 moment où 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 le remaniement à l’avenir, il est peut-être préférable de reconsidérer vos motivations. Les grandes images de conteneur qui incluent de multiples composants fonctionnels sont un bon indicateur du fait que vous ne respectez pas les meilleures pratiques en matière de conteneur. Au fil du temps, vous pourriez constater que cette approche vous freine et fait 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 ? Une fois de plus, tout dépend, mais nous vous mettons en garde contre la tentation de sauter dans le train de Docker avec la simplicité comme motivation principale.
Docker exige un changement de mentalité et une familiarisation avec de nouveaux outils et concepts. Vos développeurs seront-ils à l’aise avec lui et quel sera l’impact 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é, celle-ci a tendance à refaire surface sous différentes formes. Vous devrez écrire, documenter, maintenir et construire vos images Docker, soit localement sur les machines des développeurs, soit dans le cadre d’un pipeline CI. Les développeurs devront apprendre le CLI de 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’utiliser des conteneurs en production, vous devrez également tenir compte d’autres éléments. 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 inopinément ?
Les partisans de la mentalité « Docker est simple » ont tendance à se concentrer sur la facilité avec laquelle vous pouvez naïvement démarrer 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, il suffit d’exécuter docker -d mysql:8. Pourtant, il y a encore beaucoup à apprendre si vous voulez utiliser Docker avec succès pour créer et exécuter vos propres logiciels tout en respectant les meilleures pratiques et en évitant les pièges courants.
Vous n’êtes pas sûr de la raison de votre conteneurisation
Les conteneurs sont omniprésents ; vous ne pouvez pas lire plus de quelques articles sur le développement logiciel sans les rencontrer, et leurs partisans sont bruyants et enthousiastes. Cet attrait populaire peut créer une pression à l’adoption, car Docker est un outil » moderne » que d’autres ont trouvé utile.
Ce n’est pas une bonne raison pour conteneuriser. Vous avez besoin d’un objectif plus concret, tel que « les développeurs doivent être en mesure de répliquer précisément la production localement » ou « nous devons être en mesure de mettre à l’échelle horizontalement des répliques de nos services. » Si vous ne ressentez pas de 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. Ce choix peut sembler ennuyeux, mais Docker n’est pas une force de transformation irréprochable et son adoption réussie n’est pas garantie.
L’ajout de Docker à vos processus peut nécessiter un investissement initial important. Vous devrez peut-être remanier votre base de code, écrire et tester vos Dockerfiles, donner aux développeurs le temps d’apprendre et réaliser une évaluation de la sécurité. Lorsque les avantages qui en découlent ne sont pas clairs – et que vous n’avez pas identifié à quoi ressemblera le succès – l’effort pourrait être un fardeau qui détourne du travail productif sur votre système.
Conclusion
Docker est une technologie populaire à juste titre : pour de nombreuses équipes et de nombreux développeurs, il offre un équilibre idéal entre facilité d’utilisation, flexibilité et performance, ce qui lui permet de simplifier les processus de développement du monde réel. Cependant, Docker n’est pas magique : il y a des cas où il ne peut pas fonctionner et beaucoup d’autres où il ne fonctionnera pas, en fonction de vos technologies, processus et état d’esprit existants.
Même si Docker ne convient pas parfaitement à vos projets aujourd’hui, vous pourrez peut-être en tirer quelques avantages en l’adoptant progressivement. Identifiez les difficultés 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 votre API, la mise en œuvre de Docker sur cette partie de votre pile pourrait résoudre le problème, même si vous n’êtes pas en mesure d’utiliser des conteneurs en production.
L’intérêt des conteneurs est de pouvoir packager des parties de votre application sous forme de composants isolés qui fonctionnent indépendamment. Cela ne signifie pas automatiquement que vous devez packager chaque composant en tant que conteneur. Restez objectif, recherchez les possibilités de conteneurisation lorsque cela s’avère utile, mais soyez prêt à reconnaître les situations où Docker n’apporte pas de valeur ajoutée à votre flux de travail existant.