do que se trata?

Trata-se de um problema bastante técnico no uso de contêineres docker que interagem com o computador host do docker, geralmente relacionado ao uso do sistema de arquivos host dentro do contêiner.
Isso acontece em particular em contextos de pesquisa reproduzíveis.
Desenvolvi um utilitário de código aberto que ajuda a resolver esse problema.

contêineres docker como ambientes de execução

O caso de uso inicial e principal de um contêiner docker: um aplicativo autocontido que interage apenas com o sistema host com algumas portas de rede.
Pense em uma aplicação web: o contêiner docker normalmente contém um servidor web e uma aplicação web, rodando, por exemplo, na porta 80 (dentro do contêiner). O contêiner é então executado no host, ligando a porta interna 80 do contêiner a uma porta do host (por exemplo, 8000).
Então, a única interação entre o aplicativo em contêiner e o sistema host é por meio dessa porta de rede vinculada.

Contêineres como ambientes de execução são completamente diferentes:

• em vez de contentorizar uma aplicação, é o sistema de construção de aplicações que é contentorizado.
  • poderia ser um compilador, um IDE, um motor de notebook, um sistema de publicação Quarto...
• os objetivos são:
  • ter um ambiente padrão, fácil de instalar e compartilhar
    • imagine um ambiente de construção complexo, com versões fixas de R, python e zilhões de pacotes externos. Instalar tudo com as versões corretas pode ser uma tarefa muito difícil e demorada. Compartilhar uma imagem docker contendo tudo já instalado e pré-configurado economiza muito tempo.
  • ter um ambiente reprodutível
    • ao utilizá-lo, você consegue reproduzir alguns resultados de análises, já que está utilizando o mesmo ambiente controlado
    • você também pode reproduzir bugs facilmente, que é o primeiro passo para corrigi-los

Mas, para usar esses ambientes de execução, esses contêineres devem ter acesso ao sistema host, em particular ao sistema de arquivos do usuário host.

contêineres docker e o sistema de arquivos host

Suponha que você tenha conteinerizado um IDE, por exemplo. Rstudio.
Seu Rstudio está instalado e rodando dentro do contêiner docker, mas precisa ler e editar arquivos na pasta do seu projeto.

Para isso você bind mount a pasta do seu projeto (no sistema de arquivos host) usando a opção docker run --volume.
Então, seus arquivos estarão acessíveis no contêiner do docker.

O desafio agora são as permissões dos arquivos. Suponha que seu usuário host tenha o ID de usuário 1001 e suponha que o usuário que possui o processo Rsudio no contêiner seja 0 (root) ou 1002.

Se o usuário do contêiner for root, então não haverá problemas ao ler seus arquivos.
Mas assim que você editar alguns arquivos existentes e produzir novos (por exemplo, pdf, html), esses arquivos pertencerão à raiz também no sistema de arquivos host!.
O que significa que o usuário do host local não poderá usá-los ou excluí-los, pois pertencem ao root.

Agora, se o ID do usuário do contêiner for 1002, o Rstudio pode não conseguir ler seus arquivos, editá-los ou produzir novos arquivos.
Mesmo que possa, ao definir algumas permissões muito permissivas, o usuário do host local pode não conseguir usá-las.

É claro que uma maneira de resolver esse problema com força bruta é executar com root no computador host e dentro do contêiner do docker. Isso nem sempre é possível e levanta algumas preocupações críticas de segurança óbvias.

resolvendo o problema do proprietário do arquivo, parte 1: a opção docker run --user

Como não podemos saber com antecedência qual será o ID do usuário do host (aqui 1001), não podemos pré-configurar
o ID do usuário do contêiner do docker.

docker run agora fornece uma opção --user que permite criar um pseudo usuário com algum ID de usuário fornecido
em tempo de execução. Por exemplo, docker run --user 1001 ... criará um contêiner docker em execução com processos
pertencente a um usuário com ID de usuário 1001.

Então, o que ainda estamos discutindo sobre esse assunto? Não está resolvido?

Aqui estão algumas peculiaridades sobre esse usuário criado dinamicamente:

• é um pseudousuário
• não possui um diretório inicial (/home/xxx)
• não aparece em /etc/passwd
• não pode ser pré-configurado, por ex. com um perfil bash, alguns env vars, padrões de aplicativos etc...

Podemos contornar esses problemas, mas isso pode ser tedioso e frustrante.
O que realmente gostaríamos é pré-configurar um usuário do contêiner docker e ser capaz de alterar dinamicamente seu userid em runtime...

resolvendo o problema do proprietário do arquivo, parte 2: insira docker_userid_fixer

docker_userid_fixer é um utilitário de código aberto destinado a ser usado como um ponto de entrada do docker para corrigir o problema de ID do usuário que acabei de levantar.

Vamos ver como usá-lo: você o configura como seu docker ENTRYPOINT, especificando qual usuário deve ser usado e tem seu userid modificado dinamicamente:

ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]

Sejamos precisos em nossos termos:

• o usuário alvo, é o usuário solicitado ao docker_userid_fixer, aqui user1
• o usuário solicitado, é o usuário provisionado pelo docker run, ou seja, o usuário que (inicialmente) possui o primeiro processo (PID 1)

Então, na criação do tempo de execução do contêiner, existem duas opções:

• ou o ID do usuário solicitado (já) corresponde ao ID do usuário alvo, então nada precisa ser alterado
• ou não. Por exemplo, o ID do usuário solicitado é 1001, e o ID do usuário target é 100. Em seguida, docker_userid_fixer corrigirá o ID do usuário do usuário target user1 de 1000 a 1001, diretamente no processo principal do contêiner.

Então, na prática, isso resolve nosso problema:

• se você não precisar corrigir o ID do usuário do contêiner, basta usar docker run da maneira usual (sem a opção --user)
• ou você usa a opção --user, além de executar seu processo principal com um ID de usuário solicitado, ele modificará seu usuário pré-configurado para o ID de usuário solicitado, para que seu contêiner esteja sendo executado com o usuário pretendido e pretendido ID do usuário.

configuração do docker_userid_fixer

Você pode encontrar instruções sobre a configuração aqui.

Mas tudo se resume a:

• crie ou baixe o pequeno executável (17k)

• copie-o para sua imagem docker

• torne-o executável como setuid root

• configure-o como seu ponto de entrada

os detalhes sangrentos

Coloquei algumas notas curtas https://github.com/kforner/docker_userid_fixer#how-it-works
mas vou tentar reformular.

O ponto crucial da implementação é o setuid root do executável docker_userid_fixer no contêiner.
Precisamos de permissões de root para alterar o ID do usuário, e este setuid permite essa execução privilegiada apenas para
o docker_userid_fixerprogram, e isso por um período muito curto.

Assim que o ID do usuário for modificado, se necessário, docker_userid_fixer mudará o processo principal
para o usuário solicitado (e ID do usuário!).

Se você estiver interessado nestes tópicos (docker, pesquisa reproduzível, desenvolvimento de pacotes R, algorítmico, otimização de desempenho, paralelismo...) não hesite em entrar em contato comigo para discutir oportunidades de emprego e negócios.