WEBVTT

1
00:00:00.040 --> 00:00:02.359
<v Speaker 1>Hey, everyone, get ready for a wild ride because we're

2
00:00:02.399 --> 00:00:05.480
<v Speaker 1>diving deep into modern DevOps. We've got a ton of

3
00:00:05.480 --> 00:00:10.400
<v Speaker 1>stuff to unpack today, from Docker and Kubernetes to infrastructure automation,

4
00:00:10.800 --> 00:00:11.599
<v Speaker 1>even get ops.

5
00:00:11.679 --> 00:00:13.720
<v Speaker 2>Yeah, it's a lot to cover, but it's all connected,

6
00:00:14.000 --> 00:00:14.439
<v Speaker 2>it is.

7
00:00:14.519 --> 00:00:16.359
<v Speaker 1>And it seems like you all are really serious about

8
00:00:16.440 --> 00:00:19.359
<v Speaker 1>leveling up your DevOps game, which I love to see.

9
00:00:19.640 --> 00:00:21.399
<v Speaker 1>You know. One thing that really caught my eye was

10
00:00:21.399 --> 00:00:25.920
<v Speaker 1>this idea of running containers without a full operating.

11
00:00:25.440 --> 00:00:27.000
<v Speaker 2>System distreless images.

12
00:00:27.440 --> 00:00:31.000
<v Speaker 1>They're pretty slight distreless, right, It's amazing how much innovation

13
00:00:31.079 --> 00:00:33.520
<v Speaker 1>is happening in this space. But okay, before we get

14
00:00:33.600 --> 00:00:38.079
<v Speaker 1>hit ourselves, let's back up for a sec. Containers, Docker, Kubernetes.

15
00:00:38.520 --> 00:00:41.359
<v Speaker 1>It's a lot to digest, especially if you're just getting started.

16
00:00:41.520 --> 00:00:44.840
<v Speaker 2>You're telling me there's a reason people write entire books about.

17
00:00:44.560 --> 00:00:47.240
<v Speaker 1>This stuff exactly, But hey, that's what we're here for

18
00:00:47.359 --> 00:00:49.679
<v Speaker 1>to break it all down now. One article mentioned this

19
00:00:49.799 --> 00:00:53.600
<v Speaker 1>matrix of hell problem that containers solve. It sounds intense,

20
00:00:53.719 --> 00:00:55.840
<v Speaker 1>to say the least. What's the deal with that?

21
00:00:56.079 --> 00:00:58.960
<v Speaker 2>Oh? The matrix of hell? Yeah, that's a classic problem,

22
00:00:59.039 --> 00:01:03.759
<v Speaker 2>especially for developers. Imagine trying to manage dependencies for multiple applications,

23
00:01:03.759 --> 00:01:07.000
<v Speaker 2>all running on the same server. One app needs this

24
00:01:07.159 --> 00:01:10.680
<v Speaker 2>version of a library, another needs a different version. It

25
00:01:10.719 --> 00:01:12.680
<v Speaker 2>can quickly turn into a nightmare.

26
00:01:12.920 --> 00:01:15.439
<v Speaker 1>I can imagine. It's like trying to fit puzzle pieces

27
00:01:15.439 --> 00:01:16.480
<v Speaker 1>that don't quite match.

28
00:01:16.760 --> 00:01:19.400
<v Speaker 2>That's a good way to put it. Containers and Docker

29
00:01:19.400 --> 00:01:23.079
<v Speaker 2>in particular, offer this elegant solution by packaging your application

30
00:01:23.200 --> 00:01:25.920
<v Speaker 2>and all its dependencies into a self contained unit.

31
00:01:26.239 --> 00:01:27.959
<v Speaker 1>So no more dependency clashes.

32
00:01:28.120 --> 00:01:31.200
<v Speaker 2>Right. Each container is like its own little world, isolated

33
00:01:31.239 --> 00:01:34.359
<v Speaker 2>from everything else. And that's the beauty of dockers build once,

34
00:01:34.519 --> 00:01:39.400
<v Speaker 2>run anywhere philosophy. Whether it's your development machine, a testing environment,

35
00:01:39.519 --> 00:01:42.200
<v Speaker 2>or in production, your code behaves the same way.

36
00:01:42.319 --> 00:01:46.480
<v Speaker 1>That's huge. It simplifies so much from development to deployment. Okay,

37
00:01:46.519 --> 00:01:49.680
<v Speaker 1>so how about we unpack Docker a bit more. The

38
00:01:49.719 --> 00:01:53.480
<v Speaker 1>source material mentioned images, containers, registries, it's a.

39
00:01:53.480 --> 00:01:56.480
<v Speaker 2>Lot of jargon, true, but it's not as complicated as

40
00:01:56.519 --> 00:01:59.400
<v Speaker 2>it might sound. Think of a Docker image as a

41
00:01:59.439 --> 00:02:03.079
<v Speaker 2>blueprint for your application. It captures everything needed to run

42
00:02:03.120 --> 00:02:07.640
<v Speaker 2>your code, the operating system, libraries, dependencies, and of course

43
00:02:07.680 --> 00:02:08.719
<v Speaker 2>the application itself.

44
00:02:08.800 --> 00:02:12.319
<v Speaker 1>Got it. The image is the master plan, so to speak. Yeah,

45
00:02:12.360 --> 00:02:13.400
<v Speaker 1>what about containers.

46
00:02:13.520 --> 00:02:16.719
<v Speaker 2>A container is a running instance of that image. It's

47
00:02:16.759 --> 00:02:19.240
<v Speaker 2>like you take the blueprint and you create a live,

48
00:02:19.479 --> 00:02:22.400
<v Speaker 2>working copy of your application from It makes sense.

49
00:02:22.639 --> 00:02:25.080
<v Speaker 1>So where do registries come into play.

50
00:02:25.280 --> 00:02:29.439
<v Speaker 2>Registries are like libraries for Docker images. Think Docker Hub

51
00:02:29.479 --> 00:02:32.879
<v Speaker 2>for example. You can share your images publicly or privately,

52
00:02:33.000 --> 00:02:35.080
<v Speaker 2>making it easy for others to use them or for

53
00:02:35.159 --> 00:02:37.240
<v Speaker 2>you to deploy them across different environments.

54
00:02:37.319 --> 00:02:40.680
<v Speaker 1>It's like a central hub for all things Docker. Super convenient,

55
00:02:40.759 --> 00:02:43.240
<v Speaker 1>especially when you need to share images across teams or

56
00:02:43.280 --> 00:02:45.639
<v Speaker 1>to play different environments. Now, this is this other term

57
00:02:45.680 --> 00:02:49.599
<v Speaker 1>that keeps popping up Docker file. It sounds kind of mysterious.

58
00:02:49.919 --> 00:02:51.280
<v Speaker 1>Was the secret sauce behind it?

59
00:02:51.560 --> 00:02:55.639
<v Speaker 2>Not so mysterious really, It's basically a script that tells

60
00:02:55.680 --> 00:02:58.400
<v Speaker 2>Docker how to build your image. You list out all

61
00:02:58.439 --> 00:03:03.240
<v Speaker 2>the steps like installing soft where, copying files, setting environment variables.

62
00:03:03.879 --> 00:03:06.639
<v Speaker 2>It's like writing down a recipe for your perfect server environment.

63
00:03:06.879 --> 00:03:09.479
<v Speaker 1>Ah, a recipe analogy, and you can get behind that.

64
00:03:09.560 --> 00:03:11.479
<v Speaker 1>It's like saying, okay, doctor, I need to start with

65
00:03:11.520 --> 00:03:14.240
<v Speaker 1>this base image, then add this, then do that, and

66
00:03:14.560 --> 00:03:17.319
<v Speaker 1>what you've got your custom image ready to go exactly.

67
00:03:17.840 --> 00:03:20.280
<v Speaker 2>And a key concept here is the layered file system.

68
00:03:20.800 --> 00:03:23.599
<v Speaker 2>Each instruction in your docer file creates a new layer

69
00:03:23.639 --> 00:03:27.080
<v Speaker 2>in the image. This makes Docker super efficient because if

70
00:03:27.120 --> 00:03:29.719
<v Speaker 2>you change just one line of code, you don't have

71
00:03:29.800 --> 00:03:31.240
<v Speaker 2>to rebuild the entire image.

72
00:03:31.280 --> 00:03:33.800
<v Speaker 1>That's brilliant. It only rebuilds the layer that changed.

73
00:03:34.000 --> 00:03:35.919
<v Speaker 2>Yep, much faster and more efficient.

74
00:03:36.000 --> 00:03:39.120
<v Speaker 1>Love it. But there's always a butt, isn't there?

75
00:03:39.199 --> 00:03:42.759
<v Speaker 2>Huh huh. Usually it's important to be mindful of image size.

76
00:03:43.080 --> 00:03:45.560
<v Speaker 2>The more layers you add, the bigger your image becomes,

77
00:03:45.919 --> 00:03:48.800
<v Speaker 2>and bulky images can slow down builds and diplomas.

78
00:03:49.039 --> 00:03:52.479
<v Speaker 1>So it's all about finding that sweet spot between efficiency

79
00:03:52.680 --> 00:03:53.800
<v Speaker 1>and keeping things lean.

80
00:03:54.159 --> 00:03:56.840
<v Speaker 2>You got it. And that's where those destrollss images we

81
00:03:56.879 --> 00:04:00.479
<v Speaker 2>mentioned earlier come in. Instead of including a full operating system,

82
00:04:00.639 --> 00:04:03.240
<v Speaker 2>they only package the bare minimum needed to run your

83
00:04:03.240 --> 00:04:04.439
<v Speaker 2>application right.

84
00:04:04.360 --> 00:04:07.199
<v Speaker 1>And that not only makes them smaller and faster, but

85
00:04:07.240 --> 00:04:09.400
<v Speaker 1>it also enhances security.

86
00:04:08.960 --> 00:04:13.240
<v Speaker 2>Right, absolutely, smaller attack surface, fewer vulnerabilities. It's a win

87
00:04:13.319 --> 00:04:14.120
<v Speaker 2>win situation.

88
00:04:14.400 --> 00:04:18.480
<v Speaker 1>It's amazing how much thought goes into optimizing these containerized environments.

89
00:04:18.560 --> 00:04:19.920
<v Speaker 1>It's a fascinating world, it.

90
00:04:19.879 --> 00:04:22.399
<v Speaker 2>Really is, and it's only getting more sophisticated as we

91
00:04:22.480 --> 00:04:26.040
<v Speaker 2>move into the world of container orchestration with Kubernetes. But

92
00:04:26.120 --> 00:04:29.160
<v Speaker 2>we'll save that for another time. Okay, so you're ready

93
00:04:29.160 --> 00:04:31.160
<v Speaker 2>to dive into Kubernetes, ready.

94
00:04:30.879 --> 00:04:33.759
<v Speaker 1>As I'll ever be. We talked about Docker packaging up

95
00:04:33.759 --> 00:04:37.160
<v Speaker 1>our applications nicely, but what happens when we need to

96
00:04:37.199 --> 00:04:41.600
<v Speaker 1>manage hundreds, even thousands of these containers. It's like needing

97
00:04:41.639 --> 00:04:43.639
<v Speaker 1>an air traffic controller for our software.

98
00:04:43.920 --> 00:04:46.480
<v Speaker 2>Perfect analogy, and that's where Kubernetes comes in. It's our

99
00:04:46.480 --> 00:04:51.519
<v Speaker 2>container orchestrator, extraordinary, keeping everything running smoothly even at scale.

100
00:04:51.720 --> 00:04:55.920
<v Speaker 1>Right orchestration. It's like Kubernetes is conducting this massive symphony

101
00:04:56.040 --> 00:04:58.639
<v Speaker 1>of containers, making sure they all play together in.

102
00:04:58.600 --> 00:05:01.759
<v Speaker 2>Harmony exactly, And just like a conductor needs a score,

103
00:05:02.160 --> 00:05:05.519
<v Speaker 2>Kubernetes relies on a control plane to make decisions about

104
00:05:05.519 --> 00:05:06.560
<v Speaker 2>how the system runs.

105
00:05:06.720 --> 00:05:08.800
<v Speaker 1>Control plane, what's that exactly?

106
00:05:08.879 --> 00:05:11.680
<v Speaker 2>Give it like the brains of the operation. It's responsible

107
00:05:11.680 --> 00:05:15.360
<v Speaker 2>for things like scheduling containers, managing resources, and making sure

108
00:05:15.439 --> 00:05:17.040
<v Speaker 2>everything is running as it should.

109
00:05:17.160 --> 00:05:19.600
<v Speaker 1>Okay, so it's calling the shots, yeah, but it can't

110
00:05:19.639 --> 00:05:21.720
<v Speaker 1>do everything itself right, There's got to be some muscle

111
00:05:21.759 --> 00:05:22.879
<v Speaker 1>involved too, exactly.

112
00:05:23.079 --> 00:05:25.800
<v Speaker 2>That's where worker nodes come in. They're the workhourses of

113
00:05:25.839 --> 00:05:29.040
<v Speaker 2>the system actually running the containers and your applications.

114
00:05:29.160 --> 00:05:32.839
<v Speaker 1>So control plane makes the plans and the worker nodes execute.

115
00:05:32.399 --> 00:05:37.600
<v Speaker 2>Them precisely and to keep things organized. Kubernetes uses this concept.

116
00:05:37.319 --> 00:05:40.319
<v Speaker 1>Of a pod, a pod like a pea.

117
00:05:40.199 --> 00:05:43.759
<v Speaker 2>Pod kind of. It's basically a group of one or

118
00:05:43.759 --> 00:05:46.800
<v Speaker 2>more containers that are deployed together. Think of them as

119
00:05:46.879 --> 00:05:48.480
<v Speaker 2>logical units of your application.

120
00:05:48.800 --> 00:05:53.040
<v Speaker 1>Interesting, so instead of managing individual containers, Kubernetes works with

121
00:05:53.079 --> 00:05:55.079
<v Speaker 1>these pods. Why group them like that?

122
00:05:55.439 --> 00:05:59.920
<v Speaker 2>It simplifies things. Pods share resources and networking, making it

123
00:06:00.040 --> 00:06:02.839
<v Speaker 2>easier to manage applications with multiple components.

124
00:06:03.079 --> 00:06:06.720
<v Speaker 1>That makes sense. Now, what about resources? With so many

125
00:06:06.720 --> 00:06:10.600
<v Speaker 1>containers vying for attention? How does Kubernetes keep things fair?

126
00:06:11.000 --> 00:06:14.480
<v Speaker 2>Resource management is huge. We can actually specify how much

127
00:06:14.519 --> 00:06:18.800
<v Speaker 2>CPU and memory each pod needs. This prevents one application

128
00:06:18.879 --> 00:06:22.560
<v Speaker 2>from hogging all the resources and ensures that everything runs smoothly.

129
00:06:23.000 --> 00:06:26.639
<v Speaker 1>That's super important, especially in production environments where stability is key.

130
00:06:26.839 --> 00:06:30.920
<v Speaker 2>Right, and this ties into another amazing Kubernetes feature, autoscaling.

131
00:06:31.399 --> 00:06:34.279
<v Speaker 1>Ooh, tell me more about this auto scaling magic.

132
00:06:34.439 --> 00:06:37.199
<v Speaker 2>It's like having a magic wand that automatically scales your

133
00:06:37.199 --> 00:06:40.120
<v Speaker 2>applications up or down based on demand. You set some

134
00:06:40.240 --> 00:06:42.240
<v Speaker 2>rules and Kubernetes handles the rest.

135
00:06:42.360 --> 00:06:45.560
<v Speaker 1>So if my website suddenly gets a surge traffic, Kubernetes

136
00:06:45.600 --> 00:06:47.759
<v Speaker 1>will spin up more pods to handle the load.

137
00:06:47.759 --> 00:06:51.160
<v Speaker 2>Exactly, and when things quiet down, it scales back down

138
00:06:51.279 --> 00:06:52.399
<v Speaker 2>to save resources.

139
00:06:52.480 --> 00:06:55.639
<v Speaker 1>That's incredible. No more scrambling to provision news servers in

140
00:06:55.680 --> 00:06:57.839
<v Speaker 1>the middle of the night. It's like having an army

141
00:06:57.879 --> 00:06:59.879
<v Speaker 1>of tiny helpers that adjust everything on the fly.

142
00:07:00.240 --> 00:07:01.839
<v Speaker 2>That's a great way to think about it. But hold on,

143
00:07:01.879 --> 00:07:04.800
<v Speaker 2>it gets even better. We can also use Kubernetes to

144
00:07:04.879 --> 00:07:07.079
<v Speaker 2>manage stateful application.

145
00:07:07.120 --> 00:07:10.319
<v Speaker 1>Stateful applications, now you're just thrown around fancy terms. What

146
00:07:10.360 --> 00:07:10.720
<v Speaker 1>are those?

147
00:07:10.839 --> 00:07:13.839
<v Speaker 2>Uh huh? Sorry, It just means applications that need to

148
00:07:13.839 --> 00:07:16.279
<v Speaker 2>store data persistently like databases.

149
00:07:16.480 --> 00:07:20.079
<v Speaker 1>Ah right, that makes sense. But how do you handle

150
00:07:20.120 --> 00:07:23.319
<v Speaker 1>that in a containerized environment where containers can be created

151
00:07:23.360 --> 00:07:24.480
<v Speaker 1>and destroyed quickly?

152
00:07:24.639 --> 00:07:29.000
<v Speaker 2>Good question. Kubernetes provides a solution called persistent volumes.

153
00:07:29.160 --> 00:07:33.639
<v Speaker 1>Persistent volumes like dedicated storage units that our applications can

154
00:07:33.680 --> 00:07:36.040
<v Speaker 1>access even if a pod is deleted and.

155
00:07:36.000 --> 00:07:39.759
<v Speaker 2>Recreated, Precisely, the data lives on no matter what happens

156
00:07:39.800 --> 00:07:40.439
<v Speaker 2>to the container.

157
00:07:40.800 --> 00:07:43.639
<v Speaker 1>That's a game changer for running databases or anything else

158
00:07:43.639 --> 00:07:46.839
<v Speaker 1>that needs persistent storage. I'm starting to see why Kubernetes

159
00:07:46.839 --> 00:07:47.920
<v Speaker 1>gets people so excited.

160
00:07:48.000 --> 00:07:50.480
<v Speaker 2>It's pretty powerful stuff, but it can also be a

161
00:07:50.480 --> 00:07:53.600
<v Speaker 2>bit overwhelming, especially at first. That's why having the right

162
00:07:53.639 --> 00:07:57.040
<v Speaker 2>tools is so essential. And speaking of tools, we have

163
00:07:57.079 --> 00:07:58.240
<v Speaker 2>to talk about quebectyl.

164
00:07:58.399 --> 00:08:01.519
<v Speaker 1>Kubectyl, what's like a mythical creature. What is it?

165
00:08:01.839 --> 00:08:05.079
<v Speaker 2>Huh huh, not quite. It's the command line tool we

166
00:08:05.160 --> 00:08:07.160
<v Speaker 2>use to interact with our Kubernetes cluster.

167
00:08:07.319 --> 00:08:10.839
<v Speaker 1>So it's our magic wand for controlling the Kubernetes orchestra exactly.

168
00:08:10.879 --> 00:08:14.680
<v Speaker 2>We can use it to deploy applications, inspec logs, manage resources,

169
00:08:14.720 --> 00:08:15.720
<v Speaker 2>dot you name it.

170
00:08:15.720 --> 00:08:18.600
<v Speaker 1>It sounds essential. Any tips for taming this beast?

171
00:08:18.759 --> 00:08:23.399
<v Speaker 2>Absolutely? Creating aliases for frequently used commands is a lifesaver.

172
00:08:23.920 --> 00:08:27.240
<v Speaker 2>For example, instead of typing, quebec will get pods every time.

173
00:08:27.560 --> 00:08:30.040
<v Speaker 2>You could set an alias like kgph.

174
00:08:30.279 --> 00:08:33.600
<v Speaker 1>Like that, short and sweet, any other productivity hacks you

175
00:08:33.600 --> 00:08:34.000
<v Speaker 1>can share.

176
00:08:34.159 --> 00:08:38.279
<v Speaker 2>Definitely try using the oyamel flag when you're retrieving information

177
00:08:38.360 --> 00:08:42.559
<v Speaker 2>about resources. This gives you the resource definition in yamal format.

178
00:08:42.639 --> 00:08:45.279
<v Speaker 2>Which you can then modify and reapply to the cluster.

179
00:08:45.399 --> 00:08:47.879
<v Speaker 1>Y eddie, It's like getting a template to work with exactly.

180
00:08:47.960 --> 00:08:49.480
<v Speaker 2>It's all about working smarter.

181
00:08:49.360 --> 00:08:52.799
<v Speaker 1>Not harder. Well said, I'm feeling much more confident about

182
00:08:52.919 --> 00:08:56.279
<v Speaker 1>navigating the world of containers and orchestration now, but we

183
00:08:56.320 --> 00:08:58.960
<v Speaker 1>can't forget about the bigger picture, right, How do we

184
00:08:59.000 --> 00:09:01.960
<v Speaker 1>actually get our code into these containers and deployed to

185
00:09:01.960 --> 00:09:02.600
<v Speaker 1>our clusters.

186
00:09:02.879 --> 00:09:07.320
<v Speaker 2>That's where CICD comes in. Continuous integration and continuous delivery

187
00:09:07.360 --> 00:09:11.120
<v Speaker 2>are crucial for automating our development workflows and getting our

188
00:09:11.159 --> 00:09:14.039
<v Speaker 2>software into the hands of users quickly and reliably.

189
00:09:14.159 --> 00:09:16.399
<v Speaker 1>Okay, so we've covered a lot of ground. We talked

190
00:09:16.399 --> 00:09:20.000
<v Speaker 1>about Docker, building those containers, Kubernetes, orchestrating them like a

191
00:09:20.000 --> 00:09:23.360
<v Speaker 1>well oiled machine, and even dove into the importance of

192
00:09:23.480 --> 00:09:27.240
<v Speaker 1>CICD insecurity. Now let's circle back to this GitOps thing.

193
00:09:27.720 --> 00:09:29.799
<v Speaker 1>It's still kind of a mystery to me, to be honest.

194
00:09:30.000 --> 00:09:32.240
<v Speaker 2>Yeah, it can seem a bit abstract at first, but

195
00:09:32.279 --> 00:09:34.519
<v Speaker 2>it's really about bringing the power of get to our

196
00:09:34.519 --> 00:09:40.320
<v Speaker 2>infrastructure management. Imagine this, Your Git repository becomes the single

197
00:09:40.399 --> 00:09:44.159
<v Speaker 2>source of truth for your entire system. Every change, every update,

198
00:09:44.200 --> 00:09:46.360
<v Speaker 2>every tweak, all tracked and get.

199
00:09:46.320 --> 00:09:49.159
<v Speaker 1>So no more logging into servers directly and making changes

200
00:09:49.159 --> 00:09:51.960
<v Speaker 1>on the fly. Everything goes through GIT precisely.

201
00:09:52.120 --> 00:09:54.879
<v Speaker 2>And that's where fluxd comes in. It acts as this

202
00:09:55.039 --> 00:09:58.639
<v Speaker 2>bridge between our Git repository and our Kubernetes cluster, ensuring

203
00:09:58.639 --> 00:10:01.399
<v Speaker 2>that what's in Git is exis exactly what's running in production.

204
00:10:01.600 --> 00:10:04.799
<v Speaker 1>So flux is constantly watching our GIT repo for any changes,

205
00:10:05.240 --> 00:10:08.120
<v Speaker 1>and when it sees something new, it automatically applies those

206
00:10:08.200 --> 00:10:10.519
<v Speaker 1>changes to our cluster. You got it.

207
00:10:10.519 --> 00:10:13.200
<v Speaker 2>It's like having an automated deployment pipeline that's always on,

208
00:10:13.360 --> 00:10:14.080
<v Speaker 2>always watching.

209
00:10:14.320 --> 00:10:18.679
<v Speaker 1>That sounds incredibly powerful and maybe a little dangerous with

210
00:10:18.840 --> 00:10:21.919
<v Speaker 1>stopping someone from accidentally pushing a bad change to get

211
00:10:22.279 --> 00:10:23.320
<v Speaker 1>and breaking everything.

212
00:10:23.919 --> 00:10:26.679
<v Speaker 2>Don't worry, We've got safeguards in place. Remember how we

213
00:10:26.720 --> 00:10:31.039
<v Speaker 2>talked about those rigorous CICD pipelines. They're still crucial. Before

214
00:10:31.080 --> 00:10:33.000
<v Speaker 2>any change makes it to the main branch of our

215
00:10:33.000 --> 00:10:37.000
<v Speaker 2>GIT repository, it goes through code reviews, automated testing, the

216
00:10:37.000 --> 00:10:37.840
<v Speaker 2>whole nine yards.

217
00:10:37.919 --> 00:10:41.759
<v Speaker 1>Ah, So it's all about layers of checks and balances exactly.

218
00:10:41.840 --> 00:10:44.679
<v Speaker 2>We're not sacrificing safety for speed here and with FLUX,

219
00:10:44.720 --> 00:10:47.279
<v Speaker 2>we can actually choose how we want to trigger deployment.

220
00:10:47.360 --> 00:10:48.840
<v Speaker 1>There's more than one way, yep.

221
00:10:48.960 --> 00:10:50.759
<v Speaker 2>We can either use a push model.

222
00:10:50.600 --> 00:10:52.120
<v Speaker 1>Or a poll model push visible.

223
00:10:52.360 --> 00:10:55.879
<v Speaker 2>In the push model, our CICD pipeline pushes the changes

224
00:10:55.919 --> 00:10:58.960
<v Speaker 2>to the cluster and flux CD listens for those changes.

225
00:10:59.480 --> 00:11:01.960
<v Speaker 2>But the real cool way, the more get ops way,

226
00:11:02.399 --> 00:11:03.240
<v Speaker 2>is the pole model.

227
00:11:03.399 --> 00:11:06.159
<v Speaker 1>Okay, I'm intrigued. What's so special about this pole model.

228
00:11:06.399 --> 00:11:09.960
<v Speaker 2>In the pole model, FLUXD lives inside our Kubernetes cluster,

229
00:11:10.399 --> 00:11:14.799
<v Speaker 2>constantly monitoring our git repository. When it detects a difference,

230
00:11:15.240 --> 00:11:18.200
<v Speaker 2>it pulls those changes in and applies them automatically.

231
00:11:18.360 --> 00:11:21.320
<v Speaker 1>So it's like our clusters reaching out to get and saying, hey,

232
00:11:21.799 --> 00:11:23.840
<v Speaker 1>anything new for me? I need to stay up to date.

233
00:11:23.919 --> 00:11:25.759
<v Speaker 2>That's a great way to put it. The cluster is

234
00:11:25.799 --> 00:11:27.480
<v Speaker 2>in charge of his own destiny in a way.

235
00:11:27.799 --> 00:11:30.279
<v Speaker 1>I like that. It feels very much in line with

236
00:11:30.320 --> 00:11:34.600
<v Speaker 1>this whole GitOps philosophy of treating infrastructure as code. But

237
00:11:34.639 --> 00:11:37.720
<v Speaker 1>I have to ask, with flex having this much access,

238
00:11:38.120 --> 00:11:39.399
<v Speaker 1>how do we make sure it's secure.

239
00:11:39.679 --> 00:11:43.200
<v Speaker 2>That's a critical question. First and foremost, flux only pulls

240
00:11:43.200 --> 00:11:46.279
<v Speaker 2>from the branches we specify, and of course any changes

241
00:11:46.279 --> 00:11:49.600
<v Speaker 2>to those branches should go through our standard GET workflow,

242
00:11:49.639 --> 00:11:52.279
<v Speaker 2>code review approvals, the whole shebang.

243
00:11:52.039 --> 00:11:54.279
<v Speaker 1>Right, So it's not like flus can just grab anything

244
00:11:54.279 --> 00:11:56.759
<v Speaker 1>from our Git repository. There are rules in.

245
00:11:56.720 --> 00:12:00.279
<v Speaker 2>Place exactly, and because everything is tracked in GET, we

246
00:12:00.360 --> 00:12:02.799
<v Speaker 2>have a complete audit trail. We can see who made

247
00:12:02.799 --> 00:12:05.759
<v Speaker 2>what changes when, and even roll back to previous versions

248
00:12:05.759 --> 00:12:06.240
<v Speaker 2>if needed.

249
00:12:06.480 --> 00:12:09.639
<v Speaker 1>That's a lifesaver when things go wrong, which let's be honest,

250
00:12:09.679 --> 00:12:12.840
<v Speaker 1>they sometimes do. But what about different environments we talked

251
00:12:12.840 --> 00:12:18.159
<v Speaker 1>about dev, staging, production, How does flux handle those variations?

252
00:12:18.320 --> 00:12:22.039
<v Speaker 2>Excellent question. That's where a tool that customize comes in handy.

253
00:12:22.240 --> 00:12:25.639
<v Speaker 2>It lets us customize our deployments for different environments without

254
00:12:25.720 --> 00:12:27.840
<v Speaker 2>duplicating a ton of code.

255
00:12:27.919 --> 00:12:31.320
<v Speaker 1>So instead of having completely separate configurations for each environment,

256
00:12:31.519 --> 00:12:34.720
<v Speaker 1>we can define a base configuration and then layer on

257
00:12:34.919 --> 00:12:36.320
<v Speaker 1>environment specific tweaks.

258
00:12:36.440 --> 00:12:38.639
<v Speaker 2>You got it. We can set resource limits for our

259
00:12:38.679 --> 00:12:43.120
<v Speaker 2>staging environment, tweak network settings for production, all without touching

260
00:12:43.120 --> 00:12:44.840
<v Speaker 2>the core application configuration.

261
00:12:45.240 --> 00:12:48.440
<v Speaker 1>That's smart. It keeps things organized and much less prone

262
00:12:48.440 --> 00:12:51.159
<v Speaker 1>to errors. Now there's another tool that I keep hearing

263
00:12:51.159 --> 00:12:54.240
<v Speaker 1>about in the same breath as Kubernetes Helm. How does

264
00:12:54.279 --> 00:12:55.240
<v Speaker 1>that fit into the picture.

265
00:12:55.600 --> 00:12:59.120
<v Speaker 2>Ah Helm think of it like a package manager for Kubernetes.

266
00:12:59.399 --> 00:13:02.559
<v Speaker 2>It lets us undle up related Kubernetes resources into reusable

267
00:13:02.559 --> 00:13:03.799
<v Speaker 2>packages called charts.

268
00:13:03.960 --> 00:13:06.080
<v Speaker 1>So if I need to deploy, say a web server

269
00:13:06.240 --> 00:13:09.000
<v Speaker 1>and a database together, I can grab a pre built

270
00:13:09.000 --> 00:13:12.200
<v Speaker 1>Helm chart set of configuring everything manually exactly.

271
00:13:12.519 --> 00:13:15.480
<v Speaker 2>And the best part, Flux can manage these home charts

272
00:13:15.519 --> 00:13:18.200
<v Speaker 2>for us. It can deploy them, upgrade them, even roll

273
00:13:18.240 --> 00:13:22.759
<v Speaker 2>them back if needed, all automated and version controlled through get.

274
00:13:22.919 --> 00:13:26.000
<v Speaker 1>Wow, it just keeps getting better. We're automating deployments, managing

275
00:13:26.039 --> 00:13:30.440
<v Speaker 1>different environments, even using pre built application packages. Yeah, it's

276
00:13:30.480 --> 00:13:34.600
<v Speaker 1>like the dream workflow for any developer or operations team.

277
00:13:34.879 --> 00:13:39.519
<v Speaker 1>But what about secrets? Things like API keys, database passwords.

278
00:13:39.600 --> 00:13:41.480
<v Speaker 1>We can't just store those in plain texts in our

279
00:13:41.519 --> 00:13:43.000
<v Speaker 1>Git repository.

280
00:13:42.440 --> 00:13:44.840
<v Speaker 2>Right, absolutely not. That would be a security nightmare. That's

281
00:13:44.840 --> 00:13:47.759
<v Speaker 2>where secrets management comes in, and thankfully there are tools

282
00:13:47.759 --> 00:13:49.559
<v Speaker 2>designed specifically for Kubernetes.

283
00:13:49.679 --> 00:13:52.120
<v Speaker 1>Okay, so how do we keep our secrets safe in

284
00:13:52.159 --> 00:13:53.000
<v Speaker 1>a GitOps world?

285
00:13:53.360 --> 00:13:56.080
<v Speaker 2>One approach is to use a tool like sealed secrets.

286
00:13:56.480 --> 00:14:00.279
<v Speaker 2>It encrypts our secrets before they even touch our Git repository.

287
00:14:00.200 --> 00:14:02.320
<v Speaker 1>So even if someone got their hands on our code base,

288
00:14:02.679 --> 00:14:04.080
<v Speaker 1>those secrets would be useless.

289
00:14:04.200 --> 00:14:08.120
<v Speaker 2>Exactly, the decryption key only exists within our Kubernetes cluster.

290
00:14:08.399 --> 00:14:11.440
<v Speaker 1>That's brilliant, so we get all the benefits of storing

291
00:14:11.519 --> 00:14:15.240
<v Speaker 1>everything and get without compromising on security. This has been

292
00:14:15.240 --> 00:14:20.039
<v Speaker 1>an incredible deep dive, from Docker to Kubernetes, from CICD pipelines,

293
00:14:20.200 --> 00:14:23.240
<v Speaker 1>the magic of getops. We've covered so much ground.

294
00:14:23.039 --> 00:14:25.320
<v Speaker 2>And we've only just scratched the surface. The world of

295
00:14:25.360 --> 00:14:29.240
<v Speaker 2>debops is vast and constantly evolving, but hopefully this deep

296
00:14:29.279 --> 00:14:31.919
<v Speaker 2>dive has given you a solid foundation and the confidence

297
00:14:32.000 --> 00:14:33.000
<v Speaker 2>to explore further.

298
00:14:33.399 --> 00:14:36.240
<v Speaker 1>To our amazing listeners, if this deep dive has sparked

299
00:14:36.279 --> 00:14:39.480
<v Speaker 1>your curiosity, don't stop here. We've got tons of resources

300
00:14:39.559 --> 00:14:41.480
<v Speaker 1>linked to the show notes, and we'll be back next

301
00:14:41.519 --> 00:14:43.679
<v Speaker 1>time with another exciting deep dive into the world of

302
00:14:43.679 --> 00:14:48.639
<v Speaker 1>software development and technology. Until then, happy coding, happy automating,

303
00:14:48.799 --> 00:14:49.799
<v Speaker 1>and happy deploying.