►
Description
If you've been to the GitLab installation page, you find yourself awash in a dizzing array of options. That's because, unlike competitors, we don't limit you in how you deploy GitLab.
However, it also raises a few questions about best practices when picking a method. Join Darwin (DarwinJS) in some perspectives on how to ensure you choose well for a production-grade implementation.
A
Hello:
everyone,
my
name
is
Darwin
I'm,
a
senior
solutions
architect
here
at
gitlab
and
today,
I
want
to
walk
you
through
which
of
the
many
gitlab
installation
methods.
Should
you
use
now
just
a
quick
peek
at
what
our
gitlab
installation
methods
are.
There
are
many
and
that's
why
we
want
to
kind
of
take
you
through
this.
We
have
various
different
Linux
distros
that
you
can
deploy
on
even
raspberry
pi
we
deploy
on
kubernetes
and
that's
one
of
the
biggest
differentiators.
We
can
support
to
all
the
major
clouds
support
docker
directly.
A
If
you
want
to
get
nitty
gritty,
you
can
install
from
source
and
then
the
community
has
a
bunch
of
ways
that
they
have
prepared
gitlab
that
we
also
point
you
to
if
those
are
the
kind
of
installation
methods
that
you
would
need
to
employ.
Well
take
a
little
minute
to
talk
about.
Why
I,
like
this
topic,
so
before
I
came
to
get
lab.
A
We
also
wanted
it
to
be
production
grade
and
that
drove
a
few
things.
For
instance,
in
order
for
gitlab
to
be
taken
as
a
serious
production
grade
service
that
they
can
rely
on,
they
would
need
to
be
itself
capable
of
supporting
what
the
customers
were
requesting
of
those
stacks.
So
if
those
SAS
stacks
were
five
nines,
then
the
tooling
required
to
patch
them
upgrade
them.
Deploy
them
needed
to
also
support
that
level
of
reliability.
So
in
that
regard,
we
built
it
on
AWS
ECS
as
a
docker
cluster,
with
RDS
and
elastic
cache
and
cloud
front.
A
As
far
as
platform
as-a-service
services,
we
also
updated,
get
lab
every
month,
so
we
didn't
want
to
fall
behind
on
the
value.
That's
in
that
get
lab
continuous
release
system.
In
addition,
we
ran
all
upgrades
through
an
integration
environment
before
they
hit
the
production
environment,
so
we
could
see,
observe
and
understand
what
was
expected
to
happen.
And
finally,
we
had
a
DevOps
procedure
in
order
to
understand
when
to
adopt
I
get
lab
release,
so
we
wouldn't
simply
grab
the
release.
It
was
two
months
older
or
two
months
newer
than
us,
or
a
month
newer.
A
We
would
actually
decide
which
specific
release
to
calibrate
whether
we
wanted
to
skip
one
or
drop
back
or
move
forward,
based
on
an
analysis
procedure
of
all
the
gate
lab
metadata
about
releases.
That's
up
on
the
website,
so
I
like
this
topic,
because
I've
dug
into
it
pretty
deeply
in
a
production
situation
and
I
want
to
give
you
some
advice
that
stems
from
that
experience.
So,
as
we
mature
our
DevOps
tooling
a
lot
of
times,
we
have
customers
come
to
get
lab
and
they
have
a
situation.
A
That's
very
unsustainable
in
terms
of
the
diversity
of
tooling
that's
been
knitted
together
now.
One
of
the
big
problems
here
is,
of
course,
user
experience
users
moving
between
these
systems,
all
the
user
administration
has
to
deal
with
all
of
these
systems
independently
users
have
a
multiple
user,
IDs
everywhere,
so
there's
some
degraded
user
experience
and
knitting
too
many
things
together
and
then
there's
also
a
service
management
so
making
each
one
of
these
hae
and
capable
of
sustaining
an
H,
a
type
of
setup
is
challenging.
A
It's
really
hard
to
get
that
right
in
terms
of
service
management,
as
you
move
forward
to
consolidate
some
of
these
platforms
into
get
lab
as
a
single
solution
for
more
and
more
of
your
tool
chain,
it
feels
really
good
to
solve
that
user
experience
problem.
So
now
users
are
much
more
comfortable
in
the
system.
A
It
really
matters
how
you
implement
gitlab
in
order
to
get
a
production
grade
experience,
so
you've
got
to
know
what
you're
building
from
the
get-go
and
I'd
like
to
draw
a
little
contrast
here:
production
grade
tooling
versus
toys
and
what
it
comes
down
to
is
tooling
selections
really
important,
but
for
tools
versus
the
devil
is
in
the
service
management.
Details
now
think
of
the
go-to
joke
in
this
area.
You
know
someone
says:
hey:
we
got
new
CI
going,
it's
rockin
the
world,
it's
pushing
stuff
to
all
of
our
clouds
and
you're
like
awesome.
A
Where
did
they
implement
that?
Well,
it's
under
Larry's
desk
over
there
on
an
old
386
machine
that
was
left
lying
around
from
20
years
ago,
and
everyone
has
a
chuckle.
So
you
can
see
that
even
when
you
move
your
tooling
safe
from
that
bad
of
a
situation
into
the
cloud
that
alone
isn't
enough
to
really
make
it
a
production
grade
service
and
one
of
the
most
significant
aspects
of
service
management
is
how
gitlab
itself
is
deployed,
and
so
we're
going
to
dig
into
this
a
little
bit
deeper.
A
So,
on
the
service
management
front,
we
have
permissions
management,
very
important,
effective
operations.
Troubleshooting
a
problem
resolution
is
really
important,
so,
although
it
would
be
great
if
you
stood
up,
get
lab
and
never
needed
anything
for
the
next
20
years,
that
would
be
great,
but
at
times
problems
do
happen,
and
so,
when
they
do
happen,
you
need
the
skill
set
to
dig
in
and
try
to
find
your
way
around
on
those
infrastructure
technologies
that
you've
deployed
get
lab
to.
A
You
also
want
to
be
doing
those
regular
upgrades
to
keep
those
feature
sets
flowing
in
from
the
get
labs
release
cycle.
You
also
want
to
build
a
continuous
continuously
suit,
your
need
for
operations
killing.
So
if
you
have
shifts
and
team
members,
you
want
to
make
sure
that
the
skill
set
that
they
need
is
something
that's
readily
available
to
you.
You
also
want
to
consider
that
you
may
have
taken
on
more
of
the
DevOps
tool
chain
and
therefore
more
need
for
production
grade.
A
So
if
you
didn't
use
get
lab
before
for
deployment,
but
now
you
are
using
it
for
deployment
as
you
move
to
a
production
grade
scenario,
your
hours
of
availability
expand.
So
it's
important
to
understand
that
there's
be
more
pressure
on
having
it
up
and
available
more
of
the
time
and
then,
if
you
go
all
the
way
to
feature
Flags,
this
actually
has
customer
interacting.
A
You
know
your
customer
applications
are
actually
interacting
with
get
lab
for
some
configuration
information,
and
so
that's
another
thing
that
can
broaden
your
availability
and
reliability
requirements
even
farther
so
keys
to
service
management
or
kind
of
the
sre
perspective.
You
can
start
with
gitlab
as
a
single
virtual
instance.
That's
one
way
to
deploy
it,
it's
very
efficient
this
way
and
it
can
service
a
significant
number
of
users.
You
can
then
also
do
something
like
a
cloud
deployment
which
is
going
to
require
that
you
have
those
cloud
skills
and
appropriate
accounts
and
information.
A
Then
high
availability
implementations
are
probably
the
next
level
of
sophistication
and
finally,
at
the
top
of
the
heap,
we
have
the
ability
to
deploy
on
to
kubernetes.
Now,
underlying
all
these
installation
methods,
including
the
ones
we
saw
on
the
webpage,
that
I,
was
showing,
you
are
two
main
installation
methods.
One
is
what
we
call
omnibus,
which
is
the
main
way
of
installing
gitlab,
is
kind
of
you
know
you,
you
run
it
and
install
it
or
if
you
grab
our
containers,
we
have
an
omnibus
install
inside
of
there
when
you
configure
with
git
lab
dot.
A
Rb,
that's
our
omnibus
installed,
and
so
it
covers
most
everything
in
this
stack
and
then
the
kubernetes
method,
of
course
covers
some
overlapping
areas
and
into
kubernetes
itself.
So
kubernetes
takes
over
some
of
the
high
availability
and
scalability
aspects.
When
you
deploy
that
way
and
then,
if
you
deploy
omnibus,
we
have
published
patterns
of
how
to
get
high
availability
built
in
so
one
of
the
things.
A
As
you
look
at
this
stack
as
we
go
up,
the
stack
will
find
that
certain
things
start
to
increase
or
get
bigger,
and
one
of
them
is
the
smallest,
sufficient
scaling.
So
the
single
virtual
machine
instance
we
can
use
one
virtual
machine.
We
can
even
have
the
storage
on
there
make
sure
we
have
rock-solid
backup
and
we
have
a
pretty
minimal
footprint
as
we
move
up.
However,
that
can
start
to
grow.
A
So
as
soon
as
you
go
into
high
availability,
implementation,
you're,
looking
at
several
more
instances
and
kubernetes
itself
is
going
to
have
a
minimum
number
of
instances
that
are
suggested
so
for
kubernetes.
You
probably
want
to
have
a
minimum
of
three
instances,
so
the
smallest
possible
scaling
of
computing
cost
is
growing
as
we
move
up
the
stack.
A
Minimum
costs
tends
to
go
up
minimum
operational
complexity.
So
what
does
it
take
to
start
and
stop?
The
stack
upgrade
the
stack
and
minimum
recovery
complexity.
So,
as
you
go
up,
this
stack.
Your
recovery
complexity
can
go
up
as
well,
depending
on
how
you
choose,
make
your
choice,
choices
in
terms
of
storage.
So
when
we
take
a
continuous
service
management
approach,
we
want
to
kind
of
take
off
our
shiny
new
things.
Hat
all
of
us
love
new
tools.
We
love
to
look
at
new
ways
of
doing
things.
A
I
mean
that's,
usually
one
of
the
reasons
people
are
in
IT
or
software,
and
we
want
to
move
to
a
continuous
service
management
hat
and
so,
instead
of
thinking
of
the
latest
or
the
most
interesting
or
the
funnest,
we
try
to
think
of
right.
So
right
scaling.
What
is
the
level
of
scaling
that
should
be
pursued
for
your
organization
right
skilling?
A
We
have
pattern
for
scalability
and
the
answer
is
a
single
virtual
instance
can
do
thousand
users,
and
so
some
people
are
surprised
by
that
some
of
our
competitors.
Actually
we
have
people
come
to
us
from
competitors
because
we
can
horizontally
scale.
We
have
patterns
published
for
up
to
50,000
instances
of
it.
Sometimes
if
your
needs
are
less
than
that,
you
can
lose
sight
of
the
fact
that
there
are
costs
in
having
that
level
of
scalability
at
the
ready
at
your
fingertips.
A
All
of
these
things,
when
we
embrace
not
the
bleeding
edge
technology
for
our
teams
go
easier
and
go
better,
and
then
we
can
skill
up
on
some
of
those
things
that
are
really
interesting,
intriguing
and,
as
you
become
more
mainstreamed
in
the
market,
we
can
dig
in
and
embrace
those.
So
I'd
encourage
you
to
think
about
that
concept
of
boring
technology.
You
can
actually
google
it
on
our
website
and
find
it
in
our
handbook
kind
of
what
we
try
to
do
with
our
technology
stacks
not
regard.
A
A
While
we're
talking
I
want
to
bust
a
few
gitlab
installation
myths
so
as
I
interact
with
customers,
people
come
in
and
they
have
certain
impressions,
and
while
the
impressions
are
understandable,
they
may
not
realize
the
flexibility
that's
available
in
the
platform.
So
they
make
some
assumptions
about
what
can't
what
they
have
to
do
to
get
certain
benefits.
So
one
of
those
is
sometimes
folks
think
that
when
they
use
gitlab
sass
that
they
can
only
use
runners
that
are
also
SAS
or
hosted
by
kit
lab.
A
But
in
fact
you
can
take
and
deploy
your
own
runners
on
premise
in
your
own
data
centers
and
wherever
you
want
in
many
different
places.
If
you
want,
while
using
gitlab
SAS
so
make
sure
you're,
not
thinking
that
you
have
to
move
to
self-hosted
gitlab
in
order
to
take
advantage
of
health
self-hosted
runner,
you
also
don't
need
to
have
gitlab
running
on
kubernetes,
to
integrate
with
kubernetes
and
have
scaleable
kubernetes
runners.
So
any
gitlab
instance,
no
matter
how
it
is
deployed,
can
interface
with
the
cluster
and
can
even
put
runners
there.
A
So
just
keep
that
flexibility
in
mind
when
thinking
about
how
to
deploy.
Also,
another
thing
that
can
be
a
challenge
is
when
you're
looking
at
get
lab
and
you're
saying
man.
We
really
think
this
platform
can
do
what
we
want,
but
we
want
to
put
together
a
proof
that
we
can
do
it
and
some
companies
that
come
to
us
end
up
wanting
to
do
a
full-on
self
hosted
implementation,
that's
ready
to
scale
just
to
get
their
proof-of-concept
started,
but
there's
really
very
few
things
that
are
different
for
gitlab
comm
versus
a
self
hosted
instance.
A
So
one
way
to
break
some
of
the
schedule
pressure
here
is
to
break
that
out
and
have
it
so
that
that
proof
of
concept
goes
on
and
get
lab
comm.
Well,
you
in
parallel
handle
your
self
hosted
implementation
details
and
how
that
might
need
to
look
for
you.
One
of
the
detail.
That's
really
important
is
we
do
not
have
a
migration
path
from
kubernetes
back
to
the
omnibus
installer.
We
do
have
a
migration
path
from
omnibus
forward
to
kubernetes.
A
So
if
you're
at
a
place
with
your
kubernetes
skilling-
and
we
talked
about
kubernetes
killing,
you
really
want
to
think
in
terms
of
the
folks
who
operate
this.
So
if
this
is
your
team,
where
are
you
with
kubernetes
operations?
If
this
is
a
another
team,
some
organizations
are
so
big
that
operationalize
technology
gets
run
by
an
operation,
specific
team
where's
that
team
with
kubernetes
so
with
git
lab.
A
If
you
deploy
an
omnibus,
we
have
a
way
to
bring
you
forward
to
kubernetes
when
your
readiness,
your
operational
readiness,
is
and
ready
for
handling
kubernetes,
but
we,
if
you
start
in
kubernetes,
there's
not
a
way
to
go.
You
know
what
I
don't
like
this
I'd
like
to
go
back
to
omnibus.
So
just
keep
that
in
mind.
You
also
want
to
right-size
your
implementation
needs
according
to
how
many
users
you
have
so.
This
shows
that
up
to
a
thousand
users
are
easily
accommodated
by
an
8v
CPU
system
with
about
30
gigs
of
memory.
A
We
also
have
many
very
broadly
scaled
implementations,
where
there
are
many
many
different
instances
servicing
differently
of
the
app
the
technology
and
will
actually
show
you
in
a
final
slide,
the
link
to
that
and
let's
focus
a
little
bit
on
some
omnibus
verses,
kubernetes
decisions
questions.
So
these
are
just
kind
of
like
some
questions
to
ask
yourself
about
this
important
part.
A
Enablement
team
is
a
team
that
actually
is
in
charge
of
providing
developer.
Tooling.
You
are
a
tools,
engineer
or
a
team
of
tools,
engineers.
Then
service
management
is
even
more
critical,
especially
if
people
are
voluntarily
coming
to
the
platform,
but
even
if
they
aren't,
they
want
to
know
that
what
you're
building
for
them
is
well
service
managed.
A
Is
the
team
who's
going
to
support,
get
lab
mature
and
their
kubernetes
operation
knowledge
one
way
to
judge
that
is:
do
they
already
have
at
least
one
community
stack
running
in
production
or
production
eyes
door
they're
having
to
understand
you
know
what
can
go
wrong
and
how
to
fix
problems
quickly,
how
to
fix
deployment
problems?
Are
you
embracing
the
boring
technology
concept
to
maintain
a
production
grade
focus,
so
this
is
kind
of
like
a
JAL's
de-risk
by
repeating
risky
things.
A
This
is
another
one
of
those
kind
of
top
level
principles
that
can
help
guide
your
whole
focus
so
embracing
boring
technology.
And
then
what
are
your
practical?
Day-To-Day
scalability
needs?
You
might
be
building
gitlab
for
software
development
teams
that
are
building
software
on
it
for
applications
that
just
need
to
scale
ridiculously
and
that's
great.
We
love
it
that
the
platform
can
can
help
you
build
that.
A
But
what
are
the
actual
needs
of
the
gitlab
platform
itself
to
scale
it's
best
if
you
target
those
needs
when
deciding
how
to
build
out,
so
my
role
is
a
Solutions
Architect
at
gitlab,
I
really
enjoy
it,
because
I
get
to
help.
Customers
figure
out.
Questions
like
these,
and
so
I
wanted
to
just
give
you
a
few
links
here.
The
installation
methods
are
all
at
this
URL
the
reference
architectures
which
go
all
the
way
up
to
50,000
users
are
at
this
URL.
A
If
you
want
to
engage
with
our
pre-sales
organization,
you
can
get
the
help
of
a
Solutions
Architect,
to
give
you
some
general
guidance,
some
validation
of
your
implementation
plans
and
to
give
some
top-level
guidance
on
that.
But
you
should
also
be
aware
that
we
have
a
full
detailed
design
and
turnkey
deployment
professional
services
that
allows
you
to
get
together
express
your
objectives.
As
far
as
how
you
want
this
service
to
work.
A
Professional
services
will
work
with
you
to
come
up
with
a
design
that
works
best
for
you,
cost-wise
operationally
and
then
actually
deploy
it
to
you'd
hand
you
the
keys,
and
so
this
is
a
really
popular
option.
A
lot
of
teams
right
now
are
struggling
with
the.
They
would
love
to
step
up
to
some
tooling
like
this,
but
they
don't
actually
have
time
to
learn
all
the
gitlab
nuances
of
how
to
deploy
it
in
a
reliable
scenario,
so
that
it's
production
ready
and
whenever
you
stand
up
a
service
yourself.
A
There's
a
lot
of
learning
around
that
and
then
design
and
then
validation.
So
it's
nice
just
to
have
those
kind
of
things
done
for
you.
So
if
you
need
to
reach
out
to
solutions,
architects
or
professional
services,
we're
happy
to
help.
You
I
hope
that
this
information
does
give
you
some
initial
guidelines.
If
you're
going
to
tackle
this
yourself
thanks
a
lot
for
listening,
we
hope
to
see
you
out
there
doing
more
gitlab.