La configurazione VPN sopravvive alla ricreazione del container solo se la monti
Un file modificato dentro un container in esecuzione vive in uno strato che scompare. Confronta bind mount, volumi e segreti, poi ricrea e verifica quattro cose.
Modifichi la configurazione di WireGuard dentro un container in esecuzione, funziona, e il prossimo aggiornamento dell'immagine la cancella. Niente era configurato male. Il file viveva nello strato scrivibile del container, che esiste solo per quell'istanza del container. Il confronto che conta non è quale strumento usare, ma quali input dichiara il tuo deployment. Tutto ciò che hai modificato a mano è un input che il deployment non conosce.
Due tipi di stato, uno è usa e getta
Un container ha uno strato scrivibile per le modifiche fatte a runtime, e quello strato viene scartato quando il container viene sostituito. Non è un archivio di configurazione e non è un backup. L'immagine più gli input dichiarati sono la definizione completa di ciò che viene eseguito.
Chiediti quali dei tuoi file VPN sono input dichiarati e quali sono incidenti:
docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpnIl diff elenca cosa è cambiato nello strato scrivibile, ed è esattamente l'insieme delle cose che spariranno. L'elenco dei mount mostra cosa sopravvive. Confrontare i due risponde alla domanda prima che tu perda qualcosa.
Bind mount, volume con nome o secret: cosa protegge ciascuno
Tutti e tre possono contenere un profilo VPN, e differiscono in chi può leggerlo e in cosa succede alla sostituzione.
| 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 mappa un percorso dell'host, quindi il file è protetto quanto quel percorso ed è visibile quanto lo consentono i permessi dell'host. Un volume con nome è gestito dal runtime e sopravvive alla rimozione del container, il che lo rende l'impostazione predefinita più sicura per lo stato che il deployment possiede. Un meccanismo di secret è per materiale che non vuoi in un'immagine o in una variabile d'ambiente.
Non trattare ogni variabile d'ambiente e ogni file dell'host come una protezione equivalente, perché non lo sono.
Modificare dentro il container è la trappola
La trappola non è lo strumento, è la direzione della modifica. Una modifica fatta dentro un container in esecuzione è invisibile al deployment, quindi la ricreazione successiva la annulla in silenzio e il sintomo sembra una regressione nell'immagine. Se devi fare una modifica lì per diagnosticare, copiala subito fuori e mettila nell'input dichiarato. Poi ricrea per dimostrare che il deployment la riproduce.
Un profilo può portare chiavi private e materiale dell'account, il che rende un backup di quel file un compito di gestione dei segreti invece di una copia di file. Mantieni proprietà e accesso in lettura limitati al processo reale del container, invece di allargare una directory dell'host per far sparire un errore di permessi.
Quell'allargamento è il modo in cui una comodità nel container diventa un'esposizione dell'host.
Ricrea deliberatamente, poi verifica quattro cose
Annota la versione dell'immagine, il dispositivo e le capacità richiesti, il collegamento di rete e gli input persistenti. L'elenco di dispositivo e capacità conta in particolare per un container VPN, perché il tunnel ha bisogno del dispositivo di rete e del privilegio per configurarlo.
Conferma quale stato di runtime generato deve essere ricostruito invece che salvato. Le chiavi che il tunnel ha generato al primo avvio sono stato, e se conservarle o rigenerarle è una decisione con conseguenze per ogni peer che conosce la vecchia chiave pubblica.
Dopo una ricreazione controllata, verifica identità, instradamento, DNS e il blocco di guasto richiesto. Un processo che parte senza errori non dimostra nessuno di quei quattro. Controllalo mentre il tunnel è attivo e di nuovo dopo averlo fermato, perché il blocco di guasto si mostra solo quando il tunnel sparisce.
Mantieni una copia di ripristino fuori dal container
Mantieni una copia di ripristino che vive indipendentemente dal container, e prova a ripristinarla con il processo documentato. Un backup non testato di un profilo VPN è una speranza, soprattutto quando il percorso di ripristino implica permessi che il processo del container richiede.
Se un container proprietario di una VPN viene sostituito, coordina le applicazioni che condividono il suo stack di rete nel ciclo di vita supportato dal runtime.
Quel coordinamento è la differenza tra un riavvio e un'interruzione. Il deployment dovrebbe descrivere da dove viene la configurazione, e la documentazione dei volumi è il posto dove controllare cosa il runtime conserva davvero.