[MUSIC PLAYING]
JEN PERSON: Welcome to "Getting Started
with Artifact Registry."
Today, I'll show you how to deploy a container stored
in an Artifact Registry repository
to Google Kubernetes Engine.
If you're new the Artifact Registry,
I recommend you check out the last episode
of "Getting Started" or the documentation
before proceeding.
With that in mind, let's walk through deploying to GKE.
Now there's a good chance that if you're watching this video,
you already know about Google Kubernetes Engine,
but to get everyone up to speed, let's have a quick overview.
GKE is an enterprise grade platform
for containerized applications, including
stateful and stateless, AI and ML, Linux and Windows,
complex and simple web apps, API and backend services.
You can use GKE to leverage industry-first features,
like four-way auto scaling and no-stress management.
You can also optimize GPU and TPU provisioning,
use integrated developer tools, and get multi cluster support
from SREs.
So why use Artifact Registry then with GKE?
Using Artifact Registry with GKE gives you
the ability to manage all of your artifacts in one place.
So for example, you can build Maven packages,
push them to Artifact Registry, containerize them
with Cloud Build in Jib, and then deploy them to GKE,
all while using consistent IM across the
build process, artifact management, and GKE.
Artifact Registry also enables you to run
in fully regionalized stacks.
So with Artifact Registry, an Australian or South
American customer can run GKE clusters
and manage container images in the same region,
and pay no egress costs while they pull images.
Pretty sweet, huh?
So without further ado, let's deploy to GKE.
First, start with new or existing code.
Here's a simple Go helloworld app
that I'm going to use in my container.
You can also take a look at my Dockerfile
here for kicks, though it's pretty much boilerplate.
See below for a link to the documentation
where you can see this file in detail.
I'm using Cloud Build to build this project, but keep in mind
that you don't have to.
Using Cloud Build allows you to automatically push
the image to Artifact Registry, which I like because it
streamlines the deploy process.
These next couple steps are for building with Cloud Build
if you don't already know your cloud project ID,
you can get it by running this command.
Now create a file called cloudbuild.yaml.
Here's the contents of that file,
but don't worry about rushing to pause the video so you
can copy this down.
You can find this code in the documentation, which
of course is linked below.
These variables, repository and image,
are used for the repository name and the name
of the image in the repository so
that they can be replaced at built time using custom
Cloud Build substitutions.
This is very useful if you want to use the same build config
file to push images to repositories
for different environments, such as testing, staging, and/or
production.
For example, this command would substitute
draynepipe for the repository name,
and my image for the image name.
I run this command to submit my container
to build using Cloud Build.
It is then stored using Artifact Registry
in the draynepipe repository.
Now that you have a project built and ready to go,
you may need to configure access to your container.
Check the docs to see the minimum required GKE
versions to create clusters that have
default permissions to pull containers
from Docker repositories in the same project.
If you are not using one of these GKE versions,
you will need to configure access
to pull containers using Kubernetes imagePullSecrets.
If you need to access containers from repositories
in another project, then you need
to grant read permission on that repository to the identity
being used to pull the image.
Once that access is configured, you
can run an Artifact Registry image on a GKE cluster
using this command.
Where "name" is the name you've given the object,
"location" is the regional or multi-regional location
of your repository, "project ID" is, of course,
your Google Cloud project ID.
"Repository" is the name of the repository
where the image is stored.
"Image" is the name of the image in the repository,
and "tag" is the tag for the image version
that you want to pull.
So for my draynepipe project, I'd use this command.
And now my image that's stored in an Artifact Registry
repository is deployed to GKE.
Want to see more on deploying to Google Kubernetes
Engine with Artifact Registry?
Check out the Artifact Registry quickstart for Docker,
and the Artifact Registry guide on integrating
with Google Kubernetes Engine.
Do you have any questions about Artifact Registry?
Feel free to comment below or tweet at me.
Thanks for watching, and I'll see you
on the next "Getting Started with Artifact Registry."
[MUSIC PLAYING]