Antes de que un charm de Juju se converta no teu VPN: identidade, contrato, portos

Alguén atopa un charm que di que executa un VPN, despregáeo, expón a aplicación e espera que un cliente se conecte. O despregamento sae ben, o porto ábrese e o túnel segue sen funcionar, porque tres promesas sen relación fundíronse nunha. Un charm é unha implementación de despregamento cun contrato concreto. Examina esas promesas por separado e as lagoas aparecen antes do lanzamento en lugar de despois.

Paso un: fixa o artefacto do que estás a ler

Le os metadatos propios do candidato: publicador, repositorio de orixe, canle, revisión, base e arquitectura. Despois establece quen mantén o software de VPN dentro da carga de traballo e quen entrega as súas actualizacións de seguridade, porque a miúdo son dúas partes distintas. Un upstream sen mantemento dentro dun charm ben mantido é un problema de soporte esperando unha mala semana.

juju info CHARM_NAME informa de canles, bases e arquitecturas en Juju 3.6, e a documentación sinala que unha consulta dunha revisión concreta non se pode combinar con eses filtros. Consulta a revisión por separado en lugar de construír unha combinación que o comando rexeita. Le tamén a base e a arquitectura, xa que unha canle pode cubrir máis dunha.

Anota a combinación exacta que revisaches xunto ao despregamento. Entón unha actualización que move a canle é un cambio intencionado cun antes e un despois, non unha sorpresa un luns.

Paso dous: le a configuración como un contrato

Determina o papel que xoga o charm: rematar o acceso remoto, unirse a un VPN existente ou algo completamente distinto. Despois busca como documenta a inscrición de clientes, os emisores de confianza, a rotación de credenciais e a revogación. Eses catro deciden se podes operar a cousa, e un ficheiro de cliente xerado é unha saída sensible en lugar dun ficheiro para un ticket.

Segue as interfaces e accións que o charm expón realmente. Non deas por feito que existe unha acción de inscrición porque outro charm para o mesmo software teña unha.

Pregunta que fai a reconciliación coas edicións manuais. Se o charm sobrescribe un ficheiro de configuración na próxima actualización, unha corrección manual ten unha vida útil dunha soa actualización. Pregunta aos mantenedores onde está documentado ese comportamento e trata o silencio como descoñecemento.

Paso tres: separa o oínte da ruta reenviada

O oínte exterior é o socket que acepta o túnel. O reenvío é o que ocorre co tráfico dentro del, e unha ruta de retorno é o que permite que volvan as respostas. Un charm pode entregar o primeiro e deixar os outros dous ao equipo de infraestrutura.

A saída é unha terceira peza. Se os clientes do túnel deben chegar a internet a través deste host, ten que existir un arranxo de enderezo ou tradución, e non se crea abrindo un porto. Asigna un responsable a esa peza antes de que chegue o primeiro cliente.

Paso catro: a exposición é unha acción de cortalumes

En Juju 3.6, expor unha aplicación axusta as regras do cortalumes da nube e, por defecto, permite o tráfico desde calquera orixe cara aos portos que a carga de traballo abriu. Os selectores de endpoint e CIDR do comando existen precisamente para que ese valor por defecto poida acoutarse.

A exposición non crea usuarios de VPN, non valida as súas credenciais nin instala unha política de reenvío. Tampouco demostra que a carga de traballo estea escoitando no enderezo e no transporte que esperas, e por iso a proba posterior á exposición importa máis que a mensaxe de éxito. Comproba o socket en escoita na unidade ademais da regra da nube.

Paso cinco: acepta con catro probas

Tras un despregamento aprobado, inscribe un cliente novo e confirma o servizo privado previsto. Despois revoga esa identidade e confirma que o acceso remata de verdade, en lugar de que só se rexeite o seguinte inicio de sesión. Repite a comprobación desde unha rede que non controlas e despois desde dentro da oficina, porque eses dous camiños responden a preguntas distintas.

Remata cunha actualización e unha reconexión, porque é onde interactúan a reconciliación, o manexo de credenciais e os reinicios de servizo. Se a documentación non pode explicar quen é dono dunha desas operacións, anótao como unha lagoa de adopción en lugar de encheda cunha receita sen mantemento detrás do mesmo nome de charm. Unha lagoa anotada é unha decisión; unha lagoa enchida en silencio é unha futura caída. Pásalla a quen sexa dono da decisión do servizo, coa data en que a atopaches.