Armazenamento persistente em contêineres

Você pode ter casos em que é importante que um aplicativo seja capaz de persistir dados em um contêiner ou que você queira mostrar arquivos em um contêiner que não foram incluídos no tempo de build do contêiner. O armazenamento persistente pode ser distribuído em contêineres de algumas maneiras:

• Associar montagens
• Volumes nomeados

O Docker tem uma ótima visão geral de como usar volumes, portanto, é melhor iniciar com essa leitura. O restante desta página se concentra nas diferenças entre o Linux e Windows e fornece exemplos no Windows.

Montagens por associação

As montagens por associação permitem que um contêiner compartilhe um diretório com o host. Isso é útil quando você deseja um lugar para armazenar arquivos no computador local que esteja disponível se você reiniciar um contêiner, ou deseja compartilhá-lo com vários contêineres. Se você quiser que o contêiner seja executado em vários computadores com acesso aos mesmos arquivos, então deverá ser usado um volume nomeado ou uma montagem SMB.

Observação

Não há suporte para a montagem de vinculação diretamente em volumes compartilhados clusterizados (CSV), as máquinas virtuais que atuam como um host de contêiner podem ser executadas em um volume CSV.

Permissões

O modelo de permissão usado para montagens por associação varia de acordo com o nível de isolamento do seu contêiner.

Contêineres que usam o isolamento do Hyper-V usam um modelo de permissão somente leitura ou leitura/gravação simples. Os arquivos são acessados no host com a conta LocalSystem. Se você tiver o acesso negado no contêiner, verifique se LocalSystem tem acesso a esse diretório no host. Quando o sinalizador de somente leitura for usado, as alterações feitas no volume dentro do contêiner não serão visíveis nem persistentes no diretório no host.

Os contêineres do Windows que usam isolamento de processo são ligeiramente diferentes porque usam a identidade do processo dentro do contêiner para acessar os dados, o que significa que as ACLs de arquivo são respeitadas. A identidade do processo em execução no contêiner ("ContainerAdministrator" no Windows Server Core e "ContainerUser" em contêineres Nano Server, por padrão) será usada para acesso aos arquivos e diretórios no volume montado, em vez de LocalSystem, e precisará ter o acesso concedido para usar os dados.

Como essas identidades existem apenas no contexto do contêiner, e não no do host em que os arquivos estão armazenados, você deve usar um grupo de segurança conhecido, como o Authenticated Users, ao configurar as ACLs para conceder acesso aos contêineres.

Aviso

Não faça a montagem por associação de diretórios confidenciais, como o C:\, em um contêiner não confiável. Isso permitiria a ele alterar arquivos no host ao qual ele normalmente não teria acesso e poderia criar uma violação de segurança.

Exemplo de uso:

• docker run -v c:\ContainerData:c:\data:RO para acesso somente leitura
• docker run -v c:\ContainerData:c:\data:RW para acesso de leitura/gravação
• docker run -v c:\ContainerData:c:\data para acesso de leitura/gravação (padrão)

Links simbólicos

Os links simbólicos (symlinks) são resolvidos no contêiner. Se você fizer a montagem por associação de um caminho de host em um contêiner que é um link simbólico, ou contém links simbólicos, o contêiner não conseguirá acessá-los.

Montagens SMB

No Windows Server, versão 1709 ou posterior, um recurso chamado “Mapeamento Global de SMB” torna possível montar um compartilhamento SMB no host e, em seguida, passar diretórios nesse compartilhamento para um contêiner. O contêiner não precisa ser configurado com um servidor, um compartilhamento, um nome de usuário ou uma senha específicos – tudo isso é tratado no host. O contêiner funcionará da mesma forma como se ele tivesse armazenamento local.

Etapas de configuração

1. No host do contêiner, mapeie globalmente o compartilhamento SMB remoto:

   $creds = Get-Credential
   New-SmbGlobalMapping -RemotePath \\contosofileserver\share1 -Credential $creds -LocalPath G:
   

   Este comando usará as credenciais para autenticar com o servidor SMB remoto. Em seguida, mapeie o caminho do compartilhamento remoto para a letra de unidade G: (pode ser qualquer outra letra de unidade disponível). Os contêineres criados nesse host de contêiner agora podem ter seus volumes de dados mapeados para um caminho na unidade G:.

   Observação

   Ao usar o mapeamento global SMB para contêineres, todos os usuários no host do contêiner poderão acessar o compartilhamento remoto. Qualquer aplicativo em execução no host do contêiner também terá acesso ao compartilhamento remoto mapeado.

2. Crie contêineres com volumes de dados mapeados para o compartilhamento SMB montado globalmente docker run -it --name demo -v g:\ContainerData:c:\AppData1 mcr.microsoft.com/windows/servercore:ltsc2019 cmd.exe

   Dentro do contêiner, c:\AppData1 será mapeado para o diretório "ContainerData" do compartilhamento remoto. Quaisquer dados armazenados no compartilhamento remoto mapeado globalmente estarão disponíveis aos aplicativos dentro do contêiner. Vários contêineres podem obter acesso de leitura/gravação a esses dados compartilhados com o mesmo comando.

Esse suporte a mapeamento global SMB é um recurso do lado do cliente SMB que pode funcionar sobre qualquer servidor SMB compatível, incluindo:

• Servidor de arquivos de expansão sobre S2D (Espaços de Armazenamento Diretos) ou uma SAN tradicional
• Arquivos do Azure (compartilhamento SMB)
• Servidor de arquivos tradicional
• Implementação de terceiros do protocolo SMB (ex: para dispositivos NAS)

Observação

O mapeamento global de SMB não dá suporte a pastas DFSN (namespaces do DFS). Por exemplo, se você mapear um compartilhamento raiz DFSN com New-SmbGlobalMapping -LocalPath Z: -RemotePath \\contoso.com\share1', a leitura dos destinos de pasta dessa raiz retornará o erro "O local da rede não pode ser acessado".

Volumes nomeados

Os volumes nomeados permitem que você crie um volume pelo nome, atribua-o a um contêiner e reutilize-o posteriormente usando o mesmo nome. Não é necessário rastrear o caminho real de onde ele foi criado, apenas o nome. O mecanismo do Docker no Windows tem um plug-in de volume nomeado interno que pode criar volumes no computador local. Será necessário um plug-in adicional se você quiser usar volumes nomeados em vários computadores.

Etapas de exemplo:

1. docker volume create unwound — Crie um volume chamado “unwound”
2. docker run -v unwound:c:\data microsoft/windowsservercore — Inicie um contêiner com o volume mapeado para c:\data
3. Grave alguns arquivos em c:\data no contêiner e interrompa o contêiner
4. docker run -v unwound:c:\data microsoft/windowsservercore — Inicie um novo contêiner
5. Execute dir c:\data no novo contêiner – os arquivos ainda estão lá

Observação

O Windows Server converterá os caminhos de destino (o caminho dentro do contêiner) em letras minúsculas, ou seja, -v unwound:c:\MyData ou -v unwound:/app/MyData em contêineres do Linux, resultará em um diretório dentro do contêiner de c:\mydata ou /app/mydata em contêineres do Linux, que serão mapeados (e criados, se não existirem).