‫Très bien, maintenant que nous avons passé en revue les secrets et les fonctionnalités, et comment
‫cela fonctionne, voyons quelques pratiques.
‫Donc, ce que j’ai ici est que j’ai mis en place notre essaim à 3 nœuds comme avant.
‫Je suis dans un exemple
‫de répertoire de secrets 1 que vous verrez dans le référentiel.
‫Et tout ce que j’ai trouvé, c’est un fichier texte. Et dans ce fichier texte, il n’ya qu’un simple nom d’utilisateur, pas même un
‫mot de passe.
‫Il y a deux façons de créer un secret à l'intérieur de Swarm.
‫L'un d'eux consiste à lui attribuer un fichier et un autre consiste à transmettre une valeur à la ligne de commande.
‫Alors, utilisons d'abord le fichier. secret de docker créer. Et puis je dois lui donner un nom dans la base de données secrète.
‫Et je l'appellerai utilisateur psql.
‫Ce n'est pas forcément le même nom que le fichier, évidemment. Mais je vais l'appeler comme ça.
‫Puis... Il rejette l'ID, comme pour d'autres objets. Et laisse en créer un autre. Mettons réellement le mot de
‫passe po
‫Et cette fois, nous allons en faire écho depuis la ligne de commande.
‫Si vous voyez ce que je fais, je suis en train de taper un mot de passe dans la ligne de commande avec echo et
‫de le faire écho dans la commande de création.
‫Et remarquez le tiret à la fin, car cela indique à la commande de lire à partir de l’entrée standard. C'est ce que nous lui donnons
‫avec la commande echo.
‫Maintenant, je devrais dire que ces deux-là ont des inconvénients.
‫Le premier, vous stockez le mot de passe sur le disque dur du serveur de l'hôte.
‫Et nous ne voudrions vraiment pas faire ça.
‫Donc, vous utiliseriez peut-être l'API distante à partir de cette ligne de commande locale sur votre machine. Et puis passez dans les fichiers
‫de cette façon.
‫Et, dans le second, cela entre dans l’historique de notre fichier Bash pour notre utilisateur root.
‫Donc, techniquement, si quelqu'un pouvait accéder à root, il pourrait en fait extraire ce mot de passe.
‫Lorsque vous traitez avec vos propres systèmes de production, vous devez rechercher différents moyens de
‫résoudre ces deux problèmes de sécurité potentiels.
‫Donc, ce que nous avons ici est ... maintenant, si je fais un secret de docker, vous pouvez voir que je les ai tous les deux dedans.
‫Maintenant, je peux réellement les inspecter, mais je ne vais jamais voir les mots de passe ou le secret.
‫Alors, laissez-moi juste faire l'utilisateur.
‫Ça ne va pas nous donner l'information, non. Parce que si c'était aussi facile d'obtenir l'information, ce
‫ne serait pas vraiment secret.
‫Droite?
‫Donc, l’objectif ici est qu’une fois que vous avez mis le secret dans le système, il est stocké dans la base de données. Et la seule chose qui aura
‫accès aux secrets déchiffrés sera les conteneurs et les services auxquels
‫nous l'attribuerons.
‫Alors faisons cela maintenant.
‫Je vais créer un service manuellement.
‫service docker créer. Je l'appellerai psql. Et nous allons cartographier le secret. Fondamentalement, nous disons à cette commande
‫de création de prendre ce secret appelé ce nom particulier ...
‫Je peux aussi utiliser l'ID du secret ... et l'assigner à ce service, de sorte que tous les conteneurs de
‫ce service verront ce secret.
‫D'accord.
‫Et ensuite, mettez l’utilisateur dedans, puis je dois le refaire pour mot de passe.
‫D'accord.
‫Donc, cela mappe les secrets au service, de sorte qu'ils apparaissent sous forme de fichiers à l'intérieur du conteneur.
‫Mais cela ne dit pas à la base de données postgres que nous créons à
‫partir de cette image comment utiliser ces secrets.
‫Donc, généralement, nous devons faire quelque chose avec la configuration de l'image.
‫Et dans ce cas, les images officielles de Docker Hub ont opté pour une
‫norme dans laquelle vous utilisez des variables d’environnement. Mais, au lieu de transmettre peut-être quelque chose comme mot de passe postgres, ce serait difficile à utiliser
‫avec un fichier.
‫En fait, il nous faudrait, comme, filtrer le fichier dans la variable d'environnement et c'est un
‫peu pénible.
‫Donc, ils ont la norme où, si vous spécifiez un fichier ... et ce serait le chemin ... donc ce serait courir secrets, puis
‫le nom, non? Alors psql passe, le nom du secret.
‫Si je le fais, c'est en fait dans le démarrage de l'image qui cherchera cette variable d'environnement en cours
‫de remplissage.
‫Et si c'est le cas, il extraira ce fichier et le stockera dans la variable d'environnement. Le contenu réel de ce
‫fichier.
‫C’est un moyen très simple de consommer ces secrets contenus dans les fichiers.
‫Mais cela signifie que les images que vous utilisez doivent avoir cette norme en place.
‫Nous pouvons également faire la même chose pour l'utilisateur.
‫Espérons que cela a du sens pour vous. Lorsque je crée le
‫service, il remplit son rôle habituel lorsqu'il envoie une demande de planification pour un nouveau conteneur.
‫Il va créer une base de données Postgres et lui transmettre les
‫variables d'environnement pour les emplacements de ces deux secrets.
‫Et ensuite, il va mapper, dans un tempfs, il va mapper dans ce qui ressemble à des fichiers.
‫Mais encore une fois, il s’agit en réalité d’un système de fichiers RAM ou d’un fichier tmpfs.
‫Allons voir ce que nous pouvons voir là-bas.
‫Donc, je fais un service de menu fixe ps psql, et cela devrait nous dire sur quel nœud il tourne.
‫Ok, ça tourne sur ce noeud.
‫Faisons un exec pour voir ce que nous pouvons voir à l'intérieur du conteneur.
‫docker exec -it.
‫Et puis le nom du conteneur spécifique pour ce service, puis bash.
‫D'accord.
‫Nous devrions maintenant être en mesure de faire une ls sur les secrets d’exécution, et vous verrez que nous récupérons les deux fichiers.
‫Et si je fais un chat sur un utilisateur psql, nous voyons la valeur. Ça a marché.
‫Et si nous regardons les journaux de cette psql, nous savons que cela fonctionne. Parce que si ce n’était pas ... si elle ne possédait pas ces
‫fichiers, la base de données réelle continuerait à se recréer, sans pouvoir fonctionner car elle ne disposait pas
‫d'un mot de passe et d'un nom d'utilisateur pour créer la base de données.
‫Si vous avez à nouveau fait appel au service fixe de docker, ce que vous verriez s’il ne fonctionnait pas correctement dans un scénario de base de données, c’est
‫que la base de données serait en fait en panne. Et cela continuerait à redémarrer et vous verriez de
‫nouveaux conteneurs être créés ici.
‫Donc, maintenant que nous l'avons assigné à cet endroit, nous pouvons utiliser une mise à jour du
‫service Docker pour supprimer le secret. Donc, mise à jour du service docker --secret-rm.
‫Il y a aussi secret-add. Mais si je retirais l'un de ces
‫secrets, il se produirait un redéploiement du conteneur. Parce que les secrets font partie de la conception immuable des services.
‫Si quelque chose dans le conteneur doit changer pour le service, le service n'entrera pas et ne modifiera
‫pas quelque chose à l'intérieur du conteneur. En fait, le conteneur sera arrêté et un nouveau sera redéployé.
‫De toute évidence, ce n'est pas idéal pour les bases de données. Nous devrons donc élaborer un plan différent pour la mise à
‫jour des mots de passe des bases de données.
‫Et nous pourrons en parler plus tard.
‫Pour le moment, je veux juste que vous sachiez que vous pouvez les supprimer et en ajouter de nouveaux à un service existant.
‫Il va simplement recréer le conteneur lorsque vous le faites.