- Having to rely solely on one public cloud expert
on your team creates bottlenecks
and limits the overall productivity
of your entire organization.
But what if there was a way to clone those skills
so everyone on the team could contribute to automation
regardless of their expertise level?
Like right now, I could really use an extra pair of hands
and a monitor.
Awesome, thanks.
(upbeat music)
So when people start their automation journey,
a lot of times there's really cool
backgrounds of how these people get into automation.
I often like to go back to like a proverb I heard
which is, if you have a boring or difficult task,
give it to a lazy person and they always find
interesting ways to solve it.
And that's kind of my own automation journey.
One of my first jobs out of university
was doing very boring testing.
And it was very manually intensive
but once we had scripted this up,
I had basically automated all the boring stuff
so I could focus on new activities,
new problems, new things.
Now one of the problems that happened
was when I handed co-workers a bunch of Python scripts
and Perl scripts and they're not exactly
very human readable or understandable.
Coming back to that particular team like a year later
is that they had thrown away maybe 80% of what I had done,
and some of them had even gone back to doing stuff manually
like clicking buttons in a vendor tool
to test packet by packet and then it just went unused.
And that's what brought me to Ansible.
Ansible is really easy for you to share
and reuse automation and that's a huge tenant
of what we do today and making it easy to use and consume.
So when we talk Ansible Automation Platform
and how it can help users democratize automation,
there's actually a bunch of different tools
within the platform.
The first one is just Ansible playbooks themselves
are really easy to understand.
You can look at a playbook and it's almost self-documenting.
Each task is a human readable task that you can understand
and read and just literally understand like do this,
then do this, then do that.
And then when you actually start taking advantage
of platform components like automation controller,
you can take these playbooks and these automation jobs
and put them into easy, bite-size pieces
that anyone can launch, anyone can perform
and you can add things like surveys or schedules to them
so that it's really easy for anyone to take advantage
of anyone else's playbook.
Business continuity tasks could just be like snapshots,
backups, managing resources, turning off unused resources,
making sure that we can manage disruptions
so that your team isn't down.
'Cause that's the worst thing that can happen
is you're reactive instead of being proactive,
then you never have time to automate
and work on anything that's more high priority or fun.
Instead of just talking about it,
let's go ahead and actually look at
Ansible Automation Platform and what it can do for you.
I'm gonna go ahead and log in.
And this is automation controller
which is the web UI component
for Ansible Automation Platform
and it defaults us to the dashboard.
You can see I have a really cool setup.
We have 300 hosts, 22 inventories, 34 projects.
I have a bunch of team members using this.
So you can actually see what Ansible Automation Platform
looks like when it's in production with multiple users.
It kind of gives you an idea of what that can look like
for your team and organization.
Specifically we're talking cloud automation
and things we can do with cloud automation.
I wanna talk about cloud backups or snapshots in this case.
So it's really easy to set up backups
for someone that may not be a cloud expert on your team.
Is there a system administrator?
They understand it.
They might have other tools that can do this.
They might have DIY Python scripts
or whatever, setting this up.
But now you can see how I can democratize jobs.
There might be a playbook developer or writer
creating playbooks, but it's really easy for them
to adopt these playbooks and put them into production
really easily.
So when I want to use this
I can just click this rocket button,
it launches that job template
and then it actually prompts me with a survey.
And the survey is really easy
like any survey you use online.
I can select multiple regions.
These are AWS regions in this case.
And I'm gonna select like AP South 1
and three different US regions just at random.
So this is just a survey field,
makes it really easy to put guardrails on your automation
but still allow customizability for that particular job.
So I'm gonna click next in here.
I can review the job details
and we can see in here what inventory it's running on,
what project it got that playbook from,
what execution environments it's using.
And even that survey, I can go down here
and see it filled out that survey with variables for myself
and then I can click launch.
And you see how easy it is to launch a job
is I didn't even understand how to build the playbook
or write the playbook or where the playbook was stored,
so it becomes really easy to operationalize my playbooks
and put them into production.
So you can see those four regions
that I selected from the survey.
It's gonna snapshot all instances in there
and then it goes down and it starts grabbing
all the instance IDs and running them
and creating snapshots for my team.
And you can see that playbook is very easy to see
the output of and you understand it
and you can even zoom into this
and get the the JSON fields if you want to
or download the playbook.
So I'm gonna go back and talk about another use case
which is very cool for operationalizing AWS
kind of things you would click within the web UI
and click and point and it might be like
five or six windows.
So one of the things my team likes to do is create tags.
We like to tag early, tag often, and there's no limit
to the amount of tags you can put on cloud resources.
And the reason we like to do this is to say,
who owns this particular resource?
We kind of have an audit trail of cloud resources
and we can make sure billing is appropriate.
Like, hey, this guy spent this much on resources
we can make sure that they're responsible for
or understand the cost associated
with putting something in public cloud.
So one of the things we do is create an owner tag.
And in this case I'm actually gonna show a workflow.
And a workflow is a little bit different
from a job template by itself,
is I can actually daisy chain
multiple job templates together.
In this case I just have one line
so all these are running in parallel.
So you can gonna have multiple jobs running parallel,
but it could also build a workflow where if this job fails
run this job, if this fail succeeds, run this job.
So it's very easy for us to create
kind of more complex workflows with very easy,
simple playbooks.
So I can take playbooks and reuse them.
In this case, this playbook is actually the exact same,
it just has a different region running on each of them.
So rather than having one playbook run on all regions,
I have a simple playbook that I just run in parallel
in the workflows.
And I can click in here and actually see the output as well.
And I can download the output if I want to
to my local computer.
And it says there's zero AWS instances
with no tags on this region.
And it says there's nothing that breaks the rules.
If it did, it would run this next task that it skipped
which it would turn them off,
mark them and can even have it notify me in Slack
or ITSM tool like ServiceNow.
I'm gonna go over to inventories now
and show what public cloud inventories can look like.
So I can jump into the inventory,
I'm gonna look at sources.
So I can actually combine multiple public clouds
into a single source and then run playbooks on them.
So even if I had rail eight and rail nine servers
running in Azure and Google Cloud and AWS,
I can run the same playbook on all of them simultaneously.
In this case, I just wanna look at the AWS source
to see what one of them would look like.
I'm gonna click edit.
And you see I just need to assign it a credential.
Same credentials you would use for any tool
that's talking to public cloud.
And then in this case I'm just filtering by a region
and then I'm grabbing some key value pairs from the region
so that they show up into Ansible Automation Platform
are really easy to understand.
So I'm gonna go back to sources.
I'm gonna click sync, little sync button,
and then I can go over to the host window.
And I can see anything that I would see in the
EC2 web console for AWS will show up
into Ansible Automation Platform as inventory.
And in this case, I don't even need a job template.
I can actually just select some of these
and then I can say run command.
And then I can choose a module right from a dropdown.
So whether I wanna run an arbitrary ad hoc command
with commander shell, install an app with YUM,
turn off a service like HTTPD or NGINX,
or simply grab facts with the setup module
and get a bunch of different facts to look at
and create something like dynamic documentation.
So I just create what I call like a cloud report.
A lot of the clouds today,
I'm just gonna go ahead and kick this off.
They have a problem where they lock us into
a single pane per region.
So if I log into AWS EC2, I'm locked into US East 1
or US East 2.
And if I wanna see instances in the west
I flip my context, I flip to that.
So it's very hard to get a global footprint
just from the default dashboards,
but you can also use automation
in a really easy way to be able to look
at a 10,000 foot view of your cloud footprint
across all regions or even multiple clouds
if you set it up that way.
So I don't have to be tied to one cloud
or one pane of glass.
I can actually look at my whole footprint
and get an idea of where things are running.
So here's some dynamic documentation.
In this case I created some HTML
where I just took those key value pairs
that structured data from the Ansible modules
and I just templated it up a very simple website.
In this case, you can see immediately
that now I have a way to look at multiple regions at once
on my AWS cloud, even see what I used on Ansible,
what version of Ansible what version of Python,
what my control node is running.
More interestingly, as I know my team's not using
US East 2, I can click here, there's five instances running,
and there's even a missing name tag that's unspecified.
I need to go in and turn that off
and I can save my team immediately some money
because there's something running
that shouldn't be running in this case.
You can also see, I know we use US East 1,
I can go in here and see like, oh, there's a bunch of VPCs.
Think virtual networks set up that are empty.
And one of the things that I hate within my organization
is people try to spin up something,
like I have a demo or I have a customer
conversation in an hour,
or I need to set up a new application for my boss.
And then there's no VPC resources
but they don't wanna turn off anything
'cause they don't know who's using what.
This allows us to be more proactive
and resources back into the pool
so that you don't hit limits within your public cloud.
And it doesn't matter if it's subnets, instances,
types of instances, whatever it is,
it's a way for you to kind of get proactive.
And again, this is a read only task
so I'm not actually doing anything here,
it's just helping me get context
and understand the footprint.
We call this kind of cloud visibility
as it's just a easy way to look at things
and get another view print.
I hope this gives you an idea
of the incredible business value
of Ansible Automation Platform
and how it can help share knowledge, expand teams,
fill skill gaps.
And free up automation experts to focus
on higher level tasks or even take a well deserved vacation.
(upbeat music)