In the last video we built out our client image on our local machine.
Now that this has been built I'm going to push it out to Docker Hub.
I'm gonna do a docker push.
Steven Greider slash client.
Remember if you are using Cuban 80s on Google Cloud you do not have to run this command.
So I gotta run that and let it do its thing while that's running.
I go back over to my terminal where we're going to start to write out a pretty good amount of configuration.
So we want to get our client running inside of our communities cluster.
There are a couple of things we have to do to get that happening.
First off we need to make sure that we create a new deployment config file inside of our case its directory.
This deployment config file is going to be just about identical in nature to the one we already wrote
out for our authentication deployment we're then going to make sure that we add a config entry to our
scaffold e-mail file particularly inside this artifact section.
Remember the artifact section is going to setup some code sinking to make sure that in time we make
a change to some JavaScript files inside of our client directory.
Those changes get sink into the pod that is running our client image and then finally we want to kill
to access this next J application from inside our browser.
So in other words we need to somehow make requests from outside of our cluster and get them correctly
routed inside of it.
You'll recall that we were using ingress engine X for that.
So we've got the ingress SRB file inside of arcades directory.
This is where we are listing out all of our config to specify routing rules inside the cluster for incoming
requests from the outside world.
So in total three things for us to do.
Let's get started right away.
I'll first begin by going to my k its directory inside there are going to make a new file called client
dash double yellow again.
The client config file or the client deployment file is gonna look just about identical in nature to
the authentication one.
Just everywhere we have the word off pretty much just gets changed over to client.
So let's write this out very quickly.
I'm gonna put in an API version of apps V1 a kind of deployment we'll put in a metadata section with
the name of client dash devil I'll then put in a spec to describe exactly how this deployment is supposed
to behave I'm gonna put in replicas of one because I only want to be running at one single pod or my
next s application when we're in this kind of development environment.
I'll then put in a selector with the match labels app client then on the same level of indentation as
selector we'll put in the template.
And remember this template section describes exactly how every pod that is created and managed by this
deployment should behave it's going to put in a metadata here as well.
With labels of app client remember this metadata section right here and the selector section right here
is how the deployment is going to find the set of pods that is supposed to manage then on the same level
of indentation as metadata.
We'll put in a spec describe how every pod should behave we're gonna say that every pod is gonna have
a container section.
We only want to have one container and we're going to give it a name as simply client animals it the
image that we wanted to run so in this case my dock ready slash client quick reminder if you are making
use of Google Cloud for your communities cluster you are not going to put in this format of image right
here.
Instead you're gonna put in that kind of GC R dot Io or something like that.
You can see the format of that or get a reminder of what the format looks like by going back over to
your will see me on the dash depo file.
So go back over there and you'll see the format that you are supposed to use.
It's supposed to be something like GC short Io dot something slash and then your project I.D. and then
the name of the actual part or image they trying to run OK.
That is it for the deployment.
But remember after the deployment we also need a service to allow requests inside the cluster to get
access to this pod.
You're gonna write out that service at the bottom of the file I'll put in a dash dash dash at the very
bottom and we're gonna create our cluster I.P. service.
We'll put in an API version of V1 a kind of service metadata with the name of client SRB
and then our specs section.
We're going to add in a selector of app client.
And remember the selector right here is how the service is going to find the pods that it is supposed
to govern.
Requests to after selector will then specify the list of ports that we want to allow access to.
We're gonna have one port.
I'll give it a name of client remember the name here.
Not super important on the actual port.
It's really just for logging and reporting purposes our protocol will be DCP but the port of three thousand
and a target port of three thousand.
Why are we using three thousand here.
Well as you just saw at your terminal a moment ago as we started up our next application in the development
of armament directly on a machine you saw that next day us by default listens on port three thousand.
So that's all you're putting out here.
All right.
Let's save this file now as soon as we save this file scaffold is going to detect that we've added a
new config file to our kids directory.
So if we go back over to the terminal window running scaffold we should see something it says aha found
this thing and created some deployment and some service.
Now just you know after you apply or after scaffold applies this file you might see an error a big red
error something it says cannot find image your Docker I.D. blah blah blah if you see something like
that.
Chances are you have not finished pushing your image.
The initial build that we just put together to Docker Hub.
So if you get that really big error message all you have to do is stop scaffold with the controller
see and then start it back up with scaffold depth and you'll want to do that after you have pushed the
image successfully to Docker Hub and then after that we should see our off come back up and very shortly
we should see some logs coming from the client as well
so that gets at least the pod created.
But there are still two other things we have to go through.
Remember inside of our scaffold at the end of file we have to setup files sinking by listing out our
client project as a build artifact so I'm going to just go ahead and copy the existing block here and
paste it down and then going to fix our indentation I'll find the dash image and make sure it's on the
same level of indentation as image above it all then go through this copy paste right here and update
off to client I'll update the context to client and then the only other thing we have to change is the
directory where the files set to attempt to sync.
So remember on the scaffold project we're going to be trying to sync JavaScript files and in addition
inside this client directory we do not have a s RC folder to watch.
So we're gonna change SLC right here to star star flash star dot J.S. and we'll save that file
very last step.
Remember we need to update our ingress configuration so inside my KDE directory I'll find the ingress
service config file.
So we need to add in a new path that users can visit and have all requests that go to some particular
path read it off to our client service I'm going to add in a new entry at the bottom here of path slash
and then question mark parentheses dot star well then put in a back end but the service name of client
SRB and a service port of three thousand as well now something really important to understand here we
are listing out.
And so this part's an array of different paths.
Whenever a request comes into ingress engine X it's going to attempt to match the path of that incoming
request to the parts we've lost out inside of here.
In order that means that first the incoming request is going to attempt to be matched against that path
right there.
If it does not match that path it will then be attempted to be matched against this one.
The one that we just had in in right here is essentially a catch all in just about any path request
comes in.
This little red X right here is always going to capture it.
So we want to make sure that we always first list out our very particular API for our different services
and then only if we do not capture a request against any different services do we wanted to eventually
be forwarded on to the client service.
There are always gonna make sure that we list out the client service at the very very bottom because
if we listed at the top then any incoming request and always be matched against this one which is definitely
not what we want.
So going to save this file as well.
And now finally after all that we should be able to go over to our terminal and in the window running
scaffold.
Hopefully you will now see some output from the client pod.
Looks like I've got it right here.
If you are seeing a error message of any sort.
By far first thing you want to do is stop scaffold and start a backup after it looks like everything
is running.
Or even if you see a warning or something like that.
Let's test this out very quickly to do so we should be able to go back over to our browser and remember
how we access our development server or our carbonated cluster.
We're going to go to ticketing not dev so if I go to ticketing dot dev I will see the next J.S. page
up on the screen of landing page.
Awesome.
Remember if you get a security warning we just want to bypass that because it's chrome jumping in when
we really don't want it to do.
So you can either click on advance at the bottom and try to bypass the security warning chits or however
there will not be a bypass link inside there.
So to really bypass that screen you can type directly onto your keyboard.
This is unsafe and it should bypass the HDD yes air so we can see our landing page and if we tried to
go to slash the nana we should see the banana page as well.
All right.
So now we've got this all wired up.
Quick pause right here and continue in just a minute.