RAVI CHINTALAPUDI:
Big hello and welcome, everyone to the Session CMP 103. This session is about how do you
manage large fleets of Google Cloud compute engine VMs. And I'm Ravi Chintalapudi,
a product manager in Google Cloud. And today, I'll walk you
through a few solutions what we are building to address all
of our customer challenges, what we have heard
from you all, when managing large fleets
of compute engine VMs. I'll start with
the very high level all of the different
problems, what we have heard from you all-- an aggregated way,
summarized way there. And then we'll
talk about what are the solutions we are building
to go address those challenges. In that, specifically,
I'll drill down on patch management,
configuration management. I'll also give you a
background on why we chose this and how we're going to go
progress and make our roadmap. Going with demos--
deep dive into demos and wrapping up with a roadmap. I understand you'll be
listening to a lot of sessions in Google [INAUDIBLE] next. So there'll be a lot of data. It's very hard to
remember everything. But there is one key takeaway. If there's one thing I want you
to remember from this session, that is this. GCP now provides automated
patch management service, configuration management service
across Windows and Linux, across your Linux
distros, across your hybrid environments. Obviously, we
prioritize GCP first, but things to come up
in the near future. With that, I'll get started. So as I said, I'll
start with what are the top challenges,
what we have heard from you all, when managing
your large VM fleet. Then we'll talking about
how are we addressing that. In the interest of time, I'll
talk about only a few of them. The first one I'll start with-- as more and more
customers starts migrating their applications,
building their applications in GCP, they're often
dealing with thousands of applications, 10 thousands
of VMs, petabytes of storage. So managing this large
infrastructure at scale easily and
effectively has become a big burden for our customers. Second thing is most
of our customers are used to some
management tools when managing their
on-prem tools, their on-prem infrastructure. So as they make the
journey to the cloud, they expect the cloud
providers, like GCP, to provide some
native management tools because either those
existing tools are not compatible with the one
that's running in the cloud, or they might be working
with only specific cloud. Third big problem
what we have seen is mostly from a
security standpoint. Think of a scenarios
where we had Wannacry, Meltdown, Spectre. When in any of these
vulnerabilities hit, the biggest thing on
an IT admin's mind is, is my environment compliant? How bad is that? How can I bring it back
to the compliant state? Are all my VMs in a
desired configuration? Which of them drifted, why
it drifted, how it drifted. It's a lot. So managing security at a
scale is another big problem. Well, these are just
some of the problems talking of what we have heard
from a lot of our customers. In the interest of
time, I picked up the top thing what we heard. So what did really do after
hearing all these problems? So we started with building a
suite of VM management tools. In that, we prioritized
patch and config, keeping security and
compliance as the top view-- top priority for us. So over the next 15
minutes, 20 minutes, I'll walk you through each of the
solutions, and how we build it, and how can you use, how can you
observe it, and with the demos. I'll start with
patch management. Patching servers is
not something new. Many of our customers
tell you, oh, no, we've been patching servers
for years and years. But still it is one of the
top IT management problems. So we're really curious to know
why it was such a big pain. So we started talking to
about 100+ customers across the globe, across
the industries. Average size was ranging
from 500 to 20,000, showing that we have
covered SMBs and even the enterprise thing there. And here's a quick summary. First thing is, a
patch Tuesday comes. We know it happens on the
second Tuesday of every month. The biggest thing on IT admin's
mind, especially the patch admin mind is what's the
state of my compliance, how compliant I am, how bad. I am. And this thing I want is a
report across my environment, across my feet,
whether I'm running Windows or Linux or
different Linux distros, I want one report unified
across my environment, so I can see the state. Second big thing
what we have heard is reliability of patches
what does this really mean? As I was talking to
many of the customers, one thing is super clear. Most of them are patching
in a phased rollout. So they always start with
their dev environment first. That goes fine. They go to staging,
then pro-prod to prod. They do this because
they're worried that a particular
patch or a package might create some
incompatibilities, might break their
existing applications. So they're trying to hope
to find any of the issues throughout this phased rollout,
so that they'll find something, and they can fix
it before applying to the next environment. Third big category what
we have seen in general orchestrated patching--
what does this really mean? Most of our admins said they
spend nights and weekends only when they're doing
patching applications, primarily when
patching applications. Their reason for that is they
have to do a bunch of things before. They have to do a
bunch of things later. For example, before
patching, they have to make sure
everything's working fine. The health checks are there. The agents are running. Users are hydrated. Load balance are taken care of. There's enough space. Right after patching
is done, they want to make sure their
applications are running. They will do the health
checks, services check. And that's way they make
sure that they always do it in the
maintenance windows, like on a Friday
night, Saturday night, and they spend a lot of time
to making sure that everything is up and running. And there is sequencing. They want to go automate
these processes. When something goes
fine, automatically roll out the next environment. When the dev environment
goes fine, go to stage. So automatically rollout. Something goes wrong, stop. The other big thing is
application-aware patching. So as I said, application is
a key thing for any company. And when they're
patching an application, they really want to understand
the application architecture. So think if you're patching
an end tier application. You always want to go
do a back-end first or your databases
first then back-end. So you do a right
order and everything. So understanding the
application infrastructure, having a knowledge of
that is super important. The last thing is,
as I talked earlier, patching's not something new. Our customers have been
patching for years. So there are a lot
of existing tools. So anything we build has to
make sure that it at least integrates or provides some
value on top of an existing patch management tools. So after listening to all these
problems and reprioritizing we came up with
a solution, where our vision is we want
to go help our customers patch any OS anywhere. Any OS could be
Windows or Linux. They could be running
in GCP on GCP. But our priority is
right now running in GCP. We launched GA in
April this year. So that's the General Available. You all can go use it. However, the scope is at GCP. Both will do Windows and Linux. What's a big value prop? As a customer, why
should I use this? Just two main value props
you think about this. One is, like, I get a
compliance reporting across my environments-- across
Windows and Linux and GCP-- telling you what's bad,
how bad it is that. Second thing is automated
patch deployment. Ability to go fix that
problematic [INAUDIBLE] and bring it back
to the compliance. And I'm going to go detailed
into each of this stuff there. So let's start double-clicking
on what is patch compliance. So as I said, when patch Tuesday
comes or any new packages get released from the
repo-managers, one of the key thing for patch admin
is give me a compliance report across Windows and Linux. So with our thing,
you got a dashboard. As you can see on
the screen, you can get a view of which
part of my environment is green, which part of
my environment is red, which part of it is bad,
along with additional data. 'Cause when I just
show you a patch, compliance is not enough. I want to know what's
causing me to read that red. What type of patches I am
missing, how many patches I'm missing, how long
I've been missing because there's an action
item for each of this. if I'm running a company.
and I see everything red, that's a show stopper to me. I'm going to stop
and go fix that. If everything is-- most of them
are green, but somewhat yellow, probably time for me to take
a weekend off, and come back and fix it on the
next business day. So that's one big
aspect of getting the compliance of
your environment with the detailed metadata. Second big thing
I want to call out is we tried our best
to leverage native tools, native configuration
rather than agreeing to using a lot of neutrals. Yes, we do have our own agent
which actually does the job. But we actually go talk
to the native Windows agent, called Windows
Update Agent or MU when we are patching. For Linux, we talk to
the native repositories like YUM, apt-get, the
repo-managers, and everything. And we leverage to whatever
configuration you have, whether you're talking
to Microsoft update, whether you're talking
to [INAUDIBLE],, or whether you're
talking to repositories, the key thing is
we're leveraging most of the native tools
and config where we can. The last thing is on the
supported operating systems. For Windows, we
support 2012 and above. And Linux we do Red Hat and
[INAUDIBLE] 6, 7, 8 versions, Ubuntu 16, 18, and Debian. In our documentation,
there's a clear supported operating systems link. That will be constantly
upgraded when we add new operating systems. So that's the first part. As an admin, I get the
state of my environment, getting which one is
good, which one is bad. But the next important
thing for them is how do I bring in
back to the green state. That's my desired state. How do I bring it back,
everything to green? How do I automate this
process so that I don't have to worry about everything? And that's where the patch
deployment comes after you're knowing the compliant state. When you're patching
machines or your environment, the four important questions
come to any patch admin. First thing is-- what
VMs should I patch? Should I patch at my
application level? Should I patch at my project
level, GCP project or a zone level, or a particular
region level? So we provide you all the
flexible targeting options. You could choose to patch all
web servers because that's how you labeled it. Or you could patch all
my dev environment. So you have all the
flexible filters you can choose the
way you want, which I'll be demoing in a few
minutes when I go there. Second big important
question an admin will as is what type
of patch is installed? So first one is what VMs. That's great. Second-- what type of
patches I want to install. Should I install critical,
security, are others? Because, as I said, every
company have different SLS. That's what we've heard. Windows is 30 days
saved, for example. The next could be
60 days, 90 days. So every company differs. But on average, every company
have different SLS to go patch. So it depends on the type of
patches you want to go select. You need to have an option
to select type of patches. That's the patch configuration
I'm talking about. A couple of key
things to hit here-- patch exclusion. And many times when you
have a particular patch, it might break some of your
line-of-business applications, or there could be some
incompatibility issues. So you might want to
exclude certain patches because you know that's
going to break something. So there's a patch
exclusion capability where you can specify a KB
article or a wildcard in Linux like [INAUDIBLE] kernel
if you really wanted to install kernel patches. There's a patch exclusion. Similarly, there
is patch inclusion. Think of a scenario where
you've got a security patch, and you want that to roll out
to your environment immediately. And you just put that patch. Include only this patch and
roll out all my environment. So that's the patch
inclusion capabilities. So the first question
was, what VMs to patch. Second thing was what
patches to apply. Third big question
comes to customers as, like, when should I patch? Patching is not
a one-time thing. I'll be doing regularly. I could be doing,
like, first day of the month, last
day of the month, the last Friday of the months. So we provide all
those flexible options. You can do now. You can one time. You can do regularly. And you can choose different
dates, times, weeks of the days, and everything. I'll go a lot more
details when I demo that. The last part of scheduling
is the maintenance window enforcement. Almost 90% of our
customers told me that they'll patch only
during a maintenance window as we see people do it typically
on the Friday nights, Saturday nights, or on the weekends. So they have a
maintenance window set, and they want to doing
the patch deployment only during that time. So in our product, you can
specify a window saying that, hey, start at 9:00 in
the night on a Friday, but run for only
for three hours. So we'll ensure that we run
only that three hours, including the reboot. And we finish out
what we are running. And we get out
off to process, so that you're app's up and
up and running and coming. After the key questions--
what VMs, what patches, went should I patch-- the last
important thing is controls, what additional
controls I would need. I talked about a lot
of batch orchestration. That's one of the
top concerns what we have heard from our customers. One of the big thing is
ability to run pre-steps-- something before patch. It could be health
checks or disk space. And something to
run after the patch. So in our UI, you will be able
to select certain prescripts. This could be a script which
you upload to a Google cloud storage GCS pocket. And it'll pull up from
there and will run it. And it can also condition it. If the script fails, the
patch in deployment will stop. So you do not need having to
worry about, like, hey, have a messed up something there? The last part of the control was
one of the major feedback what we have heard from beta when
we released early this year was reboot control, especially when
you're patching applications. Even though we do a controlled
reboot, as a patch admin, I want to control my
reboot because it's my application running. So we don't reboot if the
user chooses this selection. It's a configuration option. We will not reboot. We will hand over the
control to the user. So after the patching
is done, they can come and control the
reboot per their needs. So that's about the two
value props I talked about. One is this
patch-compliant state, giving you the state
of environment, how-it-is-right-now snapshot. And the second
thing is the ability to go fix that and
automate this, so future you don't have to do it. Those are the two big value
props of patch management. Enough of me talking. I really want to show you how
the product looks in the UI. So in this
patch-management demo, I'm going to walk you
through three things. The first thing is
how do you onboard, navigate an onboard
patch management service. Second thing is, how do you
get the patch compliance. And third thing is how do
you or do a patch deployment, basically go fixing those
problematic machines and bringing it back
to this compliance. And you can automate
this process. OK, how do I navigate? So if I go to my Google Console,
go here, go to Compute Engine. And on the bottom, you can
see OS Patch Management. And this is the
screen what you will see, 'cause you have not
enabled the services. And you can see what APIs
we need, what permissions. we need. And if you click
on Learn More, it talks about whole
details about what is the service, how you can
enable it, how it works, what's architecture,
what does its agent do, what permissions--
all the details. Once you enable the service
and activate the agent, the OS config agent is part of
the most of the GC base image packages, except, I
think, Ubuntu and Suzy, which we are working
to add right now. But those things, you
have to do it separately. And we have a clear instructions
how to go install an agent, especially after if you
are using an older VMs, you have to follow the
instructions of how to go get this OS
configuration onto the VMs. So now we enable the services. In the interest of time,
I've already enabled it. I'll go to a project where I've
already enabled the service. So once you enable and activate,
we'll go scan all your VMs, collect the data
from all the sources, aggregate it, and
generate these reports. Let me walk you through
each of this stuff. The first tile talks
about all the VMs I have in my operating systems. Looks like I've got a thing 18
in this environment who have different operating systems. Looks like my Ubuntu is good. It's not missing any red. So I don't have a showstopper. I can move on. Looks like CentOS is bad. I've got all the different
categories I'm missing. I'm missing critical,
important, other, and a few are up to date. Similarly with Windows. And Red Hat is also bad. And if you want
to know more what are this type categories,
what does each one mean, if you click on this
particular link, it'll take your documentation. Let me just navigate there. So if you go to our
documentation page, it talks about the whole
charts what you see there and explaining what
each one means and how do we compute that. . All right, going back
to the dashboard. If I'm an admin and
looking at this, I really want to
know why is this bad. Let me know which VMs
are having problems and what sort of things
we already have this here. OK, so you can also click on the
VM instance page as well here. So you see the same thing. And here's where you'll see the
different VMs, what you have. Part of that is-- let me pick up the
[INAUDIBLE] CentOS VM it's having, and you can
see all the metadata here-- like what zone it is, what
OS distribution it's running, what OS version. And saying that it's
missing critical updates. When you click on
that, that's where it shows that, oh, I'm missing
a lot of updates in this. Three of them are critical. The other things are
security and other important, something for me
to take an action. So in upcoming releases, we
are adding a lot of metadata. I have to show you
a lot more data, like CB score, what repo
manager I can connect to, where do I get this patch--
it's a lot more information. In Windows we are adding
that key billings, the MSR facilities. We'll get a lot more metadata
in our upcoming releases. So that completes
the first part, where we have seen--
actually, two parts. First we have shown
about onboarding. We have seen how
to get the patch compliance in an environment
state of your environment. The third thing
is as an admin, I want to go fix this
problematic machines. I want to go create a deployment
so that it installs the patches and brings these VMs back
to the compliant state. So now I'm going to click
on Patch Deployment. So as I talked
earlier in the slide, there are four questions which
really matter for patch admins when you're doing a deployment. First is what VMs to patch. And we give a lot of flexibility
to choose different filtering mechanisms, whether we can
patch by a project, a zone-- I'm talking about a GCP
project zone, region. Or you an use labels,
tags, name prefixes. In this case, I'm using
same labels called A-- environment have all my
definitions I want to go patch. Or I can choose
to patch all VMs. OK, we've finished the first
question of what VMs to patch. Second important
question is what patches I want to install
because every customer will have different SLS
for different patches. I've seen most of the
customers have critical and security have to
be done within 30 days. If it is non-critical, they
have a little bit more time-- 45 days. there. So we give you all
the flexibility, so you can choose what
sort of patches you want. Like, for example,
critical security, that's the only
thing I care about. Patch exclusion-- so this one
I was talking about earlier. If you know that a
particular patch-- or KB in this thing--
it's going to break your line-of-business
application or some incompatibility
with a known thing, you can put that KB article, you
can put multiple KB articles, comma separated. We will exclude that
when you are installing the remaining patches there. In Linux, we can do,
like, kernel updates, or you can do wildcards. You can use any of
those stuff there. But other than critical
patch inclusion, you just want to install
selective updates. Microsoft released
a security patch, or they've got a separate
package from the next one that I want to install
that particular security package on my fleet right
now or as soon as possible. So you can include that
particular KB article, or the Linux, or
whatever the wildcard you are using to do that. Similarly, we do that same
thing for both Windows and Linux whether it's running YUM,
Red Hat, CentOS, or APT, you can choose your own
configuration and do that. So that finishes
the second question what we had-- number of VMs,
what type of VMs, what patches. Third question comes to patch
admins as when should I patch? Patching is not
something I do once. It's a recurring thing. So I need to give me all the
flexibilities to do it now, do it later. So for example, if I
choose End of the month to [INAUDIBLE] or I want to
be in a particular recurring schedule, like, I want to
do it on a specific day. I want to do it on a
fourth Friday of the month, or I can do second
Saturday of the month, second Tuesday of the month,
aligning patch Tuesday. So whatever means
you have, we provided flexible recurring
scheduling options. So you can choose
whatever is right for you. In my case, I'm going to
choose scheduled for later and doing end of the month. The other key thing to
talk about is duration. Almost every customer
confirmed that they're going to install
the patches only during the maintenance window. Typically happens on a Friday
night or on a weekend there. So they want to make sure that
the app is down at that time. No user is connected to that. So here, you can specify
a maintenance window, like a duration-- how long you want to
install the patches. If you on install
the patches, say, for 120 minutes,
that's only time we'll be installing the
patches, including the reboot. We'll take care of that. However, we'll finish
whatever the step is there. We'll not start
any new step there. The last thing which every
patch admin will care about is rebooting. By default, the
system will decide if the reboot is necessary
based on the metadata, what I'm getting from the
package or packages. But some admins, like, I want
to control my reboot, especially in patching. My application, I
want to make sure that this is actually working. I want to be in front of it. And I want to run some
presteps and poststeps. So we gave you that
options to choose never, so that you can control it. For now, I'll leave it
as a default system. Next, comes the pre
and post scripts. This is what I
was talking about. A lot of admins want
to run some things before to make sure
everything's working fine. They want to run a lot of things
after to make sure everything is working fine there. How do you do that? So you create your script,
upload your GCS packet-- Google Cloud Storage packet. In our documentation,
we explain how do you get that script
into the packet. Now I can go click on that. It opens up a GCS packet. And I can go select. Hey, I want to go do
this, my Linux prescript. And normally, you want
to do some postscript. You want to go select this,
and you want to go build this. Then you create your deployment. So let me show you what happens
if you create a deployment. For the interest of time, I've
already created a few things. That's where we go to
Schedule Deployments. So once you create a deployment,
you can actually see it here. Right now, we have an
option only to delete, recreate it if you want
to make any changes. But in the near future,
we'll be adding capabilities where you can edit. You want to add more machines. You want add in
the configuration. You want to change the date. You will be able to
do all the changes. Again, I created it. When the time triggers,
the patch deployment runs, and it'll give you a
detailed patch status. So let me show you
an example there. So I've run some patch jobs
last week, earlier this week. And it actually
shows all completed. But there are some others. So let me pick up a deployment
which had a lot of VMs, and it failed. So let me take this one which
has got 16 VMs, and it failed. First, it talks about
a number of incidents it has-- over 11 status. And something errors occurred. As an admin here, please
take an action here. Look into that. How long was the
duration wanted to run? It will give you
all the details. If anything was left in between. It was 100% done. And what classifications
you have selected gives all the details. Now this is the result state. If you look at in this state,
some are successful in that 16. Some failed because
there's no agent detected. Somewhere there was
configuration that was not running, or something happened. Somewhat inactive, which means
that the machine could be offline, or something happened. It's not running. So there could be
other state in there. Or the action failed because
of incorrect function for the batch. But here is a clear logs. If you click on any
of the logs, you can clearly see all the
details about this failure, why it failed, what time
it failed-- typical logs you get that stuff. And this is where you can
go to our stack driver logs to get a lot more details. OK, so that completes
the three parts I was talking about from patch-- how do you navigate an
onboard patch management, how to get the compliant
state of your environment, and finally, how
to deploy patches to install those patches so that
you bring that machines back into the compliance and set an
automated recurring deployment, so every time, it
takes care of that. Now let's talk about
the next service-- so on the configuration
management. There's another service
what we prioritize based on our customers need
and also keeping compliance in mind. So let's start with what
are the top problems what we have heard with our
customers when we spoke to them. The first thing is, when you
go create your VM environment, you want that to be in
a certain desired state. Like, I want security agents. I want monitoring agents
to collect all the logs. I want open certain
firewalls, certain posts, certain accounts, or you want
to have certain software. So that's the first part. You define your
desired configuration. The second big thing is
how do I do deploys this to entire environment at scale? How do I deploy this at scale? Third big thing
is maintaining it. It's not about
deploying it one time. That's all good. But how do I ensure that
this is maintaining? I don't want any drifts. Whenever there is a drift, as a
user, it I want to be notified. And, obviously, I want
to auto-fix it later stage once I get a context. But at the minimum, I want to
be notified if there is a drift. What drifted Who caused drift? What happened? Why it was drift. How long it's been drifted. So you need to know
all those details, what we call a complianced
reporting, from a configuration standpoint. The other big thing they'll
ask in a unified way, whether I'm bootstrapping
or installing a Google first-party software
or a third-party software, I need a unified way. The other big thing what we
have heard from our customers how do we integrate with
existing CICD tools? For example, most
of our customers use different
third-party CICD tools, like whether it's Jenkins,
Packard, Spinnaker-- any that they have their
own tools there. They use our tools to
go create the packages. And key thing is they
want to take that package and deploying to that
environment at scale and maintain it. So these are some
of the problems. To solve some of
the problems, we started creating
configuration management, where our value prop is
going to be three things-- define, deploy, and maintain. So what does it mean? We'll help you to define
your configuration file. Second step is we'll help
you to deploy at scale, your entire environment. The same sort of filters
what I taught earlier in patch management, where you
can do it at a project level, at a region level,
at a zone level, or a different instance level
what I talked about-- basically giving a lot of
flexible options, so that you can choose how
you want to deploy that. Going to give you a nice
compliance dashboard across Windows and Linux. They'll be similar to what
we have done with the patch. And with a lot of
additional data, as a user you know which machines are in
the compliance, which machines went out of the
compliance, what caused it to go out of the compliance,
when it actually drifted. So you get a lot
more details on that. So let me walk you through
how the product works. From a user standpoint,
when you have to go start
configuration management, there are two things
you think about. One is I'm creating
my desired config. There's a thing called that
as simple YAML file, where you define your
desired config installs a particular monitoring agent,
installs security agent, open this firewall. So you define all that stuff. We call that as a guest
policy in our terms because you're applying
a policy to the guest VM. Second big step
is take the policy and apply what we call
assignment to the bunch of VMs. So let me double-click
on each of the stuff. Guest policy-- when I'm defining
my policy or the configuration, you might want to say what
packages you want to install. All this is part of
the guest policy. For example, in this example,
took an example of it. I want to install
a Stack driver, and I want that to
be always installed. My desired state is
always to be installed, as you can see in the screen. So in the same guest
policy, now you define where do I get this
package binaries from. I want to install Stack driver. That's great. But go pull it out
from this, the order or what I've given here--
packages.cloud.com. Third part of policy would
be if a particular software needs any configuration. For example, in this
case, it's an MSI. I want to do it
in a certain way. And if you have other
configuration, like, I want to do like
silent install. So whatever configuration you
have, you can put it there. So think of, like, guest policy. Open up a notepad, or open
up any of the editors, create file, put
what package you want to install, where do you
want to get binaries from, put any configuration. And the next step
is, boom, take that and apply to a bunch of VMs. Now let me walk you
through how that happens in Pantheon console. This is Google Cloud console. So in this configuration
management demo, just like patch management,
I'll talk about three things. One is how do you onboard out
of the configuration management, how to use the service, and
next is how do you get this-- creating a policy,
applying the policy. I'll show you some of the
key cloud commands, then assignment. The first thing is onboarding. So if you have onboarded the
patch management service, what I've showed earlier, that will
enable all our OS config APIs. So you're all taken care of. And you'll have everything done. You'll also have the
G-cloud commands. You can start using it. When we launched the
config management beta and the first half of
the year, it's API only. So we are building the UI,
the user experience there. So the API is already enabled. But in a scenario
where if you want to use only config
management-- so go to the same compute engine,
or you can go to API services. And just type OS config API. And you'll see a screen
just like this, where there will be an Enable button. In this case, I've
already enabled, so I'm showing
Disable button there. So once you enable
it, it's the same API which powers both patch
management, configuration management, other
services, [INAUDIBLE].. But links to think of
this as a common API layer where you can access that. That's the first part of
creating the configuration part. Second step as I talked
about last lecture, first thing is about
how do I create my guest policy, which is my
desired configuration there. So just start with any editor,
whatever you have, and start drafting your AML file-- what package do you
want to install, what configuration do
you want, where do you get the repo manager there. Or you can take any
from other examples. So if you go to our
configuration recourse link-- and I've added all
of these things in the later parts of the
slide, so you can actually look at that stuff. But if you go to
Google Compute Engine and take configuration
management, setting up config, you can see all
those examples here. In this we have provided
a lot of examples, like, how to install a
stack driver agent, how to install other things there. So there's a lot of
examples you can see-- what state do you want, how
do you do an assignment, where you want to keep it-- it's lot of examples. Then it talks about how
to create a guest policy. So there is a simple
G-Cloud command, what we use to go
create a policy, so that it brings
into the system. So for my demo, in
the interest of time, I've already created the
policies and everything and got to the system. So first thing I'll start
with a simple view of show me all the policies
I have in my environment. So let me increase
the size a little bit, so you can actually see better. So G-Cloud-- that's a beta
because that OS Configuration Manager is beta. Then you'd have covered OS
config and guest policies list. Hit that. I think I've done two policies. I should see both the policies. One is a stack driver policy
and the Windows policy. Second thing, is I want
to know what exactly is in that stack driver policy. So I want to say, again, G-Cloud
beat OS config guest policy. I want to say describe. And all the examples, the
G-Cloud examples and everything are in our documentation, so you
can find out all the samples, which G-cloud to run when. Click on it. It will actually
show the sample. In this case, I'm installing
a stack driver agent. If we go up, it talks
about where am I pulling the packages from. It'll talk about some
labels here, as we can see, so which means that any
VM just got a label called color is it called red-- that's where we'll
apply this VM. So next time we create
a new VM, put a label. This configuration will
be automatically applied. And you can put some
policy assignments there. In the interest of
time, I took the policy and applied to a few VMs. Let me see how many
VMs I got applied to. So you want to see,
like, guest policies. You want to see describe. And again, I also want to
know what's been installed and everything there. So let me show that one
as well very quickly. Another command for
this is G-Cloud command. And this is actually saying
G-Cloud compute instance OS inventory list instances. So instance which as
got described as agent. So you can actually
see that stuff. All instances is what I
have in that stuff. there. So I've got two
machines which have got this particular stack
driver agent installed. So that completes configuration
management demo where we talked about how do
you onboard the service, how do you create the
compliance, your desired configuration guest
policy, how do you apply that on your things,
and, again, how can you verify that stuff there. Cool. Let me go back to the slides. So the key thing
is about roadmap. So as I said, we launched
GA patch management in April, the first
half of the year, same time as we launched
configuration management. So the rest of the year,
second half of 2020, we will be launching
multiple versions of OS patch management, where we'll be
doing incremental updates, improvements. Some of the things could
be really simplifying their onboarding experience. Applying a lot of
customer feedback and getting a lot of
feedback from our customers Thank you so much for that. Really appreciate your feedback. And also adding a lot
of compliance data, so making the whole
experience very smooth. And the documentation,
when we launch it, will provide clear
details about what's coming in each of the launches. You'll have way more
details on what's coming in each of the stuff there. As far as configuration
management, we launched the beta in
the first half of it. And that's API only,
as I talked earlier. Now we'll be building UI on top
of her-- the user experience, a lot more other
capabilities, which we are targeting configuration
management preview by close to the end of the year. OK, that brings up another
important topic-- pricing-- this being one of the
topmost concerns questions. I have been asked from
my customers there. So briefly a few
key things here-- this pricing, what
we're talking about is for both patch and
configuration management-- so both the services. There's no cost from now
until end of the year. So you don't have to
pay there anything until the end of the year. Starting Jan 2021, we'll
be charging per node, which like per VM per month-- of course, pro-rated
and hourly rate. Key thing is-- there's no
cost for the first 100 VMs. After the additional
ones, that have 101 VM. If the OS config agent is
running, and conversely sending the data, and doing
something, that's where you will be charged. We'll charge the rate
of $0.03 per hour. So if you keep this just for a
math, if you keep this running OS agent continuously
24 by 7, 30 days, you pay $2 per node per month
for both config and YUM. I put a link here that
gives you complete details in our documentation about what
does OS config agent running mean, what sort of things
I can do, I cannot do, how I'm getting charged-- a lot more details on that. OK, moving on--
so in this slide, having cleared a
lot of resources. So if you're getting
started with how to do patch management,
what's our architecture, and how does this
thing works, and I put a links for detail--
how to create a bad job, how do you manage a bad job. Same thing with configuration
management policies-- how do you manage these
policies there? Along with SDK links, API links. It's the same thing what
I showed you earlier, just that we have a full
link to the full page, where you can see all the
details about the supported operating systems,
how to get started and everything, including
some of our blog links. I'd like to make
one announcement. You must have already heard
about Active Assist, which is a new solution
to reduce the cloud complexity by providing some
proactive and intelligent features. And it doesn't
matter what you're running-- compute, storage,
security, billing, cost. So there are features
in every area which helps you with how to
reduce the cloud complexities. In the below links, you'll
have a more details than this. I'm happy to say patch and
configuration management are also part of Active Assist. OK, moving on-- key takeaway. So I know I've covered
a lot of content, like, demos and everything, and it's
hard to remember everything. But if there is one thing, the
key takeaway, that you take out of the session, this is this-- GCP now provides an automated
patch and configuration management tools
across your fleet, across your Windows and Linux,
across your Linus distros. With that, we'll wrap up. Thank you so much for
everyone for your time today and going through the session. And, especially, thanks
to all the customers who have given a lot of
product feedback and make us help better the product
than where it is right now. I continue to request that. Please go play with the product. Give us more and more
feedback to make it better. Thank you.
