A sua aplicação Docker consegue gravar os próprios dados? Lista de verificação das permissões de volumes

Porque é que um contentor em execução pode continuar sem conseguir gravar

Um contentor pode iniciar normalmente enquanto a aplicação não consegue criar, atualizar ou remover ficheiros num diretório de dados montado. O início do contentor confirma que o processo consegue ser executado; não confirma que tenha o acesso de que a aplicação precisa.

Para que uma escrita seja bem-sucedida, a identidade efetiva do processo da aplicação tem de ter acesso adequado ao caminho montado. Uma montagem só de leitura, um diretório-pai inacessível, uma ACL, uma política SELinux ou um mapeamento de espaços de nomes de utilizadores também podem bloquear o acesso. Antes de alterar permissões, diagnostique o caminho e a operação exatos.

• Registe a mensagem de erro da aplicação e o ficheiro ou diretório exato envolvido.
• Determine se a falha afeta uma operação específica, como criar um ficheiro, ou todo o acesso ao diretório de dados.
• Evite alterar permissões recursivamente até saber que identidade e regra de acesso estão a causar o problema.

Identifique a identidade do processo e o caminho montado

Comece por verificar como o contentor está configurado e que montagens o Docker reporta. Para um contentor com o nome myapp, execute:

docker inspect --format '{{json .Mounts}}' myapp

Verifique a origem e o destino da montagem, o tipo e a configuração de leitura/escrita. Uma montagem vinculada aponta para um caminho no anfitrião; um volume nomeado tem uma origem gerida pelo Docker. Confirme que o destino corresponde ao caminho que a aplicação está realmente a tentar utilizar.

Em seguida, inspecione a identidade do contentor com docker exec myapp id. Considere isto uma indicação, não uma prova definitiva da identidade do processo da aplicação: um ponto de entrada pode iniciar com uma identidade e baixar privilégios antes de lançar a aplicação. Consulte a documentação da imagem ou da aplicação sobre o utilizador de execução e, sempre que possível, verifique o próprio processo em execução.

Compare os IDs numéricos de utilizador e de grupo, não apenas os nomes de utilizador. Numa montagem vinculada convencional do Linux, sem remapeamento de utilizadores, a propriedade é numérica tanto no anfitrião como no contentor. Um nome de utilizador aparentemente igual em duas imagens pode corresponder a IDs numéricos diferentes.

• Confirme o nome do contentor, o destino da montagem e o caminho de origem no anfitrião ou o nome do volume.
• Identifique o utilizador e os grupos efetivos do processo da aplicação, incluindo qualquer redução de privilégios após o arranque.
• Registe os IDs numéricos. Os nomes de utilizador, por si só, não permitem comparar a propriedade de forma fiável.

Verifique a propriedade, os bits de permissão e os controlos no anfitrião

Num anfitrião Linux, inspecione a origem da montagem vinculada para ver a propriedade e as permissões numéricas. Substitua /srv/myapp/data pelo caminho real no anfitrião:

ls -ln /srv/myapp/data stat -c '%u:%g %a %n' /srv/myapp/data

Verifique o diretório e os diretórios-pai. O processo precisa de acesso adequado ao longo de todo o caminho; não basta que o diretório final pareça permitir escrita se não for possível percorrer um dos diretórios-pai. Se estiver disponível, namei -l /srv/myapp/data pode ajudar a mostrar as permissões ao longo do caminho.

Se o acesso continuar sem corresponder ao que indicam a propriedade e os bits de modo, verifique as ACLs com getfacl e, nos sistemas que usam SELinux, inspecione o contexto dos ficheiros com ls -Z. Os controlos relevantes no anfitrião e os mapeamentos de identidade dependem da implementação. O Docker sem privilégios e o remapeamento de espaços de nomes de utilizadores podem fazer com que os IDs no anfitrião sejam diferentes dos IDs vistos dentro do contentor.

• Compare o UID e os grupos do processo com o proprietário, o grupo e os bits de permissão do diretório.
• Verifique as permissões para percorrer os diretórios-pai, além do acesso ao diretório final.
• Quando as verificações normais de propriedade não explicarem o resultado, verifique as ACLs, o contexto SELinux e os mapeamentos de espaços de nomes de utilizadores ou do Docker sem privilégios.

Teste as operações de que a aplicação realmente precisa

Uma listagem de permissões não substitui um teste de escrita. Comece por confirmar se o Docker montou o caminho como só de leitura. Uma montagem só de leitura pode impedir intencionalmente a gravação, mesmo que o diretório subjacente pareça permitir escrita.

Teste com a identidade efetiva da aplicação e no destino montado, usando um nome de ficheiro temporário que não substitua dados da aplicação. Se a imagem tiver uma shell e a aplicação for executada com UID 1000 e GID 1000, um exemplo básico é:

docker exec --user 1000:1000 myapp sh -c 'f=/data/.permission-test-$$; : > "$f" && rm "$f"'

Substitua os IDs e /data pelos valores da sua implementação. Este teste verifica a criação e a remoção; não prova que todas as operações da aplicação vão funcionar. Por exemplo, atualizar um ficheiro existente, criar um subdiretório ou mudar o nome de um ficheiro pode ter requisitos diferentes. O teste também pode não reproduzir os grupos suplementares ou outros detalhes do processo da aplicação, por isso interprete-o em conjunto com a identidade do processo e o erro apresentado pela aplicação.

Sempre que possível, verifique também a operação através da própria aplicação. Um teste de shell bem-sucedido é uma indicação útil, mas a aplicação pode utilizar um caminho, uma identidade ou uma operação diferente.

• Use um ficheiro temporário no diretório realmente montado e remova-o depois do teste.
• Teste a criação ou alteração de diretórios apenas se forem operações de que a aplicação precisa.
• Se o teste for bem-sucedido, mas a aplicação continuar a falhar, volte a verificar o caminho, a identidade, os grupos e o erro reais da aplicação.

Resolva incompatibilidades de UID e GID sem usar chmod 777

Quando a propriedade numérica não corresponde à identidade da aplicação, escolha uma solução adequada ao modelo de acesso pretendido. Não presuma que é seguro alterar todos os ficheiros para um UID escolhido por suposição: confirme primeiro a identidade de execução documentada da aplicação e se outros serviços ou administradores também precisam de acesso.

Para um diretório partilhado, coordene um grupo que inclua as identidades dos processos relevantes e conceda apenas o acesso necessário a esse grupo. O bit setgid pode ajudar as novas entradas a herdar o grupo do diretório, mas conceder acesso de escrita ao grupo apenas nos ficheiros existentes não garante que os ficheiros futuros continuem acessíveis ao grupo. O umask da aplicação e quaisquer ACLs predefinidas podem afetar os novos ficheiros.

Um chmod 777 aplicado indiscriminadamente concede acesso amplo e não é uma solução fiável. Por exemplo, não resolve uma montagem só de leitura nem uma restrição SELinux. Prefira a alteração mais restrita de propriedade, grupo, ACL ou montagem que resolva a causa confirmada e faça uma cópia de segurança antes de alterações abrangentes à propriedade.

• Se apenas o proprietário estiver incorreto, confirme o UID pretendido e o âmbito da alteração antes de mudar a propriedade.
• Se vários processos precisarem de acesso, use um grupo acordado e verifique a pertença ao grupo, o comportamento de setgid, o umask e as ACLs predefinidas.
• Se a montagem for só de leitura, corrija a configuração da montagem apenas se a aplicação tiver de gravar nesse local.
• Não use chmod 777 como medida geral de resolução de problemas.

Volte a verificar as permissões quando mudarem as imagens, os anfitriões ou o método de implementação

Uma implementação que funcionava antes pode falhar depois de uma alteração na imagem ou no anfitrião. A nova imagem pode executar a aplicação com outra identidade numérica, mesmo que o nome da conta pareça igual. Uma migração para outro anfitrião também pode alterar a propriedade do diretório da montagem vinculada ou os controlos de acesso do anfitrião.

Os volumes nomeados exigem uma análise específica. Por norma, um volume nomeado vazio é preenchido a partir do diretório da imagem quando é montado sobre esse diretório, a menos que a cópia inicial esteja desativada. Um volume existente não volta a receber a propriedade do diretório da imagem em cada arranque. Os controladores de volume e as opções de montagem podem alterar o comportamento, por isso inspecione a montagem real em vez de confiar numa suposição sobre a inicialização.

Se utilizar o Docker sem privilégios ou o remapeamento de espaços de nomes de utilizadores, tenha em conta o mapeamento de identidades ao comparar os IDs do contentor e do anfitrião. Não execute chown no anfitrião com base apenas num UID do contentor antes de compreender como esse UID é mapeado.

• Antes de atualizar uma imagem, verifique se o utilizador de execução da aplicação ou os caminhos dos dados foram alterados.
• Antes de migrar para outro anfitrião, registe o caminho de origem, a propriedade numérica, as ACLs, o contexto de segurança e a configuração da montagem.
• No caso de volumes nomeados, distinga um volume recém-criado de um existente e verifique o respetivo conteúdo e propriedade atuais.
• Em configurações sem privilégios ou com remapeamento, confirme o mapeamento antes de alterar a propriedade no anfitrião.

Documente o acesso esperado e verifique-o após a migração

Mantenha um registo breve do caminho dos dados, do tipo de volume, do UID e dos grupos da aplicação, das operações de leitura e escrita necessárias e de quaisquer definições deliberadas de ACL ou de segurança do anfitrião. Indique se a montagem é só de leitura e se existe remapeamento de identidades. Assim, será mais fácil verificar a próxima atualização ou migração.

Após uma migração, atualização de imagem ou alteração da implementação, repita a inspeção e o teste. Confirme que a aplicação consegue realizar as operações de que depende, e não apenas que o contentor inicia. Mantenha uma cópia recuperável dos dados importantes antes de alterar a propriedade ou os controlos de acesso.

Uma implementação gerida pode reduzir o trabalho de infraestrutura a cargo de uma equipa, mas não elimina a necessidade de tomar decisões informadas sobre dados, acesso e recuperação. A Airbip disponibiliza implementação gerida para aplicações do catálogo executadas como cargas de trabalho Docker em servidores cloud da Airbip, com gestão do ciclo de vida dos serviços e cópias de segurança diárias, semanais e mensais configuráveis. Consulte o site atual da Airbip para conhecer os planos e termos em vigor e confirme se uma abordagem gerida se adequa aos seus requisitos operacionais e de dados.

• Documente as identidades numéricas, os detalhes da montagem, as operações esperadas e quaisquer controlos não predefinidos no anfitrião.
• Repita o teste de escrita real após uma migração ou atualização e investigue as falhas antes de confiar na implementação.
• Defina claramente as responsabilidades pela propriedade e recuperação dos dados, quer administre o servidor por conta própria quer utilize alojamento gerido.