Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
È 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. L'archiviazione permanente può essere assegnata ai contenitori in due modi:
- Eseguire il binding dei montaggi
- Volumi denominati
Docker offre un'ottima panoramica su come usare i volumi, quindi è consigliabile leggere quella per primo. 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.
Annotazioni
Il montaggio di bind direttamente su volumi condivisi del cluster (CSV) non è supportato; le macchine virtuali che fungono da host contenitore possono funzionare su un volume CSV.
Autorizzazioni
Il modello di autorizzazione usato per i montaggi di bind varia in base al livello di isolamento del contenitore.
I contenitori che usano Hyper-V isolamento usano un modello di autorizzazione di sola lettura o di lettura/scrittura semplice. È possibile accedere ai file nell'host usando l'account LocalSystem
. Se ti viene negato l'accesso nel contenitore, assicurati che LocalSystem
abbia accesso a quella directory sull'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é usano l'identità del processo all'interno del contenitore per accedere ai dati, vale a dire che gli ACL dei file vengono rispettati. L'identità del processo in esecuzione nel contenitore ("ContainerAdministrator" in Windows Server Core e "ContainerUser" nei contenitori 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 l'uso dei dati.
Poiché queste identità esistono solo all'interno del contesto del contenitore, non nell'host in cui sono archiviati i file, è consigliabile usare un gruppo di sicurezza noto, ad Authenticated Users
esempio quando si configurano gli elenchi di controllo di accesso per concedere l'accesso ai contenitori.
Avvertimento
Non montare directory sensibili come C:\
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 lettura -
docker run -v c:\ContainerData:c:\data:RW
per il permesso di lettura/scrittura -
docker run -v c:\ContainerData:c:\data
per l'accesso in lettura/scrittura (impostazione predefinita)
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.
Montature SMB
In Windows Server versione 1709 e successive, la funzionalità denominata "Mapping globale SMB" consente di montare una condivisione SMB sull'host e di passare le directory di tale condivisione a 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.
Passaggi 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 userà 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 su questo host dei contenitori possono ora avere i volumi di dati mappati al percorso nell'unità G:.
Annotazioni
Quando si usa il mapping globale SMB per i contenitori, tutti gli utenti sull'host del contenitore possono accedere alla condivisione di rete remota. Qualsiasi applicazione in esecuzione nell'host contenitore avrà anche accesso alla condivisione remota mappata.
Creare contenitori con volumi di dati mappati a una condivisione SMB montata globalmente, quindi eseguire il comando docker 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.
La funzionalità lato client SMB di supporto per mapping globale è una caratteristica che può funzionare su qualsiasi server SMB compatibile, tra cui:
- File server a 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)
Annotazioni
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 su Windows dispone di un plug-in predefinito che può creare volumi sul 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
Annotazioni
Windows Server convertirà i percorsi di destinazione (il percorso all'interno del contenitore) in lettere minuscole; ad esempio -v unwound:c:\MyData
, o -v unwound:/app/MyData
nei contenitori Linux, genererà una directory all'interno del contenitore di c:\mydata
o /app/mydata
nei contenitori Linux di cui viene eseguito il mapping (e la creazione, se non esiste).