Docker — est-ce un jouet ou pas ? Ou finalement oui ?

Bonjour à tous !

J'aimerais vraiment me plonger immédiatement dans le sujet, mais il serait plus approprié de vous parler un peu de mon histoire :

Introduction

Je suis développeur avec une expérience dans le développement d'applications à page unique en frontend, scala/java et nodejs côté serveur.

Pendant longtemps (cela fait certainement deux ou trois ans), je pensais que Docker était une bénédiction et un outil super cool, et que chaque développeur devrait savoir s'en servir. Et donc, cela en découle que chaque développeur doit avoir Docker installé sur sa machine locale. Que dire de mon opinion, parcourez les offres d'emploi publiées sur mon emploi. Dans une sur deux, il y a mention de Docker et si vous en avez la maîtrise, cela sera un avantage concurrentiel 😉

Dans mon parcours, j'ai rencontré de nombreuses personnes avec des attitudes différentes envers Docker et son écosystème. Certains disaient que c'était un outil pratique, garantissant la cross-plateforme. D'autres ne comprenaient pas pourquoi ils devraient s'exécuter dans des conteneurs et quel en était le bénéfice, d'autres s'en fichaient complètement et ne se préoccupaient pas (ils écrivaient simplement du code et rentraient chez eux — je les envie, d'ailleurs 🙂)

Raisons d'utilisation

Pourquoi ai-je utilisé Docker ? Probablement pour les raisons suivantes :

• lancer des bases de données, 99 % des applications en utilisent
• lancer Nginx pour servir le frontend et faire le proxy vers le backend
• je peux emballer l'application dans une image Docker, de cette manière mon application fonctionnera partout où Docker est présent, le problème de distribution est résolu immédiatement
• découverte de services intégrée, je peux créer des microservices, chaque conteneur (connecté à un réseau commun) peut facilement accéder à un autre par alias, c'est très pratique
• c'est amusant de créer un conteneur et de 'jouer' avec.

Ce que je n'ai jamais aimé dans Docker :

• pour que mon application fonctionne, Docker lui-même doit être installé sur le serveur. Pourquoi en ai-je besoin, si mes applications fonctionnent sur JRE ou Node.js et que l'environnement pour elles est déjà présent sur le serveur ?
• si je veux lancer ma propre image (privée) construite localement sur un serveur distant, j'ai besoin de mon propre dépôt Docker, il faut qu'il y ait un registre fonctionnant quelque part et il faut aussi configurer HTTPS, car Docker CLI ne fonctionne que par HTTPS. Oh mince... il y a des options, bien sûr, pour sauvegarder l'image localement via docker save et la transférer simplement via SCP… Mais cela demande beaucoup d'efforts. Et, de plus, cela semble être une solution 'bricolée', jusqu'à ce que je dispose de mon propre dépôt.
• docker-compose. Il est uniquement destiné à exécuter des conteneurs. C'est tout. Il ne peut rien faire d'autre. Docker-compose a de nombreuses versions de ses fichiers, sa propre syntaxe. Quel que soit son degré de déclaration, je ne veux pas lire leur documentation. Elle ne me sera plus utile ailleurs.
• lorsque je travaille en équipe, la plupart du temps les gens écrivent des Dockerfile de manière très maladroite, ne comprennent pas comment cela est mis en cache, ajoutent à l'image tout ce qu'il faut et ce qu'il ne faut pas, héritent d'images qui ne sont pas sur dockerhub ou dans un dépôt privé, créent des docker-compose fichiers avec des bases de données et ne persistent rien. En même temps, les développeurs déclarent fièrement que docker est génial, que tout fonctionne localement, et que les RH écrivent dans les offres d'emploi : « Nous utilisons docker et nous avons besoin d'un candidat ayant cette expérience ».
• pensent toujours à déployer tout et n'importe quoi dans docker : postgresql, kafka, redis. Dommage que tout ne fonctionne pas dans des conteneurs, que tout ne soit pas facile à configurer et à démarrer. Cela est soutenu par des développeurs tiers, pas par les fournisseurs eux-mêmes. Et au fait, cela pose immédiatement la question : si les fournisseurs ne se soucient pas de maintenir leurs produits dans docker, pourquoi le font-ils ? Peut-être qu'ils en savent quelque chose ?
• la question de la persistance des données du conteneur se pose toujours. Et là on se dit, devrais-je simplement monter un répertoire hôte ou créer un volume docker ou faire un conteneur de données qui maintenant déprécié? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume donne simplement que les données seront créées dans un quelconque /usr/* et la même histoire se produira avec le uid et gid comme dans le premier cas. Si vous lancez un composant tiers, il faut lire la documentation et chercher la réponse à la question : « dans quels répertoires le composant du conteneur écrit-il des fichiers ? »

Je n'ai jamais aimé devoir passer trop de temps avec docker. au départ: je pensais à comment lancer des conteneurs, de quelles images je devais partir, je créais des Makefile qui contenaient des alias pour de longues commandes docker. Je ne supportais pas docker-compose parce que je ne voulais pas apprendre un autre outil de l'écosystème docker. Et docker-compose up cela me stressait, surtout si l'on rencontrait encore build des constructions, et non des images déjà construites. Tout ce que je voulais vraiment, c'était de faire le produit de manière efficace et rapide. Mais je n'arrivais pas à mettre en ordre l'utilisation de docker.

Découverte d'Ansible

Récemment (il y a trois mois), j'ai travaillé avec une équipe DevOps, presque chaque membre de l'équipe avait une opinion négative sur docker. Pour les raisons :

• Docker gère iptables (bien qu'il soit possible de le désactiver dans daemon.json)
• Nous n'allons pas exécuter Docker en production
• Si le démon Docker échoue, tous les conteneurs d'infrastructure échouent également
• Docker n'est pas indispensable
• Pourquoi utiliser Docker quand on a Ansible et des machines virtuelles ?

Au même travail, j'ai découvert un autre outil : Ansible. J'en avais déjà entendu parler, mais je n'avais jamais essayé d'écrire mes propres playbooks. Maintenant, j'ai commencé à écrire mes propres tâches et ma perception a totalement changé ! Parce que j'ai réalisé qu'Ansible a des modules pour exécuter les mêmes conteneurs Docker, assembler des images, gérer des réseaux, etc., et qu'il est possible de lancer des conteneurs non seulement localement mais aussi sur des serveurs distants ! Mon enthousiasme était sans limites - j'ai trouvé un outil FIABLE et j'ai jeté mes fichiers Makefile et docker-compose, remplacés par des tâches YAML. Le code a été réduit grâce à l'utilisation de constructions comme loop, when, etc.

Docker pour faire fonctionner des composants tiers comme des bases de données

Récemment, j'ai découvert des tunnels SSH. Il s'est avéré qu'il était très simple de "rediriger" un port d'un serveur distant vers un port local. Le serveur distant peut être soit une machine dans le cloud, soit une machine virtuelle lancée dans VirtualBox. Si moi ou un de mes collègues avons besoin d'une base de données (ou d'autre composant tiers), il suffit de lancer le serveur avec ce composant et de le couper lorsque le serveur n'est plus nécessaire. La redirection de ports donne le même effet que d'avoir une base de données lancée dans un conteneur Docker.

Cette commande redirige mon port local vers un serveur distant avec PostgreSQL :

ssh -L 9000:localhost:5432 user@example.com

Utiliser un serveur distant résout le problème du développement en équipe. Plusieurs développeurs peuvent utiliser ce serveur sans avoir besoin de configurer PostgreSQL, de s'occuper de Docker ou d'autres complexités. Sur le serveur distant, on peut installer la même base de données dans Docker, même si la version spécifique est difficile à obtenir. Tout ce dont les développeurs auront besoin, c'est d'avoir accès via SSH !

J'ai récemment lu que les tunnels SSH sont une fonctionnalité limitée d'un VPN classique ! On peut simplement configurer OpenVPN ou d'autres implémentations de VPN, mettre en place l'infrastructure et la mettre à disposition des développeurs. C'est plutôt génial !

Heureusement, AWS, Google Cloud et d'autres offrent une année d'utilisation gratuite, alors profitez-en ! Ils sont peu coûteux si vous les éteignez quand ils ne sont pas utilisés. Je me suis toujours demandé dans quel but j'aurais besoin d'un serveur distant comme gcloud, il semble que je l'ai trouvé.

Comme machine virtuelle locale, vous pouvez utiliser le même Alpine qui est largement utilisé dans les conteneurs Docker. Ou d'autres distributions légères pour que la machine démarre plus rapidement.

En résumé : il est possible et nécessaire de faire tourner des bases de données et autres services d'infrastructure sur des serveurs distants ou dans VirtualBox. Je n'ai pas besoin de Docker pour cela.

Un peu sur les images Docker et leur distribution.

J'ai déjà écrit. article Dans lequel je voulais faire passer le message que l'utilisation des images Docker ne garantit rien. Les images Docker sont uniquement nécessaires pour créer des conteneurs Docker. Si vous vous appuyez sur une image Docker, cela signifie que vous vous appuyez sur l'utilisation de conteneurs Docker et vous serez limité à cela.

Avez-vous déjà vu des développeurs de logiciels porter leurs produits uniquement sous forme d'images Docker ?
Le résultat de la plupart des produits est des fichiers binaires pour une plateforme spécifique, qui sont simplement ajoutés dans une image Docker héritée de la plateforme requise. Ne vous êtes-vous jamais demandé pourquoi il y a tant d'images similaires sur Docker Hub ? Tapez par exemple nginx, vous verrez 100500 images de personnes différentes. Ces personnes n'ont pas développé nginx, elles ont simplement ajouté l'officiel nginx dans leur image Docker et l'ont agrémenté de leurs configurations pour simplifier le démarrage des conteneurs.

En gros, vous pouvez simplement stocker dans un tgz, et si quelqu'un souhaite le faire tourner dans Docker, qu'il ajoute le tgz dans le Dockerfile, hérite de l'environnement nécessaire et crée des améliorations qui ne modifient pas l'application dans le tgz. Celui qui créera l'image Docker saura ce qu'est ce tgz et ce dont il a besoin pour fonctionner. C'est ainsi que j'utilise Docker. ici

En résumé : je n'ai pas besoin d'un registre Docker, je vais utiliser un S3 ou simplement un stockage de fichiers comme Google Drive/Dropbox.

Docker dans l'intégration continue.

Toutes les entreprises pour lesquelles j'ai travaillé se ressemblent. Ce sont généralement des entreprises de produits. Elles ont donc une application, un ensemble de technologies (peut-être deux ou trois langages de programmation).

Ces entreprises utilisent Docker sur leurs serveurs où le processus CI est exécuté. La question est : pourquoi doit-on construire des projets dans des conteneurs Docker sur leurs serveurs ? Pourquoi ne pas simplement préparer un environnement de construction, par exemple, écrire un playbook Ansible qui installerait les bonnes versions de Node.js, PHP, JDK, et copierait les clés SSH, etc., sur le serveur où la construction aura lieu ?

Maintenant, je comprends que c'est se tirer une balle dans le pied, car Docker n'apporte aucun bénéfice avec son isolement. Les problèmes de CI dans Docker auxquels j'ai été confronté :

• il faut à nouveau une image Docker pour la compilation. Il faut chercher une image ou écrire son propre Dockerfile.
• 90 % du temps, il faut transmettre des clés SSH, des données secrètes qu'on ne veut pas écrire dans l'image Docker.
• le conteneur se crée puis meurt, perdant tous les caches avec lui. La prochaine compilation devra télécharger toutes les dépendances du projet à nouveau, ce qui prend du temps et est inefficace, et le temps, c'est de l'argent.

Les développeurs ne construisent pas de projets dans des conteneurs Docker (j'étais autrefois un tel fan, d'ailleurs, je me plains de moi-même dans le passé xD). En Java, il est possible d'avoir plusieurs versions et de changer celle dont on a besoin d'une simple commande. En Node.js, c'est pareil, il y a nvm.

Sortie

Je pense que Docker est un outil très puissant et flexible, mais c'est aussi son défaut (cela peut sembler étrange, non ?). Grâce à lui, les entreprises s'y accrochent facilement, l'utilisant quand cela est nécessaire et même quand ce n'est pas le cas. Les développeurs lancent leurs propres conteneurs, leur propre environnement, puis tout cela se déplace lentement vers le CI, la production. L'équipe DevOps écrit des solutions pour faire fonctionner ces conteneurs.

Utilisez Docker uniquement à la toute dernière étape de votre processus de travail, ne l'introduisez pas dans le projet au début. Il ne résoudra pas vos problèmes commerciaux. Il déplacera simplement les problèmes à UN AUTRE niveau et proposera ses propres solutions, vous fera faire un double travail.

Quand Docker est nécessaire: je suis arrivé à la conclusion que Docker est très bon pour optimiser un processus établi mais pas pour construire une fonctionnalité de base.

Si vous décidez tout de même d'utiliser Docker, alors :

• soyez extrêmement prudent
• ne forcez pas l'utilisation de Docker sur les développeurs
• limitez son utilisation à un seul endroit, ne le disséquez pas dans tous les dépôts avec des Dockerfiles et docker-compose.

PS :

• Je suis récemment tombé sur packer Et on dit qu'il fonctionne très bien avec Ansible et permet d'unifier le processus de création d'images (y compris les images Docker).
• C'est aussi à propos de Docker, un article intéressant.

Merci d'avoir lu jusqu'ici, je vous souhaite des solutions claires dans vos affaires et des journées de travail productives !

Source : habr.com