►
From YouTube: Detecting drift with Terraform and GitLab CI/CD
Description
A walkthrough of how you can detect drift with GitLab and Terraform when using Infrastructure as Code.
Source Code: https://gitlab.com/bdowney/terraform-drift-detect
Learn more about GitOps: https://about.gitlab.com/topics/gitops/
A
Hello,
my
name
is
Brad
downy
and
I'm,
going
to
walk
you
through
a
quick
demo
of
how
to
detect
drift
in
your
infrastructure
when
using
infrastructure.
As
code
I've
got
a
small
example
project
here
called
terraform
drift,
detect
I'm
using
terraform,
because
it
is
a
declarative
language
and
tracks
state
of
infrastructure.
So,
basically,
if
you're
not
familiar
terraform,
you
can
ask
it
to
compare
the
running
infrastructure
configuration
to
what
you
have
in
your
your
code
or
your
configuration
files.
A
This
is
going
to
kick
off
a
process
here
to
validate
my
current
configuration,
do
a
plan
and
then
apply
that
configuration
into
production,
so
we're
gonna
have
get
lab
and
terraform
completely
in
sync,
with
what
the
infrastructure
looks
like
so
I'm
going
to
go
back
to
the
project
here
and
we're
going
to
look
at
the
files.
While
that's
running
so
my
configuration
files
I've
got
a
couple
to
terraform
files.
The
end
in
TF
I've
got
a
single
back-end
file
here.
What
this
is
doing
is
specifying
the
use
of
terraform
cloud
and.
A
As
a
remote
repository,
so
we're
going
to
store
our
infrastructure
state
files
in
terraform
cloud
and
the
second
is
what
we're
going
to
be?
Actually
configuring
and
changing
and
I'm
using
a
very
simple
example
here,
with
AWS
route,
53
DNS
service
I've
got
an
entry
called
drift.
Gilligan,
ops,
demo,
comm
and
a
record
with
8.8.8.8
is
the
value.
So
this
is
what
my
canvas
is.
What
my
infrastructure
should
look
like
and
I'm
going
to
run
that
and
make
sure
that
everything
executes
successfully.
A
So
if
I
go
back
over
here,
it
looks
like
we're
planning
this
or
our
gonna
take
a
look
at
it.
We
can
see
in
the
job
logs
that
that
it's
running
through
here
and
it
looks
like
we've
got.
Everything
is
succeeding,
so
we've
done
a
plan
and
now
we're
doing
an
apply.
So
we
know
that
our
infrastructure
will
be
be
configured
as
as
the
filed
specified,
I'm
gonna
look
at
one
last
thing
here
in
the
files.
Let's
look
at
the
job
configuration
the
get
lab
CI
file
itself,
starting
at
the
top
here.
A
We're
gonna
use,
hashey
corpse,
docker
image,
terraform
light.
It's
gonna
give
us
all
the
terraformers
going
to
be
pre-installed
with
all
the
the
various
different
requirements
before
each
job
runs
I'm,
going
to
add
curl
to
the
container
and
run
a
terraform
version.
So
we
have
that
in
the
job
log
and
then
we're
gonna
an
it
to
make
sure
that
we
prep
the
environment,
got
three
stages,
validate
plan
and
apply.
So
let's
look
at
the
validate
stage.
We're
gonna
do
a
terraform
validate
in
a
format
check
and
we're
gonna
fail.
A
If
that's,
if
it's
not
formatted
correctly,
so
we
want
to
enforce
good
structure
of
our
infrastructures
code
or
good
formatting
when
we
do
merge
requests,
which
is
the
the
proper
way
to
make
changes
in
the
environment.
We're
gonna
run
this
specific
job.
It's
going
to
run
a
terraform
plan
and
then
I'll
put
that
into
a
particular
file
and
we're
going
to
save
that
file
as
an
artifact
and
then
we're
also
gonna
do
a
little
API
magic
here
to
post
the
diff
into
the
merge
request.
A
So
this
way,
when
you're
reviewing
changes,
you
understand
you
can
see
right
there
in
the
comments
posted
on
what
exactly
is
gonna
change.
This
will
help
you
make
better
decisions
on
whether
to
merge
that
code
into
master
or
not
once
it's
merged
into
master
will
actually
do
another
plan
and
then
an
apply.
A
We
only
apply
for
master,
because
masters
should
represent
what
is
actually
running
in
production,
and
it
should
always
be
the
source
of
truth
for
what
is
running
in
your
infrastructure
when
you
do
feature
branches
when
you're
planning
changes,
that's
where
you're
testing
out
your
code,
making
sure
it's
well
formatted,
maybe
it's
being
tested
in
in
a
development
environment
whatever,
but
masters
should
represent
your
production
code
and
then
the
last
little
bit
here,
which
we
haven't
kicked
off
a
job
yet,
but
we'll
we'll
take
a
look
at.
Is
this
drift
detection?
A
So
what
we're
gonna
do
is
we're
going
to
do
another
terraform
plan,
we're
gonna,
ask
it
to
use
an
exit
code
to
represent
what
the
the
diff
looks
like
and
we're
going
to
save
that
to
a
file
as
well.
So
if
it
exits,
if
the
terraform
plan
exits
with
an
exit
code
of
zero,
we're
just
gonna
print-
and
you
know
no
change-
is
found-
we're
gonna
exit
zero.
That's
that's!
A
What
we're
hoping
for,
if
it
exits
with
a
one
this
is
some
error
occurred,
so
we're
just
going
to
bubble
that
up
and
exit
out
if
it
exits
with
the
two.
That
means
changes
in
the
configuration
were
found.
That
means
we
have
drift,
so
we're
gonna,
say
changes
were
found
and
then
we're
going
to
put
that
into
a
message
here
and
use
the
API
to
create
an
open
and
shoes.
We're
gonna
use
the
gitlab
API
to
create
a
new
issue
and
and
then
alert
users.
So
you
can.
A
A
So
we're
only
gonna
do
this
on
schedules.
So
what
does
that
mean?
If
I
go
to
my
CI
CD
schedules
here,
I
can
see
that
I've
got
a
single
scheduled
job
to
run.
It's
open
it
up
here.
We're
gonna
see
that
it
runs
every
day
at
4:00
a.m.
or
whenever
I
manually,
kick
it
off
in
u.s.
specific
time
zone
and
I'm
gonna
run
that
on
the
master
branch.
So,
let's
take
a
look
at
my
existing
pipeline
here,
looks
like
by
my
pipeline
succeeded.
So,
let's
take
a
look
at
my
actual
route.
A
53
console
here
do
a
refresh
and
I
can
see
that
my
value
here
is
8.8.8.8,
which
is
what
I
have
in
my
code
and
what
I
expected
I'm
gonna
do
something
naughty
here
and
change
the
value
directly
in
the
infrastructure
without
updating
my
code,
so
I'm
gonna
hit
save
there
and
go
back
and
I'm
gonna
pretend
like
it's
4
a.m.
here.
Of
course,
we
could
set
this
to
run
more
frequently
if
I
want
to
catch
drift
sooner.
A
See
I've
got
a
new
pipeline
here
running
on
the
master
branch,
this
time
with
only
two
jobs
in
it.
So
let's
take
a
look
at
that.
We've
got
the
validate
job,
which
is
what
I
expect,
because
I
want
to
make
sure
that
our
code
stays
valid
and
each
night
reasons
why
this
this
may
fail
or
trigger
would
be
a
dependency
or
an
infrastructure.
Api
might
change
things,
might
change
in
the
infrastructure
and
our
infrastructures
code
might
get
stale
or
be
in
invalid.
A
At
some
point
we
want
to
catch
that
and
that
should
be
slightly
different
than
then
drift.
We
can
combine
these
steps
but
in
my
mind,
I
think
we'll
will
reuse
this
and
just
make
sure
that
the
code
itself
validates
out
and
it
meets
you
know
current
syntax
and
and
module
requirements.
So
my
validate
step
is
running
now.
I'm
gonna
jump
over
to
that
or
my
drift.
A
My
drift
job
here
so
we'll
see
that
we
started
off
by
you
know
like
the
other
ones,
loading
B,
terraform,
docker
image
with
all
the
the
requirements,
we're
gonna
add
curl
in
there,
because
we
need
that
later
run.
Our
terraform
version,
whoops
jumped
on
me,
run
our
terraform
version
and
then
we're
gonna.
Do
our
terraform
plan
with
our
detailed
exit
code
here
and
we'll
see
that
it
did
detect
a
change
here.
It
says:
okay,
8.8.8.8
clean
the
infrastructure.
A
My
code
says
it's
888,
my
exit
code,
exited
correctly,
changes
were
found
and
it's
gonna
open
an
issue
here.
That
was
one
issue
before
we
started
and
we're
gonna
go
back
here
and
see
that
we've
got
a
new
issue
here,
updated
just
now.
Not
this
old
one
from
my
previous
testing
an
hour
ago,
so
we're
gonna,
look
at
the
new
one
here
and
see.
Drift
has
been
detected,
could
see
what
the
dip
and.
A
Enforce
the
change
on
the
on
the
schedule,
you
infrastructure,
just
changes.
This
is
more
of
an
alert
to
an
administrator
to
go
investigate.
Why
did
it
change?
Why
did
it
change
in
production?
So
this
is
going
to
be
a
scenario
where
you
may
want
to
may
need
to
open
a
new
merge
request,
make
a
change
edit
the
code
and
have
your
infrastructure
Reese
inked
with
production.