Je propose de lire la transcription du rapport d'Alexander Sigachev d'Inventos "Processus de développement et de test avec Docker + Gitlab CI"
Ceux qui commencent tout juste à implémenter le processus de développement et de test basé sur Docker + Gitlab CI posent souvent des questions basiques. Où commencer? Comment s'organiser ? Comment tester ?
Ce rapport est bon car il parle de manière structurée du processus de développement et de test à l'aide de Docker et de Gitlab CI. Le rapport lui-même date de 2017. Je pense qu'à partir de ce rapport, vous pouvez apprendre les bases, la méthodologie, l'idée, l'expérience d'utilisation.
Qui s'en soucie, s'il vous plaît sous le chat.
Je m'appelle Alexandre Sigatchev. Je travaille pour Inventos. Je vais vous parler de mon expérience d'utilisation de Docker et de la façon dont nous l'implémentons progressivement sur des projets dans l'entreprise.
Sujet de présentation : Processus de développement avec Docker et Gitlab CI.
Ceci est mon deuxième exposé sur Docker. Au moment du premier rapport, nous n'utilisions Docker en développement que sur les machines des développeurs. Le nombre d'employés qui utilisaient Docker était d'environ 2-3 personnes. Petit à petit, l'expérience s'est accumulée et nous sommes allés un peu plus loin. Lien vers notre .
Qu'y aura-t-il dans ce rapport ? Nous partagerons notre expérience sur le râteau que nous avons collecté, les problèmes que nous avons résolus. Pas partout c'était beau, mais ça permettait d'avancer.
Notre devise est : amarrer tout ce qui nous tombe sous la main.
Quels problèmes résolvons-nous ?
Lorsqu'il y a plusieurs équipes dans une entreprise, le programmeur est une ressource partagée. Il y a des étapes où un programmeur est retiré d'un projet et donné pendant un certain temps à un autre projet.
Pour que le programmeur comprenne rapidement, il doit télécharger le code source du projet et lancer l'environnement dès que possible, ce qui lui permettra d'aller plus loin dans la résolution des problèmes de ce projet.
Habituellement, si vous partez de zéro, il y a peu de documentation dans le projet. Les informations sur la configuration ne sont disponibles que pour les anciens. Les salariés installent eux-mêmes leur lieu de travail en un ou deux jours. Pour accélérer cela, nous avons utilisé Docker.
La raison suivante est la standardisation des paramètres dans le développement. D'après mon expérience, les développeurs prennent toujours l'initiative. Tous les cinq cas, un domaine personnalisé est entré, par exemple, vasya.dev. Assis à côté de lui se trouve son voisin Petya, dont le domaine est petya.dev. Ils développent un site Web 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 à entrer dans des configurations, un conflit d'environnement de développement survient et le chemin du site est réécrit.
La même chose se produit avec les paramètres de la base de données. Quelqu'un ne se soucie pas de la sécurité et travaille avec un mot de passe root vide. Lors de l'installation, MySQL a demandé un mot de passe à quelqu'un et le mot de passe s'est avéré être 123. Il arrive souvent que la configuration de la base de données change constamment en fonction de la validation du développeur. Quelqu'un a corrigé, quelqu'un n'a pas corrigé la config. Il y avait des astuces lorsque nous avons sorti une sorte de configuration de test dans .gitignore et chaque développeur devait installer la base de données. Cela a rendu difficile le démarrage. Il faut, entre autres, se souvenir de la base de données. La base de données doit être initialisée, un mot de passe doit être entré, un utilisateur doit être enregistré, une table doit être créée, etc.
Un autre problème est les différentes versions des bibliothèques. Il arrive souvent qu'un développeur travaille avec différents projets. Il y a un projet Legacy qui a commencé il y a cinq ans (à partir de 2017 - ndlr). Au moment du lancement, nous avons commencé avec MySQL 5.5. Il existe également des projets modernes où nous essayons d'implémenter des versions plus modernes de MySQL, par exemple, 5.7 ou plus anciennes (en 2017 - ndlr)
Quiconque travaille avec MySQL sait que ces bibliothèques apportent des dépendances avec elles. Il est plutôt problématique de faire fonctionner 2 bases ensemble. Au moins, les anciens clients ont du mal à se connecter à la nouvelle base de données. Cela crée à son tour plusieurs problèmes.
Le problème suivant est que lorsqu'un développeur travaille sur une machine locale, il utilise des ressources locales, des fichiers locaux, de la RAM locale. Toute interaction au moment de développer une solution aux problèmes est réalisée dans le cadre du fait qu'elle fonctionne sur une seule machine. Un exemple est lorsque nous avons des serveurs principaux dans Production 3, et que le développeur enregistre les fichiers dans le répertoire racine et à partir de là, nginx prend les fichiers pour répondre à la demande. Lorsqu'un tel code passe en Production, il s'avère que le fichier est présent sur l'un des 3 serveurs.
La direction des microservices se développe maintenant. Lorsque nous divisons nos grandes applications en quelques petits composants qui interagissent les uns avec les autres. Cela vous permet de sélectionner des technologies pour une pile spécifique de tâches. Il vous permet également de partager le travail et les responsabilités entre les développeurs.
Frondend-developer, développant sur JS, n'a quasiment aucune influence sur Backend. Le développeur backend, à son tour, développe, dans notre cas, Ruby on Rails et n'interfère pas avec Frondend. L'interaction est effectuée à l'aide de l'API.
En prime, avec l'aide de Docker, nous avons pu recycler des ressources sur le Staging. Chaque projet, de par ses spécificités, nécessitait certains réglages. Physiquement, il fallait soit allouer un serveur virtuel et les configurer séparément, soit partager une sorte d'environnement variable et les projets pouvaient, selon la version des bibliothèques, s'influencer les uns les autres.
Outils. Qu'utilisons-nous ?
- Docker lui-même. Le Dockerfile décrit les dépendances d'une seule application.
- Docker-compose est un bundle qui regroupe quelques-unes de nos applications Docker.
- Nous utilisons GitLab pour stocker le code source.
- Nous utilisons GitLab-CI pour l'intégration du système.
Le rapport se compose de deux parties.
La première partie parlera de la façon dont Docker a été exécuté sur les machines des développeurs.
La deuxième partie expliquera comment interagir avec GitLab, comment nous exécutons des tests et comment nous déployons vers Staging.
Docker est une technologie qui permet (selon une approche déclarative) de décrire les composants nécessaires. Ceci est un exemple de Dockerfile. Ici, nous déclarons que nous héritons de l'image officielle Ruby:2.3.0 Docker. Il contient Ruby version 2.3 installé. Nous installons les bibliothèques de construction requises et NodeJS. Nous décrivons que nous créons un répertoire /app. Définissez le répertoire de l'application comme répertoire de travail. Dans ce répertoire, nous plaçons le minimum requis Gemfile et Gemfile.lock. Nous construisons ensuite les projets qui installent cette image de dépendance. Nous indiquons que le conteneur sera prêt à écouter sur le port externe 3000. La dernière commande est la commande qui lance directement notre application. Si nous exécutons la commande de démarrage du projet, l'application essaiera d'exécuter et d'exécuter la commande spécifiée.
Ceci est un exemple minimal de fichier docker-compose. Dans ce cas, nous montrons qu'il existe une connexion entre deux conteneurs. Ceci est directement dans le service de base de données et le service Web. Nos applications Web nécessitent dans la plupart des cas une sorte de base de données comme backend pour stocker les données. Puisque nous utilisons MySQL, l'exemple est avec MySQL - mais rien ne nous empêche d'utiliser une autre base de données (PostgreSQL, Redis).
Nous reprenons de la source officielle du hub Docker l'image de MySQL 5.7.14 sans modifications. Nous collectons l'image responsable de notre application Web à partir du répertoire actuel. Il collecte une image pour nous lors du premier lancement. Ensuite, il exécute la commande que nous exécutons ici. Si nous revenons en arrière, nous verrons que la commande de lancement via Puma a été définie. Puma est un service écrit en Ruby. Dans le second cas, on annule. Cette commande peut être arbitraire selon nos besoins ou nos tâches.
Nous décrivons également que nous devons transférer un port sur notre machine hôte développeur de 3000 à 3000 sur le port de conteneur. Cela se fait automatiquement à l'aide d'iptables et de son mécanisme, qui est directement intégré à Docker.
Le développeur peut également, comme auparavant, accéder à n'importe quelle adresse IP disponible, par exemple, 127.0.0.1 est l'adresse IP locale ou externe de la machine.
La dernière ligne indique que le conteneur Web dépend du conteneur db. Lorsque nous appelons le démarrage du conteneur Web, docker-compose démarre d'abord la base de données pour nous. Déjà au démarrage de la base de données (en fait - après le lancement du conteneur ! Cela ne garantit pas la disponibilité de la base de données) lancera l'application, notre backend.
Cela évite les erreurs lorsque la base de données n'est pas mise en place et économise des ressources lorsque nous arrêtons le conteneur de base de données, libérant ainsi des ressources pour d'autres projets.
Ce qui nous donne l'utilisation de la dockérisation de la base de données sur le projet. Nous fixons la version de MySQL pour tous les développeurs. Cela évite certaines erreurs qui peuvent survenir lorsque les versions divergent, lorsque la syntaxe, la configuration, les paramètres par défaut changent. Cela vous permet de spécifier un nom d'hôte commun pour la base de données, un login, un mot de passe. Nous nous éloignons du zoo de noms et de conflits dans les fichiers de configuration que nous avions auparavant.
Nous avons la possibilité d'utiliser une configuration plus optimale pour l'environnement de développement, qui sera différente de la configuration par défaut. MySQL est configuré par défaut pour les machines faibles et ses performances sont très médiocres.
Docker permet d'utiliser l'interpréteur Python, Ruby, NodeJS, PHP de la version souhaitée. Nous nous débarrassons de la nécessité d'utiliser une sorte de gestionnaire de version. Auparavant, Ruby utilisait un package rpm qui permettait de changer de version en fonction du projet. Il permet également, grâce au conteneur Docker, de migrer en douceur le code et de le versionner avec les dépendances. Nous n'avons aucun problème à comprendre la version de l'interpréteur et du code. Pour mettre à jour la version, abaissez l'ancien conteneur et soulevez le nouveau conteneur. En cas de problème, nous pouvons abaisser le nouveau conteneur, relever l'ancien conteneur.
Une fois l'image créée, les conteneurs en développement et en production seront les mêmes. Cela est particulièrement vrai pour les grandes installations.
Sur Frontend, nous utilisons JavaScipt et NodeJS.
Nous avons maintenant le dernier projet sur ReacJS. Le développeur a tout exécuté dans le conteneur et développé en utilisant le rechargement à chaud.
Ensuite, la tâche d'assemblage JavaScipt est lancée et le code compilé en statique est fourni via nginx en économisant des ressources.
J'ai donné ici le schéma de notre dernier projet.
Quelles tâches ont été résolues ? Nous avions besoin de construire un système avec lequel les appareils mobiles interagissent. Ils reçoivent des données. Une possibilité est d'envoyer des notifications push à cet appareil.
Qu'avons-nous fait pour cela ?
Nous avons réparti dans l'application des composants tels que : la partie admin sur JS, le backend, qui fonctionne via l'interface REST sous Ruby on Rails. Le backend interagit avec la base de données. Le résultat généré est remis au client. Le panneau d'administration interagit avec le backend et la base de données via l'interface REST.
Nous avions également besoin d'envoyer des notifications push. Avant cela, nous avions un projet qui implémentait un mécanisme chargé de fournir des notifications aux plateformes mobiles.
Nous avons développé le schéma suivant : un opérateur du navigateur interagit avec le panneau d'administration, le panneau d'administration interagit avec le backend, la tâche consiste à envoyer des notifications Push.
Les notifications push interagissent avec un autre composant implémenté dans NodeJS.
Des files d'attente sont construites puis des notifications sont envoyées en fonction de leur mécanisme.
Deux bases de données sont dessinées ici. Pour le moment, avec l'aide de Docker, nous utilisons 2 bases de données indépendantes qui ne sont en aucun cas liées l'une à l'autre. De plus, ils ont un réseau virtuel commun et les données physiques sont stockées dans différents répertoires sur la machine du développeur.
Le même mais en nombre. C'est là que la réutilisation du code est importante.
Si précédemment nous parlions de réutiliser du code sous forme de bibliothèques, alors dans cet exemple, notre service qui répond aux notifications Push est réutilisé comme un serveur complet. Il fournit une API. Et notre nouveau développement interagit déjà avec lui.
A cette époque, nous utilisions la version 4 de NodeJS. Maintenant (en 2017 - ndlr) dans les développements récents nous utilisons la version 7 de NodeJS. Il n'y a aucun problème dans les nouveaux composants pour impliquer de nouvelles versions de bibliothèques.
Si nécessaire, vous pouvez refactoriser et augmenter la version de NodeJS à partir du service de notification Push.
Et si nous pouvons maintenir la compatibilité de l'API, il sera alors possible de la remplacer par d'autres projets précédemment utilisés.
De quoi avez-vous besoin pour ajouter Docker ? Nous ajoutons un Dockerfile à notre référentiel, qui décrit les dépendances nécessaires. Dans cet exemple, les composants sont décomposés logiquement. C'est l'ensemble minimum d'un développeur backend.
Lors de la création d'un nouveau projet, nous créons un Dockerfile, décrivant l'écosystème souhaité (Python, Ruby, NodeJS). Dans docker-compose, il décrit la dépendance nécessaire - la base de données. Nous décrivons que nous avons besoin d'une base de données de telle ou telle version, stocker des données ici et là.
Nous utilisons un troisième conteneur séparé avec nginx pour servir statique. Il est possible de télécharger des images. Le backend les place dans un volume pré-préparé, qui est également monté dans un conteneur avec nginx, ce qui donne le statique.
Pour stocker la configuration nginx, mysql, nous avons ajouté un dossier Docker dans lequel nous stockons les configurations nécessaires. Lorsqu'un développeur fait un clone git d'un référentiel sur sa machine, il a déjà un projet prêt pour le développement local. Il n'y a aucun doute sur le port ou les paramètres à appliquer.
Ensuite, nous avons plusieurs composants : admin, inform-API, notifications push.
Afin de démarrer tout cela, nous avons créé un autre référentiel, que nous avons appelé dockerized-app. Pour le moment, nous utilisons plusieurs référentiels avant chaque composant. Ils sont juste logiquement différents - dans GitLab, cela ressemble à un dossier, mais sur la machine du développeur, un dossier pour un projet spécifique. Un niveau plus bas sont les composants qui seront combinés.
Ceci est un exemple du contenu de dockerized-app. Nous apportons également ici le répertoire Docker, dans lequel nous remplissons les configurations nécessaires aux interactions de tous les composants. Il existe un fichier README.md qui décrit brièvement comment exécuter le projet.
Ici, nous avons appliqué deux fichiers docker-compose. Ceci est fait afin de pouvoir exécuter par étapes. Lorsqu'un développeur travaille avec le noyau, il n'a pas besoin de notifications push, il lance simplement un fichier docker-compose et, en conséquence, la ressource est enregistrée.
S'il est nécessaire d'intégrer les notifications push, alors docker-compose.yaml et docker-compose-push.yaml sont lancés.
Étant donné que docker-compose.yaml et docker-compose-push.yaml se trouvent dans un dossier, un seul réseau virtuel est automatiquement créé.
Descriptif des composants. Il s'agit d'un fichier plus avancé qui est responsable de la collecte des composants. Qu'est-ce qui est remarquable ici ? Ici, nous introduisons le composant équilibreur.
Il s'agit d'une image Docker prête à l'emploi qui exécute nginx et une application qui écoute sur le socket Docker. Dynamique, au fur et à mesure que les conteneurs sont activés et désactivés, il régénère la configuration nginx. Nous répartissons la gestion des composants par 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 un domaine .dev sont disponibles sur la machine locale du développeur.
De plus, les configurations sont transférées à chaque projet et tous les projets sont lancés ensemble en même temps.
Graphiquement, il s'avère que le client est notre navigateur ou un outil avec lequel nous faisons des demandes à l'équilibreur.
L'équilibreur de nom de domaine détermine le conteneur à contacter.
Il peut s'agir de nginx, ce qui donne à l'administrateur JS. Cela peut être nginx, qui donne l'API, ou des fichiers statiques, qui sont donnés à nginx sous la forme de téléchargements d'images.
Le diagramme montre que les conteneurs sont connectés par un réseau virtuel et cachés derrière un proxy.
Sur la machine du développeur, vous pouvez accéder au conteneur en connaissant l'IP, mais en principe nous ne l'utilisons pas. Il n'y a pratiquement pas 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 difficile. Il existe de nombreuses versions. Mais sa fonctionnalité vous permet de couvrir de nombreux besoins qui peuvent survenir au cours du processus de développement ultérieur. Si vous passez du temps et comprenez comment tout cela interagit, alors je pense que vous n'aurez aucun problème d'auto-implémentation.
Hub.docker.com contient généralement des liens vers github.com, qui contient directement des données brutes à partir desquelles vous pouvez créer vous-même l'image.
Plus loin dans ce référentiel, il y a un script docker-endpoint.sh, qui est responsable de l'initialisation initiale et du traitement ultérieur du lancement de l'application.
Dans cet exemple également, il est possible de configurer à l'aide de variables d'environnement. En définissant une variable d'environnement lors de l'exécution d'un seul conteneur ou via docker-compose, nous pouvons dire que nous devons définir un mot de passe vide pour que docker root sur MySQL ou tout ce que nous voulons.
Il existe une option pour créer un mot de passe aléatoire. Nous disons que nous avons besoin d'un utilisateur, nous devons définir un mot de passe pour l'utilisateur et nous devons créer une base de données.
Dans nos projets, nous avons légèrement unifié le Dockerfile, qui est responsable de l'initialisation. Là, nous l'avons corrigé selon nos besoins pour en faire juste une extension des droits d'utilisateur que l'application utilise. Cela nous a permis de créer simplement une base de données à partir de la console de l'application par la suite. Les applications Ruby ont une commande pour créer, modifier et supprimer des bases de données.
Voici un exemple de ce à quoi ressemble une version spécifique de MySQL sur github.com. Vous pouvez ouvrir le Dockerfile et voir comment l'installation s'y déroule.
docker-endpoint.sh est le script responsable du point d'entrée. Lors de l'initialisation initiale, certaines étapes de préparation sont nécessaires et toutes ces actions sont effectuées uniquement dans le script d'initialisation.
Passons à la deuxième partie.
Pour stocker les codes sources, nous sommes passés à gitlab. C'est un système assez puissant qui a une interface visuelle.
L'un des composants de Gitlab est Gitlab CI. Il vous permet de décrire une séquence de commandes qui seront ensuite utilisées pour organiser un système de livraison de code ou exécuter des tests automatiques.
Discussion Gitlab CI 2 - rapport du club Ruby Russia - assez détaillé et peut-être que cela vous intéressera.
Nous allons maintenant examiner ce qui est nécessaire pour activer Gitlab CI. Pour lancer Gitlab CI, il suffit de mettre le fichier .gitlab-ci.yml à la racine du projet.
Ici, nous décrivons que nous voulons exécuter une séquence d'états comme un test, déployer.
Nous exécutons des scripts qui appellent directement docker-compose pour construire notre application. Ceci est juste un exemple de backend.
Ensuite, on dit qu'il faut faire des migrations pour changer de base de données et faire des tests.
Si les scripts sont exécutés correctement et ne renvoient pas de code d'erreur, le système passe à la deuxième étape du déploiement.
L'étape de déploiement est actuellement implémentée pour la mise en scène. Nous n'avons pas organisé de redémarrage sans interruption de service.
Nous éteignons de force tous les conteneurs, puis nous relevons tous les conteneurs, collectés lors de la première étape lors des tests.
Nous exécutons pour la variable d'environnement actuelle les migrations de base de données qui ont été écrites par les développeurs.
Il y a une note que cela ne s'applique qu'à la branche master.
Lors du changement d'autres branches n'est pas exécuté.
Il est possible d'organiser les déploiements par branches.
Pour mieux organiser cela, nous devons installer Gitlab Runner.
Cet utilitaire est écrit en Golang. Il s'agit d'un fichier unique, comme c'est courant dans le monde Golang, qui ne nécessite aucune dépendance.
Au démarrage, nous enregistrons le Gitlab Runner.
Nous obtenons la clé dans l'interface Web Gitlab.
Ensuite, nous appelons la commande d'initialisation sur la ligne de commande.
Configurer Gitlab Runner de manière interactive (Shell, Docker, VirtualBox, SSH)
Le code sur Gitlab Runner s'exécutera à chaque validation, en fonction du paramètre .gitlab-ci.yml.
À quoi cela ressemble visuellement dans Gitlab dans l'interface Web. Après avoir connecté GItlab CI, nous avons un drapeau qui montre l'état de la construction en ce moment.
Nous voyons qu'un commit a été fait il y a 4 minutes, qui a passé tous les tests et n'a causé aucun problème.
Nous pouvons regarder de plus près les constructions. Ici, nous voyons que deux états sont déjà passés. Statut de test et statut de déploiement sur le staging.
Si nous cliquons sur une version spécifique, il y aura une sortie de console des commandes qui ont été exécutées dans le processus selon .gitlab-ci.yml.
Voici à quoi ressemble l'historique de nos produits. On voit qu'il y a eu des tentatives réussies. Lorsque les tests sont soumis, il ne passe pas à l'étape suivante et le code de staging n'est pas mis à jour.
Quelles tâches avons-nous résolues sur la mise en scène lorsque nous avons implémenté docker ? Notre système est composé de composants et nous avons eu besoin de redémarrer, seulement une partie des composants qui ont été mis à jour dans le référentiel, et non l'ensemble du système.
Pour ce faire, nous avons dû tout casser dans des dossiers séparés.
Après avoir fait cela, nous avons eu un problème avec le fait que Docker-compose crée son propre espace réseau pour chaque papa et ne voit pas les composants du voisin.
Afin de se déplacer, nous avons créé manuellement le réseau dans Docker. Il a été écrit en Docker-compose que vous utilisez un tel réseau pour ce projet.
Ainsi, chaque composant qui commence par ce maillage voit des composants dans d'autres parties du système.
Le problème suivant consiste à répartir la mise en scène sur plusieurs projets.
Puisque pour que tout cela soit beau et le plus proche possible de la production, il est bon d'utiliser le port 80 ou 443, qui est utilisé partout sur le WEB.
Comment l'avons-nous résolu ? Nous avons assigné un Gitlab Runner à tous les projets majeurs.
Gitlab vous permet d'exécuter plusieurs Gitlab Runners distribués, qui prendront simplement toutes les tâches à tour de rôle de manière chaotique et les exécuteront.
Pour ne pas avoir de maison, nous avons limité le groupe de nos projets à un seul Gitlab Runner, qui gère sans problème nos volumes.
Nous avons déplacé nginx-proxy dans un script de démarrage séparé et ajouté des grilles pour tous les projets qu'il contient.
Notre projet a une grille, et l'équilibreur a plusieurs grilles par noms de projets. Il peut encore proxy par noms de domaine.
Nos demandes passent par le domaine sur le port 80 et sont résolues dans un groupe de conteneurs qui dessert ce domaine.
Quels autres problèmes y avait-il ? C'est ce que tous les conteneurs exécutent en tant que root par défaut. Il s'agit d'une racine différente de l'hôte racine du système.
Cependant, si vous entrez dans le conteneur, ce sera root et le fichier que nous créons dans ce conteneur obtient les droits root.
Si le développeur est entré dans le conteneur et y a effectué des commandes qui génèrent des fichiers, puis a quitté le conteneur, il a un fichier dans son répertoire de travail auquel il n'a pas accès.
Comment peut-il être résolu? Vous pouvez ajouter des utilisateurs qui seront dans le conteneur.
Quels problèmes sont survenus lorsque nous avons ajouté l'utilisateur ?
Lors de la création d'un utilisateur, nous n'avons souvent pas le même ID de groupe (UID) et ID d'utilisateur (GID).
Pour résoudre ce problème dans le conteneur, nous utilisons des utilisateurs avec l'ID 1000.
Dans notre cas, cela a coïncidé avec le fait que presque tous les développeurs utilisent le système d'exploitation Ubuntu. Et sur Ubuntu, le premier utilisateur a un ID de 1000.
Avons-nous des projets ?
Lisez la documentation Docker. Le projet se développe activement, la documentation évolue. Les données reçues il y a deux ou trois mois deviennent déjà lentement obsolètes.
Certains des problèmes que nous avons résolus sont très probablement déjà résolus par des moyens standard.
Du coup j'ai envie d'aller plus loin déjà pour aller directement à l'orchestration.
Un exemple est le mécanisme intégré de Docker appelé Docker Swarm, qui sort de la boîte. Je souhaite exécuter quelque chose en production basé sur la technologie Docker Swarm.
Les conteneurs de frai rendent peu pratique le travail avec des bûches. Maintenant, les journaux sont isolés. Ils sont dispersés dans des conteneurs. L'une des tâches consiste à faciliter l'accès aux journaux via l'interface Web.
Source: habr.com