Je vous invite à consulter la retranscription de la présentation d'Alexandre Sigatchev d'Inventos « Processus de développement et de test avec Docker + Gitlab CI »
Ceux qui commencent à mettre en œuvre le processus de développement et de test basé sur Docker + Gitlab CI posent souvent des questions basiques. Par où commencer ? Comment s'organiser ? Comment tester ?
Cette présentation est bonne car elle décrit de manière structurée le processus de développement et de test utilisant Docker et Gitlab CI. La présentation date de 2017. Je pense que l'on peut tirer des bases, de la méthodologie, de l'idée et des expériences d'utilisation de cette présentation.
Pour ceux que cela intéresse, je vous invite à lire la suite.
Je m'appelle Alexandre Sigatchev. Je travaille chez Inventos. Je vais parler de mon expérience d'utilisation de Docker et de la manière dont nous l'intégrons progressivement dans nos projets.
Thème de la présentation : Processus de développement avec Docker et Gitlab CI.
C'est ma deuxième présentation sur Docker. Au moment de la première présentation, nous utilisions Docker uniquement dans le développement sur les machines des développeurs. Le nombre d'employés utilisant Docker était d'environ 2-3 personnes. Petit à petit, nous avons accumulé de l'expérience et progressé un peu plus loin. Lien vers notre .
Que contiendra cette présentation ? Nous partagerons notre expérience sur les obstacles rencontrés et comment nous avons résolu certains problèmes. Ce n'était pas toujours idéal, mais cela nous a permis d'avancer.
Notre devise : dockeriser tout ce qui nous passe par les mains.
Quels problèmes résolvons-nous ?
Lorsque plusieurs équipes sont présentes dans l'entreprise, le programmeur est une ressource partagée. Il arrive qu'un programmeur soit extrait d'un projet et affecté temporairement à un autre projet.
Pour qu'un programmeur puisse s'intégrer rapidement, il doit télécharger le code source du projet et mettre en place un environnement le plus rapidement possible afin de résoudre les problèmes du projet.
En général, si l'on commence de zéro, la documentation dans le projet est rare. Les informations sur la configuration ne sont disponibles que pour les vétérans. Les employés configurent leur poste de travail en un ou deux jours. Pour accélérer ce processus, nous avons utilisé Docker.
La raison suivante concerne la normalisation des paramètres en développement. D'après mon expérience, les développeurs prennent souvent des initiatives. Dans un cas sur cinq, un domaine personnalisé est introduit, par exemple vasya.dev. À côté, se trouve le voisin Petya, qui a le domaine petya.dev. Ils développent un site ou un composant du système en utilisant ce nom de domaine.
Lorsque le système se développe et que ces noms de domaine commencent à figurer dans les configurations, un conflit d'environnements de développement se produit et le chemin du site est réécrit.
Il en va de même pour les paramètres de la base de données. Certaines personnes ne pensent pas à la sécurité et travaillent avec un mot de passe root vide. D'autres, lors de l'installation, la configuration MySQL a exigé un mot de passe, qui s'est révélé être 123. Il arrive souvent que la configuration de la base de données change constamment en fonction des commits du développeur. Quelqu'un a corrigé, quelqu'un ne l'a pas fait. Il y avait des astuces où nous avons sorti une configuration de test dans .gitignore et chaque développeur devait installer la base de données. Cela compliquait le processus de démarrage. Il faut, entre autres, se rappeler de la base de données. La base de données doit être initialisée, il faut indiquer un mot de passe, un utilisateur à créer, une table, etc.
Un autre problème est la diversité des versions des bibliothèques. Il arrive souvent qu'un développeur travaille sur différents projets. Il y a un projet Legacy, qui a commencé il y a cinq ans (de 2017 — note de la rédaction). Lors du démarrage, nous avons commencé avec MySQL 5.5. Il y a aussi des projets modernes, où nous essayons d'intégrer des versions de MySQL plus récentes, comme 5.7 ou plus (en 2017 — note de la rédaction).
Celui qui travaille avec MySQL sait que ces bibliothèques entraînent des dépendances. Il est assez problématique de lancer deux bases en même temps. Du moins, il est problématique de connecter de vieux clients à une nouvelle base de données. Cela engendre à son tour plusieurs problèmes.
Le prochain problème survient lorsque le développeur travaille sur sa machine locale, utilisant des ressources locales, des fichiers locaux et de la RAM locale. Toute interaction pendant le développement des solutions se déroule dans le cadre de ce qui fonctionne sur une seule machine. Par exemple, nous pouvons avoir 3 serveurs backend en production, mais le développeur enregistre des fichiers dans le répertoire racine, et c'est de là qu'Nginx prend les fichiers pour répondre aux demandes. Lorsque ce code atteint la production, il s'avère que le fichier est présent sur l'un des 3 serveurs.
Actuellement, le développement des microservices est en plein essor. Lorsque nous divisons nos grandes applications en petits composants interagissant entre eux. Cela permet de sélectionner des technologies spécifiques pour chaque ensemble de tâches. Cela permet également de répartir le travail et les zones de responsabilité entre les développeurs.
Un développeur frontend travaillant en JS n'influence pratiquement pas le backend. Le développeur backend, quant à lui, développe, dans notre cas, avec Ruby on Rails et ne gêne pas le frontend. L'interaction s'effectue via l'API.
Comme bonus, grâce à Docker, nous avons pu optimiser les ressources sur Staging. Chaque projet, en raison de sa spécificité, nécessitait des configurations particulières. Il fallait physiquement allouer soit un serveur virtuel et les configurer séparément, soit partager un environnement variable, ce qui pouvait influencer les projets les uns sur les autres selon les versions des bibliothèques.
Outils. Que utilisons-nous ?
- Docker lui-même. Les dépendances d'une application sont décrites dans le Dockerfile.
- Docker-compose est le lien qui regroupe plusieurs de nos applications Docker.
- Nous utilisons GitLab pour stocker le code source.
- Nous utilisons GitLab-CI pour l'intégration continue.
La présentation se compose de deux parties.
La première partie expliquera comment nous avons lancé Docker sur les machines des développeurs.
La deuxième partie expliquera comment interagir avec GitLab, comment nous lançons les tests et comment nous déployons en Staging.
Docker est une technologie qui permet de décrire (en utilisant une approche déclarative) les composants nécessaires. Voici un exemple de Dockerfile. Ici, nous déclarons que nous héritons de l'image Docker officielle Ruby:2.3.0. Elle contient Ruby version 2.3 préinstallé. Nous installons les bibliothèques nécessaires ainsi que NodeJS. Nous décrivons que nous créons un répertoire. /appNous définissons le répertoire app comme le répertoire de travail. Dans ce répertoire, nous plaçons le Gemfile et le Gemfile.lock minimaux nécessaires. Ensuite, nous exécutons la construction des projets qui installent cette image de dépendances. Nous indiquons que le conteneur sera prêt à écouter sur le port externe 3000. La dernière commande est celle qui lance directement notre application. Si nous exécutons la commande de lancement du projet, l'application tentera de s'exécuter et lancera la commande spécifiée.
C'est un exemple minimal d'un fichier docker-compose. Dans ce cas, nous montrons comment se fait la liaison de deux conteneurs. Il s'agit directement du service de base de données et du service web. Nos applications web nécessitent dans la plupart des cas une base de données pour stocker des données en tant que backend. Comme nous utilisons MySQL, nous avons un exemple avec MySQL — mais rien ne nous empêche d'utiliser une autre base de données (PostgreSQL, Redis).
Nous prenons de la source officielle sur Docker Hub l'image MySQL 5.7.14 sans modifications. L'image responsable de notre application web est construite à partir du répertoire actuel. Elle construit notre image lors du premier démarrage. Ensuite, elle exécute la commande que nous effectuons ici. Si nous revenons en arrière, nous verrons que la commande de démarrage a été définie via Puma. Puma est un service écrit en Ruby. Dans le deuxième cas, nous redéfinissons. Cette commande peut être arbitraire selon nos besoins ou nos tâches.
Nous décrivons également qu'il est nécessaire de transférer le port de notre machine hôte de développeur de 3000 au port 3000 du conteneur. Cela est réalisé automatiquement à l'aide d'iptables et de son propre mécanisme qui est intégré directement dans Docker.
Le développeur peut également, comme auparavant, se connecter à n'importe quelle adresse IP disponible, par exemple, l'adresse locale 127.0.0.1 ou l'adresse IP externe de la machine.
La dernière ligne indique que le conteneur web dépend du conteneur db. Lorsque nous lançons le conteneur web, docker-compose lancera d'abord notre base de données. Une fois que la base de données a démarré (en réalité — après le démarrage du conteneur ! Ceci ne garantit pas que la BDD est prête), notre application, notre backend sera lancé.
Cela permet d'éviter les erreurs lorsque la base de données n'est pas démarrée et permet d'économiser des ressources lorsque nous arrêtons le conteneur de bases de données, libérant ainsi des ressources pour d'autres projets.
Quels sont les avantages de l'utilisation de la conteneurisation des bases de données dans le projet ? Nous fixons la version de MySQL pour tous les développeurs. Cela permet d'éviter certaines erreurs qui peuvent survenir en cas de divergence des versions, lorsque la syntaxe, la configuration et les paramètres par défaut changent. Cela permet de spécifier des noms d'hôte communs pour la base de données, le login et le mot de passe. Nous nous éloignons du désordre des noms et des conflits dans les fichiers de configuration qui existaient auparavant.
Nous avons la possibilité d'utiliser une configuration plus optimale pour l'environnement de développement, qui diffère de la configuration par défaut. MySQL est par défaut configuré pour de faibles machines, et ses performances sont très basses à la sortie de la boîte.
Docker permet d'utiliser l'interpréteur Python, Ruby, NodeJS, PHP dans la version requise. Nous nous débarrassons de la nécessité d'utiliser un gestionnaire de versions. Auparavant, pour Ruby, nous utilisions un package rpm qui permettait de changer de version selon le projet. Cela permet également de migrer le code et de le versionner avec ses dépendances grâce à un conteneur Docker. Nous n'avons pas de problème pour comprendre la version tant de l'interpréteur que du code. Pour mettre à jour la version, il faut supprimer l'ancien conteneur et lever un nouveau conteneur. Si quelque chose se passe mal, nous pouvons retirer le nouveau conteneur et remettre l'ancien.
Après la construction de l'image, les conteneurs, tant en développement qu'en production, seront identiques. Cela est particulièrement pertinent pour les grandes installations.
Nous utilisons JavaScript et NodeJS dans le frontend.
Actuellement, notre dernier projet est sur ReactJS. Le développeur a lancé tous les conteneurs et a développé en utilisant le rechargement à chaud.
Ensuite, une tâche est lancée pour compiler le JavaScript, et le code compilé en statique est fourni via nginx pour économiser des ressources.
Voici un schéma de notre dernier projet.
Quelles sont les tâches que nous avons résolues ? Nous avons eu besoin de construire un système qui interagit avec des appareils mobiles. Ils reçoivent des données. L'une des possibilités est d'envoyer des notifications push à cet appareil.
Que avons-nous fait à cet égard ?
Nous avons divisé l'application en plusieurs composants : une partie administrative en JS, un backend qui fonctionne via une interface REST sous Ruby on Rails. Le backend interagit avec la base de données. Le résultat généré est renvoyé au client. L'interface d'administration, le backend et la base de données interagissent par l'interface REST.
Nous avons également eu besoin d'envoyer des notifications Push. Auparavant, nous avions un projet qui mettait en œuvre un mécanisme responsable de la livraison des notifications sur les plateformes mobiles.
Nous avons développé ce schéma : l'opérateur interagit avec l'interface admin via le navigateur, l'interface admin interagit avec le backend, une tâche est définie pour envoyer des notifications Push.
Les notifications Push interagissent avec un autre composant, qui est développé en NodeJS.
Des files d'attente sont mises en place et ensuite le mécanisme d'envoi des notifications se poursuit.
Deux bases de données sont représentées ici. Actuellement, nous utilisons 2 bases de données indépendantes avec Docker, qui ne sont pas liées entre elles, sauf par leur réseau virtuel commun, tandis que les données physiques sont stockées dans différents répertoires sur la machine du développeur.
C'est la même chose en chiffres. Ici, la réutilisation du code est importante.
Si auparavant nous parlions de réutilisation du code sous forme de bibliothèques, dans cet exemple, notre service responsable des notifications Push est réutilisé comme un serveur complet. Il fournit une API. Et notre nouveau développement interagit avec lui.
À l'époque, nous utilisions la version 4 de NodeJS. Maintenant (en 2017 — note de l'éditeur), dans les nouveaux développements, nous utilisons la version 7 de NodeJS. Il n'y a pas de problème à utiliser les nouvelles versions des bibliothèques dans les nouveaux composants.
Si nécessaire, nous pouvons procéder à un refactoring et mettre à jour la version de NodeJS pour le service des notifications Push.
Et si nous pouvons maintenir la compatibilité au niveau de l'API, nous pourrions le remplacer dans d'autres projets qui ont été utilisés auparavant.
Que faut-il pour ajouter Docker ? Nous ajoutons à notre référentiel un Dockerfile qui décrit les dépendances nécessaires. Dans cet exemple, les composants sont répartis logiquement. C'est le minimum requis pour un développeur backend.
Lors de la création d'un nouveau projet, nous créons un Dockerfile, décrivons l'écosystème nécessaire (Python, Ruby, NodeJS). Dans docker-compose, nous décrivons la dépendance requise — la base de données. Nous précisons qu'il faut une base de telle version, avec les données stockées à tel endroit.
Nous utilisons un troisième conteneur séparé avec nginx pour servir les fichiers statiques. La possibilité de télécharger des images est prévue. Le backend les place dans un volume préalablement préparé, qui est également monté dans le conteneur avec nginx, qui sert les fichiers statiques.
Pour stocker la configuration de nginx et mysql, nous avons ajouté un dossier Docker dans lequel nous conservons les configurations nécessaires. Lorsque le développeur fait un git clone du dépôt sur sa machine, il obtient déjà un projet prêt pour le développement local. Il n'y a pas de question concernant le port à utiliser ou les paramètres à appliquer.
Ensuite, nous avons plusieurs composants : admin, inform-API, notifications push.
Pour lancer tout cela, nous avons créé un autre dépôt que nous avons nommé dockerized-app. Actuellement, nous utilisons plusieurs dépôts pour chaque composant. Ils se distinguent simplement par leur logique — dans GitLab, cela apparaît comme un dossier, et sur la machine du développeur comme un dossier pour un projet spécifique. À un niveau inférieur se trouvent les composants qui seront regroupés.
Voici un exemple du contenu de dockerized-app. Nous y plaçons également le répertoire Docker, où nous stockons les configurations nécessaires pour l'interaction de tous les composants. Il y a un README.md qui décrit brièvement comment démarrer le projet.
Ici, nous avons appliqué deux fichiers docker-compose. Cela a été fait pour avoir la possibilité de démarrer de manière progressive. Lorsque le développeur travaille avec le cœur, il n'a pas besoin de notifications push, il lance simplement le fichier docker-compose, ce qui permet d'économiser des ressources.
Si une intégration avec les notifications push est nécessaire, alors docker-compose.yaml et docker-compose-push.yaml sont lancés.
Comme docker-compose.yaml et docker-compose-push.yaml se trouvent dans le même dossier, un réseau virtuel unique est automatiquement créé.
Description des composants. C'est un fichier plus détaillé qui gère l'assemblage des composants. Qu'est-ce qui est notable ici ? Nous introduisons le composant load balancer.
C'est une image Docker prête, qui exécute nginx et une application qui écoute le socket Docker. Il régénère dynamiquement la configuration de nginx à mesure que les conteneurs sont ajoutés ou supprimés. L'interaction avec les composants est répartie sur des noms de domaine de troisième niveau.
Pour l'environnement de développement, nous utilisons le domaine .dev — api.informer.dev. Les applications avec le domaine .dev sont accessibles sur la machine locale du développeur.
Ensuite, les configurations sont transmises à chaque projet et tous les projets sont lancés ensemble simultanément.
Si nous devions l'illustrer graphiquement, le client serait notre navigateur ou un outil à partir duquel nous faisons des requêtes au load balancer.
Le load balancer détermine, en fonction du nom de domaine, à quel conteneur il doit s'adresser.
Cela peut être nginx, qui sert les fichiers JS de l'interface d'administration. Cela peut être nginx, qui sert l'API ou des fichiers statiques, qui sont servis par nginx sous forme de téléchargement d'images.
Le schéma montre que les conteneurs sont regroupés dans un réseau virtuel et sont cachés derrière un proxy.
Sur la machine du développeur, on peut accéder au conteneur en connaissant l'IP, mais nous ne l'appliquons pas vraiment. Il n'y a pratiquement jamais besoin d'accès direct.
Quel exemple regarder pour dockeriser votre application ? À mon avis, un bon exemple est l'image Docker officielle pour MySQL.
C'est assez complexe. Il y a de nombreuses versions. Mais sa fonctionnalité permet de répondre à de nombreux besoins qui peuvent survenir lors du développement ultérieur. Si vous passez du temps à comprendre comment tout cela interagit, je pense qu'il n'y aura pas de problèmes avec l'implémentation autonome.
Sur hub.docker.com, il y a généralement des liens vers github.com, où se trouvent les données brutes pour assembler l'image par vous-même.
Ensuite, dans ce dépôt, il y a un script docker-endpoint.sh qui est responsable de l'initialisation initiale et de la gestion du lancement de l'application.
Cet exemple inclut également une option de configuration via des variables d'environnement. En définissant une variable d'environnement lors du lancement d'un conteneur unique ou via docker-compose, nous pouvons indiquer que nous devons définir un mot de passe vide pour docker ou un autre que nous souhaitons pour root sur MySQL.
Il est possible de créer un mot de passe aléatoire. Nous indiquons qu'un utilisateur est nécessaire, qu'il faut définir un mot de passe pour cet utilisateur et qu'une base de données doit être créée.
Dans nos projets, nous avons unifié un peu le Dockerfile qui est responsable de l'initialisation. Nous l'avons adapté à nos besoins pour simplement étendre les droits de l'utilisateur que l'application utilise. Cela a permis de créer facilement une base de données depuis la console de l'application. Dans les applications Ruby, il y a des commandes pour créer, modifier et supprimer des bases de données.
Cet exemple montre à quoi ressemble une version spécifique de MySQL sur github.com. Le Dockerfile peut être ouvert et consulté pour voir comment l'installation se déroule.
Le script docker-endpoint.sh est responsable du point d'entrée. Lors de l'initialisation initiale, certaines actions de préparation sont requises, et toutes ces actions sont mises en œuvre dans le script d'initialisation.
Passons à la deuxième partie.
Pour le stockage des codes sources, nous sommes passés à GitLab. C'est un système assez puissant qui dispose d'une interface visuelle.
Un des composants de GitLab est GitLab CI. Cela permet de décrire une suite de commandes qui seront utilisées pour organiser un système de livraison de code ou pour exécuter des tests automatisés.
Présentation sur GitLab CI 2 — présentation du Ruby Russia club — assez détaillée et susceptible de vous intéresser.
Maintenant, nous allons examiner ce qui est nécessaire pour activer GitLab CI. Pour démarrer GitLab CI, il suffit de placer un fichier .gitlab-ci.yml à la racine du projet.
Ici, nous décrivons ce que nous voulons exécuter en termes de séquence d'états comme des tests, des déploiements.
Nous exécutons des scripts qui déclenchent directement la construction de notre application avec docker-compose. C'est un exemple de backend.
Ensuite, nous indiquons qu'il est nécessaire d'exécuter les migrations pour modifier la base de données et de réaliser les tests.
Si les scripts s'exécutent correctement et ne renvoient pas de code d'erreur, le système passe à la deuxième phase du déploiement.
La phase de déploiement est actuellement mise en œuvre pour staging. Nous n'avons pas organisé de redémarrage sans interruption.
Nous éteignons tous les conteneurs de force, puis nous relançons tous les conteneurs, construits lors de la première étape de test.
Nous exécutons déjà pour l'environnement variable actuel les migrations de bases de données qui ont été écrites par les développeurs.
Il y a une note stipulant que cela ne doit être appliqué que pour la branche master.
Lors de la modification d'autres branches, cela ne s'exécute pas.
Il est possible d'organiser des déploiements par branches.
Pour organiser cela davantage, nous devons installer GitLab Runner.
C'est un utilitaire écrit en Golang. Il s'agit d'un fichier unique, comme c'est courant dans le monde de Golang, et il n'y a pas besoin de dépendances.
Lors du lancement, nous enregistrons le GitLab Runner.
Nous obtenons la clé dans l'interface Web de GitLab.
Ensuite, nous exécutons la commande d'initialisation dans la ligne de commande.
Nous configurons le GitLab Runner en mode dialogue (Shell, Docker, VirtualBox, SSH).
Le code sur GitLab Runner s'exécutera à chaque commit en fonction de la configuration de .gitlab-ci.yml.
Voici à quoi cela ressemble visuellement dans GitLab via l'interface web. Une fois que nous avons connecté GitLab CI, un drapeau apparaît, indiquant l'état actuel du build.
Nous voyons qu'il y a eu un commit il y a 4 minutes, passant tous les tests sans problèmes.
Nous pouvons examiner les builds plus en détail. Ici, nous voyons que deux états ont déjà été atteints : l'état de test et l'état de déploiement sur staging.
Si nous cliquons sur un build spécifique, nous y trouverons la sortie de la console des commandes qui ont été exécutées en suivant le fichier .gitlab-ci.yml.
Voici l'historique de notre produit. Nous voyons qu'il y a eu des tentatives réussies. Lorsque les tests échouent, la procédure ne passe pas à l'étape suivante et le code sur staging n'est pas mis à jour.
Quelles tâches avons-nous dû résoudre sur staging lors de l'intégration de Docker ? Notre système est composé de plusieurs composants et nous avons eu besoin de redémarrer uniquement les parties mises à jour dans le dépôt, plutôt que l'ensemble du système.
Pour cela, nous avons dû organiser le tout dans des dossiers séparés.
Une fois cela fait, nous avons rencontré le problème que Docker-compose crée pour chaque dossier son propre espace réseau, ne voyant pas les composants voisins.
Pour contourner cela, nous avons créé un réseau dans Docker manuellement. Dans Docker-compose, nous avons spécifié d'utiliser ce réseau pour ce projet.
Ainsi, chaque composant démarrant avec ce réseau peut voir les composants d'autres parties du système.
Le prochain problème est la séparation de staging entre plusieurs projets.
Pour que tout soit bien organisé et le plus proche possible de la production, il est bon d'utiliser le port 80 ou 443, qui sont largement utilisés dans le WEB.
Comment avons-nous résolu cela ? Nous avons attribué un GitLab Runner à tous les grands projets.
GitLab permet de lancer plusieurs GitLab Runners distribués qui prendront les tâches de manière aléatoire et les exécuteront.
Pour éviter le chaos, nous avons limité notre groupe de projets à un seul GitLab Runner, qui gère nos volumes sans problème.
Nous avons déplacé nginx-proxy dans un script de démarrage séparé, dans lequel nous avons défini les réseaux de tous les projets.
Notre projet a un réseau, tandis que le répartiteur en a plusieurs nommés d'après les projets, pouvant proxy par les noms de domaine.
Nous recevons des requêtes sur le port 80 du domaine, qui sont gérées par un groupe de conteneurs dédiés à ce domaine.
Quels autres problèmes y a-t-il eu ? C'est que par défaut tous les conteneurs s'exécutent sous l'utilisateur root. Ce root n'est pas le même root que celui de l'hôte du système.
Cependant, si l'on entre dans le conteneur, on devient root et le fichier que nous créons dans ce conteneur obtient des droits root.
Si un développeur est entré dans le conteneur et a exécuté certaines commandes qui génèrent des fichiers, puis qu'il sort du conteneur, il se retrouve avec un fichier dans son répertoire de travail auquel il n'a pas accès.
Comment peut-on résoudre cela ? On peut ajouter des utilisateurs qui seront dans le conteneur.
Quels problèmes sont survenus lorsque nous avons ajouté un utilisateur ?
En créant un utilisateur, il arrive souvent que l'ID du groupe (UID) et l'ID de l'utilisateur (GID) ne coïncident pas.
Pour résoudre ce problème, nous utilisons dans le conteneur des utilisateurs avec l'ID 1000.
Dans notre cas, cela correspond au fait que presque tous les développeurs utilisent le système d'exploitation Ubuntu. Et sur Ubuntu, le premier utilisateur a l'ID 1000.
Quels sont nos projets ?
Relire la documentation sur Docker. Le projet est en développement actif, la documentation change. Les informations obtenues il y a deux ou trois mois commencent déjà à devenir obsolètes.
Certaines des problèmes que nous avons résolus sont probablement déjà réglés par les moyens standards.
Nous avons vraiment envie d'aller plus loin et de passer directement à l'orchestration.
Un des exemples est le mécanisme intégré à Docker appelé Docker Swarm, qui est fourni par défaut. Nous avons envie de lancer quelque chose en production basé sur la technologie Docker Swarm.
La génération de conteneurs complique le travail avec les logs. Actuellement, les logs sont isolés. Ils sont éparpillés à travers les conteneurs. L'une des tâches est de rendre l'accès aux logs plus facile via une interface web.
Source : habr.com
