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)

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

Se você quiser executar um ambiente do Airflow gerenciado para fins de desenvolvimento, crie um ambiente de modo de desenvolvimento, que pode ser hibernado quando não estiver em uso.

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 de build do Airflow 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 usa a lista de pacotes PyPI instalados e os nomes das variável de ambiente do seu ambiente do Airflow Gerenciado.

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

Antes de começar

  • A ferramenta de CLI de desenvolvimento local do Composer é compatível com builds do Airflow 3 da seguinte maneira:

    • O Airflow 3.3.1 e versões mais recentes são compatíveis a partir de composer-3-airflow-3.3.1-build.0.
    • O Airflow 3.2.2 tem suporte a partir da versão composer-3-airflow-3.2.2-build.3.
    • O Airflow 3.1.8 não é compatível.
    • As versões anteriores do Airflow 3 são compatíveis a partir de composer-3-airflow-3.1.0-build.8.

  • 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 seu 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 de build do Airflow. A ferramenta de CLI de desenvolvimento local do Composer armazena um arquivo de imagem para cada build do Airflow. Por exemplo, se você tiver dois ambientes locais do Airflow com builds diferentes, a ferramenta de CLI de desenvolvimento local do Composer vai armazenar duas imagens de build do Airflow.

  • A ferramenta de 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 em todos os comandos composer-dev, exceto em 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, receba novas credenciais de usuário para usar com as credenciais padrão do aplicativo:

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 de CLI de desenvolvimento local do Composer e pelos DAGs são executadas na conta que você usa na CLI gcloud. Por exemplo, se um DAG no 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 esse for o caso, o pip vai mostrar uma mensagem de aviso. Use as informações dessa mensagem de aviso para adicionar esse 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 Usuários 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 simular 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 soquete:

    # 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 realizar essas etapas, você poderá trabalhar com os comandos da CLI composer-dev. A ferramenta detecta automaticamente o ambiente do Podman no Windows e adapta os mapeamentos de arquitetura.

Criar um ambiente local do Airflow com uma imagem de build do Airflow

Para listar as imagens de build do Airflow 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 desse ambiente local do Airflow.
  • IMAGE_VERSION pelo nome da imagem de build do Airflow.
  • 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 onde os arquivos do plug-in estão localizados.

  • DATABASE_ENGINE pelo mecanismo de banco de dados que 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 para instalar 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êiner.

    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-3-airflow-2.11.1-build.20 \
  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:

  • Build específico do Airflow usado pelo 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 de DAG, histórico de execução de DAGs, variáveis e conexões do Airflow, não são copiados do seu 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 por um nome para o ambiente local do Airflow.
  • ENVIRONMENT_NAME pelo 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 por uma porta para o servidor da Web local do Airflow.
  • LOCAL_DAGS_PATH por um caminho para um diretório local em que os DAGs estão localizados.
  • LOCAL_PLUGINS_PATH pelo caminho para um diretório local em que os arquivos de plug-ins estão localizados.

  • DATABASE_ENGINE pelo mecanismo de banco de dados que 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 para instalar 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êiner.

    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 pelo nome de um ambiente local do Airflow.

Interromper ou reiniciar um ambiente local do Airflow

Quando você reinicia um ambiente local do Airflow, a ferramenta da CLI 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 iniciados novamente. Como resultado, todas as execuções de DAG realizadas durante uma reinicialização são marcadas como com falha .

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

composer-dev restart LOCAL_ENVIRONMENT_NAME

Substitua:

  • LOCAL_ENVIRONMENT_NAME pelo 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 que você especificou no parâmetro --dags-path ao criar o ambiente local do Airflow. Por padrão, esse diretório é ./composer/<local_environment_name>/dags. Para ver o diretório usado pelo ambiente, use o comando describe.

Para adicionar e atualizar DAGs, mude os arquivos nesse 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 o ambiente local do Airflow. Dessa forma, é possível monitorar eventos relacionados a contêineres e verificar se há erros nos registros do Airflow, como conflitos de dependência causados pela instalação de pacotes do PyPI.

Para conferir 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 acompanhar 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 seu 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 pacote 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 CLI 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. Para configurá-las, execute um comando da CLI do Airflow ou armazene os parâmetros de conexão em variáveis de ambiente. Para mais informações sobre como criar e configurar conexões, consulte Como 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 de 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 alterar 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 do PyPI

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

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

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

Mudar para outra imagem de build do Airflow

É possível usar qualquer imagem de build do Airflow com a ferramenta de CLI do Composer Local Development 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 um novo build do Airflow é lançado, você pode mudar seu ambiente para usá-lo e manter a configuração do ambiente local do Airflow.

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:verifique se você salvou 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 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 extra e solução de problemas

Esta seção oferece soluções para problemas comuns e etapas de configuração extras para configurar a interação da ferramenta de linha de comando 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 com tabulação para shells Bash, Zsh e Fish. É possível usar o preenchimento com tabulação para descobrir subcomandos e opções disponíveis sem consultar o texto de ajuda.

Zsh

Gere o script de preenchimento e o use como origem no ~/.zshrc:

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

Em seguida, adicione-o ao ~/.zshrc:

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

Bash

Gere o script de preenchimento e o use como origem no ~/.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

Interação com outros serviços na máquina host

O localhost em um ambiente do Airflow Gerenciado aponta para o próprio contêiner, não para a máquina host, devido ao funcionamento da rede em contêineres do Docker ou do Podman. Para facilitar, a ferramenta de 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 em execução na porta 6379.
  • PostgreSQL: use host.docker.internal:25432 em vez de localhost:25432 se PostgreSQL estiver em execução 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 que o Docker não pode 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 é 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 adicioná-lo pela UI (Configurações > Recursos > Compartilhamento de arquivos).

Nesse caso, a ferramenta CLI do Composer Local Development 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...")

Você pode usar 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 Airflow Gerenciado é executado como o usuário airflow com o UID 999. O usuário precisa ter acesso a 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 hosts ~/.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 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 do 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 administrador (por exemplo: sudo nano /etc/subuid).

  2. Atualize ou adicione a entrada do seu nome de usuário para que 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á impedido de 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 ("Nome ou serviço desconhecido")

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 do banco de dados (your-environment-name), a rede de ponte virtual interna do Podman está fora de sincronia.

Limpe os estados 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 precisa 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) Corrigir erros de pipe durante a implantação

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

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

    podman machine stop
wsl --shutdown

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

  3. Inicie a máquina do Podman executando:

    podman machine start

Se você encontrar erros, tente fazer uma reinicialização forçada da pilha de virtualização e rede do Windows. Para fazer isso, abra o PowerShell como administrador e execute:

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

A seguir