Introdução
Uma vez que o inventário e o acesso estejam funcionando, uma tarefa comum é a implantação de arquivos de linha de base (baseline). Esses arquivos podem incluir banners, trechos de configuração de serviços ou marcadores de conformidade que devem ser consistentes entre os hosts, mas que ainda precisam conter valores específicos para cada um deles.
Neste laboratório, você criará um pequeno inventário multi-host, definirá variáveis de grupo, escreverá um modelo (template), executará um playbook e verificará os arquivos de linha de base gerados para cada host.
Criar o Projeto de Implantação de Linha de Base
Nesta etapa, você criará um projeto com inventário, modelos, arquivos e playbooks. A estrutura separa o conteúdo de origem reutilizável da lógica do playbook.
Crie e acesse o diretório do projeto.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory/group_vars,playbooks,files,templates,managed}
cd rhce-ansible
Crie o arquivo ansible.cfg.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
retry_files_enabled = False
interpreter_python = auto_silent
EOF
Os diretórios separam as funções no fluxo de trabalho: files armazena o conteúdo copiado sem alterações, templates armazena o conteúdo renderizado com variáveis, playbooks contém a lógica de automação e managed mostrará o resultado final para cada host.
Criar Inventário e Variáveis de Linha de Base
Nesta etapa, você definirá dois aliases de hosts gerenciados e variáveis de linha de base compartilhadas. As variáveis serão usadas posteriormente em um modelo.
Antes de executar os comandos nesta etapa, retorne ao diretório do projeto Ansible. Isso mantém os comandos estáveis, mesmo quando o LabEx executa cada etapa separadamente.
cd /home/labex/project/rhce-ansible
Crie o inventário.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
node2 ansible_connection=local
EOF
Os dois aliases permitem que um único playbook produza duas saídas gerenciadas distintas. Embora ambos os aliases sejam executados na mesma VM, o Ansible renderiza o inventory_hostname de forma diferente para cada host.
Crie variáveis de grupo para os hosts gerenciados.
cat > inventory/group_vars/managed.yml <<'EOF'
baseline_owner: labex
baseline_environment: training
EOF
Essas variáveis se aplicam a todos os hosts no grupo managed. Elas representam valores que devem ser compartilhados em toda a linha de base, enquanto o nome do host permanecerá específico para cada um.
Criar Arquivo de Origem e Modelo
Nesta etapa, você criará o conteúdo de origem. O arquivo simples é copiado sem alterações. O modelo Jinja2 usa variáveis como inventory_hostname e baseline_environment para renderizar uma saída específica para cada host.
Antes de executar os comandos nesta etapa, retorne ao diretório do projeto Ansible.
cd /home/labex/project/rhce-ansible
Crie um arquivo de banner compartilhado.
cat > files/banner.txt <<'EOF'
Managed by RHCE Ansible Prep
EOF
O banner é um conteúdo de origem simples. Ele será copiado exatamente como foi escrito, sendo útil para textos que não devem variar conforme o host.
Crie um modelo (template).
cat > templates/baseline.conf.j2 <<'EOF'
host={{ inventory_hostname }}
environment={{ baseline_environment }}
owner={{ baseline_owner }}
EOF
O modelo contém expressões Jinja2. Quando o Ansible o renderiza, inventory_hostname torna-se node1 ou node2, enquanto as variáveis de linha de base são obtidas de inventory/group_vars/managed.yml.
Escrever o Playbook de Implantação de Linha de Base
Nesta etapa, você escreverá um playbook que cria um diretório por alias de host e implanta tanto o banner compartilhado quanto o modelo renderizado. Como o playbook está armazenado em playbooks, os caminhos de origem usam ../files e ../templates.
Antes de executar os comandos nesta etapa, retorne ao diretório do projeto Ansible.
cd /home/labex/project/rhce-ansible
Crie o playbook.
cat > playbooks/deploy-baseline.yml <<'EOF'
---
- name: Deploy baseline files to managed aliases
hosts: managed
gather_facts: false
tasks:
- name: Create per-host baseline directory
ansible.builtin.file:
path: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}"
state: directory
mode: '0755'
- name: Copy shared banner
ansible.builtin.copy:
src: ../files/banner.txt
dest: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}/banner.txt"
mode: '0644'
- name: Render baseline configuration
ansible.builtin.template:
src: ../templates/baseline.conf.j2
dest: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}/baseline.conf"
mode: '0644'
EOF
Considere as três tarefas como uma sequência completa de implantação. Primeiro, o diretório de destino é criado para cada alias de host, depois o banner estático é copiado e, finalmente, o modelo é renderizado em um arquivo de configuração específico para o host.
Execute uma verificação de sintaxe.
ansible-playbook playbooks/deploy-baseline.yml --syntax-check
A verificação de sintaxe deve imprimir uma linha playbook:. Isso confirma que o Ansible consegue analisar os caminhos de origem relativos antes que o playbook escreva qualquer arquivo gerenciado.
Executar e Verificar a Implantação da Linha de Base
Nesta etapa, você executará o playbook e inspecionará os arquivos renderizados. A configuração renderizada deve diferir pelo nome do host, mantendo os valores compartilhados de ambiente e proprietário.
Antes de executar os comandos nesta etapa, retorne ao diretório do projeto Ansible.
cd /home/labex/project/rhce-ansible
Execute o playbook.
ansible-playbook playbooks/deploy-baseline.yml
A primeira execução deve relatar alterações, pois os diretórios e arquivos gerenciados ainda não existem. Um resumo bem-sucedido com failed=0 significa que cada alias de host recebeu a linha de base.
Inspecione os arquivos implantados.
find managed -maxdepth 3 -type f -print
cat managed/node1/banner.txt managed/node1/baseline.conf managed/node2/banner.txt managed/node2/baseline.conf
Os arquivos banner.txt devem ser exatamente iguais. Os arquivos baseline.conf devem compartilhar os mesmos valores de environment e owner, mas diferir na linha host=.
Resumo
Você implantou arquivos de linha de base em aliases de hosts gerenciados usando variáveis de inventário, um arquivo de origem compartilhado e um modelo Jinja2. Isso completa a base para alterações de estado repetíveis em nós gerenciados.
