►
From YouTube: GitLab Environment Toolkit with Geo Overview
Description
Nick Westbury (Senior Software Engineer in Test) gives an overview of how the GitLab Environment Toolkit can be used to automate GitLab Geo deployments for various reference architectures.
GitLab Environment Toolkit: https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit
A
Cool
yeah
thanks,
so
the
purpose
of
today
is
I'm
going
to
go
over
the
get
lab
environment
toolkit,
which
is
a
tool
we've
been
using
in
quality
for
a
while.
Now,
internally
and
recently,
we've
been
we've
kind
of
moved
out
to
the
wider
audience,
but
also
recently,
we've
added
a
lot
of
geo
work
to
it
so
before
it
would
set
up
our
reference
architectures,
so
anything
from
a
1k
to
a
50k
architecture,
and
now
we've
started
using
it
for
setting
up
geo
deployment
as
well.
A
A
The
main
reason
it
shouldn't
matter
too
much
is
because
a
lot
more
is
still
coming
into
the
environment
toolkit,
and
this
is
because,
like
say
originally,
it
was
very
much
an
internal
tool
and
as
we
make
it
more
public,
something
we're
trying
to
make
it
more
user-friendly,
so
we're
trying
to
change
some,
how
it
works
so
once
that's
all
finalized
there'll,
probably
be
there'll,
be
new
documentation.
There'll,
probably
be
another
demo
of
more
deep
dive
into
the
environment
toolkit
itself.
A
So
today
I'm
going
to
go
over
the
basics
of
setting
up
the
toolkit
for
how
just
so
you
can
get
your
own
environment
and
then
actually
running
the
the
geo
playbook.
So
we
can
have
at
the
end
of
it,
we'll
have
a
couple
of
sites
that
are
actually
working
and
we
can
see
kind
of
some
of
the
challenges
challenges
we
have
when
trying
to
automate
these
things,
some
of
the
workarounds
we
do
and
the
difference
between
we
have
between
rep
manager
and
petroni.
A
A
A
A
A
A
A
As
I
say,
this
all
works
as
of
the
alpha
that
was
tagged
today
and
will
be
updated
once
we
have
a
lot
of
the
new
changes
in
so
there's
two
main
parts
to
the
toolkit.
We
have
answer
and
we
have
terraform.
So
we
use
terraform
to
spin
up
our
environments
and
in
the
geo
world
we
have
our
primary
and
our
secondary
site.
A
A
So
we
can
go
into
something
like
the
postgres
here
and
we
have
the
we
have
three
of
these.
It's
a
postgres
box.
We
have
our
geo
site
and
geo
deployment,
which
I'll
show
you
in
the
variables
and
we
have
the
type
of
machine.
So
this
is
all
for
gcp
at
the
moment,
but,
like
I
said,
we
do
have
documentation
for
the
others
as
well.
A
A
This
is
just
a
unique,
unique
name
for
your
single
environment
that
you
want
to
call
it.
It
doesn't
there's
no
set
pattern
that
it
has
to
be
this,
just
whatever
you
want
to
call
it
the
external
ip.
So
this
is
a
prerequisite
that
you
need
to
create
within
gcp,
create
a
static
ip
address
that
you'll
be
accessing
your
gitlab
deployment
from
outside.
A
But
again
the
deployment
name
can
be
whatever
it's
just
how
you
connect
your
two
machines
up,
so
it's
my
geo
deployment
or
whatever
you
would
have.
It
called
so
I
say
the
secondary,
because
this
is
the
1k.
So
it's
a
much
smaller
scale.
We
haven't
got
all
the
machines
in
here.
Everything
actually
just
lives
on
the
one
box
for
our
gitlab
rails,
but
we
still
have
the
same
variables
of
saying
we
have
a
prefix
for
it,
it's
using
the
secondary
site
and
it's
got
the
same
geo
deployment
variable
and
this
one's
in
europe.
A
A
The
only
difference
is:
we've
got
a
different
external
ip
address
and
we've
got
a
different
deployment
name,
interestingly,
because
we
do
rep
manager
and
patrony.
If
you
were
doing
this
for
petroni
the
postgres,
you
can't
have
a
secondary
cluster
on
the
for
with
rep
manager.
Three,
so
we
would
just
lower
this
down
to
one
but
because
we're
using
patrony
on
the
3k.
We
can
leave
that
at
three
and
everything's
fine
ansible
works
very
much
the
same
way.
A
We
have
our
inventories.
So
these
again,
this
is
the
only
bit
you
need
to
worry
about.
Everything
outside
of
these
folders
is
just
standard
in
the
sense
of
you,
don't
need
to
change
it.
If
you
set
up
the
inventory
and
the
terraform
config
correctly,
you
just
need
to
run
one
command
and
everything
works.
A
So
we
have
our
again.
We
have
our
jio
10k
1k
and
our
10k
3k
in
here
we
have
the
primary
the
secondary,
but
we
have.
We
also
have
an
all,
and
the
reason
for
this
is
because,
when
we
set
up
for
a
geo
deployment,
we
set
up
the
primary
and
secondary
originally
as
two
separate
environments,
so
they
don't
know
anything
about
each
other
at
that
point,
so
we
to
kind
of
I
suppose
it
was
to
change
the
environment
toolkit
as
little
as
possible.
A
We
kept
them
as
treat
them
as
two
completely
separate
things,
and
then
we
have
this
all,
which
is
actually
how
we
fetch
all
the
machines
so
that
we
can
then
set
up
geo
so
again,
within
premium
secondary.
We
only
have
two
files.
We
have
our
inventory
file,
which
we
get
for
gcp,
which
this
here
is
really
the
most
important
part.
A
So
if
your
prefixes
are
different,
terraform
would
have
created
a
bucket
called
one
thing
and
ants
will
be
looking
for
something
else:
the
gcp
project
name,
we
have
our
ansful
user.
This
is
just
this
is
generated
for
us.
We
have
a
ss
ssh
key
pair
and
when
we
upload
it,
we
get
back
a
unique
id
for
it.
So
this
is
just
the
value
of
that.
So
then
we
just
have
paths
to
our
key
files.
Our
service
discount
file,
a
get
lab
license.
A
If
you
haven't
got
a
license
it
will
everything
still
works.
It's
just
a
standard
installation,
our
external
url,
on
this
one
we're
using
petroni.
So
we've
got
that
set
and
we
have
a
file
which
is
our
initial
password.
This
is
just
this
is
actually
generated
for
us.
If
we
don't
set
it
or
we
can
actually
set
this.
Some
of
the
new
changes
that
are
actually
coming
in
is
we're.
A
Removing
this
at
the
moment
like
say,
if
you
don't
set
it,
it
will
generate
it
for
you,
but
some
of
the
new
changes
as
we
make
this
public
are
actually
that
you
define
all
your
passwords
in
this
file
and
the
reason
for
that
is
just
then
that
people
can
then
we're
not
restricting
that
we
generate
passwords
using
answer.
You
can
generate
your
passwords.
A
However,
you
want
to
you,
can
set
them
in
this
file
and
then
it's
completely
up
to
you,
we're
not
like
controlling
how
that
is,
whereas
before
we
very
much
just
kind
of
had
our
defined
passwords
that
never
changed.
So
that's
only
that's
one
of
the
smaller
changes
that's
coming
in
and
then
we
have
our
all.
So
I
say
primary
and
secondary
only
worry
about
that
one
individual
site,
whereas
the
all
is
the
one
that
looks
across
both.
A
So
this
one
actually
looks
across
instead
of
using
the
here,
we
use
a
node
prefix,
which
is
the
prefix
that
we
define,
whereas
on
this
one
we
use
our
geo
deployment,
which
is
the
deployment
name
that
we
make
and
I'll
I'll
show
you
these.
Where
we
get
these
values
from
within
gcp
as
well,
and
then
this
is
pretty
much
the
same.
It's
just
a
stripped
down
version.
We
don't
need
all
the
variables
that
we
have
in
the
previous
versions.
We
just
have.
A
The
main
difference
is
that
we
have
the
concept
of
an
external
and
the
secondary
external
url.
So
as
mentioned,
I
say,
the
documentation
does,
I
think,
does
quite
a
good
job
of
explaining
how
to
set
up
the
service
account
the
ssh
key
pair.
All
of
that
information
is
in
there,
so
it's
the
best
place
to
use
the
follow
through.
A
D
A
A
D
A
So
there
you
go
we're
looking
here,
we're
looking
for
geo,
10k,
1k
secondary
and
that's
the
gitlab
node
prefix
of
this
machine
and
every
machine
that
is
in
that
that
site,
and
then
we
have
our
our
node
type.
So
this
just
tells
us
what
does
what's
the
purpose
of
this
machine,
so
this
one's
an
elastic
box,
we
have
the
level
which
is
primary
and
secondary.
A
Basically,
we
have
if
it's
got
a
one
at
the
end,
it's
a
primary
if
it's
anything
other
than
a
one,
it's
a
secondary,
and
then
we
have
our.
So
this
is
the
geosite.
So
again,
this
is
what
determines
primary
or
secondary.
We
have
our
full
role.
This
is
quite
useful
when
we're
trying
to
identify
what
easily,
what
a
machine
does
and
where
it
lives.
So
this
is
all
all
this
is,
is
actually
a
combination
of
the
joe
site
and
the
note
level
and
the
role
pretty
much
so
it's
like
here.
A
We
have
our
geo,
it's
part
of
the
geoprimary
site
and
it's
an
elastic
secondary.
So
this
one
label
tells
us
everything
we
need
to
know
to
know
where
we
need
to
put
certain
config
and
then
we
have
the
deployment
name.
So
this
is
everything
that
we
use
and
if
you
haven't
used
our
terraform
modules
and
you
created
your
own
infrastructure.
A
A
A
A
A
A
B
A
I
can
well,
I
can
carry
on
going
over
some
of
the
geo
work
and-
and
I
can
worry
about
that
later
rather
than
waiting
for
now.
I
think
because
I
can
at
least
try
and
show
the
theory
of
what
it
should
do
so
yeah.
Once
you
have
your
two
working
environments.
We
have
two
basic
ways
of
running
it.
So
once
you've
set
up
your
files
and
your
terraform
files,
you
just
need
to
run
again
like
we
have
these
things
documented.
A
You
just
need
to
run,
terraform
apply
to
create
all
the
infrastructure,
and
then
you
run
your
ansible
command
to
actually
to
put
git
lab
into
the
right
places.
So
you
can
do
that
through.
We
have
two
ways
of
doing
it.
We
have
the
ansible
just
standard
ansible
way
of
you
can
go
into
the
ansible
directory.
A
If
I
go
down
here
like
I
was,
you
can
do
ansible
playbook
point
to
your
imagery
file.
So
because
we
have
two
environments,
we
would
have
our
primary
and
our
secondary,
so
we
would
have
to
run
this
command
twice,
but
because
the
two
environments
are
completely
separate,
you
can
run
them
both
at
the
exact
same
time,
you
haven't
got
to
wait
for
one
to
finish
before
the
other,
so
you
can
spin
up
both
the
primary
and
the
secondary.
A
At
the
same
point,
we
also
have
a
an
sport
deployer,
it's
a
simple
ruby
script
and
like
say
when
you
create
these
environments
from
scratch,
with
the
all
command,
it
does
everything
sequentially.
So
it
can
take
about
45
minutes,
maybe
longer
if
your
networking's
a
bit
slow,
all
the
deployer
script
does
is
run
them
in
parallel.
So
it's
not
it's
just
running
the
ansible
commands,
but
it's
running
multiple
at
the
same
time,
and
the
main
benefit
of
that
is
that
it
takes
a
lot
less
time.
A
A
After
the
other,
so
when
you're
running
this,
that's
just
one
of
those
options,
you've
got,
you
can
just
run
the
all
and
let
it
go
or
you
can
use
the
parallel
to
to
do
it
and
with
the
parallel
it
will
it
just
prints
out
the
time,
and
then
it
puts
everything
into
this
logs
structure,
which
is
what
I've
been
using
here,
because
it's
quite
useful
with
with
the
all
you
can
often
lose
it
to
the
console
history.
So
it's
quite
useful
just
to
have
this
log
structure
as
well.
A
A
A
We
have
our
gitlab
geo
role,
which
is
this
is
a
completely
separate
playbook
and
it's
for
the
point
of
like
say
you
have
two
working
environments
and
you
do
this
afterwards.
That's
why
it's
not
done
as
part
of
the
all.
We
don't
treat
it
as
the
same.
It's
something
that
you
do
to
your
environment
after
the
fact.
After
it's
already
done
and
it's
working
and
this
the
aim
of
this
was
to
follow
the
documentation
as
best
as
it
could
so
naming
structure
and
everything
that
I've
used
is
trying
to
follow
these
this
documentation.
A
So
we
have
all
the
templates.
So
this
is
where
the
config
is
gonna
go,
so
we
have
primary
database
config,
the
read
only
replica,
so
all
of
these
are
just
they.
They
pretty
much
should
match
titles
that
we
use
within
the
documentation,
so
it
should
be
quite
easy
to
match
up
with
the
documentation
if
you
were
following
this
through
and
it's
the
same
for
our
tasks
folder,
we
have
our
our
main
file
this.
A
A
Again.
Here
we
have
postgres
for
the
geoprimary
site
and
this
one's
a
bit
more
complicated
in
that
we
have,
if
you're
doing
a
single
node,
where
you
don't
have
a
postgres
box,
then
that's
saying
if
you
don't
have
a
primary
site.
Postgres
then
put
it
on
to
get
lab
rails.
So
this
is
how
we
kind
of
configure
up
where
our
config
libs
and
for
the
most
part
for
the
rep
manager.
It's
very
much
just
we
go
through
this.
We
use
everything
as
documentated
and
it's
great
for
petroni.
A
We
have
a
few
workarounds
in
there
and
the
importance
of
these
workarounds
is
we.
We
put
these
things
in
as
workarounds
at
the
moment,
because
we
can't
really
say
that
you
can't
build
a
petroleum
environment
and
test
it,
because
it's
not
finished
it
kind
of
defeats
the
purpose,
so
we
put
these
workarounds
in,
but
we
want
to
make
sure
that
we
have
issues
raised
that
point
out,
that
this
isn't
ideal
and
this
needs
fixing.
A
So
what
we
do
here
is
we
delete
the
postgres
data
we
remove
petroni
from
its
own
cluster
and
then
we
do
a
reconfigure
and
start
it
up
again
and
that
kind
of
that
kind
of
makes
it
thinks
it's
new
and
it
joins
the
cluster.
Quite
happily,
but
we
have
an
issue
raised
to
say.
Obviously
this
isn't
how
we
want
this
to
go.
A
This
command
specifically
as
well,
is
obviously
quite
bad,
so
we're
using
the
petroni
command
line
directly
and
through
ansible.
We
have
this
expect
command.
This
command
has
no
force,
so
we
have
to
tell
it
that
wait
for
this
to
appear
on
the
command
line
and
respond
with
this
answer
then
wait
for
this
and
respond.
A
So
it's
a
very
brittle
or
process
of
automation
of
saying
we
actually
have
to
wait
for
a
response
so
that
we
can
then
fill
it
in.
Thankfully,
there's
you
know
modules
that
do
this
for
us,
but
this
is
kind
of
part
of
the
point
of
what
we
highlighted
as
saying
this
needs.
You
know
we
should
handle
this.
We
should
handle
within
get
lab
removing
from
the
cluster
and
just
joining
it
as
part
of
a
standard
reconfigure
or
whatever
it
may
be
so
yeah.
A
A
So
yeah,
like
the
main
thing
and
that's
kind
of
it's
the
good
thing
about
getting
these
things
into
the
the
toolkit,
because
it
allows
us
to
highlight
what
isn't
an
ideal
process
if
we
can't
easily
automate
it,
it's
not
easy
for
a
customer
to
do,
and
so
yeah
that's
really
not
ideal.
Now
the
aim
was
to
obviously
show
you
the
working
environment
which,
unfortunately,
I
won't
be
able
to
do.
But
what
I
will
do
is
I'll
spin
up
I'll
work
out.
A
A
We
at
the
moment
we
just
stitch.
You
know
we
just
put
a
10k
and
a
3k
together
we
might
be
wasting
resources
on
the
secondary,
because
it's
not
doing
everything
that
a
normal
3k
would
so
we
might
be
able
to
actually
say
a
more
reference
like
geo
environment,
so
those
are
kind
of
some
of
the
things
that
we
want
to
do
with
this
in
the
future.
A
A
D
Awesome
yeah
thanks
so
much
for
the
overview
yeah
I'd
like
to
keep
following
up
with
with
more
demos,
as
as
changes
keep
coming
into
to
the
get.
So
I
think
this
is
yeah
the
start
of
hopefully
a
series,
and
I
thought
it
was
a
great
overview
so
really
appreciate
it
and
just
say
yeah.
We
have
a
channel
in
slack
right.
If
folks
have
more
questions,
I
think
get
lab
environment
get
lab
underscore
environment
underscore
toolkit
is
that
right.