![\"Mascote](\"\/wp-content\/uploads\/2026\/09\/primeiros-passos-com-ansible-v4.webp\")
<\/p>\n<\/p>\n
Se voc\u00ea ainda configura servidor na m\u00e3o, entrando por SSH, editando arquivo, instalando pacote e repetindo tudo na m\u00e1quina seguinte, o Ansible<\/strong> \u00e9 a ferramenta que aposenta esse ritual. Voc\u00ea descreve em arquivos YAML como cada servidor deve ficar, e o Ansible aplica isso por SSH, sem instalar agente nenhum nas m\u00e1quinas. Pode rodar mil vezes: o resultado \u00e9 o mesmo. Neste guia voc\u00ea vai instalar o Ansible no Ubuntu, montar um projeto com invent\u00e1rio, rodar comandos avulsos e escrever um playbook com vari\u00e1vel, template e handler. Todos os comandos foram testados com o ansible-core 2.21 num laborat\u00f3rio com tr\u00eas servidores Ubuntu 24.04.<\/p>\n <\/p>\n O primeiro commit do Ansible, com a mensagem “Genesis.”, \u00e9 de 23 de fevereiro de 2012<\/strong>, feito por Michael DeHaan<\/strong>. Ele conhecia o problema de perto: na Red Hat, tinha criado o Cobbler<\/strong>, de provisionamento de servidores, e participado do Func<\/strong>, de execu\u00e7\u00e3o remota de comandos. As ferramentas de ger\u00eancia da \u00e9poca, como Puppet e Chef, exigiam um agente instalado em cada servidor e uma linguagem pr\u00f3pria. O Ansible nasceu com tr\u00eas princ\u00edpios que valem at\u00e9 hoje: sem agente<\/strong> (s\u00f3 SSH e Python, que j\u00e1 existem em qualquer Linux), YAML leg\u00edvel<\/strong> em vez de linguagem de programa\u00e7\u00e3o e curva de aprendizado curta.<\/p>\n O nome vem da fic\u00e7\u00e3o cient\u00edfica. Ans\u00edvel<\/em> \u00e9 o comunicador instant\u00e2neo entre planetas que Ursula K. Le Guin inventou em 1966, depois popularizado por O Jogo do Exterminador<\/em>, de Orson Scott Card. A met\u00e1fora combina: comandar m\u00e1quinas distantes na hora, sem intermedi\u00e1rios.<\/p>\n O projeto virou empresa, a AnsibleWorks, depois Ansible Inc., e foi comprado pela Red Hat em outubro de 2015<\/strong>, que o mant\u00e9m open source. Hoje o motor fica no pacote O Ansible \u00e9 instalado numa \u00fanica m\u00e1quina, a m\u00e1quina de controle<\/strong>: o seu notebook ou um servidor de administra\u00e7\u00e3o. Os servidores gerenciados s\u00f3 precisam de SSH e Python 3, que o Ubuntu e o Debian j\u00e1 trazem. Nada de agente, nada de servi\u00e7o extra rodando neles.<\/p>\n Para cada tarefa, o Ansible abre SSH nos servidores em paralelo (cinco por vez, por padr\u00e3o), envia um pequeno programa Python, o m\u00f3dulo<\/strong>, executa, recebe o resultado em JSON e apaga o arquivo tempor\u00e1rio. O m\u00f3dulo compara o estado atual com o que voc\u00ea pediu e s\u00f3 mexe se for preciso.<\/p>\n H\u00e1 tr\u00eas caminhos, e a diferen\u00e7a \u00e9 a vers\u00e3o:<\/p>\n O Ansible roda de qualquer diret\u00f3rio, mas vale adotar a estrutura convencional desde o primeiro dia:<\/p>\n Crie o projeto com tr\u00eas servidores em dois grupos. Troque os IPs pelos seus:<\/p>\n A linha O Ansible entra nos servidores com a sua chave SSH. Se voc\u00ea ainda n\u00e3o tem uma, gere e copie para cada servidor:<\/p>\n O Confira as chaves se o servidor n\u00e3o for de laborat\u00f3rio. Muito tutorial manda colocar Agora o teste de comunica\u00e7\u00e3o:<\/p>\n O m\u00f3dulo Antes de escrever playbooks, d\u00e1 para resolver muita coisa com comandos avulsos. Rode o comando do Agora um roteiro completo: instalar o Nginx nos servidores web, publicar uma p\u00e1gina gerada a partir de um template com vari\u00e1vel, manter o servi\u00e7o ativo e recarreg\u00e1-lo s\u00f3 quando a p\u00e1gina mudar. Primeiro a vari\u00e1vel do grupo, em O template, em E o playbook, Os nomes dos m\u00f3dulos aparecem completos, como Execute o mesmo comando outra vez e olhe o resumo:<\/p>\n Mude o t\u00edtulo em O Dois limites do Quando o playbook cresce, as tarefas viram uma role, que pode ser usada em qualquer projeto:<\/p>\n O comando cria a estrutura em Rodando de novo, as tarefas aparecem com o prefixo da role ( Com esta base, os caminhos naturais s\u00e3o:<\/p>\n Instale, fa\u00e7a o ping, rode o playbook duas vezes e veja o Instala Ansible en Ubuntu, configura el inventario y la clave SSH, ejecuta comandos ad-hoc y escribe el primer playbook con variable, template y handler, simulando antes de aplicar. Todo probado con ansible-core 2.21.<\/p>","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[46,2,120,3],"tags":[121,122,47,378,240,505,506,5,377],"class_list":["post-782","post","type-post","status-publish","format-standard","hentry","category-devops","category-linux","category-servidores","category-ubuntu","tag-ansible","tag-automacao","tag-devops","tag-iniciantes","tag-nginx","tag-playbook","tag-ssh","tag-ubuntu","tag-yaml"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/782","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/comments?post=782"}],"version-history":[{"count":8,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/782\/revisions"}],"predecessor-version":[{"id":1742,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/782\/revisions\/1742"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/media?parent=782"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/categories?post=782"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/tags?post=782"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Como nasceu o Ansible<\/h2>\n
ansible-core<\/code>, e o pacote ansible<\/code> junta o motor com dezenas de collections<\/em> da comunidade, os conjuntos de m\u00f3dulos para cada tecnologia.<\/p>\nComo o Ansible trabalha<\/h2>\n
![\"Diagrama:](\"\/wp-content\/uploads\/2026\/09\/ansible-arquitetura-sem-agente.webp\")
<\/p>\n![\"Diagrama](\"\/wp-content\/uploads\/2026\/09\/ansible-fluxo-tarefa.webp\")
<\/p>\nInstalando no Ubuntu<\/h2>\n
\n
ansible<\/code> 9.2, com ansible-core 2.16. Serve para aprender.<\/li>\nansible<\/code> 14.4.0, com ansible-core 2.21.4<\/strong>, para o Ubuntu 24.04 e o 26.04. Foi o que usamos nos testes.<\/li>\n# Op\u00e7\u00e3o 1: reposit\u00f3rio do Ubuntu\nsudo apt update\nsudo apt install -y ansible\n\n# Op\u00e7\u00e3o 2: PPA oficial (vers\u00e3o atual)\nsudo apt install -y software-properties-common\nsudo add-apt-repository --yes --update ppa:ansible\/ansible\nsudo apt install -y ansible\n\n# Op\u00e7\u00e3o 3: pipx\nsudo apt install -y pipx\npipx install --include-deps ansible\npipx ensurepath # abra um novo terminal depois deste comando<\/code><\/pre>\nansible --version<\/code><\/pre>\nansible [core 2.21.4]\n config file = \/etc\/ansible\/ansible.cfg\n ...\n python version = 3.12.3 (main, Aug 31 2026, 10:18:26) [GCC 13.3.0] (\/usr\/bin\/python3)\n jinja version = 3.1.2<\/code><\/pre>\nA estrutura de um projeto<\/h2>\n
meu-projeto\/\n\u251c\u2500\u2500 ansible.cfg # configura\u00e7\u00e3o do projeto\n\u251c\u2500\u2500 inventory.ini # quais m\u00e1quinas gerenciar\n\u251c\u2500\u2500 site.yml # playbook principal\n\u251c\u2500\u2500 group_vars\/ # vari\u00e1veis por grupo de hosts\n\u2502 \u2514\u2500\u2500 webservers.yml\n\u251c\u2500\u2500 host_vars\/ # vari\u00e1veis de um host espec\u00edfico\n\u2502 \u2514\u2500\u2500 web01.yml\n\u2514\u2500\u2500 roles\/ # partes reutiliz\u00e1veis\n \u2514\u2500\u2500 nginx\/\n \u251c\u2500\u2500 tasks\/main.yml\n \u251c\u2500\u2500 handlers\/main.yml\n \u251c\u2500\u2500 templates\/\n \u251c\u2500\u2500 files\/\n \u2514\u2500\u2500 defaults\/main.yml<\/code><\/pre>\n\n
\/etc\/ansible\/ansible.cfg<\/code>.<\/li>\nInvent\u00e1rio, chave SSH e o primeiro ping<\/h2>\n
mkdir meu-projeto && cd meu-projeto\n\ncat > inventory.ini <<'EOF'\n[webservers]\nweb01 ansible_host=192.168.64.2\nweb02 ansible_host=192.168.64.3\n\n[dbservers]\ndb01 ansible_host=192.168.64.4\n\n[all:vars]\nansible_user=ubuntu\nansible_python_interpreter=\/usr\/bin\/python3\nEOF\n\ncat > ansible.cfg <<'EOF'\n[defaults]\ninventory = inventory.ini\nEOF\n\nansible-inventory --graph<\/code><\/pre>\n@all:\n |--@ungrouped:\n |--@webservers:\n | |--web01\n | |--web02\n |--@dbservers:\n | |--db01<\/code><\/pre>\nansible_python_interpreter<\/code> fixa o Python usado nos servidores. Sem ela, o ansible-core 2.21 funciona, mas imprime um aviso em cada host dizendo que usou o Python “descoberto” e que isso pode mudar se outro Python for instalado.<\/p>\nssh-keygen -t ed25519\nfor ip in 192.168.64.2 192.168.64.3 192.168.64.4; do ssh-copy-id ubuntu@$ip; done<\/code><\/pre>\nssh-copy-id<\/code> tamb\u00e9m pede para voc\u00ea confirmar a chave de cada servidor na primeira conex\u00e3o. Se voc\u00ea usar outro caminho para distribuir a chave, o Ansible vai parar com Host key verification failed<\/code>, e \u00e9 bom que pare: \u00e9 a prote\u00e7\u00e3o contra servidor falso. Para registrar as chaves de uma vez, sem desligar a checagem:<\/p>\nssh-keyscan -H 192.168.64.2 192.168.64.3 192.168.64.4 >> ~\/.ssh\/known_hosts<\/code><\/pre>\nhost_key_checking = False<\/code> no ansible.cfg<\/code>; evite em produ\u00e7\u00e3o. E se colocar qualquer op\u00e7\u00e3o, cuidado com coment\u00e1rios: no ansible.cfg<\/code>, o #<\/code> s\u00f3 vale no come\u00e7o da linha. No nosso teste, a linha host_key_checking = True # coment\u00e1rio<\/code> foi lida como False<\/strong>, porque o Ansible pegou o texto inteiro como valor, n\u00e3o reconheceu como verdadeiro e desligou a checagem sem avisar. Coment\u00e1rio na mesma linha s\u00f3 com ;<\/code>, ou numa linha pr\u00f3pria.<\/p>\nansible all -m ansible.builtin.ping<\/code><\/pre>\nweb01 | SUCCESS => {\n \"changed\": false,\n \"ping\": \"pong\"\n}\nweb02 | SUCCESS => { ... }\ndb01 | SUCCESS => { ... }<\/code><\/pre>\nping<\/code> n\u00e3o \u00e9 o ping de rede (ICMP): ele confirma que o Ansible entra por SSH e executa Python do outro lado, que \u00e9 o que importa. Sem servidor \u00e0 m\u00e3o? Tudo funciona contra a pr\u00f3pria m\u00e1quina com ansible localhost -m ansible.builtin.ping<\/code>, que usa conex\u00e3o local.<\/p>\nComandos ad-hoc<\/h2>\n
-m<\/code> escolhe o m\u00f3dulo, -a<\/code> passa os argumentos e --become<\/code> executa com sudo do outro lado:<\/p>\nansible all -a \"uptime -p\" # comando em todos\nansible webservers -m ansible.builtin.apt \\\n -a \"name=htop state=present update_cache=true\" --become # instala pacote\nansible db01 -m ansible.builtin.setup -a \"filter=ansible_distribution*\" # fatos\nansible-doc ansible.builtin.apt # documenta\u00e7\u00e3o do m\u00f3dulo<\/code><\/pre>\nhtop<\/code> duas vezes. Na primeira, os hosts aparecem como CHANGED<\/code>; na segunda, como SUCCESS<\/code>, porque o pacote j\u00e1 estava l\u00e1. Se o seu usu\u00e1rio pede senha no sudo<\/code>, acrescente -K<\/code> (--ask-become-pass<\/code>) para o Ansible perguntar. E prefira os m\u00f3dulos espec\u00edficos ao shell<\/code>: o apt<\/code> sabe dizer se mudou algo, e um comando solto n\u00e3o sabe.<\/p>\nO primeiro playbook<\/h2>\n
group_vars\/webservers.yml<\/code>:<\/p>\n---\nsite_titulo: \"Servidor gerenciado pelo Ansible\"<\/code><\/pre>\ntemplates\/index.html.j2<\/code>, usa a sintaxe Jinja2. inventory_hostname<\/code> e ansible_facts<\/code> s\u00e3o preenchidos pelo pr\u00f3prio Ansible:<\/p>\n<!doctype html>\n<html lang=\"pt-br\">\n<head><meta charset=\"utf-8\"><title>{{ site_titulo }}<\/title><\/head>\n<body>\n <h1>{{ site_titulo }}<\/h1>\n <p>Host: {{ inventory_hostname }} ({{ ansible_facts[\"distribution\"] }} {{ ansible_facts[\"distribution_version\"] }})<\/p>\n<\/body>\n<\/html><\/code><\/pre>\nsite.yml<\/code>:<\/p>\n---\n- name: Configurar servidores web\n hosts: webservers\n become: true\n\n tasks:\n - name: Instalar o Nginx\n ansible.builtin.apt:\n name: nginx\n state: present\n update_cache: true\n cache_valid_time: 3600\n\n - name: Publicar a p\u00e1gina inicial\n ansible.builtin.template:\n src: templates\/index.html.j2\n dest: \/var\/www\/html\/index.html\n owner: root\n group: root\n mode: \"0644\"\n notify: Recarregar o Nginx\n\n - name: Garantir o Nginx ativo e habilitado no boot\n ansible.builtin.service:\n name: nginx\n state: started\n enabled: true\n\n handlers:\n - name: Recarregar o Nginx\n ansible.builtin.service:\n name: nginx\n state: reloaded<\/code><\/pre>\nansible.builtin.apt<\/code>. \u00c9 o formato recomendado desde o Ansible 2.10: deixa claro de qual collection vem cada m\u00f3dulo. O cache_valid_time<\/code> evita rodar apt update<\/code> de novo se ele foi feito na \u00faltima hora.<\/p>\nansible-playbook site.yml --syntax-check\nansible-playbook site.yml<\/code><\/pre>\nTASK [Instalar o Nginx] ********************************************************\nchanged: [web01]\nchanged: [web02]\n\nTASK [Publicar a p\u00e1gina inicial] ***********************************************\nchanged: [web01]\nchanged: [web02]\n\nTASK [Garantir o Nginx ativo e habilitado no boot] *****************************\nchanged: [web02]\nchanged: [web01]\n\nRUNNING HANDLER [Recarregar o Nginx] *******************************************\nchanged: [web02]\nchanged: [web01]\n\nPLAY RECAP *********************************************************************\nweb01 : ok=5 changed=4 unreachable=0 failed=0 skipped=0 ...\nweb02 : ok=5 changed=4 unreachable=0 failed=0 skipped=0 ...<\/code><\/pre>\nIdempot\u00eancia: rode de novo<\/h3>\n
web01 : ok=4 changed=0 unreachable=0 failed=0 ...\nweb02 : ok=4 changed=0 unreachable=0 failed=0 ...<\/code><\/pre>\nchanged=0<\/code>. Essa \u00e9 a idempot\u00eancia<\/strong>, o cora\u00e7\u00e3o do Ansible: ele n\u00e3o “executa comandos”, ele garante estados. O Nginx j\u00e1 estava instalado, a p\u00e1gina j\u00e1 era a certa, o servi\u00e7o j\u00e1 estava ativo, e nada foi tocado. O handler tamb\u00e9m n\u00e3o rodou, porque nenhuma tarefa mudou.<\/p>\nSimular antes de aplicar:
--check<\/code> e --diff<\/code><\/h3>\ngroup_vars\/webservers.yml<\/code> para “Servidor web do LinuxPro” e simule, s\u00f3 no web01<\/code>:<\/p>\nansible-playbook site.yml --check --diff --limit web01<\/code><\/pre>\nTASK [Publicar a p\u00e1gina inicial] ***********************************************\n--- before: \/var\/www\/html\/index.html\n+++ after: \/root\/.ansible\/tmp\/ansible-local-586tfwktpl6\/tmp5owga2ot\/index.html.j2\n@@ -1,8 +1,8 @@\n <!doctype html>\n <html lang=\"pt-br\">\n-<head><meta charset=\"utf-8\"><title>Servidor gerenciado pelo Ansible<\/title><\/head>\n+<head><meta charset=\"utf-8\"><title>Servidor web do LinuxPro<\/title><\/head>\n <body>\n- <h1>Servidor gerenciado pelo Ansible<\/h1>\n+ <h1>Servidor web do LinuxPro<\/h1>\n <p>Host: web01 (Ubuntu 24.04)<\/p>\n <\/body>\n <\/html>\n\nchanged: [web01]<\/code><\/pre>\n--check<\/code> n\u00e3o altera nada, e o --diff<\/code> mostra exatamente o que mudaria. Aplicando de verdade, s\u00f3 a p\u00e1gina e o handler aparecem como changed<\/code>, e o Nginx \u00e9 recarregado uma \u00fanica vez.<\/p>\n--check<\/code>, vistos nos testes:<\/p>\n\n
Could not find the requested service nginx<\/code>. \u00c9 esperado: a simula\u00e7\u00e3o vale mais para revisar mudan\u00e7as em servidores que j\u00e1 est\u00e3o configurados.<\/li>\napt<\/code> precisa do pacote python3-apt<\/code><\/strong> para simular. O Ubuntu Server j\u00e1 o traz; imagens m\u00ednimas, como as de cont\u00eainer, n\u00e3o, e o erro diz python3-apt must be installed to use check mode<\/code>. Numa execu\u00e7\u00e3o normal, o pr\u00f3prio m\u00f3dulo instala o pacote.<\/li>\n<\/ul>\nTransformando o playbook em role<\/h2>\n
ansible-galaxy role init roles\/nginx<\/code><\/pre>\nroles\/nginx\/<\/code>. Mova as tarefas para roles\/nginx\/tasks\/main.yml<\/code>, o handler para roles\/nginx\/handlers\/main.yml<\/code> e o template para roles\/nginx\/templates\/<\/code>. Dentro da role, o src<\/code> do template passa a ser s\u00f3 index.html.j2<\/code>, porque o Ansible procura na pasta templates\/<\/code> da pr\u00f3pria role. O site.yml<\/code> fica curto:<\/p>\n---\n- name: Configurar servidores web\n hosts: webservers\n become: true\n roles:\n - nginx<\/code><\/pre>\nnginx : Instalar o Nginx<\/code>) e o resultado continua changed=0<\/code>: mudou a organiza\u00e7\u00e3o, n\u00e3o o estado dos servidores.<\/p>\nPr\u00f3ximos passos<\/h2>\n
\n
ansible-vault<\/code> e atualiza\u00e7\u00e3o em ondas.<\/li>\nansible-doc -l<\/code>.<\/li>\nchanged=0<\/code>: nesse momento fica claro por que tanta gente parou de configurar servidor na m\u00e3o.<\/p>\n","protected":false},"excerpt":{"rendered":"