Alguém encontra um charm que diz executar uma VPN, implanta-o, expõe a aplicação e espera que um cliente se conecte. A implantação dá certo, a porta abre e o túnel continua sem funcionar, porque três promessas não relacionadas foram fundidas em uma. Um charm é uma implementação de implantação com um contrato específico. Examine essas promessas em separado e as lacunas aparecem antes do lançamento, não depois.

Passo um: fixe o artefato sobre o qual você está lendo

Leia os metadados do próprio candidato: publicador, repositório de origem, canal, revisão, base e arquitetura. Depois estabeleça quem mantém o software de VPN dentro da carga de trabalho e quem entrega suas atualizações de segurança, porque muitas vezes são duas partes diferentes. Um upstream sem manutenção dentro de um charm bem mantido é um problema de suporte esperando uma semana ruim.

juju info CHARM_NAME informa canais, bases e arquiteturas no Juju 3.6, e a documentação observa que uma consulta de revisão específica não pode ser combinada com esses filtros. Consulte a revisão isoladamente em vez de montar uma combinação que o comando rejeita. Leia também a base e a arquitetura, já que um canal pode cobrir mais de uma.

Anote a combinação exata que você revisou ao lado da implantação. Então uma atualização que move o canal é uma mudança intencional com um antes e um depois, não uma surpresa numa segunda-feira.

Passo dois: leia a configuração como um contrato

Determine o papel que o charm desempenha: encerrar o acesso remoto, ingressar numa VPN existente ou algo completamente diferente. Depois descubra como ele documenta o registro de clientes, os emissores confiáveis, a rotação de credenciais e a revogação. Esses quatro decidem se você consegue operar a coisa, e um arquivo de cliente gerado é uma saída sensível em vez de um arquivo para um chamado.

Siga as interfaces e ações que o charm realmente expõe. Não presuma que existe uma ação de registro só porque outro charm para o mesmo software tem uma.

Pergunte o que a reconciliação faz com edições manuais. Se o charm sobrescrever um arquivo de configuração na próxima atualização, uma correção manual tem validade de uma única atualização. Pergunte aos mantenedores onde esse comportamento está documentado e trate o silêncio como desconhecido.

Passo três: separe o ouvinte do caminho encaminhado

O ouvinte externo é o socket que aceita o túnel. O encaminhamento é o que acontece com o tráfego dentro dele, e um caminho de retorno é o que permite que as respostas voltem. Um charm pode entregar o primeiro e deixar os outros dois para a equipe de infraestrutura.

A saída é a terceira peça. Se os clientes do túnel devem chegar à internet por este host, precisa existir um arranjo de endereçamento ou tradução, e ele não é criado abrindo uma porta. Atribua um responsável a essa peça antes de o primeiro cliente chegar.

Passo quatro: a exposição é uma ação de firewall

No Juju 3.6, expor uma aplicação ajusta as regras do firewall da nuvem e, por padrão, permite tráfego de qualquer origem para as portas que a carga de trabalho abriu. Os seletores endpoint e CIDR do comando existem justamente para que esse padrão possa ser restringido.

A exposição não cria usuários de VPN, não valida as credenciais deles e não instala política de encaminhamento. Ela também não prova que a carga de trabalho está ouvindo no endereço e no transporte que você espera, e por isso o teste depois da exposição importa mais que a mensagem de sucesso. Verifique o socket em escuta na unidade e também a regra da nuvem.

Passo cinco: aceite com quatro testes

Depois de uma implantação aprovada, registre um cliente novo e confirme o serviço privado pretendido. Em seguida revogue essa identidade e confirme que o acesso realmente termina, em vez de apenas o próximo login ser recusado. Repita a verificação a partir de uma rede que você não controla e depois de dentro do escritório, porque esses dois caminhos respondem a perguntas diferentes.

Termine com uma atualização e uma reconexão, porque é ali que reconciliação, tratamento de credenciais e reinícios de serviço interagem. Se a documentação não consegue explicar quem é dono de uma dessas operações, anote isso como uma lacuna de adoção em vez de preenchê-la com uma receita sem manutenção atrás do mesmo nome de charm. Uma lacuna anotada é uma decisão; uma lacuna preenchida em silêncio é uma futura queda. Entregue-a a quem for dono da decisão do serviço, com a data em que você a encontrou.

Artigos relacionados