Up next in 10
Learn how to run Ansible Playbooks directly from the AWX GUI in this in-depth, step-by-step tutorial. Whether you are managing a few servers or orchestrating automation across large infrastructures, Ansible AWX makes it easy with a powerful web-based interface.
In this video, we will cover:
✅ Setting up an AWX Project linked to a GitHub repository
✅ Creating and syncing an inventory from inventory.ini
✅ Configuring secure machine credentials for SSH access
✅ Building and launching a Job Template to run playbooks
✅ Monitoring job execution and reviewing detailed results
What You’ll Learn:
How AWX simplifies Ansible automation with centralized management
Best practices for Git integration and version control
Credential management for secure server connections
How to schedule and track automation jobs
GitHub Repository Used:
🔗 https://github.com/pradeepantil/linuxautomation
Key Benefits of Using AWX:
Show More Show Less View Video Transcript
0:00
Hello everyone, welcome back to the
0:01
channel. Today we are diving deep into
0:03
the world of automation with Enible EWX.
0:07
If you have ever found yourself managing
0:09
a growing number of servers struggling
0:11
to keep your Enible playbook organized
0:13
and easily executable, then this video
0:15
is for you. We will explore how Enible
0:18
AWS can transform your automation
0:20
workflows providing a powerful web-based
0:23
interface to manage your enable projects
0:25
inventories and credentials and most
0:28
importantly run your playbooks with
0:30
ease. Enable AWX is the upstream project
0:33
for Enible automation platform. It
0:36
brings enterprisegrade automation
0:37
capabilities right to your fingertips.
0:40
Before we jump into AWX, let's take a
0:43
quick look at the Enible project we will
0:45
be working with today. I have a GitHub
0:47
public repository named Linux automation
0:50
which contains a collection of ensible
0:52
playbooks designed for common Linux
0:55
server automation task. This repository
0:57
structure to include everything
0:58
necessary for our demonstration
1:01
including nible.cfz.
1:03
This is the configuration file which
1:05
defines the global settings for our
1:06
ensible runs. Inventory.ini our
1:09
inventory file listing the target host
1:12
where our playbooks will be executed.
1:14
various playbooks like main_playbook.ml
1:18
node exporter NTP playbook play packages
1:21
playbook system config user and upgrade
1:24
playbooks these ML files contains the
1:27
actual automation logic defining the
1:29
task to be performed on our Linux
1:31
servers for instance mean playbook is a
1:35
comprehensive playbook that handles user
1:38
creation package installation NTP
1:40
configuration post name setup time zone
1:43
settings and even the installation of
1:44
Prometheus exporter which is vital for
1:47
monitoring. Having our playbooks in a
1:49
git repository is the best practice. It
1:52
allows for version control,
1:54
collaboration and easy integration with
1:56
automation platforms like AWS. AWS can
1:59
directly pull our playbooks from this
2:01
repository ensuring we are always
2:04
running the latest version of our
2:06
automation code. I am assuming nible AWS
2:09
is already installed. In my case, NCWx
2:12
is installed on Kubernetes cluster. I
2:14
have a managed host. One is RHL. Another
2:17
one is Ubuntu. These are up and running
2:20
and connected to the network. Move to
2:22
the core of our demonstration.
2:23
Configuring Enible AWX to work with our
2:26
GitHub repository. Run our playbooks.
2:28
This involves few key steps. First step
2:31
is to create a new project in AWS. A
2:34
project in AWS defines where your enable
2:37
playbooks are stored. Since our
2:39
playbooks are stored in Git repository,
2:41
we'll configure AWX to pull them
2:43
directly from the GitHub. Next, we need
2:47
to define our inventory. An inventory in
2:49
AWS represents the host that ensol will
2:52
manage. Instead of manually adding the
2:54
host, we will configure AWS to read our
2:57
inventory.ini file directly from our
2:59
GitHub project. In the third step, we
3:01
will create the credentials. Credentials
3:03
are vital for AWS to authenticate with
3:05
your managed machines or manage host.
3:09
Credentials are of multiple type. It
3:11
could be a machine for SSH connections
3:13
to target host. Source control for
3:17
accessing the private GitHub repository.
3:19
Vault for decryptting anible vault
3:21
encrypted content. Cloud provider for
3:24
various cloud platforms like AWS, Azure
3:26
and GCP etc. In fourth step, we will
3:30
create a job template. Job templates are
3:32
the core of running automation in AWX.
3:35
They combine a project inventory and
3:38
credentials with specific playbook to
3:40
define an automation job. A job template
3:42
offers multiple features like limit. It
3:45
can restrict the execution to a specific
3:47
host or groups. Tags run only specific
3:50
task with matching tags. Skip tags means
3:53
it will skip the task with matching
3:56
tags. scheduling. Set up a recurring job
3:59
execution. In step five, we will run our
4:02
playbook via job template. All right,
4:05
let's see these steps in action. Log to
4:08
your AWS GUI. Use the username as admin
4:11
and the password. Click on login. It
4:15
will take us to the AWX dashboard. Let's
4:19
create a new project. From the left hand
4:22
navigation menu, we have projects option
4:24
under the resources. Select the projects
4:27
here. Click on add in order to create a
4:30
new project. Let's give a name of your
4:33
project.
4:36
Linux automation.
4:40
Select the organization that you would
4:42
like to associate with this project. So
4:44
I'm using the default organization. Yes.
4:47
Choose this default one. Source control
4:49
type.
4:51
Choose g here
4:54
as we are using github public repository
4:58
in source control URL we need to specify
5:01
the URL of our GitHub repository. This
5:04
is the URL of my GitHub repository. Just
5:07
copy this URL. Paste it here
5:11
under source control branch tag and
5:14
commit. You can specify a branch name
5:17
like main or any other branch tag or
5:20
commit hash tree. For simplicity, we
5:22
will be using
5:25
a branch with the name dev automation.
5:30
Just copy this branch name here
5:33
and paste it
5:36
under the source control branch.
5:39
Scroll down.
5:41
Select the option update revision on
5:44
launch. This will ensure that AWX always
5:48
pulls the latest version of your playbox
5:50
before running a job.
5:52
Click on save. After saving, AWX
5:56
automatically perform an initial sync
5:58
with your GitHub repository, pulling
6:00
down all the playbooks and related
6:02
files. All right, this successful tick
6:06
mark confirms that sync has been
6:08
completed successfully. AWX instance is
6:10
able to clone the uh Linux automation
6:13
repository using this devy automation
6:16
branch. Next, we will create an
6:19
inventory. Again, from the leftand
6:21
navigation menu tab, we have
6:24
inventory under the resources. So,
6:27
select the inventories. Here, click add.
6:30
Select add inventory. Give the name of
6:32
your inventory. Let's say Linux servers.
6:37
Organization name is default.
6:41
Click on save. This will take us to this
6:43
page. Select sources here. Click on add.
6:49
Give the name of your source. In my
6:50
case, source is GitHub repo.
6:56
And source type would be sourced from a
6:58
project.
7:01
Select the project Linux automation.
7:03
Here
7:06
in inventory file you will able to see
7:08
the inventory.ini. This inventory.ini
7:11
file is coming from my GitHub public
7:13
repository. So select inventory.ini.
7:17
Scroll down. Click on update on launch
7:21
under the update options. This ensures
7:24
that inventory is always up to date
7:26
before a job runs. Scroll down. Click on
7:29
save. TWWX will now sync your inventory
7:33
from the specified file in your GitHub
7:35
repository. This ensures that any
7:37
changes to your GitHub inventory.ini
7:39
file in Git are automatically reflected
7:42
in AWX. If you click on inventory, you
7:45
will see the option success. It means it
7:47
has been synced successfully.
7:50
Next, create the credentials. Under the
7:52
resources, we have credentials
7:55
options as well. Just select that one.
7:57
Click on add. Give the name of your
8:00
credentials. Let's say Linux
8:04
SSH
8:06
server key. Credentials type would be
8:10
machine. Here
8:13
choose machine.
8:15
Specify the username. I will be using
8:18
Linux T key as a user.
8:22
Authenticate to the manage host or the
8:24
target host. I have already generated
8:27
the public and private key for this
8:29
Linux key user on my control plane. Let
8:32
me go there. If I do ls
8:39
keys are already generated. Let me get
8:42
the
8:44
content of this private key.
8:49
Copy it.
8:52
Paste it here.
8:54
Scroll down under privilege acceleration
8:56
method. Choose sudo
9:00
privilege acceleration username
9:03
root. Click on save.
9:07
Coming back to my control plane. We need
9:10
to also make sure that public key of
9:12
this lin key users is shared with the
9:17
manage host. So for that what you can do
9:20
is you can run SSH - copy id. So this is
9:25
my manage host
9:28
IP address.
9:30
Let me copy the public key to the second
9:33
manage host.
9:37
Output confirms that it has been copied
9:39
successfully. Actually I have already
9:42
copied the public key of this Linux key
9:45
user to the manage host 22 and 23.
9:50
That's why we are getting this output
9:52
which is already installed.
9:55
Now moving back to the AWS GUI in the
9:59
next step we will create a job template.
10:02
Select the template option here. Click
10:05
on add. Choose add a job template.
10:09
Specify the name of your job template.
10:11
So in my case it is Linux
10:15
server setup.
10:20
Job type would be run.
10:23
Select the inventory Linux servers
10:28
project Linux automation
10:33
playbook. Which playbook I would like to
10:35
execute using this job template. So
10:38
let's say I would like to execute
10:40
packages playbook file. Which
10:44
credentials will be associated to this
10:46
job template for running this playbook.
10:49
Select the credentials Linux SSS server
10:52
key we have just created in the previous
10:54
step. Just click select.
10:58
Scroll down.
11:00
Under the options, select privilege
11:03
accelerations.
11:05
Click on save.
11:08
Now in order to trigger
11:12
choose launch
11:14
it will start executing this playbook on
11:18
the manage host which is mentioned in
11:21
inventory.ini file. You will see the
11:23
status has turned to running. We will
11:26
see the output of the playbook on our
11:29
screen. Something like this. Once the
11:31
playbook has been executed successfully,
11:34
we'll see this pick mark green
11:37
successful. This means playbook has been
11:40
executed successfully. Let's say I want
11:42
to execute another playbook using this
11:45
job template. What I can do? I can go
11:47
back to the template. Select the
11:48
template Linux server setup.
11:52
Click on edit here.
11:55
Let's say I want to execute main
11:57
playbook.l file. Main playbook file will
12:02
execute multiple tasks like installing
12:05
node exporter,
12:07
installing all the necessary packages,
12:09
installing updates, creating pseudo
12:11
users, configuring NTP, set the correct
12:16
time and time zones. Scroll down,
12:19
click on save.
12:26
You will see the status first as pending
12:29
and in a second or two it will turn into
12:32
the running.
12:36
Output confirms that playbook execution
12:39
has been started. Different tasks are
12:41
being executed on the manage host.
12:50
All right. This output confirms that
12:53
playbook has been executed successfully.
12:56
In order to download the logs of this
12:58
playbook, we have this option download
13:01
output. Click on this.
13:06
So this is the output of my main
13:08
playbook file.
13:13
So this confirms that the playbook has
13:16
been executed on RHL server - 1 group
13:20
and another one is Ubuntu - server - 1.
13:24
Coming back to the AWS GUI again if you
13:27
go back to the dashboard you will see
13:29
the job status.
13:34
That's all from this video tutorial. We
13:36
have successfully demonstrated how to
13:38
integrate your encable playbook from
13:40
GitHub repository into the encable AWX.
13:43
Configure all the necessary components.
13:45
Execute your automation task with just a
13:47
few clicks from your user-friendly web
13:49
interface. AWX truly simplifies the
13:52
management and execution of enable
13:54
making your automation efforts more
13:56
efficient, collaborative andable. Key
13:58
takeaways from today's video. AWS
14:01
provide a single pane of glass for your
14:03
enable automations means centralized
14:06
management. Version control integration
14:08
seamlessly pull playbooks from the
14:09
GitHub repository ensuring consistency
14:12
credentials management securely store
14:14
and manage sensitive credentials. Job
14:17
scheduling and monitoring it schedule
14:19
the jobs track their progress and review
14:22
detailed outputs. This setup is
14:25
incredibly powerful for the teams
14:26
looking to scale their automations,
14:28
enforce best practices and provide
14:31
self-service portal for running NC
14:33
playbox. If you found this video
14:35
helpful, please give it a thumbs up.
14:37
Subscribe to the channel for more
14:38
automation content. Hit the notification
14:41
bell so you don't miss the next video.
14:43
Let me know in the comments below what
14:45
other anible or automation topics you
14:47
would like us to cover. Thanks for
14:49
watching. See you in the next one. Bite.