La configuration VPN ne survit à la recréation du conteneur que si vous la montez
Un fichier modifié dans un conteneur en cours d'exécution vit dans une couche qui disparaît. Comparez les bind mounts, les volumes et les secrets, puis recréez et vérifiez quatre choses.
Vous modifiez la configuration WireGuard à l'intérieur d'un conteneur en cours d'exécution, cela fonctionne, et la prochaine mise à jour de l'image l'efface. Rien n'était mal configuré. Le fichier vivait dans la couche inscriptible du conteneur, qui n'existe que pour cette instance du conteneur. La comparaison qui compte n'est pas quel outil utiliser, mais quelles entrées votre déploiement déclare. Tout ce que vous avez modifié à la main est une entrée que le déploiement ne connaît pas.
Deux sortes d'état, dont l'une est jetable
Un conteneur possède une couche inscriptible pour les changements faits à l'exécution, et cette couche est jetée lorsque le conteneur est remplacé. Ce n'est pas un magasin de configuration et ce n'est pas une sauvegarde. L'image plus les entrées déclarées constituent la définition complète de ce qui s'exécute.
Demandez quels sont vos fichiers VPN qui sont des entrées déclarées et lesquels sont des accidents :
docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpnLe diff liste ce qui a changé dans la couche inscriptible, soit exactement l'ensemble des choses qui vont disparaître. La liste des montages montre ce qui survit. Comparer les deux répond à la question avant que vous ne perdiez quoi que ce soit.
Bind mount, volume nommé ou secret : ce que chacun protège
Les trois peuvent contenir un profil VPN, et ils diffèrent par qui peut le lire et par ce qui se passe au remplacement.
| Mechanism | Survives recreation | Who can read it |
|---|---|---|
| Writable layer | No | Anyone with container access, until it is gone |
| Bind mount | Yes, while the host path exists | Whatever the host permissions allow |
| Named volume | Yes, until the volume is removed | Managed by the runtime |
| Secret | Yes, as a declared input | The container process, by design |
Un bind mount associe un chemin de l'hôte, donc le fichier est aussi protégé que ce chemin et aussi visible que les permissions de l'hôte le permettent. Un volume nommé est géré par le runtime et survit à la suppression du conteneur, ce qui en fait le choix par défaut le plus sûr pour l'état que possède le déploiement. Un mécanisme de secret est destiné aux données que vous ne voulez pas dans une image ou une variable d'environnement.
Ne traitez pas chaque variable d'environnement et chaque fichier de l'hôte comme une protection équivalente, car ils ne le sont pas.
Modifier à l'intérieur du conteneur est le piège
Le piège n'est pas l'outil, c'est la direction de la modification. Un changement fait dans un conteneur en cours d'exécution est invisible pour le déploiement, donc la recréation suivante l'annule silencieusement et le symptôme ressemble à une régression dans l'image. Si vous devez y faire un changement pour diagnostiquer, copiez-le immédiatement à l'extérieur et mettez-le dans l'entrée déclarée. Recréez ensuite pour prouver que le déploiement le reproduit.
Un profil peut porter des clés privées et des données de compte, ce qui fait d'une sauvegarde de ce fichier une tâche de gestion de secrets plutôt qu'une copie de fichier. Gardez la propriété et l'accès en lecture limités au processus réel du conteneur, au lieu d'élargir un répertoire de l'hôte pour faire disparaître une erreur de permissions.
Cet élargissement est la façon dont une commodité dans le conteneur devient une exposition de l'hôte.
Recréez délibérément, puis vérifiez quatre choses
Notez la version de l'image, le périphérique et les capacités requis, le rattachement réseau et les entrées persistantes. La liste des périphériques et des capacités compte particulièrement pour un conteneur VPN, car le tunnel a besoin du périphérique réseau et du privilège de le configurer.
Confirmez quel état d'exécution généré doit être reconstruit plutôt que conservé. Les clés que le tunnel a générées au premier démarrage sont de l'état, et les garder ou les régénérer est une décision aux conséquences pour chaque pair qui connaît l'ancienne clé publique.
Après une recréation contrôlée, vérifiez l'identité, le routage, le DNS et le blocage en cas de défaillance requis. Un processus qui démarre sans erreur ne prouve aucun de ces quatre points. Vérifiez-le pendant que le tunnel est actif et de nouveau après l'avoir arrêté, car le blocage en cas de défaillance ne se montre que lorsque le tunnel disparaît.
Gardez une copie de récupération hors du conteneur
Gardez une copie de récupération qui vit indépendamment du conteneur, et testez sa restauration via le processus documenté. Une sauvegarde non testée d'un profil VPN est un espoir, surtout lorsque le chemin de restauration implique des permissions dont le processus du conteneur a besoin.
Si un conteneur propriétaire d'un VPN est remplacé, coordonnez les applications qui partagent sa pile réseau dans le cycle de vie pris en charge par le runtime.
Cette coordination est la différence entre un redémarrage et une panne. Le déploiement devrait décrire d'où vient la configuration, et la documentation des volumes est l'endroit où vérifier ce que le runtime conserve réellement.