-: Wow, I'm actually kind of surprised
everything worked correctly the second time through,
at least the build did.
Remember, if you see any error message here,
try flipping over to the QA,
try comparing your code to mine on GitHub,
because it's so incredibly likely
that it's just a tiny typo.
So at this point, it looks like the build successfully ran.
All that really means is that we built our images,
pushed them off to Docker Hub,
and then ran some commands against kubectl
on our production Kubernetes instance over here.
Now, before we try to actually test out
our site inside of Kubernetes or anything like that,
I wanna very quickly open up Docker Hub.
I wanna look at some of the different repos
that we have inside of here.
How about say, multi-server.
If I look at multi-server and I look at my tags,
I'll see that both the latest tag
and this new long tag right there
were updated just two minutes ago.
So that definitely means
that I now have a permanent backup of my code,
as it was at this commit right here,
or the image I should say.
And I also have a completely up to date tag
of latest that new engineers can pull down in the future
and know without a doubt that yeah,
they're running the latest version of this image.
So that's definitely cool.
And the next thing I wanna do
is go back over to my Kubernetes dashboard.
So once over here, I'm gonna refresh the page,
and then I'll take a look at the workloads tab.
So now over here, oh, this is pretty awesome.
I see that I've got my client deployment,
PostgreSQL, Redis, server, worker,
all those deployments have been created.
You can click into one of these deployments
and you'll see all of the different pods that it manages,
along with a couple of graphs detailing the
runtime information about this deployment.
So here's the managed pods right here.
Little information about each one that's running,
and of course we can click into each of those
and see information about that individual pod as well.
Now, if I go over to services
I'm gonna see a lot of information over here as well.
So there's our set of cluster IPs.
There's say the client cluster IP,
all the others for all the other different
sets of pods we have inside of our application.
Now, very interestingly,
you'll see that we have an Ingress service right here
and it has an endpoint of like */ and */api.
These two endpoints that you see right here
are essentially routes
and those are the different routes that we had set up
inside of our K8 Ingress service .yaml file.
So remember inside of here, we set up the two paths.
We have path of / and path of /api.
So that's what these two endpoints right here
are talking about.
We still have the old load balancer.
I shouldn't say old, it was just created,
but it's the load balancer that we were talking about
in the last section.
So remember, the Ingress right here is really just
a config file.
This config file is being shipped off
to the Ingress controller.
The Ingress controller is both making changes to NGINX
and hosting NGINX simultaneously.
Now, some other quick things I wanna take a look at.
If we look at configuration,
we're gonna have some config maps,
which we haven't quite spoken about too much,
but we do also see inside of here the PG password secret
that we had previously created.
We also see a service account that belongs to NGINX Ingress.
This service account right here was created by Tiller
when it went through all that setup
of NGINX Ingress for us.
And the last thing I wanna show you
is storage tab over here.
So you'll see that we have
a persistent volume claim created.
This is the database persistent volume claim
that we had created to make sure that we had
some permanent storage allocated to PostgreSQL.
So we can click into this.
I don't know if it's gonna show us the actual,
well, ah, here we go.
So here's the volume right here.
So we can click on this volume
and this is a volume that was created
by that persistent volume claim.
Now, if you want to, I'm pretty sure we could actually go up
to our navigation menu up here
and take a look at the storage or, is it data store?
No, I forget exactly where it sits on here.
Okay, maybe we'll come back to that.
But I thought it would've been really nice
to look at the persistent disc dashboard
and see if that one was actually created over there,
but I don't actually see anything on here
related to the persistent data.
Okay, so anyways, last thing we'll do,
we'll go back over to services
and we're going to try visiting
our IP address right here again.
Now, if everything worked correctly, when we click on this
we should see our React project appear on the screen.
I don't know what to expect here.
I don't know if it's gonna work, but whatever happens,
we'll just deal with it accordingly.
Okay, so I'm gonna go to that address.
I see the privacy error here, which is totally fine.
Remember, this is something that we saw
in our local environment as well.
We are gonna fix this up very quickly.
So this is a very temporary thing.
So I'll go to advanced and then proceed.
Yeah, oh my gosh, I can barely believe it.
It actually worked, or at least it, I think it worked.
You know, let's actually try entering a number here.
I'll put in four and submit it, and then I'll refresh.
Oh my, I can't believe it.
It actually worked.
Yes!
Oh, I'm so happy.
All right, my friends, there you are.
There you have it,
a Kubernetes cluster running in production.
Now we're not quite done.
We have deployed this.
You know, we're just about there
but we still got this HTTPS error.
So clearly we need to do a little bit work there.
I also want to very quickly walk through the process
of making a change to our source code
and then redeploying all these changes
and making sure that we can see the updates up here live
at this address as well.
So let's take a pause right now
and tackle a couple extra steps
in the next couple of videos.
So I'll see you in just a minute.