Bookmark this page

Guided Exercise: Configuring Event-Driven Ansible Controller to Run Ansible Rulebooks

Integrate Event-Driven Ansible controller with automation controller, import a project containing an Ansible Rulebook, activate a rulebook, and test it by sending some events.

Outcomes

  • Create a user token in the automation controller web UI.

  • Create a controller token, a project, and a ruleset activation in the Event-Driven Ansible controller web UI.

  • Inspect rule audits in the Event-Driven Ansible controller web UI.

As the student user on the workstation machine, use the lab command to prepare your environment for this exercise, and to ensure that all required resources are available.

[student@workstation ~]$ lab start controller-configure

Instructions

  1. Create a user token in the automation controller web UI at https://controller.lab.example.com. An application that uses this token can launch job templates and workflow job templates.

    1. Navigate to https://controller.lab.example.com and log in as admin using redhat as the password.

    2. Click admin in the upper right and then click User Details.

    3. Click the Tokens tab and then click Add. Create the user token with the following settings and then click Save.

      FieldValue
      Description Event-Driven Ansible controller
      Scope Write

      Note

      The Application field is not required. If you leave the field blank, then the user token becomes a personal access token.

    4. Click the Copy to clipboard icon to copy the displayed token and then close the Token information window.

  2. Create a controller token in the Event-Driven Ansible controller web UI at https://eda-controller.lab.example.com. This controller token enables rules to launch automation controller jobs by using the run_job_template and run_workflow_template actions.

    1. In a new browser tab, navigate to https://eda-controller.lab.example.com and log in as admin using redhat as the password.

    2. Click admin in the upper right and then click User details.

    3. Click the Controller Tokens tab and then click Create controller token. Create the controller token with the following settings and then click Create controller token.

      FieldValue
      Name controller.lab.example.com
      Description Token for admin user
      Token (paste the previously copied token)
  3. Create a new project. The project points to an existing Git repository that already contains Ansible Rulebooks in the top-level /rulebooks directory.

    1. If necessary, click the main menu icon at the upper left of the page to display the main menu.

    2. Navigate to Projects and then click Create project. Create the project with the following settings and then click Create project.

      FieldValue
      Name Baseline
      SCM type Git
      SCM URL https://git.lab.example.com/student/baseline
      Options Verify SSL (selected)

      Note

      Because this is a public Git repository in the classroom environment, the project does not require a credential.

    3. After you click Create project, Event-Driven Ansible controller immediately attempts to synchronize the project. Wait until the Status field displays the Completed status.

  4. Create a rulebook activation that uses an Ansible Rulebook in the Baseline project. Event-Driven Ansible controller automatically runs any enabled rulebook activation.

    1. If necessary, click the main menu icon at the upper left of the page to display the main menu.

    2. Navigate to Rulebook Activations and then click Create rulebook activation. Create the rulebook activation with the following settings and then click Create rulebook activation.

      FieldValue
      Name Conform to baseline
      Project Baseline
      Rulebook alertmanager.yml
      Decision environment Automation Hub Default Decision Environment
      Restart policy Always
      Rulebook activation enabled? Enabled (selected)
    3. After you click Create rulebook activation, Event-Driven Ansible controller immediately attempts to run the rulebook activation. Wait until the Activation status field transitions from the Starting to Running status.

  5. (Optional) Examine components of the exercise configuration. Although this step is not required, you might complete this step to see how the different exercise components work with each other.

    1. From a terminal window, change to the /home/student/git-repos directory and then clone the git@git.lab.example.com:student/baseline Git repository. After cloning the repository, change to the baseline directory.

      [student@workstation ~]$ cd ~/git-repos
      [student@workstation git-repos]$ git clone \
      git@git.lab.example.com:student/baseline
      Cloning into 'baseline'...
      ...output omitted...
      [student@workstation git-repos]$ cd baseline
      [student@workstation baseline]$

      Note

      The student user uses the ~/.ssh/gitlab_rsa SSH key to connect to the Git repository.

    2. Run the tree command to display the contents of the repository.

      [student@workstation baseline]$ tree
      .
      ├── playbooks
      │   └── alertmanager-baseline-config.yml
      └── rulebooks
          └── alertmanager.yml
      
      2 directories, 2 files
    3. Display the contents of the alertmanager.yml rulebook. This file is the rulebook used by the Conform to baseline rulebook activation.

      ---
      - name: Capture alertmanager alerts
        hosts: localhost
        sources:
          - ansible.eda.alertmanager:
              host: 0.0.0.0
              port: 5050 1
              data_alerts_path: alerts
              data_host_path: labels.instance
              data_path_separator: .
              skip_original_data: true
      
        rules:
          - name: SELinux was disabled
            condition: event.alert.labels.alertname == "selinux disabled" and event.alert.status == "firing"
            action:
              run_job_template:
                name: Apply baseline 2
                organization: Default
                job_args:
                  limit: "{{ event.meta.hosts }}" 3
      ...output omitted...

      1

      The event source plug-in listens for events sent to port 5050. The ~/git-repos/eda-alertmanager/prometheus/alertmanager.yml file is used by the Alertmanager pod running on the workstation machine. That file is configured to send alerts to port 5050 on the Event-Driven Ansible controller. A firewall rule on the Event-Driven Ansible controller enables access to this port.

      2

      This rule applies the run_job_template action when the rule receives an event that indicates that SELinux has been disabled. The name specified by the action must match an automation controller job template name. If you view the Apply baseline job template in the automation controller web UI, then you see that the job template runs the alertmanager-baseline-config.yml playbook.

      3

      By passing the limit argument to the job template, you can restrict the hosts targeted by the associated job. This option works with the Prompt on launch option for the Limit field in a job template in automation controller.

    4. Display the contents of the alertmanager-baseline-config.yml playbook. Although this playbook only contains one task, you might add tasks that apply a baseline configuration to your servers.

      ---
      - name: Baseline config for all servers
        hosts: all
        tasks:
      
        - name: Enable SELinux
          ansible.posix.selinux:
            policy: targeted
            state: enforcing
          become: true
    5. In a new browser tab, navigate to http://servera.lab.example.com:9090/alerts to display the Prometheus web UI. A firing alert sends a notification to the Alertmanager pod running on the servera machine. The selinux disabled alert is currently green, which means that the alert is not in a pending or a firing state.

      Figure 2.13: Prometheus alerts
    6. Return to the /home/student directory.

      [student@workstation baseline]$ cd
      [student@workstation ~]$
  6. Generate a problem that Event-Driven Ansible responds to, and then verify that the action resolves the problem.

    1. Connect to servera as the student user.

      [student@workstation ~]$ ssh servera
      ...output omitted...
      [student@servera ~]$
    2. Use the sestatus command to display the current and persistent SELinux modes. Both modes indicate that SELinux is running in enforcing mode.

      [student@servera ~]$ sestatus
      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
      ...output omitted...
    3. Use the setenforce command to change the current SELinux mode to permissive mode. This change should ultimately trigger an alert.

      [student@servera ~]$ sudo setenforce 0
      [sudo] password for student: student
    4. Use the sestatus command to display the current and persistent SELinux modes. The setenforce command updated the current mode, but the command did not update the persistent mode.

      [student@servera ~]$ sestatus
      SELinux status:                 enabled
      SELinuxfs mount:                /sys/fs/selinux
      SELinux root directory:         /etc/selinux
      Loaded policy name:             targeted
      Current mode:                   permissive
      Mode from config file:          enforcing
      ...output omitted...
    5. Return to the browser tab that contains the Event-Driven Ansible web UI. If necessary, click the main menu icon at the upper left of the page to display the main menu.

    6. Navigate to Rule Audit. It might take a few minutes, but you should eventually see two entries in the rule audit list. The first entry (SELinux was disabled) appears when Event-Driven Ansible controller identifies a problem. The second entry (SELinux was enabled) appears when Event-Driven Ansible controller recognizes that the problem has been resolved.

      You can proceed with the exercise after you see the SELinux was disabled entry.

      Figure 2.14: List of rule audits
    7. Click the SELinux was disabled entry and then click the Actions tab. You can see that the run_job_template action displays the Successful status.

      Figure 2.15: List of actions for the selected rule
    8. (Optional) Right-click the run_job_template link and select Open Link in New Tab. This link opens the automation controller web UI and displays details about the successful job. If necessary, log in as admin using redhat as the password. You might examine the job information displayed on the Details and Output tabs.

    9. Use the sestatus command to verify that the current SELinux mode has been restored to use enforcing mode.

      [student@servera ~]$ sestatus
      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
      ...output omitted...
    10. Log out of the servera machine.

      [student@servera ~]$ logout
      Connection to servera closed.
      [student@workstation ~]$

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish controller-configure

Revision: do274-2.4-65daa25