1
00:00:00,740 --> 00:00:05,930
A couple of videos ago I told you that we use deployments because we can very easily update the version

2
00:00:05,960 --> 00:00:08,130
image used by each of our different pods.

3
00:00:08,150 --> 00:00:13,990
So for example if we make a change to our post project and we rebuild the image we might want to redeployed

4
00:00:14,150 --> 00:00:18,710
our application and have our deployment run this new version to instead.

5
00:00:18,710 --> 00:00:22,610
In this video we're going to start to walk through two different ways of actually applying this update

6
00:00:23,630 --> 00:00:28,090
in this video in particular we're going to take a look at Method number one for updating the image used

7
00:00:28,090 --> 00:00:29,470
by a deployment.

8
00:00:29,470 --> 00:00:33,540
You're not going to see a method number one use very often in professional deployments.

9
00:00:33,640 --> 00:00:37,950
And I'll tell you why in just a moment let's first go through the series of steps and then we'll all

10
00:00:37,960 --> 00:00:41,780
describe exactly why you can see this use very often.

11
00:00:41,800 --> 00:00:44,830
So step one we're gonna make a change to our project code.

12
00:00:44,830 --> 00:00:46,350
Let's do that right away.

13
00:00:46,360 --> 00:00:49,130
I'm going to open up my code editor and inside of my post.

14
00:00:49,140 --> 00:00:54,500
Project directory I will find the index dot J.S. file so we're going to imagine that we make some change.

15
00:00:54,500 --> 00:00:58,160
This project may be down here at the very bottom at apt.

16
00:00:58,160 --> 00:01:03,170
Listen right above that console log that says listening on four thousand I'll put in a console log of

17
00:01:03,560 --> 00:01:11,040
about version 20 we'll say that we are trying to deploy this new version 20 of our code base.

18
00:01:11,120 --> 00:01:15,540
So that's the change that we're going to make once we made that change.

19
00:01:15,570 --> 00:01:17,980
We're then going to rebuild our post image.

20
00:01:18,060 --> 00:01:24,370
And when we rebuild the image we're going to tag that image with some new version number to do so.

21
00:01:24,370 --> 00:01:32,050
We'll go back to our terminal I'll change back into my post project directory and we will rebuild that

22
00:01:32,080 --> 00:01:40,600
image by running docker build dash t your Docker I.D. flash posts then a colon and we'll put a new version

23
00:01:40,600 --> 00:01:41,830
number in here.

24
00:01:41,940 --> 00:01:49,570
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

25
00:01:50,690 --> 00:01:52,720
I'll then put a space and then the dot right there.

26
00:01:52,730 --> 00:01:53,710
Remember that designate.

27
00:01:53,710 --> 00:01:58,780
So we want to build the image out of everything inside this post directory so I'll run that.

28
00:01:58,810 --> 00:02:08,410
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.

29
00:02:08,480 --> 00:02:12,920
Now the next thing we're going to do we're gonna find our deployment config file and we're going to

30
00:02:12,950 --> 00:02:17,400
update the version of the image inside their back inside my editor.

31
00:02:17,430 --> 00:02:25,320
I'll find the post config file and I'll update the image version right here 2 0 0 5.

32
00:02:28,030 --> 00:02:29,560
I'll then save this file.

33
00:02:29,560 --> 00:02:35,040
And now we need to tell Cuban natives to use this new updated config file by just making a change to

34
00:02:35,070 --> 00:02:35,820
config file.

35
00:02:35,820 --> 00:02:38,190
Nothing changes inside of our cluster.

36
00:02:38,370 --> 00:02:41,970
Rubin 80s is not actually aware that this file even exists.

37
00:02:41,970 --> 00:02:47,660
Whenever we make a change to a config file we have to eat it back into the cluster using that same cube

38
00:02:47,670 --> 00:02:54,420
GTL apply command whenever you apply a config file humanities is going to know whether this is a config

39
00:02:54,420 --> 00:02:58,760
file has already been fed into it before or if it's something brand new.

40
00:02:58,950 --> 00:03:02,630
In this case we have a config file that we've already fed in once.

41
00:03:02,670 --> 00:03:07,620
So Cuban 80s is going to know that we are trying to make a change to an existing object as opposed to

42
00:03:07,620 --> 00:03:09,630
creating a new object.

43
00:03:09,860 --> 00:03:12,300
It's going to take a look at all the different config options.

44
00:03:12,450 --> 00:03:17,380
It's going to see that the only thing has changed inside of here is the version image or the image of

45
00:03:17,380 --> 00:03:18,220
the version.

46
00:03:18,220 --> 00:03:22,800
And so it's going to make that one single change to our existing deployment as opposed to creating a

47
00:03:22,800 --> 00:03:24,300
new deployment or something like that.

48
00:03:26,330 --> 00:03:28,800
So let's go back over to our terminal.

49
00:03:28,970 --> 00:03:34,530
I'm going to change back into our infra AIDS directory which is where our deployment file is sitting

50
00:03:35,640 --> 00:03:43,040
and we will do a cube CTO apply with that file.

51
00:03:43,110 --> 00:03:44,150
There we go.

52
00:03:44,160 --> 00:03:48,540
You'll notice that it says as soon as we apply this thing that this deployment was configured.

53
00:03:48,540 --> 00:03:52,560
You might recall that when we first created that deployment it said that the deployment was created

54
00:03:53,250 --> 00:03:58,110
so we can definitely tell that Cuban A.D. understands that this is a config file it related to a deployment

55
00:03:58,110 --> 00:04:02,940
that already exists but rather than creating a new deployment it configured or changed the configuration

56
00:04:02,940 --> 00:04:05,370
of the one that already exists.

57
00:04:05,550 --> 00:04:13,080
Now we should be able to do a cube CTO yet deployments it looks like we have one pod running and if

58
00:04:13,080 --> 00:04:15,200
I do a cube C.T. I'll get pods.

59
00:04:15,330 --> 00:04:18,860
There is our newly created or newly restarted pod.

60
00:04:18,870 --> 00:04:24,540
You'll notice it has an age of 32 seconds which means that this pod was just created using the new version

61
00:04:24,630 --> 00:04:26,460
of our image.

62
00:04:26,460 --> 00:04:33,420
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

63
00:04:33,420 --> 00:04:34,500
the name of the pod.

64
00:04:36,030 --> 00:04:41,410
And out right here I'll see if v 20 which means that our deployment or our new change right here was

65
00:04:41,410 --> 00:04:45,030
just successfully deployed through the deployment OK.

66
00:04:45,230 --> 00:04:46,720
So that is method 1.

67
00:04:46,760 --> 00:04:51,440
Number one or update the image that is used by a deployment now at the start of the video I told you

68
00:04:51,440 --> 00:04:53,420
that you're not going to see this use very frequently.

69
00:04:53,840 --> 00:04:59,270
And the reason for that is that back inside of our config file we are specifying a very precise version

70
00:04:59,330 --> 00:05:01,550
right here.

71
00:05:01,600 --> 00:05:06,580
The reason that this is a problem is that any time we want to make a change to our application or redeploy

72
00:05:06,580 --> 00:05:12,430
our application we would have to always open up this config file and make a change to that little number

73
00:05:12,460 --> 00:05:13,690
right there.

74
00:05:13,690 --> 00:05:17,870
Over time you're going to see that these deployment files start to get really really large.

75
00:05:17,980 --> 00:05:23,170
And so we really would like to not have to open up this file very often and make changes to it as every

76
00:05:23,170 --> 00:05:25,130
single time we make a change to a file.

77
00:05:25,160 --> 00:05:30,580
There's always the possibility of adding in some kind of error so it would be really great if we did

78
00:05:30,580 --> 00:05:33,760
not have to specify a version inside of here at all.

79
00:05:33,760 --> 00:05:38,890
It'd be great if we could just somehow tell communities to always use the latest version of a gimmick

80
00:05:38,950 --> 00:05:44,770
given image that would be fantastic and that's what method number two is going to be based upon we're

81
00:05:44,770 --> 00:05:48,860
gonna figure out a way to tell communities to use the latest version of an image.

82
00:05:48,940 --> 00:05:54,590
We're gonna figure out a way to tell communities to automatically update itself or we set up our deployment.

83
00:05:54,590 --> 00:05:59,880
Anytime that version changes as well or any time we create a new image as well so let's take a pause

84
00:05:59,880 --> 00:06:00,270
right here.

85
00:06:00,300 --> 00:06:02,600
We'll take a look at Method number two in just a moment.