VPN de un runner de CI: ¿sobrevive el túnel a la compilación?
Un runner de CI compartido conserva rutas y procesos entre trabajos. Planifique los estados de la VPN antes, durante y después del trabajo, y limpie solo la conexión que el trabajo posee.
Un trabajo de despliegue se conecta, copia su artefacto e informa de éxito. El túnel que abrió puede seguir activo cuando empieza el siguiente trabajo, y la ruta que cambió pertenece a todo el host. El resultado de una compilación describe el comando, no el estado que dejó atrás. Trate la VPN como un recurso con una vida útil, no como una línea al principio de una etapa.
Qué más se ejecuta en este host
Un nodo de Jenkins puede ejecutar varios ejecutores a la vez, y un trabajo que cambia rutas del host, ajustes del resolutor o una conexión de todo el sistema los cambia para todos. Que otro trabajo lo note depende de la política de rutas y de filtrado, no de una regla general sobre VPN. El acceso al repositorio, el acceso a los artefactos y el canal de control son requisitos distintos que el runner sigue necesitando. Añádalos a la lista de destinos de despliegue antes de elegir un túnel completo.
Si el canal de control fuera a cruzar el túnel, el diseño tiene que decirlo a propósito. Descubrirlo durante una reversión no es un plan. Escriba las dos listas: qué debe alcanzar el trabajo de forma privada y qué debe alcanzar el runner pase lo que pase.
¿Necesita este trabajo acceso privado siquiera?
Pregunte, antes de añadir el túnel, si la etapa de compilación lo necesita. Un agente de despliegue privado puede obtener un artefacto aprobado y realizar el despliegue, lo que mantiene la etapa general de compilación fuera de la red privada. Esa separación suele ser más barata que enseñar a cada paso de compilación a enrutarse por un túnel.
Elija la frontera a partir del flujo de trabajo, no de la costumbre. Si la respuesta es no, el resto de esta página es innecesario, y ese es el mejor resultado disponible.
El estado que hereda el siguiente trabajo
Describa qué debería ser cierto antes del trabajo, mientras tiene acceso privado y después de que termine, incluida la cancelación. El estado final es el que más a menudo queda implícito, y es el que hereda el siguiente trabajo. Escríbalo junto al pipeline en lugar de dejarlo en la memoria de alguien.
| 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 agente dedicado o desechable hace que esas fronteras sean más fáciles de imponer. Un contenedor o un espacio de nombres solo ayuda si su disposición de red y de privilegios aísla de verdad el cambio.
Detenga la conexión, no el programa
Use la ruta de finalización del pipeline para cerrar la conexión que inició este trabajo y eliminar sus credenciales temporales. No empareje procesos por nombre de programa en un host que otros trabajos usan; detenga la conexión concreta. Los dos comandos de abajo son toda la limpieza, y ninguno depende de encontrar un proceso.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"La finalización no es aislamiento: un runner que muere conserva el túnel que abrió, y un proceso detenido a la fuerza se salta el bloque por completo. Por eso el comando de limpieza por sí solo no puede ser todo el diseño. Así falla en la práctica: un trabajo de despliegue se cancela en el paso de copia, el bloque de finalización nunca se ejecuta, y el siguiente trabajo en el mismo host empieza con un túnel vivo y una ruta que apunta a una red que no puede alcanzar. El fallo parece un problema de 'DNS' en la siguiente compilación, horas después de que terminara el trabajo que lo causó.
Registre el nombre del perfil y la ruta de la credencial en la salida del trabajo. Un comando de desconexión desnudo y sin identificador es difícil de auditar después. La línea de registro es también lo que demuestra que el bloque se ejecutó cuando una investigación posterior lo pregunta.
Dé al trabajo un host que nadie más use
La infraestructura desechable elimina el problema de la herencia en lugar de gestionarlo. Un agente nuevo por trabajo empieza sin ruta, sin perfil y sin credenciales de nadie más, y su destrucción limpia lo que el trabajo haya dejado. Eso cuesta más por compilación, y es el precio honesto de una frontera que no depende del código de limpieza. Para trabajos que tocan redes de producción, suele ser la opción más barata una vez contados los incidentes.
Donde un runner compartido tenga que quedarse, pruebe el fallo y la cancelación con el mismo cuidado que la copia correcta. La prueba debería mostrar qué vería el siguiente trabajo si este se hubiera cancelado a mitad de camino. Un trabajo está hecho cuando su acceso y su estado temporal han terminado, no cuando el comando de copia devuelve cero.