-: All right, my friends.
Looks like Travis CI has successfully ran all of my tests
and made changes to my production at Kubernetes instance.
I'm now gonna flip over to my Kubernetes dashboard.
Now as a quick reminder
I've waited a couple of minutes here
or at least long enough where I feel like
yeah everything has probably been updated successfully.
We can very easily check to make sure
that everything was done correctly
by running a couple of commands inside of our cloud console.
So the first thing we can do
is try to get get our certificate object
that we had created.
And when I say get, I mean run the kubectl get command.
So inside my cloud console
I'll do a kubectl, get certificates
and this will print out all the different objects
of type certificate that exist inside of our cluster.
So I see right there
there is the certificate object they had created.
It was created two minutes ago.
Now to really make sure that this thing works successfully
I can then do a kubectl describe certificates
and this will print out some information
about the certificate object,
in particular It's going to have a little bit
of log information that describes
this back and forth project with
excuse me, back and forth process with Lets Encrypt.
All right, so I'll do kubectl describe certificates
and I'll see a bunch of information print out here.
Now I want you to know
you might see something in here around like message
and it might say like validation failed.
You also might see status false and type validate failed.
So if you see these like validation failed messages,
don't panic just yet.
You can essentially ignore these last couple
of keys inside of here.
What's really important is the list
of events that gets printed up at the very bottom.
So notice how for my events, I see issues or some messages
of created new ACME order attempting validation.
I then see that the domain
of www.k eights multi was verified successfully.
And I see the same thing for Keightsmulti.com as well.
I then had the certificate issued
we obtained the certificate and then issued successfully.
So the next thing I can do to make sure
that this all worked correctly, is check out the secret
that we had said,
that the certificate should be
stored inside of.
Inside my certificate.emo file.
Remember, we provided a secret name of keightsmulti.com
or at least that's what it was for me.
So I should now be able to look
at a list of all of my different secrets
and verify that there is a secret with this name.
I won't necessarily be able to look
at the contents of the secret.
Maybe, might not want to,
but I can at least verify that yes, the secret was created
and probably contains the TLS certificate.
So to do so, back inside of my cloud shell over here,
I'll do a clear.
And then kubectl get secrets.
And right here I see keightsmulti.com.
All right, I see data two
which probably represents the public
and private keys that make up the certificate.
So that's pretty much it.
It looks like we have successfully set up the process
of reaching out to, there it is, Let's Encrypt.
And we've successfully gotten this response back
from them that told us to set up a route.
They pinged our cluster.
That request was automatically responded
to through the cert-manager tool.
And in response we got a certificate that's going to be good
for some amount of time.
So now in theory, when that certificate is about to expire
cert-manager should wake back up
and attempt to go through this process all over again.
All right, so now the very last thing we have to
do is make sure that our NGINX ingress is aware
that we have ATLS certificate
and start using it for serving up traffic.
So let's take a quick pause
and we'll get around to that in the next section.