Problemas Conhecidos
Esses problemas conhecidos foram identificados no serviço Data Science.
Consulte também Solução de Problemas.
Falha de Remapeamento do Namespace do Usuário Linux com um Contêiner do Docker
- Detalhes
-
O recurso de namespace de usuário (
userns
) do kernel do Linux adiciona outra camada de segurança aos contêineres Linux. Ele permite que uma máquina host execute contêineres fora do namespace de ID de usuário (UID) ou ID de grupo (GID). Isso significa que todos os contêineres podem ter uma conta raiz (UID 0) em seu próprio namespace e executar processos sem receber privilégios raiz da máquina host. Quando umuserns
é criado, o kernel do Linux fornece um mapeamento entre o contêiner e a máquina host. Por exemplo, se você iniciar um contêiner e executar um processo com UID 0 nele (geralmente, a conta raiz no contêiner), o kernel do Linux mapeará o UID 0 do contêiner para um UID não privilegiado na máquina host. Isso permite que o contêiner execute um processo como se fosse o usuário raiz, enquanto realmente está sendo executado pelo usuário não raiz na máquina host.O erro é causado por uma falha de remapeamento
userns
. Quando os arquivos da máquina host são configurados com um UID ou GID válido para remapeamento, o UID ou GID deve estar no intervalo de 0 a 65535. Quando um job inicia o contêiner do Docker, o Docker extrai uma imagem e extrai camadas dessa imagem. Se uma camada contiver arquivos com UID ou GID fora da faixa aceita, o Docker não poderá remapear com sucesso, de modo que o contêiner não é iniciado.Por exemplo, se existir um arquivo com UID e GID maiores na faixa permitida. Se você copiar esse arquivo para a imagem do Docker, ele poderá manter o UID e o GID altos.
Se você executar a imagem do contêiner e o arquivo precisar ser usado no contêiner, o contêiner falhará.
- Solução alternativa 1
-
Certifique-se de que nenhum dos arquivos usados na imagem do Docker tenha UID ou GID alto.
- Solução alternativa 2
-
Se você não souber qual arquivo tem UID ou GID alto na imagem, poderá encontrá-los com:
-
Informe o contêiner com:
docker run it <image-name> sh
-
Procurar arquivos com UID/GID alto:
-
Localizar usuários:
find / \( -uid 1000000 \) -ls 2>/dev/null
-
Localizar grupos:
find / \( -gid 1000000 \) -ls 2>/dev/null
O número
1000000
é diferente porque é o erro de ID. -
- Se você localizar os arquivos, certifique-se de que o UID ou GID seja menor, no local em que o arquivo está armazenado ou no contêiner.
-
- Solução alternativa 3
-
No arquivo do Docker, após copiar os arquivos necessários na imagem, execute um dos seguintes:
Na pasta:
RUN chown -R root:root /root
Diretamente no arquivo:
RUN chown -R root:root job_logs.py
OSError: [Errno 28] Não há espaço no dispositivo
- Detalhes
-
Esse erro ocorre quando você usa um armazenamento de sistema de arquivos local que não está em
/home/datascience
.Em jobs, você pode especificar o tamanho do armazenamento em blocos. O armazenamento em blocos é montado na pasta local
/home/datascience
que você pode usar durante a execução do job. Ele tem um tamanho de armazenamento igual ao tamanho definido do armazenamento em blocos antes da execução do job. Se você usar ou criar um diretório fora desse local, ele poderá ficar rapidamente sem espaço e a mensagem de erro será exibida. Isso depende do tamanho do conteúdo que está sendo armazenado. - Solução alternativa
-
Certifique-se de sempre trabalhar na pasta principal que tenha o tamanho total do armazenamento em blocos, que é
/home/datascience
. Crie, edite e faça download de todo o conteúdo nesse local. Crie diretórios nesse local.
Imagem do Docker na Apple e M1 MacBook
- Detalhes
-
Por padrão, o Docker em um M1 MacBook cria imagens
linux/arm64
, que só funcionam nas máquinas que estão usando a arquitetura ARM. As máquinas baseadas em Intel usam a arquitetura AMD. Como resultado, as imagens do docker criadas em um M1 MacBook podem não funcionar em máquinas baseadas em Intel. - Solução alternativa
- Nenhum.