VPN pour runner de CI : le tunnel survit-il au build ?
Un runner de CI partagé conserve des routes et des processus entre les jobs. Planifiez les états du VPN avant, pendant et après le job, et ne nettoyez que la connexion que le job possède.
Un job de déploiement se connecte, copie son artefact et signale sa réussite. Le tunnel qu'il a ouvert peut encore être actif au démarrage du job suivant, et la route qu'il a modifiée appartient à tout l'hôte. Le résultat d'un build décrit la commande, pas l'état qu'il a laissé derrière lui. Traitez le VPN comme une ressource dotée d'une durée de vie, pas comme une ligne au début d'une étape.
Ce qui d'autre tourne sur cet hôte
Un nœud Jenkins peut exécuter plusieurs exécuteurs à la fois, et un job qui modifie les routes de l'hôte, les réglages du résolveur ou une connexion à l'échelle du système les modifie pour tout le monde. Qu'un autre job s'en aperçoive dépend de la politique de routes et de filtrage, non d'une règle générale sur les VPN. L'accès au dépôt, l'accès aux artefacts et le canal de contrôle sont des exigences distinctes dont le runner a toujours besoin. Ajoutez-les à la liste des destinations de déploiement avant de choisir un tunnel complet.
Si le canal de contrôle devait traverser le tunnel, la conception doit le dire délibérément. Le découvrir pendant un retour arrière n'est pas un plan. Écrivez les deux listes : ce que le job doit atteindre en privé et ce que le runner doit atteindre quoi qu'il arrive.
Ce job a-t-il vraiment besoin d'un accès privé ?
Demandez, avant d'ajouter le tunnel, si l'étape de build en a besoin. Un agent de déploiement privé peut récupérer un artefact approuvé et effectuer le déploiement, ce qui garde l'étape de build générale hors du réseau privé. Cette séparation est généralement moins chère que d'apprendre à chaque étape de build à passer par un tunnel.
Choisissez la frontière à partir du flux de travail, pas de l'habitude. Si la réponse est non, le reste de cette page est inutile, et c'est le meilleur résultat disponible.
L'état que le job suivant hérite
Décrivez ce qui doit être vrai avant le job, pendant qu'il dispose d'un accès privé et après qu'il s'est terminé, y compris en cas d'annulation. L'état final est celui qui reste le plus souvent implicite, et c'est celui que le job suivant hérite. Écrivez-le à côté du pipeline au lieu de le laisser dans la mémoire de quelqu'un.
| 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 agent dédié ou jetable rend ces frontières plus faciles à faire respecter. Un conteneur ou un espace de noms n'aide que si son agencement réseau et de privilèges isole réellement le changement.
Arrêtez la connexion, pas le programme
Utilisez le chemin de finalisation du pipeline pour fermer la connexion que ce job a ouverte et supprimer ses identifiants temporaires. Ne faites pas correspondre des processus par nom de programme sur un hôte que d'autres jobs utilisent ; arrêtez la connexion précise à la place. Les deux commandes ci-dessous constituent tout le nettoyage, et aucune ne dépend de la découverte d'un processus.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"La finalisation n'est pas une isolation : un runner qui meurt garde le tunnel qu'il a ouvert, et un processus arrêté de force saute complètement le bloc. C'est pourquoi la commande de nettoyage seule ne peut pas être toute la conception. Voici comment cela échoue en pratique : un job de déploiement est annulé à l'étape de copie, le bloc de finalisation ne s'exécute jamais, et le job suivant sur le même hôte démarre avec un tunnel actif et une route qui pointe vers un réseau qu'il ne peut pas atteindre. La panne ressemble à un problème de 'DNS' dans le build suivant, des heures après la fin du job qui l'a causée.
Consignez le nom du profil et le chemin de l'identifiant dans la sortie du job. Une commande de déconnexion nue et sans identifiant est difficile à auditer ensuite. La ligne de journal est aussi ce qui prouve que le bloc a tourné quand une enquête ultérieure le demande.
Donnez au job un hôte que personne d'autre n'utilise
L'infrastructure jetable supprime le problème d'héritage au lieu de le gérer. Un agent neuf par job démarre sans route, sans profil et sans identifiant d'autrui, et sa destruction nettoie ce que le job a laissé. Cela coûte plus cher par build, et c'est le prix honnête d'une frontière qui ne dépend pas du code de nettoyage. Pour les jobs qui touchent des réseaux de production, c'est généralement l'option la moins chère une fois les incidents comptés.
Là où un runner partagé doit rester, testez l'échec et l'annulation avec autant de soin que la copie réussie. Le test devrait montrer ce que verrait le job suivant si celui-ci était annulé à mi-chemin. Un job est terminé quand son accès et son état temporaire ont pris fin, pas quand la commande de copie renvoie zéro.