►
From YouTube: 2020-03-25: Gitaly speed run
Description
A quick intro to Gitaly, and speed run through setting up Gitaly HA.
A
Hi
I'm
James
Ramsay
group
product
manager,
here
at
gate,
lab
for
the
create
stage
of
the
DevOps
life
cycle,
and
this
is
a
speed
run
through
Gilly
and
for
those
of
you
who
are
not
familiar
with
Gilly
Gilly
is
a
component
of
the
application
and
it's
how
we
store
git
repositories.
So
to
be
more
precise,
this
is
a
diagram
which
shows
how
different
good
connections
can
come
into
the
lab
application
and
they
can
come
through
the
rails
application.
A
A
The
other
ways
that
you
might
be
interacting
with
get
early
through
the
get
lab
application
is
via
get
lab
work
horse
and
get
left
shell.
These
are
two
specific
services
which
allow
HTTP
and
SSH
connections
to
be
terminated,
and
then
the
git
protocol
is
then
passed
on
to
get
early
and
so
that
you
can
get
the
data
you
want.
A
A
For
users
of
gitlab,
you
don't
really
have
to
worry
about
giddily
and
it's
behind
the
scenes.
There's
no
interface,
that
exposes
it
directly,
there's
nothing
to
manage
or
configure.
So
this
is
really
a
piece
of
the
architecture
of
gitlab.
That's
important
to
operators
of
duplicate
web
applications,
people
who
are
installing
gitlab
on
their
own
servers
or
managing
an
existing
installation
of
gitlab
and
need
to
scale
it
and
expand
it,
and
so
one
of
the
the
particular
features
of
giddily
is
that
it
allows
you
to
scale
your
github
instance
and
what
I
mean
by
that
is.
A
If
you've
got
so
many
users
that
you
can't
fit
it
all
on
one
server.
Giddily
allows
you
to
move
the
git
storage
component
onto
a
different
box,
and
that
is
useful
in
a
couple
of
different
ways.
Firstly,
you
can
add
multiple
applications
if
you've
got
lots
and
lots
of
web
interface,
traffic
and
multiple
application
services,
and
they
can
all
talk
to
one
dedicated
get
early
node.
The
other
situation
might
be
you've
got
so
many
git
repositories
and
so
much
traffic.
A
So,
let's
walk
through
that
a
little
bit
later,
and
so,
let's,
let's
take
a
little
look
at
a
brand-new
lab
installation
and
take
a
look
at
what
get
early
is
doing
out
of
the
box.
So
we've
got
a
couple
of
projects
here:
I'm
gonna,
look
at
the
admin
area,
so
only
administrators
have
access
to
this,
and
if
we
go
to
the
list
of
projects,
let's
take
a
look
at
this
git
project.
A
You'll
see
that
the
Ghibli
storage
name
is
default.
So
when
you
install
gitlab
out
of
the
box,
diddly
is
going
to
be
running
on
the
same
server
as
the
application
zip
and
if
I
switch
over
and
I
go,
get
CTL
tale.
Italy,
we
can
see
the
logs
coming
through
from
giddily,
so
give
these
running.
We
can
see
that
it's
a
listing
last
commits
doing
all
sorts
of
operations,
and
you
can
also
see
the
storage
part.
A
Where
the
repository
is
located
on
disk,
so
gillies
running
on
every
single
gate
lab
server
for
quite
a
long
time,
so
it's
probably
running
on
your
server.
Unless
you
have
an
update
in
two
or
three
years
so
yeah,
that's
essentially
all
you
would
need
to
do
if
you
go
to
settings
repository.
These
are
some
more
detailed.
Administrative
settings
and
storage
is
the
relevant
one
here
and
you'll
see
that
we've
only
got
one
storage
now.
A
So
that
means
that
all
new
projects
that
are
created
are
going
to
be
stored
on
that
giddily
storage
location,
which
happens
to
be
on
the
same
servers.
The
application
server,
so
I'm
gonna
walk
through
now
the
configuration
of
multiple
get
early
nodes
and
a
prefetch
node,
which
together
will
allow
us
to
have
another
storage
location
that
is
highly
available
and
stored
across
a
bunch
of
other
sets.
So
let's
take
a
look
at
that,
so
this
is
the
documentation
for
Prefect,
which
is
how
a
component
that
we've
added
to
achieve
get
early
high
availability.
A
A
So
what
we're
going
to
aim
for
is
to
connect
to
this
proxy
router,
which
is
going
to
control
the
requests
and
route
them
to
the
correct,
replicas
or
and
keep
track
of
which
ones
master
in
which
ones
secondary,
so
that
if
one
of
them
goes
down,
you
can
quickly
flip
over
to
the
other
one.
That's
what
the
prefect
component
does
and
then
we'll
have
three
diddley
nodes
in
our
cluster,
so
that
if
one
or
two
of
them
go
down,
there's
still
one
left
and
that
can
service
requests.
So,
let's
get
into
configuration.
A
This
is
my
get
lab
server
and
I've
also
configured
a
couple
of
other
servers,
so
I've
got
a
prefect
node
and
three
killing
nodes.
I
really,
ultimately,
I
should
have
more
than
that,
but
I
should
probably
have
multiple
prefect
nodes.
So
prefect
isn't
a
single
point
of
failure,
but
I'll
probably
do
that.
Maybe
next
time
I
record
one
of
these
videos.
So
let's
jump
over
the
docs
got
some
preparation
information.
A
Okay,
so
we've
reconnected.
Now
we
just
need
to
create
the
database
excellent,
that's
done
so.
We
create
the
user
first
and
then
the
user
creates
the
database.
That
means
that
we
know
that
the
user
has
permissions
to
the
database
that
just
created
if
we
created
database
and
then
granted
permissions
it'd
have
to
be
a
little
bit
more
complicated
in
the
docs.
But
you
could
do
that
all
right
now.
We
need
to
finish
configuring,
the
prefect
node.
So
this
is
our
proxy
router.
A
B
A
A
B
A
A
This
okay,
so
this
is
creating
a
virtual
storage
location,
called
Prefect,
which
is
contained
made
up
of
three
physical
storage
locations,
so
Ginley
1,
2,
&,
3,
2,
&
3
will
initially
be
replicas
of
ghibli
one,
but
once
we
start
running
this
and
can
enable
automatic,
failover
and
primary
will
move
around
as
loads
fail
to
automatically
keep
everything
running.
Just
fine,
so
I
need
to
copy
and
paste
a
bunch
of
IP
addresses
not
make
any
typos.
A
B
B
B
A
A
Okay,
complete,
so,
let's
check
that
we
can
reach
the
SQL
database
and
everything
looks
good
onward
to
the
next
step.
So
we
need
to
do
this,
each
for
each
giggly,
node
and
actually
the
configuration
of
all
three
giddily
nodes
can
be
identical.
So
it's
once
you
get
the
config
right,
it's
just
a
copy
and
paste
drop.
It
also
makes
it
easy
to
automate
and
if
you're,
treating
or
giddily
notes
like
cattle
and
you're,
just
bringing
them
up
with
some
automation
script.
A
B
A
Right
now
we
able
listen
addresses
as
well,
so
that
we
can
accept
connections
and
talk.
Prometheus
metrics
can
be
collected.
Here's
our
secure
authentication
token
for
inside
the
cluster.
You
can
have
a
different
token
for
talking
between
prefix,
sorry,
the
the
cluster
and
the
application,
but
internally
in
the
cluster,
you
need
to
use
the
same
chocolate
and
then
secret
tokens
server
URL.
A
So
when
write
operations
come
in
to
get
early
nodes,
we
call
back
to
the
rails
application
to
do
different
kinds
of
checks
like
check
permissions
check
for
fire
locks,
other
kinds
of
information
so
because
git
will
receive
the
operation
from
whoever's
making
it
and
then
we
can
unpack
it
and
look
inside
of
what
they're
trying
to
do
to
the
repo
and
then
make
the
appropriate
checks
with
the
application
to
see.
If
that
is
permitted,
and
so
I
need
to.
A
This
server
is
giddily
one.
So
technically
we
only
need
to
get
Li
one
path,
and
this
is
the
same
path
on
each
server,
because
each
server
is
going
to
be
configured
identically.
So
this
server,
the
router,
will
only
route
requests
to
get
early
one
to
the
get
early.
One
server
has
configured
in
the
IP
address
that
we
configured
in
prefix,
so
we
can
actually
safely
put
all
the
data
terms
for
all
the
get
early
nodes
in
the
same
configuration
on
every
single
get
early
note.
That
makes
it
really
easy
to
just
copy
and
paste.
A
A
A
A
B
A
B
A
B
A
A
And
we'll
also
need
to
then
verify
that
we
can
reach
the
prefect
no-till.
We
added
so
prefect
simply
looks
like
a
giddily
node,
and
so
it's
like
quite
invisible.
It
implements
the
exact
same
interfaces
giddily.
So
that's
why
we
can
just
drop
the
prefect
cluster
and
as
a
replacement
for
a
giggly
node,
because
they
implement
all
the
same
features.
A
A
A
We
do
cache
this
information
because
we
don't
want
have
to
be
like
checking
storage
information
with
every
single
repo
call
like
every
time
you
create
a
new
repo.
We
want
to
be
able
to
just
say:
okay,
here's
the
location
to
store
it.
That
does
mean
these
settings.
Sometimes
tape
I
think
they
take
that
60
seconds
to
propagate
while
we're
doing
that
waiting,
let's
jump
ahead
to
enable
failover.
So
let's
take
a
look
at
this,
these
Doc's
have
changed
since
I
last
looked
at
them.
B
A
B
A
A
A
Meanwhile,
should
have
had
some
success
here,
excellent
so
and
we
can
see
the
prefect
storage
location.
So,
let's,
let's
set
that
as
the
new
default
and
save
that
change
and
then
the
other
thing
we
can
do
is
we
can
take
existing
repositories
and
move
them.
So
let's
move
one
of
these
repositories
to
this
new
prefix
and
the
way
to
do
that
is
through
the
tops.
B
B
B
B
B
B
A
B
B
B
B
A
A
A
A
A
A
B
A
A
I
do
it
we
are
going
to
edit
it
well,
let's,
let's
actually
first
flip
over
and
see
the
activity
coming
through
on
the
precinct
notes.
So
remember
how
I
was
tailing
these
logs
right.
We
can
see.
These
are
just
health
checks,
but
we
should
actually
see
more
activity
come
through
on
this
primary
one,
because
all
the
read
requests
are
being
served
by
the
primary.
So
if
I
was
to
edit
this
file
you'll
see
that
we're
generating
all
this
traffic.
A
B
A
A
Now
ask
anything
the
logs
we
can
see
some
health
checks
are
failing.
So
that
means
that
prefix,
detecting
this
note
is
down
and
will
mean
it's
now
promoting
a
different
o2
primary.
If
I
make
you
go
and
refresh.
Hopefully
we
should
see
an
inversion
here.
Excellent,
so
giddily
too
has
now
been
promoted
to
primary,
which
means,
if
I
reload,
this
page
it's
working,
and
we
can
see
that
now
giddily
is
actually
generating
all
the
traffic.
So
if
we
added
this
we're
seeing
now
that
traffic
flow
through
there.
A
A
default
installation
which
had
giddily
running
on
the
same
server
with
everything
we
split
out
giddily
on
to
its
own
cluster,
so
we
actually
had
three
get
alleys
and
so
there's
redundancy
and
we
also
configured
the
prefect
proxy
router
that
handles
and
manages
the
failover
between
replicas
and
we
implement
configured
the
SQL
database.
So
that's
a
quick
run
through
of
giddily
and
I.
Guess
the
core
feature
of
Ginley,
which
is
allowing
you
to
split
out
the
configuration
and
scale
it
to
meet
your
needs.
And
if
you
have
any
questions,
get
in
touch.