O Dia em que o Python 3.10 "quebrou" meu aaPanel

O Dia em que o Python 3.10 "Quebrou" meu aaPanel no Podman (e como resolvi)#

Se você trabalha com infraestrutura, sabe que o "unhealthy" no status de um container é o começo de uma dor de cabeça. Recentemente, me deparei com um cenário clássico de quem gosta de manter as coisas atualizadas, mas esquece que o ambiente isolado do container pode não estar pronto para o futuro.

Neste post, vou detalhar como diagnostiquei e resolvi um erro crítico de sintaxe no aaPanel rodando via Podman no Rocky Linux, que culminou na decisão de migrar o painel para o host físico.

O container "zumbi"#

Tudo começou quando percebi que meu container do aaPanel estava rodando, mas o painel simplesmente não carregava. Ao rodar um podman ps, o status era desanimador: Up 33 hours (unhealthy).

O primeiro passo foi investigar o health check:

podman inspect --format='{{json .State.Health}}' aapanel

O retorno mostrou um FailingStreak de quase 20 mil tentativas e um ExitCode: 1. O serviço interno estava morto.

O conflito de gerações do Python#

Tentei reiniciar o painel manualmente dentro do container com o comando bt restart. Foi aí que o culpado apareceu. O log de erro cuspiu um traceback que qualquer desenvolvedor Python reconhece:

TypeError: unsupported operand type(s) for |: 'type' and '_GenericAlias'

O que aconteceu? O código do aaPanel (versão 11.5.0) foi atualizado para usar Type Hints modernas do Python 3.10+, especificamente o operador de união | (ex: dict | List). No entanto, a imagem base que eu estava usando (aapanel:lib) ainda rodava o Python 3.7.9.

O Python 3.7 olha para o caractere | em uma definição de tipo e não sabe o que fazer. O painel tentava subir, encontrava esse erro de sintaxe nas bibliotecas common.py e public/__init__.py, e morria.

As tentativas de "cirurgia" via terminal#

Como eu precisava do painel de pé rápido, tentei uma abordagem agressiva usando sed para remover as dicas de tipo problemáticas:

# Tentativa de limpar as uniões de tipo que quebravam o Python 3.7
podman exec -it aapanel sed -i -E "s/: [^=,)]*\|[^=,)]*//g" /www/server/panel/class/public/common.py

O resultado? O sed é uma ferramenta poderosa, mas perigosa. Ele acabou corrompendo expressões regulares (Regex) que também usavam o caractere |, resultando em um SyntaxError: invalid syntax ainda pior.

Tentei restaurar o ambiente com o script oficial de atualização:

podman exec -it aapanel curl -sSO http://download.bt.cn/install/update_panel.sh
podman exec -it aapanel bash update_panel.sh

O script atualizou o painel para a v11.5.0, mas não atualizou o binário do Python (o pyenv interno), mantendo o erro de compatibilidade.

A mudança de estratégia: reinstalação e migração#

Percebi que tentar "remendar" o Python 3.7 para rodar um código de 2026 era perda de tempo. Decidi remover o container antigo e subir a imagem mais recente (aapanel/aapanel:latest).

Ao tentar subir a nova imagem com o Podman, esbarrei em um erro de montagem de volumes: Error: statfs /www/server/data: no such file or directory

Isso me lembrou que, no Rocky Linux, precisamos garantir que os diretórios de persistência existam no host antes do mapeamento:

sudo mkdir -p /www/wwwroot /www/server/data /www/server/panel/vhost
sudo chown -R $USER:$USER /www/wwwroot /www/server/data /www/server/panel/vhost

A conclusão: "bare metal" é o caminho#

Mesmo conseguindo subir o container novo, a experiência me mostrou que, para a complexidade do aaPanel - que gerencia compiladores, múltiplos serviços (Nginx, PHP, MySQL) e tem seu próprio ambiente Python - rodar direto no host (Bare Metal) oferece uma estabilidade que o container, por vezes, dificulta.

Se você está enfrentando erros de TypeError no aaPanel dentro de containers antigos, minha recomendação é: não lute contra a sintaxe do Python.

Faça backup dos seus arquivos /www/wwwroot.
Instale o aaPanel direto no Rocky Linux usando o script oficial:

sudo yum install -y wget && wget -O install.sh http://www.aapanel.com/script/install_6.0_en.sh && sudo bash install.sh aapanel

Libere as portas no Firewalld: Não esqueça que o Rocky é rigoroso. Portas como 7800 (ou 8888), 80, 443 e 888 precisam ser liberadas manualmente com firewall-cmd.

No fim das contas, a infraestrutura deve servir ao projeto, e não se tornar o projeto. Às vezes, o caminho mais simples (instalação nativa) é o que garante que você durma tranquilo sem containers "unhealthy" na madrugada.

Gostou do relato? Se você também já brigou com versões de Python em containers de painéis de controle, comenta aí como resolveu!

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.

O Dia em que o Python 3.10 "quebrou" meu aaPanel no Podman (e como resolvi)