Die Verwendung von Docker während des Entwicklungsprozesses ist zum De-facto-Standard geworden. Das Starten einer Anwendung mit all ihren Abhängigkeiten mit nur einem Befehl wird immer häufiger. Wenn die Anwendung über die Webschnittstelle oder eine HTTP-API Zugriff bietet, leitet der Front-Line-Container höchstwahrscheinlich seinen eindeutigen Port (unter anderen Anwendungen, die Sie parallel entwickeln) an den Host weiter, indem er darauf klickt, dass wir mit der Anwendung im Container interagieren können .
Und dies funktioniert einwandfrei, bis Sie einen ganzen Zoo von Anwendungen haben, zwischen denen das Wechseln einige Unannehmlichkeiten verursacht, da Sie sich das Schema und den Port merken müssen und irgendwo festlegen müssen, welche Ports für welche Anwendung Sie einmal zugewiesen haben, um dies nicht zu tun Kollisionen entstanden im Laufe der Zeit.
Und dann möchten Sie auch die Arbeit an https überprüfen - und Sie müssen entweder Ihr curl --insecure ... oder immer curl --insecure ... , und wenn verschiedene Befehle für Anwendungen funktionieren, beginnt die Anzahl der Paare exponentiell zu wachsen.
Wieder einmal mit einem solchen Problem konfrontiert - der Gedanke schoss mir durch den Kopf: „Hör auf!“, Und das Ergebnis der Arbeit an einigen Wochenenden war ein Dienst, der dieses Problem im Keim löst, der weiter unten beschrieben wird. Für die Ungeduldigen traditionell - eine Referenz .
Die Welt Wir werden den Reverse Proxy speichern
In guter Weise benötigen wir eine Art Domänenzone, alle Unterdomänen, aus denen der lokale Host immer auflöst (127.0.0.1). Eine schnelle Suche zeigte auf Domänen wie *.localho.st , *.lvh.me , *.vcap.me und andere, aber wie kann man ihnen ein gültiges SSL-Zertifikat *.vcap.me ? Nachdem ich an meinem Stammzertifikat herumgebastelt hatte, gelang es mir, curl ohne Fehler zu erhalten, aber nicht alle Browser akzeptierten es korrekt und gaben weiterhin einen Fehler aus. Außerdem - ich wollte wirklich nicht mit SSL "herumspielen".
"Nun, lass uns auf die andere Seite gehen!" - und dann wurde eine Domain mit dem Namen localhost.tools gekauft, an CloudFlare delegiert, die erforderliche Auflösung wurde konfiguriert (alle Subdomains werden aufgelöst 127.0.0.1 ):
$ dig foo.localhost.tools | grep -v '^;\|^$' foo.localhost.tools. 190 IN A 127.0.0.1
Danach wurde certbot im Container gestartet, der beim Empfang der KEY-API von CF unter Verwendung des DNS- Eintrags den Domänenbesitz bestätigt und ein gültiges SSL-Zertifikat für die Ausgabe ausstellt:
$ 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/*"
Die Datei ./cf-config.conf enthält die Autorisierungsdaten für CF. Weitere Informationen finden Sie in der Dokumentation zu certbot, $CF_EMAIL - Umgebungsvariable mit Ihrer E-Mail
Ok, jetzt haben wir ein gültiges SSL-Zertifikat (auch für 3 Monate und nur für Subdomains derselben Stufe). Es bleibt irgendwie zu lernen, wie man alle Anfragen, die an den lokalen Host kommen, im richtigen Container vertritt.
Und hier kommt uns Traefik zu Hilfe (Spoiler - es ist wunderschön). Durch lokales Starten und Weiterleiten eines Docker-Sockets an seinen Container über das Volume können Anforderungen an den Container mit der erforderlichen docker label . Daher benötigen wir keine zusätzliche Konfiguration, außer wenn wir beginnen, die gewünschte Bezeichnung für den Container (und das Docker-Netzwerk) anzugeben, aber wenn wir ohne Docker-Compose starten, ist auch dies nicht erforderlich, obwohl dies sehr wünschenswert ist), für die wir möchten Zugriff über Domainname und mit gültigem SSL !
Nachdem dies alles geschehen war, sah die Welt einen Docker-Container mit diesem sehr vorkonfigurierten Traefik- und Wildcard-SSL-Zertifikat (ja, es ist öffentlich).
Privater Schlüssel von SSL in einem öffentlichen Container?
Ja, aber ich denke, dass dies nicht beängstigend ist, da es sich in der Domänenzone befindet, die immer den lokalen Host auflöst. MitM macht in diesem Fall prinzipiell wenig Sinn.
Was tun, wenn das Zertifikat fehlerhaft ist?
Ziehen Sie einfach das frische Bild ab, indem Sie den Container neu starten. Für das Projekt ist CI konfiguriert, das das Zertifikat (derzeit) automatisch einmal im Monat aktualisiert und ein neues Image veröffentlicht.
Ich möchte es versuchen!
Einfacher geht es nicht. Stellen Sie zunächst sicher, dass Ihre lokalen Ports 80 und 443 frei sind, und gehen Sie wie folgt vor:
Und jetzt können wir testen:
$ 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>
Wie Sie sehen können, funktioniert es :)
Wo lebt die Dokumentation, Beschreibung?
Es ist nicht schwer zu erraten, dass alles unter https://localhost.tools verfügbar ist . Darüber hinaus reagiert die Mündung und kann feststellen, ob der Reverse-Proxy-Daemon lokal ausgeführt wird, und eine Liste der Container anzeigen, die ausgeführt werden und für die Interaktion verfügbar sind (falls vorhanden).
Wie viel es kostet?
Überhaupt nicht. Absolut. Nachdem ich dies für mich und mein Team getan hatte, wurde mir klar, dass es für andere Entwickler / Ops nützlich sein kann. Außerdem kostet nur der Domainname Geld, alles andere wird ohne Bezahlung verwendet.
PS Der Dienst befindet sich daher noch in der Beta-Phase - wenn Mängel, Tippfehler usw. festgestellt werden - kritzeln Sie einfach in PM . Die Hubs "Programmierung" und "Website-Entwicklung" sind angegeben, da dieser Ansatz vor allem in diesen Branchen nützlich sein kann.