WEBVTT

1
00:00:00.160 --> 00:00:03.240
<v Speaker 1>Welcome to the deep dive. We're your shortcut to getting

2
00:00:03.359 --> 00:00:07.799
<v Speaker 1>genuinely well informed fast without drowning you in details.

3
00:00:07.879 --> 00:00:11.839
<v Speaker 2>Yeah, we focus on those core insights, those aha moments exactly.

4
00:00:12.279 --> 00:00:15.439
<v Speaker 1>And today we are taking a really fascinating deep dive

5
00:00:15.480 --> 00:00:18.800
<v Speaker 1>into the world of Argo CD and git ops. We're

6
00:00:18.879 --> 00:00:21.800
<v Speaker 1>using Argo CD up and running a hands on guide

7
00:00:21.800 --> 00:00:24.239
<v Speaker 1>to get ups and Kubernetes by Andrew Block and Christian

8
00:00:24.239 --> 00:00:28.199
<v Speaker 1>Hernandez as our guide. It's a pretty comprehensive.

9
00:00:27.679 --> 00:00:31.039
<v Speaker 2>Definitely, and our mission today really is to unpack what

10
00:00:31.199 --> 00:00:34.600
<v Speaker 2>gid ops actually is, how Argo CD brings it to life,

11
00:00:35.320 --> 00:00:39.200
<v Speaker 2>and why it's becoming such a standard for cloud native apps.

12
00:00:39.439 --> 00:00:41.960
<v Speaker 1>Right. So, whether you're prepping for that big meeting or

13
00:00:42.039 --> 00:00:45.399
<v Speaker 1>just trying to stay current, or maybe you're just you know, curious.

14
00:00:45.039 --> 00:00:47.399
<v Speaker 2>We'll give you the essential nuggets you walk away understanding

15
00:00:47.399 --> 00:00:48.200
<v Speaker 2>this whole paradigm.

16
00:00:48.240 --> 00:00:51.679
<v Speaker 1>Okay, let's start unpacking getups. We hear this term everywhere,

17
00:00:52.079 --> 00:00:53.840
<v Speaker 1>so at its very core, what is it?

18
00:00:54.240 --> 00:00:57.200
<v Speaker 2>Well, the book defines it pretty simply. It's basically a

19
00:00:57.240 --> 00:01:01.200
<v Speaker 2>method for managing your infrastructure, your applications. Yeah, by describing

20
00:01:01.240 --> 00:01:04.599
<v Speaker 2>the state you want them to be in declaratively in

21
00:01:04.760 --> 00:01:08.079
<v Speaker 2>get and using git as that single source of truth.

22
00:01:08.799 --> 00:01:11.159
<v Speaker 1>That sounds simple, but I guess the revolutionary part is

23
00:01:11.200 --> 00:01:13.920
<v Speaker 1>the shift right from telling systems how to do things

24
00:01:13.959 --> 00:01:17.359
<v Speaker 1>exactly imperative commands to just defining what you want in

25
00:01:17.400 --> 00:01:20.920
<v Speaker 1>a way that's like auditible and trappable because it's.

26
00:01:20.719 --> 00:01:24.879
<v Speaker 2>In geit precisely. Yeah, that's the real aha moment there.

27
00:01:25.200 --> 00:01:27.359
<v Speaker 2>And you know the origin story is pretty interesting too.

28
00:01:27.519 --> 00:01:29.200
<v Speaker 1>Oh yeah, tell me about that.

29
00:01:29.359 --> 00:01:32.040
<v Speaker 2>It goes back to twenty seventeen with leave Works. They

30
00:01:32.079 --> 00:01:36.400
<v Speaker 2>apparently had this incident where someone fat finger to config.

31
00:01:36.280 --> 00:01:38.400
<v Speaker 1>Change oops we've all been there, took.

32
00:01:38.280 --> 00:01:41.120
<v Speaker 2>Down their whole platform. Yeah, but the way they recovered

33
00:01:41.439 --> 00:01:44.079
<v Speaker 2>by rolling back using git it sort of revealed this

34
00:01:44.159 --> 00:01:45.400
<v Speaker 2>new better way of working.

35
00:01:45.519 --> 00:01:48.560
<v Speaker 1>Ah. So necessity is the mother of invention.

36
00:01:48.560 --> 00:01:51.920
<v Speaker 2>Kind of Yeah. And their CEO, Alexis Richardson, he's the

37
00:01:51.920 --> 00:01:54.719
<v Speaker 2>one who coined the term git ops. It came out

38
00:01:54.719 --> 00:01:55.719
<v Speaker 2>of a real mess basically.

39
00:01:55.760 --> 00:01:57.640
<v Speaker 1>Okay, that makes sense, and it's important to note right

40
00:01:57.719 --> 00:01:59.879
<v Speaker 1>this isn't some completely separate thing from.

41
00:02:00.840 --> 00:02:03.000
<v Speaker 2>No, not at all. The book is really clear on this.

42
00:02:03.079 --> 00:02:05.719
<v Speaker 2>It says get ops is DevOps. Get ops is the

43
00:02:05.840 --> 00:02:07.319
<v Speaker 2>natural progression of DevOps.

44
00:02:07.359 --> 00:02:09.759
<v Speaker 1>So it's like formalizing the good stuff people were already

45
00:02:09.800 --> 00:02:13.639
<v Speaker 1>trying to do version control automation exactly.

46
00:02:13.719 --> 00:02:16.599
<v Speaker 2>It takes those DevOps best practices and puts them into

47
00:02:16.680 --> 00:02:21.159
<v Speaker 2>a really solid, audible automated workflow, like putting guardrails on things.

48
00:02:21.240 --> 00:02:25.400
<v Speaker 1>Gotcha. So if it's a progression, what specifically defines it?

49
00:02:25.520 --> 00:02:26.400
<v Speaker 1>Are their rules?

50
00:02:26.639 --> 00:02:29.439
<v Speaker 2>Yeah? There are the open getops principles, which came out

51
00:02:29.439 --> 00:02:32.759
<v Speaker 2>in twenty twenty one, lay out four key tenets. First,

52
00:02:32.960 --> 00:02:34.400
<v Speaker 2>it has to be declarative.

53
00:02:34.479 --> 00:02:38.039
<v Speaker 1>Declarative, meaning you describe the what, not the how, like

54
00:02:38.080 --> 00:02:39.439
<v Speaker 1>a Kubernetes manifest.

55
00:02:39.560 --> 00:02:43.879
<v Speaker 2>Precisely your entire system, state, apps, infra networks, whatever is

56
00:02:43.919 --> 00:02:47.000
<v Speaker 2>described declaratively, you say what the end state should look like. Okay.

57
00:02:47.039 --> 00:02:48.919
<v Speaker 1>Principle one declarative what's suck.

58
00:02:49.080 --> 00:02:53.000
<v Speaker 2>Second, versioned and immutable. The desired state lives entirely in.

59
00:02:53.000 --> 00:02:55.759
<v Speaker 1>Geit ah the source of truth part exactly.

60
00:02:55.800 --> 00:02:59.000
<v Speaker 2>And because it's GIT, you get a complete, unchangeable history

61
00:02:59.000 --> 00:03:02.479
<v Speaker 2>of every single change, auditing rollbacks, it's all built in.

62
00:03:02.599 --> 00:03:03.759
<v Speaker 1>That's huge. Okay.

63
00:03:03.800 --> 00:03:06.800
<v Speaker 2>Third, Third, and this is a really key difference from

64
00:03:06.800 --> 00:03:10.560
<v Speaker 2>a lot of traditional CICD. Changes are pulled.

65
00:03:10.639 --> 00:03:13.400
<v Speaker 1>Automatically, hold, not push right.

66
00:03:13.599 --> 00:03:16.520
<v Speaker 2>Instead of a CI server pushing updates, you have get

67
00:03:16.639 --> 00:03:21.080
<v Speaker 2>ups agents or controllers inside your environment, actively pulling the

68
00:03:21.120 --> 00:03:24.400
<v Speaker 2>definitions from Git. They run this reconciliation loop.

69
00:03:24.199 --> 00:03:27.439
<v Speaker 1>A reconciliation loop like a little robot constantly checking.

70
00:03:27.520 --> 00:03:31.479
<v Speaker 2>Yeah, constantly checking does the live system match the blueprint

71
00:03:31.520 --> 00:03:34.479
<v Speaker 2>in Git. It makes it more secure, more robust than

72
00:03:34.560 --> 00:03:36.000
<v Speaker 2>just reacting to webbooks.

73
00:03:36.280 --> 00:03:38.719
<v Speaker 1>Interesting, okay, And the fourth principle follows from that.

74
00:03:38.840 --> 00:03:42.280
<v Speaker 2>It does it's continuously reconciled. Those agents are always observing

75
00:03:42.280 --> 00:03:45.000
<v Speaker 2>the live state and working to make it match the

76
00:03:45.080 --> 00:03:48.319
<v Speaker 2>desired state from GIT. It's like Kubernetes controllers, but for

77
00:03:48.439 --> 00:03:52.479
<v Speaker 2>your whole application stack, always self healing, always striving for

78
00:03:52.520 --> 00:03:53.240
<v Speaker 2>that get state.

79
00:03:53.439 --> 00:03:55.719
<v Speaker 1>Okay. That makes get ups much clearer. So where does

80
00:03:55.840 --> 00:03:57.919
<v Speaker 1>argo CD fit in this landscape?

81
00:03:58.240 --> 00:04:00.599
<v Speaker 2>Rgo CD is a really prominent tool in this space.

82
00:04:00.719 --> 00:04:03.000
<v Speaker 2>It's part of the wider Argo project and those built

83
00:04:03.039 --> 00:04:06.120
<v Speaker 2>specifically for getups. Developer experience was a big focus too.

84
00:04:06.039 --> 00:04:08.599
<v Speaker 1>And its main job is its core purpose.

85
00:04:08.280 --> 00:04:12.080
<v Speaker 2>Is delivering changes to Kubernetes clusters, potentially at massive scale,

86
00:04:12.439 --> 00:04:15.080
<v Speaker 2>following those getups principles we just talked about, and.

87
00:04:15.080 --> 00:04:18.360
<v Speaker 1>The big value proposition seems to be around configuration drift.

88
00:04:18.439 --> 00:04:21.839
<v Speaker 2>Absolutely, that's where it really shines. It actively detects and

89
00:04:21.879 --> 00:04:25.439
<v Speaker 2>prevents configuration drift. You know, when your live cluster gets

90
00:04:25.480 --> 00:04:27.480
<v Speaker 2>out of sync with Git because someone made a manual

91
00:04:27.560 --> 00:04:28.480
<v Speaker 2>change or something.

92
00:04:28.279 --> 00:04:32.279
<v Speaker 1>Broke, rgo CD sees the mismatch and flags it or

93
00:04:32.759 --> 00:04:33.839
<v Speaker 1>fixes it both.

94
00:04:33.959 --> 00:04:37.439
<v Speaker 2>Potentially. It constantly compares the YAMEL and Git to the

95
00:04:37.480 --> 00:04:40.319
<v Speaker 2>live state. If they diverge, it lets you know, and

96
00:04:40.360 --> 00:04:42.639
<v Speaker 2>you can configure it to automatically sink things back to

97
00:04:42.680 --> 00:04:43.480
<v Speaker 2>the desired state.

98
00:04:43.720 --> 00:04:47.639
<v Speaker 1>Okay, and you mentioned it brought structure to Kubernetes management.

99
00:04:47.800 --> 00:04:50.560
<v Speaker 2>Yeah, Before tools like rgo CD, managing all the differ

100
00:04:50.600 --> 00:04:53.839
<v Speaker 2>Kubernetes pieces to deployment services can fig maps could be

101
00:04:53.879 --> 00:04:54.279
<v Speaker 2>a bit.

102
00:04:54.160 --> 00:04:56.519
<v Speaker 1>Loose, right, just a bunch of Yamo files.

103
00:04:56.680 --> 00:05:00.560
<v Speaker 2>Rgo CD introduced the concept of an ARGOCD application. Think

104
00:05:00.560 --> 00:05:03.480
<v Speaker 2>of it as an atomic unit of work. It bundles

105
00:05:03.519 --> 00:05:07.279
<v Speaker 2>everything related to your app, the deployment, the service, ingress,

106
00:05:07.319 --> 00:05:08.720
<v Speaker 2>everything into one manageable thing.

107
00:05:08.879 --> 00:05:12.839
<v Speaker 1>So deployments become more coherent, audible, automated exactly.

108
00:05:12.959 --> 00:05:15.120
<v Speaker 2>You're dealing with the whole application picture at once.

109
00:05:15.199 --> 00:05:18.040
<v Speaker 1>And it's flexible too, right, not just for strict geit ops.

110
00:05:18.079 --> 00:05:20.199
<v Speaker 2>That's true. The book points out it can function as

111
00:05:20.240 --> 00:05:22.720
<v Speaker 2>a general purpose deployment tool even if you're not doing

112
00:05:22.800 --> 00:05:26.439
<v Speaker 2>full git ops yet, and it integrates nicely with tools

113
00:05:26.480 --> 00:05:29.879
<v Speaker 2>people already use like Helm and customize. We'll get into

114
00:05:29.879 --> 00:05:30.680
<v Speaker 2>those more cool.

115
00:05:30.720 --> 00:05:33.360
<v Speaker 1>So it's adaptable. Let's maybe peel back the layers a bit.

116
00:05:33.680 --> 00:05:35.480
<v Speaker 1>What's the architecture look like under the hood.

117
00:05:35.639 --> 00:05:39.800
<v Speaker 2>Sure, so RGOCD itself follows on Microservice's architecture. Is made

118
00:05:39.879 --> 00:05:43.040
<v Speaker 2>up of several smaller independent components working together.

119
00:05:43.199 --> 00:05:45.480
<v Speaker 1>Okay, typical cloud native design, right.

120
00:05:45.560 --> 00:05:48.920
<v Speaker 2>And it leans heavily on Kubernetes primitives. It uses Kubernetes

121
00:05:49.040 --> 00:05:52.279
<v Speaker 2>concepts effectively. What's really fundamental is how it implements the

122
00:05:52.319 --> 00:05:54.079
<v Speaker 2>Kubernetes controller pattern.

123
00:05:54.040 --> 00:05:57.519
<v Speaker 1>Ah, the reconciliation loop idea again exactly.

124
00:05:58.160 --> 00:06:01.720
<v Speaker 2>Just like built in Kubernetes controllers watch resources, rg CD

125
00:06:01.839 --> 00:06:05.759
<v Speaker 2>watches two things, the desired state and get and the

126
00:06:05.800 --> 00:06:07.199
<v Speaker 2>actual spate in your clusters.

127
00:06:07.800 --> 00:06:10.279
<v Speaker 1>If there's a difference, it steps in and enforces the

128
00:06:10.319 --> 00:06:12.079
<v Speaker 1>get state prevents that.

129
00:06:12.040 --> 00:06:14.360
<v Speaker 2>Drift precisely, it's constantly reconciling.

130
00:06:14.519 --> 00:06:16.720
<v Speaker 1>So what are the main components doing this work?

131
00:06:16.839 --> 00:06:20.040
<v Speaker 2>Okay, First, you have the repository server. Its job is

132
00:06:20.079 --> 00:06:22.959
<v Speaker 2>to maintain a local cache of your Git repos or

133
00:06:23.000 --> 00:06:26.319
<v Speaker 2>Helm chart sources casing for speed yep, and then it

134
00:06:26.439 --> 00:06:30.240
<v Speaker 2>generates the final Kubernetes manifests from whatever source you're using,

135
00:06:30.319 --> 00:06:31.959
<v Speaker 2>Helm customized plane YAML.

136
00:06:32.519 --> 00:06:36.079
<v Speaker 1>It preps the manifests, got it manifest prep station what else?

137
00:06:36.120 --> 00:06:38.079
<v Speaker 2>Then there's the API server. This is the main hub.

138
00:06:38.319 --> 00:06:42.759
<v Speaker 2>It uses gRPC and rest pretty standard stuff for communication,

139
00:06:42.959 --> 00:06:47.439
<v Speaker 2>and this manages everything really application status, triggering, sinks, handling, RBAC,

140
00:06:47.600 --> 00:06:49.519
<v Speaker 2>role based access control, you know who can do what,

141
00:06:50.120 --> 00:06:51.480
<v Speaker 2>and it also serves the web UI.

142
00:06:52.079 --> 00:06:54.759
<v Speaker 1>The user interface runs off This API server.

143
00:06:54.879 --> 00:06:57.399
<v Speaker 2>Makes sense, but for cashing it uses rehttis.

144
00:06:57.079 --> 00:06:59.759
<v Speaker 1>Reddus okay, fast in memory database.

145
00:06:59.439 --> 00:07:02.000
<v Speaker 2>Right is it for local caching to speed things up,

146
00:07:02.040 --> 00:07:05.560
<v Speaker 2>reduce calls to get and store some temporary state. Important

147
00:07:05.639 --> 00:07:09.399
<v Speaker 2>note though this redd as cache isn't persistent. If rgo

148
00:07:09.480 --> 00:07:11.800
<v Speaker 2>CV restarts, it rebuilds the cash.

149
00:07:11.600 --> 00:07:14.399
<v Speaker 1>From get good to know not a permanent data store.

150
00:07:14.839 --> 00:07:18.560
<v Speaker 2>And finally, finally, a really key part its own custom

151
00:07:18.639 --> 00:07:25.319
<v Speaker 2>resources or crds. These extend Kubernetes itself. Rgo CD adds

152
00:07:25.360 --> 00:07:28.680
<v Speaker 2>things like application at project and application set.

153
00:07:28.519 --> 00:07:31.720
<v Speaker 1>So you manage rgo CD deployments using these Kubernetes native

154
00:07:31.720 --> 00:07:32.720
<v Speaker 1>objects exactly.

155
00:07:32.759 --> 00:07:35.439
<v Speaker 2>These crds become your main way of interacting with rgo

156
00:07:35.519 --> 00:07:39.360
<v Speaker 2>CD and defining your gitups deployments within Kubernetes itself.

157
00:07:39.600 --> 00:07:41.680
<v Speaker 1>Very cool. Okay, so how do you actually get this

158
00:07:41.720 --> 00:07:43.079
<v Speaker 1>thing running and start using it?

159
00:07:43.360 --> 00:07:46.360
<v Speaker 2>Installation is pretty standard Kupernettes stuff. You can use the

160
00:07:46.399 --> 00:07:49.639
<v Speaker 2>raw yamal manifests they provide our helm or yeah, more

161
00:07:49.639 --> 00:07:52.720
<v Speaker 2>commonly these days helm charts. The book guides you through

162
00:07:52.959 --> 00:07:56.600
<v Speaker 2>setting it up into local kind cluster Kubernettes in Docker,

163
00:07:56.839 --> 00:07:58.600
<v Speaker 2>which is great for just playing around.

164
00:07:58.319 --> 00:08:00.360
<v Speaker 1>And learning and interacting with it. I hear the UI

165
00:08:00.439 --> 00:08:01.639
<v Speaker 1>is quite good, it really is.

166
00:08:01.759 --> 00:08:04.720
<v Speaker 2>The user interface gives you a great visual overview. You

167
00:08:04.759 --> 00:08:07.160
<v Speaker 2>can see what apps are doing, theirs, SINC, datas, health,

168
00:08:07.199 --> 00:08:09.519
<v Speaker 2>managed settings. It's very user friendly.

169
00:08:09.600 --> 00:08:11.040
<v Speaker 1>How do you access it? Initially?

170
00:08:11.360 --> 00:08:13.839
<v Speaker 2>You can start with cubictol PORTFOD, just a tunnel into

171
00:08:13.839 --> 00:08:16.759
<v Speaker 2>it quickly, but for anything more permanent, you'd set up

172
00:08:16.759 --> 00:08:19.160
<v Speaker 2>a proper Kubernetes ingress to give it a real host

173
00:08:19.240 --> 00:08:21.680
<v Speaker 2>name like rgo CD dot, your domain, dot.

174
00:08:21.560 --> 00:08:23.920
<v Speaker 1>Local or something right, make it accessible like a normal

175
00:08:23.920 --> 00:08:25.519
<v Speaker 1>web app. What about the command line.

176
00:08:25.639 --> 00:08:28.639
<v Speaker 2>Yep, there's the rg CDCLI tool. It actually offers more

177
00:08:28.639 --> 00:08:32.799
<v Speaker 2>functionality than the UI, sometimes hitting the same back end API.

178
00:08:33.360 --> 00:08:36.080
<v Speaker 2>It's where you do more advanced things like adding remote

179
00:08:36.080 --> 00:08:37.919
<v Speaker 2>clusters declaratively.

180
00:08:37.879 --> 00:08:42.120
<v Speaker 1>UI for visuals, CLI for power users, and automation. But

181
00:08:42.200 --> 00:08:45.799
<v Speaker 1>here's the really neat getops part I read about. You

182
00:08:45.879 --> 00:08:48.679
<v Speaker 1>manage rgo CD itself declaratively.

183
00:08:48.840 --> 00:08:52.360
<v Speaker 2>Yes, this is super elegant. Rgo CD's own configuration like

184
00:08:52.399 --> 00:08:56.120
<v Speaker 2>connection details for get, rebos, security settings, UI tweaks is

185
00:08:56.159 --> 00:08:58.679
<v Speaker 2>stored in standard Kubernetes confct maps and secrets.

186
00:08:58.720 --> 00:09:01.399
<v Speaker 1>So you can put rgo CD can fig in get

187
00:09:01.720 --> 00:09:04.759
<v Speaker 1>and have ARGOCD apply its own can fig using.

188
00:09:04.519 --> 00:09:08.360
<v Speaker 2>GetUp exactly, it manages itself. You define its configuration, declaratively

189
00:09:08.440 --> 00:09:11.399
<v Speaker 2>commit it, and rgo CD picks it up and reconfigures itself.

190
00:09:11.559 --> 00:09:12.840
<v Speaker 2>It's get oops all the way down.

191
00:09:13.080 --> 00:09:15.559
<v Speaker 1>That is elegant. Okay, let's get to the heart of it,

192
00:09:16.320 --> 00:09:21.600
<v Speaker 1>managing and synchronizing actual applications. This application CRD seems key.

193
00:09:22.039 --> 00:09:25.279
<v Speaker 2>It is an rgo CD application is basically a pointer.

194
00:09:25.960 --> 00:09:29.360
<v Speaker 2>It tells ARGOCD about a set of Kubernetes resources that

195
00:09:29.399 --> 00:09:31.679
<v Speaker 2>belong together. It primarily defines two things.

196
00:09:31.679 --> 00:09:32.279
<v Speaker 1>What are those?

197
00:09:32.399 --> 00:09:35.039
<v Speaker 2>First? The dot sbec dot source. This is where the

198
00:09:35.080 --> 00:09:38.279
<v Speaker 2>manifests live, usually a get repo URL, maybe a specific

199
00:09:38.320 --> 00:09:40.759
<v Speaker 2>branch or tag and a path within that repo.

200
00:09:40.960 --> 00:09:42.639
<v Speaker 1>Okay, where the blueprint is right.

201
00:09:42.879 --> 00:09:46.279
<v Speaker 2>And interestingly, newer versions like V two point six onwards

202
00:09:46.519 --> 00:09:48.200
<v Speaker 2>support multisource applications.

203
00:09:48.240 --> 00:09:49.279
<v Speaker 1>Oh what does that mean?

204
00:09:49.559 --> 00:09:52.200
<v Speaker 2>It means you can pull manifests from multiple sources like

205
00:09:52.240 --> 00:09:54.919
<v Speaker 2>maybe your main app deployment from one get repo, but

206
00:09:55.000 --> 00:09:58.159
<v Speaker 2>it's database configuration from another, and combine them into a

207
00:09:58.200 --> 00:10:02.399
<v Speaker 2>single rgo CD application. Really powerful for complex setups.

208
00:10:02.480 --> 00:10:03.480
<v Speaker 1>Okay, that's the source.

209
00:10:03.519 --> 00:10:05.960
<v Speaker 2>What's the second part, the dot spec dot destination. This

210
00:10:06.159 --> 00:10:09.960
<v Speaker 2>just tells our docd where to deploy those manifests, which

211
00:10:10.039 --> 00:10:13.279
<v Speaker 2>Kubernetes cluster and which namespace within that cluster could be.

212
00:10:13.200 --> 00:10:15.720
<v Speaker 1>The same cluster rgo CD is running on or different one.

213
00:10:16.000 --> 00:10:19.000
<v Speaker 2>Yep, you can specify in cluster for the local cluster

214
00:10:19.519 --> 00:10:22.799
<v Speaker 2>or provide the API server address for a remote cluster.

215
00:10:23.000 --> 00:10:26.200
<v Speaker 1>And to manage the actual YAML complexity you mentioned, helm.

216
00:10:26.000 --> 00:10:29.159
<v Speaker 2>And customize absolutely. You rarely want to be just copying

217
00:10:29.159 --> 00:10:33.120
<v Speaker 2>and pasting raw YAML everywhere. RGOCD has first class support

218
00:10:33.159 --> 00:10:35.679
<v Speaker 2>for Helm, which is kind of the standard package manager

219
00:10:35.679 --> 00:10:37.039
<v Speaker 2>for Kubernetes.

220
00:10:36.480 --> 00:10:39.320
<v Speaker 1>Now right for templating and managing dependencies, and.

221
00:10:39.440 --> 00:10:43.240
<v Speaker 2>Also Customize, which is great for applying environment specific patches

222
00:10:43.320 --> 00:10:47.840
<v Speaker 2>or variations to base manifests without actually changing the original files.

223
00:10:48.000 --> 00:10:50.960
<v Speaker 1>You use bases and overlays, so RGOCD works with these

224
00:10:50.960 --> 00:10:55.000
<v Speaker 1>tools to render the final manifests before applying them exactly.

225
00:10:55.039 --> 00:10:57.720
<v Speaker 2>It uses the repository server component we talked about to

226
00:10:57.799 --> 00:11:00.960
<v Speaker 2>run Helm or customize base on your applications tech.

227
00:11:01.080 --> 00:11:05.519
<v Speaker 1>Okay, now the magic part synchronization. You said by default

228
00:11:05.720 --> 00:11:08.200
<v Speaker 1>nothing happens when you create an application.

229
00:11:07.879 --> 00:11:11.279
<v Speaker 2>Correct, and this is surprising but also really important. By default,

230
00:11:11.720 --> 00:11:15.480
<v Speaker 2>creating an application resource just registers it with rgo CD.

231
00:11:15.720 --> 00:11:18.600
<v Speaker 2>It doesn't actually apply anything to your cluster yet it

232
00:11:18.600 --> 00:11:20.159
<v Speaker 2>gives you a chance to review. You can look in

233
00:11:20.159 --> 00:11:23.519
<v Speaker 2>the UI see what argocd would deploy and make sure

234
00:11:23.519 --> 00:11:27.039
<v Speaker 2>it looks right before you manually click sink or enable automation.

235
00:11:27.120 --> 00:11:28.039
<v Speaker 2>It's a safety net.

236
00:11:28.200 --> 00:11:32.159
<v Speaker 1>Ah okay, a deliberate pause, but you can automate it. Oh.

237
00:11:32.240 --> 00:11:35.120
<v Speaker 2>Yes, you define a SINK policy in the application manifest.

238
00:11:35.480 --> 00:11:37.399
<v Speaker 2>This lets you turn on automated.

239
00:11:36.960 --> 00:11:38.679
<v Speaker 1>SINC And what options do you have there.

240
00:11:38.879 --> 00:11:43.240
<v Speaker 2>Key ones are pune true, which tells RGOCD to automatically

241
00:11:43.279 --> 00:11:46.519
<v Speaker 2>delete resources from the cluster if they're removed from get

242
00:11:46.600 --> 00:11:47.759
<v Speaker 2>garbage collection.

243
00:11:47.600 --> 00:11:50.039
<v Speaker 1>Essentially important for keeping things clean, and.

244
00:11:49.960 --> 00:11:53.960
<v Speaker 2>Self heal true this tells RGCD to automatically fix any

245
00:11:54.039 --> 00:11:57.720
<v Speaker 2>drifted to texts. If someone manually changes something in the cluster,

246
00:11:58.080 --> 00:11:59.559
<v Speaker 2>self heal will revert it back.

247
00:11:59.440 --> 00:12:03.159
<v Speaker 1>To the gets stay so truly, enforcing that get source of.

248
00:12:03.120 --> 00:12:06.000
<v Speaker 2>Truth exactly the thing. Policy also lets you set up

249
00:12:06.000 --> 00:12:08.919
<v Speaker 2>retry strategies. If a sinc fails with backoffs and.

250
00:12:08.960 --> 00:12:12.080
<v Speaker 1>Limits, what about controlling things at a finer grain than

251
00:12:12.120 --> 00:12:13.600
<v Speaker 1>the whole application you.

252
00:12:13.559 --> 00:12:17.440
<v Speaker 2>Can You can use Kubernetes annotations directly on individual resource

253
00:12:17.519 --> 00:12:21.080
<v Speaker 2>manifests in get what. For instance, you might annotate a

254
00:12:21.120 --> 00:12:26.799
<v Speaker 2>persistent volume claim with rgocd dot rgoprojei dot iosinc options

255
00:12:26.840 --> 00:12:29.840
<v Speaker 2>prune false to prevent argo CD from ever deleting it

256
00:12:30.200 --> 00:12:31.480
<v Speaker 2>even if it's removed.

257
00:12:31.159 --> 00:12:33.639
<v Speaker 1>From gitt ah protecting stateful things right.

258
00:12:34.120 --> 00:12:37.399
<v Speaker 2>Or there's skip dry run and missing resource true, which

259
00:12:37.440 --> 00:12:40.240
<v Speaker 2>can be useful if your application installs its own crds

260
00:12:40.559 --> 00:12:43.799
<v Speaker 2>or operators. Sometimes the dry run fails initially because the

261
00:12:43.799 --> 00:12:46.440
<v Speaker 2>CRD isn't there yet, So this lets you bypass that

262
00:12:46.559 --> 00:12:48.200
<v Speaker 2>check for specific resources.

263
00:12:48.279 --> 00:12:51.679
<v Speaker 1>Okay, annotations for fine tuning. What about running tasks during

264
00:12:51.759 --> 00:12:53.879
<v Speaker 1>SINC like database migrations.

265
00:12:54.000 --> 00:12:57.480
<v Speaker 2>That's where hooks come in. RGOCD lets you define Kubernetes

266
00:12:57.600 --> 00:13:00.559
<v Speaker 2>jobs or pods as hooks that run its specif points

267
00:13:00.600 --> 00:13:01.639
<v Speaker 2>in the sync life cycle.

268
00:13:01.759 --> 00:13:02.759
<v Speaker 1>When would you use those?

269
00:13:02.960 --> 00:13:05.480
<v Speaker 2>You have precinc hooks that run before anything else sincoks

270
00:13:05.519 --> 00:13:08.279
<v Speaker 2>during the main sync, post sync, after a successful sink,

271
00:13:08.440 --> 00:13:10.759
<v Speaker 2>sink fail if it bombs out, and even post.

272
00:13:10.519 --> 00:13:13.480
<v Speaker 1>Delete, so post sync would be perfect for database migrations,

273
00:13:13.519 --> 00:13:17.159
<v Speaker 1>apply the new app code, then run the migration job exactly.

274
00:13:17.320 --> 00:13:19.840
<v Speaker 2>Or precinc could be used to say take a database

275
00:13:19.840 --> 00:13:23.080
<v Speaker 2>backup before and upgrade. Very powerful automation.

276
00:13:22.840 --> 00:13:26.080
<v Speaker 1>And for really complex apps with lots of dependencies, how

277
00:13:26.120 --> 00:13:27.080
<v Speaker 1>do you manage the order?

278
00:13:27.399 --> 00:13:30.639
<v Speaker 2>That's where sink waves are incredibly useful. Sometimes you need

279
00:13:30.720 --> 00:13:33.519
<v Speaker 2>resource a like a database, to be fully up and

280
00:13:33.600 --> 00:13:36.440
<v Speaker 2>running before resource b your application starts.

281
00:13:36.559 --> 00:13:38.559
<v Speaker 1>Right dependencies, sink waves.

282
00:13:38.399 --> 00:13:41.759
<v Speaker 2>Let you assign numerical waves to your resources using annotations.

283
00:13:42.320 --> 00:13:46.039
<v Speaker 2>RGCD applies resources in wave order, waiting for resources in

284
00:13:46.080 --> 00:13:49.159
<v Speaker 2>one wave to become healthy before starting the next wave zero,

285
00:13:49.320 --> 00:13:51.120
<v Speaker 2>then wave one, wave two, and so on.

286
00:13:51.480 --> 00:13:55.320
<v Speaker 1>Ah, so you can orchestrate complex rollouts precisely.

287
00:13:55.399 --> 00:13:58.399
<v Speaker 2>Precisely. It prevents things from failing just because of dependency

288
00:13:58.440 --> 00:13:59.200
<v Speaker 2>wasn't ready yet.

289
00:13:59.200 --> 00:14:02.200
<v Speaker 1>One more sinc thing. Ignoring differences Sometimes the live state

290
00:14:02.240 --> 00:14:04.320
<v Speaker 1>should be different, right, like with autoscaling.

291
00:14:04.399 --> 00:14:07.480
<v Speaker 2>Good point. Yes, rgo CD lets you configure it to

292
00:14:07.559 --> 00:14:11.840
<v Speaker 2>ignore specific differences. Maybe you have a horizontal pod autoscaler

293
00:14:12.159 --> 00:14:14.919
<v Speaker 2>managing the replica's count of a deployment. You don't want

294
00:14:15.000 --> 00:14:17.000
<v Speaker 2>rgo CD fighting with the HPA, so.

295
00:14:17.000 --> 00:14:20.200
<v Speaker 1>You tell RGOCD, hey ignore changes to spec Dot replicas

296
00:14:20.200 --> 00:14:21.879
<v Speaker 1>for this deployment exactly.

297
00:14:22.320 --> 00:14:24.720
<v Speaker 2>You can configure these ignores at the application level or

298
00:14:24.799 --> 00:14:28.840
<v Speaker 2>even globally for certain resource types or specific JSON paths

299
00:14:29.279 --> 00:14:32.480
<v Speaker 2>across your whole RGOCD instance. Very flexible.

300
00:14:32.639 --> 00:14:36.559
<v Speaker 1>Okay, makes sense. Now what about application health? How does

301
00:14:36.679 --> 00:14:39.480
<v Speaker 1>rgo CD know if a deployment actually worked?

302
00:14:39.799 --> 00:14:43.480
<v Speaker 2>It relies heavily on kubernators built in health checks. This

303
00:14:43.559 --> 00:14:46.720
<v Speaker 2>means defining proper readiness and liveness probes in your deployments

304
00:14:46.720 --> 00:14:49.360
<v Speaker 2>in state ful sets is absolutely critical.

305
00:14:49.000 --> 00:14:52.600
<v Speaker 1>Because RGOCD uses those probe statuses to decide if a

306
00:14:52.639 --> 00:14:57.120
<v Speaker 1>resource and therefore the whole application is healthy exactly if

307
00:14:57.120 --> 00:14:59.840
<v Speaker 1>your probes aren't set up correctly, rgo CD might think

308
00:15:00.039 --> 00:15:02.480
<v Speaker 1>app is healthy when it's not, or vice versa.

309
00:15:02.600 --> 00:15:05.360
<v Speaker 2>Good probes are fundamental to reliable get ops.

310
00:15:05.559 --> 00:15:07.720
<v Speaker 1>Does argo CD add its own health checks too?

311
00:15:07.960 --> 00:15:11.200
<v Speaker 2>It does for many standard Kubernetes resource types. It has

312
00:15:11.240 --> 00:15:14.279
<v Speaker 2>built in logic to understand the health of deployments, services,

313
00:15:14.279 --> 00:15:19.080
<v Speaker 2>stateful sets, etc. However, there's a catch. Oh a surprising fact, Yeah,

314
00:15:19.159 --> 00:15:22.080
<v Speaker 2>surprising faction. In the book, the built in health check

315
00:15:22.120 --> 00:15:26.000
<v Speaker 2>for rgo CD's own application CRD was actually removed by

316
00:15:26.039 --> 00:15:28.320
<v Speaker 2>default back in argo CD version one point eight.

317
00:15:28.399 --> 00:15:30.320
<v Speaker 1>Wait, why would they do that and why does it matter?

318
00:15:30.480 --> 00:15:34.600
<v Speaker 2>It matters if you're doing complex orchestrations where one rgo

319
00:15:34.639 --> 00:15:37.200
<v Speaker 2>CD application needs to know if another argo CD application

320
00:15:37.279 --> 00:15:39.639
<v Speaker 2>is healthy before it proceeds, like in the app of

321
00:15:39.679 --> 00:15:41.080
<v Speaker 2>apps pattern we might discuss.

322
00:15:41.200 --> 00:15:43.360
<v Speaker 1>Ah, So if you need applications to depend on each

323
00:15:43.360 --> 00:15:44.440
<v Speaker 1>other's health, you need.

324
00:15:44.320 --> 00:15:47.480
<v Speaker 2>To explicitly re enable that application health check in the

325
00:15:47.519 --> 00:15:51.919
<v Speaker 2>main argo CD configment rgo CD cny it's off by default,

326
00:15:51.960 --> 00:15:54.720
<v Speaker 2>which can trip people up when building those advanced workflows.

327
00:15:54.960 --> 00:15:58.200
<v Speaker 1>Good tip. Okay, let's shift gears to more advanced topics

328
00:15:58.240 --> 00:16:02.480
<v Speaker 1>operationalizing this stuff. Authentication and authorization seem crucial.

329
00:16:02.679 --> 00:16:06.080
<v Speaker 2>Absolutely out of the box, RGCD gives you a single

330
00:16:06.120 --> 00:16:09.480
<v Speaker 2>admin user. The initial password is in a Kubernet.

331
00:16:09.120 --> 00:16:10.919
<v Speaker 1>Seekert change it immediately, yes, please?

332
00:16:11.360 --> 00:16:15.120
<v Speaker 2>Then you can define additional local users. But more realistically,

333
00:16:15.159 --> 00:16:18.960
<v Speaker 2>in an enterprise setup, you'll integrate with single sign on sso.

334
00:16:18.840 --> 00:16:22.120
<v Speaker 1>Like using Octa or Google Workspace or something exactly.

335
00:16:22.320 --> 00:16:26.679
<v Speaker 2>Rgo CD supports standard protocols like openetd Connect, ODC, or

336
00:16:26.720 --> 00:16:29.080
<v Speaker 2>you can use an identity broker like decks, which can

337
00:16:29.120 --> 00:16:33.440
<v Speaker 2>then connect to LDFP, SAML, get up whatever your company uses.

338
00:16:33.759 --> 00:16:36.000
<v Speaker 2>The book uses key cloak as an example of you decks.

339
00:16:36.200 --> 00:16:39.559
<v Speaker 1>Okay, so users log in with their normal company credentials.

340
00:16:39.960 --> 00:16:42.080
<v Speaker 1>What about what they can do once logged in.

341
00:16:42.559 --> 00:16:45.960
<v Speaker 2>That's where rg CDs built in RBAC comes in. Role

342
00:16:45.960 --> 00:16:48.679
<v Speaker 2>based access control. It governs permissions.

343
00:16:48.879 --> 00:16:50.159
<v Speaker 1>Does it have default roles?

344
00:16:50.279 --> 00:16:53.279
<v Speaker 2>Yes? It starts with a powerful role Dot admin and

345
00:16:53.320 --> 00:16:56.360
<v Speaker 2>a useful role dot readily, but you can define your

346
00:16:56.360 --> 00:17:00.519
<v Speaker 2>own custom roles using simple CSD policies stored in configmap.

347
00:17:00.159 --> 00:17:02.960
<v Speaker 1>So you can get really granular, like this team can

348
00:17:03.000 --> 00:17:04.960
<v Speaker 1>only deploy to the devname space.

349
00:17:04.720 --> 00:17:09.599
<v Speaker 2>Precisely, and that leads into projects or app project resources.

350
00:17:09.960 --> 00:17:13.759
<v Speaker 2>These are fundamental for multi tenancy or just organizing things.

351
00:17:13.880 --> 00:17:15.039
<v Speaker 1>Let do projects control.

352
00:17:15.359 --> 00:17:19.160
<v Speaker 2>They act as logical groupings for applications. Crucially, they let

353
00:17:19.200 --> 00:17:21.359
<v Speaker 2>administrators restrict things within that.

354
00:17:21.319 --> 00:17:23.480
<v Speaker 1>Group, like what kind of restrictions you can.

355
00:17:23.359 --> 00:17:26.799
<v Speaker 2>Restrict which get repositories applications in that project are like

356
00:17:26.839 --> 00:17:27.319
<v Speaker 2>to pull.

357
00:17:27.160 --> 00:17:29.440
<v Speaker 1>From AH security boundaries.

358
00:17:28.960 --> 00:17:32.440
<v Speaker 2>Exactly which destination clusters or name spaces they can deploy to.

359
00:17:32.839 --> 00:17:36.599
<v Speaker 2>You can even blacklist or whitelist specific kinds of Kubernetes resources,

360
00:17:36.880 --> 00:17:39.640
<v Speaker 2>maybe disallow creating cluster rolls from a certain project.

361
00:17:40.000 --> 00:17:43.720
<v Speaker 1>Wow. Okay, So projects are like security and policy sandboxes

362
00:17:43.759 --> 00:17:45.559
<v Speaker 1>for groups of applications.

363
00:17:45.000 --> 00:17:49.160
<v Speaker 2>Yep, and you assign permissions which users or sso groups

364
00:17:49.160 --> 00:17:52.000
<v Speaker 2>can access the project and what roles they have at

365
00:17:52.000 --> 00:17:52.960
<v Speaker 2>the project level too.

366
00:17:53.359 --> 00:17:57.319
<v Speaker 1>There's also something called applications sinc impersonation that sounds important

367
00:17:57.319 --> 00:17:57.960
<v Speaker 1>for security.

368
00:17:58.480 --> 00:18:00.920
<v Speaker 2>It is, and it's relatively new from v two point

369
00:18:00.920 --> 00:18:04.759
<v Speaker 2>one four onwards. It lets you specify a different Kumbinaties

370
00:18:04.799 --> 00:18:07.920
<v Speaker 2>service account for RGOCD to use what it actually applies

371
00:18:07.960 --> 00:18:10.799
<v Speaker 2>manifest to a cluster for a specific application.

372
00:18:11.000 --> 00:18:13.640
<v Speaker 1>Why is that better than ARGOCD just using its own

373
00:18:13.720 --> 00:18:15.200
<v Speaker 1>default service account.

374
00:18:14.960 --> 00:18:18.720
<v Speaker 2>Principle of least privilege, the default argo CD service account

375
00:18:18.720 --> 00:18:21.920
<v Speaker 2>often needs fairly broad permissions to manage crds and things.

376
00:18:22.319 --> 00:18:25.759
<v Speaker 2>By using impersonation, you can create a dedicated service account

377
00:18:25.880 --> 00:18:28.839
<v Speaker 2>for an application that only has permissions to manage deployments

378
00:18:28.839 --> 00:18:31.240
<v Speaker 2>and services in the specific name space. For example.

379
00:18:31.559 --> 00:18:34.480
<v Speaker 1>Ah so, even if the main RGO CD controller was

380
00:18:34.519 --> 00:18:37.759
<v Speaker 1>somehow compromised, the blast radius for what it could do

381
00:18:37.920 --> 00:18:39.440
<v Speaker 1>during a sink is much smaller.

382
00:18:39.559 --> 00:18:42.759
<v Speaker 2>Exactly, it decouples the control planes permissions from the sink

383
00:18:42.839 --> 00:18:46.079
<v Speaker 2>execution permissions. Big security win makes sense.

384
00:18:46.519 --> 00:18:49.920
<v Speaker 1>Okay, what about managing multiple clusters? How does that work?

385
00:18:50.240 --> 00:18:53.160
<v Speaker 2>RGOCD uses a hub and spoke model. Your main RGO

386
00:18:53.200 --> 00:18:57.119
<v Speaker 2>CD installation is the hub. It then manages deployments out

387
00:18:57.119 --> 00:18:59.079
<v Speaker 2>to potentially many spoke clusters.

388
00:18:59.799 --> 00:19:02.599
<v Speaker 1>The control plane is centralized generally.

389
00:19:02.359 --> 00:19:07.599
<v Speaker 2>Yes, the hub pushes or more accurately applies the configurations

390
00:19:07.640 --> 00:19:09.759
<v Speaker 2>defined in get out to the managed clusters.

391
00:19:09.839 --> 00:19:11.680
<v Speaker 1>How do you add those remote clusters?

392
00:19:11.759 --> 00:19:14.279
<v Speaker 2>You can use the rgo CLI. There's a command like

393
00:19:14.519 --> 00:19:17.880
<v Speaker 2>rgo sed cluster ad or more get up style. You

394
00:19:17.920 --> 00:19:22.200
<v Speaker 2>can define the cluster connection details. API server endpoint credentials

395
00:19:22.720 --> 00:19:25.519
<v Speaker 2>within a kubernating secret and apply that secret to the

396
00:19:25.640 --> 00:19:27.359
<v Speaker 2>rgo CD control plane cluster.

397
00:19:27.680 --> 00:19:30.400
<v Speaker 1>So the cluster definitions themselves live in geit.

398
00:19:30.480 --> 00:19:34.279
<v Speaker 2>Yep RGOCD watches for secrets labeled correctly and automatically adds

399
00:19:34.319 --> 00:19:35.480
<v Speaker 2>them as managed clusters.

400
00:19:35.799 --> 00:19:38.079
<v Speaker 1>Okay, so you have multiple clusters defined. How do you

401
00:19:38.119 --> 00:19:41.319
<v Speaker 1>deploy the same app to multiple clusters? And application CRD

402
00:19:41.440 --> 00:19:42.640
<v Speaker 1>only points to one destination?

403
00:19:42.799 --> 00:19:46.279
<v Speaker 2>Right, correct? A single application resource maps one source to

404
00:19:46.319 --> 00:19:49.680
<v Speaker 2>one destination, but there are patterns for deploying to many.

405
00:19:49.839 --> 00:19:51.559
<v Speaker 2>First is the app of apps pattern.

406
00:19:51.319 --> 00:19:52.480
<v Speaker 1>App of apps? What's that?

407
00:19:52.799 --> 00:19:56.960
<v Speaker 2>It's basically an rgo CD application whose source git rebo

408
00:19:57.240 --> 00:20:01.240
<v Speaker 2>contains manifests for other rgo CD applicants meta.

409
00:20:01.319 --> 00:20:04.680
<v Speaker 1>So one application deploys more application Exactly.

410
00:20:05.039 --> 00:20:07.599
<v Speaker 2>You might have a staging apps application that deploys the

411
00:20:07.680 --> 00:20:12.119
<v Speaker 2>specific application resources for your AP service, staging front and staging,

412
00:20:12.119 --> 00:20:15.119
<v Speaker 2>et cetera. It's great for boost wrapping environments or managing

413
00:20:15.160 --> 00:20:16.359
<v Speaker 2>application stacks together.

414
00:20:16.680 --> 00:20:17.960
<v Speaker 1>Clever, what's the other way?

415
00:20:18.279 --> 00:20:23.440
<v Speaker 2>Application sets? These are designed specifically for this multi deployment scenario.

416
00:20:24.279 --> 00:20:27.200
<v Speaker 2>Think of an application set as an application factory. A

417
00:20:27.319 --> 00:20:30.319
<v Speaker 2>factory you define an application set with a template for

418
00:20:30.359 --> 00:20:33.279
<v Speaker 2>an rgo CD application, but you leave parts like the

419
00:20:33.319 --> 00:20:37.039
<v Speaker 2>destination cluster or namespace dynamic. Then you use a generator

420
00:20:37.160 --> 00:20:40.079
<v Speaker 2>generators like what for several A list generator lets you

421
00:20:40.119 --> 00:20:43.079
<v Speaker 2>just provide a static list of clusters or parameters. A

422
00:20:43.119 --> 00:20:46.960
<v Speaker 2>cluster generator automatically finds all the clusters registered with rgocd

423
00:20:47.279 --> 00:20:50.160
<v Speaker 2>and creates an application for each. There's even an sem

424
00:20:50.200 --> 00:20:52.720
<v Speaker 2>provider generator that can look at your Git hosting like

425
00:20:52.759 --> 00:20:56.400
<v Speaker 2>GitHub git lab and create applications based on folders or branches.

426
00:20:56.440 --> 00:20:59.880
<v Speaker 1>It finds wow, so application sets automate creating many so

427
00:21:00.000 --> 00:21:04.240
<v Speaker 1>smilar applications targeted at different places. Very useful for platform teams.

428
00:21:04.319 --> 00:21:07.359
<v Speaker 2>Hugely useful, reduces boilerplate can figure dramatically.

429
00:21:07.480 --> 00:21:11.559
<v Speaker 1>Let's stock more security TLS certificates, connecting to private Git

430
00:21:11.640 --> 00:21:13.359
<v Speaker 1>repos critical stuff.

431
00:21:14.119 --> 00:21:17.839
<v Speaker 2>Rgocd obviously supports configuring TLS for its own EPI server

432
00:21:18.279 --> 00:21:21.000
<v Speaker 2>and UI. You can bring your own CERTs or generate

433
00:21:21.039 --> 00:21:25.119
<v Speaker 2>self signed ones. It also handles connecting securely to get repositories.

434
00:21:25.319 --> 00:21:29.319
<v Speaker 2>How for HTTPS repos you can store credentials like username, password,

435
00:21:29.400 --> 00:21:33.000
<v Speaker 2>or access tokens in Kubernetes. Secrets that rg CD is

436
00:21:33.039 --> 00:21:36.680
<v Speaker 2>configured to use for SSH. You sort the private key

437
00:21:36.680 --> 00:21:39.359
<v Speaker 2>in a secret and configure the known host entries again,

438
00:21:39.440 --> 00:21:42.599
<v Speaker 2>usually via rgo CD's configureent secrets managed.

439
00:21:42.319 --> 00:21:45.519
<v Speaker 1>Via git ops Okay, standard secure connection methods. What about

440
00:21:45.599 --> 00:21:46.920
<v Speaker 1>verifying the commits themselves?

441
00:21:47.039 --> 00:21:49.880
<v Speaker 2>Yes, for extra assurance, you can enable get commit signature

442
00:21:49.960 --> 00:21:52.960
<v Speaker 2>verification using GTG gpgkeys, so.

443
00:21:53.039 --> 00:21:55.240
<v Speaker 1>Argo City checks if the commit was signed by a

444
00:21:55.240 --> 00:21:57.079
<v Speaker 1>trusted developer key before sinking.

445
00:21:57.440 --> 00:22:00.319
<v Speaker 2>Exactly, you can figure rgo CD with the public keys

446
00:22:00.319 --> 00:22:03.000
<v Speaker 2>of your trusted committers. If a commit in the tracked

447
00:22:03.039 --> 00:22:05.880
<v Speaker 2>branch isn't signed or is signed by an unknown key,

448
00:22:06.400 --> 00:22:09.759
<v Speaker 2>rgo CD can refuse to sink it. It ensures code.

449
00:22:09.599 --> 00:22:13.519
<v Speaker 1>Provenance, important for regulated environments or just high trust. Okay,

450
00:22:13.519 --> 00:22:15.920
<v Speaker 1>scaling this up monitoring essential.

451
00:22:16.400 --> 00:22:19.880
<v Speaker 2>You absolutely should integrate rgo CD with Prometheus for metrics

452
00:22:19.880 --> 00:22:22.119
<v Speaker 2>collection and Grafana for visualization.

453
00:22:22.240 --> 00:22:23.519
<v Speaker 1>What kind of metrics do you get?

454
00:22:23.599 --> 00:22:27.759
<v Speaker 2>You get metrics about argocd itself, CPU memory, usage of

455
00:22:27.799 --> 00:22:32.279
<v Speaker 2>its components, API requests, latency, number of applications being managed,

456
00:22:32.759 --> 00:22:36.920
<v Speaker 2>but also crucial metrics about SINC operations, how many sinks

457
00:22:36.920 --> 00:22:40.079
<v Speaker 2>are happening, how long they take, success failure rates, it

458
00:22:40.079 --> 00:22:43.799
<v Speaker 2>gives you operational visibility beyond just your own app metrics.

459
00:22:43.440 --> 00:22:45.160
<v Speaker 1>And getting alerted when things go wrong.

460
00:22:45.240 --> 00:22:48.039
<v Speaker 2>That's where RGCD notifications comes in. It's an optional but

461
00:22:48.119 --> 00:22:50.559
<v Speaker 2>highly recommended component. It watches rgo CD.

462
00:22:50.400 --> 00:22:54.799
<v Speaker 1>Events like sync failed or an app became unhealthy.

463
00:22:54.680 --> 00:23:00.000
<v Speaker 2>Sync success failure, health degradation, sink starting, lots of triggers.

464
00:23:00.079 --> 00:23:03.759
<v Speaker 2>Can then send nicely formatted notifications to slack matter, most

465
00:23:04.079 --> 00:23:07.240
<v Speaker 2>email page, your duty teams, you name. It keeps everyone

466
00:23:07.240 --> 00:23:09.000
<v Speaker 2>in the loop automatically. Very handy.

467
00:23:09.400 --> 00:23:13.880
<v Speaker 1>What about keeping rgo CD itself reliable? High availability definitely

468
00:23:13.920 --> 00:23:14.680
<v Speaker 1>needed for production.

469
00:23:14.960 --> 00:23:19.519
<v Speaker 2>Rgocd's components, the API server, reposerver, application controller are designed

470
00:23:19.559 --> 00:23:23.720
<v Speaker 2>to run with multiple replicas for high availability BJA. If

471
00:23:23.759 --> 00:23:27.000
<v Speaker 2>one pod dies, another takes over. You typically manage this

472
00:23:27.079 --> 00:23:31.240
<v Speaker 2>with standard Kubernetes deployments and potentially horizontal pod autoscalers.

473
00:23:31.279 --> 00:23:33.960
<v Speaker 1>And if you have thousands of applications, can one controller

474
00:23:34.039 --> 00:23:36.039
<v Speaker 1>handle all that reconciliation It.

475
00:23:36.000 --> 00:23:40.279
<v Speaker 2>Can become a bottleneck for really large scale RGOCD supports

476
00:23:40.359 --> 00:23:42.119
<v Speaker 2>charding the application.

477
00:23:41.599 --> 00:23:44.200
<v Speaker 1>Controller starting splitting the work exactly.

478
00:23:44.440 --> 00:23:46.759
<v Speaker 2>You can run multiple replicas of the controller and rgo

479
00:23:46.839 --> 00:23:50.000
<v Speaker 2>CD will automatically distribute the applications across them. Based on

480
00:23:50.039 --> 00:23:53.559
<v Speaker 2>a hashing algorithm, each controller instance only manages a subset

481
00:23:53.599 --> 00:23:56.559
<v Speaker 2>of the total applications. This prevents one controller from becoming

482
00:23:56.559 --> 00:23:59.960
<v Speaker 2>a hotspot and improves overall sync throughput okay.

483
00:24:00.160 --> 00:24:03.319
<v Speaker 1>Jay and scharding for scale. Can you extend rgo CD's

484
00:24:03.359 --> 00:24:06.400
<v Speaker 1>functionality if it doesn't support your specific tools out of

485
00:24:06.400 --> 00:24:06.799
<v Speaker 1>the box.

486
00:24:07.039 --> 00:24:11.319
<v Speaker 2>Yes, through config management plugins CMPs. Let's say you have

487
00:24:11.440 --> 00:24:14.880
<v Speaker 2>some customs scripting process to generate your Yamel or maybe

488
00:24:14.920 --> 00:24:16.279
<v Speaker 2>you use a less common tool.

489
00:24:16.359 --> 00:24:17.960
<v Speaker 1>You can teach rgo CD how to use.

490
00:24:17.880 --> 00:24:20.519
<v Speaker 2>It pretty much. If you package your tool or script

491
00:24:20.519 --> 00:24:23.559
<v Speaker 2>into a container image to find how RGOCD should call

492
00:24:23.599 --> 00:24:27.759
<v Speaker 2>it in the RGCD s endemioconfigmap and rgo CD's repository

493
00:24:27.799 --> 00:24:30.839
<v Speaker 2>server will run your plug in in a sidecar container

494
00:24:30.839 --> 00:24:32.880
<v Speaker 2>to generate the manifests. It's very flexible.

495
00:24:33.039 --> 00:24:36.039
<v Speaker 1>Nice. What about customizing the look and feel of the UI.

496
00:24:36.240 --> 00:24:38.480
<v Speaker 2>You can do that too. You could apply custom CSS

497
00:24:38.480 --> 00:24:42.119
<v Speaker 2>style sheets to change colors, fonts, layout, maybe make the

498
00:24:42.119 --> 00:24:44.599
<v Speaker 2>top bar red in your production. Rgo CD instances as

499
00:24:44.599 --> 00:24:45.319
<v Speaker 2>a visual cue.

500
00:24:45.720 --> 00:24:48.759
<v Speaker 1>Simple but effective. Can you add new UI elements?

501
00:24:48.880 --> 00:24:51.720
<v Speaker 2>Yes? Through UI extensions. These are more involved. You basically

502
00:24:51.759 --> 00:24:55.119
<v Speaker 2>build custom react components that get loaded into the RGO CDUI.

503
00:24:55.440 --> 00:24:57.599
<v Speaker 2>You could use this to add buttons that trigger external

504
00:24:57.640 --> 00:25:00.880
<v Speaker 2>actions or display information from other systems right within the

505
00:25:01.000 --> 00:25:02.000
<v Speaker 2>RGO CD interface.

506
00:25:02.279 --> 00:25:07.960
<v Speaker 1>Cool. Last major area integration with CI. How does rgocd

507
00:25:08.119 --> 00:25:10.680
<v Speaker 1>fit into the broader CICD pipeline.

508
00:25:10.720 --> 00:25:14.920
<v Speaker 2>Good question. We mentioned The reconciliation loop runs periodically, maybe

509
00:25:14.960 --> 00:25:18.240
<v Speaker 2>every three minutes by default, but often you want changes

510
00:25:18.279 --> 00:25:19.839
<v Speaker 2>deployed faster.

511
00:25:19.720 --> 00:25:21.440
<v Speaker 1>Right as soon as they merge to maine.

512
00:25:21.440 --> 00:25:24.240
<v Speaker 2>That's where web hooks come in. You can figure get GitHub,

513
00:25:24.279 --> 00:25:27.039
<v Speaker 2>get lab, et cetera to send a webook notification to

514
00:25:27.160 --> 00:25:30.599
<v Speaker 2>argocd whenever there's a push to the track branch. Rgo

515
00:25:30.640 --> 00:25:33.799
<v Speaker 2>CD can then immediately trigger a refresh and sink if needed.

516
00:25:33.960 --> 00:25:36.319
<v Speaker 2>It provides that on demand synchronization, so.

517
00:25:36.240 --> 00:25:40.079
<v Speaker 1>You get the continuous reconciliation and fast updates via web hooks.

518
00:25:40.359 --> 00:25:42.559
<v Speaker 2>Best of both worlds. And you can integrate this further,

519
00:25:42.559 --> 00:25:46.319
<v Speaker 2>maybe your CI process using something like Tecton pipelines.

520
00:25:45.839 --> 00:25:48.440
<v Speaker 1>Tecton the Kubernetes native CICD tool.

521
00:25:48.599 --> 00:25:52.039
<v Speaker 2>Right your Tecton pipeline could run tests, lynch your manifests,

522
00:25:52.119 --> 00:25:54.400
<v Speaker 2>maybe build an image and then as a final step.

523
00:25:54.400 --> 00:25:57.279
<v Speaker 2>After everything passes, it merges the change, which then triggers

524
00:25:57.279 --> 00:25:58.599
<v Speaker 2>the RGO CD web hoook.

525
00:25:58.480 --> 00:26:01.599
<v Speaker 1>So CI handles the validation before getaps takes over for

526
00:26:01.680 --> 00:26:02.960
<v Speaker 1>deployment exactly.

527
00:26:03.480 --> 00:26:06.279
<v Speaker 2>You can even have tech ton directly interact with the

528
00:26:06.359 --> 00:26:09.880
<v Speaker 2>RGO CD API if needed. Technon triggers can listen forget

529
00:26:09.920 --> 00:26:14.000
<v Speaker 2>events to start these pipelines automatically. It creates a really robust,

530
00:26:14.119 --> 00:26:17.160
<v Speaker 2>fully automated flow from code commit to running.

531
00:26:16.920 --> 00:26:20.480
<v Speaker 1>In the cluster that paints a really comprehensive picture looking ahead.

532
00:26:20.680 --> 00:26:24.119
<v Speaker 1>What are some ongoing discussions or future considerations in the

533
00:26:24.160 --> 00:26:25.039
<v Speaker 1>getop space.

534
00:26:25.799 --> 00:26:29.240
<v Speaker 2>One big one, especially for organizations starting out, is getops

535
00:26:29.279 --> 00:26:33.680
<v Speaker 2>directory structures. How should you actually organize your repositories?

536
00:26:33.839 --> 00:26:34.960
<v Speaker 1>Is there one right answer?

537
00:26:35.680 --> 00:26:38.319
<v Speaker 2>Not really? The book mentions it often comes down to

538
00:26:38.359 --> 00:26:43.079
<v Speaker 2>Conway's law. Your org structure influences your system design. Some

539
00:26:43.359 --> 00:26:46.240
<v Speaker 2>for poly repos maybe one repo for the cluster platform

540
00:26:46.279 --> 00:26:49.559
<v Speaker 2>stuff and separate reapers for each application. Others go for

541
00:26:49.720 --> 00:26:51.920
<v Speaker 2>large monerapos containing everything.

542
00:26:51.559 --> 00:26:52.480
<v Speaker 1>Pros and cons to both.

543
00:26:52.519 --> 00:26:55.960
<v Speaker 2>I imagine definitely CALLI repos give teams more autonomy, but

544
00:26:56.000 --> 00:26:58.839
<v Speaker 2>can be harder to coordinate. LONO repos make cross cutting

545
00:26:58.920 --> 00:27:01.880
<v Speaker 2>changes easier, but require more tooling and discipline.

546
00:27:01.920 --> 00:27:05.359
<v Speaker 1>What about storing rendered manifests you mentioned that earlier, Yes.

547
00:27:05.519 --> 00:27:09.799
<v Speaker 2>The rendered manifest pattern. Instead of rgo CD pulling helm

548
00:27:09.920 --> 00:27:12.200
<v Speaker 2>charts or customized bases and rendering them.

549
00:27:12.039 --> 00:27:14.720
<v Speaker 1>On the fly, you pre render them in your CI

550
00:27:14.880 --> 00:27:18.119
<v Speaker 1>pipeline and commit the final YAML to get exactly.

551
00:27:18.519 --> 00:27:22.200
<v Speaker 2>The benefit is absolute clarity. What's in GET is exactly

552
00:27:22.240 --> 00:27:26.200
<v Speaker 2>what rgo CD will apply. No surprises from template rendering

553
00:27:26.559 --> 00:27:30.759
<v Speaker 2>logic changing between environments. It makes auditing and diffing much simpler.

554
00:27:31.000 --> 00:27:33.599
<v Speaker 1>Interesting trade off, more CI work, but simpler.

555
00:27:33.640 --> 00:27:36.599
<v Speaker 2>Geit ops state right and related to get structure is

556
00:27:36.640 --> 00:27:40.359
<v Speaker 2>the recommended GitOps workflow. The book strangly advocates for trunk

557
00:27:40.400 --> 00:27:41.559
<v Speaker 2>based development as.

558
00:27:41.440 --> 00:27:44.799
<v Speaker 1>Opposed to something like gitflow with long lived develop staging

559
00:27:45.039 --> 00:27:45.799
<v Speaker 1>main branches.

560
00:27:46.000 --> 00:27:49.200
<v Speaker 2>Yes, the problem with long lived environment branches in a

561
00:27:49.240 --> 00:27:53.599
<v Speaker 2>geitops world is that environment specific configuration like replica accounts

562
00:27:53.640 --> 00:27:57.640
<v Speaker 2>or URLs tends to diverge. Merging between these branches becomes

563
00:27:57.680 --> 00:27:59.079
<v Speaker 2>a nightmare, ah.

564
00:27:58.759 --> 00:28:02.400
<v Speaker 1>Because you don't want stagings can fig merged into production exactly.

565
00:28:02.920 --> 00:28:05.680
<v Speaker 1>Trunk based development where changes flow quickly to the main

566
00:28:05.720 --> 00:28:09.079
<v Speaker 1>branch and configuration differences are handled by tools like Customize

567
00:28:09.160 --> 00:28:12.359
<v Speaker 1>or helm values outside of Git. Branching generally works much

568
00:28:12.359 --> 00:28:13.559
<v Speaker 1>better with the gt ops model.

569
00:28:13.799 --> 00:28:16.799
<v Speaker 2>Good practical advice Where can people go to learn more

570
00:28:17.000 --> 00:28:17.839
<v Speaker 2>or get involved?

571
00:28:18.079 --> 00:28:21.799
<v Speaker 1>The community is really active. The CNCF slack has hashtag

572
00:28:21.839 --> 00:28:25.200
<v Speaker 1>giittops and hashtag rgo CD channels, which are great places

573
00:28:25.200 --> 00:28:26.039
<v Speaker 1>to ask questions.

574
00:28:26.079 --> 00:28:27.240
<v Speaker 2>Okay, CNCs slack.

575
00:28:27.519 --> 00:28:30.960
<v Speaker 1>Attending the public Argo project community meetings online is also

576
00:28:31.000 --> 00:28:32.759
<v Speaker 1>a good way to see what's happening and check out

577
00:28:32.759 --> 00:28:36.920
<v Speaker 1>projects incubating in Argo project labs. Likewise, there's the rgo

578
00:28:36.960 --> 00:28:40.720
<v Speaker 1>CD image updater, which helps automate updating container image tags

579
00:28:40.759 --> 00:28:44.200
<v Speaker 1>and get and a newer, more holistic project called cargo

580
00:28:44.359 --> 00:28:48.519
<v Speaker 1>is emerging focused on orchestrating promotions and progressive delivery across

581
00:28:48.559 --> 00:28:51.880
<v Speaker 1>different stages in a geit ops environment. It looks very promising.

582
00:28:52.160 --> 00:28:54.400
<v Speaker 2>Lot's happening. Okay, let's try to wrap this up. We've

583
00:28:54.440 --> 00:28:58.039
<v Speaker 2>really unpacked rgo CD and get ops today from weave workes,

584
00:28:58.119 --> 00:29:01.880
<v Speaker 2>fat finger origin story, the core git ups principles.

585
00:29:01.799 --> 00:29:07.440
<v Speaker 1>Declarative version pulled reconciled to rg CD's architecture, the controller pattern,

586
00:29:07.519 --> 00:29:13.240
<v Speaker 1>how you interact via UI and CLI managing applications with sources, destinations,

587
00:29:13.440 --> 00:29:15.880
<v Speaker 1>sink policies, hooks, waves.

588
00:29:15.640 --> 00:29:18.960
<v Speaker 2>All the way to advance topics like security, multi cluster

589
00:29:19.039 --> 00:29:22.440
<v Speaker 2>with apsets, ha charding extensibility.

590
00:29:22.640 --> 00:29:25.799
<v Speaker 1>Right, you should now have a really solid foundation. This

591
00:29:25.960 --> 00:29:28.559
<v Speaker 1>deep dive gives you that understanding of how it all

592
00:29:28.559 --> 00:29:29.279
<v Speaker 1>clicks together.

593
00:29:29.440 --> 00:29:32.640
<v Speaker 2>You've definitely got more than just the buzzwords, now practical insights,

594
00:29:32.880 --> 00:29:35.799
<v Speaker 2>some of those surprising details like the application health check

595
00:29:35.880 --> 00:29:39.000
<v Speaker 2>default hopefully helping you navigate get ups with more confidence.

596
00:29:39.119 --> 00:29:41.319
<v Speaker 1>So here's a final thought to leave you with. If

597
00:29:41.359 --> 00:29:43.920
<v Speaker 1>GIT truly becomes the single source of truth for our

598
00:29:43.960 --> 00:29:47.559
<v Speaker 1>system's desired state, how might that change the way we

599
00:29:47.640 --> 00:29:50.640
<v Speaker 1>think about all kinds of operational changes in our organizations

600
00:29:51.119 --> 00:29:55.079
<v Speaker 1>beyond just application deployments. What else could we managed declaratively

601
00:29:55.160 --> 00:29:56.240
<v Speaker 1>via get It's.

602
00:29:56.119 --> 00:29:59.440
<v Speaker 2>A powerful shift in thinking, moving from imperative actions to

603
00:29:59.599 --> 00:30:02.640
<v Speaker 2>declare of state management. Definitely something to moll over. And

604
00:30:02.680 --> 00:30:04.559
<v Speaker 2>of course check out the book rg CD up and

605
00:30:04.640 --> 00:30:07.759
<v Speaker 2>Running for even more detail and engage with that vibrant

606
00:30:07.759 --> 00:30:08.720
<v Speaker 2>GitOps community.

607
00:30:09.079 --> 00:30:12.960
<v Speaker 1>Absolutely, there's always more to explore. Thanks for joining us

608
00:30:12.960 --> 00:30:13.640
<v Speaker 1>on the deep dive.