>> Hello, my name's Bridget Kromhout.
I'm a Principal Program Manager at Microsoft Azure.
Today we're going to talk about Helm,
the package manager for Kubernetes.
We can use Helm Charts to describe
applications for repeatable installation.
We can define, install, upgrade,
even the most complex Kubernetes applications,
doing updates, sharing, rollbacks, etc.
We can create version sharing, publish Helm Charts.
We'll do a quick demo to
show how to get started with Helm,
work with charts,
and install and re-install an application.
We'll start with the most current
version of the Helm client.
Helm List, lists Helm releases in a Kubernetes cluster,
so we need one of those.
You can use Helm with any Kubernetes cluster including
managed Kubernetes like that offered by AAAS.
Let's start with the current version
of the home client and
a local install for minikube for simplicity.
Helm installs charts or Helm packages into Kubernetes,
creating a new release for each installation,
and to find new charts, you can
search Helm Chart repositories.
You can create charts yourself.
But to start with, let's look
at community provided charts.
You can search on artifact hub in a browser
or from the CLI to see what's available.
See we want to install WordPress.
Look on artifacts hub for that.
We can choose a chart from
a verified source like Bitnami has a WordPress chart.
In the past Helm was
preconfigured with default chart repositories.
These days, charts are
decentralized and found in many repositories.
We can add the Bitnami repo to our local Helm search.
We can look at all the charts available,
and including all the versions of the charts that
we're interested in, such as WordPress.
Note that we have a chart version and an app version,
aren't necessarily the same thing.
A new version of the chart with different variables,
etc can be released,
and the version of the app may or may not be changing.
We're going to install the most current version.
In this particular case,
we can actually pull the chart down and look at
it locally before we install it.
In this case, we can see if
there's anything we want to customize.
Let's take a look in the values.yaml,
so we can see what we could set.
There is a BlogName.
We definitely can give it
a more customized blog name for this particular instance.
One way we can customize it is with a command line flag.
With dash, dash set,
we can set new variables
that way at initial installation.
Note in this case, by the way,
that the load balancer ip is listed as pending.
It will sway that way forever without
intervention because unlike public Cloud providers,
minikube doesn't offer a load balancer.
We can work around this with minikube tunnel.
We talked before about our customized title to start,
so let's take a look.
We've installed, we've found WordPress,
an artifact Hub,
and we have our customized title on
our WordPress installation in this particular case.
Now we have our WordPress site.
We can login to it, take a look,
see the username and password,
get in through the admin interface,
and we can see it is in fact
customized in the database locally.
But say we want to change something else.
If we want to release a change
before we used set on the command line,
we can also use a yaml file.
Let's take a look at the values that are set,
these are the user supplied
values we set ahead of time now.
But we can do a new release
with a change using Helm upgrade.
Notice that it failed because it expects a password,
which we can work around,
providing that on the command line.
Let's take a look now,
we're on revision 2,
did our update make it in?
Look at that, it says goodbye KubeCon.
You notice that we've deployed the second release,
change the title,
it'll be active when that path goes active.
We can look at the history for this revision,
with the correct man line tool.
We can see that our initial revision 1 was superseded,
and our first release is no longer active,
and our second release is what's active.
You can see that's where we're at now.
But what if we don't want to say goodbye,
we want to go back to the original.
If we have regrets, well,
time travel is not possible,
but we can redeploy a previous version.
You can see we've rolled back to the first release.
Let's look at those values now.
Hey, look at that. You say hello.
You can see there that our roll
back to the first version is complete.
You can see kubectl will just take a minute for it to
be active in our WordPress pad.
Notice that, by the way,
this is a composed application,
has MariaDB running,
and we haven't been changing that at all.
But now our new WordPress is
active. We are in revision 3.
We don't have to have this running,
we can uninstall it.
Uninstall's pretty quickly,
and kubectl doesn't see it anymore.
In summary, Helm is the package manager for Kubernetes.
Helm Charts allow for
repeatable application installation,
and nice to know,
Helm is a graduated CNCF project
maintained by the community.
You can visit the Helm site for
docs and community engagement.
Learn more about Kubernetes on Azure and
checkout more demos. Thank you.