1
00:00:02,560 --> 00:00:05,619
‫Let me tell you about dry runs and diff's, which

2
00:00:05,620 --> 00:00:06,820
‫is new stuff.

3
00:00:07,060 --> 00:00:09,603
‫The last few versions of Kubernetes starting with 1.13

4
00:00:10,300 --> 00:00:13,269
‫have this new option that allows us to see

5
00:00:13,270 --> 00:00:16,179
‫what we're going to change before we change it.

6
00:00:16,600 --> 00:00:18,269
‫We've seen that before.

7
00:00:18,280 --> 00:00:20,350
‫I've showed you a couple examples earlier in the course.

8
00:00:20,680 --> 00:00:23,739
‫But, this method of using it with

9
00:00:23,740 --> 00:00:26,739
‫the apply command is new and

10
00:00:26,800 --> 00:00:29,500
‫better. What we had in the past

11
00:00:29,860 --> 00:00:32,798
‫was we had a dry run, but it was only

12
00:00:32,860 --> 00:00:35,109
‫on the client. The client didn't actually talk to the

13
00:00:35,110 --> 00:00:37,409
‫server to say hey, are these resources already there?

14
00:00:38,830 --> 00:00:41,379
‫Do I need to recreate them, or are they going to be updated

15
00:00:41,380 --> 00:00:42,490
‫or what's going to happen? Right.

16
00:00:43,210 --> 00:00:44,439
‫That didn't happen before.

17
00:00:44,470 --> 00:00:47,050
‫Now there's a server dry run option

18
00:00:47,830 --> 00:00:50,979
‫that will send our YAML to the server and

19
00:00:50,980 --> 00:00:53,890
‫compare, figure out what needs to actually happen

20
00:00:54,160 --> 00:00:56,559
‫and then report back to the command line what's going to

21
00:00:56,560 --> 00:00:58,630
‫change. Let's see that in action.

22
00:00:58,960 --> 00:01:02,319
‫I'm in the K8s YAML directory like I discussed earlier

23
00:01:02,320 --> 00:01:05,829
‫in a lecture, if you are in Docker Mastery's repo

24
00:01:05,830 --> 00:01:07,741
‫and you don't have this directory, then

25
00:01:08,890 --> 00:01:11,150
‫you need to do a git-pull to get the latest updates.

26
00:01:11,730 --> 00:01:13,334
‫This is a file that we've seen in a previous lecture,

27
00:01:13,335 --> 00:01:16,359
‫app.yml. This is a service, plus

28
00:01:16,360 --> 00:01:17,769
‫a deployment, in one file.

29
00:01:17,770 --> 00:01:20,740
‫It's technically two resources are created with one

30
00:01:20,770 --> 00:01:23,319
‫apply command and they're related.

31
00:01:23,620 --> 00:01:26,168
‫The service uses a selector, which we haven't talked

32
00:01:26,680 --> 00:01:30,069
‫about yet. Selectors are how one object

33
00:01:30,550 --> 00:01:33,629
‫finds the resources that it wants to talk to

34
00:01:33,640 --> 00:01:34,870
‫or do something with.

35
00:01:34,900 --> 00:01:37,448
‫A service needs to talk to pods, so it needs to find

36
00:01:38,140 --> 00:01:39,189
‫a way to get to those.

37
00:01:39,460 --> 00:01:41,979
‫It uses selectors as essentially

38
00:01:42,460 --> 00:01:45,204
‫pattern matching to match the labels the keys and values

39
00:01:45,670 --> 00:01:48,700
‫there. If I did the traditional dry run here,

40
00:01:49,150 --> 00:01:52,480
‫then all it would do is the client would look at the apply

41
00:01:52,510 --> 00:01:54,790
‫and say, yeah, I'm going to create these objects.

42
00:01:55,150 --> 00:01:57,519
‫All right. It's always going to come back and say created.

43
00:01:57,880 --> 00:02:01,059
‫That's because the apply is not

44
00:02:01,060 --> 00:02:03,951
‫very specific. If you were using an update, or a create, or

45
00:02:03,970 --> 00:02:06,273
‫a delete command, which again I don't feel like

46
00:02:07,090 --> 00:02:09,399
‫is a very DevOps-based workflow.

47
00:02:09,880 --> 00:02:12,575
‫Those commands would just do a dry run and you know the

48
00:02:12,820 --> 00:02:14,409
‫update one would say yeah, they're both going to be

49
00:02:14,410 --> 00:02:17,050
‫updated. But, it doesn't really know on your cluster,

50
00:02:17,080 --> 00:02:18,880
‫right. It hasn't talked to the server to figure that out.

51
00:02:19,180 --> 00:02:21,091
‫We want to try the server dry run which

52
00:02:22,180 --> 00:02:24,729
‫is enabled by default on anything 1.13 and newer.

53
00:02:25,270 --> 00:02:27,916
‫When I do that, it will then go talk to the server and

54
00:02:28,270 --> 00:02:29,379
‫give me a proper response.

55
00:02:29,770 --> 00:02:31,629
‫Let's go ahead and create this.

56
00:02:31,850 --> 00:02:33,819
‫I'm going to take off the server dry run.

57
00:02:34,920 --> 00:02:37,839
‫This will create the two resources, the deployment

58
00:02:37,960 --> 00:02:38,960
‫and the service.

59
00:02:39,430 --> 00:02:42,249
‫Now, if I hit the up arrow and go back to server dry run,

60
00:02:43,180 --> 00:02:45,729
‫you'll see that it says unchanged for both of them.

61
00:02:46,060 --> 00:02:48,849
‫It's not telling me what changed or

62
00:02:49,120 --> 00:02:50,859
‫if there was something that was going to change what it

63
00:02:50,860 --> 00:02:53,506
‫would be. It's just telling me that a resource will be

64
00:02:53,680 --> 00:02:56,379
‫changed or not changed. It's sort of a toggle, yes or no.

65
00:02:56,860 --> 00:03:00,219
‫What about getting the actual difference between

66
00:03:00,220 --> 00:03:02,768
‫what we want to give the server and what the current

67
00:03:03,400 --> 00:03:05,469
‫status is of our resources.

68
00:03:05,530 --> 00:03:07,900
‫That is the kubectl diff command.

69
00:03:08,080 --> 00:03:11,199
‫If I simply give it a diff instead of an apply,

70
00:03:11,560 --> 00:03:14,590
‫it will compare the YAML I have to

71
00:03:14,650 --> 00:03:17,879
‫the spec that is in the servers

72
00:03:17,920 --> 00:03:20,889
‫now running. that status comes back, and it will do

73
00:03:20,890 --> 00:03:22,671
‫a diff on that. Let's do that.

74
00:03:22,790 --> 00:03:24,699
‫It'll say nothing because there is no difference.

75
00:03:24,730 --> 00:03:25,740
‫But what if we go change the YAML?

76
00:03:28,642 --> 00:03:31,560
‫What if I change the replicas to two?

77
00:03:32,030 --> 00:03:35,180
‫Then I add a label in the metadata and

78
00:03:35,210 --> 00:03:37,415
‫I'll give it something like...something like.

79
00:03:38,110 --> 00:03:39,320
‫Servers dmz.

80
00:03:40,300 --> 00:03:41,490
‫I made it up. Doesn't really matter.

81
00:03:42,460 --> 00:03:43,840
‫Then we have the replicas of two.

82
00:03:44,680 --> 00:03:47,889
‫If I do that same diff, it comes back with

83
00:03:48,400 --> 00:03:49,460
‫the pluses and minuses.

84
00:03:49,500 --> 00:03:51,879
‫If you're used to reading diff's, this makes perfect sense

85
00:03:51,880 --> 00:03:54,909
‫to you. If you're not used to diff's, the minus

86
00:03:54,910 --> 00:03:56,559
‫means that line would go away.

87
00:03:57,105 --> 00:03:59,139
‫Then these lines would be added.

88
00:03:59,920 --> 00:04:03,249
‫Then down here, it shows you what line

89
00:04:03,250 --> 00:04:05,357
‫and what character in the line that this is

90
00:04:06,250 --> 00:04:07,185
‫being removed.

91
00:04:07,186 --> 00:04:08,379
‫This is being added.

92
00:04:08,770 --> 00:04:11,650
‫It's keeping the YAML formatting, which is nice.

93
00:04:11,920 --> 00:04:13,870
‫It's letting us know that multiple changes are happening.

94
00:04:14,170 --> 00:04:17,349
‫Great. Of course, this isn't really doing something like

95
00:04:18,220 --> 00:04:20,379
‫a canary, or test deployment or anything.

96
00:04:20,589 --> 00:04:23,679
‫It's not trying to do the thing and then seeing

97
00:04:23,680 --> 00:04:26,179
‫what the result is. It's really just looking at the

98
00:04:26,290 --> 00:04:29,109
‫specification it has on record, and the specification that

99
00:04:29,110 --> 00:04:30,629
‫we have on our disk.  Check for

100
00:04:32,140 --> 00:04:34,540
‫more info on that on the resources links.

101
00:04:34,570 --> 00:04:37,069
‫It's a blog article from the Kubernetes team on the

102
00:04:37,570 --> 00:04:40,209
‫future of these and how they're going to play out as they

103
00:04:40,210 --> 00:04:42,879
‫come out of beta. Remember, these features right now are

104
00:04:42,880 --> 00:04:44,920
‫beta, at least in 1.15 they are.

105
00:04:45,340 --> 00:04:48,339
‫Hopefully with that, you can create your own workflow

106
00:04:48,580 --> 00:04:50,832
‫for creating YAMLs from scratch, Managing

107
00:04:52,090 --> 00:04:55,420
‫the specs in those YAMLs, and then using the apply command

108
00:04:55,450 --> 00:04:57,819
‫over and over to make your changes.

109
00:04:58,060 --> 00:05:01,089
‫That's a much more DevOps friendly infrastructure as

110
00:05:01,090 --> 00:05:02,889
‫code type of way of doing it.

111
00:05:03,190 --> 00:05:05,206
‫Everything you do is documented, hopefully in Git.

112
00:05:05,520 --> 00:05:08,319
‫So, you're hopefully making a git-commit for each change

113
00:05:08,320 --> 00:05:10,839
‫you make in your YAML before deploying it to the server.

114
00:05:11,290 --> 00:05:14,010
‫Then you have that nice documentation in Git,

115
00:05:14,830 --> 00:05:17,623
‫as well as the documentation when you do something like a

116
00:05:17,710 --> 00:05:20,139
‫diff to see what you have versus what's actually running.