pyinfra — automação de infraestrutura sem agentes, em Python puro

(pyinfra.com)

1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp

Escreva tarefas de automação de servidores em código Python e execute em paralelo via SSH, realizando comandos de forma idempotente sem agentes
O pyinfra destaca ser 6 vezes mais rápido que o Ansible na mesma carga de trabalho, usando execução concorrente baseada em gevent e SSH
Com a opção --dry, é possível verificar o diff de mudanças por host antes da aplicação, e na execução real os resultados retornam em streaming paralelo
Os hosts de destino precisam apenas de shell e SSH, sem daemon, arquivos de estado ou control plane
Enfatiza uma configuração centrada em código que usa diretamente loops e condicionais do Python, em vez de codificar o fluxo de controle em YAML

Recursos principais e fluxo de execução

Automação para milhares de servidores
- pyinfra é uma ferramenta de automação agentless, nativa de Python, que executa comandos via SSH
- A execução de comandos enfatiza concorrência, idempotência e velocidade, destacando ser 6 vezes mais rápido que o Ansible na mesma carga de trabalho
- O comando de instalação é $ uv tool install pyinfra
- Os pré-requisitos básicos indicados são licença MIT, Python 3.10 ou superior, sem agentes e configuração zero
Exemplo de código de deploy
- As operações apt, files e systemd são importadas em código Python para instalar pacotes, aplicar templates e recarregar serviços
- O código de exemplo instala os pacotes nginx e certbot e aplica templates/nginx.conf.j2 em /etc/nginx/sites-enabled/api
- Na etapa final, recarrega o serviço nginx com systemd.service("nginx", reloaded=True)
```
from pyinfra.operations import apt, files, systemd

apt.packages(
    packages=["nginx", "certbot"],
    update=True,
)

files.template(
    src="templates/nginx.conf.j2",
    dest="/etc/nginx/sites-enabled/api",
)

systemd.service("nginx", reloaded=True)
```
Inventário e resultados de execução
- O exemplo de inventário organiza hosts web de web-01.prod até web-23.prod, além dos hosts de banco de dados db-01.prod e db-02.prod
- O comando $ pyinfra inventory.py deploy.py --limit web executa apenas sobre os alvos limitados a web
- A saída de execução segue a ordem de carregamento do inventário, coleta concorrente de facts, execução de deploy.py e resumo
- O resumo do exemplo registra sucesso em 23 hosts, 18 alterados, 0 falhas e total de 2,1 segundos
Verificação antes das mudanças
- --dry permite verificar antes todas as diffs por host das operações que o pyinfra executará
- Na execução real, os resultados são transmitidos em paralelo, mostrando o número de mudanças e o tempo de execução de cada host
- O exemplo registra, em 24 hosts, 18 alterados, 6 sem mudanças, 0 falhas e total de 2,1 segundos

Características, comparação com Ansible e princípios

Seis motivos para escolher pyinfra
- Just Python: escreve o fluxo de controle real em Python, sem YAML e sem Jinja dentro de YAML
- Concurrent SSH: executa concorrentemente com base em gevent e SSH, sendo 6 vezes mais rápido que o Ansible na mesma carga de trabalho
- Diff before apply: com --dry, mostra todas as mudanças antecipadamente, e operações idempotentes viram no-op em reexecuções
- 0 agents: os hosts precisam apenas de shell e SSH, sem daemon, arquivos de estado ou control plane
- Scale-ready: funciona de 1 a 10.000 hosts, com execução paralela e saída em streaming em tempo real
- Hackable: permite criar operações customizadas em 10 linhas e conectar com docker, lxc e k8s que se comunicam via shell
Comparação de código entre Ansible e pyinfra
- O exemplo em Ansible usa 16 linhas em playbook.yml para instalar nginx, renderizar template e recarregar o serviço com handler
- O exemplo em pyinfra usa 8 linhas em deploy.py para escrever o mesmo fluxo em código Python
- No exemplo de pyinfra, systemd.service("nginx", reloaded=True) roda apenas quando cfg.will_change do resultado de files.template for verdadeiro
```
from pyinfra.operations import apt, files, systemd

apt.packages(["nginx"], update=True)

cfg = files.template(
    src="nginx.conf.j2",
    dest="/etc/nginx/sites-enabled/api",
)
if cfg.will_change:
    systemd.service("nginx", reloaded=True)
```
Declarações
- Code > config: loops continuam sendo loops, sem codificar o fluxo de controle em YAML
- Show, then do: veja primeiro o diff e aplique depois, evitando mudanças inesperadas
- Stay out of the way: executa diretamente via SSH, sem agentes, arquivos de estado ou control plane
- Read like english: as operações são lidas em formato de substantivo e verbo, como apt.packages, files.template, systemd.service
Comando inicial
- O comando de instalação é $ uv tool install pyinfra
- É oferecida a orientação para ler o quickstart de 5 minutos e fazer o deploy do primeiro host

1 comentários

GN⁺ 4 시간 전

Opiniões no Lobste.rs

pyinfra parece o que o Ansible deveria ter sido desde o início. Em vez de misturar YAML com templates e adicionar fluxo de controle por cima, dá para escrever a automação diretamente em Python
Foi algo revigorante depois de muito tempo lidando com Ansible, e nem era porque eu detestasse Ansible
- Mais precisamente, parece menos um Ansible em Python e mais um interpretador que converte Python em shell, e isso traz seus próprios problemas
  Talvez um híbrido que também use Python nos servidores de destino fosse melhor. Assim haveria menos inferno de aspas ao atualizar arquivos, e também daria para evitar coisas como as limitações de regex do sed
Gosto do pyinfra e queria que fosse mais amplamente usado
Todas as empresas em que trabalhei até agora usavam Ansible, com ou sem Terraform em paralelo, e nenhuma estava pronta para reescrever toda a automação existente em uma ferramenta sem experiência interna
O pyinfra exige que SysOps saiba Python, e pessoalmente acho que SysOps deveria conhecer ao menos uma linguagem de script. Especialmente porque, no Ansible, escrever módulos em Python também pode reduzir a bagunça de YAML, mas pelo menos na França isso não parece ser uma ideia muito comum
- Usei bastante Ansible e, na prática, vejo isso como algo disfarçado de linguagem de script
  Talvez isso nem seja um tema tão polêmico assim
Eu usava Ansible no meu homelab, mas fui ficando cada vez mais frustrado. Configuração em YAML é horrível, tudo parecia gambiarra, e a velocidade era deprimente. Também não fazia sentido para mim precisar de python3 no servidor só para executar alguns comandos de shell
Conheci o pyinfra graças ao Google AI Mode e, no quase um mês em que usei, a experiência foi muito mais leve. As vantagens são que ele é bem mais rápido que Ansible, permite escrever loops e condicionais em Python e, sem roles nem diretórios aninhados, o servidor só precisa ter shell. Ele monta um plano com base no estado atual antes de executar e, se você não passar -y, ainda pede confirmação
As desvantagens são que as tarefas padrão são um subconjunto bem menor que os módulos do Ansible, o código pode virar espaguete rapidamente, e coisas como if 'web_server' in hosts.groups também não parecem muito boas. Talvez operation(..., filter_group='web_server') seja melhor
O pior de tudo é que escrever conectores customizados é sofrido demais. Parece precisar de um pyproject.toml com um entry point específico do pyinfra, e mesmo com uv, desenvolver conectores internos parece um pesadelo. Deveria ser possível fazer isso como um arquivo Python comum dentro do projeto
Estou testando o pyinfra por alguns dias como ferramenta de deploy do meu homelab e, comparado ao Ansible, o que mais gostei até agora não foi a sintaxe em Python, mas a velocidade
O Ansible sempre pareceu insuportavelmente lento
- Essa área é interessante. Eu também estou criando uma ferramenta de deploy e a uso em produção no meu trabalho principal
  Quero substituir o uso de Ansible e Salt na maioria dos lugares
É engraçado como a infraestrutura como código deu a volta completa. Fomos de scripts para YAML e agora voltamos a scripts mais sofisticados
Cada abordagem tem seu ponto ideal, e do ponto de vista de um usuário de Ansible, o pyinfra parece bem interessante
- Continuamos girando no configuration complexity clock
O principal motivo para eu adotar Ansible foi o modo dry-run e visualização de diferenças. Isso me dava confiança de que ele não faria nada inesperado
Mas não parece haver essa opção na CLI do pyinfra. Posso ter deixado passar por não encontrar uma referência com todas as opções listadas em ordem alfabética
- Existe a flag —dry, e ela aparece logo na tela inicial do pyinfra
Para quem tiver interesse, tenho também um projeto parecido de 14 anos: https://github.com/sebastien/cuisine/tree/main
Ele é sem agente, usa só SSH e oferece uma API em estilo Python sobre funções centrais de gerenciamento, mas não suporta modo dry
Usamos Ansible para provisionar recursos no OpenStack e fazemos o restante com pyinfra, e isso tem funcionado muito bem nos últimos anos
A maior desvantagem é a comunidade pequena, então você acaba escrevendo suas próprias soluções. Por exemplo, armazenamos os segredos compartilhados necessários para deploy em disco com keyring + privy e escrevemos algumas linhas de código para transformar o inventário de computação do OpenStack em dados de hosts

pyinfra — automação de infraestrutura sem agentes, em Python puro

Recursos principais e fluxo de execução

Automação para milhares de servidores

Exemplo de código de deploy

Inventário e resultados de execução

Verificação antes das mudanças

Características, comparação com Ansible e princípios

Seis motivos para escolher pyinfra

Comparação de código entre Ansible e pyinfra

Declarações

Comando inicial

Leituras relacionadas

1 comentários

Opiniões no Lobste.rs