ALEXIS MOUSSINE-POUCHKINE: Containers have drastically
changed the workflow of many developers.
And so you might wonder, how do I run containers
on Google Cloud Platform?
In this video, we'll review three ways you
can run your containers on GCP.
[MUSIC PLAYING]
While the concepts underlying containers have been around
for many years, Docker, Kubernetes,
and an entire ecosystem of products and best practices
have emerged in the last few years
enabling many different kinds of applications
to be containerized.
As a developer, containers give you a lot of freedom
by letting you package an app with all of its dependencies
into an easy-to-move package.
The solutions for running containers in GCP
vary essentially in how much of the underlying infrastructure
is exposed.
The first way you can run a container on GCP
is to use Google Kubernetes Engine, or GKE.
As the inventor of Kubernetes, Google quite
naturally offers a fully managed Kubernetes service,
taking care of scheduling and scaling your containers
while monitoring their health and state.
Getting your code to production on GKE
can be as simple as creating a container
deployment with the cluster being provisioned on the fly.
Once running, GKE clusters are secure by default, highly
available, monitored, and they run on Google Cloud's
high-speed network.
They can also be fine tuned for zonal and regional locations
and can use specific machine types
with optional GPUs or TPUs.
GKE clusters also offer hassle-free operations,
with auto scaling, auto-repair of failing nodes,
and an auto-upgrade to the latest
stable version of Kubernetes.
GKE is also a key component of Anthos,
Google Cloud's enterprise hybrid and multi-cloud platform.
With Anthos, you can also migrate existing VMs directly
into containers and move your workloads freely
between on-premises and cloud environments, such as GCP.
What if you could focus on building your stateless app,
not on writing YAML files, and still deliver
code packaged in a container?
The second way you can deploy your containers on Google Cloud
is with Cloud Run.
This gives you the benefits of both containers and serverless.
There is no cluster or infrastructure to provision
or manage.
And Cloud Run automatically scales any
of your stateless containers.
Creating a Cloud Run service with your container
only requires selecting a location, giving it a name,
and setting authentication requirements.
Cloud Run supports multiple requests per container.
And it works with any language, any library, any binary,
and even any base Docker image.
The result is service with true pay-for-usage,
the ability to scale to zero, and full out-of-the-box
monitoring, logging, and error reporting.
Because Cloud Run is built using the Knative open source
project, which offers a serverless abstraction on top
of Kubernetes, you can have your own private hosting environment
and deploy the exact same container
workload on Cloud Run for Anthos in GCP or on prem.
The third option for deploying your containers
is straight to Google Compute Engine, or GCE.
That's right, you can leverage your familiar virtual machine
environment to run your containers.
This means using your existing workflow and tools
without requiring your team to ramp up on all things cloud
native.
When creating a GCE virtual machine,
the container section will let you
specify the image you'd like to use,
as well as a few important options.
When you get to the boot disk section,
the suggested virtual machine OS is something
called a Container-Optimized OS, an operating system
optimized for running Docker containers
and maintained by Google.
This operating system image comes with a Docker Runtime
pre-installed, thus enabling you to bring up your Docker
container at the same time you create your virtual machine.
But it also lacks most of what you
expect to find in a typical Linux distribution,
such as a package manager and many other binaries.
This means a lockdown environment
that ensures a smaller attack surface, keeping your container
runtime as safe as possible.
The great thing about running your containers
on Compute Engine is that you can still
create scalable services using managed instance groups,
as they offer auto scaling, auto healing, rolling updates,
multi-zone deployment, and load balancing
for the compute instances.
Where do these container images come from?
Where do I store them?
How do I version them?
And how do I restrict access to them?
The answer lies in Google Container Registry, or GCR,
which is a private-by-default Container Registry that
runs on GCP with consistent uptime
and across multiple regions.
You can push, pull, and manage images
in GCR from any system, VM instance, or your own hardware,
and maintain control over who can access,
view, and download those images.
Note, also, how you can conveniently deploy
to all three run times we've discussed straight
from Container Registry, deploy to Cloud Run,
to Container Engine, and to Compute Engine.
Container Registry works with popular continuous delivery
systems, such as Cloud Build, Spinnaker, or Jenkins
to automatically build containers on code or tag
changes to repository.
Finally, Container Analysis scans
containing images stored in the registry
for known vulnerabilities, and keeps
you informed so that you can review and address issues
before deployment.
Google Cloud offers you three solid ways
to run your containers, ranging from a fully managed Kubernetes
environment to a truly serverless platform.
Pick the solution that works best for you,
and start deploying your containerized workloads today.
Consider trying some free code labs linked in the description
below to explore these products, and look forward to upcoming
episodes and more overviews.
If you like this video, please like, subscribe, comment,
share, and look forward to more GCP Essentials videos.
[MUSIC PLAYING]