1
1

00:00:02,510  -->  00:00:04,769
In the last video, I covered Imperative vs.
2

2

00:00:04,770  -->  00:00:07,487
Declarative. We talked about the specifics in Kubernetes
3

3

00:00:08,250  -->  00:00:09,330
of one or the other.
4

4

00:00:09,570  -->  00:00:12,389
Really, when you look at the Kubernetess documentation, it
5

5

00:00:12,390  -->  00:00:14,595
lends itself towards three, different styles.
6

6

00:00:14,762  -->  00:00:17,879
There's a subtle difference, but they're
7

7

00:00:17,880  -->  00:00:20,879
really on a spectrum of all the way on imperative on one
8

8

00:00:20,880  -->  00:00:22,620
side and all the way declarative on the other.
9

9

00:00:22,890  -->  00:00:25,199
Then this nice, little option in the middle if you so
10

10

00:00:25,200  -->  00:00:27,209
choose to use it. In this course, so far,
11

11

00:00:28,170  -->  00:00:30,920
I've been teaching you the strict, imperative CLI
12

12

00:00:31,500  -->  00:00:34,959
commands. That includes run, expose.
13

13

00:00:35,280  -->  00:00:36,450
Maybe we have scale.
14

14

00:00:36,570  -->  00:00:38,639
We didn't cover edit but it does exactly what you think it
15

15

00:00:38,640  -->  00:00:41,130
would. It edits a resource in real time.
16

16

00:00:41,300  -->  00:00:44,220
Or create deployment, which is the new way to do a run.
17

17

00:00:44,640  -->  00:00:46,845
These are really best for learning how things
18

18

00:00:47,700  -->  00:00:50,909
work. Learning the resource types and what they do, and
19

19

00:00:51,090  -->  00:00:53,429
personal projects and really small setups where maybe
20

20

00:00:53,430  -->  00:00:56,369
you're the only person in charge. You're not trying to
21

21

00:00:56,400  -->  00:00:59,370
automate. You're not trying to build out a full production
22

22

00:00:59,580  -->  00:01:00,580
workflow, and CICD, right.
23

23

00:01:01,920  -->  00:01:03,029
That's great for those.
24

24

00:01:03,390  -->  00:01:05,440
Then there's this nice middle ground that Kubernetes offers
25

25

00:01:05,441  -->  00:01:08,219
you with the create commands
26

26

00:01:08,640  -->  00:01:11,189
that you can either use the create commands themselves, but
27

27

00:01:11,190  -->  00:01:13,260
you can also use those with a YAML file.
28

28

00:01:13,710  -->  00:01:16,739
You can use create  -f, and you
29

29

00:01:16,740  -->  00:01:19,440
can give it one of those specs like we saw earlier.
30

30

00:01:19,710  -->  00:01:22,709
You can give it a spec, and it will create any of
31

31

00:01:22,710  -->  00:01:24,449
the objects you have in there. You could have multiple
32

32

00:01:24,450  -->  00:01:26,969
objects in that file. You could have a deployment, plus a
33

33

00:01:26,970  -->  00:01:28,559
service, in there.
34

34

00:01:28,560  -->  00:01:31,559
Maybe some storage needs that you have, networking
35

35

00:01:31,560  -->  00:01:34,109
setups, whatever. You could have all that one nice file.
36

36

00:01:34,140  -->  00:01:36,198
Then, if you needed to replace anything in
37

37

00:01:37,140  -->  00:01:39,719
there, you could edit the file and then use the replace
38

38

00:01:39,720  -->  00:01:42,119
command, which we haven't covered yet, but it does what you
39

39

00:01:42,120  -->  00:01:44,579
think it does. Then, there's the delete command, which we
40

40

00:01:44,580  -->  00:01:47,040
have used, which does what you think it does as well.
41

41

00:01:47,400  -->  00:01:49,859
The nice thing here is it's kind of middle ground, right.
42

42

00:01:50,160  -->  00:01:53,519
It forces you to use YAML so that you've documented
43

43

00:01:53,550  -->  00:01:56,220
what you're doing, and you have this change record if
44

44

00:01:56,280  -->  00:01:57,280
you're using something like git.
45

45

00:01:57,540  -->  00:01:58,540
Hopefully you're using git.
46

46

00:01:58,950  -->  00:02:01,920
The benefit there, though, is for us humans,
47

47

00:02:01,980  -->  00:02:04,890
we're using the create, or the replace,
48

48

00:02:05,160  -->  00:02:08,250
or the delete. So, it gives us this explicit verb
49

49

00:02:08,310  -->  00:02:11,339
to use so we know we're not accidentally
50

50

00:02:11,340  -->  00:02:13,409
deleting something when we're using a create command.
51

51

00:02:13,680  -->  00:02:15,839
And we know we're not accidentally deleting something when
52

52

00:02:15,840  -->  00:02:17,099
we use the replace command.
53

53

00:02:17,640  -->  00:02:18,640
So that helps, right.
54

54

00:02:18,990  -->  00:02:21,734
That's a good, middle ground as you get your feet wet in
55

55

00:02:21,990  -->  00:02:24,719
the YAML specifications that you're going to need to use
56

56

00:02:25,020  -->  00:02:28,229
when you get to the full, declarative object
57

57

00:02:28,230  -->  00:02:30,870
model. That is what I was talking about earlier.
58

58

00:02:31,140  -->  00:02:34,259
That is where you're only using YAML and you're only
59

59

00:02:34,470  -->  00:02:35,789
using the apply command.
60

60

00:02:35,910  -->  00:02:38,459
There's other commands to help you with the apply, like the
61

61

00:02:38,460  -->  00:02:41,101
diff, which will show you the changes you're about to take.
62

62

00:02:41,102  -->  00:02:44,149
But, apply is simply editing
63

63

00:02:44,150  -->  00:02:45,539
YAML, running the apply.
64

64

00:02:45,780  -->  00:02:47,460
Edit some more YAML, run the apply.
65

65

00:02:47,850  -->  00:02:50,249
This is similar to Swarm where we had Swarm stacks.
66

66

00:02:50,280  -->  00:02:53,009
If you remember, there's a docker stack deploy command
67

67

00:02:53,310  -->  00:02:56,201
and in order to update those, you use the same command over
68

68

00:02:56,490  -->  00:02:57,750
and over and over again.
69

69

00:02:58,260  -->  00:03:00,942
That's the same style here with their full-on declarative
70

70

00:03:01,290  -->  00:03:04,109
objects. It's nice that they have documentation, and you'll
71

71

00:03:04,110  -->  00:03:06,560
see this in the resource links for this lecture, a
72

72

00:03:07,110  -->  00:03:10,280
very detailed page on these three different types.
73

73

00:03:10,920  -->  00:03:12,120
I encourage you to check that out.
74

74

00:03:12,660  -->  00:03:14,865
The real rule I'm going to give to this whole
75

75

00:03:15,750  -->  00:03:18,629
thing, even if you go read the resource page about it, is
76

76

00:03:18,780  -->  00:03:21,419
to just not mix the three approaches.
77

77

00:03:21,960  -->  00:03:25,080
It's more important that you don't mix these three when
78

78

00:03:25,140  -->  00:03:27,419
you have true production dependencies.
79

79

00:03:27,750  -->  00:03:30,239
In production, I'm really going to advocate you try to
80

80

00:03:30,240  -->  00:03:33,090
stick with, as early as you can in your
81

81

00:03:33,210  -->  00:03:36,150
model of maturity, with the
82

82

00:03:36,270  -->  00:03:39,450
full-on declarative model using the YAML files
83

83

00:03:39,510  -->  00:03:40,510
with the apply command.
84

84

00:03:40,830  -->  00:03:43,574
The sooner you get comfortable with that, the sooner you
85

85

00:03:43,620  -->  00:03:46,800
are used to documenting that in YAML and
86

86

00:03:47,160  -->  00:03:49,630
saving it in a git-commit every time you change it, that
87

87

00:03:51,000  -->  00:03:53,819
process will really benefit you later on.
88

88

00:03:54,030  -->  00:03:56,789
When anyone wants to see changes you have, they can go look
89

89

00:03:56,790  -->  00:03:59,819
at the git-log. Most of us are probably doing something
90

90

00:03:59,820  -->  00:04:02,515
in git today so creating another git repo just to store
91

91

00:04:02,970  -->  00:04:05,100
these YAMLs isn't going to be a lot of effort for you,
92

92

00:04:05,270  -->  00:04:07,818
right. Even if you're just doing git locally on your
93

93

00:04:08,250  -->  00:04:10,680
machine, git locally can
94

94

00:04:11,280  -->  00:04:13,730
basically help you see the history of changes that
95

95

00:04:14,340  -->  00:04:16,979
you've done to these YAMLs so that when you forget in six
96

96

00:04:16,980  -->  00:04:19,889
months what you changed three months ago, you can go back
97

97

00:04:19,890  -->  00:04:21,180
and look and see what you're doing there.
98

98

00:04:21,450  -->  00:04:23,550
That is really going to save you a lot of time.
99

99

00:04:23,580  -->  00:04:26,910
The most important rule is don't mix the approaches.
100

100

00:04:27,180  -->  00:04:30,029
If you create something with run, it's going to be harder
101

101

00:04:30,030  -->  00:04:33,359
later to use the apply to manage that resource.
102

102

00:04:33,660  -->  00:04:36,749
There are little tricks of the trade you can get around
103

103

00:04:36,750  -->  00:04:39,959
with some of these commands to try to edit objects later
104

104

00:04:39,960  -->  00:04:41,250
without screwing them up.
105

105

00:04:41,550  -->  00:04:43,829
But really, if you're going to be doing production, you
106

106

00:04:43,830  -->  00:04:46,469
probably shouldn't start with those run commands on your
107

107

00:04:46,470  -->  00:04:49,559
production server. You should probably think long term and
108

108

00:04:49,560  -->  00:04:52,379
stick with the YAML. My four tips here are
109

109

00:04:52,620  -->  00:04:54,450
learning the command line like you're doing.
110

110

00:04:54,510  -->  00:04:56,789
Learn that imperative command line so that you can operate
111

111

00:04:56,790  -->  00:04:59,209
it locally. And you will need those commands sometimes for
112

112

00:04:59,210  -->  00:05:01,750
troubleshooting, and testing, and servers as well.
113

113

00:05:02,320  -->  00:05:05,211
Then as quickly as you can for getting ready for your first
114

114

00:05:05,440  -->  00:05:08,529
production Kubernetes is to learn the apply command,
115

115

00:05:08,530  -->  00:05:10,151
the diff command, the YAML specification
116

116

00:05:11,560  -->  00:05:13,870
for all the resource types you're going to use.
117

117

00:05:14,320  -->  00:05:16,329
Then storing it in git like I'm saying.
118

118

00:05:16,360  -->  00:05:19,480
Even if it's just local git or git repos somewhere
119

119

00:05:19,510  -->  00:05:20,709
that your team can use.
120

120

00:05:20,860  -->  00:05:23,041
Remember, this method of editing the YAML,
121

121

00:05:23,890  -->  00:05:26,800
saving the change in git, then applying it with
122

122

00:05:27,010  -->  00:05:30,220
kubectl apply, then saving it again,
123

123

00:05:30,310  -->  00:05:31,633
and storing changes in git.
124

124

00:05:31,931  -->  00:05:35,019
This process will get you down the road
125

125

00:05:35,020  -->  00:05:37,672
of DevOps automation and to that git-ops
126

126

00:05:38,470  -->  00:05:41,049
that I mentioned earlier, which is I think where some of
127

127

00:05:41,050  -->  00:05:44,019
these tools are starting to go. Where we're git centric.
128

128

00:05:44,350  -->  00:05:47,499
We're doing changes in a git repo just like software
129

129

00:05:47,500  -->  00:05:48,500
coders do..
130

130

00:05:48,910  -->  00:05:51,190
We're doing the same thing with this DevOps workflow.
131

131

00:05:51,220  -->  00:05:54,519
We're sort of adopting the way that they do their change
132

132

00:05:54,520  -->  00:05:57,819
work in a team for our own operations and tooling.