[ROCK MUSIC]
[PHONE BUZZING]
TOM MELENDEZ: Eh, I'll get to that later.
[THEME MUSIC]
Good morning, folks.
OK, adjust that for your time of day, I suppose.
Hi.
I'm Tom Melendez.
And this is next in a series of short videos
showing you how you can use Ansible with Google Cloud
Platform.
If you saw our first couple of videos,
you'll recall the theme of these videos
is that I'm a DevOps engineer using
Ansible to manage infrastructure for our satellite imagery
project.
Earlier, I received a text letting
me know about an unexpected traffic surge on our imagery
website.
But we're autoscaling with Google Cloud Platform,
so I could keep playing my game.
Dylan Silva is here from Red Hat again,
joining me to talk about how we're using Ansible
to manage our infrastructure.
DYLAN SILVA: Hi, all.
Tom, thanks for having me again.
Can you describe the setup?
And then I'll be happy to walk us
through the Ansible playbooks, like we did the last time.
TOM MELENDEZ: Sure.
Google Compute Engine not only has
VMs, like we saw in the last video,
but it also has lots of networking capabilities.
In this video, we'll walk through how
we're using GCE's HTTP load balancer
to create a globally accessible, cross-region,
auto-scaling website running on managed VMs,
all provisioned with the Ansible.
I'm going to kick off the provisioning process,
and then hand it over to Dylan to walk us
through these Ansible playbooks.
You can watch our first video if you need tips
on setting up Google Cloud Platform or Ansible.
DYLAN SILVA: OK, so while that's running,
let's take a look at some of the playbooks, shall we?
TOM MELENDEZ: Sure.
Let me open it up.
DYLAN SILVA: All right.
So now that that's open, it looks
like we have a playbook that executes commands
from local hosts and includes some variables
from various files like last time.
TOM MELENDEZ: Right.
You can run this command from anywhere,
as long as you have the proper credentials.
DYLAN SILVA: OK, cool.
So first, we're creating a couple of managed instance
groups.
We set the name and zone, as well as the starting size,
and we're also setting the instance
template that should be used in building these new instances.
And then it looks like the managed instance
group, also where you configure the auto-scaling policy,
is here as well.
TOM MELENDEZ: Yes.
DYLAN SILVA: OK, so that's one of the greatest features
that I think are there about scaling applications
with Google Cloud Platform.
Can you tell us a little bit more
about auto-scaling and depth?
TOM MELENDEZ: OK.
Well, with auto-scaling, you can have
your host scale up or down, based
on a policy you configure.
The policy can be based on things like CPU utilization
or what fraction of the load balancer utilization
the instance group should handle.
You can even define policies using custom metrics,
if those don't suit you.
DYLAN SILVA: And details are in documentation, right?
TOM MELENDEZ: Right.
To keep it simple, we went with CPU utilization.
This policy basically reads, "scale accordingly
to keep the CPU utilization on the machines under 80%."
DYLAN SILVA: And that's it?
GCP will scale up those instances for you?
TOM MELENDEZ: Yes, to the max number
of instances that you specify.
DYLAN SILVA: That's great.
So I see we specified two managed instance groups here
with basically the same configuration.
TOM MELENDEZ: Very true.
We wanted to be explicit here, but one
might consider using a looping construct, like
with items or with [? depth. ?]
DYLAN SILVA: And then finally, for our managed instance group,
we have [? name and ?] port specified.
TOM MELENDEZ: Yes.
Those are where the backend service
will send the traffic to.
DYLAN SILVA: Great segue.
So let's talk about backend services.
What is a backend service for?
TOM MELENDEZ: Basically, a backend service
is a collection of interest groups.
The backend service lets the administrator
treat all of these instance groups
as a single entity in terms of serving capability.
DYLAN SILVA: So what do you mean by that?
TOM MELENDEZ: Well, we've configured the managed instance
groups to scale up based on CPU previously.
But really, we haven't talked about how much traffic
we want them to handle.
By grouping these instance groups into a backend service,
We can set additional configuration, as well as
a health check on the whole entity.
DYLAN SILVA: And then you can have multiple backend services,
I imagine, right?
TOM MELENDEZ: Right.
This lets admins build out their desired infrastructure,
placing groups of instances where it makes sense for them,
and determining how much traffic they should handle.
DYLAN SILVA: Wow, this really seems super powerful.
TOM MELENDEZ: It is.
Another powerful and customizable feature
is the URL map, which we have up next.
DYLAN SILVA: So now it looks like all of the configuration
here is pretty minimal.
It looks like just giving it a name
and handling the backend service that we created.
What is URL map for anyways?
TOM MELENDEZ: You're right.
In this case, and for many applications,
a simple configuration, such as this, is fine.
In essence, the URL map maps the URL to a backend service.
We don't do it here, but you can route different paths
to different backend services.
DYLAN SILVA: So for our configuration,
this playbook is basically saying
map any URL to the default backend service, right?
TOM MELENDEZ: Right.
Next is a target proxy, which terminates the connection
from the client and routes the request to a URL map.
In this case, we're using an HTTP proxy.
DYLAN SILVA: So we could then change that to an HTTPS proxy
and then still use the same URL map though, right?
TOM MELENDEZ: Correct.
In that case, you would also specify the SSL cert,
in addition to a URL map.
DYLAN SILVA: And then finally, create a static IP
address and a forwarding rule.
TOM MELENDEZ: Right.
Up until this point, we've built out the load balancing
capability.
Now we're creating an IP address and mapping to the proxy.
DYLAN SILVA: Gotcha.
So when a client makes a request to this IP
address on that port, the proxy's going to handle it.
TOM MELENDEZ: Yep.
And that's the entire configuration for a global load
balanced web application.
DYLAN SILVA: So cool-- not a whole lot of configuration
then.
How'd the provisioning go?
TOM MELENDEZ: It was done a lot sooner than we were.
The load balancer was created successfully.
DYLAN SILVA: Great.
So how does this look in the web console?
TOM MELENDEZ: Let's take a look.
Opening up the dashboard, then we
click on Networking, then Load Balancing.
Let's click on the Advanced menu down at the bottom here,
which gives us the component breakdown that mirrors how
we built that up in Ansible.
We see the global forwarding rule and the IP
address it maps to.
Under Target Proxies, we see the proxy name, the type of proxy,
and the URL map to apply.
Clicking on Backend Services, we see our backend service.
Let's click on that.
DYLAN SILVA: Hey, cool-- traffic.
So we can see how much is being served out
of each instance group here.
TOM MELENDEZ: Right.
I generated this traffic with a Bash one-liner using
[? cURL-- ?] one instance in our east region, one in the west--
just to demonstrate the graphs.
Interesting note that the user can click right here
and adjust the settings if they like.
DYLAN SILVA: But of course, those
are going to be overwritten by the playbook the next time
because of the desired state of the system.
TOM MELENDEZ: Yep, of course.
Well, that's it-- another quick in-and-out video
showing Ansible and GCP.
Thanks, Dylan.
DYLAN SILVA: You're welcome, Tom.
Hey, it's been great showing viewers
how to use Ansible with Google Cloud Platform.
Are you up for another one?
TOM MELENDEZ: I sure am.
DYLAN SILVA: We've got more to show you, folks.
So we'll see you next time.
TOM MELENDEZ: And don't forget to check out
all of our Ansible modules at the URL in the description
below.
[THEME MUSIC]