Archiviazione permanente nei contenitori
È possibile che si verifichino casi in cui è importante che un'app possa salvare in modo permanente i dati in un contenitore o che si desideri visualizzare in un contenitore file che non erano stati inclusi in fase di compilazione del contenitore. È possibile assegnare un archivio permanente ai contenitori in due modi:
- Eseguire il binding dei montaggi
- Volumi denominati
Docker offre una panoramica di come usare i volumi , quindi è consigliabile leggere prima di tutto questo. La parte restante di questa pagina è incentrata sulle differenze tra Linux e Windows e fornisce esempi in Windows.
Associa montaggi
I montaggi di associazione consentono a un contenitore di condividere una directory con l'host. Ciò è utile se si vuole che un luogo archivii i file nel computer locale disponibili se si riavvia un contenitore o si vuole condividerlo con più contenitori. Se si vuole che un contenitore venga eseguito in più computer con accesso agli stessi file, occorre invece usare un volume denominato oppure montare una condivisione SMB.
Nota
Il montaggio di binding direttamente nei volumi condivisi cluster (CSV) non è supportato, le macchine virtuali che fungono da host contenitore possono essere eseguite in un volume CSV.
Autorizzazioni
Il modello di autorizzazione usato per i montaggi di associazione varia in base al livello di isolamento per il contenitore.
I contenitori che usano l'isolamento Hyper-V adottano un modello di autorizzazione semplice in sola lettura o in lettura/scrittura. È possibile accedere ai file nell'host usando l'account LocalSystem
. Se viene negato l'accesso nel contenitore, assicurarsi di LocalSystem
avere accesso a tale directory nell'host. Quando viene usato il flag di sola lettura, le modifiche apportate al volume all'interno del contenitore non saranno visibili o persistenti nella directory nell'host.
I contenitori di Windows che usano l'isolamento del processo sono leggermente diversi perché utilizzano l'identità del processo all'interno del contenitore per accedere ai dati, vale a dire che vengono rispettati gli ACL dei file. L'identità del processo in esecuzione nel contenitore ("Container Amministrazione istrator" in Windows Server Core e "ContainerUser" nei contenitori di Nano Server, per impostazione predefinita) verrà usata per accedere ai file e alle directory nel volume montato invece di LocalSystem
e dovrà essere concesso l'accesso per usare i dati.
Poiché queste identità esistono solo nel contesto del contenitore e non nell'host in cui sono archiviati i file, è consigliabile utilizzare un gruppo di sicurezza ben noto, ad esempio Authenticated Users
quando si configurano gli ACL per concedere l'accesso ai contenitori.
Avviso
Non associare directory sensibili al montaggio, ad C:\
esempio in un contenitore non attendibile. Ciò consentirebbe di modificare i file nell'host a cui normalmente non avrebbe accesso e potrebbe creare una violazione della sicurezza.
Sintassi di esempio:
docker run -v c:\ContainerData:c:\data:RO
per l'accesso in sola letturadocker run -v c:\ContainerData:c:\data:RW
per l'accesso in lettura e scritturadocker run -v c:\ContainerData:c:\data
per l'accesso in lettura e scrittura (predefinito)
Collegamenti simbolici
I collegamenti simbolici vengono risolti nel contenitore. Se si associa un percorso host a un contenitore che è un collegamento simbolico o contiene collegamenti simbolici, il contenitore non sarà in grado di accedervi.
Montaggi SMB
In Windows Server versione 1709 e successive, una nuova funzionalità denominata "mapping globale SMB" consente di montare una condivisione SMB nell'host e quindi di passare le directory della condivisione in un contenitore. Non è necessario configurare il contenitore con un server, una condivisione, un nome utente o una password specifici, ovvero tutti gestiti nell'host. Il contenitore funzionerà allo stesso modo di se avesse una risorsa di archiviazione locale.
Procedura di configurazione
Nell'host contenitore eseguire il mapping globale della condivisione SMB remota:
$creds = Get-Credential New-SmbGlobalMapping -RemotePath \\contosofileserver\share1 -Credential $creds -LocalPath G:
Questo comando utilizzerà le credenziali per l'autenticazione con il server SMB remoto. Eseguire quindi il mapping del percorso di condivisione remota a G: lettera di unità (può essere qualsiasi altra lettera di unità disponibile). I contenitori creati in questo host contenitore possono ora avere i volumi di dati mappati a un percorso nell'unità G: .
Nota
Quando si utilizza il mapping globale SMB per i contenitori, tutti gli utenti nell'host contenitore possono accedere alla condivisione remota. Qualsiasi applicazione in esecuzione nell'host contenitore avrà anche accesso alla condivisione remota mappata.
Crea i contenitori con i volumi di dati mappati a una condivisione SMB montata a livello globale run -it --name demo -v g:\ContainerData:c:\AppData1 mcr.microsoft.com/windows/servercore:ltsc2019 cmd.exe
All'interno del contenitore, c:\AppData1 verrà quindi mappato alla directory "ContainerData" della condivisione remota. Tutti i dati archiviati in una condivisione remota mappata a livello globale saranno disponibili per le applicazioni all'interno del contenitore. Più contenitori possono ottenere l'accesso in lettura/scrittura a questi dati condivisi con lo stesso comando.
Questo supporto per mapping globale SMB è una funzionalità lato client SMB che può funzionare su qualsiasi server SMB compatibile, tra cui:
- File server di scalabilità orizzontale su Spazi di archiviazione diretta (S2D) o san tradizionale
- File di Azure (condivisione SMB)
- File server tradizionale
- Implementazione di terze parti del protocollo SMB (ad esempio: appliance NAS)
Nota
Il mapping globale SMB non supporta le cartelle DFS Namespaces (DFSN). Ad esempio, se si esegue il mapping di una condivisione radice DFSN con New-SmbGlobalMapping -LocalPath Z: -RemotePath \\contoso.com\share1'
, la lettura delle destinazioni della cartella della radice restituirà l'errore "Impossibile raggiungere il percorso di rete".
Volumi denominati
I volumi denominati consentono di creare un volume in base al nome, assegnarlo a un contenitore e riutilizzarlo in un secondo momento con lo stesso nome. Non è necessario tenere traccia del percorso effettivo in cui è stato creato, ma solo il nome. Il motore Docker in Windows dispone di un plug-in volume denominato predefinito che può creare volumi nel computer locale. Se si desidera usare volumi denominati in più computer, è necessario un plug-in aggiuntivo.
Passaggi di esempio:
docker volume create unwound
- Creare un volume denominato 'unwound'docker run -v unwound:c:\data microsoft/windowsservercore
- Avviare un contenitore con il volume mappato a c:\data- Scrivere alcuni file in c:\data nel contenitore, quindi arrestare il contenitore
docker run -v unwound:c:\data microsoft/windowsservercore
- Avviare un nuovo contenitore- Eseguire
dir c:\data
nel nuovo contenitore: i file sono ancora presenti
Nota
Windows Server converte i percorsi di destinazione (il percorso all'interno del contenitore) in lettere minuscole; quindi -v unwound:c:\MyData
, o -v unwound:/app/MyData
nei contenitori Linux, saranno convertiti nelle directory c:\mydata
, o /app/mydata
nei contenitori Linux (che verranno mappate e create se non esistenti).