Automation Control Plane

The control plane for the Ansible Automation Platform is the automation controller. This platform is replacing Ansible Tower. However, throughout this post, we will refer to it as Ansible Tower when discussing the Ansible Tower use cases.

For a quick recap with Ansible Tower, we have several key components, such as a user interface (UI), role-based access control (RBAC), workflows, and continuous integration and continuous delivery (CI/CD) for supporting your team to scale with more efficiency and flexibility with automation throughout the enterprise.

Ansible Tower ( Ansible Automation Platform) helps formalize how automation is deployed, initiated, delegated, and audited, permitting enterprises to automate while reducing the risk of sprawl and variance. We can, for example, manage inventory, launch and schedule workflows, track changes, and incorporate them into reporting, all from a centralized user interface and RESTful API.

Ansible Red Hat: Ansible CLI

In more undersized team environments where everyone is well-versed in Ansible, maintaining control over automating the infrastructure and adhering to Ansible’s best practices in terms of using playbooks, meeting your security conditions, and delegating control is manageable. 

1. Challenge: Scaling

However, challenges emerge as teams start to scale and the use cases of automation become diverse; many organizations now have team-based usage needs that stretch well beyond Ansible’s command-line interface (CLI) with Ansible Core.

2. Challenge: Governance & Control

When automation is moved to a product and numerous teams use the CLI for automation, the problem is governance and control. For example, various users will write their Playbooks stored locally on their laptops. These Playbooks can be controlled, but the controlling factors may not be enforced.

3. Challenge: Extending Automation

Consequently, the potentially uncontrolled playbooks are configuring your organization’s entire infrastructure. So, we need to find a way to extend automation throughout the enterprise in a more controlled, secure, and scalable way. This can only be done with a platform approach to security, not CLI.

Red Hat Tower: Ansible Tower Use Cases

**Multi-machine & multi-vendor**

Nowadays, we are looking to expand automation to various Ansible Tower use cases, not just simple application deployments but even the ability to orchestrate multi-machine deployments with multi-vendor environments. The platform must support clustering and reach some far-edge use cases, such as edge networking.

**Automation Mesh**

There is a variety of Ansible Tower use cases that can be achieved with Automation mesh. Every product out there needs automation tied in—even the Cisco ACI. If you glance at the Cisco ACI programmable network, using Endpoint Groups (EPGs) is a significant benefit of the ACI network. However, you need something to configure the endpoints in the Endpoint Groups.  

**Enforcing Compliance and Standards**

You need to shift towards a platform such as Ansible Red Hat Tower with a central point for handling automation that allows you to enforce standards with your automation from the top organizational level to the exact CLI arguments that can be run and by whom.

Ansible Tower goes beyond running automated Playbooks; it helps you have better security, control, and visibility of your entire infrastructure. Ansible Tower can tie multiple processes and actions into a coherent workflow with a central control point. It has several Ansible Tower features that make scaling automation safe.

**Security use cases**

For security use cases, you can integrate Ansible Tower with an Enterprise security system. For control, we can have role-based access control on all of the Ansible Tower objects using Teams and Groups. You can integrate Tower with a central logging system, such as the ELK stack, for visibility. For metrics, Ansible Tower can be combined with Prometheus. Prometheus captures metrics from HTTP endpoints.

**Open networking**

Ansible Tower can also be integrated with various open networking use cases. Open networking describes a network that uses open standards and commodity hardware. Ansible Tower here can perform on multi-vendor networking equipment. 

The Big Question: Why Automate?

So, when beginning automation, you must first figure out why you should automate. So, the only thing that matters is how quickly you can deploy the application. To answer this, you must consider how quickly you can move from Dev, Test, and Production.

This is where the challenges are anchored, as we have different teams, such as network, load balancing, security, storage, and virtualization teams, to get involved. What can you do to make this more efficient?

**Integration Points**

We can test Ansible Tower against a staging environment before production deployment, all of which can be integrated into your CI/CD pipeline. This will help you better predict and manage your infrastructure.

When integrated with Jenkins, Ansible Tower uses cases to open possibilities. It is a powerful tool in a CI/CD process since it takes responsibility for environment provision and inventory management, leaving Jenkins with only one job: orchestrating the process.

**Multiple Inventories**

The Ansible architecture, of course, supports multiple inventories. Creating similar dev, test, and production inventories is not a problem if you want to create them. We make three inventories (‘dev,’ ‘test,’ and ‘prod’), each with identical sets of servers but with custom Ansible variables for their environment. This allows you to have a single Playbook with Ansible variables that separate the site-specific information to run against many inventories.

**What to automate?**

Every task that you can describe and explain can be automated. This generally starts with the device and service provisioning, such as ACL and Firewall rules. You can also carry out consistency checks, continuously running checks with automation against your environments. The Survey feature is an Ansible Tower feature used to run consistency checks. Here, you can have less experience running automatic checks that don’t need complete automation requirements. 

Ansible Tower Use Cases: Starting advice

Imagine that the developers of a Playbook are not the same people as the infrastructure owners. Who can run what Inventory becomes essential as we begin to scale out automation in the enterprise?  At a fundamental level, playbooks manage configurations and deployments to remote machines. In addition, they can sequence multi-tier rollouts involving rolling updates at a more advanced level and delegate actions to other hosts.

You can run continuous tests, which can be reported as an inconsistency when something goes wrong. This could be as simple as checking the VRRP neighbor and determining if you can see the neighbor. Or you could fit more detailed information, such as a stateful inspection firewall, and examine the contents to ensure your firewall works as expected. You can go further with routing adjustment and failure remediation, all with automation. It depends on how far you want to push the limitations of automation.  

Be Careful of Automating Mistakes

A) With automation, you can automate mistakes. A good starting point is to start with read-online, such as extracting configuration and checking specific parameters are there.

B) Then, you could move to devise provisioning and service provisionings such as VLAN segments, load balancing rules, and firewall changes.

C) Once you have mastered these operations, you could examine additional Ansible Tower use cases, such as traffic re-routing and advanced security use cases where Ansible Tower can assist in your threat-hunting effort.  

Ansible Tower Features

Highlighting an Organization’s objects

Sometimes, you have multiple independent groups of people that you need to manage autonomous machines. One central Ansible Tower feature to discuss is using the Organization’s objects. Hence, if you have two parts of an enterprise with entirely different requirements but still require Ansible Tower, they can share a single Red Hat Tower instance without overlapping configuration in the user interface by Organizations.

An Organization is a tenant with unique User accounts, Teams, Projects, Inventories, and Job Templates. It is like having a separate instance of Ansible Tower that allows you to segregate roles and responsibilities.

Red Hat Ansible: Role-based access control (RBAC)

An Organization is the highest level of role-based access control and is a collection of Teams, Projects, and Inventories. If you have a small deployment, you only need one Organization. However, larger deployments allow users and teams to be configured with access to specific sets of resources. Ansible Tower has a default Organization. Users exist at the Red Hat Tower level and can have roles in multiple Organizations.

When combined with the Ansible Tower features, such as role-based access control capabilities, Playbooks can be deployed at the push of a button but in a controlled and easily audited way. Role-based access control: You can set up teams and users in various roles. These can integrate with your existing LDAP or A.D. environment.

Restricting Playbooks

You can control who has access to what, when, and where, and explicitly restrict playbook access to authorized users. For example, we can have one team that can run playbooks in check mode, which is like a read-only mode, while other, more experienced users can have full administrative access with the ability to upgrade IOS versions to a fleet of routers. Developers log into Ansible Tower and, under RBAC, see only the job templates they have permission to access and deploy.

**Autonomy of an Automation Job**

In this next section, I will introduce the autonomy of an automation job in Red Hat Tower, giving you a good outline of the available Ansible Tower features. We have a new way to manage old Ansible objects and new Tower objects. You will notice that some of the objects used in Ansible Engine are the same, such as Playbooks and Inventory, and we have some new objects, such as Job Templates.

**Playbooks and Projects

We still maintain Playbooks containing your tasks. These Playbooks are stored in Projects. And this is synced to wherever you are starting your playbook. 

**Credential Management 

One significant benefit of using Ansible Tower is that it separates credentials from the Project. This allows you to have different Credentials for different Inventories. So, we can have one playbook targeting all hosts, run against different inventories with other credentials, and keep all your software release environments the same. This scenario is perfect for constancy in dev, test, staging, and production environments.

**Inventory

The final part is the Red Hat Ansible Inventory. You need to know how to connect with SSH or API; we can have many examples here. GitHub, Netbox, and ServiceNow. Even Though ServiceNow is an ITSM tool, it can be used as a CMDB database for inventory.

Automation Job:

All of these Ansible Tower features sync together to form what is known as an automation job. So when you look at Job templates and jobs, they always need to reference Projects, Inventory, and Credentials; otherwise, they can’t run. A basic four-stage process involves getting a playbook to run from Tower. The four stages are as follows:

1. Define a project.
2. Define an inventory.
3. Define credentials.
4. Define a template.

The first three stages can be performed in any order, but the template mentioned in the final stage pulls together the three previously created facets. Therefore, it must be specified last. 

Main Details on Ansible Tower Features

Projects allow you to define that area or space that allows all your resources and playbooks to exist. It is a location where our playbooks are stored. The defaults point to GitHub, but you can choose manual as the source control credential type, and then we would have our playbooks in the local directory.  This is different from the recommended approach for production as you don’t have any version control for projects stored locally on the Tower machines.

• Red Hat Ansible: Projects Management

Before creating Job Templates, Credentials, Inventories, and everything necessary to run a Playbook, Tower needs to know where to find all the files required for the automation job. This is where projects come into play, and we can execute a lot of governance in project management. 

• Source control and branching

First, playbooks are governed by Source Control Management (SCM). The Tower project components support the storage of playbooks in all major SCM systems, such as GitHub. 

• The Role of GitHub

Managing can be challenging even if only two people work on a Playbook. So, how do we follow changes across the enterprise? What if other people made a mistake? How do you roll back if they change the local machine’s text editor? So you can commit to pushing changes to GitHub and go back and forth to see who made what change. The advantages of adopting source control are:

1. Increased scalability and manageability
2. Audit trails of any modification
3. Better security  
4. The ability to perform distributed and automated testing 
5. Multiple life cycle environments for the Ansible code (i.e., dev, test, Q.A. & prod)
6. Consistency with CI/CD pipeline integration

Red Hat Ansible: Inventory

Basic Inventory

In its most basic form, an Inventory delivers host information to Ansible to trigger the tasks on the right managed assets. These may be containers, edge devices, or network nodes. In traditional and non-dynamic environments, the static inventory is adequate. However, as we develop our use of automation, we must transition to more effective methods of gathering ever-changing environment details. This is where dynamic inventory and smart inventories come into play.

Dynamic Inventory

When you have a dynamic inventory, such as one on AWS with an EC2 group, it populates several different variables directly from AWS. This allows you to keep current on any insurance you have launched on AWS. A prime example is using a dynamic Inventory Plugin to gather inventory information from a cloud provider or hypervisor. Ansible Red Hat has built-in dynamic Inventory support, so you don’t need to edit configuration files or install additional Python modules.

Smart Inventory

Ansible and Ansible Tower have long been able to pull inventory from several sources, such as a local CMDB, private cloud, or public cloud. However, could you tell me what you need to do to automate your inventory? For example, let’s say you want to create an inventory across all machines tagged “dev” or all machines running a potentially vulnerable piece of software.

This is where you can use Smart Inventories. Smart inventory allows you to create inventories off Ansible Tower fact caching support. So, could you please create new inventories that include all hosts that match specific criteria? This can be based on host attributes such as groups or gathering facts. Gathering facts could be anything, such as the manufacturer or installed software service.

This can be particularly helpful for dynamically creating inventories with a specific type of host based on a filter. It saves the need for manually creating many different groups—or worse, adding the same host multiple times.

Red Hat Ansible: Machine Credentials 

When running a job template against one or more remote hosts or nodes, you must create a credential and associate it with your job template. The default is the machine credential, but we have many different credential types. A machine credential is, for example, an SSH username and password or an SSH username and a private key—these are stored securely in Tower’s backend database. 

Credential via Hashicorp Vault

Ansible Credential Plugin integration via Hashicorp Vault is an API-addressable secrets engine that will make life easier for anyone wishing to improve secrets management and automation. Modern systems require multiple secrets to automate effectively: certificates, database credentials, keys for external services, operating systems, and networking. 

Understanding who is accessing secret credentials and when is complex and often platform-specific. Managing key rotation, secure storage, and detailed audit logging across a heterogeneous toolset is almost impossible. Red Hat Tower solves numerous issues, but its integration with enterprise secret management solutions can utilize secrets on demand without human interaction.

Ansible Vault

Then we have Ansible Vault. Ansible Vault is a feature that keeps sensitive data in encrypted form, for example, passwords or keys, instead of saving them as plain text in roles or playbooks.  An Ansible vault is a standard file on your disk that you can edit using your favorite text editor, with one key difference. When you hit save, the file is locked inside strong AES-256 Encryption. What I like about this is that these vault files can be securely placed in source control or distributed to multiple locations.

Red Hat Ansible: Ansible Templates

With Ansible Tower, a Playbook is run from a Job Template. Within the job templates, we can specify the number of parameters and environment details for running the playbook. The template is a job definition with all of its parameters. In addition, the Job Template can be launched or scheduled. Scheduling is suitable for running playbooks at regular intervals, such as a nightly backup of configurations of all network devices.

Two Options: Job or Workflow Template

So we have two options: add a standard Template or a Workflow Template. A job template runs a single playbook with one set of settings. On the other hand, we have a workflow template that says I want to run this job with this playbook, and then if that passes or fails, we are, for example, a continuous workflow of multiple templates. 

1.Workflow Template

The real value here is that you can have one team of users; let’s say the Linux team creates a template. This template will reference its inventory and playbooks and has its permission structure with role-based access control. Then, we can have a Network team that has developed its Playbooks and grouped them into a template with its Inventory, Credentials, and permission structure.

**Different teams, playbooks, and credentials**

A job template allows you to connect all of this. This is done with a Job Workflow template visualizer, enabling you to connect numerous playbooks, updates, and workflows, even if different users run them, use other inventories, or have other credentials. The vital point is that the various teams use different Playbooks, Credentials, and Inventories, yet everything is easily linked in one automation unit. Therefore, complex dependencies between the templates can be broken down into steps.

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. Or if you want someone to double-check that there is enough capacity on the target hosts.

Ansible Red Hat: Automation Requirements

• Requirement: Low barrier of entry

With push-button deployment access, non-privileged users can safely deploy entire applications without any previous Ansible knowledge or risk of causing damage. 

• Requirement: Better control and manageability

Ansible Tower is a welcomed addition to the power of the original Red Hat Ansible CLI version. It ensures that you can operate your infrastructure with automation and gain all the benefits of automation in a well-managed, secure, and auditable manner. Now, we need the ability to delegate authority to different users or teams and lock down access to particular projects or resources.

• Requirement: The ability to schedule

Manual and ad hoc practices, even with the role of automation, can be inconsistent. Ansible Tower offers a more uniform and reliable way to manage your environment with Job Scheduling. One of Tower’s primary features is the ability to schedule jobs. Scheduling can enable periodic remediation, continuous deployment, or even scheduled nightly backups.

• Requirement: Better visibility and real-time updates

Administrators want a real-time view of what Ansible is up to at any time, such as job status updates and playbook runs, as well as what’s working in their Ansible environment. All Ansible automation is centrally logged, ensuring audibility and compliance. With Ansible Tower, we have real-time analyses. It provides a real-time update about the completion of Ansible plays and tasks and each host’s success and failure. In addition, we can see our automation’s status and which will run next.

• Requirements: Centralized logging and metrics

The Ansible Tower dashboard could better view our inventory, hosts, scheduled tasks, and manual job runs. However, we can incorporate Ansible Tower with the ELK stacks for additional information to better understand and predict future trends.

• Requirement: Inventory management

Ansible Tower supports multiple Inventories, making creating dev, test, and similar production inventories easy. This will help you have better consistency throughout. Additionally, this provides a better way to manage and track their inventory across complex, hybrid virtualized, and cloud environments.

• Requirement: System tracking and audit trail

System tracking. Verifies that machines are in compliance and configured as they should be. 

• Requirement: Enterprise integration

For additional Ansible Tower use cases, several authentication methods make it easy to embed into existing tools and processes to help ensure the right people can access Ansible Tower resources. For example, Ansible Tower can link to central directories, such as Lightweight Directory Access Protocol (LDAP) and Azure Active Directory, to assist with authentication with the ability to create user accounts locally on the server itself.

Enterprise integration integrates Ansible into an existing environment and enterprise toolset. Self-service I.T. Provides the flexibility to free up time and delegate automation jobs to others.

• Requirement: RESTful API

This allows Red Hat Tower to interact with other I.T. gear—enabling you to integrate Ansible Tower into existing areas of your infrastructure or your pipeline. For example, we can integrate Ansible Tower with ServiceNow and Inflowblox.  Every component and function of Ansible Tower can be API-driven. So it depends on your organization and how they operationalize their automation via the API or U.I.

Ansible Tower is a game-changer when it comes to streamlining IT operations. Its powerful features, centralized management, and extensive integrations make it a valuable tool for organizations of all sizes. By leveraging Ansible Tower, businesses can achieve greater efficiency, reduce human error, and drive innovation. Embrace the power of automation with Ansible Tower and embark on a journey towards a more agile and productive IT infrastructure.