Docker est-il un jouet ou pas ? Ou est-ce toujours vrai ?

Bonjour à tous!

J'ai vraiment envie d'entrer directement dans le sujet, mais il serait plus correct de raconter un peu mon histoire :

Entrée

Je suis un programmeur avec de l'expérience dans le développement d'applications frontend monopage, scala/java et nodejs sur le serveur.

Pendant assez longtemps (certainement quelques ou trois ans), j'étais d'avis que Docker était une manne tombée du ciel et en général un outil très cool et qu'absolument tous les développeurs devraient pouvoir l'utiliser. Et il s’ensuit que chaque développeur devrait avoir Docker installé sur sa machine locale. Qu'en est-il de mon avis, parcourez les offres d'emploi qui sont publiées sur le même hh. Un sur deux contient une mention de docker, et si vous le possédez, ce sera votre avantage concurrentiel 😉

Sur mon chemin, j'ai rencontré de nombreuses personnes, avec leurs attitudes différentes envers Docker et son écosystème. Certains ont dit que c'était une chose pratique qui garantit la fonctionnalité multiplateforme. Les seconds ne comprenaient pas pourquoi ils devaient fonctionner dans des conteneurs et quel profit en tirerait, le troisième s'en fichait du tout et ne s'en souciait pas (ils ont juste écrit le code et sont rentrés chez eux - je les envie, par le chemin :)

Raisons d'utilisation

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

• lancement de la base de données, 99% des applications les utilisent
• lancement de nginx pour la distribution frontend et proxy vers le backend
• vous pouvez empaqueter l'application dans une image Docker, de cette façon mon application fonctionnera partout où Docker existe, le problème de distribution est résolu immédiatement
• découverte de services prête à l'emploi, vous pouvez créer des microservices, chaque conteneur (connecté à un réseau commun) peut facilement en atteindre un autre via un alias, très pratique
• C’est amusant de créer un conteneur et de « jouer » dedans.

Ce que je n'aime toujours pas chez Docker :

• Pour que mon application fonctionne, j'ai besoin de Docker lui-même sur le serveur. Pourquoi en ai-je besoin si mes applications s'exécutent sur jre ou nodejs et que leur environnement est déjà sur le serveur ?
• si je veux exécuter mon image (privée) construite localement sur un serveur distant, alors j'ai besoin de mon propre référentiel Docker, j'ai besoin que le registre fonctionne quelque part et je dois également configurer https, car Docker cli ne fonctionne que sur https. Oh putain... il existe bien sûr des options pour enregistrer l'image localement via docker save et envoyez simplement l'image via scp... Mais cela fait beaucoup de mouvements corporels. Et en plus, cela ressemble à une solution « béquille » jusqu'à ce que votre propre référentiel apparaisse
• docker-compose. Il n’est nécessaire que pour exécuter des conteneurs. C'est tout. Il ne peut rien faire d'autre. Docker-compose a un tas de versions de ses fichiers, sa propre syntaxe. Aussi déclaratif soit-il, je ne veux pas lire leur documentation. Je n’en aurai besoin nulle part ailleurs.
• lorsqu'ils travaillent en équipe, la plupart des gens écrivent un Dockerfile de manière très tordue, ne comprennent pas comment il est mis en cache, ajoutent tout ce dont ils ont besoin et n'ont pas besoin à l'image, héritent d'images qui ne sont pas dans Dockerhub ou dans un référentiel privé, en créent docker-compose fichiers avec des bases de données et rien ne persiste. Dans le même temps, les développeurs déclarent fièrement que Docker est cool, que tout fonctionne localement pour eux, et les RH écrivent de manière importante dans le poste vacant : « Nous utilisons Docker et nous avons besoin d'un candidat avec une telle expérience professionnelle.
• Je suis constamment hanté par l'idée de tout augmenter dans Docker : postgresql, kafka, redis. C'est dommage que tout ne fonctionne pas dans des conteneurs, tout n'est pas facile à configurer et à exécuter. Ceci est pris en charge par des développeurs tiers et non par les fournisseurs eux-mêmes. Et d'ailleurs, la question se pose immédiatement : les fournisseurs ne se soucient pas de maintenir leurs produits dans Docker, pourquoi, peut-être qu'ils savent quelque chose ?
• La question se pose toujours de la persistance des données des conteneurs. et puis vous pensez, devrais-je simplement monter le répertoire hôte ou créer un volume Docker ou créer un conteneur de données qui est maintenant deprecated? Si je monte un répertoire, je dois m'assurer que l'uid et le gid de l'utilisateur dans le conteneur correspondent à l'identifiant de l'utilisateur qui a lancé le conteneur, sinon les fichiers créés par le conteneur seront créés avec les droits root. Si j'utilise volume alors les données seront simplement créées dans certains /usr/* et il y aura la même histoire avec uid et gid que dans le premier cas. Si vous lancez un composant tiers, vous devez lire la documentation et chercher la réponse à la question : « dans quels répertoires conteneurs le composant écrit-il des fichiers ?

Je n'ai toujours pas aimé le fait de devoir bricoler Docker trop longtemps au stade initial: J'ai compris comment lancer des conteneurs, à partir de quelles images lancer, j'ai créé des Makefiles contenant des alias de longues commandes Docker. Je détestais Docker-compose parce que je ne voulais pas apprendre un autre outil de l'écosystème Docker. ET docker-compose up Ça me dérangeait, surtout s'ils se rencontraient encore là-bas build des constructions, plutôt que des images déjà assemblées. Tout ce que je voulais vraiment, c’était simplement fabriquer un produit de manière efficace et rapide. Mais je n'arrivais pas à comprendre comment utiliser Docker.

Présentation d'Ansible

Récemment (il y a trois mois), j'ai travaillé avec une équipe DevOps, dont presque tous les membres avaient une attitude négative envers Docker. Pour des raisons:

• Docker Rules iptables (bien que vous puissiez le désactiver dans daemon.json)
• Docker est bogué et nous ne l'exécuterons pas en production
• si le démon Docker plante, alors tous les conteneurs avec infrastructure crash en conséquence
• pas besoin de docker
• pourquoi docker s'il y a Ansible et des machines virtuelles

Au même travail, j'ai découvert un autre outil - Ansible. J’en ai entendu parler une fois, mais je n’ai pas essayé d’écrire mes propres playbooks. Et maintenant j'ai commencé à écrire mes tâches et puis ma vision a complètement changé ! Parce que j'ai réalisé : Ansible dispose de modules pour exécuter les mêmes conteneurs Docker, constructions d'images, réseaux, etc., et les conteneurs peuvent être exécutés non seulement localement, mais également sur des serveurs distants ! Mon plaisir n'avait pas de limites - j'ai trouvé un outil NORMAL et j'ai jeté mes fichiers Makefile et docker-compose, ils ont été remplacés par des tâches yaml. Le code a été réduit en utilisant des constructions comme loop, when, etc.

Docker pour exécuter des composants tiers tels que des bases de données

J'ai récemment découvert les tunnels ssh. Il s'est avéré qu'il est très simple de « rediriger » le port d'un serveur distant vers un port local. Le serveur distant peut être soit une machine dans le cloud, soit une machine virtuelle exécutée dans VirtualBox. Si mon collègue ou moi avons besoin d'une base de données (ou d'un autre composant tiers), nous pouvons simplement démarrer le serveur avec ce composant et le désactiver lorsque le serveur n'est pas nécessaire. La redirection de port donne le même effet qu'une base de données exécutée dans un conteneur Docker.

Cette commande transfère mon port local vers un serveur distant exécutant postgresql :

ssh -L 9000 : hôte local : 5432 [email protected]

L'utilisation d'un serveur distant résout le problème du développement d'équipe. Un tel serveur peut être utilisé par plusieurs développeurs à la fois ; ils n'ont pas besoin d'être capables de configurer postgresql, de comprendre Docker et d'autres subtilités. Sur un serveur distant, vous pouvez installer la même base de données dans Docker lui-même, s'il est difficile d'installer une version spécifique. Tout ce dont les développeurs ont besoin est de fournir un accès ssh !

J'ai récemment lu que les tunnels SSH constituent une fonctionnalité limitée d'un VPN classique ! Vous pouvez simplement installer OpenVPN ou d’autres implémentations VPN, configurer l’infrastructure et la donner aux développeurs pour qu’ils l’utilisent. C'est trop cool!

Heureusement, AWS, GoogleCloud et autres vous offrent un an d'utilisation gratuite, alors utilisez-les ! Ils sont bon marché si vous les éteignez lorsqu’ils ne sont pas utilisés. Je me suis toujours demandé pourquoi j'aurais besoin d'un serveur distant comme gcloud, il semble que je les ai trouvés.

En tant que machine virtuelle locale, vous pouvez utiliser le même Alpine, qui est activement utilisé dans les conteneurs Docker. Eh bien, ou d'autres distributions légères pour accélérer le démarrage de la machine.

En fin de compte : vous pouvez et devez exécuter des bases de données et d’autres éléments d’infrastructure sur des serveurs distants ou dans Virtualbox. Je n'ai pas besoin de Docker à ces fins.

Un peu sur les images Docker et leur distribution

J'ai déjà écrit статью dans lequel je voulais faire comprendre que l'utilisation d'images Docker n'offre aucune garantie. Les images Docker sont nécessaires uniquement pour créer un conteneur Docker. Si vous effectuez une mise à niveau vers une image Docker, vous effectuez une mise à niveau pour utiliser des conteneurs Docker et vous ne les utiliserez que.

Avez-vous vu un endroit où les développeurs de logiciels portent leurs produits uniquement dans une image Docker ?
Le résultat de la plupart des produits est des fichiers binaires pour une plateforme spécifique ; ils sont simplement ajoutés à l'image docker, héritée de la plateforme souhaitée. Vous êtes-vous déjà demandé pourquoi il y a tant d'images similaires sur dockerhub ? Entrez nginx par exemple, vous verrez 100500 XNUMX images de personnes différentes. Ces personnes n'ont pas développé nginx elles-mêmes, elles ont simplement ajouté nginx officiel à leur image docker et l'ont assaisonné avec leurs propres configurations pour faciliter le lancement de conteneurs.

En général, vous pouvez simplement le stocker dans tgz, si quelqu'un a besoin de l'exécuter dans Docker, laissez-le ajouter tgz au Dockerfile, hériter de l'environnement souhaité et créer des petits pains supplémentaires qui ne modifient pas l'application elle-même dans tgz. Quiconque créera une image Docker saura ce qu'est tgz et ce dont il a besoin pour fonctionner. Voici comment j'utilise Docker ici

En fin de compte : je n'ai pas besoin de registre Docker, j'utiliserai une sorte de S3 ou simplement un stockage de fichiers comme Google Drive/dropbox

Docker dans CI

Toutes les entreprises pour lesquelles j'ai travaillé sont similaires. Ce sont généralement des épiceries. Autrement dit, ils ont une application, une pile technologique (enfin, peut-être quelques ou trois langages de programmation).

Ces sociétés utilisent Docker sur leurs serveurs où s'exécute le processus CI. Question : Pourquoi avez-vous besoin de créer des projets dans un conteneur Docker sur vos serveurs ? Pourquoi ne pas simplement préparer un environnement pour la build, par exemple, écrire un playbook Ansible qui installera les versions nécessaires de nodejs, php, jdk, copiera les clés ssh, etc. sur le serveur sur lequel la build aura lieu ?

Maintenant, je comprends que c'est une balle dans le pied, car Docker ne rapporte aucun profit avec son isolement. Problèmes que j'ai rencontrés avec CI dans Docker :

• encore une fois, vous avez besoin d'une image Docker pour créer. vous devez rechercher une image ou écrire votre propre fichier docker.
• 90 % que vous devez transférer des clés ssh, des données secrètes que vous ne souhaitez pas écrire dans l'image du docker.
• le conteneur est créé et meurt, tous les caches sont perdus avec lui. la prochaine version téléchargera à nouveau toutes les dépendances du projet, 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 grand fan, vraiment, je me sens désolé pour moi dans le passé xD). En Java, il est possible d'avoir plusieurs versions et de les modifier avec une seule commande par celle dont vous avez besoin actuellement. C'est pareil dans nodejs, il y a nvm.

conclusion

Je pense que Docker est un outil très puissant et flexible, c'est son inconvénient (cela semble étrange, oui). Avec son aide, les entreprises peuvent facilement s'y accrocher et l'utiliser là où elles sont nécessaires ou non. Les développeurs lancent leurs conteneurs, certains de leurs environnements, puis tout se déroule en douceur vers le CI et la production. L'équipe DevOps écrit une sorte de code pour exécuter ces conteneurs.

Utiliser Docker uniquement sur la plus récente étape de votre flux de travail, ne le faites pas glisser dans le projet au début. Cela ne résoudra pas vos problèmes commerciaux. Il ne fera que déplacer les problèmes à UN AUTRE niveau et proposera ses propres solutions, vous ferez un double travail.

Quand Docker est nécessaire: Je suis arrivé à la conclusion que Docker est très efficace pour optimiser un processus donné, mais pas pour créer des fonctionnalités de base

Si vous décidez toujours d'utiliser Docker, alors :

• être extrêmement prudent
• ne forcez pas les développeurs à utiliser Docker
• localisez son utilisation en un seul endroit, ne le répartissez pas sur tous les référentiels Dockefile et docker-compose

PS:

• Je suis récemment tombé sur emballeur et ils disent que cela fonctionne très bien avec Ansible et vous permet d'unifier le processus de création d'images (y compris l'image Docker)
• aussi à propos de docker, article intéressant

Merci d'avoir lu, je vous souhaite des décisions transparentes dans vos affaires et des journées de travail productives !

Source: habr.com