Auto Ansible : AWX
I was initially preparing to use Ansible to efficiently control and configure a large number of instances.
I was on an internship and would be leaving soon,, so I decided to prepare for the introduction of AWX, which would allow me to run Ansible scripts in a GUI environment for the convenience of my coworkers after I left.
It never actually materialized for security reasons, but it was an interesting service, so I though I’d summarize it.
Ansible
What is Ansible
Ansible is an open source IaC solution and IT automation tool developed in Python. It allows you to automate and manage IT tasks via YAML or JSON, including configuring systems, deploying applications, and more.
Ansible replaces shell scripts, which can be difficult to manage when the resources or number of servers grows exponentially, and is suitable for managing any environment, from small to enterprise environments managing thousands of servers.
To summarize the benefits:
- SSH communication for agentless management
- Easy, readable
- Idempotency (that doesn’t change over multiple operations)
Ansible usage scenarios
- Start working on the Control Node, which is the server where Ansible is installed.
- The Control Node has an Inventory file. This file lists the target service on which you want to install the web server(: the IP addresses or domain names of the hosts, the host groups, and so on.. )
- Run the Playbook that defines the tasks to install and configure the web server. This Playbook is written in YAML.
- These defined Tasks are related to each other and can be collected together and defined as a single Role.
- Now when you run the playbook, the Control Node connects to each Host specified in the Inventory and performs the Tasks defined by the Role.
- The Tasks are performed with the User permissions specified in the Playbook or Inventory(become)
- If all tasks are successfully executed, the web server installation and configuration is complete.
Playbook Structure
- Inside the Playbook, there are several Tasks, each of which uses a specific Module to perform a Task.
How to use Ansible
- Ansible Ad-Hoc
Performing a single task is called an Ad-Hoc Command and can be executed, for example, as show below.
ansible [pattern] -m mode [-a 'module options'] [-i inventory]
# ex) Run the ping module test against the hosts in the group named aws_ec2.
ansible -m ping aws_ec2
More details about pattern are available in the docs : https://docs.ansible.com/ansible/latest/inventory_guide/intro_patterns.html#intro-patterns
2. Playbook
If you need to run a combination of tasks, you can also write a collection of tasks, which we call a playbook. Below is code to set the root password, and load the role responsible for the default installation of k8s.
--
- hosts: all
become: yes
vars_files:
- secrets.yml
vars:
os: xUbuntu_22.04
crio_version: 1.28
pre_tasks:
- name: Set root password
user:
name: root
password: "{{ root_password | password_hash('sha512') }}"
roles:
- k8s_default
#Execution
ansible-playbook -i aws_ec2.yml setup.yml
AWX
What is AWX
An Open Source version of Ansible Tower, system that allows you to manage Ansbile with GUI and control it with an API.
AWX is the nature of the middleware that runs the Ansible language. There’s very little Ansible can do without playbooks, so it’s really all about developing Ansible playbooks.
And,, AWX provides many of the features you need to manage and operate your playbooks.
It provides the following features:
- Ansible Project Management and Host Management
- Provisioning and Configuration Management
- CD(Continuous Delivery) & Workflow Template
- Centralized logging/audit
- Authentication integration (LDAP, SAML, GitHub, Google, Azure AD)
- Visualized web dashboard
- High availability
How to install AWX
I’ve kept it simple. For more information, please refer to the links below.
Note that AWX installs on top of Docker on Linux OX up to version 17 (k8s is also possible), and from version 18 onwards, AWX defaults to installing on top of Kubernetes (no Docker support).
I turned on the virtualenv venv and proceeded. If you have venv enabled, you will need to replace the ansible_python_interpreter path in ~/awx/installer/inventory with the venv python path. And, installation methods may vary from environment to environment.
# Install Ansible
$ yum install ansible -y
# Install pip
$ yum isntall python3-pip
# Install Docker
# https://github.com/docker/docker-py/issues/3194
(venv)$ pip install docker==6.1.3
# Install Docker Compose
(venv)$ pip install docker-compose
# Install Git & AWX 17.1.0
yum -y install git
git clone --branch 17.1.0 --single-branch https://github.com/ansible/awx.git
# Configuration
cd ~/awx/installer # It is related to my AWX path
vi inventory # This file contains the env information required to install AWX
# admin_password=password <-- Uncomment : change password you want
# project_data_dir=/var/lib/awx/projects <-- Uncomment
yum -y install libselinux-python3
ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
ansible-playbook -i inventory install.yml -b
# Confirm
docker ps
About AWX
AWX is not an automation tool per se, it’s more about providing an environment to help organizations use the Ansible code developed for automation, so the features it provides are aimed at managed lists, registering accounts, registering SCM information, and finally creating templates that actually do the work in order to run the Ansible code developed.
The components of AWX include..
Nginx
- This is a web server that acts as a reverse proxy, loadbalancer, mail proxy, and HTTP cache.
- In AWX, it is responsible for routing client requests to the appropriate services and delivering responses from those services to the client.
PostgreSQL
- This is the main database used by AWX. It stores information such as AWX’s settings, user info, and job results.
- PostgreSQL provides features such as transactions and recovery, subqueries, triggers, and replication to support the reliability and scalability of AWX.
Redis
- This is an in-memory data structure store that is used as a database, cache, message broker, and so on.
- In AWX, it is responsible for fetching and processing messages from the job queue.
- It is also improves performance by caching state information, job results, and etc.
RabbitMQ
- This is a message broker, which is responsible for asynchronous message delivery between AWX components.
- In AWX, it’s responsible for enqueuing job requests and letting Redis handle them.
The way AWX works is roughly as follows
- A user requests to run an Ansible Playbook through the AWX web interface.
- The request is passed through Nginx to the AWX API server.
- The AWX API server passes the request to RabbitMQ, which adds it to the job queue.
- Redis fetches the job from RabbitMQ’s job queue and processes it.
- The job’s execution results are stored in a PostgreSQL database and cached by Redis if necessary.
- The user can view the job’s execution results through the AWX web interface.
Using AWX
Let’s take a look at just a few of the highlights of the sidebar UI.
Credentials
- Register permissions to access a target
- The target can be a server, or it can be Github. Typically, you would register an SSH private key or password to access the server so that it is available to authorized users without exposing its contents.
Projects
- Manage projects in SCM, that is, in Git or SVN, typically used as a unit of service.
- For example, create credentials to log in to Git and associate them with projects to clone sources from Git.
Inventories
- A list of target servers to work with, either as a list of IPs or IP lookupable hostnames.
- You can list servers one by one, or you can manage them in groups, or you can include groups within groups.
- When using Ansible directly, you create and mange a hosts file, but AWX supports building lists using several sources.
Templates
- Gain access to the server in the Inventory list with credentials to run the playbooks in your project.
If you have an idea of Ansible, using the GUI, AWX, shouldn’t be too difficult. So, let’s just talk about Instance Groups of a moment and wrap things up.
AWX has something called Instance Groups, which you should know is different from Inventory.
An instance group in AWX is a structure for managing the computing resource on a system used to process AWX jobs. In other words, an instance group represents a collection of AWX instances running Ansible playbooks.
By managing multiple instances together as an instance group, you can valance the load of AWX jobs. This prevents the load from being concentrated on a single instance and improves the performance and reliability of the overall system.
On the other hand, AWX’s inventory is a structure that manages the hosts that are the target of Ansible jobs.
The link below shows a simple example of adding an instance named task. Please refer to it if necessary.