Executar um ambiente local do Airflow com a ferramenta de CLI de desenvolvimento local do Composer

Airflow gerenciado (Geração 3) | Airflow gerenciado (Geração 2) | Airflow gerenciado (Geração 1 legada)

Esta seção descreve como criar, configurar e executar um ambiente local do Airflow usando a ferramenta de CLI de desenvolvimento local do Composer.

Sobre a ferramenta de CLI de desenvolvimento local do Composer

A ferramenta de CLI de desenvolvimento local do Composer simplifica o desenvolvimento de DAGs do Apache Airflow para o Airflow gerenciado executando um ambiente do Airflow localmente. Esse ambiente local do Airflow usa uma imagem do Airflow Gerenciado usada por uma versão específica do Airflow Gerenciado.

É possível criar um ambiente local do Airflow com base em um ambiente do Airflow gerenciado. Nesse caso, o ambiente local do Airflow recebe a lista de pacotes PyPI instalados e os nomes das variável de ambiente do seu ambiente do Airflow Gerenciado.

Você pode usar esse ambiente local do Airflow para fins de teste e desenvolvimento, como testar novos códigos DAG, pacotes PyPI ou opções de configuração do Airflow.

Antes de começar

  • A ferramenta de CLI de desenvolvimento local do Composer cria ambientes locais do Airflow em um diretório em que você executa o comando composer-dev create. Para acessar o ambiente local do Airflow mais tarde, execute os comandos da ferramenta no caminho em que você criou o ambiente local inicialmente. Todos os dados do ambiente local são armazenados em um subdiretório no caminho em que você criou o ambiente local: ./composer/<local_environment_name>.

  • O computador precisa ter espaço em disco suficiente para armazenar imagens do Airflow gerenciado. A ferramenta de CLI de desenvolvimento local do Composer armazena um arquivo de imagem para cada versão do Airflow gerenciado. Por exemplo, se você tiver dois ambientes locais do Airflow com versões diferentes do Airflow Gerenciado, a ferramenta de CLI de desenvolvimento local do Composer vai armazenar duas imagens do Airflow Gerenciado.

  • A ferramenta CLI de desenvolvimento local do Composer usa saída colorida. É possível desativar a saída colorida com a variável NO_COLOR=1: NO_COLOR=1 composer-dev <other commands>.

  • Se você tiver apenas um ambiente local, poderá omitir o nome dele de todos os comandos composer-dev, exceto o run-airflow-cmd.

  • Instale as dependências da ferramenta de CLI de desenvolvimento local do Composer:

  • O Docker (Linux/macOS/Windows) ou o Podman (Linux ou Windows) precisam estar instalados e em execução no seu computador.

    Para verificar se o Docker ou o Podman estão em execução, execute qualquer comando da CLI do Docker ou do Podman, como docker ps ou podman ps. Todas as instruções se aplicam ao Docker e ao Podman, a menos que especificado de outra forma. Além disso, todos os comandos do Docker podem ser substituídos por comandos equivalentes do Podman.

Configurar credenciais

Se ainda não tiver feito isso, consiga novas credenciais de usuário para usar com o Application Default Credentials:

gcloud auth application-default login

Faça login na CLI gcloud usando sua Conta do Google:

gcloud auth login

Todas as chamadas de API feitas pela ferramenta CLI de desenvolvimento local do Composer e pelos DAGs são executadas na conta usada na CLI gcloud. Por exemplo, se um DAG no seu ambiente local do Airflow ler o conteúdo de um bucket do Cloud Storage, essa conta precisará ter permissões para acessar o bucket. Isso é diferente dos ambientes do Airflow Gerenciado, em que a conta de serviço de um ambiente faz as chamadas.

Instalar a ferramenta de CLI de desenvolvimento local do Composer

Clone o repositório da CLI de desenvolvimento local do Composer:

git clone https://github.com/GoogleCloudPlatform/composer-local-dev.git

No diretório de nível superior do repositório clonado, execute:

pip install .

Dependendo da configuração do pip, o caminho em que a ferramenta está instalada pode não estar na variável PATH. Se for esse o caso, o pip vai mostrar uma mensagem de aviso. Use as informações dessa mensagem de aviso para adicionar o diretório à variável PATH no seu sistema operacional.

(Podman) Configurar o Podman

Se você estiver usando o Podman, siga estas etapas para configurá-lo:

Linux

  1. Ative o soquete de serviço do usuário do Podman.

    A CLI composer-dev se comunica por chamadas de API Docker padrão. É necessário ativar o wrapper de soquete do serviço em segundo plano do Podman no nível do usuário para imitar o daemon do Docker.

    Primeiro, verifique se o soquete no nível do usuário já está ativo:

    systemctl --user is-active podman.socket

    Se o comando retornar inactive ou failed, ative e inicie o socket:

    # Enable and start Podman's user-level systemd socket
systemctl --user enable --now podman.socket

  2. Configure as variáveis de ambiente para o Podman.

    Adicione o seguinte comando ao arquivo de configuração do shell (como .bashrc ou .zshrc):

    export DOCKER_HOST="unix:///run/user/$UID/podman/podman.sock"

Windows

  1. Defina a configuração do WSL 2 (.wslconfig). Antes de inicializar a máquina do Podman, verifique se o WSL 2 tem um limite de memória e troca definido. Sem ele, as implantações de vários contêineres podem causar picos de memória durante a extração de imagens. Também é importante definir uma restrição para o limite de downloads simultâneos.

    Mude ou crie o arquivo %USERPROFILE%\.wslconfig:

    [wsl2]
memory=4GB
swap=2GB

[registry]
max_concurrent_downloads = 2

  2. No PowerShell, inicialize a máquina do Podman:

    podman machine init

  3. Inicie a máquina:

    podman machine start

Depois de executar essas etapas, você poderá trabalhar com comandos da CLI composer-dev. A ferramenta detecta automaticamente seu ambiente do Podman no Windows e adapta os mapeamentos de arquitetura.

Criar um ambiente local do Airflow com uma imagem do Airflow gerenciado

Para listar as imagens do Airflow Gerenciado disponíveis, execute:

composer-dev list-available-versions --include-past-releases --limit 10

Para criar um ambiente local do Airflow com parâmetros padrão, execute:

composer-dev create \
  --from-image-version IMAGE_VERSION \
  LOCAL_ENVIRONMENT_NAME

Outros parâmetros:

composer-dev create LOCAL_ENVIRONMENT_NAME \
  --from-image-version IMAGE_VERSION \
  --project PROJECT_ID \
  --port WEB_SERVER_PORT \
  --dags-path LOCAL_DAGS_PATH \
  --plugins-path LOCAL_PLUGINS_PATH \
  --database DATABASE_ENGINE \
  --editable-dependencies EDITABLE_DEPENDENCY_PATH

Substitua:

  • LOCAL_ENVIRONMENT_NAME com o nome do ambiente local do Airflow.
  • IMAGE_VERSION com o nome da imagem do Airflow gerenciado.
  • PROJECT_ID pelo ID do projeto;
  • WEB_SERVER_PORT com a porta em que o servidor da Web do Airflow precisa detectar.
  • LOCAL_DAGS_PATH com o caminho para um diretório local onde os arquivos DAG estão localizados.
  • LOCAL_PLUGINS_PATH com o caminho para um diretório local em que os arquivos do plug-in estão localizados.

  • DATABASE_ENGINE com o mecanismo de banco de dados a ser usado. Os valores possíveis são postgresql (padrão) e sqlite.

  • (Somente Linux/macOS) EDITABLE_DEPENDENCY_PATH com o caminho para um diretório local que contém um pacote Python a ser instalado no modo editável. Esse argumento não é compatível com o Windows.

    Os caminhos podem ser absolutos ou relativos (os caminhos relativos são resolvidos em relação ao diretório de trabalho atual). Esse diretório precisa ser acessível pelo mecanismo de contêineres.

    Para especificar vários pacotes editáveis, repita a opção. Exemplo: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    A instalação dos pacotes com pip install -e aplica imediatamente as mudanças a esses pacotes dentro do projeto.

Exemplo:

composer-dev create \
  --from-image-version composer-2.17.11-airflow-2.11.1 \
  example-local-environment

Criar um ambiente local do Airflow com base em um ambiente do Airflow gerenciado

Somente as seguintes informações são extraídas de um ambiente do Airflow Gerenciado:

  • Versões do Airflow gerenciado e do Airflow usadas no seu ambiente.

  • Lista de pacotes PyPI personalizados instalados no seu ambiente.

  • Lista comentada de nomes de variáveis de ambiente definidas no seu ambiente.

Outras informações e parâmetros de configuração do ambiente, como arquivos DAG, histórico de execução de DAGs, variáveis e conexões do Airflow, não são copiados do ambiente do Airflow Gerenciado.

Para criar um ambiente local do Airflow com base em um ambiente do Airflow Gerenciado:

composer-dev create LOCAL_ENVIRONMENT_NAME \
    --from-source-environment ENVIRONMENT_NAME \
    --location LOCATION \
    --project PROJECT_ID \
    --port WEB_SERVER_PORT \
    --dags-path LOCAL_DAGS_PATH \
    --plugins-path LOCAL_PLUGINS_PATH \
    --database DATABASE_ENGINE \
    --editable-dependencies EDITABLE_DEPENDENCY_PATH

Substitua:

  • LOCAL_ENVIRONMENT_NAME com um nome para o ambiente local do Airflow.
  • ENVIRONMENT_NAME com o nome do ambiente do Airflow Gerenciado.
  • LOCATION pela região em que o ambiente do Airflow Gerenciado está localizado.
  • PROJECT_ID pelo ID do projeto;
  • WEB_SERVER_PORT com uma porta para o servidor da Web do Airflow local.
  • LOCAL_DAGS_PATH com um caminho para um diretório local onde os DAGs estão localizados.
  • LOCAL_PLUGINS_PATH com o caminho para um diretório local em que os arquivos de plug-ins estão localizados.

  • DATABASE_ENGINE com o mecanismo de banco de dados a ser usado. Os valores possíveis são postgresql (padrão) e sqlite.

  • (Somente Linux/macOS) EDITABLE_DEPENDENCY_PATH com o caminho para um diretório local que contém um pacote Python a ser instalado no modo editável. Esse argumento não é compatível com o Windows.

    Os caminhos podem ser absolutos ou relativos (os caminhos relativos são resolvidos em relação ao diretório de trabalho atual). Esse diretório precisa ser acessível pelo mecanismo de contêineres.

    Para especificar vários pacotes editáveis, repita a opção. Exemplo: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    A instalação dos pacotes com pip install -e aplica imediatamente as mudanças a esses pacotes dentro do projeto.

Exemplo:

composer-dev create example-local-environment \
  --from-source-environment example-environment \
  --location us-central1 \
  --project example-project \
  --port 8081 \
  --dags-path ./example_directory/dags \
  --plugins-path ./example_directory/plugins \
  --database postgresql \
  --editable-dependencies ./pkg1

Iniciar um ambiente local do Airflow

Para iniciar um ambiente local do Airflow, execute:

composer-dev start LOCAL_ENVIRONMENT_NAME

Substitua:

  • LOCAL_ENVIRONMENT_NAME com o nome de um ambiente local do Airflow.

Parar ou reiniciar um ambiente local do Airflow

Quando você reinicia um ambiente local do Airflow, a ferramenta de linha de comando de desenvolvimento local do Composer reinicia o contêiner do Docker em que o ambiente é executado. Todos os componentes do Airflow são interrompidos e reiniciados. Como resultado, todas as execuções de DAG que são executadas durante uma reinicialização são marcadas como falhas .

Para reiniciar ou iniciar um ambiente local do Airflow interrompido, execute:

composer-dev restart LOCAL_ENVIRONMENT_NAME

Substitua:

  • LOCAL_ENVIRONMENT_NAME com o nome de um ambiente local do Airflow.

Para interromper um ambiente local do Airflow, execute:

composer-dev stop LOCAL_ENVIRONMENT_NAME

Adicionar e atualizar DAGs

Os DAGs são armazenados no diretório especificado no parâmetro --dags-path ao criar o ambiente local do Airflow. Por padrão, esse diretório é ./composer/<local_environment_name>/dags. É possível acessar o diretório usado pelo seu ambiente com o comando describe.

Para adicionar e atualizar DAGs, mude os arquivos neste diretório. Não é necessário reiniciar o ambiente local do Airflow.

Conferir registros do ambiente local do Airflow

É possível ver os registros recentes de um contêiner do Docker que executa seu ambiente local do Airflow. Assim, você pode monitorar eventos relacionados a contêineres e verificar os registros do Airflow em busca de erros, como conflitos de dependência causados pela instalação de pacotes PyPI.

Para ver os registros de um contêiner do Docker que executa seu ambiente local do Airflow, execute:

composer-dev logs LOCAL_ENVIRONMENT_NAME --max-lines 10

Para seguir o fluxo de registros, omita o argumento --max-lines:

composer-dev logs LOCAL_ENVIRONMENT_NAME

Executar um comando da CLI do Airflow

É possível executar comandos da CLI do Airflow no ambiente local do Airflow.

Para executar um comando da CLI do Airflow:

composer-dev run-airflow-cmd LOCAL_ENVIRONMENT_NAME \
  SUBCOMMAND SUBCOMMAND_ARGUMENTS

Exemplo:

composer-dev run-airflow-cmd example-local-environment dags list -o table

Configurar ambientes locais do Airflow

A ferramenta de CLI de desenvolvimento local do Composer armazena parâmetros de configuração para um ambiente local do Airflow, como variáveis de ambiente e requisitos de pacotes PyPI no diretório do ambiente local (./composer/<local_environment_name>).

A configuração é aplicada quando um ambiente local do Airflow é iniciado. Por exemplo, se você adicionar requisitos de pacote PyPI conflitantes, a ferramenta de linha de comando de desenvolvimento local do Composer vai informar erros ao iniciar o ambiente local.

As conexões do Airflow são armazenadas no banco de dados do ambiente local do Airflow. É possível configurá-los executando um comando da CLI do Airflow ou armazenando os parâmetros de conexão em variáveis de ambiente. Para mais informações sobre como criar e configurar conexões, consulte Gerenciar conexões na documentação do Airflow.

Receber uma lista e o status dos ambientes locais do Airflow

Para listar todos os ambientes locais do Airflow disponíveis e mostrar o status deles:

composer-dev list

Para descrever um ambiente específico e receber detalhes como versão da imagem, caminho dos DAGs e URL do servidor da Web de um ambiente:

composer-dev describe LOCAL_ENVIRONMENT_NAME

Substitua:

  • LOCAL_ENVIRONMENT_NAME com o nome do ambiente local do Airflow.

Listar imagens usadas por ambientes locais do Airflow

Para listar todas as imagens usadas pela ferramenta de CLI de desenvolvimento local do Composer, execute:

docker images --filter=reference='*/cloud-airflow-releaser/*/*'

Instalar plug-ins e mudar dados

Os plug-ins e dados de um ambiente local do Airflow são extraídos do diretório do ambiente local: ./composer/<local_environment_name>/data e ./composer/<local_environment_name>/plugins.

Para mudar o conteúdo dos diretórios /data e /plugins, adicione ou remova arquivos nesses diretórios. O Docker propaga automaticamente as mudanças de arquivo para seu ambiente local do Airflow.

A ferramenta de CLI de desenvolvimento local do Composer não permite especificar um diretório diferente para dados e plug-ins.

Configure as variáveis de ambiente

Para configurar variáveis de ambiente, edite o arquivo variables.env no diretório do ambiente: ./composer/<local_environment_name>/variables.env.

O arquivo variables.env precisa conter definições de chave-valor, uma linha para cada variável de ambiente. Para mudar as opções de configuração do Airflow, use o formato AIRFLOW__SECTION__KEY. Para mais informações sobre as variáveis de ambiente disponíveis, consulte a referência de configuração do Airflow.

EXAMPLE_VARIABLE=True
ANOTHER_VARIABLE=test
AIRFLOW__WEBSERVER__DAG_DEFAULT_VIEW=graph

Para aplicar as mudanças, reinicie seu ambiente local do Airflow.

Instalar ou remover pacotes PyPI

Para instalar ou remover pacotes PyPI, modifique o arquivo requirements.txt no diretório do ambiente: ./composer/<local_environment_name>/requirements.txt.

Os requisitos precisam seguir o formato especificado no PEP-508. Nele, cada requisito é especificado em letras minúsculas e consiste no nome do pacote com especificadores de versão e atributos extras opcionais.

Para aplicar as mudanças, reinicie seu ambiente local do Airflow.

Mudar para outra imagem do Airflow gerenciado

É possível usar qualquer imagem do Airflow Gerenciado com a ferramenta de CLI de desenvolvimento local do Composer e alternar entre as imagens. Essa abordagem é diferente de fazer upgrade do ambiente do Airflow Gerenciado, porque os parâmetros de configuração do ambiente local do Airflow são aplicados quando ele é iniciado.

Por exemplo, depois que uma nova versão do Airflow Gerenciado for lançada, você poderá mudar seu ambiente para usá-la e manter a configuração do ambiente local do Airflow. Outro exemplo: é possível alternar entre diferentes versões do Airflow em uma versão específica do Airflow Gerenciado.

Para mudar a imagem do ambiente usada pelo seu ambiente local do Airflow:

  1. Edite o arquivo de configuração do ambiente local: ./composer/<local_environment_name>/config.json.

  2. Mude o valor do parâmetro composer_image_version. Para conferir os valores disponíveis, liste as imagens disponíveis.

  3. Para aplicar as mudanças, reinicie seu ambiente local do Airflow.

Excluir um ambiente local do Airflow

Atenção:salve todos os dados necessários do ambiente, como registros e configuração.

Para excluir um ambiente local do Airflow, execute o seguinte comando:

composer-dev remove LOCAL_ENVIRONMENT_NAME

Se o ambiente estiver em execução, adicione a flag --force para forçar a remoção.

Excluir imagens do Docker

Para excluir todas as imagens baixadas pela ferramenta de CLI de desenvolvimento local do Composer, execute:

docker rmi $(docker images --filter=reference='*/cloud-airflow-releaser/*/*' -q)

Configuração e solução de problemas extras

Esta seção oferece soluções para problemas comuns e etapas de configuração extras para configurar a interação da ferramenta de CLI de desenvolvimento local do Composer com outras ferramentas e serviços.

Preenchimento com tabulação do shell

A CLI composer-dev é compatível com o preenchimento automático para shells Bash, Zsh e Fish. Você pode usar o preenchimento de guias para descobrir subcomandos e opções disponíveis sem consultar o texto de ajuda.

Zsh

Gere o script de conclusão e a origem dele em ~/.zshrc:

_COMPOSER_DEV_COMPLETE=zsh_source composer-dev > ~/.composer-dev-complete.zsh

Em seguida, adicione ao ~/.zshrc:

echo 'source ~/.composer-dev-complete.zsh' >> ~/.zshrc

Bash

Gere o script de conclusão e a origem dele em ~/.bashrc:

_COMPOSER_DEV_COMPLETE=bash_source composer-dev > ~/.composer-dev-complete.bash

Em seguida, adicione ao ~/.bashrc:

echo 'source ~/.composer-dev-complete.bash' >> ~/.bashrc

Peixe

Gere o script de conclusão e salve-o no diretório de conclusões do Fish:

_COMPOSER_DEV_COMPLETE=fish_source composer-dev > ~/.config/fish/completions/composer-dev.fish

Interagir com clusters do Kubernetes

Por padrão, o arquivo ~/.kube/config não é montado. É possível especificar o caminho para o arquivo de configuração do Kubernetes exportando a variável de ambiente KUBECONFIG antes de iniciar o ambiente.

export KUBECONFIG=~/.kube/config

Interagir com outros serviços na máquina host

O localhost em um ambiente do Airflow Gerenciado aponta para o próprio contêiner, e não para a máquina host, devido ao funcionamento da rede em contêineres do Docker ou do Podman. Para sua conveniência, a ferramenta CLI composer-dev configura a rede do contêiner para acessar a máquina pelo alias de domínio host.docker.internal. Exemplos:

  • Redis: use host.docker.internal:6379 em vez de localhost:6379 se Redis estiver sendo executado na porta 6379.
  • PostgreSQL: use host.docker.internal:25432 em vez de localhost:25432 se PostgreSQL estiver sendo executado na porta 25432.
  • Qualquer outro serviço: Siga este padrão: host.docker.internal:<PORT>

Não é possível iniciar um ambiente local no macOS

Se você instalou o pacote composer-dev em um diretório em que o Docker não consegue acessar, talvez o ambiente local não seja iniciado.

Por exemplo, se o Python estiver instalado no diretório /opt, como quando você o instala com a configuração padrão do Homebrew no macOS, o pacote composer-dev também será instalado no diretório /opt. Como o Docker obedece às regras de sandbox da Apple, o diretório /opt não está disponível por padrão. Além disso, não é possível adicionar esse recurso pela UI (Configurações > Recursos > Compartilhamento de arquivos).

Nesse caso, a ferramenta CLI de desenvolvimento local do Composer gera uma mensagem de erro semelhante ao exemplo a seguir:

Failed to create container with an error: 400 Client Error for ...
Bad Request ("invalid mount config for type "bind": bind source path does not exist:
/opt/homebrew/lib/python3.9/site-packages/composer_local_dev/docker_files/entrypoint.sh

Possible reason is that composer-dev was installed in the path that is
not available to Docker. See...")

Use uma das seguintes soluções:

  • Instale o Python ou o pacote composer-dev em um diretório diferente para que o Docker possa acessar o pacote.
  • Edite manualmente o arquivo ~/Library/Group\ Containers/group.com.docker/settings.json e adicione /opt a filesharingDirectories.

Acesso do usuário do contêiner a arquivos e diretórios montados do host

Por padrão, o contêiner do ambiente do Airflow Gerenciado é executado como o usuário airflow com UID 999. O usuário precisa ter acesso aos arquivos e diretórios montados do host, por exemplo ~/.config/gcloud/application_default_credentials.json.

Problemas conhecidos:

  • google.auth.exceptions.DefaultCredentialsError: Your default credentials were not found: pode ser gerado ao executar o contêiner com o usuário padrão airflow (999) e o diretório do host ~/.config/gcloud/ não tem a permissão de execução para o usuário.
  • [Errno 13] Permission denied: '/home/airflow/.config/gcloud/application_default_credentials.json': pode ser gerado quando você executa o contêiner com o usuário padrão airflow (999) e o arquivo do host ~/.config/gcloud/application_default_credentials.json não tem a permissão de leitura para o usuário.

No Linux ou macOS, é recomendável executar o contêiner como o usuário do host atual adicionando COMPOSER_CONTAINER_RUN_AS_HOST_USER=True a composer/<LOCAL_ENVIRONMENT_NAME>/variables.env. Esse recurso não está disponível no Windows. Por isso, talvez seja necessário atualizar as permissões dos arquivos e diretórios montados no host para permitir o acesso pelo usuário dentro do contêiner.

(Podman) Corrigir erros de permissão ou lchown para usuários corporativos

Para evitar que o Podman sem raiz aloque automaticamente namespaces de usuário que se sobrepõem ao ID de usuário corporativo principal (causando erros de lchown: invalid argument ou permissão), você precisa enviar manualmente seus intervalos subordinados acima do bloco de 4 milhões.

  1. Abra /etc/subuid e /etc/subgid com privilégios de root (por exemplo: sudo nano /etc/subuid).

  2. Atualize ou adicione a entrada do nome de usuário para que ela fique exatamente assim:

    YOUR_USERNAME:4000000:3000000

  3. Salve os dois arquivos e execute o seguinte para aplicar as novas regras de mapeamento de namespace ao Podman:

    podman system migrate

(Podman) Remover arquivos presos e erros de permissão negada

Se você atualizou os intervalos de subuid enquanto os contêineres antigos existiam, o namespace atual será bloqueado para acessar o próprio cache de dados.

Limpe à força o gráfico de armazenamento local usando privilégios de raiz no nível do host:

podman rm -fa
podman volume rm --all --force
podman system migrate

(Podman) Corrigir falhas de DNS ("Name or service not known")

Se o contêiner do Airflow gerar um psycopg2.OperationalError informando que não é possível traduzir ou resolver o nome do host do contêiner de banco de dados (your-environment-name), a rede de ponte virtual interna do Podman estará dessincronizada.

Limpe os estados de tempo de execução e force netavark e aardvark-dns a regenerar tabelas de roteamento limpas.

podman rm -fa
podman network prune --force

rm -rf /run/user/$UID/containers/*
rm -rf /run/user/$UID/netavark/*
rm -rf COMPOSER_LOCAL_DEV_PATH/composer/*

podman system migrate

(Podman) Verificar o status do mecanismo

Para verificar se o Podman está gerenciando seu fluxo de trabalho sem raiz e não está ignorando sua configuração no Docker do sistema:

  1. Verifique o back-end de DNS da rede:

    podman info | grep -A 3 -i "dns"

    A saída precisa conter backend: netavark e um caminho executável válido para aardvark-dns.

  2. Verifique o mapeamento de propriedade do processo. Com o ambiente em execução, verifique o proprietário do processo do host:

    ps -ef | grep -i "postgres"

    A coluna mais à esquerda deve mostrar um número de UID alto (como 4000069) correspondente ao intervalo do mapa de subuid, provando que ele está sendo executado sem raiz.

(Podman, Windows) Correção de erros de pipe durante a implantação

Se o banco de dados ou o contêiner do Airflow sair imediatamente com erros de pipe durante a implantação, o Podman poderá estar atingindo um limite de memória. Para corrigir isso, tente aumentar os limites de memória e troca no arquivo .wslconfig:

  1. Pare a máquina do Podman e a máquina virtual do WSL 2 executando o comando a seguir no PowerShell:

    podman machine stop
wsl --shutdown

  2. Faça mudanças no arquivo %USERPROFILE%\.wslconfig para adaptar seus limites de troca e memória. Para referência, consulte a Referência de configuração do WSL.

  3. Inicie sua máquina Podman executando:

    podman machine start

Se você encontrar erros, tente redefinir completamente a virtualização do Windows e a pilha de rede. Para isso, abra o PowerShell como administrador e execute:

Restart-Service -Name vmms -Force
Restart-Service -Name hns -Force
wsl --shutdown

A seguir