L'utilisation de Docker pendant le processus de développement est devenue la norme de facto. Le lancement d'une application avec toutes ses dépendances à l'aide d'une seule commande devient de plus en plus courant. Si l'application fournit un accès à l'aide de l'interface Web ou d'une API HTTP - le conteneur de première ligne transmet probablement son port unique (parmi d'autres applications que vous développez en parallèle) à l'hôte, en frappant sur lequel nous pouvons interagir avec l'application dans le conteneur .
Et cela fonctionne bien jusqu'à ce que vous ayez tout un zoo d'applications, le basculement entre ceux-ci commençant à causer des inconvénients, car vous devez vous souvenir du schéma et du port, et quelque part pour fixer les ports pour quelle application vous avez une fois alloué, afin de ne pas Les collisions sont survenues au fil du temps.
Et puis vous voulez également vérifier le travail sur https - et vous devez soit utiliser votre certificat racine, soit toujours utiliser curl --insecure ... , et lorsque diverses commandes fonctionnent sur des applications - le nombre de paires commence à croître de façon exponentielle.
Face à un tel problème une fois de plus - la pensée m'a traversé la tête "Arrête ça!", Et le résultat du travail sur quelques week-ends a été un service qui résout ce problème dans l'œuf, qui sera décrit ci-dessous. Pour les impatients, traditionnellement - une référence .
Le monde Nous enregistrerons le proxy inverse
Dans le bon sens, nous avons besoin d'une sorte de zone de domaine, tous les sous-domaines à partir desquels l'hôte local sera toujours résolu (127.0.0.1). Une recherche rapide a indiqué des domaines comme *.localho.st , *.lvh.me , *.vcap.me et d'autres, mais comment leur attacher un certificat SSL valide? Après avoir bricolé mon certificat racine, j'ai réussi à obtenir une curl erreur, mais tous les navigateurs ne l'ont pas correctement accepté et ont continué à générer une erreur. De plus, je ne voulais vraiment pas "déconner" avec SSL.
"Eh bien, allons de l'autre côté!" - puis un domaine avec le nom localhost.tools été acheté, délégué à CloudFlare, la résolution requise a été configurée (tous les sous-domaines sont résolus 127.0.0.1 ):
$ dig foo.localhost.tools | grep -v '^;\|^$' foo.localhost.tools. 190 IN A 127.0.0.1
Après cela, certbot a été lancé dans le conteneur qui, lors de la réception de l'API KEY de CF en utilisant l'enregistrement DNS, confirme la propriété du domaine et émet un certificat SSL valide sur la sortie:
$ docker run \ --entrypoint="" \ -v "$(pwd)/cf-config.conf:/cf-credentials:ro" \ -v "$(pwd)/cert:/out:rw" \ -v "/etc/passwd:/etc/passwd:ro" \ -v "/etc/group:/etc/group:ro" \ certbot/dns-cloudflare:latest sh -c \ "certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials '/cf-credentials' \ -d '*.localhost.tools' \ --non-interactive \ --agree-tos \ --email '$CF_EMAIL' \ --server 'https://acme-v02.api.letsencrypt.org/directory' \ && cp -f /etc/letsencrypt/live/localhost.tools/* /out \ && chown '$(id -u):$(id -g)' /out/*"
Le fichier ./cf-config.conf contient les données d'autorisation sur CF, pour plus de détails, voir la documentation sur certbot, $CF_EMAIL - variable d'environnement avec votre email
Ok, nous avons maintenant un certificat SSL valide (même pour 3 mois, et uniquement pour les sous-domaines du même niveau). Il reste à savoir comment proxy toutes les requêtes qui arrivent à l'hôte local dans le bon conteneur.
Et ici Traefik vient à notre aide (spoiler - c'est beau). En le lançant localement et en transférant un socket Docker vers son conteneur via le volume, il peut envoyer des requêtes par proxy au conteneur qui possède le docker label nécessaire. Ainsi, nous n'avons besoin d'aucune configuration supplémentaire, sauf lorsque nous commençons à spécifier le libellé souhaité pour le conteneur (et le réseau docker, mais lorsque nous démarrons sans docker-compose, cela n'est pas nécessaire, bien que très souhaitable), auquel nous voulons accès par nom de domaine et avec SSL valide !
Après avoir fait tout ce chemin, le monde a vu un conteneur Docker avec ce certificat SSL Traefik et générique très préconfiguré (oui, il est public).
Clé privée de SSL dans un conteneur public?
Oui, mais je pense que ce n'est pas effrayant, car c'est sur la zone de domaine, ce qui résout toujours l'hôte local. MitM dans ce cas n'a pas beaucoup de sens en principe.
Que faire lorsque le certificat tourne mal?
Retirez simplement la nouvelle image en redémarrant le conteneur. Le projet a configuré CI, qui met automatiquement à jour une fois par mois (actuellement) le certificat et publie une nouvelle image.
Je veux l'essayer!
Rien de plus simple. Tout d'abord, assurez-vous que vos ports locaux 80 et 443 libres et faites:
Et maintenant, nous pouvons tester:
$ curl -sS http://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1> $ curl -sS https://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1>
Comme vous pouvez le voir, cela fonctionne :)
Où se trouve la documentation, la description?
Tout, ce n'est pas difficile à deviner, vit à https://localhost.tools . De plus, le museau est réactif et peut voir si le démon de proxy inverse s'exécute localement et afficher une liste de conteneurs en cours d'exécution et disponibles pour l'interaction (le cas échéant).
Combien cela coûte-t-il?
Pas du tout. Absolument. Ayant fait cette chose pour moi et mon équipe, j'ai réalisé qu'elle pouvait être utile à d'autres développeurs / ops. De plus - seul le nom de domaine coûte de l'argent, tout le reste est utilisé sans paiement.
PS Le service est toujours en version bêta, donc - si des lacunes, des fautes de frappe, etc. sont trouvées - gribouiller en PM . Les concentrateurs "Programmation" et "Développement de sites Web" sont indiqués car cette approche peut être utile principalement dans ces secteurs.