A couple of videos ago I told you that we use deployments because we can very easily update the version
image used by each of our different pods.
So for example if we make a change to our post project and we rebuild the image we might want to redeployed
our application and have our deployment run this new version to instead.
In this video we're going to start to walk through two different ways of actually applying this update
in this video in particular we're going to take a look at Method number one for updating the image used
by a deployment.
You're not going to see a method number one use very often in professional deployments.
And I'll tell you why in just a moment let's first go through the series of steps and then we'll all
describe exactly why you can see this use very often.
So step one we're gonna make a change to our project code.
Let's do that right away.
I'm going to open up my code editor and inside of my post.
Project directory I will find the index dot J.S. file so we're going to imagine that we make some change.
This project may be down here at the very bottom at apt.
Listen right above that console log that says listening on four thousand I'll put in a console log of
about version 20 we'll say that we are trying to deploy this new version 20 of our code base.
So that's the change that we're going to make once we made that change.
We're then going to rebuild our post image.
And when we rebuild the image we're going to tag that image with some new version number to do so.
We'll go back to our terminal I'll change back into my post project directory and we will rebuild that
image by running docker build dash t your Docker I.D. flash posts then a colon and we'll put a new version
number in here.
So for example I can put it in 0 0 5 0 imagine this is version 5 or something like that of my post project
I'll then put a space and then the dot right there.
Remember that designate.
So we want to build the image out of everything inside this post directory so I'll run that.
And now I've got 0 0 0 5 so we've now got a new image with a appropriate image version tied to it.
Now the next thing we're going to do we're gonna find our deployment config file and we're going to
update the version of the image inside their back inside my editor.
I'll find the post config file and I'll update the image version right here 2 0 0 5.
I'll then save this file.
And now we need to tell Cuban natives to use this new updated config file by just making a change to
config file.
Nothing changes inside of our cluster.
Rubin 80s is not actually aware that this file even exists.
Whenever we make a change to a config file we have to eat it back into the cluster using that same cube
GTL apply command whenever you apply a config file humanities is going to know whether this is a config
file has already been fed into it before or if it's something brand new.
In this case we have a config file that we've already fed in once.
So Cuban 80s is going to know that we are trying to make a change to an existing object as opposed to
creating a new object.
It's going to take a look at all the different config options.
It's going to see that the only thing has changed inside of here is the version image or the image of
the version.
And so it's going to make that one single change to our existing deployment as opposed to creating a
new deployment or something like that.
So let's go back over to our terminal.
I'm going to change back into our infra AIDS directory which is where our deployment file is sitting
and we will do a cube CTO apply with that file.
There we go.
You'll notice that it says as soon as we apply this thing that this deployment was configured.
You might recall that when we first created that deployment it said that the deployment was created
so we can definitely tell that Cuban A.D. understands that this is a config file it related to a deployment
that already exists but rather than creating a new deployment it configured or changed the configuration
of the one that already exists.
Now we should be able to do a cube CTO yet deployments it looks like we have one pod running and if
I do a cube C.T. I'll get pods.
There is our newly created or newly restarted pod.
You'll notice it has an age of 32 seconds which means that this pod was just created using the new version
of our image.
Nabeel to get logs out of this pod right here so I'll copy the pod name and do a cube CDL logs and then
the name of the pod.
And out right here I'll see if v 20 which means that our deployment or our new change right here was
just successfully deployed through the deployment OK.
So that is method 1.
Number one or update the image that is used by a deployment now at the start of the video I told you
that you're not going to see this use very frequently.
And the reason for that is that back inside of our config file we are specifying a very precise version
right here.
The reason that this is a problem is that any time we want to make a change to our application or redeploy
our application we would have to always open up this config file and make a change to that little number
right there.
Over time you're going to see that these deployment files start to get really really large.
And so we really would like to not have to open up this file very often and make changes to it as every
single time we make a change to a file.
There's always the possibility of adding in some kind of error so it would be really great if we did
not have to specify a version inside of here at all.
It'd be great if we could just somehow tell communities to always use the latest version of a gimmick
given image that would be fantastic and that's what method number two is going to be based upon we're
gonna figure out a way to tell communities to use the latest version of an image.
We're gonna figure out a way to tell communities to automatically update itself or we set up our deployment.
Anytime that version changes as well or any time we create a new image as well so let's take a pause
right here.
We'll take a look at Method number two in just a moment.