Introdução
Ter um pacote instalado, um arquivo de configuração existente e um serviço respondendo são resultados diferentes. Você gerenciará cada um explicitamente: instalará e removerá um utilitário, configurará o nginx, declarará seu estado em execução e recarregará configurações alteradas por meio de um handler. Respostas HTTP reais dos dois nós gerenciados comprovarão que o serviço funciona.
Declarar estados de pacotes instalados e ausentes
Nesta etapa, você instalará um pequeno utilitário, o inspecionará e o removerá por meio de uma declaração reutilizável de pacote.
O módulo apt gerencia pacotes Ubuntu no host gerenciado. Seu state: present solicita a instalação e state: absent solicita a remoção. Este ambiente inclui listas de pacotes preparadas e downloads em cache, portanto mantenha update_cache: false; atualizar listas ou solicitar as versões mais recentes acrescentaria dependências de rede desnecessárias. As políticas de atualização em produção podem ser diferentes.
Entre no projeto do controlador:
cd /home/labex/project
Crie um playbook cuja variável seleciona o estado desejado do pacote tree. As operações de pacotes exigem become nos destinos. install_recommends: false evita pacotes recomendados opcionais.
cat > packages.yml <<'YAML'
- name: Declare a utility package state
hosts: all
gather_facts: false
become: true
vars:
utility_state: present
tasks:
- name: Converge the tree package
ansible.builtin.apt:
name: tree
state: "{{ utility_state }}"
update_cache: false
install_recommends: false
YAML
Instale o utilitário:
ansible-playbook packages.yml
O comando tree exibe árvores de diretórios; aqui, sua opção de versão demonstra que o executável está realmente instalado em cada nó gerenciado:
ansible all -m ansible.builtin.command -a 'tree --version'
Cada destino deve retornar uma versão de tree. Repita o playbook; pacotes presentes não devem precisar de outra instalação:
ansible-playbook packages.yml
Agora solicite a ausência com uma variável extra, em vez de editar a tarefa reutilizável:
ansible-playbook packages.yml -e utility_state=absent
Repita o mesmo estado desejado de ausência. As duas linhas do resumo agora devem mostrar changed=0, failed=0 e unreachable=0:
ansible-playbook packages.yml -e utility_state=absent
O estado de um pacote é uma declaração sobre a instalação, não uma prova de que um serviço está em execução ou respondendo. Deixe tree ausente enquanto a próxima etapa implanta o nginx.
Configurar e iniciar um serviço web real
Nesta etapa, você instalará o nginx, implantará uma configuração completa validada e manterá explicitamente seu serviço em execução.
Os dois nós gerenciados são contêineres com destinos SSH e sistemas de arquivos separados. Eles não executam systemd. O módulo service usa o gerenciador de serviços disponível neles; não execute systemctl nesses destinos. Gerenciaremos o estado atual de execução, em vez de prometer uma política de inicialização do systemd.
Crie uma página estática no controlador. Ela termina com uma quebra de linha para que seus bytes gerenciados exatos sejam previsíveis:
printf 'Ansible service ready\n' > page.txt
Escreva uma configuração nginx completa. events e http são contextos nginx de nível superior, server define um site, listen escolhe a porta 8080, root seleciona seu diretório de documentos e index seleciona a página para solicitações a /. Essas são configurações nginx, não YAML do Ansible.
cat > nginx-course.conf <<'NGINX'
events {}
http {
server {
listen 8080;
root /var/www/ansible-site;
index index.html;
}
}
NGINX
Crie o playbook de implantação. A tarefa apt usa policy_rc_d: 101 para impedir que o instalador de pacotes inicie o nginx implicitamente; a tarefa service posterior declara explicitamente o estado em execução. O validate da tarefa copy executa o teste de configuração do nginx em um candidato temporário (%s) antes de substituir o destino.
Um handler é uma ação nomeada listada em handlers. Uma tarefa de configuração alterada notifica Reload nginx, que executa uma vez ao fim do play. Nenhuma alteração de configuração significa nenhuma notificação. A tarefa service comum usa started, que mantém um serviço já em execução sem reiniciá-lo incondicionalmente.
cat > web.yml <<'YAML'
- name: Deploy a working web service
hosts: all
gather_facts: false
become: true
tasks:
- name: Install nginx without refreshing the prepared package lists
ansible.builtin.apt:
name: nginx
state: present
update_cache: false
install_recommends: false
policy_rc_d: 101
- name: Prepare the site directory
ansible.builtin.file:
path: /var/www/ansible-site
state: directory
owner: root
group: root
mode: "0755"
- name: Deploy the static page
ansible.builtin.copy:
src: /home/labex/project/page.txt
dest: /var/www/ansible-site/index.html
owner: root
group: root
mode: "0644"
- name: Validate and deploy nginx configuration
ansible.builtin.copy:
src: /home/labex/project/nginx-course.conf
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: "0644"
validate: /usr/sbin/nginx -t -c %s
notify: Reload nginx
- name: Keep nginx running
ansible.builtin.service:
name: nginx
state: started
handlers:
- name: Reload nginx
ansible.builtin.service:
name: nginx
state: reloaded
YAML
Verifique a sintaxe e aplique a implantação:
ansible-playbook web.yml --syntax-check
ansible-playbook web.yml
Os dois nós devem instalar o nginx, receber os arquivos e iniciar com sucesso. Uma primeira alteração na configuração também agenda o handler de recarga. Verificar apenas a versão de um pacote não comprovaria nenhum desses comportamentos do serviço.
curl é um cliente HTTP. Sua opção --fail trata um status HTTP malsucedido como falha do comando; --silent remove a saída de progresso e --show-error mantém os detalhes das falhas. Execute-o em cada host gerenciado contra a interface de loopback do próprio host:
ansible all -m ansible.builtin.command -a 'curl --fail --silent --show-error http://127.0.0.1:8080/'
Cada resultado deve conter Ansible service ready. O controlador e cada destino têm interfaces de loopback separadas; esse comando verifica os dois serviços dos destinos, não o controlador.
Aplicar uma alteração de configuração por meio de um handler
Nesta etapa, você alterará uma configuração ativa do nginx, observará o handler e confirmará a configuração por uma resposta HTTP.
A diretiva server_tokens do nginx controla se os cabeçalhos de resposta expõem sua versão. Acrescente server_tokens off dentro de http substituindo a configuração no controlador por esta versão completa:
cat > nginx-course.conf <<'NGINX'
events {}
http {
server_tokens off;
server {
listen 8080;
root /var/www/ansible-site;
index index.html;
}
}
NGINX
Aplique o mesmo playbook:
ansible-playbook web.yml
A cópia da configuração deve informar changed e notificar Reload nginx nos dois hosts. O handler recarrega o serviço em execução depois que a nova configuração passa na validação. Sua execução torna a configuração efetiva; apenas copiar um arquivo não comprova o que o processo carregou.
O -I de curl solicita cabeçalhos HTTP. Inspecione a resposta real do serviço nos dois hosts:
ansible all -m ansible.builtin.command -a 'curl --fail --silent --show-error -I http://127.0.0.1:8080/'
As duas respostas devem ter um status HTTP de sucesso e um cabeçalho Server de nginx sem sufixo de versão. Outros campos de cabeçalho, como datas, variam.
Repita o playbook completo:
ansible-playbook web.yml
Os dois hosts devem informar changed=0 sem tarefas failed ou unreachable, e nenhum handler de recarga deve ser agendado. A página estática continua disponível, tree permanece ausente e nginx continua instalado e em execução.
Resumo
Você declarou a presença e a ausência de pacotes, separou a instalação do estado em execução do serviço e implantou uma configuração nginx completa com validação do candidato. Uma configuração alterada notificou um handler de recarga, respostas HTTP reais comprovaram o comportamento ativo e uma repetição sem alterações evitou mudanças ou recargas extras.
