WEBVTT

1
00:00:00.080 --> 00:00:03.879
<v Speaker 1>Okay, let's unpack this. Have you ever found yourself wrestling

2
00:00:03.919 --> 00:00:08.199
<v Speaker 1>with repetitive tasks in your IT infrastructure, you know, copying

3
00:00:08.240 --> 00:00:11.839
<v Speaker 1>commands from some messy document, making tiny tweaks, and then

4
00:00:11.919 --> 00:00:15.000
<v Speaker 1>just crossing your fingers hoping it all works. What if

5
00:00:15.000 --> 00:00:17.719
<v Speaker 1>there was a dramatically better way, a way to automate,

6
00:00:17.920 --> 00:00:20.559
<v Speaker 1>streamline and even share those IT operations.

7
00:00:20.600 --> 00:00:23.519
<v Speaker 2>Oh yeah, it's a scenario that it's close to home

8
00:00:23.640 --> 00:00:27.280
<v Speaker 2>for so many of us in tech. That constant manual effort,

9
00:00:27.519 --> 00:00:30.800
<v Speaker 2>the inefficiency, and frankly, the lurking risk of human error.

10
00:00:31.199 --> 00:00:32.359
<v Speaker 2>It's a major pain.

11
00:00:32.200 --> 00:00:35.640
<v Speaker 1>Point, exactly, and that's precisely why today we're taking a

12
00:00:35.679 --> 00:00:39.359
<v Speaker 1>deep dive into an incredibly powerful automation tool called antsable.

13
00:00:39.840 --> 00:00:42.560
<v Speaker 1>We're drawing our insights from learn ansable, which is really

14
00:00:42.600 --> 00:00:45.399
<v Speaker 1>a fantastic resource for anyone looking to get into automation.

15
00:00:45.719 --> 00:00:46.320
<v Speaker 2>He really is.

16
00:00:46.439 --> 00:00:48.719
<v Speaker 1>Our mission today is to pull out the most impactful

17
00:00:48.759 --> 00:00:51.759
<v Speaker 1>nuggets from this material, giving you a real shortcut, a

18
00:00:51.759 --> 00:00:54.719
<v Speaker 1>shortcut to understanding how ansable can revolutionize the way you

19
00:00:54.759 --> 00:00:58.320
<v Speaker 1>manage everything from say, simple web servers to vast complex

20
00:00:58.359 --> 00:00:59.200
<v Speaker 1>cloud deployments.

21
00:00:59.280 --> 00:01:04.040
<v Speaker 2>Yeah, we'll explo or its core philosophy some maybe surprising capabilities,

22
00:01:04.640 --> 00:01:08.359
<v Speaker 2>and ultimately how it brings structure and consistency to your

23
00:01:08.359 --> 00:01:11.920
<v Speaker 2>technical life. It's really about empowering you to build more

24
00:01:11.959 --> 00:01:13.120
<v Speaker 2>reliable system.

25
00:01:12.879 --> 00:01:16.239
<v Speaker 1>And reclaim your valuable time. Right, absolutely, Okay, let's kick

26
00:01:16.280 --> 00:01:19.280
<v Speaker 1>things off with something pretty cool. Actually a surprising fact

27
00:01:19.319 --> 00:01:21.400
<v Speaker 1>that kind of sets the stage. Did you know the

28
00:01:21.480 --> 00:01:25.959
<v Speaker 1>name ansable actually comes from science fiction? Oh? Yeah, yeah.

29
00:01:26.000 --> 00:01:29.799
<v Speaker 1>Back in nineteen sixty six, Ursula k Legwin coined the term.

30
00:01:30.239 --> 00:01:34.560
<v Speaker 1>It described this fictional device capable of sending messages faster

31
00:01:34.680 --> 00:01:37.079
<v Speaker 1>than light, you know, across interstellar distances.

32
00:01:37.280 --> 00:01:40.560
<v Speaker 2>Huh. And when you think about it, that origin story

33
00:01:40.640 --> 00:01:43.920
<v Speaker 2>is incredibly fitting for the software, isn't it. Ansible lets

34
00:01:43.959 --> 00:01:46.760
<v Speaker 2>you have this rapid remote communication with all your infrastructure.

35
00:01:46.760 --> 00:01:48.400
<v Speaker 2>It's like Legwin's device in a way.

36
00:01:48.519 --> 00:01:49.719
<v Speaker 1>It's a brilliant metaphor.

37
00:01:49.840 --> 00:01:53.159
<v Speaker 2>Yeah. The core insight is that it kind of collapses

38
00:01:53.200 --> 00:01:55.680
<v Speaker 2>the distance between you and your machines. Yeah. Allows for

39
00:01:55.760 --> 00:01:58.000
<v Speaker 2>near instant deployment, near instant management, and.

40
00:01:57.920 --> 00:02:00.120
<v Speaker 1>The software really lives up to that, especially with it's

41
00:02:00.159 --> 00:02:02.640
<v Speaker 1>core principles. First off, it's agentless, right.

42
00:02:02.760 --> 00:02:05.200
<v Speaker 2>And this isn't just a technical detail, it's a fundamental

43
00:02:05.200 --> 00:02:08.080
<v Speaker 2>simplification how so well, Unlike a lot of other cools

44
00:02:08.080 --> 00:02:11.759
<v Speaker 2>that make you install special software agents on every single

45
00:02:11.759 --> 00:02:15.479
<v Speaker 2>machine you want to manage, ansable uses standard, widely available

46
00:02:15.520 --> 00:02:20.439
<v Speaker 2>protocols like SSH exactly SSH for Linux and macOS and

47
00:02:20.560 --> 00:02:23.080
<v Speaker 2>WinRM that's Windows Remote Management for Windows.

48
00:02:23.479 --> 00:02:26.400
<v Speaker 1>So no extra software to maintain on the target machines.

49
00:02:26.520 --> 00:02:30.400
<v Speaker 2>Precisely, it's a monumental advantage. No extra ports to open,

50
00:02:30.520 --> 00:02:34.120
<v Speaker 2>no agents to update or troubleshoot, and your security posture

51
00:02:34.159 --> 00:02:37.639
<v Speaker 2>is simpler. Your main control machine just needs basic network

52
00:02:37.680 --> 00:02:39.520
<v Speaker 2>access to the target operationally.

53
00:02:39.599 --> 00:02:41.240
<v Speaker 1>That must save a ton of headache.

54
00:02:41.280 --> 00:02:44.960
<v Speaker 2>Oh it slashes the overhead ongoing agent maintenance just disappears,

55
00:02:45.479 --> 00:02:48.360
<v Speaker 2>makes your infrastructure and inherently more robust, I think.

56
00:02:48.400 --> 00:02:51.680
<v Speaker 1>And it's wonderfully minimal too. Right on your Linux targets,

57
00:02:52.439 --> 00:02:55.599
<v Speaker 1>what you just need Ssh and Python installed.

58
00:02:55.159 --> 00:02:58.759
<v Speaker 2>Pretty much, that's usually it, No complex dependencies to untangle.

59
00:02:59.120 --> 00:03:02.240
<v Speaker 1>That simplicity it carries over into how you actually describe

60
00:03:02.240 --> 00:03:03.719
<v Speaker 1>your infrastructure it does.

61
00:03:04.360 --> 00:03:09.520
<v Speaker 2>Ansable uses a language Yammel that's remarkably human readable, but

62
00:03:09.599 --> 00:03:14.639
<v Speaker 2>it's also perfectly machine executable. This descriptive, straightforward approach makes

63
00:03:14.639 --> 00:03:17.520
<v Speaker 2>it highly intuitive, easy to pick up, even if you're

64
00:03:17.520 --> 00:03:18.599
<v Speaker 2>totally new to automation.

65
00:03:18.800 --> 00:03:21.199
<v Speaker 1>Okay, now, if I'm about a really key difference. Something

66
00:03:21.199 --> 00:03:24.599
<v Speaker 1>that often trips people up when they're first learning automation tools.

67
00:03:24.719 --> 00:03:27.840
<v Speaker 1>It's the philosophical approach, right, how they manage state?

68
00:03:28.000 --> 00:03:32.560
<v Speaker 2>Yeah? Exactly. Many configuration tools, like Puppet or chef the

69
00:03:32.719 --> 00:03:34.560
<v Speaker 2>use what's called a declarative.

70
00:03:34.000 --> 00:03:36.520
<v Speaker 1>Approach, meaning you define the end state you want.

71
00:03:36.439 --> 00:03:38.479
<v Speaker 2>Right, You say, I want this system to look like this,

72
00:03:38.879 --> 00:03:40.840
<v Speaker 2>and the tool then figures out the steps to get there.

73
00:03:40.879 --> 00:03:42.120
<v Speaker 1>Okay, that sounds reasonable.

74
00:03:42.240 --> 00:03:45.840
<v Speaker 2>It can be, but from a broader perspective. While declarative

75
00:03:45.879 --> 00:03:50.319
<v Speaker 2>tools aim for eventual consistency, they can introduce some tricky challenges,

76
00:03:50.960 --> 00:03:53.080
<v Speaker 2>especially with dependencies.

77
00:03:52.680 --> 00:03:53.840
<v Speaker 1>Like what, give me an example.

78
00:03:53.960 --> 00:03:58.280
<v Speaker 2>Okay, imagine trying to create a user before their required

79
00:03:58.280 --> 00:03:59.400
<v Speaker 2>group even exists.

80
00:03:59.599 --> 00:04:01.639
<v Speaker 1>Ah, okay, the tool wouldn't know.

81
00:04:01.599 --> 00:04:04.879
<v Speaker 2>The order exactly. A declarative tool might just fail on

82
00:04:04.919 --> 00:04:07.080
<v Speaker 2>the first run. Then you write it again, maybe it

83
00:04:07.120 --> 00:04:10.240
<v Speaker 2>creates the group, then a third time it creates the user.

84
00:04:10.680 --> 00:04:13.520
<v Speaker 2>It might require multiple runs to finally converge on that

85
00:04:13.599 --> 00:04:15.159
<v Speaker 2>desired state, which.

86
00:04:14.919 --> 00:04:17.519
<v Speaker 1>Can be frustrating, especially if you've got hundreds of steps.

87
00:04:17.560 --> 00:04:21.120
<v Speaker 1>You could be stuck debugging and rerunning constantly precisely.

88
00:04:21.560 --> 00:04:24.360
<v Speaker 2>Ansable, on the other hand, takes an imperative approach.

89
00:04:24.439 --> 00:04:27.199
<v Speaker 1>Imperative meaning you tell it exactly what to do, step

90
00:04:27.199 --> 00:04:27.720
<v Speaker 1>by step.

91
00:04:27.839 --> 00:04:30.560
<v Speaker 2>You got it. You define the exact order in which

92
00:04:30.600 --> 00:04:35.120
<v Speaker 2>each task executes. You explicitly say create group, then create

93
00:04:35.240 --> 00:04:39.680
<v Speaker 2>user in that group. Ansible executes them in that precise sequence.

94
00:04:39.879 --> 00:04:42.399
<v Speaker 1>So it ensures a predictable flow exactly.

95
00:04:42.800 --> 00:04:47.639
<v Speaker 2>It elegantly sidesteps those tricky dependency errors, saves immense debugging time,

96
00:04:47.879 --> 00:04:49.439
<v Speaker 2>especially in complex setups.

97
00:04:49.560 --> 00:04:52.800
<v Speaker 1>That predictability sounds like a huge relief. And here's another

98
00:04:52.879 --> 00:04:56.839
<v Speaker 1>critical point you mentioned earlier. Antsable isn't just configuration management.

99
00:04:56.920 --> 00:04:59.000
<v Speaker 1>It's also an orchestration tool.

100
00:04:58.879 --> 00:05:01.279
<v Speaker 2>Right, And what's really powerful here is you can use

101
00:05:01.279 --> 00:05:05.480
<v Speaker 2>answable to say, launch a server, install an entire software

102
00:05:05.480 --> 00:05:09.720
<v Speaker 2>stack like a Lampe stack, you know, Linux, Apache, Dbphp,

103
00:05:09.839 --> 00:05:12.199
<v Speaker 2>and then you're done with that host.

104
00:05:12.399 --> 00:05:13.959
<v Speaker 1>No lingering agents checking in.

105
00:05:14.120 --> 00:05:18.519
<v Speaker 2>Nope, no lingering agents continuously policing its state, Which leads

106
00:05:18.519 --> 00:05:21.720
<v Speaker 2>to an important question for you, the listener, What potential

107
00:05:21.759 --> 00:05:25.279
<v Speaker 2>points of failure? What unnecessary complexity can you get rid

108
00:05:25.319 --> 00:05:27.959
<v Speaker 2>of by not having agents constantly phoning home?

109
00:05:28.360 --> 00:05:31.920
<v Speaker 1>For many places. That means a leaner, maybe more resilient

110
00:05:32.000 --> 00:05:33.800
<v Speaker 1>infrastructure definitely, And.

111
00:05:33.920 --> 00:05:36.680
<v Speaker 2>All of this leads us to a truly transformative concept

112
00:05:36.680 --> 00:05:40.399
<v Speaker 2>in modern IT infrastructure as code IIC.

113
00:05:40.959 --> 00:05:43.160
<v Speaker 1>This is the absolute game changer, isn't it.

114
00:05:43.160 --> 00:05:46.160
<v Speaker 2>It really is answerable lets you manage your entire infrastructure

115
00:05:46.160 --> 00:05:48.399
<v Speaker 2>pretty much like a software developer manages code.

116
00:05:48.600 --> 00:05:51.000
<v Speaker 1>So version control like get.

117
00:05:50.720 --> 00:05:54.879
<v Speaker 2>Ye, get collaboration with poll requests, creating branches for new

118
00:05:54.920 --> 00:05:57.519
<v Speaker 2>features or testing. You can even run unit tests on

119
00:05:57.560 --> 00:05:58.839
<v Speaker 2>your infrastructure definitions.

120
00:05:59.000 --> 00:06:02.480
<v Speaker 1>Wow, that brings incredible consistency and peer review for security

121
00:06:02.519 --> 00:06:03.360
<v Speaker 1>and best practices.

122
00:06:03.639 --> 00:06:08.759
<v Speaker 2>Absolutely, and it fosters this shared, transparent understanding of how

123
00:06:08.800 --> 00:06:12.600
<v Speaker 2>your systems are actually built and maintained. It turns infrastructure

124
00:06:12.639 --> 00:06:14.959
<v Speaker 2>management from this kind of dark art done by a

125
00:06:15.000 --> 00:06:18.480
<v Speaker 2>few people into a collaborative, open engineering process.

126
00:06:18.519 --> 00:06:21.399
<v Speaker 1>Okay, let's get down to actually using it. Then. Installing

127
00:06:21.439 --> 00:06:24.319
<v Speaker 1>ansable sounds surprisingly straightforward.

128
00:06:24.439 --> 00:06:27.720
<v Speaker 2>It really is. On macOS, you've got great options Homebrew,

129
00:06:27.759 --> 00:06:30.759
<v Speaker 2>the package manager is super popular, or you can use

130
00:06:30.800 --> 00:06:34.439
<v Speaker 2>pip by Thon's package installer, which gives you really precise

131
00:06:34.480 --> 00:06:36.839
<v Speaker 2>control over the exact ansable version you want.

132
00:06:37.040 --> 00:06:39.439
<v Speaker 1>And for Linux like Ubuntu.

133
00:06:39.839 --> 00:06:43.120
<v Speaker 2>On Linux, pip is often preferred over the system package

134
00:06:43.120 --> 00:06:46.480
<v Speaker 2>manager like app. Why is that, Well, sometimes the app

135
00:06:46.480 --> 00:06:49.600
<v Speaker 2>packages can lag behind a bit become outdated quickly, so

136
00:06:49.680 --> 00:06:52.000
<v Speaker 2>PIP often gets you the latest features faster.

137
00:06:52.120 --> 00:06:54.800
<v Speaker 1>Right, and Windows users aren't left out, not at all.

138
00:06:54.920 --> 00:06:57.800
<v Speaker 2>You can easily use the Windows subsystem for Linux WSL

139
00:06:58.040 --> 00:07:00.439
<v Speaker 2>run antsable just like you're on a native Linux machine.

140
00:07:00.439 --> 00:07:01.879
<v Speaker 2>It feels totally seamless.

141
00:07:01.920 --> 00:07:04.600
<v Speaker 1>Okay, So once it's installed, you work with ansable's basic

142
00:07:04.639 --> 00:07:07.519
<v Speaker 1>building blocks, host inventories and playbooks.

143
00:07:07.800 --> 00:07:10.800
<v Speaker 2>That's right. A host inventory is essentially just a list

144
00:07:10.800 --> 00:07:12.600
<v Speaker 2>of the machines Anthemble is going to manage.

145
00:07:12.720 --> 00:07:14.920
<v Speaker 1>Can be super simple, right, like one IP address.

146
00:07:14.959 --> 00:07:16.839
<v Speaker 2>Yeah, it could be just a single IP with a

147
00:07:16.959 --> 00:07:20.600
<v Speaker 2>username and maybe a private key file. Or it can

148
00:07:20.600 --> 00:07:24.120
<v Speaker 2>get more complex, organizing hosts into logical groups, yeah, maybe

149
00:07:24.120 --> 00:07:25.680
<v Speaker 2>with shared settings for each group.

150
00:07:25.720 --> 00:07:29.399
<v Speaker 1>And then you have your playbooks. These are the automation blueprints.

151
00:07:28.879 --> 00:07:32.399
<v Speaker 2>Exactly your blueprints. They're written in the YAMEL that's yamil,

152
00:07:32.519 --> 00:07:35.879
<v Speaker 2>ain't markup language or anyone wondering, very.

153
00:07:35.839 --> 00:07:38.800
<v Speaker 1>Human readable, and they lay out the key parts.

154
00:07:38.639 --> 00:07:41.800
<v Speaker 2>YEP key elements like name, just a description of what

155
00:07:41.839 --> 00:07:46.519
<v Speaker 2>the playbook does. Host which machines or groups to target gatherfacts,

156
00:07:46.560 --> 00:07:50.240
<v Speaker 2>tells ansible to collect info about the target machines before starting.

157
00:07:50.240 --> 00:07:52.800
<v Speaker 1>Like OS version, IP address things.

158
00:07:52.680 --> 00:07:55.959
<v Speaker 2>Like that exactly. Then become that lets ansable run commands

159
00:07:55.959 --> 00:07:59.120
<v Speaker 2>with elevated privileges like pseudo or running his root. And

160
00:07:59.160 --> 00:08:00.000
<v Speaker 2>then you have handlers.

161
00:08:00.079 --> 00:08:02.199
<v Speaker 1>Handler's sound interesting. They're special tasks.

162
00:08:02.480 --> 00:08:05.360
<v Speaker 2>Yeah, they're pretty clever. Handlers only get triggered if a

163
00:08:05.399 --> 00:08:08.759
<v Speaker 2>prior task actually made a change to the system. And crucially,

164
00:08:09.079 --> 00:08:12.079
<v Speaker 2>they only run once at the very end of the

165
00:08:12.240 --> 00:08:15.360
<v Speaker 2>entire playbook, run even if multiple tasks notified them.

166
00:08:15.519 --> 00:08:18.319
<v Speaker 1>Ah, So like restarting a service only if it's config

167
00:08:18.360 --> 00:08:19.000
<v Speaker 1>file change.

168
00:08:19.160 --> 00:08:22.120
<v Speaker 2>Perfect example. Think of them as a highly efficient cleanup

169
00:08:22.160 --> 00:08:25.480
<v Speaker 2>crew that only jumps into action if something actually got modified.

170
00:08:25.920 --> 00:08:27.360
<v Speaker 2>Saves unnecessary restarts.

171
00:08:27.439 --> 00:08:29.720
<v Speaker 1>Makes sense, and running the playbook.

172
00:08:29.319 --> 00:08:32.039
<v Speaker 2>Is simple, super simple. A command like ansonable playbook on

173
00:08:32.120 --> 00:08:35.639
<v Speaker 2>a host's playbook dot iml that applies your configurations to

174
00:08:35.720 --> 00:08:38.639
<v Speaker 2>one machine or hundreds brings new machines up to your

175
00:08:38.679 --> 00:08:40.399
<v Speaker 2>desired state quickly, consistently.

176
00:08:40.519 --> 00:08:44.159
<v Speaker 1>When you think about using that single command, what for

177
00:08:44.279 --> 00:08:46.960
<v Speaker 1>you is the biggest time saver? For me, it's just

178
00:08:47.039 --> 00:08:50.480
<v Speaker 1>the sheer consistency across maybe dozens or hundreds of machines.

179
00:08:50.639 --> 00:08:54.399
<v Speaker 2>Absolutely, consistency is huge, but also just the ability to

180
00:08:54.440 --> 00:08:57.519
<v Speaker 2>bring a brand new, freshly launched machine to a perfectly

181
00:08:57.519 --> 00:09:00.559
<v Speaker 2>configured state with one command replicating what used to take

182
00:09:00.600 --> 00:09:04.519
<v Speaker 2>maybe hours of manual, error prone clicking and typing. It's

183
00:09:04.559 --> 00:09:08.600
<v Speaker 2>truly transformative, like having an army of tireless meticulous assistance.

184
00:09:08.840 --> 00:09:11.639
<v Speaker 1>Okay, so once you've got the basics down, you quickly

185
00:09:11.679 --> 00:09:15.759
<v Speaker 1>see the real power comes when you start scaling up reusability,

186
00:09:15.960 --> 00:09:17.759
<v Speaker 1>more advanced commands.

187
00:09:17.360 --> 00:09:19.960
<v Speaker 2>Exactly, and that brings us to the vibrant heart of

188
00:09:20.000 --> 00:09:21.120
<v Speaker 2>the ansible community.

189
00:09:21.559 --> 00:09:24.799
<v Speaker 1>Ansible galaxy, the community hubs.

190
00:09:24.600 --> 00:09:27.440
<v Speaker 2>Right, it's a central repository for what we call rolls

191
00:09:27.440 --> 00:09:28.120
<v Speaker 2>and collections.

192
00:09:28.200 --> 00:09:29.159
<v Speaker 1>Let's break those down.

193
00:09:29.279 --> 00:09:33.159
<v Speaker 2>Rolls first, okay. Roles are basically pre built, reusable units

194
00:09:33.159 --> 00:09:36.480
<v Speaker 2>of automation for common tasks I think installing a patche,

195
00:09:36.679 --> 00:09:39.639
<v Speaker 2>configuring NTP, setting up a database, user.

196
00:09:39.559 --> 00:09:41.799
<v Speaker 1>Stuff lots of people need to do exactly.

197
00:09:42.000 --> 00:09:44.879
<v Speaker 2>They have a standard folder structure, specific places for tasks,

198
00:09:44.960 --> 00:09:48.000
<v Speaker 2>files to copy, templates, variables, those handlers we talked about.

199
00:09:48.159 --> 00:09:51.200
<v Speaker 2>This structure makes them incredibly portable and super easy to

200
00:09:51.240 --> 00:09:54.919
<v Speaker 2>share and reuse and collections. They're newer yeah, introduced in

201
00:09:54.960 --> 00:09:58.399
<v Speaker 2>Antsable two point New collections are a more comprehensive way

202
00:09:58.440 --> 00:10:01.559
<v Speaker 2>to bundle things. They can passckage modules, the actual code

203
00:10:01.559 --> 00:10:04.360
<v Speaker 2>that does the work, plugins and rolls altogether, so like a.

204
00:10:04.360 --> 00:10:07.360
<v Speaker 1>Bigger content pack, maybe from a specific vendor.

205
00:10:07.600 --> 00:10:11.200
<v Speaker 2>Precisely makes it much easier to distribute and consume related

206
00:10:11.240 --> 00:10:14.879
<v Speaker 2>content from vendors or specific community projects. And you use

207
00:10:14.919 --> 00:10:18.519
<v Speaker 2>the ansable Galaxy command line tool to easily install roles

208
00:10:18.639 --> 00:10:21.600
<v Speaker 2>or collections, search for them, even publish your own. It

209
00:10:21.639 --> 00:10:24.480
<v Speaker 2>really expands the ecosystem now beyond.

210
00:10:24.120 --> 00:10:26.639
<v Speaker 1>Just Ansable Playbook, there's a whole suite of commands right

211
00:10:26.679 --> 00:10:28.000
<v Speaker 1>an antsible command toolkit.

212
00:10:28.039 --> 00:10:30.919
<v Speaker 2>There is for quick one off tasks against machines. You

213
00:10:31.000 --> 00:10:34.399
<v Speaker 2>use the Ansible command itself, not Ansible Playbook.

214
00:10:34.200 --> 00:10:37.080
<v Speaker 1>Like checking up time or installing one package.

215
00:10:36.720 --> 00:10:39.639
<v Speaker 2>Yeah, or running any module ad hoc. For instance, ansible

216
00:10:39.639 --> 00:10:42.519
<v Speaker 2>iosts all, Ansable dot build in dot ping just checks

217
00:10:42.559 --> 00:10:45.639
<v Speaker 2>connectivity to all hosts. Or you could update all packages

218
00:10:45.919 --> 00:10:49.120
<v Speaker 2>like ansible ihosts webservers, ansable dot build in dot app

219
00:10:49.600 --> 00:10:53.399
<v Speaker 2>a name state latest. It's like a powerful parallel remote.

220
00:10:53.080 --> 00:10:55.200
<v Speaker 1>Show, very handy for quick checks or changes.

221
00:10:55.360 --> 00:10:57.639
<v Speaker 2>What else is in the toolkit, Well, there's ansable config

222
00:10:57.720 --> 00:11:01.120
<v Speaker 2>for managing Antsable's configuration files. Ansable doc is super useful.

223
00:11:01.120 --> 00:11:03.840
<v Speaker 2>It gives you documentation on any module written your terminal.

224
00:11:04.039 --> 00:11:06.279
<v Speaker 2>An Soble inventory helps you work with your inventory files,

225
00:11:06.399 --> 00:11:07.480
<v Speaker 2>visualized groups, et cetera.

226
00:11:07.639 --> 00:11:09.399
<v Speaker 1>An ansible poll. That one sounds different.

227
00:11:09.639 --> 00:11:13.559
<v Speaker 2>It is quite unique. Ansible poll reverses the normal process

228
00:11:14.320 --> 00:11:18.159
<v Speaker 2>instead of your control node pushing configurations out. Target machines

229
00:11:18.200 --> 00:11:20.759
<v Speaker 2>can use ansible poll to pull playbooks down from source

230
00:11:20.799 --> 00:11:23.480
<v Speaker 2>control like get and run them locally.

231
00:11:23.720 --> 00:11:27.960
<v Speaker 1>Ah useful for machines that are maybe disconnected sometimes or

232
00:11:28.039 --> 00:11:30.679
<v Speaker 1>behind strict firewalls exactly.

233
00:11:30.399 --> 00:11:33.120
<v Speaker 2>Or if you just prefer a poll model for configuration management.

234
00:11:33.200 --> 00:11:37.519
<v Speaker 1>Okay, all these commands offer incredible flexibility. But this leads

235
00:11:37.559 --> 00:11:40.679
<v Speaker 1>to a critical question. We're writing all this configuous code,

236
00:11:40.720 --> 00:11:44.720
<v Speaker 1>maybe storing it and get how do you manage sensitive stuff? Passwords,

237
00:11:44.799 --> 00:11:47.679
<v Speaker 1>API keys. You can't just hardcode those, right.

238
00:11:47.639 --> 00:11:50.840
<v Speaker 2>Absolutely not. That's a huge security risk, and that's where

239
00:11:50.879 --> 00:11:53.759
<v Speaker 2>ansible volt comes in. It is an absolute life.

240
00:11:53.559 --> 00:11:56.000
<v Speaker 1>Saver, welt like a safe pretty much.

241
00:11:56.200 --> 00:11:59.320
<v Speaker 2>It's purpose built for securing your secrets within your answable project.

242
00:12:00.000 --> 00:12:02.120
<v Speaker 2>Can use it to encrypt entire files like maybe your

243
00:12:02.120 --> 00:12:05.879
<v Speaker 2>inventory file if it has passwords, or even more granularly,

244
00:12:06.159 --> 00:12:09.000
<v Speaker 2>you can encrypt individual variables directly within a playbook or

245
00:12:09.039 --> 00:12:10.159
<v Speaker 2>a variable file, so the.

246
00:12:10.159 --> 00:12:12.320
<v Speaker 1>File itself is still readable, but the secret part.

247
00:12:12.200 --> 00:12:15.600
<v Speaker 2>Is scrambled exactly. What's really genius here is that the

248
00:12:15.720 --> 00:12:19.639
<v Speaker 2>encrypted content remains fully readable by ansable when you provide

249
00:12:19.639 --> 00:12:22.240
<v Speaker 2>the vault password at runtime, but it appears as just

250
00:12:22.440 --> 00:12:26.120
<v Speaker 2>garbled unreadable text to any human looking at the file

251
00:12:26.159 --> 00:12:27.120
<v Speaker 2>and get or on disc.

252
00:12:27.559 --> 00:12:30.720
<v Speaker 1>That's brilliant. So it's safe to commit sensitive information directly

253
00:12:30.720 --> 00:12:31.679
<v Speaker 1>into your source control.

254
00:12:31.799 --> 00:12:34.519
<v Speaker 2>Yes, yeah, which is crucial for security, especially when you

255
00:12:34.519 --> 00:12:37.480
<v Speaker 2>integrate with CICD pipelines, which we'll talk about later. It

256
00:12:37.519 --> 00:12:40.480
<v Speaker 2>means your automation can run accessing the secrets it needs

257
00:12:40.519 --> 00:12:43.879
<v Speaker 2>without ever exposing those sensitive credentials in logs or to

258
00:12:43.960 --> 00:12:45.720
<v Speaker 2>developers just browsing the code.

259
00:12:45.799 --> 00:12:48.240
<v Speaker 1>Okay, that vault feature sounds essential. Let's move to some

260
00:12:48.279 --> 00:12:52.679
<v Speaker 1>practical applications censible really doing work. How about deploying a

261
00:12:52.720 --> 00:12:55.519
<v Speaker 1>classic web server stack like LMP.

262
00:12:55.480 --> 00:13:00.320
<v Speaker 2>Sure, LMP Linux, Apache, MERYDB, or myseql PHP. It's a

263
00:13:00.360 --> 00:13:04.039
<v Speaker 2>perfect example. You can combine multiple ansable roles. Maybe one

264
00:13:04.159 --> 00:13:06.440
<v Speaker 2>role for setting up a patche one for Maria dB,

265
00:13:06.600 --> 00:13:07.440
<v Speaker 2>one for Php.

266
00:13:07.639 --> 00:13:09.519
<v Speaker 1>Showing that modularity exactly.

267
00:13:09.600 --> 00:13:13.320
<v Speaker 2>Each role handles its specific part. The Apache role installs

268
00:13:13.320 --> 00:13:18.000
<v Speaker 2>the package, configures virtual hosts, manages firewall rules. Maybe the

269
00:13:18.080 --> 00:13:22.080
<v Speaker 2>MERIDB role installs the database, sets the root passwords securely

270
00:13:22.159 --> 00:13:26.840
<v Speaker 2>using vault, creates application databases and users. The Php role

271
00:13:26.879 --> 00:13:31.000
<v Speaker 2>installs the necessary modules. Ansable orchestrates all these roles together,

272
00:13:31.559 --> 00:13:35.960
<v Speaker 2>ensuring a consistent, repeatable lamp deployment every single time.

273
00:13:36.399 --> 00:13:39.600
<v Speaker 1>Nice. Now, one of the really cool tricks you mentioned

274
00:13:39.639 --> 00:13:43.320
<v Speaker 1>is managing different Linux operating systems, right like Debian and

275
00:13:43.399 --> 00:13:45.080
<v Speaker 1>red Hat, maybe with the same playbook.

276
00:13:45.200 --> 00:13:48.000
<v Speaker 2>Yeah, that's a huge benefit, especially in larger environments. You

277
00:13:48.000 --> 00:13:49.639
<v Speaker 2>don't want separate playbooks for everything.

278
00:13:49.720 --> 00:13:52.039
<v Speaker 1>So how does that work? How does ansble know the difference?

279
00:13:52.120 --> 00:13:56.120
<v Speaker 2>It's quite elegant. Actually, remember gather facts. Ansable collects information

280
00:13:56.159 --> 00:13:58.799
<v Speaker 2>about the target system. One of those facts is ANSI

281
00:13:58.840 --> 00:14:02.639
<v Speaker 2>police samiling. Your playbook can use conditional logic based on

282
00:14:02.679 --> 00:14:05.399
<v Speaker 2>that fact, like an if statement sort of. You can

283
00:14:05.519 --> 00:14:09.279
<v Speaker 2>use when ansible's family equals Debian on tasks specific to Debian, Ubuntu,

284
00:14:09.919 --> 00:14:13.799
<v Speaker 2>or you can use import tasks conditionally like import tasks

285
00:14:14.200 --> 00:14:17.720
<v Speaker 2>wn dot mL when dot ansib lea's family equals Debian

286
00:14:17.960 --> 00:14:20.320
<v Speaker 2>and have another for Redhead dot mml ah.

287
00:14:20.360 --> 00:14:24.240
<v Speaker 1>So you group the OS specific tasks into separate fives exactly.

288
00:14:24.440 --> 00:14:27.600
<v Speaker 2>It keeps the main playbook clean. This is absolutely essential

289
00:14:27.639 --> 00:14:31.200
<v Speaker 2>because things differ, right Yeah, package names HTTPD versus Apache

290
00:14:31.200 --> 00:14:34.480
<v Speaker 2>two service names. Security features like selnix or firewalled on

291
00:14:34.480 --> 00:14:37.960
<v Speaker 2>red Hat systems requires specific handling that Debian doesn't.

292
00:14:38.120 --> 00:14:42.240
<v Speaker 1>So a single well written role can truly be distribution agnostic,

293
00:14:42.279 --> 00:14:46.240
<v Speaker 1>makes them much more reusable. Perfect for sharing on Galaxy precisely. Okay.

294
00:14:46.279 --> 00:14:48.879
<v Speaker 1>Now for something maybe really surprising. Windows automation.

295
00:14:49.200 --> 00:14:52.320
<v Speaker 2>Yeah, it's one of ansable's lesser known superpowers. But it's

296
00:14:52.440 --> 00:14:53.240
<v Speaker 2>really capable.

297
00:14:53.320 --> 00:14:55.440
<v Speaker 1>So not just Linux. How does it talk to Windows?

298
00:14:55.759 --> 00:14:57.159
<v Speaker 1>Not SSH? Right? Right?

299
00:14:57.399 --> 00:15:00.519
<v Speaker 2>It uses win RM Windows Remote Management, which is Microsoft

300
00:15:00.519 --> 00:15:04.519
<v Speaker 2>standard protocol for remote management based on WS management. Ansable

301
00:15:04.519 --> 00:15:07.360
<v Speaker 2>has a rapidly growing collection of Windows specific modules.

302
00:15:07.360 --> 00:15:08.480
<v Speaker 1>What kind of things can you do?

303
00:15:08.759 --> 00:15:12.200
<v Speaker 2>A lot? You can launch Windows servers in Azure or AWS,

304
00:15:12.679 --> 00:15:17.240
<v Speaker 2>enable Windows features, manage local users and groups, install software

305
00:15:17.320 --> 00:15:20.279
<v Speaker 2>using tools like Chocolatey, a package manager for Windows. You

306
00:15:20.320 --> 00:15:25.080
<v Speaker 2>can manage services, registry, keys, reboot, machines run PowerShell scripts. Honestly,

307
00:15:25.120 --> 00:15:28.279
<v Speaker 2>the experience feels just as seamless and powerful as managing

308
00:15:28.279 --> 00:15:29.879
<v Speaker 2>a Linux host. Once you're set up.

309
00:15:29.919 --> 00:15:32.639
<v Speaker 1>That really brondzs the scope. And speaking of scope, ANTSAPLE

310
00:15:32.759 --> 00:15:35.519
<v Speaker 1>isn't just for servers, is it? Network automation? Oh?

311
00:15:35.559 --> 00:15:38.080
<v Speaker 2>Yeah. Network automation is a huge area for antsible now.

312
00:15:38.120 --> 00:15:42.399
<v Speaker 2>It covers a vast array of network devices. We're talking Cisco, Juniper, Arista,

313
00:15:42.600 --> 00:15:45.559
<v Speaker 2>F five, Checkpoint fort net list goes on.

314
00:15:45.679 --> 00:15:49.399
<v Speaker 1>So routers, switches, firewalls, load balancers, all of the above.

315
00:15:49.399 --> 00:15:51.919
<v Speaker 2>There are literally hundreds of network specific modules. You can

316
00:15:51.960 --> 00:15:57.360
<v Speaker 2>manage configurations, push updates, manage vlands, interfaces, firewall rules, BGP neighbors.

317
00:15:57.480 --> 00:16:01.200
<v Speaker 2>It transforms network configuration from this manual, often error prone,

318
00:16:01.240 --> 00:16:05.799
<v Speaker 2>CLI driven task into a fully automated code driven process,

319
00:16:05.879 --> 00:16:07.279
<v Speaker 2>just like servers.

320
00:16:07.000 --> 00:16:09.960
<v Speaker 1>Bringing infrastructure as code to the network stack exactly.

321
00:16:10.039 --> 00:16:12.759
<v Speaker 2>Huge benefits for consistency and speed and of.

322
00:16:12.679 --> 00:16:17.200
<v Speaker 1>Course the cloud massive platforms like Azure and AWS. How

323
00:16:17.240 --> 00:16:18.279
<v Speaker 1>does ansable play there.

324
00:16:18.320 --> 00:16:21.279
<v Speaker 2>It's a natural fit for Microsoft Azure. Ansable can do

325
00:16:21.320 --> 00:16:25.000
<v Speaker 2>the full life cycle launch vms, configure them, but also

326
00:16:25.080 --> 00:16:30.120
<v Speaker 2>manage the surrounding infrastructure v nets subnets, network security groups, nsgs,

327
00:16:30.320 --> 00:16:31.480
<v Speaker 2>Azure load balancers.

328
00:16:31.720 --> 00:16:34.559
<v Speaker 1>Can it automatically add new vms to its inventory?

329
00:16:35.000 --> 00:16:39.000
<v Speaker 2>Yes, Azure has dynamic inventory scripts for ansable, so as

330
00:16:39.000 --> 00:16:41.919
<v Speaker 2>you scale up vms, they automatically become manageable by ansable.

331
00:16:42.159 --> 00:16:45.039
<v Speaker 2>And critically, ansable has modules to wait for a VM

332
00:16:45.080 --> 00:16:48.360
<v Speaker 2>to be fully provisioned and ready, maybe wait for SSH

333
00:16:48.399 --> 00:16:52.639
<v Speaker 2>to be available before attempting configuration. Prevents so many frustrating.

334
00:16:52.320 --> 00:16:56.360
<v Speaker 1>Errors that weighting capability sounds simple but essential and AWS

335
00:16:56.519 --> 00:16:58.120
<v Speaker 1>similar story, very similar.

336
00:16:58.159 --> 00:17:01.519
<v Speaker 2>You can build out entire cloud networks on AWS, vpcs,

337
00:17:01.759 --> 00:17:06.440
<v Speaker 2>subjects across multiple availability zones, azs, Internet gateways, route tables,

338
00:17:06.440 --> 00:17:10.000
<v Speaker 2>security groups. Antsable can even dynamically retrieve your own public

339
00:17:10.000 --> 00:17:12.319
<v Speaker 2>IP address when running the playbook, so you can create

340
00:17:12.400 --> 00:17:15.880
<v Speaker 2>highly specific firewall rules in your security groups allowing access

341
00:17:15.880 --> 00:17:17.400
<v Speaker 2>only from where you're running antsable.

342
00:17:17.599 --> 00:17:19.599
<v Speaker 1>Very neat okay, Now for what you called a real

343
00:17:19.759 --> 00:17:25.200
<v Speaker 1>ASA moment highly available cloud deployments, this is like the

344
00:17:25.240 --> 00:17:27.960
<v Speaker 1>holy grail for many web applications, right staying up.

345
00:17:27.880 --> 00:17:30.319
<v Speaker 2>No matter what it is, and this is where ansable

346
00:17:30.359 --> 00:17:35.440
<v Speaker 2>truly shines in orchestrating complex, resilient architectures. Let's take deploying

347
00:17:35.440 --> 00:17:38.759
<v Speaker 2>a highly available WordPress site on AWS as an example.

348
00:17:38.480 --> 00:17:42.559
<v Speaker 1>Okay, WordPress needs a web server, database, file storage. How

349
00:17:42.559 --> 00:17:46.319
<v Speaker 1>do you make it highly available with ansable and AWS.

350
00:17:45.720 --> 00:17:50.480
<v Speaker 2>So ansable integrates multiple AWS services seamlessly. First, instead of

351
00:17:50.519 --> 00:17:53.359
<v Speaker 2>running a database on your web server VMS, you use

352
00:17:53.400 --> 00:17:56.119
<v Speaker 2>Amazon RDS, the Relational Database Service.

353
00:17:56.240 --> 00:18:00.079
<v Speaker 1>A managed database takes away the pain of managing myseql yourself.

354
00:18:00.000 --> 00:18:04.279
<v Speaker 2>Exactly highly available automated backups patching. Ansable just configures WordPress

355
00:18:04.279 --> 00:18:09.000
<v Speaker 2>to point to the RDS endpoint. Then, for the WordPress files, themes, plugins, uploads,

356
00:18:09.119 --> 00:18:11.759
<v Speaker 2>you need shared storage accessible by multiple web servers and

357
00:18:11.799 --> 00:18:15.200
<v Speaker 2>different ass For that use Amazon EFS Elastic file System.

358
00:18:15.279 --> 00:18:18.519
<v Speaker 2>Ansible mounts the EFS volume onto each web server instance.

359
00:18:18.400 --> 00:18:21.079
<v Speaker 1>So all instances see the same files. What about traffic?

360
00:18:21.279 --> 00:18:24.799
<v Speaker 2>You put an application Elastic load Balancer ELB in front

361
00:18:24.839 --> 00:18:28.359
<v Speaker 2>of your web servers. The ELB distributes traffic across instances

362
00:18:28.400 --> 00:18:33.200
<v Speaker 2>in multiple availability zones. Ansable configures the ELB target groups,

363
00:18:33.440 --> 00:18:34.400
<v Speaker 2>health checks.

364
00:18:34.119 --> 00:18:36.599
<v Speaker 1>And the web servers themselves. How do you handle scaling

365
00:18:36.640 --> 00:18:37.359
<v Speaker 1>and failures?

366
00:18:37.599 --> 00:18:41.440
<v Speaker 2>That's where Amazon Machine Images amis and Auto Scaling Groups

367
00:18:41.480 --> 00:18:44.160
<v Speaker 2>asgs come in. First, you use ansable to build a

368
00:18:44.240 --> 00:18:47.200
<v Speaker 2>golden AMI a pre configured image of your WordPress web

369
00:18:47.200 --> 00:18:50.559
<v Speaker 2>server with a patch in Jinks PHP, the EFS mount

370
00:18:50.640 --> 00:18:53.000
<v Speaker 2>everything set up. Then you tell an autoscaling group to

371
00:18:53.079 --> 00:18:56.759
<v Speaker 2>use this AMI launch instances across multiple azs and maintain

372
00:18:56.799 --> 00:19:00.359
<v Speaker 2>a desired number of instances. The ASG automatically repla places

373
00:19:00.359 --> 00:19:02.599
<v Speaker 2>fail instances and can scale up or down based on

374
00:19:02.680 --> 00:19:04.480
<v Speaker 2>load using ELB health checks.

375
00:19:04.559 --> 00:19:08.160
<v Speaker 1>Wow so ansable orchestrates the setup of RDS, EFS, ELB,

376
00:19:08.279 --> 00:19:09.799
<v Speaker 1>the Golden AMI, and the ASG.

377
00:19:10.160 --> 00:19:14.279
<v Speaker 2>Precisely, it ties all these powerful AWO services together into

378
00:19:14.279 --> 00:19:18.279
<v Speaker 2>a coherent, highly available WordPress deployment. If you connect this

379
00:19:18.359 --> 00:19:21.720
<v Speaker 2>to the bigger picture, this kind of sophisticated automation doesn't

380
00:19:21.720 --> 00:19:26.200
<v Speaker 2>just reduce potential downtime. It inherently builds resilience right into

381
00:19:26.240 --> 00:19:30.079
<v Speaker 2>your application architecture. It ensures your site stays available even

382
00:19:30.079 --> 00:19:34.000
<v Speaker 2>if an entire AWS availability zone has issues. Trying to

383
00:19:34.039 --> 00:19:38.200
<v Speaker 2>achieve that level of robustness manually would be incredibly complex,

384
00:19:38.519 --> 00:19:40.480
<v Speaker 2>time consuming, and error prone.

385
00:19:40.559 --> 00:19:43.960
<v Speaker 1>Okay, that AWUS example is impressive, but all this powerful

386
00:19:44.000 --> 00:19:46.599
<v Speaker 1>automation it sounds great that it also brings up a

387
00:19:46.640 --> 00:19:50.440
<v Speaker 1>crucial question, security and compliance. How do you make sure

388
00:19:50.480 --> 00:19:53.720
<v Speaker 1>your automated deployments are actually secure before they even run.

389
00:19:54.240 --> 00:19:56.640
<v Speaker 1>Just relying on manual code reviews seems risky.

390
00:19:56.759 --> 00:19:59.960
<v Speaker 2>It is risky. Humans miss things, especially in complex playbooks.

391
00:20:00.000 --> 00:20:02.839
<v Speaker 2>That's why Stata code analysis tools are absolutely essential in

392
00:20:02.880 --> 00:20:07.039
<v Speaker 2>an IIC world. Tools like checkof and kics are fantastic examples.

393
00:20:07.079 --> 00:20:08.160
<v Speaker 2>They're open source.

394
00:20:07.880 --> 00:20:10.279
<v Speaker 1>And they scan your ansable playbooks exactly.

395
00:20:10.359 --> 00:20:14.799
<v Speaker 2>They scan your playbooks, terraform code, Kubernetes, manifests, whatever IC

396
00:20:14.960 --> 00:20:18.039
<v Speaker 2>you have. They act as your automated safety net. They

397
00:20:18.039 --> 00:20:22.759
<v Speaker 2>look for common misconfigurations, potential security vulnerabilities, think like an

398
00:20:22.759 --> 00:20:25.759
<v Speaker 2>EC two instance accidentally getting a public IP when it

399
00:20:25.799 --> 00:20:28.680
<v Speaker 2>shouldn't or in at three bucket being public. They also

400
00:20:28.759 --> 00:20:32.519
<v Speaker 2>check for compliance issues like maybe unencrypted storage volumes or

401
00:20:32.559 --> 00:20:35.200
<v Speaker 2>resources missing required organizational tags.

402
00:20:35.519 --> 00:20:38.640
<v Speaker 1>So they're like that super meticulous colleague who reviews your

403
00:20:38.680 --> 00:20:41.160
<v Speaker 1>code for obvious flaws, but automated.

404
00:20:41.359 --> 00:20:44.119
<v Speaker 2>That's a great analogy, and they run fast, integrated to

405
00:20:44.160 --> 00:20:48.079
<v Speaker 2>CICD pipelines. They catch potential problems long before they hit production.

406
00:20:48.440 --> 00:20:50.640
<v Speaker 2>You can even add suppression comments in your code for

407
00:20:50.720 --> 00:20:53.319
<v Speaker 2>risks you've analyzed and decided to accept, so they don't

408
00:20:53.319 --> 00:20:54.039
<v Speaker 2>flag those again.

409
00:20:54.079 --> 00:20:57.279
<v Speaker 1>So they help prevent issues. Can ansable also help fix

410
00:20:57.359 --> 00:20:59.240
<v Speaker 1>issues or harden existing servers?

411
00:20:59.319 --> 00:21:03.000
<v Speaker 2>Yes? Absolutely. Ansible can integrate with s COPY, the Security

412
00:21:03.039 --> 00:21:07.240
<v Speaker 2>Content Automation Protocol. It's a NYST standard for automating vulnerability

413
00:21:07.279 --> 00:21:09.799
<v Speaker 2>management and compliance checking s KEP.

414
00:21:10.319 --> 00:21:11.599
<v Speaker 1>How does that work with ansable?

415
00:21:11.759 --> 00:21:15.160
<v Speaker 2>There's an open source implementation called openscap. You can use

416
00:21:15.200 --> 00:21:18.839
<v Speaker 2>ansable to run openscapy scans against your systems using pre

417
00:21:18.920 --> 00:21:23.799
<v Speaker 2>defined security baselines like CIS benchmarks or dissistigs. And here's

418
00:21:23.839 --> 00:21:27.960
<v Speaker 2>the really cool part. Openscap can often automatically generate ansible

419
00:21:28.000 --> 00:21:31.519
<v Speaker 2>playbooks or Bash scripts to remediate the problems it finds.

420
00:21:31.640 --> 00:21:34.079
<v Speaker 1>WHOA seriously, it writes the fix for.

421
00:21:34.039 --> 00:21:37.720
<v Speaker 2>You in many cases. Yes, it's incredibly powerful for maintaining

422
00:21:37.759 --> 00:21:41.720
<v Speaker 2>a hardened state and for web applications specifically. Ansible playbooks

423
00:21:41.720 --> 00:21:45.440
<v Speaker 2>can orchestrate security scans using specialized tools too, like wp

424
00:21:45.559 --> 00:21:49.759
<v Speaker 2>scan for WordPress vulnerabilities or oasp zeba, a more general

425
00:21:49.839 --> 00:21:52.720
<v Speaker 2>web app scanner. Often you'd run these tools inside doctor

426
00:21:52.799 --> 00:21:55.960
<v Speaker 2>containers triggered by ansable for consistency.

427
00:21:55.519 --> 00:21:58.960
<v Speaker 1>Okay, scanning before hardening during and this all feeds beautifully

428
00:21:58.960 --> 00:22:03.319
<v Speaker 1>into continuous integration and continuous delivery right CICD, making automation

429
00:22:03.440 --> 00:22:05.680
<v Speaker 1>truly frictionless.

430
00:22:05.000 --> 00:22:08.599
<v Speaker 2>Exactly cics where it all comes together platforms like GitHub actions,

431
00:22:08.599 --> 00:22:12.400
<v Speaker 2>get labci, Azure DevOps. They provide these temporary compute resources

432
00:22:12.599 --> 00:22:16.079
<v Speaker 2>ephemeral runners that automatically execute your ansible playbooks whenever code

433
00:22:16.119 --> 00:22:18.279
<v Speaker 2>changes are pushed to your repository, so.

434
00:22:18.319 --> 00:22:20.400
<v Speaker 1>No manual ansable playbook commands.

435
00:22:20.079 --> 00:22:24.319
<v Speaker 2>Anymore, ideally not for production deployments. You define your entire workflow,

436
00:22:24.680 --> 00:22:29.039
<v Speaker 2>linking the playbook, running static analysis with checkof maybe running tests,

437
00:22:29.319 --> 00:22:32.119
<v Speaker 2>and finally applying the playbook, all in the ammal file

438
00:22:32.359 --> 00:22:33.480
<v Speaker 2>right alongside your code.

439
00:22:33.519 --> 00:22:36.799
<v Speaker 1>What are the tricky parts there? Getting credential setup securely.

440
00:22:36.480 --> 00:22:41.079
<v Speaker 2>That's critical, setting up sshkey securely, managing cloud credentials like

441
00:22:41.119 --> 00:22:45.680
<v Speaker 2>Azure Service Principles or AWSIM roles, and storing sensitive stuff

442
00:22:45.680 --> 00:22:49.680
<v Speaker 2>like the ansible vault password. These platforms have secure secret

443
00:22:49.720 --> 00:22:53.920
<v Speaker 2>management features. You store the secrets there, not in your code.

444
00:22:54.519 --> 00:22:57.279
<v Speaker 2>The CICD runner gets temporary access when it runs.

445
00:22:57.359 --> 00:23:01.559
<v Speaker 1>So the core idea is push code, pipeline, run infrastructure updates,

446
00:23:01.920 --> 00:23:06.759
<v Speaker 1>no manual intervention, no exposed passwords, just consistent, repeatable deployments.

447
00:23:06.880 --> 00:23:09.799
<v Speaker 2>That's the goal. The pinnacle of automated reliability.

448
00:23:09.920 --> 00:23:13.240
<v Speaker 1>Thinking about that shift, moving from running playbooks manually to

449
00:23:13.279 --> 00:23:16.440
<v Speaker 1>a full CICD model, what stands out to you as

450
00:23:16.480 --> 00:23:19.240
<v Speaker 1>the biggest shift in mindset for a team making that transition?

451
00:23:20.119 --> 00:23:23.519
<v Speaker 2>Good question. I think it's the fundamental shift from well

452
00:23:23.599 --> 00:23:26.200
<v Speaker 2>it worked when I ran it to it always works

453
00:23:26.240 --> 00:23:29.799
<v Speaker 2>the same way. You move from a manual, often reactive

454
00:23:29.839 --> 00:23:35.640
<v Speaker 2>process to a proactive, automated one where consistency and reliability

455
00:23:35.640 --> 00:23:39.279
<v Speaker 2>are just baked in, it really changes team dynamics. You

456
00:23:39.319 --> 00:23:42.480
<v Speaker 2>start trusting the automation itself. It frees up so much

457
00:23:42.599 --> 00:23:46.200
<v Speaker 2>mental energy for innovation instead of constantly fighting fires or

458
00:23:46.440 --> 00:23:48.039
<v Speaker 2>worrying about deployment errors.

459
00:23:48.319 --> 00:23:50.599
<v Speaker 1>That makes a lot of sense. Let's explore a few

460
00:23:50.599 --> 00:23:53.559
<v Speaker 1>more advanced topics and really see the real world impact.

461
00:23:53.880 --> 00:23:56.720
<v Speaker 1>Answerable can integrate with other services too, right, going beyond

462
00:23:56.759 --> 00:23:58.720
<v Speaker 1>just configuring the machines themselves.

463
00:23:58.799 --> 00:24:01.119
<v Speaker 2>Oh yeah, that's where things get really integrated and powerful.

464
00:24:01.400 --> 00:24:03.960
<v Speaker 2>Antsl can talk to collaboration tools like Slack.

465
00:24:03.799 --> 00:24:05.680
<v Speaker 1>So you get notified when a playbook.

466
00:24:05.359 --> 00:24:08.640
<v Speaker 2>Runs exactly, send real time notifications, maybe color code the

467
00:24:08.640 --> 00:24:11.359
<v Speaker 2>message based on whether changes were made or if it failed.

468
00:24:11.680 --> 00:24:14.240
<v Speaker 2>Keeps everyone in the loop. You can also send detailed

469
00:24:14.279 --> 00:24:17.640
<v Speaker 2>messages to a host cyslog for centralized logging and auditing.

470
00:24:17.839 --> 00:24:21.440
<v Speaker 1>What about ITSM tools like service now Absolutely yeah.

471
00:24:21.599 --> 00:24:24.400
<v Speaker 2>You can have your playbook automatically open an incident ticket

472
00:24:24.400 --> 00:24:27.559
<v Speaker 2>in service now if something fails, or maybe open a

473
00:24:27.640 --> 00:24:31.079
<v Speaker 2>change request before starting and close it upon successful completion.

474
00:24:31.880 --> 00:24:34.680
<v Speaker 2>You could even attach the playbook run logs or configuration

475
00:24:34.759 --> 00:24:38.599
<v Speaker 2>files directly to the ticket for auditing purposes. This really

476
00:24:38.640 --> 00:24:42.160
<v Speaker 2>takes automation to the next level, ensuring operational processes are

477
00:24:42.200 --> 00:24:43.400
<v Speaker 2>followed automatically.

478
00:24:43.759 --> 00:24:47.480
<v Speaker 1>That's bridging the gap between automation code and business process.

479
00:24:48.079 --> 00:24:51.559
<v Speaker 1>Very cool. Now, what happens when things don't go as planned?

480
00:24:52.079 --> 00:24:55.240
<v Speaker 1>Because let's be honest, complex automation sometimes breaks.

481
00:24:55.559 --> 00:24:59.279
<v Speaker 2>You mentioned a debugger, Yes, the answerable playbook debugger. It

482
00:24:59.359 --> 00:25:02.720
<v Speaker 2>is an abs life saver, especially when you're working on complex,

483
00:25:03.119 --> 00:25:04.279
<v Speaker 2>multi step playbooks.

484
00:25:04.359 --> 00:25:06.279
<v Speaker 1>So if a task fails, it doesn't just stop.

485
00:25:06.559 --> 00:25:08.880
<v Speaker 2>You can configure it to drop you into an interactive

486
00:25:08.920 --> 00:25:11.000
<v Speaker 2>debugger shell right at the point of failure.

487
00:25:11.079 --> 00:25:12.039
<v Speaker 1>What can you do in there?

488
00:25:12.200 --> 00:25:15.480
<v Speaker 2>A lot? You can inspect all the variables available to

489
00:25:15.519 --> 00:25:18.480
<v Speaker 2>the task using commands like p task of ours pe

490
00:25:18.559 --> 00:25:21.839
<v Speaker 2>for print. You can review the exact error message and

491
00:25:21.920 --> 00:25:25.279
<v Speaker 2>here's the killer feature. You can often modify variables on

492
00:25:25.359 --> 00:25:28.839
<v Speaker 2>the fly right there in the debugger, and then rerun

493
00:25:29.039 --> 00:25:31.319
<v Speaker 2>just the failed task using the redo command.

494
00:25:31.480 --> 00:25:34.000
<v Speaker 1>No way, so you don't have to guess, change the

495
00:25:34.000 --> 00:25:36.119
<v Speaker 1>playbook and rerun the whole thing from the start.

496
00:25:36.279 --> 00:25:39.559
<v Speaker 2>Exactly. If you think a variable was wrong, you can

497
00:25:39.599 --> 00:25:42.559
<v Speaker 2>try changing it and immediately retry the task. It saves

498
00:25:42.599 --> 00:25:46.079
<v Speaker 2>an immense amount of debugging time and frustration, especially on

499
00:25:46.119 --> 00:25:47.200
<v Speaker 2>long running playbooks.

500
00:25:47.279 --> 00:25:50.599
<v Speaker 1>That debugger sounds incredibly useful. Okay, let's bring it all

501
00:25:50.599 --> 00:25:54.160
<v Speaker 1>home some concrete, real world examples where you've seen antsable

502
00:25:54.240 --> 00:25:55.079
<v Speaker 1>really make it different.

503
00:25:55.240 --> 00:25:58.799
<v Speaker 2>Sure, we've seen it use for incredible complex depliments, multi

504
00:25:58.839 --> 00:26:03.720
<v Speaker 2>component applications spanning dozens of servers across public clouds. Automating

505
00:26:03.720 --> 00:26:06.880
<v Speaker 2>that whole process cut deployment times from days to hours

506
00:26:07.200 --> 00:26:09.240
<v Speaker 2>and drastically reduced human error.

507
00:26:09.279 --> 00:26:11.039
<v Speaker 1>What about using it with other tools?

508
00:26:11.319 --> 00:26:14.359
<v Speaker 2>Yeah, A very common and powerful pattern is using ansable

509
00:26:14.359 --> 00:26:18.400
<v Speaker 2>with Terraform. Terraform is great at provisioning the core infrastructure

510
00:26:18.880 --> 00:26:23.960
<v Speaker 2>the VMS networks databases. Then Terraform hands off to ansable,

511
00:26:24.000 --> 00:26:28.279
<v Speaker 2>which handles the application level configuration, software installation, and bootstrapping

512
00:26:28.319 --> 00:26:32.559
<v Speaker 2>on that infrastructure. You leverage each tool's strengths terraform for

513
00:26:32.599 --> 00:26:35.559
<v Speaker 2>the wet ansable for the how on the instance, it's

514
00:26:35.559 --> 00:26:36.880
<v Speaker 2>a fantastic combo.

515
00:26:36.720 --> 00:26:39.119
<v Speaker 1>That makes sense using the right tool for the job.

516
00:26:39.200 --> 00:26:41.440
<v Speaker 1>Any other examples, maybe in enabling others.

517
00:26:41.519 --> 00:26:45.680
<v Speaker 2>Definitely deploying antsable awx, the open source version of red

518
00:26:45.720 --> 00:26:49.480
<v Speaker 2>hat Ansable automation platform or the commercial RedHat platform itself.

519
00:26:49.799 --> 00:26:52.640
<v Speaker 2>This gives you a web based UID and API for ansable.

520
00:26:52.920 --> 00:26:55.319
<v Speaker 2>We've seen companies use this to create self service IT

521
00:26:55.599 --> 00:26:56.160
<v Speaker 2>portals for.

522
00:26:56.119 --> 00:26:58.440
<v Speaker 1>Developers self service How does that work?

523
00:26:58.640 --> 00:27:01.720
<v Speaker 2>A developer might go to the atax WebUI fill out

524
00:27:01.720 --> 00:27:04.240
<v Speaker 2>a simple survey like I need a medium sized environment

525
00:27:04.279 --> 00:27:08.079
<v Speaker 2>with this database and it's emit awx then triggers an

526
00:27:08.079 --> 00:27:12.119
<v Speaker 2>ansable playbook behind the scenes that provisions the VMS, installs

527
00:27:12.119 --> 00:27:15.720
<v Speaker 2>the software, maybe updates the cmdb all automatically. It can

528
00:27:15.759 --> 00:27:19.400
<v Speaker 2>integrate with ticketing systems enforced role based access control. It

529
00:27:19.440 --> 00:27:22.599
<v Speaker 2>frees up the central IT team from handling repetitive requests

530
00:27:22.759 --> 00:27:24.519
<v Speaker 2>and empowers the developers directly.

531
00:27:24.680 --> 00:27:27.440
<v Speaker 1>That's huge, democratizing the automation exactly.

532
00:27:27.519 --> 00:27:31.799
<v Speaker 2>Another quick example automated DNS updates, giving frontline support teams

533
00:27:31.799 --> 00:27:35.640
<v Speaker 2>a simple AWX survey to update specific DNS records without

534
00:27:35.640 --> 00:27:38.720
<v Speaker 2>ever needing direct access to the complex DNS provider console.

535
00:27:38.960 --> 00:27:42.240
<v Speaker 2>AWX runs, the ansable playbook makes the change via API

536
00:27:42.640 --> 00:27:45.920
<v Speaker 2>and logs everything automatically, safe, controlled, auditive.

537
00:27:46.400 --> 00:27:48.720
<v Speaker 1>Wow, what a journey we've taken. We've really gone from

538
00:27:48.799 --> 00:27:53.200
<v Speaker 1>understanding ansables fascinating sci fi origins its core principles all

539
00:27:53.240 --> 00:27:56.400
<v Speaker 1>the way to seeing its practical application across different operating systems,

540
00:27:56.440 --> 00:27:59.880
<v Speaker 1>network gear and the major cloud providers like AWS Nazure.

541
00:28:00.160 --> 00:28:03.119
<v Speaker 2>Yeah, and we explored how it helps ensure security and

542
00:28:03.200 --> 00:28:07.200
<v Speaker 2>compliance through scanning, how it integrates so naturally into modern

543
00:28:07.400 --> 00:28:12.000
<v Speaker 2>CICD pipelines, and even how it enhances team collaboration through

544
00:28:12.119 --> 00:28:14.680
<v Speaker 2>things like notifications and self service portals.

545
00:28:14.880 --> 00:28:17.359
<v Speaker 1>What's really profound here, I think, is that answable isn't

546
00:28:17.400 --> 00:28:20.440
<v Speaker 1>just about technical efficiency, you know, automating a few scripts.

547
00:28:20.759 --> 00:28:25.640
<v Speaker 1>It's really about enabling consistency at scale, drastically reducing human

548
00:28:25.759 --> 00:28:29.279
<v Speaker 1>error which is always lurking, and freeing up incredibly valuable

549
00:28:29.279 --> 00:28:33.279
<v Speaker 1>time for people to do more strategic, more creative work.

550
00:28:33.359 --> 00:28:36.680
<v Speaker 2>Absolutely, it's fundamentally about defining your entire IT landscape as

551
00:28:36.799 --> 00:28:41.799
<v Speaker 2>executable code, making it repeatable, shareable, versionable, and scalable in

552
00:28:41.880 --> 00:28:45.480
<v Speaker 2>ways that were frankly unimaginable just a decade or so ago.

553
00:28:45.799 --> 00:28:48.519
<v Speaker 1>So, wrapping this up, what does all this mean for

554
00:28:48.720 --> 00:28:51.200
<v Speaker 1>you the listener? As you go about your day, think

555
00:28:51.200 --> 00:28:53.799
<v Speaker 1>about those manual tasks you do, the repetitive stuff. This

556
00:28:53.920 --> 00:28:57.799
<v Speaker 1>raises a critical personal question. Really, what single repetitive process

557
00:28:57.839 --> 00:28:59.640
<v Speaker 1>in your daily routine, maybe one that feels like a

558
00:28:59.640 --> 00:29:02.400
<v Speaker 1>constant drain or source of errors? Could you potentially start

559
00:29:02.440 --> 00:29:03.519
<v Speaker 1>automating with antsable?

560
00:29:03.720 --> 00:29:06.519
<v Speaker 2>It doesn't have to be a huge, complex system right away.

561
00:29:07.039 --> 00:29:10.880
<v Speaker 2>Often it's those small, targeted winds automating one annoying task

562
00:29:11.160 --> 00:29:14.319
<v Speaker 2>that build momentum and lead to the biggest, most satisfying

563
00:29:14.359 --> 00:29:15.359
<v Speaker 2>impacts down the line.