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: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: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: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:25
a branch with the name dev automation.
5:30
Just copy this branch name here
5:36
under the source control branch.
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
7:01
Select the project Linux automation.
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:06
server key. Credentials type would be
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:44
content of this private key.
8:54
Scroll down under privilege acceleration
9:00
privilege acceleration username
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:30
Let me copy the public key to the second
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: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.
11:00
Under the options, select privilege
11:08
Now in order to trigger
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: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: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:26
You will see the status first as pending
12:29
and in a second or two it will turn into
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: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: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.