DevOps strives to improve service delivery by bringing teams together, streamlining processes, automating tasks and making these available in a self-service manner.

Many organisations don’t realise the full benefits of DevOps for multiple reasons, including unintegrated tools, manual handovers, and lack of a unified automation solution, leading to islands of automation.

Red Hat Ansible Automation Platform offers an easy-to-understand automation language, a vast array of IT ecosystem integrations, and enterprise features, such as an API and Role-Based Access Control (RBAC). This blog demonstrates how these capabilities can help accelerate your DevOps practices using simple, practical examples. 

This blog covers:

• Using Ansible Automation Platform to automate DevOps tooling configurations.
• Integration of Ansible Automation Platform into existing DevOps environments.
• Orchestrating DevOps workflows using automation controller.
• Use controller approvals to allow for final sign-off of services before production deployment.

Note

The examples shared in this blog are based on the “DevOps and CI/CD with automation controller” self-paced lab. Feel free to get hands-on and try it out!

Environment overview

Let’s explore the tools and configurations used in this blog.

ACME Corp illustrative tooling diagram.

• Gitea - This example uses Gitea for source control management and hosts the acme_corp repository. The acme_corp repository contains the “Let’s Quiz!” application code and a webhook to trigger a Jenkins build.
• Jenkins - Jenkins is the build tool used in this example. The “ACMECorp” Jenkins job performs several development tasks and uses the automation controller API to initiate the “DevOps Workflow” controller workflow.
• Automation controller - Multiple development and operational tasks are orchestrated using the “DevOps workflow”.
• Web server - A Red Hat Enterprise Linux (RHEL) server hosts the “Let’s Quiz!” application. The web server belongs to the [webservers] Ansible inventory group.

Automated operations with Ansible

Ansible Automation Platform enables teams to define and standardise configurations across the IT ecosystem using an easy-to-understand, pervasive language. This capability reduces the operational overhead associated with managing multiple tools, commonly experienced when implementing a DevOps strategy.

Below are examples of how I used Ansible Automation Platform to configure the self-paced lab environment.

Jenkins automated configuration with Ansible

Jenkins provides a base container image that I customised and configured using the following:

• Jenkins Configuration as Code plugin and configuration file.
• Custom Dockerfile.
• The configure_jenkins.yml playbook.

---
- name: Configure ACMECorp Jenkins job
  hosts: controller.acme.example.com
  gather_facts: false
  tasks:
    - name: Create a Jenkins job using basic authentication
      community.general.jenkins_job:
        config: "{{ lookup('file', 'acme.xml') }}"
        name: ACMECorp
        user: admin
        password: password
        url: "http://jenkins:8080"
        validate_certs: false

configure_jenkins.yml. You can find the full playbook example here.

The configure_jenkins.yml playbook uses the community.general.jenkins_job module and applies the acme.xml configuration file to create a new job called “ACMECorp”. We’ll explore the Jenkins pipeline job steps in later sections.

Gitea automated configuration with Ansible

I used the standard Gitea container image and configured it using the following:

• Gitea configuration environment variables.
• The configure_gitea.yml playbook.

…output omitted..
    - name: Create repo
      ansible.builtin.uri:
        url: http://gitea:3000/api/v1/user/repos
        method: POST
        body_format: json
        body:
          name: acme_corp
          auto_init: false
          private: false
        force_basic_auth: true
        url_password: "{{ student_password }}"
        url_username: "{{ student_user }}"
        status_code: [201, 409]
…output omitted..

configure_gitea.yml playbook snippet. You can find the full playbook example here.

The configure_gitea.yml creates Gitea users, the acme_corp repository, and a webhook we’ll use later to call the “ACMECorp” Jenkins pipeline.

Automation controller configuration as code

The ansible.controller Red Hat Ansible Certified Content Collection makes it easy to describe your automation controller configuration as code. I used the collection to configure multiple resources, including the “DevOps Workflow” controller workflow job template.

The configure_workflow.yml playbook below contains a code snippet used to configure the “DevOps Workflow”.

   …output omitted..
    - name: Create DevOps Workflow
      ansible.controller.tower_workflow_job_template:
        name: "DevOps Workflow"
        inventory: "ACME Corp inventory"
        extra_vars: "{{ workflow_vars }}"
        ask_variables_on_launch: true
        organization: "ACME Corp"
        schema: "{{ workflow_schema }}"
        controller_oauthtoken: "{{ auth_token }}"
        controller_host: "controller.acme.example.com"
        validate_certs: false
    - name: Add nodes to DevOps workflow
      ansible.controller.workflow_job_template_node:
        state: present
        identifier: "{{ item.workflow_node_id }}"
        workflow_job_template: "DevOps Workflow"
        organization: "ACME Corp"
        approval_node: "{{ item.workflow_node_approval }}"
        unified_job_template: "{{ item.workflow_node_unified_jt }}"
        success_nodes: "{{ item.workflow_node_success_nodes}}"
        controller_oauthtoken: "{{ auth_token }}"
        controller_host: "controller.acme.example.com"
        validate_certs: false
      loop: "{{ lab_devops_worklow_nodes }}"
    …output omitted..

configure_workflow.yml playbook snippet. You can find the full playbook example here.

Next, we’ll look at the CI/CD pipeline steps and how automation controller orchestrates multiple tasks using a workflow job template.

The ACMECorp pipeline

ACMECorp Jenkins Job

Once the updated code is committed and pushed to the acme_corp repo, the webhook initiates the “ACMECorp” Jenkins job, which performs the following tasks:

1. SCM Get Code - Pulls the latest “Let’s Quiz!” application code from the acme_corp repository.
2. Installing packages - Installs the packages needed to test the application.
3. Static Code Checking - Runs static code analysis.
4. Build and Tag - Increments the ”Let’s Quiz!” application version, creates a git tag, and saves it as the $newPkgVersion variable.

• Controller - DevOps - Calls the automation controller API using the Ansible Tower Jenkins plugin.

Note

The Ansible Tower Jenkins plugin is community-driven and used for demonstration purposes only. Multiple methods, such as the curl or awx commands, and job template webhooks, can be used to call the automation controller API.

Let’s look closer at the final Controller - DevOps pipeline step.

 stage('Controller - DevOps') {
            steps {
                ansibleTower(
                    towerServer: 'ACME Corp controller',
                    templateType: 'workflow',
                    jobTemplate: 'DevOps Workflow',
                    importTowerLogs: true,
                    removeColor: false,
                    verbose: true,
                        extraVars: '''---
                        pkg_version: $pkgVersion
                        tag_name: $newPkgVersion
                        '''
                )
            }
        }

Controller - DevOps pipeline step

The Controller - DevOps step in the “ACMECorp” pipeline calls the automation controller API to initiate the “DevOps Workflow”.

The controller API accepts multiple parameters, including passing extra variables to the workflow. In our example, the $newPkgVersion variable, which contains the Git tag version created in the previous Build and Tag step, is passed to the controller API using the tag_name variable.

DevOps Workflow extra variables.

Next, we’ll explore how automation controller orchestrates multiple automation tasks in the “DevOps Workflow” job template.

Orchestration using automation controller

DevOps Workflow job template

The first step in the “DevOps Workflow” is an approval node called “Deploy to Prod?”.

Workflow approval nodes

Workflow approval nodes require human interaction to advance the workflow. This interaction lets decision makers approve the automation before it’s applied in the environment. A simple example of where this could be useful is the finance team checking if funds are available before deploying new services to the public cloud.

Workflow Approvals are managed in automation controller, as illustrated below.

Controller Workflow Approvals interface.

Once the user with the appropriate permissions approves the “Deploy to Prod?” step, the “DevOps Workflow” runs the following job templates.

Workflow job templates

“Create App Release” node

The “Create App Release” node generates a new “Let’s Quiz!” application release in the acme_corp repo using the app_release.yml playbook. The playbook uses the ansible.builtin.uri module to POST to the Gitea API.

  …output omitted..
    # The tag_name variable is populated from the Jenkins pipeline
    - name: Create new ACME release
      ansible.builtin.uri:
        url: "http://gitea:3000/api/v1/repos/{{ student_user }}/acme_corp/releases"
        method: POST
        user: "{{ student_user }}"
        password: "{{ student_password }}"
        body_format: json
        force_basic_auth: true
        body:
          '{"target_commitish": "main",
          "name": "ACME Corp Patch Release {{ tag_name }}",
          "draft": false,
          "prerelease": false,
          "tag_name": "{{ tag_name }}"}'
    …output omitted..

app_release.yml playbook snippet. You can find the full playbook example here.

Config Webservers node

The “Config Webservers” node installs the required web server dependencies to host the “Let’s Quiz!” application using the configure_webservers.yml playbook. The playbook calls the ansible.builtin.package and ansible.builtin.pip modules to install operating system and Python dependencies.

---
- name: Install packages on webservers
  hosts: webservers
  gather_facts: false
  tasks:
    - name: Install base packages
      ansible.builtin.package:
        name:
          - python3-setuptools
          - virtualenv
        state: present
      become: true
    - name: Install Python packages
      ansible.builtin.pip:
        requirements: "/home/rhel/acme_corp/playbooks/files/requirements_prod.txt"
        virtualenv: /home/rhel/.virtualenvs/acme_corp

configure_webservers.yml playbook. You can find the full playbook example here.

Deploy ACME App node

Once the “Config Webservers” and “Create App Release” nodes execute successfully, the “Deploy ACME App” node runs the deploy_acme_app.yml playbook. The playbook downloads and extracts the latest “Let’s Quiz!” release from the acme_corp repo, configures the application, and finally runs it.

 …output omitted..  
    # The tag_name variable is populated from the Jenkins pipeline
    - name: Extract download
      ansible.builtin.unarchive:
        src: "http://gitea:3000/{{ student_user }}/acme_corp/archive/{{ tag_name }}.tar.gz"
        remote_src: true
        owner: rhel
        group: rhel
        dest: /usr/local/
    
    - name: Create database migrations
      community.general.django_manage:
        command: migrate
        project_path: /usr/local/acme_corp/app/lets_quiz
        virtualenv: /home/rhel/.virtualenvs/acme_corp
    …output omitted..

deploy_acme_app.yml playbook snippet. You can find the full playbook example here.

Once the “DevOps Workflow” is complete, the “Let’s Quiz!” application is ready to use!

“Let’s Quiz!” application.

Let’s recap

This blog demonstrated how Ansible Automation Platform orchestrates tasks across multiple IT domains, augments existing workflows, and automates system configurations to get the most out of your DevOps journey. However, the platform offers so much more. 

Why Ansible Automation Platform for CI/CD and DevOps?

Ansible, the pervasive automation language

Ansible is widely used across the IT ecosystem and provides the opportunity to leverage the automation already created in your organisation.

Do more with your automation

Ansible Automation Platform offers a wide variety of Red Hat Ansible Certified Content Collections, co-developed with our partners, that let you extend your automated processes to more areas of your IT environment. 

Automation controller enables you to solve complex use cases by logically chaining your automation tasks together and offers native integrations to external enterprise systems.

Accelerate your DevOps journey

Ansible Automation Platform 2 provides a distributed, scalable platform that grows as you mature in your DevOps journey. Automation mesh enables you to localise automation execution closer to the endpoints that need it, with improved resilience to connection disruptions and latency.

Security and compliance

Ansible Automation Platform offers RBAC and native integration into enterprise Identity Access Management systems, such as Active Directory and Privilege Access Management solutions, to centralise credential management.

Ansible Automation Platform records all automation actions and provides native integration to enterprise logging systems for auditing and compliance monitoring.

Where to go next

• Self-paced labs - Specifically, check out the  DevOps and CI/CD with automation controller lab that will get you hands-on time with everything discussed in this blog.
• Subscribe to the Red Hat Ansible Automation Platform YouTube channel. Be sure to check out our web series, Automated Live, hosted by Colin McNaughton.
• Follow Red Hat Ansible Automation Platform on Twitter. Do you have questions or an automation project you want to show off? Tweet at us!