Ansible Architecture
Ansible has emerged as one of the most popular automation tools, revolutionizing how organizations manage and deploy their IT infrastructure. Ansible has gained widespread adoption across diverse industries with its simple yet robust architecture. In this blog post, we will delve into the intricacies of Ansible architecture, exploring how it works and its key components.
At its core, Ansible follows a client-server architecture model. It has three main components: control nodes, managed nodes, and communication channels. Let’s take a closer look at each of these components.
1. Control Node:
The control node acts as the central management point in Ansible architecture. It is the machine from which Ansible is installed and executed. The control node stores the inventory, playbooks, and modules to manage the managed nodes. Ansible uses a declarative language called YAML to define playbook tasks and configurations.
2. Managed Nodes:
Managed nodes are the machines that Ansible is driving. These can be physical servers, virtual machines, or even network devices. Ansible connects to managed nodes over SSH or WinRM protocols, enabling seamless management across different operating systems.
3. Communication Channels:
Ansible utilizes SSH or WinRM protocols to establish secure communication channels between the control node and managed nodes. SSH is used for Linux-based systems, whereas WinRM is for Windows-based systems. This allows Ansible to execute commands, transfer files, and collect information from managed nodes.
Highlights: Ansible Architecture
- Playbooks and Inventory
As a best practice, you don’t want your Ansible architecture that consists of playbooks and Inventory to be too specific. But on the other hand, you need to have a certain level of abstraction and keep out precise information. Therefore, to develop flexible code, you must separate site-specific information from the code, done with variables in Ansible.
Remember that when you develop dynamic code along with your static information, you can use this on any site with minor modifications to the variables themselves. However, you can have variables in different places, and where you place variables, such as a play header or Inventory, will take different precedence. So, to provide site-specific code, variables can be used in your Ansible deployment architecture.
Before you proceed, you may find the following posts helpful for pre-information:
- A key point: Video on Ansible automation and Ansible architecture.
In this video, we will discuss Ansible automation and Ansible architecture. In particular, Ansible Engine is run from the CLI. This is compared to a different Ansible deployment architecture with Ansible Tower, a platform approach to security. We will discuss the challenging landscape forcing us to move to automation. At the same time, it introduces Ansible playbooks, Ansible variables, and other main components.
Ansible Architecture: The Drive for Automation
To move to an Ansible architecture has been driven by several megatrends. Firstly, the rise of distributed computing made the manual approach to almost anything in the IT environment obsolete. Not only because this causes many errors and mistakes but also because the configuration drift from the desired to the actual state was considerable.
Not only is this an operational burden, but also a considerable security risk. Today, deploying applications by combining multiple services that run on a distributed set of resources is expected. As a result, configuration and maintenance are more complex than in the past.
Ansible Architecture |
|
You have two options to implement all of this. First, you can connect up these services by, for example, manually spinning up the servers, installing the necessary packages, and SSHing to each one, or you can go down the path of automation, in particular, automation with Ansible.
So, with Ansible deployment architecture, we have the Automation Engine, the CLI, and Ansible Tower, which is more of an automation platform for enterprise-grade automation. This post focuses on Ansible Engine.
As a quick note, if you have environments with more than a few teams automating, I recommend Ansible Tower or the open-source version of AWX. This is because Ansible Tower has a 60-day trial license, while AWX is fully open-sourced and does not require a license. The open-source version of AWX could be a valuable tool for your open networking journey.
- A Key Point: Risky: The Manual Way.
Let me put it this way. If you are configuring manually, you will likely maintain all the settings manually. Or, more importantly, what about mitigating vulnerabilities and determining what patches or packages are installed in a large environment?
How can you ensure all your servers are patched and secured manually? Manipulating configuration files by hand is a tedious and error-prone task. Not to mention time-consuming. Equally, performing pattern matching to make changes to existing files is risky.
- A Key Point: The issue of Configuration Drift
The manual approach will result in configuration drift, where some servers will drift from the desired state. Configuration drift is caused by inconsistent configuration items across devices, usually due to manual changes and updates and not following the automation path. Ansible is all about maintaining the desired state and eliminating configuration drift.
Ansible Architecture | Automation Feature |
Ansible Workflow:
Ansible operates on a push-based model, where the control node pushes configurations and commands to the managed nodes. The workflow involves the following steps:
1. Inventory:
The inventory is a file that contains a list of managed nodes. It provides Ansible with information such as IP addresses, hostnames, and connection details required to establish communication.
2. Playbooks:
Playbooks are YAML files that define the desired state of the managed nodes. They consist of a series of tasks or plays, where each task represents a specific action to be executed on the managed nodes. Playbooks can be as simple as a single task or as complex as a multi-step deployment process.
3. Execution:
Ansible executes playbooks on the control node and communicates with managed nodes to perform the defined tasks. It uses modules, which are small programs written in Python or other scripting languages, to interact with the managed nodes and carry out the required operations.
4. Reporting:
Ansible provides detailed reports on the execution status of tasks, allowing administrators to monitor and troubleshoot any issues that arise. This helps maintain visibility and ensure the desired configurations are applied consistently across the infrastructure.
- A key point: Video on Ansible Job Template
In this product demonstration, we will go through the key components of Ansible Tower and its use of Job Templates. We will look at the different Job Template parameters that you can use to form an automation job that you can deploy to your managed assets.
Advantages of Ansible Architecture:
The Ansible architecture offers several advantages, making it a preferred choice for automation:
1. Simplicity:
Ansible’s architecture is designed to be simple and easy to understand. Using YAML playbooks and declarative language allows administrators to define configurations and tasks in a human-readable format.
2. Agentless:
Unlike traditional configuration management tools, Ansible requires no agent software installed on managed nodes. This reduces complexity and eliminates the need for additional overhead.
3. Scalability:
Ansible’s architecture is highly scalable, enabling administrators to manage thousands of nodes simultaneously. SSH and WinRM protocols allow for efficient communication and coordination across large infrastructures.
Components of Ansible Deployment Architecture
-
-
Configuration management
-
The Ansible architecture is based on a configuration management tool that can help alleviate these challenges. Ansible replaces the need for an operator to tune configuration files manually and does an excellent job in application deployment and orchestrating multi-deployment scenarios. It can also be integrated into CI/CD pipelines.
In reality, Ansible is relatively easy to install and operate. However, it is not a single entity. Instead, it comprises tools, modules, and software-defined infrastructure that form the ansible toolset configured from a single host that can manage multiple hosts.
We will discuss the value of idempotency with Ansible modules later in mind. Even with the idempotency nature of modules, you can still have users of Ansible automate over each other. Ansible Tower or AWS is the recommended solution for multi-team automation efforts.
-
-
Pre-deployed infrastructure: Terraform
-
Ansible does not deploy the infrastructure; you could use other solutions like Terraform that are best suited for this. Terraform is infrastructure as a code tool. Ansible Engine is more of a configuration as code. The physical or virtual infrastructure needs to be there for Ansible to automate, compared to Terraform, which does all of this for you.
Ansible is an easy-to-use DevOps tool that manages configuration as code has in the same design through any sized environment. Therefore, the size of the domain is irrelevant to Ansible.
As Ansible Connectivity uses SSH that runs over TCP, there are multiple optimizations you can use to increase performance and optimize connectivity, which we will discuss shortly. Ansible is often described as a configuration management tool and is typically mentioned along the same lines as Puppet, Chef, and Salt. However, there is a considerable difference in how they operate. Most notably, the installation of agents.
-
-
Ansible architecture: Agentless
-
The Ansible architecture is agentless and requires nothing to be installed on the managed systems. In addition, its architecture is serverless and agentless, so it has a minimal footprint. Some configuration management systems, such as Chef and Puppet, are “pull-based” by default.
Where agents are installed, periodically check in with the central service and pull-down configuration. Ansible is agentless and does not require the installation of an agent on the target for Ansible to communicate to the target host.
However, it requires connectivity from the control host to the target inventory ( which contains a list of hosts that Ansible manages) with a trusted relationship. For convenience, we can have passwordless sudo connectivity between our hosts. This allows you to log in without a password and can be a security risk if someone gets to your machines; they could have escalated privileges on all the Ansible-managed hosts.
Ansible Deployment Architecture
Ansible Architecture Key Features
|
Key Ansible features:
Easy-to-Read Syntax: Ansible uses the YAML file format and Jinja2 templating. Jinja2 is the template engine for the Python programming language. Ansible uses Jinja2 templating to access variables and facts and extends the defaults of Ansible for more advanced use cases.
Not a full programming language: Remember that Ansible is not a full-fledged programming language, but it has several good features. One of the most important of these is a variable substitution, or using the values of variables in strings or other variables.
In addition, the variables in Ansible make the Ansible playbooks, which are like executable documents, very flexible. Variables are a powerful construct within Ansible and can be used in various ways. Nearly every single thing done in Ansible can include a variable reference. We also have dynamic variables known as facts.
Jinja2 templating language: The defaults of Ansible are extended using Jinja2 templating language. In addition, Ansible’s use of Jinja2 templating adds more advanced use cases to Ansible. One great benefit is that it is self-documenting, so when someone looks at your playbook, it’s easy to understand, unlike a Python code or a Bash script.
So not only is Ansible easy to understand, but with just a few lines of YAML, which is the language used for Ansible, you can install, let’s say, web servers on as many hosts as you like.
Ansible Architecture: Scalability: Ansible can scale. For example, Ansible uses advanced features like SSH multiplexing to optimize SSH performance. Some use cases manage thousands of nodes with Ansible from a single machine.
SSH Connection: Parallel connections: We have three managed hosts: web1, web2, and web3. Ansible will make SSH connections parallel to web1, web2, and web3. It will then execute the first task on the list on all three hosts simultaneously. In this example, the first task is installing the Nginx package, so the task in the playbook would look like this. Ansible uses the SSH protocol to communicate with hosts, except for Windows hosts.
This SSH service is usually integrated with the operating system authentication stack, enabling you to use Kerberos to improve authentication security. Ansible uses the same authentication methods that you will already be familiar with. SSH keys are typically the easiest way to proceed as they remove the need for users to input the authentication password every time a playbook is run.
- A key point: Optimizing SSH
Ansible uses SSH to manage hosts, and establishing an ssh connection takes time. However, you can optimize SSH with several features. Because the SSH protocol runs on top of the TCP protocol, you need to create a new TCP connection when you connect to a remote host with SSH.
You don’t want to open a new SSH connection for every activity. Here, you can use Control Master, which allows multiple simultaneous SSH connections with a remote host using one network connection. Control Persists, or multiplexing, keeps a connection option for xx seconds. The pipeline allows more commands to use simultaneous SSH connections. If you recall how Ansible executes a task?
-
- It generates a Python script based on the module being invoked
- It then copies the Python script to the host
- Finally, it executes the Python script
The pipelining optimization will execute the Python scripts by piping it to the SSH sessions instead of copying git. Here, we are using one SSH session instead of two. These options can be configured in Ansible.cfg, and we use the SSH_connecton section. Then, you can specify how these connections are used.
-
A note on scalability: Ansible and modularity
Ansible scales down well because simple tasks are easy to implement and understand in playbooks. Ansible scales well because it allows the decomposing complex jobs into smaller pieces. So we can bring the concept of modularity into playbooks as the playbook becomes more difficult. I like using Tags for playbook developments that can save time and effect to test different parts of the playbook when you know certain parts are 100% working.
Security wins! No daemons and no listening agents
Once Ansible is installed, it will not add a database, and there will be no daemons to start or keep running. You only need to install it on one machine (which could easily be a laptop), and it can manage an entire fleet of remote machines from that central point. No Ansible agent is listening on a port. Therefore, when you use Ansible, there is no extra attack surface for a bad actor to play with.
This is a big win for security following one of the leading security principles of reducing the attack surface. When you run the Ansible-playbook command, Ansible connects to the remote servers and does what you want. By its defaults, Ansible is pretty streamlined out of the box, but you can enhance it by configuring Ansible.cfg file, to be even more automated.
Ansible Architecture: Ansible Architecture diagram.
-
- Ansible Inventory: Telling Ansible About Your Servers
The Ansible architecture diagram has several critical components. First, the Ansible inventory is all about telling Ansible about your servers. Ansible can manage only the servers it explicitly knows about. Ansible comes with one default server of the local host, the control host.
You provide Ansible with information about servers by specifying them in an inventory. We usually create a directory called “inventory” to hold this information.
For example, a straightforward inventory file might contain a list of hostnames. The Ansible Inventory is the system that a playbook runs against. It is a list of systems in your infrastructure that the automaton is executed against. The following Ansible architecture diagram shows all the Ansible components, including modules, playbooks, and plugins.
Ansible architecture diagram: Inventory highlights
These hosts commonly have hosts but can comprise other components such as network devices, storage arrays, and other physical and virtual appliances. It also has valuable information that can be used alongside our target using the execution.
The Inventory can be simple as a text file or more dynamic where the Inventory is an executable where the data is sourced dynamically. This way, we can store data externally and use it during runtime. So we can have a dynamic inventory via Amazon Web Service or create our own dynamic.
- A key point: Video on Ansible Inventory
This short educational tutorial will discuss the Ansible Inventory used to hold the Ansible Managed Host. We will then discuss the different types of inventories, static and dynamic. Along with other ways, you can apply variables to host in the inventory.
Example: AWS EC2 External inventory script
You will see a connection to the cloud in the above Ansible architecture diagram. If you use Amazon Web Services EC2, maintaining an inventory file might not be the best approach because hosts may come and go over time, be managed by external applications, or be affected by AWS autoscaling.
For this reason, you can use the EC2 external inventory script. In addition, if your hosts run on Amazon EC2, then EC2 tracks information about your hosts for you. Ansible inventory is flexible; you can use multiple inventory sources simultaneously. Mix dynamic and statically managed inventory sources in the same ansible run is possible. Many are referring to this as an instant hybrid cloud.
Ansible deployment architecture and Ansible modules
Next, within the Ansible deployment architecture, we have the Ansible modules, considered to be the main workhorse of Ansible. You use modules to perform various tasks, such as installing a package, restarting a service, or copying a configuration file. Ansible modules cater to a wide range of system administration tasks.
This list has the categories of the kinds of modules that you can use. There are over 3000 modules. So you may be thinking, who is looking after these modules? That’s where collections in the more recent versions of Ansible are doing.
-
-
Extending Ansible modules
-
The modules are the scripts ( that are written in Python) that come with packages with Ansible and Perform some action on the managed host. Ansible has extensive modules covering many areas, including networking, cloud computing, server config, containerized, and virtualization.
In addition, there are many modules to support the automation requirements you have. If no modules exist, you can create a custom module with the extensive framework of Ansible. So, each task is a one-to-one correlation with the module. So, for example, a template task will use the template module.
-
-
A key point: Idempotency
-
Modules strive to be idempotent, allowing the module to run repeatedly without a negative impact. In Ansible, the input is in the form of command-line arguments to the module, and the output is delivered as JSON to STDOUT. Input is generally provided in the space-separated key=value syntax, and it’s up to the module to deconstruct these into usable data.
Most of the Ansible modules are also idempotent. Idempotent means running an Ansible playbook multiple times against a server is safe. For example, if the deploy user does not exist, Ansible will create it. If it does exist, Ansible will not do anything. This is a significant improvement over the shell script approach, where running the script a second time might have different and potentially unintended effects.
-
-
The Use of Ansible Ad Hoc Commands
-
For instance, if you wanted to power off all of your labs for the weekend, you could execute a quick one-liner in Ansible without writing a playbook. With an Ad Hoc command, we can be suitable for running one command on a host, and it uses the modules. They are used for checking configuring on the host and are also good for learning Ansible.
Note that Ansible is the executable for ad hoc one-task executions, and ansible-playbook is the executable that will process playbooks to orchestrate multiple tasks.
The opposable side of the puzzle is the playbook commands are used for more complex tasks and are better for use cases where the dependencies have to be managed. The playbook can take care of the entire application deployments and dependencies.
Ansible Plays
-
Ansible playbooks
An Ansible Playbook can have multiple plays that can exist within an Ansible playbook that can execute on different managed assets. So, an Ansible Play is all about “what am I automating.” Then, it connects to the hosts to perform the actions. Each playbook comprises one or more ‘plays’ in a list. The goal of a play is to map a group of hosts to some well-defined roles, represented by things Ansible calls tasks.
At a basic level, a task is just a call to an Ansible module. By composing a playbook of multiple ‘plays’, it is possible to orchestrate multi-machine deployments, running specific steps on all machines in the web servers group. For example, particular actions on the database server group, then more commands back on the web servers group, etc.
-
Ansible tasks
Ansible is ready to execute a task once a playbook is parsed and the hosts are determined. Tasks include a name, a module reference, module arguments, and task control directives. Task execution By default, Ansible executes each task in order, one at a time, against all machines matched by the host pattern. Each task executes a module with specific arguments. You can also use the “–start-at-task <task name> flag to tell the Ansible playbook to start a playbook in the middle of a task.
-
Task execution
Each play contains a list of tasks. Tasks are executed in order, one at a time, against all machines matched by the host pattern before moving on to the next task. It is essential to understand that, within a play, all hosts will get the same task directives. This is because the purpose of a play is to map a selection of hosts to tasks.
- Fortinet’s new FortiOS 7.4 enhances SASE - April 5, 2023
- Comcast SD-WAN Expansion to SMBs - April 4, 2023
- Cisco CloudLock - April 4, 2023