O uso do Docker durante o processo de desenvolvimento tornou-se o padrão de fato. O lançamento de um aplicativo com todas as suas dependências usando apenas um comando está se tornando cada vez mais comum. Se o aplicativo fornecer acesso usando a interface da Web ou alguma API HTTP, é provável que o contêiner front-end encaminhe sua porta exclusiva (entre outros aplicativos que você está desenvolvendo em paralelo) para o host. Ao bater nele, podemos interagir com o aplicativo no contêiner .
E isso funciona bem até que você tenha um zoológico inteiro de aplicativos, alternar entre os quais começa a causar algum inconveniente, já que você precisa lembrar o esquema e a porta e algum lugar para corrigir quais portas para qual aplicativo você alocou uma vez, para não Colisões surgiram com o tempo.
E você também deseja verificar o trabalho em https - e precisa usar seu certificado raiz ou sempre usar curl --insecure ... e quando vários comandos funcionam em aplicativos - o número de pares começa a crescer exponencialmente.
Diante desse problema mais uma vez - o pensamento passou pela minha cabeça "Pare com isso!", E o resultado do trabalho em alguns fins de semana foi um serviço que resolve esse problema pela raiz, que será descrito abaixo. Para os impacientes, tradicionalmente - uma referência .
O mundo Vamos salvar o proxy reverso
De uma maneira boa, precisamos de algum tipo de zona de domínio, todos os subdomínios dos quais o host local sempre resolverá (127.0.0.1). Uma pesquisa rápida apontou para domínios no formato *.localho.st , *.lvh.me , *.vcap.me e outros, mas como anexar um certificado SSL válido a eles? Tendo mexido no meu certificado raiz, consegui obter curl sem erros, mas nem todos os navegadores o aceitaram corretamente e continuamos a gerar um erro. Além disso - eu realmente não queria "mexer" com SSL.
"Bem, vamos do outro lado!" - e, em seguida, um domínio com o nome localhost.tools foi adquirido, delegado ao CloudFlare, a resolução necessária foi configurada (todos os subdomínios foram resolvidos 127.0.0.1 ):
$ dig foo.localhost.tools | grep -v '^;\|^$' foo.localhost.tools. 190 IN A 127.0.0.1
Depois disso, o certbot foi lançado no contêiner, que, ao receber a API KEY do CF usando o registro DNS, confirma a propriedade do domínio e emite um certificado SSL válido na saída:
$ 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/*"
O arquivo ./cf-config.conf contém os dados de autorização do CF. Para obter mais detalhes, consulte a documentação do certbot, $CF_EMAIL - variável de ambiente com seu email.
Ok, agora temos um certificado SSL válido (mesmo por 3 meses e apenas para subdomínios do mesmo nível). Resta aprender de alguma forma como proxy de todas as solicitações que chegam ao host local no contêiner certo .
E aqui Traefik vem em nosso auxílio (spoiler - é lindo). Ao iniciá-lo localmente e encaminhar um soquete de docker para seu contêiner por meio de volume, ele pode fazer pedidos de proxy para o contêiner que possui o docker label necessário. Portanto, não precisamos de nenhuma configuração adicional, exceto quando começar a especificar o rótulo desejado para o contêiner (e rede de encaixe, mas ao iniciar sem composição de encaixe, mesmo isso não é necessário, embora muito desejável), para o qual queremos acesso por nome de domínio e com SSL válido !
Tendo feito tudo isso, o mundo viu um contêiner de encaixe com este certificado Traefik e curinga SSL muito pré-configurado (sim, é público).
Chave privada do SSL em um contêiner público?
Sim, mas acho que isso não é assustador, pois está na zona do domínio, que sempre resolve o host local. O MitM, neste caso, não faz muito sentido em princípio.
O que fazer quando o certificado fica ruim?
Basta retirar a nova imagem reiniciando o contêiner. O projeto possui um IC configurado, que automaticamente, uma vez por mês (no momento) atualiza o certificado e publica uma nova imagem.
Eu quero tentar!
Não há nada mais fácil. Antes de tudo, verifique se as portas 80 e 443 livres e faça:
E agora podemos testar:
$ 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 você pode ver, funciona :)
Onde está a documentação, descrição?
Tudo, não é difícil adivinhar, vive em https://localhost.tools . Além disso, o focinho é responsivo e pode ver se o daemon de proxy reverso está sendo executado localmente e exibe uma lista de contêineres em execução e disponíveis para interação (se houver).
Quanto custa?
Nem um pouco. Absolutamente. Tendo feito isso por mim e pela minha equipe, percebi que isso pode ser útil para outros desenvolvedores / ops. Além disso - apenas o nome do domínio custa dinheiro, todo o resto é usado sem a necessidade de pagamento.
PS O serviço ainda está na versão beta, portanto - se houver falhas, erros de digitação etc. - apenas rabiscar em PM . Os hubs "Programação" e "Desenvolvimento de sites" são indicados porque essa abordagem pode ser útil principalmente nesses setores.