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]