A construção do docker do fastzero_app falha no código-fonte das Aulas 10 a 12

[K-dash]

@dunossauro
Olá.
Gostaria de relatar um problema encontrado relacionado ao título mencionado. Vou enviar um pull request em breve.

Conteúdo

Ao clonar o repositório principal mais recente e executar docker build -t "fast_zero" . usando o código-fonte da Aula 10 a 12, ocorreu o seguinte erro:

❯ docker build -t "fast_zero" .
[+] Building 7.6s (10/10) FINISHED
 => [internal] load build definition from Dockerfile 0.0s
 => => transferring dockerfile: 303B 0.0s
...

 => [4/6] RUN pip install poetry 5.3s
 => [5/6] RUN poetry config installer.max-workers 10 0.3s 
 => ERROR [6/6] RUN poetry install --no-interaction --no-ansi 0.4s 
------
 > [6/6] RUN poetry install --no-interaction --no-ansi: 
0.277 Skipping virtualenv creation, as specified in config file. 
0.347 Installing dependencies from lock file 
0.388 
0.388 pyproject.toml changed significantly since poetry.lock was last generated. Run `poetry lock [--no-update]` to fix the lock file.
------
Dockerfile:10
--------------------
   8 |     
   9 |     RUN poetry config installer.max-workers 10
  10 | >>> RUN poetry install --no-interaction --no-ansi
  11 |     
  12 |     EXPOSE 8000
--------------------
ERROR: failed to solve: process "/bin/sh -c poetry install --no-interaction --no-ansi" did not complete successfully: exit code: 1

Este erro ocorre porque o arquivo poetry.lock não está em conformidade com o arquivo pyproject.toml. Então, em cada um dos diretórios das Aulas 10 a 12, executei poetry lock --no-update para atualizar o arquivo poetry.lock.

❯ poetry lock --no-update      
Resolving dependencies... (0.1s)

Writing lock file

Depois de atualizar o arquivo poetry.lock, executei novamente docker build -t "fast_zero" ., mas ocorreu um novo erro:

❯ docker build -t "fast_zero" .
[+] Building 10.5s (10/10) FINISHED
 => [internal] load build definition from Dockerfile 0.0s
 => => transferring dockerfile: 303B 0.0s
 => [internal] load metadata for docker.io/library/python:3.11-slim 2.0s
 => [internal] load .dockerignore 0.0s
 => => transferring context: 2B 0.0s
 => [1/6] FROM docker.io/library/python:3.11-slim@sha256:fc39d2e68b554c3f0a5cb8a776280c0b3d73b4c04b83dbade835e2a171ca27ef 0.0s
 => [internal] load build context 0.0s
 => => transferring context: 165.53kB 0.0s
 => CACHED [2/6] WORKDIR app/ 0.0s
 => [3/6] COPY . . 0.0s
 => [4/6] RUN pip install poetry 5.2s
 => [5/6] RUN poetry config installer.max-workers 10 0.2s 
 => ERROR [6/6] RUN poetry install --no-interaction --no-ansi 3.0s 
------
 > [6/6] RUN poetry install --no-interaction --no-ansi:
...

2.843   gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_SIZEOF_PID_T=4 -DPSUTIL_VERSION=598 -DPy_LIMITED_API=0x03060000 -DPSUTIL_ETHTOOL_MISSING_TYPES=1 -DPSUTIL_LINUX=1 -I/tmp/tmp_f4v79j0/.venv/include -I/usr/local/include/python3.11 -c psutil/_psutil_common.c -o build/temp.linux-aarch64-cpython-311/psutil/_psutil_common.o
2.843   psutil could not be installed from sources because gcc is not installed. Try running:
2.843     sudo apt-get install gcc python3-dev
2.843   error: command 'gcc' failed: No such file or directory
2.843   
2.843 
2.843   at /usr/local/lib/python3.11/site-packages/poetry/installation/chef.py:164 in _prepare
2.846       160│ 
2.846       161│                 error = ChefBuildError("\n\n".join(message_parts))
2.846       162│ 
2.846       163│             if error is not None:
2.846     → 164│                 raise error from None
2.846       165│ 
2.846       166│             return path
2.846       167│ 
2.846       168│     def _prepare_sdist(self, archive: Path, destination: Path | None = None) -> Path:
2.846 
2.846 Note: This error originates from the build backend, and is likely not a problem with poetry but with psutil (5.9.8) not supporting PEP 517 builds. You can verify this by running 'pip wheel --no-cache-dir --use-pep517 "psutil (==5.9.8)"'.
2.846 
------
Dockerfile:10
--------------------
   8 |     
   9 |     RUN poetry config installer.max-workers 10
  10 | >>> RUN poetry install --no-interaction --no-ansi
  11 |     
  12 |     EXPOSE 8000
--------------------
ERROR: failed to solve: process "/bin/sh -c poetry install --no-interaction --no-ansi" did not complete successfully: exit code: 1

Este erro ocorre porque o pacote psutil (uma dependência do taskipy) requer o gcc para ser construído, mas a imagem python3.11-slim não possui o gcc instalado. Para resolver esse problema, adicionei uma etapa no Dockerfile para instalar as ferramentas de construção necessárias.

FROM python:3.11-slim
ENV POETRY_VIRTUALENVS_CREATE=false

WORKDIR app/
COPY . .

# add build-essential
RUN apt-get update && apt-get install -y \
    build-essential && \
    rm -rf /var/lib/apt/lists/*

RUN pip install poetry

Com isso, o comando docker build -t "fast_zero" . foi concluído com sucesso.

Refleti o código corrigido (código que permite fazer docker compose up completamente) nas Aulas 10 a 12 e também alterei o conteúdo do Markdown. Poderia revisar as alterações, por favor?

Sobre a adição do build-essential

# add build-essential
RUN apt-get update && apt-get install -y \
    build-essential && \
    rm -rf /var/lib/apt/lists/*

Além do método acima, acho que existem outras alternativas para garantir o sucesso da construção do Dockerfile:

1. Utilizar a imagem base python:3.11 em vez da python:3.11-slim, pois esta já inclui o compilador gcc.
2. Usar a construção multi-stage build.

Para a opção 1, considerei que não seria adequada, pois o tamanho da imagem resultante aumentaria para 1,25GB, enquanto utilizando a imagem slim fica em torno de 710MB, resultando numa diferença de aproximadamente 500MB.

Já a opção 2 poderia minimizar ainda mais o tamanho da imagem, mas descartamos essa alternativa devido à complexidade adicional que traria à lição, exigindo explicações sobre a construção multi-stage.

Com base nisso, concluí que adicionar o build-essential na imagem python:3.11-slim seria a abordagem mais adequada, pois permite manter o tamanho da imagem pequeno e evita aumentar a complexidade da lição.

No entanto, reconheço que podem haver diferentes opiniões sobre essa decisão. Gostaria de ouvir seu feedback a respeito.

[dunossauro]

@K-dash, dei um poetry update e fiz o build. Não consegui reproduzir esse erro que você está notificando.

[dunossauro]

@K-dash, https://github.com/dunossauro/fastapi-do-zero/actions/runs/9178391115/job/25238187876

Subi até um CI aqui pra gente ver se estava funcionando e está como na minha máquina. Os containers estão sendo buildados sem nenhum problema. Acredito que tenha alguma relação com a sua configuração.

No mais, estou aqui pro que precisar para reproduzir.

Qual o seu ambiente?

[K-dash]

@dunossauro
Obrigado por investigar o problema.

Após verificar novamente no meu ambiente, descobri que a razão pela qual a construção falhava era devido à diferença na arquitetura da CPU do Docker.

Meu ambiente é MacOS (chip M2) e a arquitetura da CPU do Docker estava configurada como aarch64.

❯ docker info | grep Architecture
 Architecture: aarch64

Para testar, especifiquei a opção de plataforma como linux/amd64 na construção e confirmei que a construção foi bem-sucedida.

❯ docker build --platform linux/amd64 -t "fast_zero" .

Além disso, para garantir, testei em um ambiente com arquitetura x86_64 e também confirmei que a construção foi bem-sucedida.

$ docker info | grep Architecture
 Architecture: x86_64

• Suplemento
  Parece que o psutil atualmente não fornece wheels oficiais para a arquitetura aarch64 (ARM64).
  Como resultado, ao usar psutil em um ambiente aarch64, é necessário compilá-lo a partir do código-fonte, o que requer ferramentas de compilação adicionais, como gcc e python3-dev.

Deveria ter investigado antes de abrir um issue. Peço desculpas pelo incômodo.
Pode encerrar este problema.

[dunossauro]

@K-dash obrigado por ser tão explicativo. Quando passar por essa aula, vou colocar uma nota na revisão.

Obrigado

[matheusfs99]

Tive esse mesmo problema. Obrigado por compartilhar o problema e a resolução de forma tão clara e explicativa. Ajudou bastante.