J'ai travaillé dans différentes entreprises qui utilisent des microservices. Et ils les ont conduits dans des conteneurs dockers. Maintenant, je travaille avec un projet qui, bien qu'il s'agisse d'un monolithe, il est encore plus pratique de l'exécuter dans un conteneur.
D'une part, Docker est un outil très polyvalent, il peut être utilisé facilement et efficacement pour résoudre un grand nombre de tâches. C'est compréhensible et il semble que tout est élémentaire. Mais d'un autre côté, si vous ne dépensez pas votre temps et vos ressources pour «pomper» dans son bon usage, vous risquez de trop compliquer les choses simples. Et bien sûr, vous supposerez que vous avez raison, et Docker est une poubelle encombrante médiocre qui ne convient pas pour résoudre votre tâche unique.
Habituellement, dans une entreprise standard, le processus de travail sur n'importe quelle tâche ressemble à ceci:
- Git push est fait avec notre commit
- Un système est déclenché, que ce soit Jenkins, TeamCity, etc.
- Le pipeline / travail est lancé, dans lequel des bibliothèques tierces sont téléchargées, le projet est compilé, des tests sont exécutés
- Une image Docker avec le projet assemblé (ADD ..) est créée et insérée dans le registre Docker distant
- D'une manière ou d'une autre, sur le serveur distant, le docker est fait (chef, marionnette, manuellement via docker-compose) et le conteneur démarre.
Intuitivement, j'ai toujours pensé que c'était en quelque sorte trop compliqué. Ce processus est fièrement appelé CI / CD, et je suis fatigué de ces gens intelligents qui ne doutent pas que c'est la façon la plus simple.
Pour l'utilisateur final, cela ressemble à ceci: en poussant vers le dépôt git, ce qui était dans la validation se déroule quelque part.
Ce que je n'aime pas dans cette approche.
- La seule façon de déployer le système sur un serveur distant est de suivre les 5 étapes.
- À l'étape 3, vous aurez peut-être besoin de clés d'accès à des bibliothèques privées. Le processus peut être long si la mise en cache des bibliothèques précédemment téléchargées n'est pas configurée.
- Vous devez préparer le Dockerfile, décider de l'image (DE ...), décider comment nous allons étiqueter l'image et avoir besoin d'accéder au référentiel dans lequel nous allons pousser l'image.
- Besoin de votre propre référentiel, configurez https. Après tout, le client docker ne fonctionne que sur https.
Le quatrième paragraphe, bien sûr, est fait une fois et peut-être ne devrait-il pas être ajouté.
Mais combien de fois le mot Docker est-il déjà mentionné au stade de la sortie?
Pensez-y: pourquoi traînons-nous tout ce Docker à l'avance? Parce que l'on pense que le conteneur est pratique et «Eh bien, tout allait bien, cela fonctionne. Que commencez-vous alors? ».
Donc, pour de telles personnes, je peux dire - les conteneurs Docker ne sont pas une panacée et pas le seul environnement dans lequel votre application peut s'exécuter. Projet écrit en python, php, js, swift, scala / java, etc. peut être exécuté sur:
- machine virtuelle distante
- sur un hôte local sans virtualisation ni conteneurs Docker.
Tout d'un coup :)
Imaginons que nous faisons un service qui fonctionnera sur nodeJS.
Le résultat de ce projet (ou comme j'appelle «l'artefact») sera un ensemble de fichiers js (le service lui-même) + node_modules (bibliothèques tierces qui sont utilisées dans le service).
Supposons que nous nous sommes assurés que le service fonctionne et que nous voulons l'exécuter à distance afin que nos testeurs puissent le tester pour la fonctionnalité.
Comment aimez-vous cette idée:
- Nous créons .tar.gz avec notre projet et le téléchargeons dans ... un dépôt à distance d'artefacts! (De plus, ces référentiels sont appelés «référentiels binaires»).
- Nous indiquons l'URL par laquelle ils peuvent télécharger notre service et commencer les tests.
De plus, les testeurs peuvent démarrer le service localement à la maison, s'ils ont tout, ou créer un Dockerfile, dans lequel il y aura un téléchargement d'artefact et il suffit de démarrer le conteneur. Eh bien, ou autre chose.
Je dirai tout de suite si vous ne voulez pas que les testeurs lancent des conteneurs de docker et en général "ce n'est pas leur travail" de démarrer, puis utilisez un outil qui collectera des images dès que de nouveaux artefacts apparaissent dans le référentiel binaire (utilisez le web hook, poursuivez périodiquement par-dessus la couronne).
Maintenant, à partir des référentiels binaires, il y a:
- Nexus de sonatype
- Artifactory
Nexus est facile à utiliser, il a un tas de différents référentiels que vous pouvez créer (npm, maven, raw, docker) donc je l'utilise.
C'est une putain d'idée simple, pourquoi n'ai-je pas lu à ce sujet nulle part? Sur Internet, vous ne pouvez pas compter les articles "comme sur git push quelque part où un conteneur est déployé dans une sorte de kubernetes". À partir d'algorithmes aussi complexes, les cheveux se tiennent debout.
Le but de cet article, pour dire - il n'est pas nécessaire dans un processus d'assembler le projet et de l'ajouter à l'image du docker.
Divisez et régnez!
Construisez le projet, publiez des artefacts dans un endroit téléchargeable. (Le registre Docker n'est pas le seul endroit où vous pouvez stocker votre projet, choisissez des chemins universels pour la livraison d'artefacts aux serveurs).
Avec un outil séparé, remettez les artefacts au serveur sur lequel votre projet fonctionnera.
Tout est très simple, donnez le choix aux autres: utilisez docker, exécutez dans kubernetes ou utilisez tout autre outil pour exécuter des artefacts. Pas besoin d'imposer l'utilisation de la technologie malgré le fait qu'elle vous semble très pratique et à la mode.
Bonne chance dans le lancement de vos projets!