►
From YouTube: Terraform modules in GitLab
Description
Conversation between Maria (SrConfigure Product designer) and Craig (Sr Site Reliability Engineer) I on how the GitLab Infrastructure team uses Terraform modules and the upcoming feature for introducing a Terraform registry where modules will be automatically be populated.
A
B
A
It's
an
instance
name:
it's
it's!
A
analogous
to
instantiating
a
class
right,
you'd,
be
like
in
some
pseudo
code,
you'd
be
like
var,
my
instance
equals
new,
my
class
and
the
variable
name.
You
give
that
class
instance
is
not
dictated
by
the
Declaration
of
the
class
and
that's
what
that
string
is
after
module
and
terraform
right.
It's
the
the
name
of
that
instance.
So
you
you
make
it
up.
It's
not
part
of
module
and.
B
B
B
A
Answer
to
how
someone
would
use
this
realistically
is
someone
would
need
to
create
some
infrastructure
and
would
look
in
our
existing
terraform,
codebase
and
module
directory
for
similar
things
or
the
reviewer
would
point
that
out.
So
it's
kind
of
its
kind
of
like
anything
else,
I
get
to
analogous
to
adding
a
feature
to
a
code
base
as
a
new
developer,
and
if
someone
kind
of
reinvents
the
wheel,
it
would
be
up
to
the
reviewer
on
team
members
to
say:
hey.
A
A
It's
really
exactly
like
that,
and
that's
now
that
I've
said
that
I
think
that's
a
really
good
way
to
think
about
how
we
use
terraform
modules
at
gitlab,
then
they
tend
not
to
be
generic,
reusable
components
that
would
be
of
interest
to
the
rest
of
the
world,
their
specific
wrappers
for
us
that
do
sometimes
very
simple
things
like
default,
a
bunch
of
params
that
we
never
want
to
vary
that
kind
of
thing.
So
it's
some!
They
would
quite
rarely
become
things
we
want
to.
A
A
A
Gonna
say
we
create
new
modules.
Sometimes
we
extend
or
change
the
behavior
of
existing
ones,
pretty
regularly.
You
know
almost,
and
sometimes
it's
as
easy
as
okay.
We
already
have
this
functionality
in
a
module.
We
can
just
declare
it.
You
know
in
our
environment
files
like
what
you're
looking
at
now,
an
actual
terraform
root
module
that
describes
a
gay
lab
environment,
okay,.
B
B
A
A
really
good
question,
and
for
for
us
specifically
on
Gallivan
for
this,
this
is
this
can
be
particularly
awkward
because,
unfortunately,
we
have
a
lot
of
repetition
between
our
modules.
So
the
vast
majority
of
our
Sara
form
code
was
written,
pre,
terraform,
not
point
12,
which,
as
you
might
know,
like
completely
revised
the
language
and
added
more
abstractions
that
allow
you
to
write
dry,
terraform
code.
This
didn't
used
to
be
possible.
A
You
know
to
sort
of
explain
their
particular
particular
use
case
so
like
that
that
shouldn't
really
be
held
up
as
an
example
these
days,
I
think,
but
some
in
the
general
case,
our
workflow,
for
making
changes
to
modules
is
a
little
clunky
right
because
we
have
to,
as
you
said,
find
the
module
would
find
the
best
module
from
that
tree
from
terraform
modules
check.
If
it
supports
your
use
case,
usually
you
know
often
extend
it
to
support
your
use
case.
A
Making
all
the
usual
trade-offs
around
do
I
make
this
backwards-compatible
or
do
I,
make
a
breaking
change
and
then
have
to
go
and
update
all
uses
of
that
module
everywhere
in
our
in
our
terraform
codebase,
which
we
do
sometimes,
and
you
know,
then,
when
you're
confident
in
your
change,
you
have
to
get
a
tag
released
and
then,
mr
the
tag
back
into
that
get
lab
comm
infrastructure
repo.
This
is
all
really
fiddly.
A
B
B
A
B
A
A
A
A
I
made
some
change.
This
is
a
very
trivial
change,
I
added
that
he
default
to
a
variable.
So
this
is
a
backwards,
compatible,
non-breaking
change.
For
some
reason,
I
decided
that
this
was
a
patch
from
and
a
minor
release.
It
must
have
been
fixing
something
I,
don't
remember,
and
we
use
in
our
lab
CI
for
these
modules
we
reference
a
because
we
have
all
these
different
modules.
We
don't
duplicate
all
the
pipeline
code.
A
I've
seen
this
year
is
used
in
like
a
bunch
of
places
here,
it's
it
reads,
commit
messages
and
bumps
like
releases,
a
tag,
it's
kind
of
appropriate
to
the
most
severe
commit
message.
So
if
you're,
if
you're
merging,
if
the
new
master
commit
contains
commits
to
just
say
fix
in
their
title,
it
will
bump
the
patch
version,
look
to
the
most
recent
tag
and
add
a
patch
semver
and
get
that
released.
So
I
mean
the.
What
is
the
case
here
so
the.
B
A
B
A
A
B
A
A
B
A
B
B
B
B
A
So
yeah,
that's
that
sounds
great
I
mean
you
know.
If
you're
going
to
use
semver
at
least
get
the
benefits
of
semver
right
so
being
able
to
pin
2
minor
series,
or
rather
major
series
I
guess
like
1x,
would
would
be
very
helpful,
especially
because
the
next
pipeline
run
of
our
master
pipeline
would
presumably
put
in
all
these
new
minor
and
patch
versions.
If
they
were
allowed
to
float
a
bit
and
we
would
immediately
see
any
planned
ifs
there
and
be
able
to
go
back
and
fix
them
caused
unexpected
dis.
A
We're
not
at
the
moment
we're
considering
getting
rid
of
most
Mutual's
modules
altogether,
really
and
just
having
entry
modules
in
a
mono
repo
so
that
there
is
no
versioning
like
you
make
a
change
to
a
module.
It
is
being
used
by
the
other
plans
because
in
because
in
practice
we're
not.
This
is
like
under
discussion.
So
this
is
like
my
opinion,
but
it's
I'm,
not
the
only
one
I
sunk.
It
live
in
furnace
airily,
feeling
the
benefit
of
having
all
of
these
extracted
modules
that
are
typically
only
used
in
in
one
place
in
madness,
yeah.
A
B
B
A
Like
at
the
moment,
all
of
our
huge
duplication
between
our
routes
modules
as
well
like
the
environments
directory
and
get
lab
comment
for
it.
So
that's
something
that
we
could
really
potentially
try
out.
I
mean
there's
another
way
to
do
that
as
well,
which
is
to
use
workspaces
to
use
the
same
piece
of
terraform
code
across
different
environments.
B
A
No
I
don't
know
until
I
mean,
as
far
as
I
knew,
which
maybe
isn't
much
terraform
modules
didn't
used
to
have
names
because
they
were
referenced
by
some
fully
qualified
URL
like
a
relative
path
or
or
a
get
URL,
but
now
that
there's
a
module
registry,
presumably
to
have
names
for
this
I
mean
unfortunately,
you're.
Really
speaking
to
someone
who
doesn't
know
about
this
stuff,
cuz
I've
never
used
a
powerful
module
registry
before
so.
A
Even
then,
the
de
string,
the
first
instance
of
the
string
at
night
right
after
module,
that's
just
the
instance
right.
That's
not
the
modules
name,
and
now
the
I
I,
don't
think
so
anyway,
I
mean
because
if
you
have
more
than
one
instance
that
module
you
kind
of
have
to
call
them
something
else.
So.
B
A
A
B
A
Not
sure
how
that
could
I'm
not
sure
how
I
could
possibly
work
because
the
you
know
you
know
that
cloud
map
module
I
showed
you.
For
instance,
it
can't
possibly
know
what
consumers
there
are
in
the
world
that
are
pulling
it
in
on
what
they're
calling
it.
That
would
be
like
a
class
in
a
programming
language
not
having
a
name,
unless
it's
somehow
knew
everything
in
the
world
that
consumed
it
and
looked
at
what
they're
calling
it
and
then
like
picked
one
or
something
it's
wrong.
B
A
Yeah
I
mean
really
I'm
just
looking
up
now,
terraform
registry
publishing
modules,
because
because
I
really
can't
give
you
an
answer
without
having
ever
built
a
registry
compatible
module
or
even
used
one
myself,
that's
why
I'm
speaking
so
vaguely
because
I've
not
used
this
business
stuff
at
all.
Actually,
that's.
A
B
A
B
A
Think
we
prematurely
extracted
them,
so
it's
quite
difficult
to
speculate.
I
mean
yeah,
they're,
they're.
Definitely
poor
candidates
for
for
reuse
by
people
other
than
the
get
labem
for
team,
because
they're
sitting
to
us,
but
yeah,
I,
I,
don't
know
and
I
would
have
to
go
away
and
like
to
learn
about
about
terraform
module
registries.
To
really
to
really
like
answer
any
of
these
questions.
Okay,.
B
A
I
mean,
like
my
point
of
view,
as
someone
who
writes
a
lot
of
tariff.
Where
is
this
it's
more
than
happy
to
dog
food,
the
feature
as
long
as
it
is
a
feature
that
we
actually
need?
So,
if
you
know
rather
than
do
work
to
use
the
gitlab
module
registry,
I
personally
would
be
arguing
in
favor
of
enlightening
all
of
our
modules
into
a
mono
repo,
but
but
yeah.
A
Yeah,
it's
it's
slightly
complicated
because
we,
some
of
the
modules
are
used
somewhere
else,
but
that
that
other
consumption
point
is
far
less
frequently
used
and
important
than
that
main
consumption
point
get
a
common
infrastructure
that
I
showed
you.
So
it's
very
asymmetrical.
It's
not
like.
We've
got
like
three
repos
of
sort
of
equal
ish
importance
that
are
all
depending
on
this
common
code
and
that's
that's
kind
of
the
that's
kind
of
the
problem.
Yeah.
B
A
B
A
In
terms
of
if
an
environment
is
like
environments
in
overloaded
would
in
terraform
terms,
an
environment
is
usually
used
coat.
Ominously
with,
like
a
rule
like
something
that
has
its
own
TF
State,
the
new
terraform
in
it
and
run
plans
on
run,
applies
on
and
the
the
environments
directory
and
get
that
comm
infrastructure
should
be
as
seen
as
a
source
of
truth
there.
So
we
have
lots
of
environments
in
terraform
terms,
but
then
there's
like
a
mapping
of
those
on
to
get
lab
environments.
A
So,
in
terms
of
get
lab
environments,
we've
got
I
mean
production
which,
for
G,
Pro
and
G
stage
pre.
Those
three
are
similar
styles
of
deployment.
Then
we've
got
ops,
which
is
a
bit
different.
You
know,
there's
there's
a
lot
of
different
things
and
since
it
confuse
this
firm,
there
are
some
modules
like
CI
and
or
CI,
which
correspond
to
pieces
of
production
like
if
you
make
changes
to
them
and
it
changes
our
CI
infrastructure,
yeah
I
mean
that's,
that's
a
production,
CI
infrastructure,
you've
changed
production,
but
it's
not
in
the
production
module.
A
There's
a
there's,
a
mapping
that
must
be
performed
between
a
terraform
root,
module
or
environment
and
like
an
engineer's
concept
of
an
environment.
So
the
simple
answer
is
get
logged
production,
as
in
all,
the
things
that
serve
real
production
requests
is
terraformed
from
like
two
or
three
even
separate
terraform
root
modules,
and
then
it
gets
confusing,
because
we
also
use
root
modules
not
just
to
like
shut
up
production
but
as
ways
to
express
different
environments
at
the
same
deployment.
I
know.
A
A
bit
crazy,
gee
prodigy
stage
are
very
similar
root
modules.
They
both
declare
a
bunch
of
resources
which
are
needed
to
run
a
gate,
lab
comm
type
thing
and
in
the
case
of
G
product,
actually
runs
gitlab
comm,
but
then
you've
got
the
CI
module,
which
runs
production
CI
and
there
is
no
CI
staging
module
as
such,
so
it's
all
unwound
and
mixed
and
match.
So
it's
hard
to
point
to
each
it's
hard
to
look
at
the
list
of
terraform
environments
and
go
these
map
cleanly
on.
A
B
A
Like
what
just
in
case
like
workspaces,
are
a
terraform
state
namespace
effectively,
so
you
you
can
take
one
route
module
like
one
piece
of
terraform
code
that
has
like
a
back
end
declared
has
is
like
a
main
terraform
file
effectively
and
by
switching
workspaces.
You
switch
state
files
in
that
same
back-end,
so
I
could
like
declare
a
thing.
Terraform
ply.
Is
there
terraform
plan,
no
changes
already
applied,
terraformed,
select
workspace
and
then
terraform
plan
and
it's
showing
me
the
same
diff
again.
A
Like
when
you
combine
that
with
being
able
to
inject
variables
per
workspace,
which
you
can
do
that's
another
way
to
dry
out
terraform
code
to
say,
hey
I've
got
this
like
parameterised
module
of
code
and
I
can
use
workspaces
and
different
variables
to
instantiate
that
terraform
in
slightly
different
ways.
So
it's
overlaps
with
modules
conceptually.
It.
A
It's
all
a
bit,
we
would
use
I
think
the
ideal
and
again
this
is
like
a
newish
feature:
workspaces
new.
It
I
think
our
ideal
final
States
is
removing
the
duplication
between
things
like
gee,
prodigy
stage
and
pre
like
things
that
look
a
bit
like
get
lab
comm
and
it
put
that
all
in
one
place
a
parameterised
place
that
says:
hey
like
a
gait
lab,
comm
kind
of
looks
like
this.
A
A
B
A
To
make
it
concrete,
let's,
let's
forget
gitlab
entirely
and
say
I'm
building
a
website
from
scratch
and
for
my
infrastructure,
I
go
right.
Well,
I
need
a
kubernetes
cluster
which,
in
terraform
terms,
involves
declaring
at
least
two
quite
large
resources,
one
for
the
google
container
cluster
and
one
for
the
Google,
contain
a
node
pool
and
for
argument's
sake.
Let's
say:
I
need
a
NAT
gateway
right
to
send
that
traffic
I
might
I
might
type
all
that
up,
be
like
cool,
like
I'll
type,
my
terraform
and
go
cool.
What's
the?
A
A
I
haven't
used
modules
yet
because
there's
kind
of
not
a
need
at
this
point
now,
let's
say
I
deploy
another
website
all
together
and
need
a
for
whatever
reason
like
its
own
kubernetes
cluster,
a
slightly
differently
configured,
one
I
might
draw
than
coffee
paste
the
entire
Declaration
of
the
Cuba
Nancy
stuff
from
my
previous
website,
because,
let's
say
there's
a
lot
of
commonality.
I
might
then
choose
to
extract
that
into
a
module
and
reference
that
module
window
some
params
yet
from
the
new
from
the
new
module.
A
That's
sorry
for
rambling!
So
long,
because
that's
probably
a
bit
out
of
scope
for
this
registry
feed
check
is
really
like.
If
you're
gonna
use
modules,
you
might
want
to
use
them
in
a
registry.
Therefore
it
might
make
sense
for
get
lab
to
be
a
module
registry
and
that
kind
of
has
nothing
to
do
with
workspaces.
But
for
the
for
the
dogfooding,
it's
like
potentially
a
bit
but.