‫Qu'en est-il des secrets pour le développement local à l'aide de la ligne de commande Docker Compose. Nous avons parlé de Swarm
‫jusqu'à maintenant.
‫Mais je suis de retour sur ma machine et j'ai installé Docker Compose que je n'avais pas dans mon essaim, n'est-ce
‫pas?
‫Car encore une fois, Compose n'est pas un outil de production.
‫C'est conçu pour le développement.
‫Je suis dans le même répertoire secret que celui que nous avions auparavant.
‫Vous pouvez voir que j'ai les deux fichiers de mot de passe et le fichier Docker Compose que nous avions dans l'essaim. Juste pour prouver que je ne suis pas dans un
‫essaim, je peux faire
‫un nœud docker ls, et cela
‫me dira en fait que ce n'est pas un gestionnaire d'essaim.
‫Je ne fais pas partie d'un essaim, je n'ai donc pas accès à la base de données Swarm ni la possibilité d'y mettre des secrets.
‫Alors, comment traitons-nous cela dans le développement local?
‫Idéalement, nous pouvons toujours utiliser le même fichier Compose.
‫Nous pouvons toujours utiliser les mêmes objets que les variables d’environnement pour postgres.
‫Docker devait trouver un moyen de faire en sorte que cela fonctionne dans les tests et le développement.
‫Si nous faisons un
‫docker compose -d, puis un docker compose exec psql. Ensuite, un chat a-t-il utilisé des utilisateurs secrets de
‫psql, comment notre secret est-il entré, n'est-ce pas?
‫Parce que nous n'avons pas la base de données.
‫Eh bien, il s'avère qu'il y a un peu de magie ici.
‫Et bien ce n'est pas magique. C'est juste se cacher dans les coulisses, que ce
‫qui se passe réellement avec Compose n'est pas sécurisé, mais cela fonctionne.
‫Il lie essentiellement les montages au moment de l’exécution du fichier sur mon disque dur au conteneur.
‫Il s’agit en fait de faire un -v avec ce fichier particulier en arrière-plan.
‫Encore une fois, ceci n’est absolument pas sécurisé et ce n’est pas censé l’être.
‫C'est juste un moyen de contourner ce problème et de nous permettre de développer avec le même
‫processus et le même environnement des informations de variable d'environnement secrètes que nous aurions en production.
‫Seulement maintenant, nous pouvons le faire localement aussi. Ce qui est excellent, car cela signifie que nous pouvons maintenant développer à l'aide des mêmes
‫scripts de lancement et de la même manière que nous introduisons des variables d'environnement dans notre conteneur, comme nous le ferions dans Swarm.
‫Et c'est ce que nous voulons vraiment.
‫Nous voulons adapter notre environnement de production autant que possible localement.
‫Pour ce faire, vous devez disposer de la dernière version de Docker Compose.
‫Je crois que cela ne fonctionne que dans Docker Compose 11.
‫J'espère que vous trouvez ça très cool parce que je pensais que c'était un bon
‫compromis à faire pour nous permettre d'utiliser les commandes Secret.
‫Maintenant, je soulignerai que cela ne fonctionne qu'avec des secrets basés sur des fichiers.
‫Cela ne fonctionnera pas avec l'externe dont nous avons parlé.
‫Si nous examinons rapidement le fichier Compose, je devrais utiliser des fichiers basés sur des fichiers pour mon développement local.
‫Peut-être que si vous utilisez external dans votre production, vous devrez peut-être un fichier Compose différent
‫pour le développement, qui aurait l'attribut de fichier ici et spécifierait des exemples de fichiers factices dans le même répertoire ou ailleurs,
‫que vous pourriez stocker, en utilisant simplement un mot de passe pour le développement.