1
00:00:00,040 --> 00:00:01,320
Terraform exists because your
2
00:00:01,320 --> 00:00:02,520
Azure Portal clicks can't be
3
00:00:02,520 --> 00:00:03,439
rebuilt twice.
4
00:00:03,439 --> 00:00:05,280
It writes that infrastructure
down as a file.
5
00:00:05,280 --> 00:00:07,120
You can read, review, and run
again.
6
00:00:07,120 --> 00:00:09,599
Small plugins called providers,
many of them written by the
7
00:00:09,599 --> 00:00:13,119
platform teams themselves let
Terraform reach Azure, AWS, and
8
00:00:13,119 --> 00:00:14,560
thousands of other services.
9
00:00:14,560 --> 00:00:18,800
Welcome to the M365 FM podcast
where we explore the people,
10
00:00:18,800 --> 00:00:21,640
ideas, and technologies shaping
the future of work.
11
00:00:21,640 --> 00:00:24,120
Cloud teams keep coming back to
it because writing
12
00:00:24,120 --> 00:00:26,120
infrastructure down means nobody
has to remember it.
13
00:00:26,120 --> 00:00:27,600
So it's worth understanding even
14
00:00:27,600 --> 00:00:28,839
if you never write a line of it
15
00:00:28,839 --> 00:00:29,679
yourself.
16
00:00:29,679 --> 00:00:30,719
By the end, you'll be able to
17
00:00:30,719 --> 00:00:32,000
read a Terraform setup and say
18
00:00:32,000 --> 00:00:33,439
what it will do before it does
19
00:00:33,439 --> 00:00:34,399
anything.
20
00:00:34,399 --> 00:00:36,560
What infrastructure as code
really means?
21
00:00:36,560 --> 00:00:37,520
Think about the last time you
22
00:00:37,520 --> 00:00:38,520
built something in the Azure
23
00:00:38,520 --> 00:00:40,000
portal, a resource group, or a
24
00:00:40,000 --> 00:00:41,439
storage account, or a small
25
00:00:41,439 --> 00:00:42,640
virtual machine you needed for
26
00:00:42,640 --> 00:00:43,280
testing.
27
00:00:43,280 --> 00:00:45,119
It took ten minutes and
everything worked.
28
00:00:45,119 --> 00:00:46,299
Now imagine someone asked you to
29
00:00:46,299 --> 00:00:48,119
build that same setup again next
30
00:00:48,119 --> 00:00:48,320
month.
31
00:00:48,320 --> 00:00:51,439
For a different team, you have
to do it from memory naming
32
00:00:51,439 --> 00:00:54,119
every setting you picked in the
order you picked it.
33
00:00:54,119 --> 00:00:56,640
Almost nobody can get through
that without missing something.
34
00:00:56,640 --> 00:00:58,520
And that gap is the entire
reason.
35
00:00:58,520 --> 00:01:00,070
Infrastructure as code exists.
36
00:01:00,070 --> 00:01:02,570
Infrastructure as code means you
write down what you want to
37
00:01:02,570 --> 00:01:05,549
exist in a file instead of
clicking it into existence.
38
00:01:05,549 --> 00:01:07,230
The file is plain text, and it
39
00:01:07,230 --> 00:01:08,510
names the things you need, the
40
00:01:08,510 --> 00:01:09,430
way you'd write a list for
41
00:01:09,430 --> 00:01:10,269
someone else.
42
00:01:10,269 --> 00:01:13,030
It sits in the same place as
your other work, which changes
43
00:01:13,030 --> 00:01:14,269
how a team behaves.
44
00:01:14,269 --> 00:01:15,390
A change to the file can be
45
00:01:15,390 --> 00:01:16,709
reviewed before it happens and
46
00:01:16,709 --> 00:01:17,909
traced afterwards.
47
00:01:17,909 --> 00:01:20,750
It also means you can copy the
file, so a setup that works in
48
00:01:20,750 --> 00:01:22,829
one place can be reused
somewhere else without anyone
49
00:01:22,829 --> 00:01:24,310
rebuilding it from memory.
50
00:01:24,310 --> 00:01:26,790
People describe infrastructure
in a file in two different ways,
51
00:01:26,790 --> 00:01:28,590
and the difference matters more
than it sounds.
52
00:01:28,590 --> 00:01:29,989
One way is imperative, where you
53
00:01:29,989 --> 00:01:31,189
spell out every step in order,
54
00:01:31,189 --> 00:01:32,750
creating one thing and then the
55
00:01:32,750 --> 00:01:34,189
next, and then connecting the
56
00:01:34,189 --> 00:01:35,109
two together.
57
00:01:35,109 --> 00:01:37,629
The other way is declarative,
where you describe the result
58
00:01:37,629 --> 00:01:39,909
you want and let the tool work
out the steps.
59
00:01:39,909 --> 00:01:41,189
Terraform belongs to the second
60
00:01:41,189 --> 00:01:42,469
group, which is why you almost
61
00:01:42,469 --> 00:01:43,670
never see it written as a list
62
00:01:43,670 --> 00:01:44,390
of instructions.
63
00:01:44,390 --> 00:01:46,829
So the habit shift is simple
enough to say out loud.
64
00:01:46,829 --> 00:01:49,310
You stop remembering what you
clicked and you start writing
65
00:01:49,310 --> 00:01:50,469
down what you want.
66
00:01:50,469 --> 00:01:51,629
Everything else in this episode
67
00:01:51,629 --> 00:01:53,030
is a detail hanging off that one
68
00:01:53,030 --> 00:01:53,629
change.
69
00:01:53,629 --> 00:01:55,989
The first time a plan comes back
with nothing to change.
70
00:01:55,989 --> 00:01:58,150
You'll see why teams get
attached to it.
71
00:01:58,150 --> 00:02:00,099
What Terraform actually is.
72
00:02:00,099 --> 00:02:01,500
Terraform is an infrastructure
73
00:02:01,500 --> 00:02:02,819
as code tool that lets you
74
00:02:02,819 --> 00:02:04,420
build, change, and version your
75
00:02:04,420 --> 00:02:06,019
cloud resources safely and
76
00:02:06,019 --> 00:02:06,579
efficiently.
77
00:02:06,579 --> 00:02:07,579
That's how HashiCorp, the
78
00:02:07,579 --> 00:02:09,139
company that built it, describes
79
00:02:09,139 --> 00:02:09,939
the product.
80
00:02:09,939 --> 00:02:11,500
Those three verbs build, change,
81
00:02:11,500 --> 00:02:12,780
and version cover nearly
82
00:02:12,780 --> 00:02:14,060
everything you'll ever do with
83
00:02:14,060 --> 00:02:14,620
it.
84
00:02:14,620 --> 00:02:15,659
It also works with older
85
00:02:15,659 --> 00:02:16,939
infrastructure that runs in your
86
00:02:16,939 --> 00:02:18,300
own data center, which is what
87
00:02:18,300 --> 00:02:19,460
people mean when they say on
88
00:02:19,460 --> 00:02:20,020
premises.
89
00:02:20,020 --> 00:02:22,740
HashiCorp released Terraform in
twenty fourteen, and the tool
90
00:02:22,740 --> 00:02:25,020
has had more than a decade to
grow up in public.
91
00:02:25,020 --> 00:02:27,280
It grew alongside cloud
platforms and had years to
92
00:02:27,280 --> 00:02:28,740
smooth down the rough edges.
93
00:02:28,740 --> 00:02:30,139
It now handles small things like
94
00:02:30,139 --> 00:02:31,580
a single storage account and
95
00:02:31,580 --> 00:02:32,819
large things like an entire
96
00:02:32,819 --> 00:02:34,780
network with routing firewalls
97
00:02:34,780 --> 00:02:36,099
and a load balancer in front of
98
00:02:36,099 --> 00:02:36,580
it.
99
00:02:36,580 --> 00:02:38,180
It also had time to settle into
100
00:02:38,180 --> 00:02:39,460
a shape a beginner can pick up
101
00:02:39,460 --> 00:02:40,939
in an afternoon, which is not
102
00:02:40,939 --> 00:02:42,340
something every cloud tool can
103
00:02:42,340 --> 00:02:42,979
claim.
104
00:02:42,979 --> 00:02:46,020
The workflow underneath all of
that has three stages, and
105
00:02:46,020 --> 00:02:48,259
they're worth holding on to
because every other idea in this
106
00:02:48,259 --> 00:02:49,699
episode hangs off them.
107
00:02:49,699 --> 00:02:51,699
First, you write the
configuration, which is a text
108
00:02:51,699 --> 00:02:54,020
file in a language HashiCorp
built for the job.
109
00:02:54,020 --> 00:02:55,300
It reads close to plain English.
110
00:02:55,300 --> 00:02:57,979
Once you know a handful of
words, then Terraform produces a
111
00:02:57,979 --> 00:03:01,659
plan describing what it intends
to create, change, or destroy.
112
00:03:01,659 --> 00:03:04,300
Once you approve that plan, it
goes and does the work in the
113
00:03:04,300 --> 00:03:06,620
right order without you walking
it through the steps.
114
00:03:06,620 --> 00:03:09,139
That order matters more than
beginners expect.
115
00:03:09,139 --> 00:03:11,740
Terraform builds what's called a
dependency graph.
116
00:03:11,740 --> 00:03:13,240
It knows that a network has to
117
00:03:13,240 --> 00:03:14,580
exist before anything can be
118
00:03:14,580 --> 00:03:16,139
attached to it, and it works
119
00:03:16,139 --> 00:03:17,340
through everything that doesn't
120
00:03:17,340 --> 00:03:18,819
depend on anything else at the
121
00:03:18,819 --> 00:03:19,500
same time.
122
00:03:19,500 --> 00:03:21,219
You never write that sequence
yourself.
123
00:03:21,219 --> 00:03:22,659
You describe the destination and
124
00:03:22,659 --> 00:03:24,240
Terraform finds a route
125
00:03:24,240 --> 00:03:26,379
providers how Terraform talks to
126
00:03:26,379 --> 00:03:27,060
your cloud.
127
00:03:27,060 --> 00:03:29,419
The next word to learn is
provider, and it's the one that
128
00:03:29,419 --> 00:03:30,979
unlocks the rest of Terraform.
129
00:03:30,979 --> 00:03:33,340
A provider is a plugin that
teaches Terraform how to speak
130
00:03:33,340 --> 00:03:34,539
to a single platform.
131
00:03:34,539 --> 00:03:35,860
It uses the interface that
132
00:03:35,860 --> 00:03:37,300
platform publishes for software,
133
00:03:37,300 --> 00:03:38,699
which the cloud world calls an
134
00:03:38,699 --> 00:03:39,539
API.
135
00:03:39,539 --> 00:03:41,819
Add the Azure provider and
Terraform can create Azure
136
00:03:41,819 --> 00:03:45,419
resources, add the AWS provider,
and it can create AWS resources.
137
00:03:45,419 --> 00:03:48,740
With both in place, it can build
across the two in a single run.
138
00:03:48,740 --> 00:03:51,060
There's a provider for almost
everything you've heard of from
139
00:03:51,060 --> 00:03:53,860
the three big clouds to
Kubernetes, GitHub, Datadog, and
140
00:03:53,860 --> 00:03:57,009
a long tail of smaller services
HashiCorp and the community have
141
00:03:57,009 --> 00:03:59,569
written thousands of them, and
they're all listed publicly in
142
00:03:59,569 --> 00:04:00,849
the Terraform registry.
143
00:04:00,849 --> 00:04:02,210
The reason providers exist as a
144
00:04:02,210 --> 00:04:03,169
separate thing is worth a
145
00:04:03,169 --> 00:04:03,849
moment.
146
00:04:03,849 --> 00:04:05,330
Terraform itself stays fairly
147
00:04:05,330 --> 00:04:06,349
small and only knows how to
148
00:04:06,349 --> 00:04:07,530
compare what you want with what
149
00:04:07,530 --> 00:04:08,009
exists.
150
00:04:08,009 --> 00:04:09,490
Each platform contributes its
151
00:04:09,490 --> 00:04:11,090
own translation layer, written
152
00:04:11,090 --> 00:04:12,129
by the people who know that
153
00:04:12,129 --> 00:04:12,969
platform best.
154
00:04:12,969 --> 00:04:15,129
A resource is the second piece
of vocabulary.
155
00:04:15,129 --> 00:04:17,769
A resource is one thing you want
to exist, such as a storage
156
00:04:17,769 --> 00:04:19,370
account or a virtual network.
157
00:04:19,370 --> 00:04:20,649
You describe it by naming the
158
00:04:20,649 --> 00:04:22,009
kind of thing it is, then
159
00:04:22,009 --> 00:04:23,170
listing the settings you care
160
00:04:23,170 --> 00:04:23,649
about.
161
00:04:23,649 --> 00:04:25,370
Everything else gets a sensible
default.
162
00:04:25,370 --> 00:04:26,449
That's the entire shape of a
163
00:04:26,449 --> 00:04:27,850
Terraform file, repeated as many
164
00:04:27,850 --> 00:04:28,870
times as you have things to
165
00:04:28,870 --> 00:04:29,449
build.
166
00:04:29,449 --> 00:04:32,129
This is also where the fear
about being locked into one
167
00:04:32,129 --> 00:04:33,449
cloud falls apart.
168
00:04:33,449 --> 00:04:36,250
Because providers are separate
from Terraform, the same tool
169
00:04:36,250 --> 00:04:38,970
reaches several platforms, and
one configuration can manage an
170
00:04:38,970 --> 00:04:41,930
Azure environment and a GitHub
repository at the same time.
171
00:04:41,930 --> 00:04:44,170
You're not choosing a vendor
when you choose Terraform,
172
00:04:44,170 --> 00:04:46,250
you're choosing a way of
describing what you want.
173
00:04:46,250 --> 00:04:48,490
The part people get wrong first
is not the provider, though.
174
00:04:48,490 --> 00:04:51,089
It's the file Terraform keeps
about everything it has already
175
00:04:51,089 --> 00:04:53,930
built, and that file has caused
more damage to more teams than
176
00:04:53,930 --> 00:04:55,240
any other piece of this tool.
177
00:04:55,240 --> 00:04:58,560
We'll get to it and I'll tell
you exactly where it bites.
178
00:04:58,560 --> 00:05:00,740
Plan and apply the safety net
179
00:05:00,740 --> 00:05:01,959
you meet for commands when you
180
00:05:01,959 --> 00:05:03,120
start with Terraform, and they
181
00:05:03,120 --> 00:05:04,920
arrive in a fixed order and it
182
00:05:04,920 --> 00:05:06,279
prepares your working folder and
183
00:05:06,279 --> 00:05:07,480
downloads the providers you
184
00:05:07,480 --> 00:05:08,079
asked for.
185
00:05:08,079 --> 00:05:09,319
Plan works out what would change
186
00:05:09,319 --> 00:05:10,560
and apply makes those changes
187
00:05:10,560 --> 00:05:11,040
real.
188
00:05:11,040 --> 00:05:12,240
Destroy takes everything down
189
00:05:12,240 --> 00:05:13,459
again, which is the command you
190
00:05:13,459 --> 00:05:14,800
keep in your pocket and treat
191
00:05:14,800 --> 00:05:15,720
with respect.
192
00:05:15,720 --> 00:05:17,279
Plan is the one that earns
Terraform.
193
00:05:17,279 --> 00:05:17,839
It's trust.
194
00:05:17,839 --> 00:05:21,160
Terraform compares three things
what you wrote, what it recorded
195
00:05:21,160 --> 00:05:23,920
last time, and what exists in
your cloud right now.
196
00:05:23,920 --> 00:05:25,160
Then it shows you a list of what
197
00:05:25,160 --> 00:05:26,920
it intends to add, change, or
198
00:05:26,920 --> 00:05:28,079
delete before it touches
199
00:05:28,079 --> 00:05:28,839
anything.
200
00:05:28,839 --> 00:05:31,680
You get to read that list, argue
about it with a colleague, and
201
00:05:31,680 --> 00:05:32,680
change your mind.
202
00:05:32,680 --> 00:05:33,639
Apply as the short step.
203
00:05:33,639 --> 00:05:36,519
At the end, you confirm the plan
and Terraform executes it
204
00:05:36,519 --> 00:05:39,000
respecting the dependencies it
worked out earlier.
205
00:05:39,000 --> 00:05:41,379
If your configuration asks for a
virtual network and three
206
00:05:41,379 --> 00:05:44,240
machines inside, Terraform will
make sure the network exists.
207
00:05:44,240 --> 00:05:45,360
First, nothing has to be
208
00:05:45,360 --> 00:05:46,839
sequenced by hand, and once you
209
00:05:46,839 --> 00:05:48,079
approve the plan, you can step
210
00:05:48,079 --> 00:05:49,000
back in.
211
00:05:49,000 --> 00:05:50,160
A team plan stops being a
212
00:05:50,160 --> 00:05:51,240
personal habit and becomes a
213
00:05:51,240 --> 00:05:52,120
checkpoint.
214
00:05:52,120 --> 00:05:54,149
The plan gets attached to the
change request.
215
00:05:54,149 --> 00:05:55,189
A colleague reads it and the
216
00:05:55,189 --> 00:05:56,709
apply only happens after someone
217
00:05:56,709 --> 00:05:57,910
else has looked at what's about
218
00:05:57,910 --> 00:05:58,750
to happen.
219
00:05:58,750 --> 00:06:00,629
That feels different from
watching a colleague click
220
00:06:00,629 --> 00:06:02,790
through the portal while you
read the output afterwards.
221
00:06:02,790 --> 00:06:04,189
Destroy deserves its own mention
222
00:06:04,189 --> 00:06:05,310
because it does exactly what it
223
00:06:05,310 --> 00:06:06,050
says, and it does it to
224
00:06:06,050 --> 00:06:07,430
everything in that state file at
225
00:06:07,430 --> 00:06:07,750
once.
226
00:06:07,750 --> 00:06:09,790
There's an honest caveat worth
saying out loud.
227
00:06:09,790 --> 00:06:10,990
Plan output can be a wall of
228
00:06:10,990 --> 00:06:12,550
text on your first attempt, and
229
00:06:12,550 --> 00:06:13,470
some entries are hard to
230
00:06:13,470 --> 00:06:13,990
predict.
231
00:06:13,990 --> 00:06:15,189
That's especially true when
232
00:06:15,189 --> 00:06:16,550
Terraform warns that a change
233
00:06:16,550 --> 00:06:17,629
will force a resource to be
234
00:06:17,629 --> 00:06:18,350
replaced.
235
00:06:18,350 --> 00:06:19,589
That warning is not an error.
236
00:06:19,589 --> 00:06:22,230
It's Terraform telling you it
plans to delete the old thing
237
00:06:22,230 --> 00:06:23,029
and build a new one.
238
00:06:23,029 --> 00:06:25,589
Read those lines slowly, because
that's where surprises live.
239
00:06:25,589 --> 00:06:28,670
So plan is the safety net, and
the reason it can work at all is
240
00:06:28,670 --> 00:06:31,470
that Terraform has something to
compare your file against.
241
00:06:31,470 --> 00:06:32,790
That something is the state
242
00:06:32,790 --> 00:06:34,149
file, the one I mentioned, and
243
00:06:34,149 --> 00:06:35,389
it gets its own section in a
244
00:06:35,389 --> 00:06:36,069
moment.
245
00:06:36,069 --> 00:06:38,110
The state file Terraform's
memory.
246
00:06:38,110 --> 00:06:40,189
The scary file is called the
state file, and it is
247
00:06:40,189 --> 00:06:42,550
terraform's memory of the
infrastructure it built.
248
00:06:42,550 --> 00:06:43,910
HashiCorp describes it as the
249
00:06:43,910 --> 00:06:44,910
source of truth for your
250
00:06:44,910 --> 00:06:45,509
environment.
251
00:06:45,509 --> 00:06:47,269
In plain terms, Terraform uses
252
00:06:47,269 --> 00:06:48,670
this record to decide what has
253
00:06:48,670 --> 00:06:49,269
to change.
254
00:06:49,269 --> 00:06:51,230
So reality matches what you
wrote.
255
00:06:51,230 --> 00:06:52,430
Without it, Terraform would have
256
00:06:52,430 --> 00:06:53,779
no idea which of the resources
257
00:06:53,779 --> 00:06:55,300
in your subscription it created
258
00:06:55,300 --> 00:06:56,220
and which ones were there
259
00:06:56,220 --> 00:06:56,980
before.
260
00:06:56,980 --> 00:06:59,379
Inside the state file, you'll
find real details about real
261
00:06:59,379 --> 00:07:01,779
things, including the
identifiers your cloud assigns
262
00:07:01,779 --> 00:07:04,459
to each resource and the values
you gave it.
263
00:07:04,459 --> 00:07:05,620
Some of those values are
264
00:07:05,620 --> 00:07:06,980
passwords, connection strings,
265
00:07:06,980 --> 00:07:08,639
and private addresses, and they
266
00:07:08,639 --> 00:07:10,060
sit in that file as readable
267
00:07:10,060 --> 00:07:10,699
text.
268
00:07:10,699 --> 00:07:12,019
That one detail explains most of
269
00:07:12,019 --> 00:07:13,180
the rules people repeat about
270
00:07:13,180 --> 00:07:13,620
state.
271
00:07:13,620 --> 00:07:15,019
Never commit it to your team's
272
00:07:15,019 --> 00:07:16,779
code repository and never open
273
00:07:16,779 --> 00:07:18,220
it and start editing entries by
274
00:07:18,220 --> 00:07:18,660
hand.
275
00:07:18,660 --> 00:07:21,220
Instead, you use the commands
built for the job.
276
00:07:21,220 --> 00:07:24,339
Moving a resource or renaming it
in state is a command, and
277
00:07:24,339 --> 00:07:26,540
removing something from state
without deleting it from your
278
00:07:26,540 --> 00:07:27,379
cloud is another.
279
00:07:27,379 --> 00:07:28,459
They exist precisely so you
280
00:07:28,459 --> 00:07:29,459
never have to touch the file
281
00:07:29,459 --> 00:07:30,060
itself.
282
00:07:30,060 --> 00:07:31,420
It sounds fussy until the first
283
00:07:31,420 --> 00:07:32,500
time you rename something in
284
00:07:32,500 --> 00:07:34,100
your configuration and need the
285
00:07:34,100 --> 00:07:35,339
record to follow along without
286
00:07:35,339 --> 00:07:36,420
rebuilding the resource from
287
00:07:36,420 --> 00:07:37,220
scratch.
288
00:07:37,220 --> 00:07:38,459
If the state file is lost or
289
00:07:38,459 --> 00:07:40,019
damaged, the recovery is not
290
00:07:40,019 --> 00:07:40,540
quick.
291
00:07:40,540 --> 00:07:41,660
You can restore an older copy
292
00:07:41,660 --> 00:07:42,699
from a backup if you set your
293
00:07:42,699 --> 00:07:44,019
storage up to keep versions,
294
00:07:44,019 --> 00:07:45,259
which is a small decision with a
295
00:07:45,259 --> 00:07:46,860
large payoff without one, you
296
00:07:46,860 --> 00:07:48,379
rebuild the record by importing
297
00:07:48,379 --> 00:07:49,819
each existing resource one at a
298
00:07:49,819 --> 00:07:51,660
time, and that gets slow very
299
00:07:51,660 --> 00:07:52,060
fast.
300
00:07:52,060 --> 00:07:53,259
On a large environment.
301
00:07:53,259 --> 00:07:54,420
It's the kind of afternoon
302
00:07:54,420 --> 00:07:55,699
nobody plans for and everybody
303
00:07:55,699 --> 00:07:56,540
remembers.
304
00:07:56,540 --> 00:07:58,980
Handled properly, though, this
file is what makes Terraform
305
00:07:58,980 --> 00:08:02,139
feel fast on your first run, it
records the things it created on
306
00:08:02,139 --> 00:08:02,779
your second run.
307
00:08:02,779 --> 00:08:05,139
It looks at those resources,
notices that most of them
308
00:08:05,139 --> 00:08:07,620
already match what you want and
leaves them alone.
309
00:08:07,620 --> 00:08:11,019
Nothing is created twice,
nothing is deleted by accident,
310
00:08:11,019 --> 00:08:13,620
and the only work left is
whatever you changed.
311
00:08:13,620 --> 00:08:15,699
That's the payoff of keeping the
record honest.
312
00:08:15,699 --> 00:08:18,560
And it's why the boring advice
about backups and access control
313
00:08:18,560 --> 00:08:20,139
turns out to matter so much.
314
00:08:20,139 --> 00:08:22,420
Modules stop rebuilding the same
thing.
315
00:08:22,420 --> 00:08:23,420
Once you've written the same
316
00:08:23,420 --> 00:08:24,660
block of configuration a few
317
00:08:24,660 --> 00:08:25,860
times, you'll notice the
318
00:08:25,860 --> 00:08:26,420
pattern.
319
00:08:26,420 --> 00:08:29,500
Every new project needs a
storage account, a network, and
320
00:08:29,500 --> 00:08:32,460
a set of permissions, and the
details differ only slightly
321
00:08:32,460 --> 00:08:33,259
from the last one.
322
00:08:33,259 --> 00:08:34,419
A module is how Terraform
323
00:08:34,419 --> 00:08:35,460
answers that, and it's a
324
00:08:35,460 --> 00:08:36,340
reusable bundle of
325
00:08:36,340 --> 00:08:37,659
infrastructure that you can hand
326
00:08:37,659 --> 00:08:38,700
to a colleague or keep for
327
00:08:38,700 --> 00:08:39,500
yourself.
328
00:08:39,500 --> 00:08:41,820
HashiCorp calls them
configurable collections of
329
00:08:41,820 --> 00:08:44,100
infrastructure, which is
accurate and a little dry.
330
00:08:44,100 --> 00:08:45,460
Think of a module as a recipe
331
00:08:45,460 --> 00:08:46,860
with a few blanks you fill in
332
00:08:46,860 --> 00:08:47,379
each time.
333
00:08:47,379 --> 00:08:48,659
Modules come from two places.
334
00:08:48,659 --> 00:08:50,259
There's a public registry full
335
00:08:50,259 --> 00:08:51,529
of modules that other people
336
00:08:51,529 --> 00:08:52,970
published, covering everything
337
00:08:52,970 --> 00:08:54,289
from a single secure storage
338
00:08:54,289 --> 00:08:56,169
account to complete multi-region
339
00:08:56,169 --> 00:08:57,129
environments.
340
00:08:57,129 --> 00:08:57,970
Then there are the private
341
00:08:57,970 --> 00:08:59,289
modules your own team writes,
342
00:08:59,289 --> 00:09:00,289
which encode how your
343
00:09:00,289 --> 00:09:01,970
organization does things from
344
00:09:01,970 --> 00:09:03,090
naming conventions to the
345
00:09:03,090 --> 00:09:04,210
network rules that must be
346
00:09:04,210 --> 00:09:04,889
applied.
347
00:09:04,889 --> 00:09:06,049
The private ones are usually the
348
00:09:06,049 --> 00:09:07,309
more valuable of the two,
349
00:09:07,309 --> 00:09:08,409
because they carry knowledge
350
00:09:08,409 --> 00:09:09,610
that isn't in any vendor's
351
00:09:09,610 --> 00:09:10,570
documentation.
352
00:09:10,570 --> 00:09:13,210
There's a cost worth naming a
module you didn't write is still
353
00:09:13,210 --> 00:09:15,529
code that runs against your
subscription, and you're the one
354
00:09:15,529 --> 00:09:16,649
who answers for it.
355
00:09:16,649 --> 00:09:17,889
PIN the version you're using so
356
00:09:17,889 --> 00:09:18,970
an update doesn't arrive while
357
00:09:18,970 --> 00:09:20,529
you're asleep, and read what the
358
00:09:20,529 --> 00:09:21,809
module does before you point it
359
00:09:21,809 --> 00:09:22,490
at anything.
360
00:09:22,490 --> 00:09:24,090
That's not caution for its own
sake.
361
00:09:24,090 --> 00:09:26,169
It's the same instinct that
stops you installing software
362
00:09:26,169 --> 00:09:28,210
from a link a stranger sent you
the first time.
363
00:09:28,210 --> 00:09:30,769
You swap a hundred lines of
repeated configuration for a
364
00:09:30,769 --> 00:09:33,409
module you call with three
settings, the point stops
365
00:09:33,409 --> 00:09:35,809
needing any explanation at all.
366
00:09:35,809 --> 00:09:37,889
Remote state working with other
people.
367
00:09:37,889 --> 00:09:40,730
Everything so far works on one
laptop, and that's where it
368
00:09:40,730 --> 00:09:41,889
stops being simple.
369
00:09:41,889 --> 00:09:44,769
Picture two engineers on the
same team, both fixing something
370
00:09:44,769 --> 00:09:46,049
on a Friday afternoon.
371
00:09:46,049 --> 00:09:47,490
The two of them run a plan, see
372
00:09:47,490 --> 00:09:48,904
the same state file and apply a
373
00:09:48,904 --> 00:09:49,440
change.
374
00:09:49,440 --> 00:09:51,080
One of those applies wins and
375
00:09:51,080 --> 00:09:52,399
the other person's work vanishes
376
00:09:52,399 --> 00:09:53,639
without a warning on anyone's
377
00:09:53,639 --> 00:09:54,320
screen.
378
00:09:54,320 --> 00:09:55,519
It isn't carelessness.
379
00:09:55,519 --> 00:09:56,399
It's what happens when the
380
00:09:56,399 --> 00:09:57,620
team's shared record lives on
381
00:09:57,620 --> 00:09:58,559
two machines.
382
00:09:58,559 --> 00:09:59,840
Remote state is the fix.
383
00:09:59,840 --> 00:10:00,799
Instead of keeping the state
384
00:10:00,799 --> 00:10:02,399
file on a laptop, you keep it in
385
00:10:02,399 --> 00:10:04,120
a shared place, such as an Azure
386
00:10:04,120 --> 00:10:05,679
storage account or an AWS
387
00:10:05,679 --> 00:10:06,120
bucket.
388
00:10:06,120 --> 00:10:08,519
Every engineer then reads and
writes the same copy.
389
00:10:08,519 --> 00:10:10,200
That one move buys three
separate things.
390
00:10:10,200 --> 00:10:11,700
Two runs can't collide because
391
00:10:11,700 --> 00:10:12,919
Terraform locks the state while
392
00:10:12,919 --> 00:10:13,480
it's working.
393
00:10:13,480 --> 00:10:14,919
Encryption keeps those passwords
394
00:10:14,919 --> 00:10:16,200
and connection strings out of
395
00:10:16,200 --> 00:10:16,840
the open.
396
00:10:16,840 --> 00:10:19,679
Access can be restricted, so the
state is only visible to the
397
00:10:19,679 --> 00:10:21,360
people who should see it.
398
00:10:21,360 --> 00:10:24,120
Teams that have done this for a
while add a few habits on top.
399
00:10:24,120 --> 00:10:25,620
They keep one state file per
400
00:10:25,620 --> 00:10:27,080
environment and per component,
401
00:10:27,080 --> 00:10:28,639
instead of one enormous file
402
00:10:28,639 --> 00:10:30,240
that touches everything at once,
403
00:10:30,240 --> 00:10:31,879
versioning gets switched on so a
404
00:10:31,879 --> 00:10:33,320
bad day can be undone and the
405
00:10:33,320 --> 00:10:34,240
state store gets its own
406
00:10:34,240 --> 00:10:34,759
credentials.
407
00:10:34,759 --> 00:10:36,279
Rather than reusing the admin
408
00:10:36,279 --> 00:10:37,720
account somebody created in a
409
00:10:37,720 --> 00:10:38,159
hurry.
410
00:10:38,159 --> 00:10:40,840
If you'd rather not run any of
that yourself, there are managed
411
00:10:40,840 --> 00:10:43,519
services that store the state
and execute the runs for you,
412
00:10:43,519 --> 00:10:45,120
and HashiCorp sells one of them.
413
00:10:45,120 --> 00:10:46,279
It's a reasonable option for a
414
00:10:46,279 --> 00:10:47,875
small team with no platform
415
00:10:47,875 --> 00:10:48,590
engineer.
416
00:10:48,590 --> 00:10:51,429
The concepts are the same either
way, and it's worth learning on
417
00:10:51,429 --> 00:10:53,909
the command line first, so you
can tell what the service is
418
00:10:53,909 --> 00:10:55,470
doing on your behalf.
419
00:10:55,470 --> 00:10:56,549
What matters at this stage is
420
00:10:56,549 --> 00:10:58,110
that this record sits somewhere
421
00:10:58,110 --> 00:10:59,309
the whole team can reach, and
422
00:10:59,309 --> 00:11:00,230
only the right people can
423
00:11:00,230 --> 00:11:00,509
change.
424
00:11:00,509 --> 00:11:01,470
That's the difference between
425
00:11:01,470 --> 00:11:03,230
infrastructure, your team trusts
426
00:11:03,230 --> 00:11:04,070
and infrastructure.
427
00:11:04,070 --> 00:11:08,350
Your team guesses at drift when
reality quietly changes.
428
00:11:08,350 --> 00:11:09,789
Even a careful team has one
429
00:11:09,789 --> 00:11:11,470
enemy left and it doesn't come
430
00:11:11,470 --> 00:11:12,070
from inside.
431
00:11:12,070 --> 00:11:14,190
The tool drift is any change to
infrastructure.
432
00:11:14,190 --> 00:11:17,389
Terraform manages that Terraform
didn't make, and it happens more
433
00:11:17,389 --> 00:11:18,549
often than anyone admits.
434
00:11:18,549 --> 00:11:20,110
The classic version goes like
this.
435
00:11:20,110 --> 00:11:23,549
An engineer gets paged during an
incident, logs into the console,
436
00:11:23,549 --> 00:11:26,509
raises an auto scaling limit
from five to ten, fixes the
437
00:11:26,509 --> 00:11:27,710
problem, and moves on.
438
00:11:27,710 --> 00:11:28,870
The code still says five.
439
00:11:28,870 --> 00:11:29,909
The cloud says ten.
440
00:11:29,909 --> 00:11:31,110
Nobody notices for weeks, and
441
00:11:31,110 --> 00:11:32,429
then someone runs a plan for an
442
00:11:32,429 --> 00:11:33,350
unrelated reason.
443
00:11:33,350 --> 00:11:35,269
There it is in the output ten,
going back to five.
444
00:11:35,269 --> 00:11:36,470
Because Terraform has just read
445
00:11:36,470 --> 00:11:37,350
the real world and found a
446
00:11:37,350 --> 00:11:37,750
difference.
447
00:11:37,750 --> 00:11:39,889
That's the moment people learn
to respect drift, because
448
00:11:39,889 --> 00:11:43,470
Terraform is about to undo a fix
that someone made deliberately.
449
00:11:43,470 --> 00:11:46,509
Catching drift is mostly a
matter of looking on purpose.
450
00:11:46,509 --> 00:11:47,720
A normal plan refreshes what
451
00:11:47,720 --> 00:11:48,980
Terraform knows about your real
452
00:11:48,980 --> 00:11:50,500
resources and shows you whatever
453
00:11:50,500 --> 00:11:51,220
doesn't match.
454
00:11:51,220 --> 00:11:54,240
There's also a refresh only
version of that command, which
455
00:11:54,240 --> 00:11:56,740
updates the record without
proposing any infrastructure
456
00:11:56,740 --> 00:11:57,740
changes at all.
457
00:11:57,740 --> 00:11:59,980
Then you have a choice, and both
answers are legitimate.
458
00:11:59,980 --> 00:12:02,539
You can update the file to match
what's running now, which is the
459
00:12:02,539 --> 00:12:04,700
right call when the manual
change was a good one.
460
00:12:04,700 --> 00:12:06,100
Or you can apply the plan and
461
00:12:06,100 --> 00:12:07,379
roll reality back to what the
462
00:12:07,379 --> 00:12:07,899
file says.
463
00:12:07,899 --> 00:12:08,820
And that's the right move.
464
00:12:08,820 --> 00:12:11,700
When someone was experimenting
and forgot to clean up some
465
00:12:11,700 --> 00:12:14,500
drift is deliberate and some is
a mistake, and no tool can
466
00:12:14,500 --> 00:12:17,740
reliably tell the two apart that
judgment belongs to the team.
467
00:12:17,740 --> 00:12:20,539
You might expect the obvious
answer here to be automation,
468
00:12:20,539 --> 00:12:22,899
where every difference gets
reversed the moment it appears.
469
00:12:22,899 --> 00:12:24,179
People who have run this at
470
00:12:24,179 --> 00:12:25,860
scale advise against that,
471
00:12:25,860 --> 00:12:27,139
because a tool that reverts
472
00:12:27,139 --> 00:12:28,340
every change will eventually
473
00:12:28,340 --> 00:12:30,259
revert something that mattered
474
00:12:30,259 --> 00:12:31,980
when Terraform is the right
475
00:12:31,980 --> 00:12:32,620
choice.
476
00:12:32,620 --> 00:12:35,500
So this earns its keep in a few
specific situations.
477
00:12:35,500 --> 00:12:36,940
The strongest case is when you
478
00:12:36,940 --> 00:12:38,120
have more than one place to
479
00:12:38,120 --> 00:12:38,740
manage.
480
00:12:38,740 --> 00:12:39,980
If your infrastructure lives in
481
00:12:39,980 --> 00:12:41,500
Azure, your code sits in GitHub
482
00:12:41,500 --> 00:12:42,539
and your monitoring live
483
00:12:42,539 --> 00:12:43,259
somewhere else.
484
00:12:43,259 --> 00:12:44,700
Terraform gives you one language
485
00:12:44,700 --> 00:12:46,220
and one workflow across all of
486
00:12:46,220 --> 00:12:47,179
it.
487
00:12:47,179 --> 00:12:49,860
The second case is rebuilding,
because a written configuration
488
00:12:49,860 --> 00:12:52,299
turns a stressful afternoon into
a single command.
489
00:12:52,299 --> 00:12:53,299
The third case is review.
490
00:12:53,299 --> 00:12:54,539
Because a file can be proposed,
491
00:12:54,539 --> 00:12:55,860
discussed, and approved before
492
00:12:55,860 --> 00:12:57,179
anything happens, and that
493
00:12:57,179 --> 00:12:58,340
conversation is stored for
494
00:12:58,340 --> 00:12:58,899
later.
495
00:12:58,899 --> 00:12:59,980
If you have lived through an
496
00:12:59,980 --> 00:13:01,539
outage caused by an undocumented
497
00:13:01,539 --> 00:13:02,980
change, this tends to matter
498
00:13:02,980 --> 00:13:04,179
more than it does to everyone
499
00:13:04,179 --> 00:13:04,700
else.
500
00:13:04,700 --> 00:13:06,860
There are also honest reasons to
walk away from it.
501
00:13:06,860 --> 00:13:09,700
If everything you run lives
inside a single cloud.
502
00:13:09,700 --> 00:13:12,139
A tool built for that cloud is
often the simpler answer.
503
00:13:12,139 --> 00:13:13,820
Microsoft's own bicep for Azure
504
00:13:13,820 --> 00:13:15,139
and Amazon's cloud formation
505
00:13:15,139 --> 00:13:16,379
exist for exactly that
506
00:13:16,379 --> 00:13:17,220
situation.
507
00:13:17,220 --> 00:13:18,659
They're narrower and tied to one
508
00:13:18,659 --> 00:13:19,980
platform, and for a single
509
00:13:19,980 --> 00:13:20,980
platform team, that is a
510
00:13:20,980 --> 00:13:21,620
feature.
511
00:13:21,620 --> 00:13:23,820
Between those two extremes,
there's a middle ground.
512
00:13:23,820 --> 00:13:26,179
Pulumi lets you describe
infrastructure in ordinary
513
00:13:26,179 --> 00:13:28,980
programming languages instead of
Terraform's own, which suits
514
00:13:28,980 --> 00:13:31,220
teams that already live in
TypeScript or Python.
515
00:13:31,220 --> 00:13:34,259
Ansible, which many Microsoft
Teams already use, configures
516
00:13:34,259 --> 00:13:35,860
software on machines that exist.
517
00:13:35,860 --> 00:13:38,179
It can create infrastructure
too, which is why running it
518
00:13:38,179 --> 00:13:40,700
alongside Terraform without
clear boundaries is a known way
519
00:13:40,700 --> 00:13:41,539
to create drift.
520
00:13:41,539 --> 00:13:42,860
One practical note, because it
521
00:13:42,860 --> 00:13:44,034
comes up in every team's first
522
00:13:44,034 --> 00:13:44,970
conversation.
523
00:13:44,970 --> 00:13:46,570
Terraform's command line tool is
524
00:13:46,570 --> 00:13:47,610
free to use on your own
525
00:13:47,610 --> 00:13:48,490
infrastructure.
526
00:13:48,490 --> 00:13:51,210
You'll also hear the name Open
Tofu, an open source version
527
00:13:51,210 --> 00:13:53,289
built by the community that
speaks the same language.
528
00:13:53,289 --> 00:13:55,529
The file you learn to write
works with both, so this isn't a
529
00:13:55,529 --> 00:13:56,649
decision you have to make today.
530
00:13:56,649 --> 00:13:58,529
Strip all of it back and
Terraform is a trade.
531
00:13:58,529 --> 00:14:01,370
You spend time writing down what
you want in a language you have
532
00:14:01,370 --> 00:14:04,090
to learn, and in exchange, you
stop depending on anyone's
533
00:14:04,090 --> 00:14:05,490
memory of a portal.
534
00:14:05,490 --> 00:14:07,210
Whether that's worth it depends
535
00:14:07,210 --> 00:14:08,529
on how much infrastructure you
536
00:14:08,529 --> 00:14:10,250
have and how many people touch
537
00:14:10,250 --> 00:14:11,649
it.
538
00:14:11,649 --> 00:14:14,009
A quick recap and one question
for you.
539
00:14:14,009 --> 00:14:15,529
So the whole thing comes down to
this.
540
00:14:15,529 --> 00:14:18,090
Infrastructure as code means the
environment you want lives in a
541
00:14:18,090 --> 00:14:19,970
file, not in somebody's memory
of a portal.
542
00:14:19,970 --> 00:14:22,850
Providers are how Terraform
reaches each platform plan shows
543
00:14:22,850 --> 00:14:24,970
you what will change before it
changes and apply.
544
00:14:24,970 --> 00:14:25,809
Makes it real.
545
00:14:25,809 --> 00:14:28,490
The state file is terraform's
memory of what it built, and
546
00:14:28,490 --> 00:14:30,889
modules stop you rebuilding the
same thing twice.
547
00:14:30,889 --> 00:14:32,250
Remote state keeps a team from
548
00:14:32,250 --> 00:14:33,970
overwriting each other and drift
549
00:14:33,970 --> 00:14:34,610
is reality.
550
00:14:34,610 --> 00:14:36,409
Quietly disagreeing with your
file?
551
00:14:36,409 --> 00:14:38,649
There's one question worth
taking with you.
552
00:14:38,649 --> 00:14:41,409
Which part of your own setup
would you most want written down
553
00:14:41,409 --> 00:14:42,090
in a file?
554
00:14:42,090 --> 00:14:44,610
And what's actually stopped you
from doing it?
00:00:00,040 --> 00:00:01,320
Terraform exists because your
2
00:00:01,320 --> 00:00:02,520
Azure Portal clicks can't be
3
00:00:02,520 --> 00:00:03,439
rebuilt twice.
4
00:00:03,439 --> 00:00:05,280
It writes that infrastructure
down as a file.
5
00:00:05,280 --> 00:00:07,120
You can read, review, and run
again.
6
00:00:07,120 --> 00:00:09,599
Small plugins called providers,
many of them written by the
7
00:00:09,599 --> 00:00:13,119
platform teams themselves let
Terraform reach Azure, AWS, and
8
00:00:13,119 --> 00:00:14,560
thousands of other services.
9
00:00:14,560 --> 00:00:18,800
Welcome to the M365 FM podcast
where we explore the people,
10
00:00:18,800 --> 00:00:21,640
ideas, and technologies shaping
the future of work.
11
00:00:21,640 --> 00:00:24,120
Cloud teams keep coming back to
it because writing
12
00:00:24,120 --> 00:00:26,120
infrastructure down means nobody
has to remember it.
13
00:00:26,120 --> 00:00:27,600
So it's worth understanding even
14
00:00:27,600 --> 00:00:28,839
if you never write a line of it
15
00:00:28,839 --> 00:00:29,679
yourself.
16
00:00:29,679 --> 00:00:30,719
By the end, you'll be able to
17
00:00:30,719 --> 00:00:32,000
read a Terraform setup and say
18
00:00:32,000 --> 00:00:33,439
what it will do before it does
19
00:00:33,439 --> 00:00:34,399
anything.
20
00:00:34,399 --> 00:00:36,560
What infrastructure as code
really means?
21
00:00:36,560 --> 00:00:37,520
Think about the last time you
22
00:00:37,520 --> 00:00:38,520
built something in the Azure
23
00:00:38,520 --> 00:00:40,000
portal, a resource group, or a
24
00:00:40,000 --> 00:00:41,439
storage account, or a small
25
00:00:41,439 --> 00:00:42,640
virtual machine you needed for
26
00:00:42,640 --> 00:00:43,280
testing.
27
00:00:43,280 --> 00:00:45,119
It took ten minutes and
everything worked.
28
00:00:45,119 --> 00:00:46,299
Now imagine someone asked you to
29
00:00:46,299 --> 00:00:48,119
build that same setup again next
30
00:00:48,119 --> 00:00:48,320
month.
31
00:00:48,320 --> 00:00:51,439
For a different team, you have
to do it from memory naming
32
00:00:51,439 --> 00:00:54,119
every setting you picked in the
order you picked it.
33
00:00:54,119 --> 00:00:56,640
Almost nobody can get through
that without missing something.
34
00:00:56,640 --> 00:00:58,520
And that gap is the entire
reason.
35
00:00:58,520 --> 00:01:00,070
Infrastructure as code exists.
36
00:01:00,070 --> 00:01:02,570
Infrastructure as code means you
write down what you want to
37
00:01:02,570 --> 00:01:05,549
exist in a file instead of
clicking it into existence.
38
00:01:05,549 --> 00:01:07,230
The file is plain text, and it
39
00:01:07,230 --> 00:01:08,510
names the things you need, the
40
00:01:08,510 --> 00:01:09,430
way you'd write a list for
41
00:01:09,430 --> 00:01:10,269
someone else.
42
00:01:10,269 --> 00:01:13,030
It sits in the same place as
your other work, which changes
43
00:01:13,030 --> 00:01:14,269
how a team behaves.
44
00:01:14,269 --> 00:01:15,390
A change to the file can be
45
00:01:15,390 --> 00:01:16,709
reviewed before it happens and
46
00:01:16,709 --> 00:01:17,909
traced afterwards.
47
00:01:17,909 --> 00:01:20,750
It also means you can copy the
file, so a setup that works in
48
00:01:20,750 --> 00:01:22,829
one place can be reused
somewhere else without anyone
49
00:01:22,829 --> 00:01:24,310
rebuilding it from memory.
50
00:01:24,310 --> 00:01:26,790
People describe infrastructure
in a file in two different ways,
51
00:01:26,790 --> 00:01:28,590
and the difference matters more
than it sounds.
52
00:01:28,590 --> 00:01:29,989
One way is imperative, where you
53
00:01:29,989 --> 00:01:31,189
spell out every step in order,
54
00:01:31,189 --> 00:01:32,750
creating one thing and then the
55
00:01:32,750 --> 00:01:34,189
next, and then connecting the
56
00:01:34,189 --> 00:01:35,109
two together.
57
00:01:35,109 --> 00:01:37,629
The other way is declarative,
where you describe the result
58
00:01:37,629 --> 00:01:39,909
you want and let the tool work
out the steps.
59
00:01:39,909 --> 00:01:41,189
Terraform belongs to the second
60
00:01:41,189 --> 00:01:42,469
group, which is why you almost
61
00:01:42,469 --> 00:01:43,670
never see it written as a list
62
00:01:43,670 --> 00:01:44,390
of instructions.
63
00:01:44,390 --> 00:01:46,829
So the habit shift is simple
enough to say out loud.
64
00:01:46,829 --> 00:01:49,310
You stop remembering what you
clicked and you start writing
65
00:01:49,310 --> 00:01:50,469
down what you want.
66
00:01:50,469 --> 00:01:51,629
Everything else in this episode
67
00:01:51,629 --> 00:01:53,030
is a detail hanging off that one
68
00:01:53,030 --> 00:01:53,629
change.
69
00:01:53,629 --> 00:01:55,989
The first time a plan comes back
with nothing to change.
70
00:01:55,989 --> 00:01:58,150
You'll see why teams get
attached to it.
71
00:01:58,150 --> 00:02:00,099
What Terraform actually is.
72
00:02:00,099 --> 00:02:01,500
Terraform is an infrastructure
73
00:02:01,500 --> 00:02:02,819
as code tool that lets you
74
00:02:02,819 --> 00:02:04,420
build, change, and version your
75
00:02:04,420 --> 00:02:06,019
cloud resources safely and
76
00:02:06,019 --> 00:02:06,579
efficiently.
77
00:02:06,579 --> 00:02:07,579
That's how HashiCorp, the
78
00:02:07,579 --> 00:02:09,139
company that built it, describes
79
00:02:09,139 --> 00:02:09,939
the product.
80
00:02:09,939 --> 00:02:11,500
Those three verbs build, change,
81
00:02:11,500 --> 00:02:12,780
and version cover nearly
82
00:02:12,780 --> 00:02:14,060
everything you'll ever do with
83
00:02:14,060 --> 00:02:14,620
it.
84
00:02:14,620 --> 00:02:15,659
It also works with older
85
00:02:15,659 --> 00:02:16,939
infrastructure that runs in your
86
00:02:16,939 --> 00:02:18,300
own data center, which is what
87
00:02:18,300 --> 00:02:19,460
people mean when they say on
88
00:02:19,460 --> 00:02:20,020
premises.
89
00:02:20,020 --> 00:02:22,740
HashiCorp released Terraform in
twenty fourteen, and the tool
90
00:02:22,740 --> 00:02:25,020
has had more than a decade to
grow up in public.
91
00:02:25,020 --> 00:02:27,280
It grew alongside cloud
platforms and had years to
92
00:02:27,280 --> 00:02:28,740
smooth down the rough edges.
93
00:02:28,740 --> 00:02:30,139
It now handles small things like
94
00:02:30,139 --> 00:02:31,580
a single storage account and
95
00:02:31,580 --> 00:02:32,819
large things like an entire
96
00:02:32,819 --> 00:02:34,780
network with routing firewalls
97
00:02:34,780 --> 00:02:36,099
and a load balancer in front of
98
00:02:36,099 --> 00:02:36,580
it.
99
00:02:36,580 --> 00:02:38,180
It also had time to settle into
100
00:02:38,180 --> 00:02:39,460
a shape a beginner can pick up
101
00:02:39,460 --> 00:02:40,939
in an afternoon, which is not
102
00:02:40,939 --> 00:02:42,340
something every cloud tool can
103
00:02:42,340 --> 00:02:42,979
claim.
104
00:02:42,979 --> 00:02:46,020
The workflow underneath all of
that has three stages, and
105
00:02:46,020 --> 00:02:48,259
they're worth holding on to
because every other idea in this
106
00:02:48,259 --> 00:02:49,699
episode hangs off them.
107
00:02:49,699 --> 00:02:51,699
First, you write the
configuration, which is a text
108
00:02:51,699 --> 00:02:54,020
file in a language HashiCorp
built for the job.
109
00:02:54,020 --> 00:02:55,300
It reads close to plain English.
110
00:02:55,300 --> 00:02:57,979
Once you know a handful of
words, then Terraform produces a
111
00:02:57,979 --> 00:03:01,659
plan describing what it intends
to create, change, or destroy.
112
00:03:01,659 --> 00:03:04,300
Once you approve that plan, it
goes and does the work in the
113
00:03:04,300 --> 00:03:06,620
right order without you walking
it through the steps.
114
00:03:06,620 --> 00:03:09,139
That order matters more than
beginners expect.
115
00:03:09,139 --> 00:03:11,740
Terraform builds what's called a
dependency graph.
116
00:03:11,740 --> 00:03:13,240
It knows that a network has to
117
00:03:13,240 --> 00:03:14,580
exist before anything can be
118
00:03:14,580 --> 00:03:16,139
attached to it, and it works
119
00:03:16,139 --> 00:03:17,340
through everything that doesn't
120
00:03:17,340 --> 00:03:18,819
depend on anything else at the
121
00:03:18,819 --> 00:03:19,500
same time.
122
00:03:19,500 --> 00:03:21,219
You never write that sequence
yourself.
123
00:03:21,219 --> 00:03:22,659
You describe the destination and
124
00:03:22,659 --> 00:03:24,240
Terraform finds a route
125
00:03:24,240 --> 00:03:26,379
providers how Terraform talks to
126
00:03:26,379 --> 00:03:27,060
your cloud.
127
00:03:27,060 --> 00:03:29,419
The next word to learn is
provider, and it's the one that
128
00:03:29,419 --> 00:03:30,979
unlocks the rest of Terraform.
129
00:03:30,979 --> 00:03:33,340
A provider is a plugin that
teaches Terraform how to speak
130
00:03:33,340 --> 00:03:34,539
to a single platform.
131
00:03:34,539 --> 00:03:35,860
It uses the interface that
132
00:03:35,860 --> 00:03:37,300
platform publishes for software,
133
00:03:37,300 --> 00:03:38,699
which the cloud world calls an
134
00:03:38,699 --> 00:03:39,539
API.
135
00:03:39,539 --> 00:03:41,819
Add the Azure provider and
Terraform can create Azure
136
00:03:41,819 --> 00:03:45,419
resources, add the AWS provider,
and it can create AWS resources.
137
00:03:45,419 --> 00:03:48,740
With both in place, it can build
across the two in a single run.
138
00:03:48,740 --> 00:03:51,060
There's a provider for almost
everything you've heard of from
139
00:03:51,060 --> 00:03:53,860
the three big clouds to
Kubernetes, GitHub, Datadog, and
140
00:03:53,860 --> 00:03:57,009
a long tail of smaller services
HashiCorp and the community have
141
00:03:57,009 --> 00:03:59,569
written thousands of them, and
they're all listed publicly in
142
00:03:59,569 --> 00:04:00,849
the Terraform registry.
143
00:04:00,849 --> 00:04:02,210
The reason providers exist as a
144
00:04:02,210 --> 00:04:03,169
separate thing is worth a
145
00:04:03,169 --> 00:04:03,849
moment.
146
00:04:03,849 --> 00:04:05,330
Terraform itself stays fairly
147
00:04:05,330 --> 00:04:06,349
small and only knows how to
148
00:04:06,349 --> 00:04:07,530
compare what you want with what
149
00:04:07,530 --> 00:04:08,009
exists.
150
00:04:08,009 --> 00:04:09,490
Each platform contributes its
151
00:04:09,490 --> 00:04:11,090
own translation layer, written
152
00:04:11,090 --> 00:04:12,129
by the people who know that
153
00:04:12,129 --> 00:04:12,969
platform best.
154
00:04:12,969 --> 00:04:15,129
A resource is the second piece
of vocabulary.
155
00:04:15,129 --> 00:04:17,769
A resource is one thing you want
to exist, such as a storage
156
00:04:17,769 --> 00:04:19,370
account or a virtual network.
157
00:04:19,370 --> 00:04:20,649
You describe it by naming the
158
00:04:20,649 --> 00:04:22,009
kind of thing it is, then
159
00:04:22,009 --> 00:04:23,170
listing the settings you care
160
00:04:23,170 --> 00:04:23,649
about.
161
00:04:23,649 --> 00:04:25,370
Everything else gets a sensible
default.
162
00:04:25,370 --> 00:04:26,449
That's the entire shape of a
163
00:04:26,449 --> 00:04:27,850
Terraform file, repeated as many
164
00:04:27,850 --> 00:04:28,870
times as you have things to
165
00:04:28,870 --> 00:04:29,449
build.
166
00:04:29,449 --> 00:04:32,129
This is also where the fear
about being locked into one
167
00:04:32,129 --> 00:04:33,449
cloud falls apart.
168
00:04:33,449 --> 00:04:36,250
Because providers are separate
from Terraform, the same tool
169
00:04:36,250 --> 00:04:38,970
reaches several platforms, and
one configuration can manage an
170
00:04:38,970 --> 00:04:41,930
Azure environment and a GitHub
repository at the same time.
171
00:04:41,930 --> 00:04:44,170
You're not choosing a vendor
when you choose Terraform,
172
00:04:44,170 --> 00:04:46,250
you're choosing a way of
describing what you want.
173
00:04:46,250 --> 00:04:48,490
The part people get wrong first
is not the provider, though.
174
00:04:48,490 --> 00:04:51,089
It's the file Terraform keeps
about everything it has already
175
00:04:51,089 --> 00:04:53,930
built, and that file has caused
more damage to more teams than
176
00:04:53,930 --> 00:04:55,240
any other piece of this tool.
177
00:04:55,240 --> 00:04:58,560
We'll get to it and I'll tell
you exactly where it bites.
178
00:04:58,560 --> 00:05:00,740
Plan and apply the safety net
179
00:05:00,740 --> 00:05:01,959
you meet for commands when you
180
00:05:01,959 --> 00:05:03,120
start with Terraform, and they
181
00:05:03,120 --> 00:05:04,920
arrive in a fixed order and it
182
00:05:04,920 --> 00:05:06,279
prepares your working folder and
183
00:05:06,279 --> 00:05:07,480
downloads the providers you
184
00:05:07,480 --> 00:05:08,079
asked for.
185
00:05:08,079 --> 00:05:09,319
Plan works out what would change
186
00:05:09,319 --> 00:05:10,560
and apply makes those changes
187
00:05:10,560 --> 00:05:11,040
real.
188
00:05:11,040 --> 00:05:12,240
Destroy takes everything down
189
00:05:12,240 --> 00:05:13,459
again, which is the command you
190
00:05:13,459 --> 00:05:14,800
keep in your pocket and treat
191
00:05:14,800 --> 00:05:15,720
with respect.
192
00:05:15,720 --> 00:05:17,279
Plan is the one that earns
Terraform.
193
00:05:17,279 --> 00:05:17,839
It's trust.
194
00:05:17,839 --> 00:05:21,160
Terraform compares three things
what you wrote, what it recorded
195
00:05:21,160 --> 00:05:23,920
last time, and what exists in
your cloud right now.
196
00:05:23,920 --> 00:05:25,160
Then it shows you a list of what
197
00:05:25,160 --> 00:05:26,920
it intends to add, change, or
198
00:05:26,920 --> 00:05:28,079
delete before it touches
199
00:05:28,079 --> 00:05:28,839
anything.
200
00:05:28,839 --> 00:05:31,680
You get to read that list, argue
about it with a colleague, and
201
00:05:31,680 --> 00:05:32,680
change your mind.
202
00:05:32,680 --> 00:05:33,639
Apply as the short step.
203
00:05:33,639 --> 00:05:36,519
At the end, you confirm the plan
and Terraform executes it
204
00:05:36,519 --> 00:05:39,000
respecting the dependencies it
worked out earlier.
205
00:05:39,000 --> 00:05:41,379
If your configuration asks for a
virtual network and three
206
00:05:41,379 --> 00:05:44,240
machines inside, Terraform will
make sure the network exists.
207
00:05:44,240 --> 00:05:45,360
First, nothing has to be
208
00:05:45,360 --> 00:05:46,839
sequenced by hand, and once you
209
00:05:46,839 --> 00:05:48,079
approve the plan, you can step
210
00:05:48,079 --> 00:05:49,000
back in.
211
00:05:49,000 --> 00:05:50,160
A team plan stops being a
212
00:05:50,160 --> 00:05:51,240
personal habit and becomes a
213
00:05:51,240 --> 00:05:52,120
checkpoint.
214
00:05:52,120 --> 00:05:54,149
The plan gets attached to the
change request.
215
00:05:54,149 --> 00:05:55,189
A colleague reads it and the
216
00:05:55,189 --> 00:05:56,709
apply only happens after someone
217
00:05:56,709 --> 00:05:57,910
else has looked at what's about
218
00:05:57,910 --> 00:05:58,750
to happen.
219
00:05:58,750 --> 00:06:00,629
That feels different from
watching a colleague click
220
00:06:00,629 --> 00:06:02,790
through the portal while you
read the output afterwards.
221
00:06:02,790 --> 00:06:04,189
Destroy deserves its own mention
222
00:06:04,189 --> 00:06:05,310
because it does exactly what it
223
00:06:05,310 --> 00:06:06,050
says, and it does it to
224
00:06:06,050 --> 00:06:07,430
everything in that state file at
225
00:06:07,430 --> 00:06:07,750
once.
226
00:06:07,750 --> 00:06:09,790
There's an honest caveat worth
saying out loud.
227
00:06:09,790 --> 00:06:10,990
Plan output can be a wall of
228
00:06:10,990 --> 00:06:12,550
text on your first attempt, and
229
00:06:12,550 --> 00:06:13,470
some entries are hard to
230
00:06:13,470 --> 00:06:13,990
predict.
231
00:06:13,990 --> 00:06:15,189
That's especially true when
232
00:06:15,189 --> 00:06:16,550
Terraform warns that a change
233
00:06:16,550 --> 00:06:17,629
will force a resource to be
234
00:06:17,629 --> 00:06:18,350
replaced.
235
00:06:18,350 --> 00:06:19,589
That warning is not an error.
236
00:06:19,589 --> 00:06:22,230
It's Terraform telling you it
plans to delete the old thing
237
00:06:22,230 --> 00:06:23,029
and build a new one.
238
00:06:23,029 --> 00:06:25,589
Read those lines slowly, because
that's where surprises live.
239
00:06:25,589 --> 00:06:28,670
So plan is the safety net, and
the reason it can work at all is
240
00:06:28,670 --> 00:06:31,470
that Terraform has something to
compare your file against.
241
00:06:31,470 --> 00:06:32,790
That something is the state
242
00:06:32,790 --> 00:06:34,149
file, the one I mentioned, and
243
00:06:34,149 --> 00:06:35,389
it gets its own section in a
244
00:06:35,389 --> 00:06:36,069
moment.
245
00:06:36,069 --> 00:06:38,110
The state file Terraform's
memory.
246
00:06:38,110 --> 00:06:40,189
The scary file is called the
state file, and it is
247
00:06:40,189 --> 00:06:42,550
terraform's memory of the
infrastructure it built.
248
00:06:42,550 --> 00:06:43,910
HashiCorp describes it as the
249
00:06:43,910 --> 00:06:44,910
source of truth for your
250
00:06:44,910 --> 00:06:45,509
environment.
251
00:06:45,509 --> 00:06:47,269
In plain terms, Terraform uses
252
00:06:47,269 --> 00:06:48,670
this record to decide what has
253
00:06:48,670 --> 00:06:49,269
to change.
254
00:06:49,269 --> 00:06:51,230
So reality matches what you
wrote.
255
00:06:51,230 --> 00:06:52,430
Without it, Terraform would have
256
00:06:52,430 --> 00:06:53,779
no idea which of the resources
257
00:06:53,779 --> 00:06:55,300
in your subscription it created
258
00:06:55,300 --> 00:06:56,220
and which ones were there
259
00:06:56,220 --> 00:06:56,980
before.
260
00:06:56,980 --> 00:06:59,379
Inside the state file, you'll
find real details about real
261
00:06:59,379 --> 00:07:01,779
things, including the
identifiers your cloud assigns
262
00:07:01,779 --> 00:07:04,459
to each resource and the values
you gave it.
263
00:07:04,459 --> 00:07:05,620
Some of those values are
264
00:07:05,620 --> 00:07:06,980
passwords, connection strings,
265
00:07:06,980 --> 00:07:08,639
and private addresses, and they
266
00:07:08,639 --> 00:07:10,060
sit in that file as readable
267
00:07:10,060 --> 00:07:10,699
text.
268
00:07:10,699 --> 00:07:12,019
That one detail explains most of
269
00:07:12,019 --> 00:07:13,180
the rules people repeat about
270
00:07:13,180 --> 00:07:13,620
state.
271
00:07:13,620 --> 00:07:15,019
Never commit it to your team's
272
00:07:15,019 --> 00:07:16,779
code repository and never open
273
00:07:16,779 --> 00:07:18,220
it and start editing entries by
274
00:07:18,220 --> 00:07:18,660
hand.
275
00:07:18,660 --> 00:07:21,220
Instead, you use the commands
built for the job.
276
00:07:21,220 --> 00:07:24,339
Moving a resource or renaming it
in state is a command, and
277
00:07:24,339 --> 00:07:26,540
removing something from state
without deleting it from your
278
00:07:26,540 --> 00:07:27,379
cloud is another.
279
00:07:27,379 --> 00:07:28,459
They exist precisely so you
280
00:07:28,459 --> 00:07:29,459
never have to touch the file
281
00:07:29,459 --> 00:07:30,060
itself.
282
00:07:30,060 --> 00:07:31,420
It sounds fussy until the first
283
00:07:31,420 --> 00:07:32,500
time you rename something in
284
00:07:32,500 --> 00:07:34,100
your configuration and need the
285
00:07:34,100 --> 00:07:35,339
record to follow along without
286
00:07:35,339 --> 00:07:36,420
rebuilding the resource from
287
00:07:36,420 --> 00:07:37,220
scratch.
288
00:07:37,220 --> 00:07:38,459
If the state file is lost or
289
00:07:38,459 --> 00:07:40,019
damaged, the recovery is not
290
00:07:40,019 --> 00:07:40,540
quick.
291
00:07:40,540 --> 00:07:41,660
You can restore an older copy
292
00:07:41,660 --> 00:07:42,699
from a backup if you set your
293
00:07:42,699 --> 00:07:44,019
storage up to keep versions,
294
00:07:44,019 --> 00:07:45,259
which is a small decision with a
295
00:07:45,259 --> 00:07:46,860
large payoff without one, you
296
00:07:46,860 --> 00:07:48,379
rebuild the record by importing
297
00:07:48,379 --> 00:07:49,819
each existing resource one at a
298
00:07:49,819 --> 00:07:51,660
time, and that gets slow very
299
00:07:51,660 --> 00:07:52,060
fast.
300
00:07:52,060 --> 00:07:53,259
On a large environment.
301
00:07:53,259 --> 00:07:54,420
It's the kind of afternoon
302
00:07:54,420 --> 00:07:55,699
nobody plans for and everybody
303
00:07:55,699 --> 00:07:56,540
remembers.
304
00:07:56,540 --> 00:07:58,980
Handled properly, though, this
file is what makes Terraform
305
00:07:58,980 --> 00:08:02,139
feel fast on your first run, it
records the things it created on
306
00:08:02,139 --> 00:08:02,779
your second run.
307
00:08:02,779 --> 00:08:05,139
It looks at those resources,
notices that most of them
308
00:08:05,139 --> 00:08:07,620
already match what you want and
leaves them alone.
309
00:08:07,620 --> 00:08:11,019
Nothing is created twice,
nothing is deleted by accident,
310
00:08:11,019 --> 00:08:13,620
and the only work left is
whatever you changed.
311
00:08:13,620 --> 00:08:15,699
That's the payoff of keeping the
record honest.
312
00:08:15,699 --> 00:08:18,560
And it's why the boring advice
about backups and access control
313
00:08:18,560 --> 00:08:20,139
turns out to matter so much.
314
00:08:20,139 --> 00:08:22,420
Modules stop rebuilding the same
thing.
315
00:08:22,420 --> 00:08:23,420
Once you've written the same
316
00:08:23,420 --> 00:08:24,660
block of configuration a few
317
00:08:24,660 --> 00:08:25,860
times, you'll notice the
318
00:08:25,860 --> 00:08:26,420
pattern.
319
00:08:26,420 --> 00:08:29,500
Every new project needs a
storage account, a network, and
320
00:08:29,500 --> 00:08:32,460
a set of permissions, and the
details differ only slightly
321
00:08:32,460 --> 00:08:33,259
from the last one.
322
00:08:33,259 --> 00:08:34,419
A module is how Terraform
323
00:08:34,419 --> 00:08:35,460
answers that, and it's a
324
00:08:35,460 --> 00:08:36,340
reusable bundle of
325
00:08:36,340 --> 00:08:37,659
infrastructure that you can hand
326
00:08:37,659 --> 00:08:38,700
to a colleague or keep for
327
00:08:38,700 --> 00:08:39,500
yourself.
328
00:08:39,500 --> 00:08:41,820
HashiCorp calls them
configurable collections of
329
00:08:41,820 --> 00:08:44,100
infrastructure, which is
accurate and a little dry.
330
00:08:44,100 --> 00:08:45,460
Think of a module as a recipe
331
00:08:45,460 --> 00:08:46,860
with a few blanks you fill in
332
00:08:46,860 --> 00:08:47,379
each time.
333
00:08:47,379 --> 00:08:48,659
Modules come from two places.
334
00:08:48,659 --> 00:08:50,259
There's a public registry full
335
00:08:50,259 --> 00:08:51,529
of modules that other people
336
00:08:51,529 --> 00:08:52,970
published, covering everything
337
00:08:52,970 --> 00:08:54,289
from a single secure storage
338
00:08:54,289 --> 00:08:56,169
account to complete multi-region
339
00:08:56,169 --> 00:08:57,129
environments.
340
00:08:57,129 --> 00:08:57,970
Then there are the private
341
00:08:57,970 --> 00:08:59,289
modules your own team writes,
342
00:08:59,289 --> 00:09:00,289
which encode how your
343
00:09:00,289 --> 00:09:01,970
organization does things from
344
00:09:01,970 --> 00:09:03,090
naming conventions to the
345
00:09:03,090 --> 00:09:04,210
network rules that must be
346
00:09:04,210 --> 00:09:04,889
applied.
347
00:09:04,889 --> 00:09:06,049
The private ones are usually the
348
00:09:06,049 --> 00:09:07,309
more valuable of the two,
349
00:09:07,309 --> 00:09:08,409
because they carry knowledge
350
00:09:08,409 --> 00:09:09,610
that isn't in any vendor's
351
00:09:09,610 --> 00:09:10,570
documentation.
352
00:09:10,570 --> 00:09:13,210
There's a cost worth naming a
module you didn't write is still
353
00:09:13,210 --> 00:09:15,529
code that runs against your
subscription, and you're the one
354
00:09:15,529 --> 00:09:16,649
who answers for it.
355
00:09:16,649 --> 00:09:17,889
PIN the version you're using so
356
00:09:17,889 --> 00:09:18,970
an update doesn't arrive while
357
00:09:18,970 --> 00:09:20,529
you're asleep, and read what the
358
00:09:20,529 --> 00:09:21,809
module does before you point it
359
00:09:21,809 --> 00:09:22,490
at anything.
360
00:09:22,490 --> 00:09:24,090
That's not caution for its own
sake.
361
00:09:24,090 --> 00:09:26,169
It's the same instinct that
stops you installing software
362
00:09:26,169 --> 00:09:28,210
from a link a stranger sent you
the first time.
363
00:09:28,210 --> 00:09:30,769
You swap a hundred lines of
repeated configuration for a
364
00:09:30,769 --> 00:09:33,409
module you call with three
settings, the point stops
365
00:09:33,409 --> 00:09:35,809
needing any explanation at all.
366
00:09:35,809 --> 00:09:37,889
Remote state working with other
people.
367
00:09:37,889 --> 00:09:40,730
Everything so far works on one
laptop, and that's where it
368
00:09:40,730 --> 00:09:41,889
stops being simple.
369
00:09:41,889 --> 00:09:44,769
Picture two engineers on the
same team, both fixing something
370
00:09:44,769 --> 00:09:46,049
on a Friday afternoon.
371
00:09:46,049 --> 00:09:47,490
The two of them run a plan, see
372
00:09:47,490 --> 00:09:48,904
the same state file and apply a
373
00:09:48,904 --> 00:09:49,440
change.
374
00:09:49,440 --> 00:09:51,080
One of those applies wins and
375
00:09:51,080 --> 00:09:52,399
the other person's work vanishes
376
00:09:52,399 --> 00:09:53,639
without a warning on anyone's
377
00:09:53,639 --> 00:09:54,320
screen.
378
00:09:54,320 --> 00:09:55,519
It isn't carelessness.
379
00:09:55,519 --> 00:09:56,399
It's what happens when the
380
00:09:56,399 --> 00:09:57,620
team's shared record lives on
381
00:09:57,620 --> 00:09:58,559
two machines.
382
00:09:58,559 --> 00:09:59,840
Remote state is the fix.
383
00:09:59,840 --> 00:10:00,799
Instead of keeping the state
384
00:10:00,799 --> 00:10:02,399
file on a laptop, you keep it in
385
00:10:02,399 --> 00:10:04,120
a shared place, such as an Azure
386
00:10:04,120 --> 00:10:05,679
storage account or an AWS
387
00:10:05,679 --> 00:10:06,120
bucket.
388
00:10:06,120 --> 00:10:08,519
Every engineer then reads and
writes the same copy.
389
00:10:08,519 --> 00:10:10,200
That one move buys three
separate things.
390
00:10:10,200 --> 00:10:11,700
Two runs can't collide because
391
00:10:11,700 --> 00:10:12,919
Terraform locks the state while
392
00:10:12,919 --> 00:10:13,480
it's working.
393
00:10:13,480 --> 00:10:14,919
Encryption keeps those passwords
394
00:10:14,919 --> 00:10:16,200
and connection strings out of
395
00:10:16,200 --> 00:10:16,840
the open.
396
00:10:16,840 --> 00:10:19,679
Access can be restricted, so the
state is only visible to the
397
00:10:19,679 --> 00:10:21,360
people who should see it.
398
00:10:21,360 --> 00:10:24,120
Teams that have done this for a
while add a few habits on top.
399
00:10:24,120 --> 00:10:25,620
They keep one state file per
400
00:10:25,620 --> 00:10:27,080
environment and per component,
401
00:10:27,080 --> 00:10:28,639
instead of one enormous file
402
00:10:28,639 --> 00:10:30,240
that touches everything at once,
403
00:10:30,240 --> 00:10:31,879
versioning gets switched on so a
404
00:10:31,879 --> 00:10:33,320
bad day can be undone and the
405
00:10:33,320 --> 00:10:34,240
state store gets its own
406
00:10:34,240 --> 00:10:34,759
credentials.
407
00:10:34,759 --> 00:10:36,279
Rather than reusing the admin
408
00:10:36,279 --> 00:10:37,720
account somebody created in a
409
00:10:37,720 --> 00:10:38,159
hurry.
410
00:10:38,159 --> 00:10:40,840
If you'd rather not run any of
that yourself, there are managed
411
00:10:40,840 --> 00:10:43,519
services that store the state
and execute the runs for you,
412
00:10:43,519 --> 00:10:45,120
and HashiCorp sells one of them.
413
00:10:45,120 --> 00:10:46,279
It's a reasonable option for a
414
00:10:46,279 --> 00:10:47,875
small team with no platform
415
00:10:47,875 --> 00:10:48,590
engineer.
416
00:10:48,590 --> 00:10:51,429
The concepts are the same either
way, and it's worth learning on
417
00:10:51,429 --> 00:10:53,909
the command line first, so you
can tell what the service is
418
00:10:53,909 --> 00:10:55,470
doing on your behalf.
419
00:10:55,470 --> 00:10:56,549
What matters at this stage is
420
00:10:56,549 --> 00:10:58,110
that this record sits somewhere
421
00:10:58,110 --> 00:10:59,309
the whole team can reach, and
422
00:10:59,309 --> 00:11:00,230
only the right people can
423
00:11:00,230 --> 00:11:00,509
change.
424
00:11:00,509 --> 00:11:01,470
That's the difference between
425
00:11:01,470 --> 00:11:03,230
infrastructure, your team trusts
426
00:11:03,230 --> 00:11:04,070
and infrastructure.
427
00:11:04,070 --> 00:11:08,350
Your team guesses at drift when
reality quietly changes.
428
00:11:08,350 --> 00:11:09,789
Even a careful team has one
429
00:11:09,789 --> 00:11:11,470
enemy left and it doesn't come
430
00:11:11,470 --> 00:11:12,070
from inside.
431
00:11:12,070 --> 00:11:14,190
The tool drift is any change to
infrastructure.
432
00:11:14,190 --> 00:11:17,389
Terraform manages that Terraform
didn't make, and it happens more
433
00:11:17,389 --> 00:11:18,549
often than anyone admits.
434
00:11:18,549 --> 00:11:20,110
The classic version goes like
this.
435
00:11:20,110 --> 00:11:23,549
An engineer gets paged during an
incident, logs into the console,
436
00:11:23,549 --> 00:11:26,509
raises an auto scaling limit
from five to ten, fixes the
437
00:11:26,509 --> 00:11:27,710
problem, and moves on.
438
00:11:27,710 --> 00:11:28,870
The code still says five.
439
00:11:28,870 --> 00:11:29,909
The cloud says ten.
440
00:11:29,909 --> 00:11:31,110
Nobody notices for weeks, and
441
00:11:31,110 --> 00:11:32,429
then someone runs a plan for an
442
00:11:32,429 --> 00:11:33,350
unrelated reason.
443
00:11:33,350 --> 00:11:35,269
There it is in the output ten,
going back to five.
444
00:11:35,269 --> 00:11:36,470
Because Terraform has just read
445
00:11:36,470 --> 00:11:37,350
the real world and found a
446
00:11:37,350 --> 00:11:37,750
difference.
447
00:11:37,750 --> 00:11:39,889
That's the moment people learn
to respect drift, because
448
00:11:39,889 --> 00:11:43,470
Terraform is about to undo a fix
that someone made deliberately.
449
00:11:43,470 --> 00:11:46,509
Catching drift is mostly a
matter of looking on purpose.
450
00:11:46,509 --> 00:11:47,720
A normal plan refreshes what
451
00:11:47,720 --> 00:11:48,980
Terraform knows about your real
452
00:11:48,980 --> 00:11:50,500
resources and shows you whatever
453
00:11:50,500 --> 00:11:51,220
doesn't match.
454
00:11:51,220 --> 00:11:54,240
There's also a refresh only
version of that command, which
455
00:11:54,240 --> 00:11:56,740
updates the record without
proposing any infrastructure
456
00:11:56,740 --> 00:11:57,740
changes at all.
457
00:11:57,740 --> 00:11:59,980
Then you have a choice, and both
answers are legitimate.
458
00:11:59,980 --> 00:12:02,539
You can update the file to match
what's running now, which is the
459
00:12:02,539 --> 00:12:04,700
right call when the manual
change was a good one.
460
00:12:04,700 --> 00:12:06,100
Or you can apply the plan and
461
00:12:06,100 --> 00:12:07,379
roll reality back to what the
462
00:12:07,379 --> 00:12:07,899
file says.
463
00:12:07,899 --> 00:12:08,820
And that's the right move.
464
00:12:08,820 --> 00:12:11,700
When someone was experimenting
and forgot to clean up some
465
00:12:11,700 --> 00:12:14,500
drift is deliberate and some is
a mistake, and no tool can
466
00:12:14,500 --> 00:12:17,740
reliably tell the two apart that
judgment belongs to the team.
467
00:12:17,740 --> 00:12:20,539
You might expect the obvious
answer here to be automation,
468
00:12:20,539 --> 00:12:22,899
where every difference gets
reversed the moment it appears.
469
00:12:22,899 --> 00:12:24,179
People who have run this at
470
00:12:24,179 --> 00:12:25,860
scale advise against that,
471
00:12:25,860 --> 00:12:27,139
because a tool that reverts
472
00:12:27,139 --> 00:12:28,340
every change will eventually
473
00:12:28,340 --> 00:12:30,259
revert something that mattered
474
00:12:30,259 --> 00:12:31,980
when Terraform is the right
475
00:12:31,980 --> 00:12:32,620
choice.
476
00:12:32,620 --> 00:12:35,500
So this earns its keep in a few
specific situations.
477
00:12:35,500 --> 00:12:36,940
The strongest case is when you
478
00:12:36,940 --> 00:12:38,120
have more than one place to
479
00:12:38,120 --> 00:12:38,740
manage.
480
00:12:38,740 --> 00:12:39,980
If your infrastructure lives in
481
00:12:39,980 --> 00:12:41,500
Azure, your code sits in GitHub
482
00:12:41,500 --> 00:12:42,539
and your monitoring live
483
00:12:42,539 --> 00:12:43,259
somewhere else.
484
00:12:43,259 --> 00:12:44,700
Terraform gives you one language
485
00:12:44,700 --> 00:12:46,220
and one workflow across all of
486
00:12:46,220 --> 00:12:47,179
it.
487
00:12:47,179 --> 00:12:49,860
The second case is rebuilding,
because a written configuration
488
00:12:49,860 --> 00:12:52,299
turns a stressful afternoon into
a single command.
489
00:12:52,299 --> 00:12:53,299
The third case is review.
490
00:12:53,299 --> 00:12:54,539
Because a file can be proposed,
491
00:12:54,539 --> 00:12:55,860
discussed, and approved before
492
00:12:55,860 --> 00:12:57,179
anything happens, and that
493
00:12:57,179 --> 00:12:58,340
conversation is stored for
494
00:12:58,340 --> 00:12:58,899
later.
495
00:12:58,899 --> 00:12:59,980
If you have lived through an
496
00:12:59,980 --> 00:13:01,539
outage caused by an undocumented
497
00:13:01,539 --> 00:13:02,980
change, this tends to matter
498
00:13:02,980 --> 00:13:04,179
more than it does to everyone
499
00:13:04,179 --> 00:13:04,700
else.
500
00:13:04,700 --> 00:13:06,860
There are also honest reasons to
walk away from it.
501
00:13:06,860 --> 00:13:09,700
If everything you run lives
inside a single cloud.
502
00:13:09,700 --> 00:13:12,139
A tool built for that cloud is
often the simpler answer.
503
00:13:12,139 --> 00:13:13,820
Microsoft's own bicep for Azure
504
00:13:13,820 --> 00:13:15,139
and Amazon's cloud formation
505
00:13:15,139 --> 00:13:16,379
exist for exactly that
506
00:13:16,379 --> 00:13:17,220
situation.
507
00:13:17,220 --> 00:13:18,659
They're narrower and tied to one
508
00:13:18,659 --> 00:13:19,980
platform, and for a single
509
00:13:19,980 --> 00:13:20,980
platform team, that is a
510
00:13:20,980 --> 00:13:21,620
feature.
511
00:13:21,620 --> 00:13:23,820
Between those two extremes,
there's a middle ground.
512
00:13:23,820 --> 00:13:26,179
Pulumi lets you describe
infrastructure in ordinary
513
00:13:26,179 --> 00:13:28,980
programming languages instead of
Terraform's own, which suits
514
00:13:28,980 --> 00:13:31,220
teams that already live in
TypeScript or Python.
515
00:13:31,220 --> 00:13:34,259
Ansible, which many Microsoft
Teams already use, configures
516
00:13:34,259 --> 00:13:35,860
software on machines that exist.
517
00:13:35,860 --> 00:13:38,179
It can create infrastructure
too, which is why running it
518
00:13:38,179 --> 00:13:40,700
alongside Terraform without
clear boundaries is a known way
519
00:13:40,700 --> 00:13:41,539
to create drift.
520
00:13:41,539 --> 00:13:42,860
One practical note, because it
521
00:13:42,860 --> 00:13:44,034
comes up in every team's first
522
00:13:44,034 --> 00:13:44,970
conversation.
523
00:13:44,970 --> 00:13:46,570
Terraform's command line tool is
524
00:13:46,570 --> 00:13:47,610
free to use on your own
525
00:13:47,610 --> 00:13:48,490
infrastructure.
526
00:13:48,490 --> 00:13:51,210
You'll also hear the name Open
Tofu, an open source version
527
00:13:51,210 --> 00:13:53,289
built by the community that
speaks the same language.
528
00:13:53,289 --> 00:13:55,529
The file you learn to write
works with both, so this isn't a
529
00:13:55,529 --> 00:13:56,649
decision you have to make today.
530
00:13:56,649 --> 00:13:58,529
Strip all of it back and
Terraform is a trade.
531
00:13:58,529 --> 00:14:01,370
You spend time writing down what
you want in a language you have
532
00:14:01,370 --> 00:14:04,090
to learn, and in exchange, you
stop depending on anyone's
533
00:14:04,090 --> 00:14:05,490
memory of a portal.
534
00:14:05,490 --> 00:14:07,210
Whether that's worth it depends
535
00:14:07,210 --> 00:14:08,529
on how much infrastructure you
536
00:14:08,529 --> 00:14:10,250
have and how many people touch
537
00:14:10,250 --> 00:14:11,649
it.
538
00:14:11,649 --> 00:14:14,009
A quick recap and one question
for you.
539
00:14:14,009 --> 00:14:15,529
So the whole thing comes down to
this.
540
00:14:15,529 --> 00:14:18,090
Infrastructure as code means the
environment you want lives in a
541
00:14:18,090 --> 00:14:19,970
file, not in somebody's memory
of a portal.
542
00:14:19,970 --> 00:14:22,850
Providers are how Terraform
reaches each platform plan shows
543
00:14:22,850 --> 00:14:24,970
you what will change before it
changes and apply.
544
00:14:24,970 --> 00:14:25,809
Makes it real.
545
00:14:25,809 --> 00:14:28,490
The state file is terraform's
memory of what it built, and
546
00:14:28,490 --> 00:14:30,889
modules stop you rebuilding the
same thing twice.
547
00:14:30,889 --> 00:14:32,250
Remote state keeps a team from
548
00:14:32,250 --> 00:14:33,970
overwriting each other and drift
549
00:14:33,970 --> 00:14:34,610
is reality.
550
00:14:34,610 --> 00:14:36,409
Quietly disagreeing with your
file?
551
00:14:36,409 --> 00:14:38,649
There's one question worth
taking with you.
552
00:14:38,649 --> 00:14:41,409
Which part of your own setup
would you most want written down
553
00:14:41,409 --> 00:14:42,090
in a file?
554
00:14:42,090 --> 00:14:44,610
And what's actually stopped you
from doing it?
