MARTIN OMANDER: Roger,
I'm a big believer in infrastructure as code. All settings for
my system should be in files that are
checked into source control. ROGER MARTINEZ: Yeah,
that way you always know what's running in your
production environment. Many developers use
Terraform for that. MARTIN OMANDER: Right. But Terraform is not
right for everyone. I've heard that we can do
declarative deployments in Cloud Run without Terraform. ROGER MARTINEZ: We sure can. Let's take a closer look. [MUSIC PLAYING] The first thing we'll
need is somewhere to store application image. For that, we can use
Artifact Registry. MARTIN OMANDER: And this is
similar to Container Registry, right? ROGER MARTINEZ: Yeah,
Artifact Registry provides a single location
for storing and managing different Docker
container images. It's like Container Registry,
except with a couple of extra bells and whistles. MARTIN OMANDER: All right. Let me set it up
now in my project. And from the navigation under
CICD, I find Artifact Registry. I'll click on Create Repository. I'll give it a name,
my serverless app. I'll choose Docker. I'll choose region, us-central1,
and actually create. ROGER MARTINEZ:
Once that's done, we can submit the first
build of our application. MARTIN OMANDER: And our regular
viewers will be familiar with the command I have here
in build-container.sh, gcloud builds submit. And this part of
the URL here means that the built container goes
into the Artifact Registry. ROGER MARTINEZ: Now
that it's finished, we can head over to the Cloud
Console and see our build. And there it is. MARTIN OMANDER:
Let's add a tag to it to make it easier to
reference later on. ROGER MARTINEZ: All right, next
let's deploy it to Cloud Run. MARTIN OMANDER: And
once again, this is a familiar command,
gcloud run deploy. ROGER MARTINEZ: Let's see what
that looks like in the Console. If you click the service on this
list, you can see the progress. Click the Revisions tab for
more info on the revision that's currently being created. MARTIN OMANDER: It's all done. Let's see if it's
up and running. Hello, London! It's working, Roger! I see that our service
here has one revision. There can be many. What exactly is a
revision, Roger? ROGER MARTINEZ: Well, when
you deploy a new container image to Cloud Run or change
the configuration of an existing service, an immutable
revision is created. The revision includes what
container image the service should use and
any configurations that you specify,
like defining values for your services
environment variables. MARTIN OMANDER: Funny you
should say that, Roger. And the Cloud Run
service we deployed does display the value of the
city environment variable. And here it is in the code. And that's what we
saw a minute ago when we hit the services URL. Now I'll change it
in the Cloud Console. I'll click Edit and
Deploy New Version. Then scroll down to the
environment variables. I'll change the city
variable here to Munich. And I'll hit Deploy. ROGER MARTINEZ:
And there it goes. It's deploying a new revision. The revision name by default
will be auto generated and start with the service name. Once it's finished deploying,
100% of our traffic will be directed towards
the latest revision. MARTIN OMANDER: I see. Now that was pretty easy. But it doesn't
seem very practical if I wanted to automate this
process when I make updates to my application. ROGER MARTINEZ: That's right. That's where Cloud
Run YAML configuration can come in handy. Let's jump back into our code. By using a YAML file
for our configuration, it lets us manage our Cloud
Run service declaratively. MARTIN OMANDER: Declaratively? That sounds like
infrastructure as code. ROGER MARTINEZ: Yep. So instead of making
lots of manual changes, the YAML file just
describes what the service should look like. MARTIN OMANDER: Aha. But I've heard that some
folks use Terraform for that. ROGER MARTINEZ:
It's the same idea. If you're using Terraform,
stick with that. If not, this could do the trick. MARTIN OMANDER: Right. I shot a few Terraform videos. I'll include the
links to them below. But regardless of whether I'm
using Terraform or this YAML, the idea is that we can check
this file into source control, right? ROGER MARTINEZ: Yeah. And that's always much
better than having it in a batch script sitting on
a workstation under your desk. This is a very basic
YAML configuration for a Cloud Run service. And it will work just fine. If we wanted to
deploy a new service. Since we've already
deployed our service, let's retrieve the
existing YAML for it. I sent you the
command to do that. Did you get it? MARTIN OMANDER: All
right, running it now. It looks like I got
a YAML file here. Let's open it. ROGER MARTINEZ: As
you can see, it's a little more than just a basic
file that we just looked at. Check out the image
under the specs section. That's the container image
for a current revision. And remember that environment
variable we updated? That's there in the
spec section under env. MARTIN OMANDER: So
what would I have to do here to say hello
to Sydney, instead? ROGER MARTINEZ: Easy. Just update the value to Sydney. But since we're
changing that value, it's going to be a new revision. So we'll need a
new revision name. MARTIN OMANDER: Ah. And what kind of a name should
I use for this new revision? ROGER MARTINEZ: Well,
it can be anything. But remember, it has to
start with the service name. We can also leave that
line out, and Cloud Run will generate a
revision name for us. If there are no changes
to the configuration, though, it won't
create a new revision. MARTIN OMANDER: OK. I will take that line
out and let Google pick a name for the next revision. Now how do I use this YAML file
to update my Cloud Run service? ROGER MARTINEZ: The
command you'll use is gcloud run services replace
followed by the YAML file that you're going to use. This is a different
command than the one we use to deploy a Cloud Run service. MARTIN OMANDER: Got it. I wrote that up in a
shell script here-- running it now. It finished applying the YAML. I'll go to the
services URL here. And it says Hello Sydney,
just like we expect. ROGER MARTINEZ: We didn't
deploy any new code. But we did deploy
new settings of value for the environment variable. Revisions are immutable. So if either code or settings
change, we get a new revision. MARTIN OMANDER: Hey, I noticed
that 100% of our traffic is being sent to our
latest revision here. I know I can change my traffic
settings here in the Console. How about in my YAML file? ROGER MARTINEZ: You can do that
by adding a couple of lines. First, you'll need the
name of the revisions that you want to use. Then in the YAML
configuration, we'll add an entry to
the traffic block. MARTIN OMANDER: OK. I'll make this a 20/80
split between our latest revision, Hello Sydney,
and the revision before that, Hello Munich. And this is useful if I want
to make a Canary release. Only some of my users will get
the latest new Hello Sydney version. And if there's a bug, not all
of my users are exposed to it. ROGER MARTINEZ:
That's exactly right. Now if that looks right to
you, we can deploy the update the same way we did before, with
gcloud run services replace. MARTIN OMANDER: And there it is. Now our traffic is split
between this latest revision and the previous one. And if I refresh the
page in my browser here, I will see Hello
Munich most of the time and Hello Sydney
some of the time. So let's say this Canary
release, Hello Sydney, contained a bug, and
we want to roll back, so users get the old
Hello Munich version 100% of the time. How would we do that? ROGER MARTINEZ: We
can do that two ways. First, we can simply
update the traffic section so that 0% is going to
our broken revision. Or we can rerun
gcloud run replace with a YAML that excludes
the traffic split and deploys our
earlier revision. MARTIN OMANDER: OK. I will update the
traffic split here. Instead of 20/80, I
will make it 0/100. And then I'll run it again. ROGER MARTINEZ: Very good. Now let's check if it worked. MARTIN OMANDER: Yep. If I refresh my
browser window here, I get Hello Munich every time. All right, Roger,
so far, we've only updated the configuration for
our Cloud Run service, not the actual code. Let's say I want the service to
say Bonjour City Name instead like this. What would the YAML look like
for deploying this new code? ROGER MARTINEZ:
First, you would need to build a new container image. MARTIN OMANDER: All right. I'm running gcloud
builds submit now. ROGER MARTINEZ: Now that
we have a new build, we should go to the Artifact
Registry and check it out. There's our new build. It's tagged latest
and created just now. In order to
reference this build, we can use the latest
tag that it already has or give it a new
tag and use that. MARTIN OMANDER: OK. So we can update our deployment
by updating the container image URL to include that tag. ROGER MARTINEZ: Exactly. We'll update the YAML file
again, except this time, updating the line for image
name under the template spec. There, you'll include the
tag for the new build. Another alternative is to use
images sha256 digest instead of the tag. That's another way to
reference a particular build. MARTIN OMANDER:
Is there anything else we should change
in this YAML file? ROGER MARTINEZ: Before
we deploy this change, we should also adjust
the traffic again. With this change, a new
revision will be created. So the revision indicated
by latestRevision will change to Bonjour. MARTIN OMANDER: Ah, right. I will delete this
so the new version get 100% of the traffic. And next, I'll apply the YAML. ROGER MARTINEZ: Looks good. Now when we check out
the Console again, we'll have 100% of traffic
going to our newest revision that we just deployed. MARTIN OMANDER: And
it's working great. We've seen how YAML files can
be used to describe and deploy Cloud Run services. To recap, why is
that useful, Roger? ROGER MARTINEZ: If you keep that
YAML file in source control, you always know what the latest
settings are for your service. And you can rerun
them at any time. When things change and
you deploy a new revision of your Cloud Run service,
you update the YAML file in your repo. It's very clear what
it's currently running in your production environment. MARTIN OMANDER:
Very nice, Roger. Let's say, someone
watching this video wants to start using declarative
Cloud Run deployments with YAML. Where would they start? ROGER MARTINEZ: Check out the
source repo for this episode. If you already have
a Cloud Run service, you can just run gcloud
run services describe. And that will give you the
current configuration in YAML. MARTIN OMANDER: Thank you for
guiding us through this, Roger. And thank you,
everyone, for watching. You will find links to
the code we talked about in the show notes. If you have any
questions for Roger or me or suggestions for
future serverless topics, please enter them in
the comments below. We read every single comment. Until next time. [MUSIC PLAYING]
