>> Hey friends.
Did you know that HashiCorp Service Mesh offering Consul
has been deployed to tens of thousands
of nodes in a single datacenter?
Now, it integrates with
discovery features inside and outside of Kubernetes.
Geoffrey from HashiCorp is here to show us how that works with
Azure Kubernetes Service today on Azure Friday.
[MUSIC]
>> Hey, I'm Scott and it's Azure Friday.
I'm here with Geoffrey from HashiCorp,
and you're going to show me some amazing stuff
and I appreciate you.
>> Yes we're running Consul,
our service mesh on AKS.
I'm excited because we've
shown in a previous Azure Friday episode,
how to create an AKS cluster with
Terraform, our scripted provisioning tool.
But Terraform is already installed right in the Cloud Shell.
So, I can just use this right in the Azure Cloud Shell.
>> TF command lines already there in the Cloud Shell.
>> So, we've I already done this elsewhere,
but just want to show two snippets that are
relevant to running Consul in AKS.
One is we do want to enable role-based access control,
so that Helm the Kubernetes package manner can do its thing.
>> Okay.
>> Then once that's running,
we can also configure a service account inside of
Kubernetes and that's called
Tiller which is the server- side component of Helm.
So, we'll set up Helm with that and we have that here.
>> Okay.
>> Now, that that's running,
we're ready to actually install Consul to this cluster.
So, as is often the case,
we want to override some values.
>> How big is this cluster?
How big does something need to be to install Consul?
>> Well, thanks to the way that Kubernetes works.
It can even just be a single computer, no,
so, you don't need a lot of resources to do this.
I belt just a two or three node cluster here.
But it can be pretty small, if you want it to be.
>> Nice.
>> So, we're overriding a few values.
I'm giving a name to my datacenter within Consul.
I'm going to say that I want to be able to see
the user interface through a load balancer.
I want to be able to use connects this sidecar that
will build my service mesh out of the Envoy proxy.
Then I do want to understand how Kubernetes
works to where when resources aren't being used.
It will reap those and use those for other things.
But I always want my servers to be running.
So, I'll tell it to not disrupt any of my Consul servers.
>> Okay.
>> So, with that,
I can now install Consul using a Helm chart.
So, with a single command and my overrides,
I can install Consul via Helm.
I'd like to give it a name. So, I've called
this azure just so that I can refer to this.
>> Okay. If I understand correctly
because AKS is really Kubernetes,
all these HashiCorp things just work.
You didn't have to have the Azure version
of your HashiCorp favorite tools.
>> Exactly. When I provisioned the AKS cluster,
I'll do some Azure specific things.
But from there on, it's just Kubernetes.
>> Nice.
>> So, I've installed that
and now I want to see where's my load balancers.
So, I can look at my administrative user interface.
Fortunately, I can get
that with "kubectl get service" and I've given this name.
So, azure-consul-uI is going to be my administrative dashboard.
When I'm using Kubernetes,
I like to use this double dash watch option
because of the load balancers still spinning up.
This will just hang until that is ready.
Then it'll show me out, my external IP address.
>> I see.
>> So, I've got that and here is my Consul user interface.
So, I see a list of services.
I can see all of my compute nodes,
and I can see
my key value store for
configuration and other kinds of things like that.
But now we need some services.
So, let's look at that.
So, I have a two service web application
and they want to communicate with each other.
I'll just use standard Kubernetes techniques here.
So, I'll apply a directory
of YAML files that builds
these services for me as parts in Kubernetes.
Here it is. So, it's a dashboard.
This number is being pulled from a backend data service.
>> Okay.
>> So, those are my two services.
So, now we're actually ready to think about how
these services interact and secure this a little bit more.
We're already using TLS over the Envoy proxy to make sure
that all communication is encrypted
and that's one thing that Consul does for you.
It generates certificates, rotates those certificates,
make sure they're on the proper compute nodes,
and in the proper pods.
But we want to lock this down a little bit more
using this principle of least privilege.
>> Okay. We'll assume I understand some context here.
So, this web application is talking to a back-end.
It's doing it, If I understand correctly in
a fairly naive way because it
doesn't want to have to think about doing it right.
It just wants to do something and wants to talk to the backend.
>> Exactly.
>> So, it may think if I understand correctly that it's
talking directly to the backend
and it gets its thing that's satisfied.
It's happy. But reality isn't the
same as what it thinks reality is.
>> Exactly.
>> Okay.
>> Right now we've just left
is fairly open to where any service can talk to any other service.
Well, we might not want
our calendaring service to be able to
talk to our fraud detection service.
So, let's specify which services
should be allowed to talk to each other service.
>> That makes sense.
>> There are many ways we can do that through
the API or through this web user interface.
>> This is one of
the important things about this entire ecosystem is
that my application shouldn't care about
the things you're about to do to lock things down.
You're not going to make application code changes.
>> Exactly. In fact,
I wrote these applications using Go, a year ago.
Before I even thought about putting them into Kubernetes,
I didn't have to even recompile.
>> So, even better. They don't even know
where they are living. They're in the matrix.
>> Yeah.
>> That's awesome.
>> So, we'll start with a rule
and intention here which is just a rule
about how services should be able to
interact and we'll just lock this down.
So, no service is allowed to talk to any other service.
Right away after a few seconds,
the few seconds is not a feature of Consul.
It's very fast. It's more of
my application which checks every few seconds.
As we can see, now it can't reach
that back-end data service and there's nothing to display.
So, we've locked that down.
But now we want to enable it.
So, I'll create another intention that says
my dashboard service should be able to
talk to my counting service and I will go ahead and
allow that and very quickly.
Now, we're connected again.
But with additional control
over how our services are allowed to interact.
>> How are those rules reconciled are they in-order?
Is there a union that is produced in some way?
>> Great question.
As we can see here, they have a precedence.
So, we know that more specific rules
should apply differently than the more general rules.
So, there is a ordering and you
can see it right here on the web user interface.
>> Very cool. That makes sense. It's intuitive.
So, when the application,
the counting application is talking to that backend,
is it just going like HTTP slash,
slash counting service or counting database?
Does it think it's talking to a local intranet?
>> Well, that's one thing that we've done to make this as easy as
possible is that we'll manage these proxies for you.
But the applications just talk to
localhost on a port that you configure and then we
handle the rest of discovering
the service that you want to connect
to and what IP address it's one running on.
What port. That type of thing.
So, your application just talks to localhost.
>> Really? That's interesting. So, I've seen
different services have different hits or different ways to do it.
I've seen some Kubernetes apps where they
have HTTP slash, slash DB.
I've seen other ones where they map it to a port.
Why would I pick one versus the other?
What kind of benefits would I get when I want to use Consul?
>> Well, we know that in today's modern infrastructure,
resources are being spun up and shut down all the time.
So, we don't want you to have to specify
IP addresses and have to manage that.
Let us do that for you.
So, Consul allows you just to think of these services by
their name and then we'll
do the rest of discovering where they are,
the healthy ones,
which ones are ready
to serve the kind of data that you want to get.
So, that's a way that we tried to make
a really good user interface for
the DevOps professional who's
building their infrastructure around us.
>> You point out that we think about those services by name.
Do we think about them by name at
the only the DevOps level or might I
actually Consul-aware or Consul-enable my app?
Like you made a comment that
your Go apps don't know where they're living.
There really kind of ignorant.
Is there value in them becoming more
like knowing about what's outside of their scope?
Or is it important for them to be ignorant?
>> Well, there's two ways you can do it.
We do connect to the DNS services built into Kubernetes.
So, if you want to use the ways that
Kubernetes can find other services,
you can use that Consul.
Works together with those.
Or Consul runs its own DNS on a top-level dot Consul domain.
So, you could say "counting.service.consul" and use
that to then find
the available healthy resources serving the counting.
>> That's really interesting. That implies
that you are prescriptive and opinionated,
but not so much that you don't let me do what I want to do.
>> Exactly. We want to suggest a workflow,
but also enable you to plug into legacy,
green field or any other applications that you want to write it.
>> Right. I liked that your application
even though is only a year ago,
you could call it a legacy application.
Because you just enabled it
without telling it about its environment.
You just brought it in.
Now, it could potentially scale.
>> Exactly. It was written to
be configurable through some environment variables.
So, I was able to control
the precompiled application just by sending
in localhost at a port
that I wanted to talk to and then from there,
it was just up to the proxy to find that service.
>> Cool. No code changes, everything just worked?
>> No code changes.
>> So, Consul is a service mesh in that you could have dozens,
hundreds, thousands of potential microservices.
I've seen people go a little crazy with microservices
almost like they're creating
an old DCOM application from 20 years ago,
where every single thing is a service.
How do you decide what your granularity is and what's too far?
>> We've seen that and we want to give you
the ability to decide how your architecture runs.
But for Consul to be as flexible as it needs to be.
So, we have these top-level service names like counting or
fraud detection and then we also allow you to tag those services.
So, you could tag them by version number
or some feature or maybe you're doing some kind of feature flags.
So, we'll give you the ability to
use either tags or service names,
and then it's up to you how you want to split up those services.
>> You mentioned versioning which is great.
It's actually my next question.
Like if you're going to do this,
would you version this by running two versions of
your counting service or would you
teach the counting service about managing versions?
Then you'd have one instance and it would be smart.
Ultimately, Consul doesn't care.
>> Console doesn't care as some people like feature flags
to where a single binary is running two different features
based on the audience or you can spin up
a whole new compute resource or a Kubernetes pod,
that's running a separate version and then will allow
you either to just say, "Give me all the healthy services,
for the counting service or only the
counting services that have my particular version tag."
>> Fantastic. Well, this is great.
Thanks for sharing with me.
I am learning all about the stuff
that I can bring in from HashiCorp and
the Kubernetes ecosystem like Consul and I can run it
on Azure and learning all about it today on Azure Friday.
[MUSIC]