VPN dun runner de CI: sobrevive o túnel á compilación?
Un runner de CI compartido conserva rutas e procesos entre traballos. Planifica os estados da VPN antes, durante e despois do traballo, e limpa só a conexión que posúe o traballo.
Un traballo de despregue conéctase, copia o seu artefacto e informa de éxito. O túnel que abriu pode seguir activo cando comeza o seguinte traballo, e a ruta que cambiou pertence a todo o host. O resultado dunha compilación describe o comando, non o estado que deixou atrás. Trata a VPN como un recurso cunha vida útil, non como unha liña ao comezo dunha etapa.
Que máis se executa neste host
Un nodo de Jenkins pode executar varios executores á vez, e un traballo que cambia rutas do host, axustes do resolutor ou unha conexión de todo o sistema cámbiaos para todos. Que outro traballo o note depende da política de rutas e de filtrado, non dunha regra xeral sobre VPN. O acceso ao repositorio, o acceso aos artefactos e a canle de control son requisitos distintos que o runner aínda necesita. Engádeos á lista de destinos de despregue antes de elixir un túnel completo.
Se a canle de control fose cruzar o túnel, o deseño ten que dicilo a propósito. Descubrilo durante unha reversión non é un plan. Escribe as dúas listas: que debe acadar o traballo de forma privada e que debe acadar o runner pase o que pase.
Necesita este traballo acceso privado, despois de todo?
Pregunta, antes de engadir o túnel, se a etapa de compilación o necesita. Un axente de despregue privado pode obter un artefacto aprobado e realizar o despregue, o que mantén a etapa xeral de compilación fóra da rede privada. Esa separación adoita ser máis barata que ensinar a cada paso de compilación a encamiñarse por un túnel.
Escolle a fronteira a partir do fluxo de traballo, non do costume. Se a resposta é non, o resto desta páxina é innecesario, e ese é o mellor resultado dispoñible.
O estado que herda o seguinte traballo
Describe que debería ser certo antes do traballo, mentres ten acceso privado e despois de que remate, incluída a cancelación. O estado final é o que máis a miúdo queda implícito, e é o que herda o seguinte traballo. Escríbeo xunto ao pipeline en lugar de deixalo na memoria de alguén.
| Moment | What proves it | What leaks if it is skipped |
|---|---|---|
| Job start: pre-flight route check | The route table shows no tunnel from an earlier job, and the profile list is empty | A stale route sends deployment traffic into a dead tunnel |
| Job end: disconnect and shred | The profile is down and the temporary key file is gone | The next job inherits an open tunnel and a usable credential |
| Cancelled job: reboot or disposal | The host is replaced or rebooted before the next job starts | A killed process leaves the tunnel up with no owner |
Un axente dedicado ou dun só uso fai máis doado facer cumprir esas fronteiras. Un contedor ou un espazo de nomes só axuda se a súa disposición de rede e de privilexios illa de verdade o cambio.
Deter a conexión, non o programa
Usa a ruta de finalización do pipeline para pechar a conexión que iniciou este traballo e eliminar as súas credenciais temporais. Non emparelles procesos polo nome do programa nun host que outros traballos usan; detén a conexión concreta. Os dous comandos de abaixo son toda a limpeza, e ningún depende de atopar un proceso.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"A finalización non é illamento: un runner que morre conserva o túnel que abriu, e un proceso detido á forza salta o bloque por completo. Por iso o comando de limpeza por si só non pode ser todo o deseño. Así falla na práctica: un traballo de despregue cancélase no paso de copia, o bloque de finalización nunca se executa, e o seguinte traballo no mesmo host comeza cun túnel vivo e unha ruta que apunta a unha rede que non pode acadar. O fallo parece un problema de 'DNS' na seguinte compilación, horas despois de que rematase o traballo que o causou.
Rexistra o nome do perfil e a ruta da credencial na saída do traballo. Un comando de desconexión espido e sen identificador é difícil de auditar despois. A liña de rexistro tamén é o que demostra que o bloque se executou cando unha investigación posterior o pregunta.
Dálle ao traballo un host que ninguén máis use
A infraestrutura dun só uso elimina o problema da herdanza en lugar de xestionalo. Un axente novo por traballo comeza sen ruta, sen perfil e sen credenciais de ninguén máis, e a súa destrución limpa o que o traballo deixase. Iso custa máis por compilación, e é o prezo honesto dunha fronteira que non depende do código de limpeza. Para traballos que tocan redes de produción, adoita ser a opción máis barata unha vez contados os incidentes.
Onde un runner compartido teña que quedar, proba o fallo e a cancelación co mesmo coidado que a copia correcta. A proba debería mostrar que vería o seguinte traballo se este se cancelase a medio camiño. Un traballo está feito cando remataron o seu acceso e o seu estado temporal, non cando o comando de copia devolve cero.