Roles e Coleções Ansible no RHEL

Introdução

Neste laboratório, você aprenderá a automatizar a configuração de um servidor web Red Hat Enterprise Linux (RHEL) aproveitando o poder e a reutilização de Roles e Collections do Ansible. Você construirá um fluxo de trabalho de automação abrangente criando uma role personalizada para implantar configurações específicas, integrando uma role externa de um repositório Git como dependência e utilizando uma RHEL System Role pré-construída de uma Ansible Collection para gerenciar serviços do sistema como o SELinux.

O processo começa com a criação de uma estrutura de role padronizada usando ansible-galaxy init. Em seguida, você definirá e instalará uma dependência de role de um repositório Git usando um arquivo requirements.yml. Após integrar uma RHEL System Role, você montará todos os três tipos de roles — personalizada, baseada em Git e baseada em Collection — em um único playbook mestre. Finalmente, você executará o playbook e verificará se o servidor web Apache e as configurações do SELinux foram aplicadas corretamente ao servidor RHEL de destino, demonstrando uma solução de automação completa e modular.

Criar uma Role Personalizada do Ansible com ansible-galaxy init

Nesta etapa, você começará criando uma estrutura de diretórios padronizada para uma nova role do Ansible usando o comando ansible-galaxy init. As roles do Ansible são um conceito fundamental para a construção de conteúdo de automação reutilizável e organizado. Elas permitem empacotar tarefas, handlers, variáveis e outros componentes em uma unidade autônoma e portátil. O uso de uma estrutura padrão é uma boa prática que torna sua automação mais fácil de entender, gerenciar e compartilhar.

Primeiro, certifique-se de estar no diretório de trabalho correto. Todo o trabalho para este laboratório será feito dentro do diretório ~/project.

cd ~/project

Antes de criar uma role, você precisa garantir que as ferramentas de linha de comando do Ansible estejam instaladas. O pacote ansible-core fornece as ferramentas essenciais, incluindo ansible-galaxy.

Instale o ansible-core usando o gerenciador de pacotes dnf. A flag -y responde automaticamente "sim" a quaisquer prompts de confirmação.

sudo dnf install -y ansible-core

Você deverá ver uma saída indicando que o pacote está sendo instalado e as dependências estão sendo resolvidas.

...
Installed:
  ansible-core-2.16.x-1.el9.x86_64
  ...
Complete!

É uma prática comum organizar todas as roles do projeto dentro de um diretório dedicado roles. Crie este diretório agora.

mkdir roles

Agora, navegue para dentro do diretório roles recém-criado. É aqui que você inicializará sua nova role personalizada.

cd roles

Você agora usará o comando ansible-galaxy init para criar um esqueleto para uma role chamada apache.developer_configs. Este comando gera automaticamente um conjunto de diretórios e arquivos padrão, fornecendo um ponto de partida limpo para o desenvolvimento da sua role.

ansible-galaxy init apache.developer_configs

Após executar o comando, você verá uma mensagem de confirmação.

- Role apache.developer_configs was created successfully

Para ver a estrutura que acabou de ser criada, você pode usar o comando ls -R, que lista o conteúdo de um diretório e todos os seus subdiretórios recursivamente.

ls -R apache.developer_configs

A saída mostra a estrutura de diretórios padrão para uma role do Ansible:

apache.developer_configs:
defaults  files  handlers  meta  README.md  tasks  templates  tests  vars

apache.developer_configs/defaults:
main.yml

apache.developer_configs/files:

apache.developer_configs/handlers:
main.yml

apache.developer_configs/meta:
main.yml

apache.developer_configs/tasks:
main.yml

apache.developer_configs/templates:

apache.developer_configs/tests:
inventory  test.yml

apache.developer_configs/vars:
main.yml

Aqui está uma breve visão geral dos diretórios mais importantes:

• tasks: Contém a lista principal de tarefas a serem executadas pela role.
• handlers: Contém handlers, que são tarefas que só são executadas quando notificadas por outra tarefa.
• vars: Contém variáveis para a role.
• templates: Contém templates de arquivos que usam o motor de template Jinja2.
• meta: Contém metadados para a role, incluindo dependências de outras roles.

Você agora criou com sucesso a estrutura básica para sua role personalizada do Ansible. Nas próximas etapas, você preencherá esses diretórios com conteúdo para configurar um servidor web.

Instalar uma Dependência de Role de um Repositório Git usando requirements.yml

Nesta etapa, você aprenderá a gerenciar dependências de roles de fontes externas, como um repositório Git. Esta é uma prática comum em projetos Ansible maiores onde você reutiliza roles desenvolvidas pela comunidade ou por outras equipes. O Ansible usa um arquivo, tipicamente chamado requirements.yml, para definir uma lista de roles a serem instaladas.

Sua role personalizada, apache.developer_configs, dependerá de uma role Apache fundamental para garantir que o servidor web seja instalado e esteja em execução. Você definirá essa dependência e a instalará.

Primeiro, certifique-se de estar no diretório principal do projeto. Se você ainda estiver no subdiretório roles da etapa anterior, retorne para ~/project.

cd ~/project

Agora, você criará o arquivo requirements.yml dentro do seu diretório roles. Este arquivo listará todas as roles externas que seu projeto precisa. Use o editor nano para criar e editar o arquivo.

nano roles/requirements.yml

Adicione o seguinte conteúdo ao arquivo. Esta entrada informa ao ansible-galaxy para baixar uma versão específica de uma role Apache de um repositório Git público e nomeá-la localmente como infra.apache.

- name: infra.apache
  src: https://github.com/geerlingguy/ansible-role-apache.git
  scm: git
  version: 3.2.0

Vamos detalhar esta definição:

• name: Este é o nome local para a role. Mesmo que o repositório de origem tenha um nome diferente, ele será instalado em um diretório chamado infra.apache.
• src: O URL de origem do repositório Git.
• scm: Especifica a ferramenta de gerenciamento de controle de origem, que neste caso é git.
• version: O branch, tag ou hash de commit Git específico a ser usado. Fixar uma versão é crucial para garantir que sua automação seja estável e previsível.

Salve o arquivo e saia do nano pressionando Ctrl+X, seguido por Y e depois Enter.

Com o arquivo requirements.yml no lugar, você agora pode usar o comando ansible-galaxy install para baixar e instalar a role.

• A flag -r aponta para o seu arquivo de requisitos.
• A flag -p especifica o caminho onde as roles devem ser instaladas.

ansible-galaxy install -r roles/requirements.yml -p roles

Você verá uma saída confirmando o processo de download e instalação.

Starting galaxy role install process
- downloading role 'ansible-role-apache', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-apache/archive/3.2.0.tar.gz
- extracting infra.apache to /home/labex/project/roles/infra.apache
- infra.apache (3.2.0) was installed successfully

Para confirmar que a role foi instalada corretamente, liste o conteúdo do diretório roles.

ls -l roles

Você agora deverá ver o diretório infra.apache ao lado da role apache.developer_configs que você criou anteriormente.

total 12
drwxr-xr-x. 9 labex labex 4096 Nov 10 10:10 apache.developer_configs
drwxr-xr-x. 9 labex labex 4096 Nov 10 10:15 infra.apache
-rw-r--r--. 1 labex labex  118 Nov 10 10:12 requirements.yml

Você agora declarou com sucesso um repositório Git externo como uma dependência e o instalou em seu projeto. A próxima etapa é integrar essa dependência nos metadados da sua role personalizada.

Integrar uma System Role do RHEL de uma Coleção Ansible

Nesta etapa, você trabalhará com Coleções Ansible (Ansible Collections), que são a forma padrão de distribuir conteúdo Ansible, incluindo roles, módulos e plugins. Você instalará a coleção community.general, que fornece um conjunto de módulos úteis para automatizar tarefas administrativas comuns, incluindo o gerenciamento do SELinux.

Para o nosso cenário de servidor web, precisamos configurar corretamente o SELinux para permitir que o serviço Apache escute em portas não padrão. A coleção community.general inclui módulos SELinux que são perfeitos para esta tarefa.

Primeiro, certifique-se de que você está no diretório principal do projeto.

cd ~/project

É uma boa prática manter as coleções instaladas dentro do diretório do projeto para tornar seu projeto autossuficiente. Crie um diretório chamado collections para armazená-las.

mkdir collections

Agora, use o comando ansible-galaxy collection install para instalar as coleções necessárias. O flag -p indica ao comando para instalar as coleções no diretório collections que você acabou de criar.

ansible-galaxy collection install community.general:7.5.0 ansible.posix:1.5.4 -p collections

O comando baixará as coleções e suas dependências. Você verá uma saída semelhante à seguinte:

Starting galaxy collection install process
Process install dependency map
Starting collection install process
Installing 'community.general:7.5.0' to '/home/labex/project/collections/ansible_collections/community/general'
Installing 'ansible.posix:1.5.4' to '/home/labex/project/collections/ansible_collections/ansible/posix'
...
community.general:7.5.0 was installed successfully
ansible.posix:1.5.4 was installed successfully

Para verificar se a coleção está agora disponível para o seu projeto, você pode listar todas as coleções instaladas especificando o caminho das coleções.

ansible-galaxy collection list -p collections

A saída mostrará as coleções instaladas e seus caminhos de instalação dentro do seu projeto.

## /home/labex/project/collections/ansible_collections
Collection              Version
----------------------- -------
ansible.posix           1.5.4
community.general       7.5.0

Ao usar um módulo de uma coleção em um playbook, você deve se referir a ele pelo seu Nome de Coleção Totalmente Qualificado (Fully Qualified Collection Name - FQCN). Para gerenciamento do SELinux, você usará ansible.posix.selinux para o gerenciamento do estado do SELinux e community.general.seport para o gerenciamento de portas do SELinux.

Você agora instalou com sucesso coleções poderosas que incluem módulos de gerenciamento do SELinux. Na próxima etapa, você montará um playbook que usa sua role personalizada, a role do Git e os módulos SELinux dessas coleções para configurar completamente o servidor web de desenvolvimento.

Montar e Executar um Playbook com Roles Personalizadas, Git e de Sistema

Nesta etapa, você reunirá todos os componentes que preparou: sua role personalizada, a dependência do Git e a RHEL System Role. Você criará um playbook principal que orquestra essas roles para configurar completamente o servidor web de desenvolvimento.

Pense nesta etapa como a montagem de uma máquina complexa a partir de diferentes peças - cada role serve a um propósito específico e elas trabalham juntas para criar um ambiente completo de servidor web. Vamos detalhar isso em partes gerenciáveis:

Primeiro, certifique-se de estar no diretório principal do projeto.

cd ~/project

Antes de mergulhar na configuração, vamos entender o que estamos criando:

• Configuração do Ansible: Configura como o Ansible se comporta e onde encontra os arquivos
• Inventário: Define quais servidores gerenciar (no nosso caso, localhost)
• Variáveis: Armazenam dados que nossas roles usarão (informações do desenvolvedor, configurações do SELinux)
• Conteúdo da Role Personalizada: As tarefas reais que configurarão os ambientes de desenvolvimento
• Playbook Principal: O orquestrador que executa tudo na ordem correta

1. Criar Configuração e Inventário do Ansible

O arquivo ansible.cfg é como um arquivo de configuração que diz ao Ansible como se comportar. Sem ele, você precisaria especificar caminhos e opções em cada comando. Com ele, o Ansible sabe automaticamente onde encontrar suas roles, coleções e inventário.

Crie o arquivo ansible.cfg usando nano. Este arquivo diz ao Ansible onde encontrar suas roles, coleções e inventário.

nano ansible.cfg

Adicione o seguinte conteúdo. Vamos entender cada linha:

[defaults]
inventory = inventory
roles_path = roles
collections_paths = collections
host_key_checking = False

[privilege_escalation]
become = True

O que cada configuração faz:

• inventory = inventory: Em vez de digitar -i inventory toda vez, o Ansible usará automaticamente este arquivo
• roles_path = roles: O Ansible procurará roles no diretório roles
• collections_paths = collections: O Ansible encontrará suas coleções instaladas aqui
• host_key_checking = False: Impede erros de verificação de chave SSH em ambientes de laboratório
• become = True: Executa automaticamente tarefas com privilégios elevados quando necessário

Salve e saia do nano (Pressione Ctrl+X, depois Y, depois Enter).

O arquivo de inventário diz ao Ansible quais máquinas gerenciar. No nosso caso, estamos configurando a máquina local.

nano inventory

Adicione a seguinte linha:

localhost ansible_connection=local

O que isso significa:

• localhost: O nome do nosso host de destino
• ansible_connection=local: Em vez de SSH, use conexões locais (já que estamos gerenciando a mesma máquina em que estamos executando o Ansible)

Salve e saia do nano.

2. Definir Variáveis de Role

Variáveis no Ansible são como configurações que suas roles podem usar. Em vez de codificar valores como nomes de usuário ou números de porta em suas tarefas, você os define em arquivos de variáveis. Isso torna sua automação flexível e reutilizável.

O diretório group_vars/all é um local especial onde o Ansible carrega automaticamente variáveis para todos os hosts. Qualquer arquivo YAML neste diretório fica disponível para seus playbooks e roles.

Crie a estrutura de diretórios para variáveis que se aplicam a todos os hosts:

mkdir -p group_vars/all

Agora, crie um arquivo para definir as informações do desenvolvedor. Esses dados serão usados por sua role personalizada para criar contas de usuário e configurações web.

nano group_vars/all/developers.yml

Adicione o seguinte conteúdo:

---
web_developers:
  - username: jdoe ## Primeiro desenvolvedor
    port: 9081 ## Porta personalizada para o site deste desenvolvedor
  - username: jdoe2 ## Segundo desenvolvedor
    port: 9082 ## Porta personalizada para o site deste desenvolvedor

O que esta estrutura de dados significa:

• web_developers: Uma lista contendo informações do desenvolvedor
• Cada desenvolvedor tem um username e uma port
• Sua role personalizada percorrerá esta lista para criar configurações para cada desenvolvedor

Salve e saia.

Em seguida, crie um arquivo de variáveis para a configuração do SELinux. SELinux (Security-Enhanced Linux) é um módulo de segurança que controla o que os aplicativos podem fazer.

nano group_vars/all/selinux.yml

Adicione o seguinte conteúdo:

---
selinux_state: enforcing ## Define o SELinux para o modo enforcing (maior segurança)
selinux_ports: ## Lista de portas para permitir que o Apache use
  - ports: "9081" ## Permite a porta 9081
    proto: "tcp" ## Protocolo: TCP
    setype: "http_port_t" ## Tipo SELinux: porta HTTP
    state: "present" ## Adiciona esta regra
  - ports: "9082" ## Permite a porta 9082
    proto: "tcp" ## Protocolo: TCP
    setype: "http_port_t" ## Tipo SELinux: porta HTTP
    state: "present" ## Adiciona esta regra

Entendendo as configurações do SELinux:

• selinux_state: enforcing: O SELinux bloqueará ativamente ações não autorizadas
• selinux_ports: Uma lista de configurações de porta
• http_port_t: O tipo SELinux que permite ao Apache vincular-se a portas
• Por padrão, o Apache só pode usar as portas 80 e 443; precisamos permitir explicitamente 9081 e 9082

Salve e saia.

3. Popular a Role Personalizada

Sua role apache.developer_configs atualmente tem a estrutura de diretórios, mas nenhum conteúdo real. Precisamos adicionar:

• Templates: Arquivos que podem incluir variáveis (usando sintaxe Jinja2)
• Tarefas: O trabalho real que o Ansible realizará
• Handlers: Tarefas especiais que só são executadas quando notificadas (como reiniciar serviços)
• Metadados: Informações sobre dependências de roles

Templates permitem que você crie arquivos de configuração que se adaptam com base em suas variáveis. A extensão .j2 indica que este é um template Jinja2.

nano roles/apache.developer_configs/templates/developer.conf.j2

Adicione o seguinte conteúdo:

{% for dev in web_developers %}
Listen {{ dev.port }}
<VirtualHost *:{{ dev.port }}>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/{{ dev.username }}

    <Directory /var/www/{{ dev.username }}>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
{% endfor %}

Entendendo a sintaxe do template:

• {% for dev in web_developers %}: Inicia um loop pela lista de desenvolvedores
• {{ dev.port }}: Insere o número da porta para este desenvolvedor
• {{ dev.username }}: Insere o nome de usuário para este desenvolvedor
• {% endfor %}: Finaliza o loop
• O resultado serão configurações de virtual host separadas para cada desenvolvedor

O que isso cria: Para nossos dois desenvolvedores, este template gerará a configuração do Apache que:

1. Faz o Apache escutar nas portas 9081 e 9082
2. Cria virtual hosts que servem conteúdo de /var/www/jdoe e /var/www/jdoe2
3. Define permissões apropriadas para cada diretório

Salve e saia.

Tarefas são o trabalho real que o Ansible realiza. Cada tarefa usa um módulo Ansible para realizar algo específico.

nano roles/apache.developer_configs/tasks/main.yml

Adicione o seguinte conteúdo e vamos entender cada tarefa:

---
## Tarefa 1: Criar contas de usuário para cada desenvolvedor
- name: Create developer user accounts
  ansible.builtin.user: ## Usa o módulo 'user'
    name: "{{ item.username }}" ## Cria o usuário com este nome
    state: present ## Garante que o usuário exista
  loop: "{{ web_developers }}" ## Faz isso para cada desenvolvedor na lista

## Tarefa 2: Criar diretórios web para cada desenvolvedor
- name: Create developer web root directories
  ansible.builtin.file: ## Usa o módulo 'file'
    path: "/var/www/{{ item.username }}" ## Cria este diretório
    state: directory ## Garante que seja um diretório
    owner: "{{ item.username }}" ## Define o proprietário
    group: "{{ item.username }}" ## Define o grupo
    mode: "0755" ## Define as permissões (rwxr-xr-x)
  loop: "{{ web_developers }}"

## Tarefa 3: Criar uma página de exemplo index.html para cada desenvolvedor
- name: Create a sample index.html for each developer
  ansible.builtin.copy: ## Usa o módulo 'copy'
    content: "Welcome to {{ item.username }}'s dev space\n" ## Conteúdo do arquivo
    dest: "/var/www/{{ item.username }}/index.html" ## Onde colocar o arquivo
    owner: "{{ item.username }}" ## Proprietário do arquivo
    group: "{{ item.username }}" ## Grupo do arquivo
    mode: "0644" ## Permissões do arquivo (rw-r--r--)
  loop: "{{ web_developers }}"

## Tarefa 4: Implantar o arquivo de configuração do Apache
- name: Deploy developer apache configs
  ansible.builtin.template: ## Usa o módulo 'template'
    src: developer.conf.j2 ## Arquivo de template de origem
    dest: /etc/httpd/conf.d/developer.conf ## Destino no servidor
    mode: "0644" ## Permissões do arquivo
  notify: restart apache ## Aciona o handler de reinício quando isso mudar

Entendendo os conceitos chave:

• loop: Repete a tarefa para cada item na lista
• {{ item.username }}: Refere-se ao nome de usuário do item atual no loop
• notify: restart apache: Quando esta tarefa fizer alterações, ela acionará um handler chamado "restart apache"
• Permissões de arquivo: 0755 significa que o proprietário pode ler/escrever/executar, outros podem ler/executar; 0644 significa que o proprietário pode ler/escrever, outros podem apenas ler

Salve e saia.

Handlers são tarefas especiais que só são executadas quando notificadas por outras tarefas. Eles são tipicamente usados para ações como reiniciar serviços.

nano roles/apache.developer_configs/handlers/main.yml

Adicione o seguinte conteúdo:

---
- name: restart apache ## Este nome deve corresponder à declaração notify:
  ansible.builtin.service: ## Usa o módulo 'service'
    name: httpd ## O nome do serviço (Apache é chamado 'httpd' no RHEL)
    state: restarted ## Reinicia o serviço

Por que usar handlers?

• Eficiência: O serviço só reinicia se a configuração realmente mudou
• Ordem: Todas as tarefas são executadas primeiro, depois todos os handlers são executados no final
• Idempotência: Várias tarefas podem notificar o mesmo handler, mas ele só é executado uma vez

Salve e saia.

Finalmente, precisamos dizer ao Ansible que nossa role personalizada depende da role infra.apache que instalamos anteriormente.

nano roles/apache.developer_configs/meta/main.yml

Substitua o conteúdo do arquivo por:

---
dependencies:
  - role: infra.apache ## Esta role deve ser executada antes da nossa role personalizada

O que isso faz:

• Quando o Ansible executar apache.developer_configs, ele executará automaticamente infra.apache primeiro
• Isso garante que o Apache esteja instalado e configurado antes de adicionarmos nossas configurações personalizadas
• As dependências são executadas na ordem em que são listadas

Salve e saia.

4. Montar e Executar o Playbook Principal

Um playbook é como uma receita que diz ao Ansible o que fazer e em que ordem. Nosso playbook fará o seguinte:

1. Configurar as configurações do SELinux (pre_tasks)
2. Executar nossas roles (que inclui a cadeia de dependências)

Crie o arquivo do playbook principal:

nano web_dev_server.yml

Adicione o seguinte conteúdo com explicações detalhadas:

---
- name: Configure Dev Web Server ## Nome do Playbook
  hosts: localhost ## Executa no localhost
  pre_tasks: ## Tarefas que executam antes das roles
    ## Tarefa 1: Configurar o modo SELinux
    - name: Set SELinux to enforcing mode
      ansible.posix.selinux: ## Módulo da coleção ansible.posix
        policy: targeted ## Usa a política SELinux 'targeted'
        state: "{{ selinux_state }}" ## Usa a variável que definimos
      when: selinux_state is defined ## Executa apenas se a variável existir

    ## Tarefa 2: Configurar portas SELinux
    - name: Configure SELinux ports for Apache
      community.general.seport: ## Módulo da coleção community.general
        ports: "{{ item.ports }}" ## Número da porta
        proto: "{{ item.proto }}" ## Protocolo (tcp)
        setype: "{{ item.setype }}" ## Tipo SELinux (http_port_t)
        state: "{{ item.state }}" ## present ou absent
      loop: "{{ selinux_ports }}" ## Percorre nossa lista de portas
      when: selinux_ports is defined ## Executa apenas se a variável existir

  roles: ## Roles a serem executadas
    - apache.developer_configs ## Nossa role personalizada (que acionará infra.apache)

Entendendo a ordem de execução:

1. pre_tasks: A configuração do SELinux é executada primeiro
2. roles: As dependências de roles são executadas (infra.apache), depois nossa role personalizada
3. handlers: Quaisquer handlers notificados são executados por último

Por que essa ordem é importante:

• O SELinux deve ser configurado antes que o Apache tente vincular-se a portas personalizadas
• O Apache deve ser instalado antes que possamos configurar virtual hosts
• Reinícios de serviço ocorrem após a conclusão de toda a configuração

Salve e saia.

Agora você está pronto para executar sua automação completa:

ansible-playbook web_dev_server.yml

O playbook será executado e você verá uma saída detalhada. Veja o que esperar (por exemplo):

PLAY [Configure Dev Web Server] *************************************************

TASK [Gathering Facts] **********************************************************
ok: [localhost]                     ## O Ansible coleta informações do sistema

TASK [Set SELinux to enforcing mode] *******************************************
changed: [localhost]                ## O modo SELinux foi alterado

TASK [Configure SELinux ports for Apache] **************************************
changed: [localhost] => (item={'ports': '9081', 'proto': 'tcp', 'setype': 'http_port_t', 'state': 'present'})
changed: [localhost] => (item={'ports': '9082', 'proto': 'tcp', 'setype': 'http_port_t', 'state': 'present'})

TASK [infra.apache : Ensure Apache is installed.] *******************************
changed: [localhost]                ## O pacote Apache foi instalado

TASK [apache.developer_configs : Create developer user accounts] ****************
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})

TASK [apache.developer_configs : Create developer web root directories] *********
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})

TASK [apache.developer_configs : Create a sample index.html for each developer] *
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})

TASK [apache.developer_configs : Deploy developer apache configs] ***************
changed: [localhost]                ## O arquivo de configuração foi criado

RUNNING HANDLER [apache.developer_configs : restart apache] *********************
changed: [localhost]                ## O Apache foi reiniciado

PLAY RECAP **********************************************************************
localhost                  : ok=17   changed=12   unreachable=0    failed=0    skipped=3    rescued=0    ignored=0

Você montou e executou com sucesso um playbook complexo que combina várias roles de diferentes fontes para criar um ambiente completo de desenvolvimento web!

Verificar a Configuração do SELinux e Apache no Servidor RHEL

Nesta etapa final, você verificará se sua automação Ansible configurou o sistema corretamente. É crucial confirmar se os serviços estão em execução como esperado e se as políticas de segurança (SELinux) foram aplicadas corretamente. Você usará ferramentas de linha de comando padrão do RHEL para inspecionar o estado do sistema.

Primeiro, certifique-se de estar no diretório principal do projeto.

cd ~/project

1. Verificar a Configuração do SELinux

Os módulos SELinux das coleções tiveram a tarefa de definir o modo SELinux para enforcing e permitir novas portas para o tipo http_port_t.

Verifique o status atual do SELinux usando o comando sestatus.

sestatus

A saída deve mostrar que o SELinux está habilitado e em modo enforcing.

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

Em seguida, use o comando semanage port para verificar se as portas 9081 e 9082 foram adicionadas ao contexto http_port_t. Você pode canalizar a saída para grep para encontrar as linhas relevantes.

sudo semanage port -l | grep http_port_t

Você deverá ver suas portas personalizadas listadas entre as portas HTTP padrão. A saída exata pode variar, mas incluirá as portas que você definiu.

http_port_t                    tcp      9082, 9081, 80, 81, 443, 488, 8008, 8009, 8443, 9000
pegasus_http_port_t            tcp      5988

Isso confirma que os módulos SELinux atualizaram com sucesso a política.

2. Verificar o Serviço e a Configuração do Apache

A role infra.apache instalou e iniciou o serviço httpd. Como o systemctl não está disponível neste ambiente de contêiner, você pode verificar o processo em execução usando ps.

ps aux | grep httpd

Você deverá ver vários processos httpd em execução, indicando que o serviço está ativo.

root        8851  0.2  0.4  25652 16228 ?        Ss   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8852  0.0  0.1  25308  6044 ?        S    09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8853  0.0  0.3 1443348 11364 ?       Sl   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8854  0.0  0.3 1443348 11480 ?       Sl   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8855  0.0  0.4 1574484 15848 ?       Sl   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
labex       9298  0.0  0.0   6408  2176 pts/3    S+   09:31   0:00 grep --color=auto httpd

3. Verificar a Acessibilidade do Conteúdo Web

Finalmente, o teste mais importante é ver se os sites dos desenvolvedores são acessíveis. Sua role apache.developer_configs configurou hosts virtuais nas portas 9081 e 9082. Use o comando curl para solicitar o conteúdo de cada endpoint.

Primeiro, teste o site para o usuário jdoe na porta 9081.

curl http://localhost:9081

A saída esperada é o conteúdo do arquivo index.html que você criou para este usuário.

Welcome to jdoe's dev space

Em seguida, teste o site para o usuário jdoe2 na porta 9082.

curl http://localhost:9082

Você deverá ver a mensagem de boas-vindas correspondente.

Welcome to jdoe2's dev space

Esses comandos curl bem-sucedidos confirmam que o Apache está configurado corretamente, os hosts virtuais estão funcionando e a política SELinux está permitindo o tráfego nas portas personalizadas.

Parabéns! Você construiu com sucesso um projeto completo de automação Ansible que combina uma role personalizada, uma role de um repositório Git e módulos SELinux de coleções do Ansible para configurar um servidor web de desenvolvimento seguro e multi-tenant.

Resumo

Neste laboratório, você aprenderá como automatizar a configuração de um servidor web RHEL aproveitando o poder e a estrutura de Roles e Coleções do Ansible. Você começará criando uma role personalizada do zero usando o comando ansible-galaxy init, que estabelece uma estrutura de diretórios padronizada para conteúdo de automação reutilizável. Esta etapa fundamental prepara o terreno para tarefas de automação mais complexas.

Com base na role personalizada, você integrará dependências externas, incluindo uma role de um repositório Git através de um arquivo requirements.yml e uma Role de Sistema RHEL oficial de uma Coleção Ansible. Finalmente, você montará esses diferentes tipos de roles — personalizadas, baseadas em Git e de sistema — em um único playbook, o executará para configurar o servidor e verificará as configurações resultantes do Apache e do SELinux para confirmar o sucesso da automação.