El uso de Docker durante el proceso de desarrollo se ha convertido en el estándar de facto. Lanzar una aplicación con todas sus dependencias usando solo un comando se está volviendo cada vez más común. Si la aplicación proporciona acceso utilizando la interfaz web o alguna API HTTP, lo más probable es que el contenedor de primera línea reenvíe su puerto único (entre otras aplicaciones que está desarrollando en paralelo) al host, al tocarlo para que podamos interactuar con la aplicación en el contenedor .
Y esto funciona bien hasta que tenga un zoológico completo de aplicaciones, cambiar entre las cuales comienza a causar algunos inconvenientes, ya que debe recordar el esquema y el puerto, y en algún lugar para arreglar qué puertos para qué aplicación asignó una vez, para no Las colisiones surgieron con el tiempo.
Y luego también desea verificar el trabajo en https, y debe usar su certificado raíz o siempre usar curl --insecure ... , y cuando varios comandos funcionan en aplicaciones, el número de pares comienza a crecer exponencialmente.
Frente a este problema una vez más, el pensamiento pasó por mi cabeza "¡Basta!", Y el resultado del trabajo en un par de fines de semana fue un servicio que resuelve este problema de raíz, que se describirá a continuación. Para los impacientes, tradicionalmente, una referencia .
El mundo Guardaremos el proxy inverso
En el buen sentido, necesitamos algún tipo de zona de dominio, todos los subdominios a partir de los cuales el host local siempre se resolverá (127.0.0.1). Una búsqueda rápida apuntó a dominios como *.localho.st , *.lvh.me , *.vcap.me y otros, pero ¿cómo adjuntarles un certificado SSL válido? Después de jugar con mi certificado raíz, logré obtener curl sin errores, pero no todos los navegadores lo aceptaron correctamente, y continué arrojando un error. Además, realmente no quería "perder el tiempo" con SSL.
"Bueno, ¡vamos al otro lado!" - y luego se compró un dominio con el nombre localhost.tools , delegado a CloudFlare, se configuró la resolución requerida (todos los subdominios se resuelven 127.0.0.1 ):
$ dig foo.localhost.tools | grep -v '^;\|^$' foo.localhost.tools. 190 IN A 127.0.0.1
Después de eso, se lanzó certbot en el contenedor que, al recibir la API CLAVE de CF utilizando el registro DNS, confirma la propiedad del dominio y emite un certificado SSL válido en la salida:
$ 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/*"
El archivo ./cf-config.conf contiene los datos de autorización para CF, para más detalles, consulte la documentación de certbot, $CF_EMAIL - variable de entorno con su correo electrónico
Ok, ahora tenemos un certificado SSL válido (incluso por 3 meses, y solo para subdominios del mismo nivel). Queda por aprender de alguna manera cómo proxy todas las solicitudes que llegan al host local en el contenedor correcto .
Y aquí Traefik viene en nuestra ayuda (spoiler, es hermoso). Al iniciarlo localmente y reenviar un socket docker a su contenedor a través del volumen, puede enviar solicitudes proxy al contenedor que tiene la docker label necesaria. Por lo tanto, no necesitamos ninguna configuración adicional, excepto cuando comenzamos a especificar la etiqueta deseada para el contenedor (y la red de acopladores, pero cuando comenzamos sin docker-compose, incluso esto no es necesario, aunque es muy deseable), a lo que queremos acceso por nombre de dominio y con SSL válido !
Una vez hecho todo esto, el mundo vio un contenedor acoplable con este certificado SSL Traefik y comodín muy preconfigurado (sí, es público).
¿Clave privada de SSL en un contenedor público?
Sí, pero creo que esto no da miedo, ya que está en la zona de dominio, que siempre resuelve el host local. MitM en este caso no tiene mucho sentido en principio.
¿Qué hacer cuando el certificado sale mal?
Simplemente retire la imagen nueva reiniciando el contenedor. El proyecto tiene configurado CI, que automáticamente, una vez al mes (en este momento) actualiza el certificado y publica una nueva imagen.
¡Quiero probarlo!
No hay nada mas facil. En primer lugar, asegúrese de que sus puertos locales 80 y 443 gratuitos y haga lo siguiente:
Y ahora podemos probar:
$ 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>
Como puedes ver, funciona :)
¿Dónde vive la documentación, descripción?
Todo, no es difícil de adivinar, vive en https://localhost.tools . Además, el hocico responde y puede ver si el demonio proxy inverso se está ejecutando localmente y mostrar una lista de contenedores que se están ejecutando y disponibles para la interacción (si corresponde).
Cuanto cuesta
En absoluto Absolutamente Después de hacer esto por mí y por mi equipo, me di cuenta de que puede ser útil para otros desarrolladores / operaciones. Además, solo el nombre de dominio cuesta dinero, todo lo demás se usa sin necesidad de pago.
PD: El servicio todavía está en beta, por lo tanto, si se encuentran fallas, errores tipográficos, etc. - Solo garabatear en PM . Los centros "Programación" y "Desarrollo de sitios web" están indicados porque este enfoque puede ser útil principalmente en estas industrias.