In the last video, I covered Imperative vs. 2 2
Declarative. We talked about the specifics in Kubernetes 3 3
of one or the other. 4 4
Really, when you look at the Kubernetess documentation, it 5 5
lends itself towards three, different styles. 6 6
There's a subtle difference, but they're 7 7
really on a spectrum of all the way on imperative on one 8 8
side and all the way declarative on the other. 9 9
Then this nice, little option in the middle if you so 10 10
choose to use it. In this course, so far, 11 11
I've been teaching you the strict, imperative CLI 12 12
commands. That includes run, expose. 13 13
Maybe we have scale. 14 14
We didn't cover edit but it does exactly what you think it 15 15
would. It edits a resource in real time. 16 16
Or create deployment, which is the new way to do a run. 17 17
These are really best for learning how things 18 18
work. Learning the resource types and what they do, and 19 19
personal projects and really small setups where maybe 20 20
you're the only person in charge. You're not trying to 21 21
automate. You're not trying to build out a full production 22 22
workflow, and CICD, right. 23 23
That's great for those. 24 24
Then there's this nice middle ground that Kubernetes offers 25 25
you with the create commands 26 26
that you can either use the create commands themselves, but 27 27
you can also use those with a YAML file. 28 28
You can use create -f, and you 29 29
can give it one of those specs like we saw earlier. 30 30
You can give it a spec, and it will create any of 31 31
the objects you have in there. You could have multiple 32 32
objects in that file. You could have a deployment, plus a 33 33
service, in there. 34 34
Maybe some storage needs that you have, networking 35 35
setups, whatever. You could have all that one nice file. 36 36
Then, if you needed to replace anything in 37 37
there, you could edit the file and then use the replace 38 38
command, which we haven't covered yet, but it does what you 39 39
think it does. Then, there's the delete command, which we 40 40
have used, which does what you think it does as well. 41 41
The nice thing here is it's kind of middle ground, right. 42 42
It forces you to use YAML so that you've documented 43 43
what you're doing, and you have this change record if 44 44
you're using something like git. 45 45
Hopefully you're using git. 46 46
The benefit there, though, is for us humans, 47 47
we're using the create, or the replace, 48 48
or the delete. So, it gives us this explicit verb 49 49
to use so we know we're not accidentally 50 50
deleting something when we're using a create command. 51 51
And we know we're not accidentally deleting something when 52 52
we use the replace command. 53 53
So that helps, right. 54 54
That's a good, middle ground as you get your feet wet in 55 55
the YAML specifications that you're going to need to use 56 56
when you get to the full, declarative object 57 57
model. That is what I was talking about earlier. 58 58
That is where you're only using YAML and you're only 59 59
using the apply command. 60 60
There's other commands to help you with the apply, like the 61 61
diff, which will show you the changes you're about to take. 62 62
But, apply is simply editing 63 63
YAML, running the apply. 64 64
Edit some more YAML, run the apply. 65 65
This is similar to Swarm where we had Swarm stacks. 66 66
If you remember, there's a docker stack deploy command 67 67
and in order to update those, you use the same command over 68 68
and over and over again. 69 69
That's the same style here with their full-on declarative 70 70
objects. It's nice that they have documentation, and you'll 71 71
see this in the resource links for this lecture, a 72 72
very detailed page on these three different types. 73 73
I encourage you to check that out. 74 74
The real rule I'm going to give to this whole 75 75
thing, even if you go read the resource page about it, is 76 76
to just not mix the three approaches. 77 77
It's more important that you don't mix these three when 78 78
you have true production dependencies. 79 79
In production, I'm really going to advocate you try to 80 80
stick with, as early as you can in your 81 81
model of maturity, with the 82 82
full-on declarative model using the YAML files 83 83
with the apply command. 84 84
The sooner you get comfortable with that, the sooner you 85 85
are used to documenting that in YAML and 86 86
saving it in a git-commit every time you change it, that 87 87
process will really benefit you later on. 88 88
When anyone wants to see changes you have, they can go look 89 89
at the git-log. Most of us are probably doing something 90 90
in git today so creating another git repo just to store 91 91
these YAMLs isn't going to be a lot of effort for you, 92 92
right. Even if you're just doing git locally on your 93 93
machine, git locally can 94 94
basically help you see the history of changes that 95 95
you've done to these YAMLs so that when you forget in six 96 96
months what you changed three months ago, you can go back 97 97
and look and see what you're doing there. 98 98
That is really going to save you a lot of time. 99 99
The most important rule is don't mix the approaches. 100 100
If you create something with run, it's going to be harder 101 101
later to use the apply to manage that resource. 102 102
There are little tricks of the trade you can get around 103 103
with some of these commands to try to edit objects later 104 104
without screwing them up. 105 105
But really, if you're going to be doing production, you 106 106
probably shouldn't start with those run commands on your 107 107
production server. You should probably think long term and 108 108
stick with the YAML. My four tips here are 109 109
learning the command line like you're doing. 110 110
Learn that imperative command line so that you can operate 111 111
it locally. And you will need those commands sometimes for 112 112
troubleshooting, and testing, and servers as well. 113 113
Then as quickly as you can for getting ready for your first 114 114
production Kubernetes is to learn the apply command, 115 115
the diff command, the YAML specification 116 116
for all the resource types you're going to use. 117 117
Then storing it in git like I'm saying. 118 118
Even if it's just local git or git repos somewhere 119 119
that your team can use. 120 120
Remember, this method of editing the YAML, 121 121
saving the change in git, then applying it with 122 122
kubectl apply, then saving it again, 123 123
and storing changes in git. 124 124
This process will get you down the road 125 125
of DevOps automation and to that git-ops 126 126
that I mentioned earlier, which is I think where some of 127 127
these tools are starting to go. Where we're git centric. 128 128
We're doing changes in a git repo just like software 129 129
coders do.. 130 130
We're doing the same thing with this DevOps workflow. 131 131
We're sort of adopting the way that they do their change 132 132
work in a team for our own operations and tooling.