Hey, I'm Nick from the container tools team at Google.
And today, I want to talk to you about one
of our newest and most exciting tools, Skaffold.
Skaffold is a tool that's designed
to make local Kubernetes development easy.
It watches your local application directories
for changes, and can automatically
build, push, and deploy your application images
to any local or remote Kubernetes cluster,
letting you focus on developing your application.
Let's take a look at how to get Skaffold
running on your application.
Skaffold runs as a binary on your local machine.
So installing it is as easy as downloading the latest release
from the Google Container Tools GitHub page.
Alternatively, you can build Skaffold straight from source.
Skaffold uses YAML configuration to describe
how your application should be built and deployed.
You can specify one or more images for Skaffold to build,
which Skaffold will tag, and push to any valid document
repository.
These continuously-built images will
be injected into your Kubernetes ideas manifest,
and used to deploy new changes to your cluster on every code
change.
Let's walk through an example to demonstrate a typical Skaffold
workflow.
Here we have a simple go Hello World! application,
which just prints "Hello World!" in a loop forever.
We have a docker file that builds a binary from the source
file, and puts it into a container,
and a Kubernetes manifest that creates a pod
from this container image.
Skaffold has a built-in command, skaffold init,
that will generate a Skaffold YAML for your code base
containing default values to get Skaffold running.
Let's run it on the code that we have here.
You can see our generated Skaffold YAML has one build
artifact pointing to our Docker file that builds the image
and pushes it to our project's registry.
This image is tagged with the git tagging strategy, which
uses the latest commit hash as an image tag,
though there are several other tagging strategies available.
Skaffold also defaults to using the Kube control deployer
that deploys from our Kubernetes manifest
to our existing cluster, though there
are several other deployment strategies available as well.
As we run skaffold dev, you can see Skaffold immediately
builds the artifact we specified, and pushes it
to the target registry.
It then creates a pod in our cluster
using the image we just pushed.
By default, Skaffold streams the logs from the pods it creates,
so looking at these now, we can see Hello World!
being logged like we expect.
One of Skaffold's most exciting features
is its file watcher, which watches for changes
to one or more local directories on your file
system in real time.
When Skaffold sees any changes to your code,
it will build a new image from source,
and deploy it to your Kubernetes cluster.
Let's change our print statement up,
and watch how Skaffold reacts.
As I change the string to Hello Skaffold!
We can immediately see Skaffold recognizes
that our source file has changed and re-triggers
a build and deploy.
Watching the logs, we can see them switch over in real time
to our new print statement as the new pod is created.
Let's take a look at a more complex example
to see how Skaffold works with more realistic workflows.
Here, we have an application with two services-- a web
server and an application server.
These services can be built and deployed independently
of each other, and Skaffold is smart enough
to understand that.
Let's go through the same flow we did with the Hello World!
Example here to see what it looks like.
Running skaffold init again, this time
we're prompted for which Docker file
builds each image, since there's no way for Skaffold
to know that beforehand.
In our generated Skaffold YAML, we
can see that a build artifact is specified for each services'
source code directory, and Skaffold
will put a separate file watcher on each of these directories.
This means that when files change in one directory but not
the other, only the container corresponding to the modified
directory will be rebuilt. skaffold dev builds and deploys
both parts of the application as we expect, and in the logs,
we can see both services are ready in our Kubernetes
cluster.
Now if I go make a change in the web server,
we can see Skaffold picks up the change,
and only rebuilds that container.
Skaffold's deployer then only updates
the deployment associated with the newly-built artifact,
and we can see this reflected in the deploy logs.
This means your dev cycles are never
bottlenecked by parts of your application
that you're not working on.
These services don't necessarily need
to live in the same repository.
As long as your Skaffold YAML points to valid workspaces
on your local file system, you can
use any number of different repositories
in a Skaffold workflow, making it
an awesome tool for development on microservice-based
applications.
Skaffold can help speed up any Kubernetes development workflow
by getting ops out of your way, allowing you to focus solely
on application development.
You can find these examples and more
in the Skaffold GitHub repository,
linked in the description of this video.
Contributions to Skaffold are always welcome.
If you'd like to learn more about contributing,
check out the contributing guidelines
in our GitHub repository.
Go try it out for yourself, and let us know what you think.
Happy Skaffolding.
[MUSIC PLAYING]