To operationalize your environment and drive automation to production, you need to have everything centrally managed and better role-based access. So you understand who is automating and what they are doing, along with a good audit trail. This is where Red Hat Ansible and Ansible Tower can assist with several Ansible Tower features and Ansible Tower use cases. Red Hat Tower, also known as the Ansible Automation Platform, are a web-based U.I. and RESTful API for Ansible that allows users to manage the Ansible network in an easy and scalable way.
Ansible Tower is a big setup from using just the CLI for automation. Tower’s main purpose is to make automation easier and safer with scale to do in the enterprise. And it does this by presenting several Ansible Tower features from a web-based U.I.
All the Ansible Tower features, such as Projects, Credentials, and Inventory, are isolated objects with different settings. However, once these components are combined or linked, they form an automation job within a Job Template. Consider the Job template to be the Tower object that glues all of the other components together to form an automation journey.
Ansible Tower Use Cases
A key point: Video on Ansible Tower
In this product demonstration, we will go through the key components of Ansible Tower along wth the Ansible Tower use cases, and its functionality which is a considerable step up from the Ansible CLI you may have used with Ansible Core. In addition, we will discuss the autonomy of an automaton job with Red Hat Tower that shares similar objects when using the CLI but has considerable differences, such as the use of Job Templates, better Credentials management, and Inventory that you may have come across with Ansible CLI, and Ansible Tower Projects.
Ansible Tower for beginnersIn this product demonstration, we will go through the key components of Ansible Tower and its functionality which is a considerable step up from the Ansible CLI that you may have used with Ansible Core.
We will discuss the autonomy of an automaton job that shares similar objects when using the CLI but has considerable differences such as The use of Job Templates, better Credentials management, and inventory that you may have come across with Ansible CLI, and Ansible Tower Projects.
Start a free trial for all my Elearning courses at Pluralsight with the following link:
Visit my website for additional technical content:
Contact me directly at firstname.lastname@example.org
A key point: 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.
But challenges emerge as teams start to scale and the use case of automation becomes diverse; many organizations now have team-based usage needs that stretch well beyond Ansible’s command line interface (CLI) with Ansible Core. The problem you have when moving automation to a product and numerous teams using the CLI for automation is governance and control. A variety of users will write their Playbooks that are stored locally on their laptops.
These Playbooks can be controlled, but the controlling factors may not be enforced. 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
Nowadays, we are looking to expand automation to a variety of Ansible Tower use cases and not just to simple application deployments but even the ability to orchestrate multi-machine deployment with multi-vendor environments. The platform must support clustering and reach some far-edge use cases, such as edge networking. There is a variety of Ansible Tower use cases that can be achieved with Automation mesh. Every product out there needs to have automation tied in. Even the Cisco ACI. If you glance at the Cisco ACI programmable network, the use of Endpoint Groups (EPGs) is a big benefit of the ACI network. However, you need something to configure the endpoints in the Endpoint Groups.
Ansible Tower: Ansible Tower use cases
You need to shift more 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 who.
Ansible Tower goes above just 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. And it has several Ansible Tower features that make rolling out automation at scale safe.
For Ansible Tower use cases related to security, 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. And for visibility, you can integrate Tower with a central logging system such as the ELK stack. And for metrics, Ansible Tower can be integrated with Prometheus. Prometheus scaps metrics from HTTP endpoints.
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.
Ansible Tower features
Ansible Tower Features
The Big Question: Why Automate?
So when you are beginning automation, you first need to figure out why you should automate. So, the only thing that matters is how quickly you can deploy the application. So to answer this, you need to consider how quickly you can move from Dev, Test and Production.
This is where the challenges anchor, as we have different teams, such as network, load balancing, security, storage and virtualization teams, to get involved. So what can you do to make this more efficient? 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 predicate and manage your infrastructure.
Ansible tower uses cases to open a world of possibilities when integrated with Jenkins. Ansible Tower is a powerful tool in a CI/CD process since it takes responsibility for the environment provision and inventory management, leaving Jenkins with only one job: orchestrating the process.
The Ansible architecture, of course, supports multiple inventories. So if you want to create similar dev, test, and production inventories, creating them is not a problem. We create 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 separates the site-specific information to run against many inventories.
What to automate
Every task that you can describe and explain can be automated. So 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 experienced running automatic checks that don’t need full automation requirements.
A key point: 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. 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, and the moment something goes wrong, it can be reported as an inconsistency. This could be as simple as checking the VRRP neighbour and determining if you can see the neighbour. Or you could check more detailed information, such as a stateful inspection firewall and examine the contents to ensure your firewall is working 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.
A key point: Ansible Tower use cases: Be careful of automating mistakes
With automation, you can automate mistakes. A good starting point is to start with read-online, such as extracting configuration and checking certain parameters are there. Then you could move to devise provisioning, along with service provisionings such as VLAN segments, load balancing rules and firewall changes. 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 independent machines. One of the main Ansible Tower features 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.
A key point: 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.
Role-based access control
When combined with the Ansible Tower features, such as role-based access control capabilities of Ansible Tower, 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.
So you can control who has access to what, when, and where. So you can 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 Ansible Tower features available to you. 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. And these Playbooks are stored in Projects. And this is synced to wherever you are starting your playbook.
- Credential Management
One big 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 different credentials, keeping all of your software release environments the same. This is a perfect scenario for constancy in your dev, test, staging and production environments.
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:
- Define a project.
- Define an inventory.
- Define credentials.
- 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 that are stored locally on the Tower machines.
Red Hat Ansible: Highlighting 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 needed for the automation job. This is where projects come to play, and we can execute a lot of governance in project management.
Source control and branching
First, governance of playbooks with Source Control Management (SCM). The Tower project components support the storage of playbooks in all major SCM systems, such as GitHub.
It can be challenging to manage even if you have only two people working on a Playbook. So how to 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 and push changes to GitHub and go back and forth to see who made what change. The advantages of adopting source control are:
- Increased scalability and manageability
- Audit trails of any modification
- Better security
- The ability to perform distributed and automated testing
- Multiple life cycle environments for the Ansible code (i.e., dev, test, Q.A. & prod)
- Consistency with CI/CD pipeline integration
Red Hat Ansible: 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. As we develop our use of automation, we need to transition to more effective methods of gathering ever-changing environment details. This is where dynamic inventory and smart inventories come to play.
When you have a dynamic Inventory, such as on AWS with an EC2 group, this will pe-populate several different variables directly from AWS. This allows you to keep up to date on any insurances 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.
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, what are you need to automate across your entire Inventory? 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. Therefore, allow you to create new inventories that contain all hosts that match certain 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.
Benefits of Smart Inventories
This can be particularly helpful for dynamically creating inventories with a specific type of host based on a filter and saves the need for manually creating lots of different groups—or worse, having to add 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 lots of 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 the backend database of Tower.
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 handle secrets management and automation better. To automate effectively, modern systems require multiple secrets: certificates, database credentials, keys for external services, operating systems, and networking.
Understanding who is accessing secret credentials and when is difficult and often platform-specific, and 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.
Then we have Ansible Vault. Ansible Vault is a feature to keep 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 normal file on your disk that you can edit using your favourite 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. The Job Template can be launched or scheduled. Scheduling is good 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 normal Template or a Workflow Template. So a job template is used to run 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.
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 that allows you to connect numerous playbooks, updates, and workflows, even if different users run them, use different inventories, or have different credentials. The vital point is that the different teams use different Playbooks, Credentials, and Inventories, yet everything is easily linked in one automation unit. Therefore, complex dependencies can be broken down into steps between the different templates.
- 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
Non-privileged users can safely deploy entire applications with push-button deployment access 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 then 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 basic 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. We can see our automation’s status and which will run next.
- Requirements: Centralized logging and metrics
The Ansible Tower dashboard could offer a better view of our inventory, hosts, scheduled tasks, and the manual job runs. However, we can incorporate Ansible Tower with the ELK stacks for additional information to better understand trends that can help you 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. This provides a better way to manage and track their entire 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, there are several authentication methods to make it easy to embed Ansible Tower 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 is what 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. We can integrate Ansible Tower with tools such as 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.