Serviços, firewall e validação externa | RHCE in Ansible: automação e operação

Três dimensões do serviço

Um serviço pode estar enabled e parado, ou started sem estar configurado para voltar no arranque. Uma unidade masked acrescenta outra restrição: não pode ser iniciada enquanto o bloqueio existir. Antes de remover esse bloqueio, confirma se foi uma medida operacional intencional. O exemplo usa state: started e enabled: true para um httpd de laboratório. Não força masked: false porque o desbloqueio não deve resultar de uma suposição escondida. Num handover, descreve estado atual, política de arranque e impedimentos encontrados.

Mudança de definição e mudança de processo

Se alterares um unit file, daemon_reload permite que systemd releia as definições. Não significa por si reiniciar o processo com novas opções. Distingue esse passo de reload da aplicação e de restart. Um state: restarted colocado numa tarefa normal vai interromper o serviço em cada execução; um handler apropriado limita a ação a alterações que a justificam. Mesmo com handler, define a janela e o critério funcional depois da ativação. O processo estar active não comprova que consegue consultar a base de dados ou concluir uma reconciliação.

Estado runtime e persistente do firewall

O exercício mantém firewalld ativo e adiciona http à zona public, tanto na configuração permanente como no estado imediato. A VM de laboratório deve ter a interface de teste associada a essa zona. Uma regra na zona errada não trata o tráfego observado. Uma alteração apenas permanente pode ainda não valer no runtime; uma alteração apenas imediata pode desaparecer depois de reload ou reinício. Não uses um reload global como resposta automática sem analisar alterações runtime de outras equipas. O módulo precisa ainda do binding Python de firewalld no interpretador realmente usado no nó.

Observar do lado do consumidor

Um pedido HTTP feito dentro do próprio servidor não percorre necessariamente o mesmo caminho que o cliente. Depois de confirmar listener, zona e regra, executa uma sonda a partir do segmento consumidor de laboratório. Especifica o status e o conteúdo esperados; a página de boas-vindas de um pacote não representa a aplicação pretendida. Se o serviço responde localmente mas o cliente falha, recolhe evidência por camada: endereço de escuta, rota, firewall do host, controlo externo e protocolo. Mantém a decisão de reabrir tráfego associada ao conjunto de critérios, não a uma única tarefa verde.

Executar e provar persistência

Usa apenas uma VM RHEL 10 descartável e uma interface de teste preparada. O exemplo instala httpd e abre HTTP nessa zona para estudo; não configura HTTPS nem uma aplicação bancária. Verifica sintaxe, executa, regista estado atual e permanente, repete e mede interrupções. Num reboot controlado, volta a confirmar serviço, regras e sonda externa. Nesta revisão só foram executadas verificações de sintaxe e resolução de módulos. A prática RHEL, a conectividade externa e a persistência continuam por demonstrar.

# Exercise for a disposable RHEL 10 VM with active firewalld public zone.
# It starts a packaged httpd service; it does not configure TLS or a banking app.
# Syntax checked only. A separate client probe and reboot test remain required.
- name: Maintain service and firewall state with separate acceptance criteria
  hosts: rhel_lab
  become: true
  gather_facts: true
  pre_tasks:
    - name: Require the intended lab
      ansible.builtin.assert:
        that:
          - lab_confirmed | default(false) | bool
          - ansible_distribution == 'RedHat'
          - ansible_distribution_major_version == '10'
          - ansible_service_mgr == 'systemd'
  tasks:
    - name: Install the lab web server and firewall Python binding
      ansible.builtin.package:
        name: [httpd, firewalld, python3-firewall]
        state: present
    - name: Keep firewall available now and after boot
      ansible.builtin.systemd_service:
        name: firewalld.service
        state: started
        enabled: true
    - name: Keep the packaged web service available now and after boot
      ansible.builtin.systemd_service:
        name: httpd.service
        state: started
        enabled: true
    - name: Configure both current and persistent lab-zone access
      ansible.posix.firewalld:
        zone: public
        service: http
        state: enabled
        permanent: true
        immediate: true
    - name: Record unit state without treating it as business acceptance
      ansible.builtin.command:
        argv: [systemctl, show, httpd.service, --property=ActiveState, --property=UnitFileState]
      register: unit_state
      changed_when: false
    - name: Show the observed unit fields
      ansible.builtin.debug:
        var: unit_state.stdout_lines

NA PRÁTICA

systemd mostra active e enabled; o cliente continua sem resposta porque a regra foi colocada noutra zona.

Armadilhas comuns

Enabled como running; daemon_reload como restart; regra permanente como runtime; sonda local como prova do caminho cliente.

Tópicos relacionados: LVM, filesystem e montagem persistente · SELinux: mapeamento e estado efetivo

Leva esta ideia contigo

Aceita estado atual, persistência e acesso pelo consumidor como critérios separados.

Criar conta

Referência: Systemd service module · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned