‫Dans cette section, nous avons beaucoup traité de Swarm. Swarm, Stacks and Secrets sont un peu comme une
‫trilogie de fonctionnalités impressionnantes qui peuvent vraiment nous faciliter la tâche en production.
‫Je veux vous montrer à quoi ça pourrait ressembler si vous preniez réellement vos fichiers Compose, que vous les
‫organisiez de plusieurs manières,
‫et c’est ce que j’appelle vivre le rêve.
‫Il s'avère que vous pouvez réellement utiliser un seul fichier pour faire beaucoup de choses, mais parfois, votre
‫complexité augmente et vous aurez besoin de plusieurs fichiers Compose.
‫Je veux juste traverser très vite.
‫Vous n'êtes pas obligé de le faire vous-même si vous ne le souhaitez pas. Je vais simplement vous montrer un exemple de
‫la manière dont ces fichiers Compose pourraient fonctionner ensemble pour créer votre environnement au fur et à mesure.
‫Dans ce scénario, nous allons utiliser Docker Composer pour notre environnement de développement local.
‫Nous allons utiliser un menu fixe pour la configuration et le fichier de notre environnement CI afin de réaliser des tests d'intégration.
‫Ensuite, lorsque nous sommes en production, nous allons utiliser ces fichiers pour le déploiement de la pile de docker
‫afin de déployer réellement l'environnement de production avec une pile. Donc, je suis sur mon ordinateur local et nous allons utiliser l'exemple
‫précédent du scénario Drupal, avec un serveur de base de données et une interface Web.
‫Nous avons le fichier Docker que nous avons utilisé lors de nos précédentes missions. Nous reconstruisons une configuration drupal personnalisée,
‫mais simple, avec un modèle.
‫Ensuite, nous allons avoir ce fichier de composition par défaut.
‫Cela s'appelle une dérogation,
‫ce que nous sommes sur le point de faire. Un remplacement est le lieu où se trouve le fichier
‫Docker Compose standard et définit les valeurs par défaut identiques dans tous les environnements.
‫Ensuite, j'ai ce fichier de remplacement qui, par défaut, Docker Compose, s’il est nommé exactement
‫ce nom, docker compose. passer outre. yml, cela sera automatiquement ajouté à chaque fois que je compose un docker.
‫Vous verrez que dans ce scénario, nous supposons le développement local car nous souhaitons réellement que les commandes à saisie manuelle
‫que nous allons taper soient les plus faciles localement.
‫Normalement, dans votre environnement CI, tout est automatisé, nous ne nous soucions donc pas de savoir si ces commandes sont
‫un peu plus longues.
‫Mais nous voulons vraiment localement, c'est le docker facile à composer.
‫La chose intéressante est que Docker Compose lira ce fichier automatiquement
‫et l’appliquera par-dessus ou remplacera tous les paramètres du fichier Docker Compose yml.
‫Et donc ici, remarquez
‫que je n'ai pas le nom de l'image, car c'est déjà spécifié ici. Dans ce fichier de substitution, je remplace
‫en indiquant que je veux construire l'image localement en utilisant le fichier Docker dans ce répertoire actuel.
‫Je veux créer un port sur 8080 pour le développement local. Et je suis en train de monter quelques volumes, et vous remarquerez même que je vous ai
‫donné ici un exemple de montage avec bind, où je pourrais faire un thème personnalisé. Et je veux monter mon thème sur mon hôte
‫dans le conteneur comme nous l'avons fait dans les sections précédentes, afin que je puisse le changer localement
‫et le voir immédiatement sur le serveur.
‫Et au fait, pour cet exemple, je ne sais pas vraiment comment développer des thèmes dans Drupal.
‫Je ne suis pas tout à fait sûr que si je change un fichier, celui-ci sera automatiquement reflété.
‫Je voulais juste montrer un exemple de la façon dont vous développez sur le Web. C'est généralement comme cela que vous le
‫feriez sans avoir à arrêter et à démarrer Compose à chaque fois. En bas, sous postgres, nous avons la variable
‫d'environnement et les paramètres Secret comme auparavant. Nous avons les volumes définis, et vous verrez en
‫bas, j'ai
‫en fait le secret basé sur fichier, car lorsque nous faisons du développement local, nous devons utiliser le secret
‫basé sur fichier.
‫Les choses deviennent un peu intéressantes quand je regarde cette prod ou les fichiers de test. La façon dont cela fonctionnera
‫est, rappelez-vous que le. passer outre. yml est automatiquement récupéré par la ligne
‫de commande Docker Compose. En prod ou
‫test, je vais devoir les spécifier manuellement.
‫Donc, pour le test, nous allons devoir utiliser la commande -f.
‫Si vous vous souvenez des sections précédentes, le -f correspond à la composition d'un menu fixe que vous souhaitez
‫spécifier un fichier personnalisé. Je vais vous montrer que dans une minute.
‫Ensuite, en production, étant donné que la ligne de commande Docker Compose ne sera
‫pas réellement installée sur un serveur de production, nous allons utiliser une commande docker compose config.
‫La commande config va réellement produire une sortie en regroupant ou en combinant la sortie de plusieurs
‫fichiers de configuration.
‫Donc ce sera vraiment cool.
‫Vraiment rapide, le fichier de test n'a que le drupal et le postgres.
‫Imaginez s’il s’agissait de votre solution Jenkins CI ou Codeship CI, où je souhaite que l’image soit générée à chaque fois
‫que je valide mon code, et que je souhaite l’appeler ainsi, et que je souhaite l’utiliser sur ce
‫port à des fins de test. Ensuite, je vais utiliser un faux mot de passe. Mais je n'ai pas besoin de définir les volumes, car
‫je ne vais pas essayer de conserver les données de volume nommé car, encore une fois, il ne s'agit que d'une plate-forme CI.
‫Dès qu'il réussit ou échoue, il se débarrasse de tout.
‫Ensuite, dans ce scénario, vous constaterez peut-être que j'ai en fait un exemple de scénario de
‫données dans lequel, dans votre solution CI, vous disposez simplement de bases de données provenant d'un référentiel Git
‫personnalisé ou peut-être d'un téléchargement FTP. Ou quelque chose se passe pendant l'initialisation de votre
‫CI où il télécharge réellement un fichier de base de données. Et au lieu de devoir créer notre base de données chaque
‫fois que nous effectuons des tests de CI, nous montons simplement ce répertoire de données exemple dans l'emplacement où nos données postgres sont supposées
‫se trouver.
‫Et ainsi, nous pourrions garantir que nous disposions des mêmes échantillons de données à chaque fois que nous effectuons un test de CI.
‫Je ne vais pas aller plus loin. Je voulais simplement montrer que c'était peut-être la raison pour
‫laquelle ce fichier pour CI serait différent.
‫Ensuite, en production, nous avons toutes nos préoccupations de production normales. Nous spécifions des volumes pour
‫nos données spécifiques. Nous spécifions notre secret. Et remarquez en bas, nous avons le secret externe.
‫Parce que nous allons déjà avoir mis le secret dedans via la ligne de commande comme nous l'avions fait
‫dans l'assignation précédente.
‫Le point ici est que ces trois configurations sont différentes d'une manière ou d'une autre, mais
‫elles se rapportent toutes à la configuration principale, ou à la configuration de base, qui définit simplement les deux services et leurs images.
‫Vous pouvez voir ici. Voici un rappel de ce à quoi il ressemble.
‫Quittons ceci et exécutons quelques commandes.
‫Si je regarde dans ce répertoire, vous verrez que j'ai le fichier de base, puis les trois fichiers de remplacement.
‫Encore une fois, rappelez-vous que la dérogation. yml est la valeur par défaut.
‫Si je compose un docker, il utilisera le docker-compose. yml en premier, et ensuite il
‫superposera le remplacement. yml un sur le dessus. Je veux mettre un -d afin
‫que nous puissions jeter un rapide coup d'œil après le début. Je vais faire un docker inspecter l'image drupal.
‫Et ce que je voulais vous montrer était ici, il contient toutes les montures énumérées.
‫Nous savons donc qu’il a fallu le fichier de remplacement, car c’est là que nous avons défini tous
‫ces montages.
‫Nous savons donc que cela a été pris en compte.
‫Évidemment, si elle ne prenait pas la première, elle ne saurait même pas quelles images
‫utiliser, elle se plaint donc et nous dit que le fichier Compose est incomplet.
‫Celui-là a fonctionné.
‫Faisons une descente rapide.
‫Si nous devions exécuter la commande dont nous avions besoin pour notre solution CI,
‫nous devions nous assurer que Docker Compose était présent, installé et disponible pour pouvoir exécuter les
‫commandes de composition de docker. Ensuite, nous pouvons spécifier le -f, puis
‫l'ordre des f est le fichier de base qui doit toujours être en premier.
‫Alors docker compose yml, puis docker compose le test.
‫Si nous faisions cela avec un up à la fin et un -d, et ensuite j'allais inspecter le même Drupal, vous remarquerez qu'il
‫n'y a pas de monture de liaison.
‫Ils sont complètement absents car dans le fichier test, nous ne les avons pas spécifiés.
‫En fait, nous n’avions pas besoin de Drupal pour sauvegarder les informations, car elles allaient être jetées à la
‫fin de notre course à la CI.
‫Et puis troisième, nous avons la config de production.
‫La configuration de la production sera un peu différente.
‫Je vais frapper la flèche vers le haut, et puis ici je vais faire la prod. Au lieu d'une commande up, ce
‫que je veux faire ici est une config.
‫Si vous regardez rapidement l’aide fournie pour la configuration, celle-ci n’a que deux options et aucune d’elles
‫n’est vraiment pertinente dans cette situation.
‫Ce que nous voulons juste faire, c'est simplement lancer config par lui-même. Ce qu'il va réellement faire, c'est
‫examiner les deux fichiers et les regrouper dans un seul fichier Compose équivalent.
‫Donc, ce que nous pourrions faire ici est d’exécuter cette commande quelque part dans notre solution CI. Ensuite, transférez-le dans un
‫fichier, avec peut-être quelque chose comme ça. Ce fichier de sortie serait celui que nous utiliserions
‫officiellement en production pour créer ou mettre à jour notre pile.
‫Cependant, je tiens à faire une petite mise en garde ici.
‫Tout cela est relativement nouveau.
‫Nous savons que Secrets et Swarm Stacks sont relativement nouveaux.
‫Ils ont seulement deux mois.
‫À partir de cet enregistrement.
‫Il y a donc quelques aspérités.
‫Nous venons d'exécuter cette commande de configuration et vous remarquerez en fait que les secrets n'y étaient pas répertoriés.
‫C'est un bug actuellement.
‫En fait, je travaille avec l'équipe Docker pour voir si nous ne pouvons pas éliminer ce bogue.
‫Donc, au moment où vous lisez ceci, cela a peut-être déjà été corrigé.
‫Assurez-vous d'inspecter cette sortie de la ligne de configuration avant de
‫déployer en production.
‫Deuxièmement, l'option Compose Extends, que je n'ai pas abordée ici, est un autre moyen de remplacer ces
‫fichiers Compose dans lesquels vous utilisez le fichier de remplacement et définissez une section
‫expand.
‫C'est un peu plus déclaratif, donc c'est plus facile à comprendre. Je vais fournir un lien dans
‫les références de cette section. Sachez simplement que cette option Extends ne fonctionne pas encore dans les piles Swarms.
‫Je n'en ai pas parlé ici parce que cela ne vous donne pas vraiment le cycle de vie complet des applications que
‫nous espérions, mais je m'attends vraiment à ce qu'ils fassent quelque chose à ce sujet.
‫Par exemple, ajoutez-le à Swarm ou créez un meilleur flux de travail. Parce que c’est vraiment l’idée que nous essayons
‫d’obtenir avec tous ces outils, c’est d’avoir un cycle de vie complet et aisé, du développement au test, en
‫passant par la production, avec le même ensemble de configurations, dans le même ensemble d’images. .
‫J'espère que cela vous a amené à réfléchir à la manière dont vous pourriez créer vos applications de cette manière et
‫à la possibilité d'étendre vos propres fichiers Compose pour des scénarios complexes.
‫Parce que rien ne me fait sourire plus vite que lorsque je vois quelqu'un exécuter une commande d'une ligne
‫pour exécuter une tâche qui nécessitait auparavant l'exécution de plusieurs scripts.