►
From YouTube: GitLab Runner Deep Dive
Description
Brendan O'Leary talks about GitLab Runners and provides a technical deep dive. The presentation covers:
an overview of runners
Runner Architecture
Platforms & Executors
Autoscaling Runners for Fun & Profit
Security Considerations
Installation & Advanced Configuration
B
C
B
So
first,
let's
just
talk
a
little
bit
about
the
agenda.
We'll
do
a
quick
overview
for
anybody
that
might
not
be
very
familiar
with
gitlab
runners
and
how
they
interact
with
gitlab
ci
cd
and
then
we'll
go
through
the
architecture
of
how
runners
interact
with
the
gitlab
server,
we'll
talk
about
different
platforms
and
executors
for
the
runner
we'll
go
to
auto
scanning
and
how
that
works.
B
B
D
B
The
closest
thing,
although
I
hesitate
to
even
say
it
because
it's
a
bad
comparison,
but
the
closest
thing
would
be
slaves
in
jenkins
in
the
jenkins
world.
But
I
I
wouldn't
recommend
making
that
comparison,
because
once
people
start
thinking
that
way,
they
they
lose
a
lot
of
the
things
that
differentiates
from
jenkins.
B
So,
first,
let's
do
a
little
bit
of
an
overview,
so
this
is
just
kind
of
some
things.
Oh
no,
my
emojis
might
not
work
anyway.
This
is
just
some
ideas
that
are
taken
from
the
render
page
but
they're
important
to
understand
each
of
these.
So
first
off
the
runner
is
a
piece
of
software.
That's
multi-platform,
so
the
runner's
written
in
a
pretty
modern
language
called
go.
That
runs
on
basically
every
platform
out
there,
and
so
you
can
run
the
runner
on
almost
any
platform
that
exists.
B
It's
also
multi-language,
so
it's
agnostic
to
what
programming
language
you're
using
it
doesn't
really
care
about
that.
You
can
just
use
the
runner
for
for
any
language.
It
enables
parallel
builds.
So
this
is
builds,
don't
have
to
happen
in
sequence.
They
don't
happen
in
parallel,
it's
built
from
the
ground
up
for
docker,
so
that
that's
really
helpful
and
something
that
is
unique
about
gitlab
city,
but
our
runner
is
kind
of
built
for
docker,
and
then
one
install
of
the
runner
can
actually
be
many
runners.
B
So
I
can
have
the
runner
installed
on
the
machine
and
have
many
instances
with
different
executors
all
running
on
that
same
single
installation
of
the
runner
software
and
then
there's
a
pooled
model
for
the
job
execution.
So
you
know
basically,
all
of
the
runners
that
I
have
are
in
the
pool
and
then
as
jobs
come
up
for
selection.
B
E
B
Other
questions
before
I
get
dive
deep
into
the
architecture
wait.
So
just
this
picture
is
from
the
website.
It's
like
a
really
simple
view
of
the
architecture,
but
it's
an
important
one
to
understand.
So,
of
course
we
have
the
gitlab
server
right.
That's
that's
gitlab
itself,
and
that
could
be
you
know
one
server
or
that
could
be.
B
And
then
you
can
have
you
know:
zero
to
n
runner
processes
on
other
servers.
So
we
actually
highly
recommend
against
running
the
gitlab
runner
on
the
gitlab.
Server
works
much
better.
If
you
have
a
separate
vm
or
a
separate
server
or
a
separate,
you
know,
even
your
laptop
could
be
a
runner,
and
so
you
can
have
zero
to
end
runners
machines
and
then
zero
to
end
runner
processes
again
on
that
machine,
because
one
install
of
the
runner
can
actually
be
multiple
run.
B
Multiple
copies
of
the
runner
for
different
different
methods
and
and
so
then,
to
dig
into
the
architecture
a
little
bit
more.
There's
there's
three
properties
that
are
important
to
understand
about
the
runner
when
we're
talking
about
what
jobs
are
going
to
run
on
what
run,
and
so
these
are
the
three
properties.
B
So,
first
of
all,
a
shared
runner
is
one
that
can
be
used
by
any
project.
So
this
is
in
a
pool
of
runners
that,
basically,
you
know.
In
most
cases
you
know
the
the
gitlab
admin,
the
devops
team.
The
tools
team
that
owns
gitlab
is
going
to
also
stand
up
some
n
number
of
runners
that
can
be
used
by
any
project.
B
For
that
specific
runners
are
ones
that
are
tied
to
one
or
more
specific
projects,
and
so
then
they're
only
in
the
pool
for
their
projects
that
they're
tied
to-
and
you
can
see
here-
I
differentiate
between
who
manages
them
right.
So
the
gitlab
admin
is
who
manages
shared
runners,
because
they're
only
can
be
managed
through
slash
admin
runners,
where
I
only
get
live
admins
where
specific
owners
can
actually
be
managed
by
whoever
owns
that
runner
right.
So
again,
your
laptop
could
be
a
runner.
B
Obviously,
then,
you
are
the
one
that
can
manage
what
what
that's
doing
and
that's
so
typically
these
are
for
like
specialized
builds.
So,
for
instance,
if
I
need
to
build
an
ios
project,
I'm
going
to
need
an
os
x
runner
in
order
to
to
build
that,
and
so
I
might
have
specific
for
that
or
if
I
have
a
specific
project
that
has
specific
requirements
that
go
beyond
what
I
can
do
with
generic
runners,
I
might
have
a
specialized
runner
for
that
or
specific
runner.
B
B
B
B
So
this
is
useful
again
for
let's
say
you
had
shared
runners,
but
some
had
windows
on
them
or
some
had
os
x
on
them
or
some
had.
You
know
a
bunch
of
ruby
stuff
that
you
needed
installed
by
default,
so
you
don't
have
to
download
it
at
the
time.
This
is
a
way
you
can
tag
runners
and
then
they're
only
going
to
run
jobs
that
share
their
exact
same
tag
or
if
the
job
has
multiple
tags.
B
So
here
we
have
an
example
on
the
left
of
a
at
the
top.
This
win
2012
ec2
runner
is
a
runner
with
windows
on
it
has
been
tagged
with
windows
and
then
it's
the
build
step
we
see
below,
which
is
doing
an
ms
build,
is
only
going
to
run
on
runners
that
I've
tagged
with
windows
and
that's
just
the
tag
I
made
up
and
so
because,
in
order
to
build
this,
I
need
to
be
on
windows.
B
I've
I've
used
these
tags
to
make
sure
that
it
doesn't
try
to
run
that
build
on
some
random
runner
or
shared
runner.
That's
typically
going
to
be
linux
or
might
have
docker,
whereas
on
the
right
we
have
a
runner,
that's
on
tags,
and
then
we
have
a
java
project
that
can
be
has
no
tags
associated
with
the
job
and
thus
could
be
run
on
any
untagged.
One.
B
Yeah
the
inverse
is
true
right,
so
the
runner
must
have
all
the
tags
of
my
job.
Job
does
not
have
to
have
all
the
tags
in
my
runner.
So
if
I,
if
that
runner
was
tagged
with
windows
and
java,
this
job
could
still
be
picked
by
that
runner
perfect.
Thank
you
very
much
yeah,
but
if
I
added
a
tag
to
the
job
of
java-
and
I
didn't
add
that
tag
to
the
runner,
then
that
runner
would
not
would
not
pick
the
job.
B
So
I've
got
a
specific
runner
for
this
project
and
I
want-
and
I've
got
my
deploy
keys
on
there,
and
so
I
only
want
that
to
run
a
master
so
that
those
deployed
keys
can't
be
exposed
to
someone
nefarious.
That's
just
making
a
branch
and
anytime
something
runs
on
it.
I
know
that
it's
on
mass,
or
only
and
and
thus
has
been
reviewed
and
pushed
by
someone
who
has
that
permission.
B
B
It
basically
pauses
them
so,
instead
of
deleting
the
runner,
if
I
need
to
do
some
maintenance
or
something
on
a
specific
number,
I
can
just
deactivate
it
for
now
it
won't
pick
up
any
jobs
until
I
reactivate
it
and
then
there's
also
a
thing
called
lock
to
the
current
project.
So
if
we
remember,
when
I
was
talking
about
specific
runners,
shared
versus
specific
specific
runners,
I
said
are
tied
to
one
or
more
projects.
B
So
it
wouldn't
be
able
to
become
a
shared
runner,
but
it
could
say,
be
used
for
another
project.
Unless
I
lock
it
to
the
current
project,
then
this
runner
can
only
be
used
for
one
project.
This
project
does
that
kind
of
make
sense,
yeah
a
little
bit
more
complex
but
worth
mentioning,
and
then
also
I
skipped
over
untagged
jobs.
So
for
a
runner
with
a
tag
you
could
say,
I
don't
want
this
runner
to
pick
up
any
untagged
jobs,
because
even
if
I
have
a
tag,
I'm
gonna
assume.
Oh
I
can.
B
G
B
D
B
F
Brandon,
I
have
a
question
that
I
don't
know
whether
it
fits
in
here
right
now,
but
about
executing
the
runner
on
the
client
machine
in
the
first
place.
So
my
understanding
is
typically
have
a
runner
install
a
one
runner
installation
on
your
client
computer.
That
might
be
your
local
laptop
and
you
can
choose
whether
you
register
that
runner
as
with
root
privileges
or
without
you,
privileges,
using
pseudo
or
not.
That
obviously
is
going
to
be
a
difference
and
is
there
any
general
recommendations
for
that?
B
Yeah,
so
I
do
talk
about
our
recommendations
I
think
later
on
in
the
security
section,
but
just
generally
to
address
that
now,
as
with
any
linux
process
or
any
process
on
any
computer,
it
runs
as
a
user
right,
so
you're,
either
gonna
run
it
as
root
or
or
run
it
as
your
local
user
and
those
that
has
implications
for
security
and
for,
like
you
said
where
the
tomo
gets
stored,
etc.
So,
but
that's
not
necessarily
a
problem
specific
to
get
lab
runner
right.
B
B
All
right
so
next,
I
kind
of
want
to
talk
about
what
platforms
the
runner
runs
on
and
then
what
executors
they're
running
around.
So
those
are
two
different
things
right.
The
platform
is
the
underlying
os
that
we're
going
to
be
running
on
and
then
the
executor
is
actually
there's
a
number
of
different
ways
that
the
git
lab
runner
can
choose
to
execute
jobs
and
we'll
talk
about
that.
So
first
platforms.
B
Right,
like
it's
available
like
I
said
it's
in,
go
so
it's
available
for
basically
any
platform
that
you
can
name
there's
some
that
don't
support
guild,
but
almost
anything
so
any
distribution
of
linux.
That's
out
there,
including
we
have
packages
for
for
the
big
four
for
your.
You
can
run
on
your
mac.
It
can
run
on
windows,
it
can
run
as
a
docker
service.
B
B
Then
the
executor,
oh,
the
emojis-
did
not
work.
This
was
a
really
cool,
looking
page
until
the
emoji,
so
there's
these
different
kind
of
executions,
and
so
we're
gonna
talk
about
them
in
detail
next
and
we'll
talk
about
the
kind
of
most
common
and
then
the
less
common
ones
as
far
as
what
I've
seen
in
the
market,
but
the
beauty
of
the
gitlab
documentation
is,
as
you
can
see
at
the
bottom
here,
there
is
a
section
of
our
executor.
B
Docs
called.
I
am
not
sure
what
executor
I
want
to
pick
and
that
really
helps
users
make
a
decision
about
what
executor
is
right
for
their
specific
use
case.
So,
first,
let's
talk
about
the
four
most
common,
so
that
would
be
shell,
docker,
docker,
machine
and
kubernetes.
So
shell
is
exactly
what
it
sounds
like.
This
is
directly
running
commands
as
if
I'm
writing
them
to
the
terminal
so
bash
or
sh
in
linux,
for
the
command
prompt
for
powershell
in
windows.
B
So
this
is
as
if
I
was
a
human
being
typing
those
into
the
terminal.
Again,
as
gronk
pointed
out,
smartly
as
the
user,
that
the
runner
is
running
as
typing
those
commands
and
executing
them
in
parallel,
this
is
really
helpful
for
like
low
level
stuff.
You
want
to
do
if
you're
running
your
own
runner
on
your
machine.
It's
helpful
because
it's
super
easy
to
debug.
B
It's
really
useful
for
that.
The
other
really
useful
tool
is
docker
machine.
So
this
is
docker.
Machine
is
a
specific
driver
from
docker,
where
there's
kind
of
like
a
master
machine
that
can
then
scale
up
runners
with
demand,
and
so
this
is
very
typical
in
cloud
deployments
and
I
think
we
talked
about
it
a
little
bit
later.
B
But
you
know
most
cloud
providers
support
this
and
then
many
on-premise
private
cloud
type
supporters
tools
support
this
as
well,
and
so
it
allows
you
to
scale
up
and
down
with
demand,
just
like
the
kubernetes
one
does
so.
The
kubernetes
executor
is
similar,
but
it
actually
runs
the
build
as
a
pod
in
the
kubernetes
question
and
again
that
also
then
brings
you
some
native
auto
scaling
options
around
around
how
that
works.
G
B
So
no
docker
machine
is
a
way
that
docker
drives
creation
of
new
virtual
machines,
basically
right,
okay,
so
you
could
think
of
it
as
docker
virtual
machines,
so,
for
instance,
on
aws
I
can
use
docker
machine
to
spin
up
a
new
ec2
instance
and
we'll
get
into
that
a
little
bit
later.
Docker
and
docker
means
a
I'm
inside
of
a
docker
image,
but
I
also
want
to
be
able
to
have
docker
running
so
that
I
can
then
build
docker
images
from
with
inside
of
background
like
in
seconds.
So
those
two
things.
F
I
understand
that
as
a
default
image,
but
I
have
yet
to
see
a
gitlab
ci
yml
file,
where
you
wouldn't
define
what
the
image
actually
is,
but
if
you
define
let's,
for
example,
if
I'm
giving
on
the
on
the
on
the
registration
of
the
runner,
if
I'm
giving
it
an
alpine
image
and
then
in
my
in
my
yaml
file,
I
simply
say:
well,
I'm
going
to
use
jdk8
here
or
something
like
that
that
will
override
the
default.
Is
that
correct?
F
It's
overriding
a
default?
Another
thing
is,
I
have
a
setup
here
that
I'm
using
where
I'm
using
docker
machine
manually
to
create
a
virtual
machine
running
boot
to
docker
as
the
as
a
deck
as
a
as
a
distinct
docker
execution
environment
were
kind
of
isolated
from
my
mac.
Basically,
in
order
to
talk
to
that,
I'll
still
use
a
gitlab
runner
with
the
docker
executor
as
such,
so
it's
sometimes
confusing,
but
I
might
be
using
as
a
user
docker
machine
to
have
a
docker
environment.
F
B
F
B
All
right,
I
hope,
you're
all
still
there,
but
because
I
can't
see
you
next
we're
going
to
take
a
look
at
some
three
of
the
less
com.
I
would
say
less
common
executors,
so
virtualbox
can
be
an
executor.
This
is
basically
where
you
specify
a
base
virtual
machine
for
your
runner
in
virtualbox
and
then
kind
of
that
master
runner
again
creates
a
new
virtual
machine
for
each
one,
so
that's
similar
to
a
docker
machine,
but
a
little
less
universe.
B
It's
just
for
virtualbox,
but
actually
it's
also
for
parallels
too,
because
parallels
for
mac
is
really
just
a
nice
platform
on
top
of
virtualbox.
Just
don't
tell
anyone,
but
that's
what
you're
paying
for
and
then
there's
also
an
ssh
runner
which
is
similar
to
shell,
but
a
little
bit
different.
In
this
case
I
would
the
ssh
executor
would
first
ssh
you
would
ssh
into
that
machine
and
then
execute
commands
on
that
machine.
B
So
if
I
don't
want
runner
installed
on
that
machine,
but
I
want
to
be
able
to
execute
commands
during
my
build
on
that
machine.
This
kind
of
lets
me
do
it,
but
again
it's
it's
a
little
bit
more
limited,
because
this
is
only
really
supports
bash.
The
cache
really
isn't
supported
in
this,
and
so
it's
kind
of
a
limited
set
of
use
cases.
But
it's
it's
valuable
when
you
need
it.
B
B
All
right,
so,
let's
talk
about
auto
scaling
launchers.
So
again,
there's
three
different,
auto
scaling
methods.
This
is
where
we're
gonna
dive
into
it
right.
So
there's
aws
I've,
I've
separated
out
aws
actually
uses
docker
machine,
but
there's
some
specific
things
to
aws
that
I
want
to
talk
about
which
I
think
they're
important,
there's
docker
machine
which
again
works
with
most
cloud
providers.
Docker
shows
examples
of
digital
ocean
or
aws,
but
then
you
can
also
see
the
the
massive
list
of
drivers
that
exist.
B
That
support
are
supported
by
docker
for
a
docker
machine
which
includes
virtualbox,
actually
and
then
includes
three
vmware
tools:
vcloud
air,
fusion
and
vsphere,
and
then
a
number
of
other
tools,
as
you
can
see,
and
then
last
is
kubernetes.
So
we'll
talk
about
how
the
kubernetes
scaling
works
as
well
and
just
real
quick.
Can
I
get
a
time
check?
I
have
no
idea
what
time
it
is
either.
B
Awesome
cool
great
great,
all
right,
okay,
so
let's
first
talk
about
docker
machines.
So
again,
docker
machine
is
a
driver
from
docker
that
allows
you
to
create
machines
on
demand
and
so
basically
to
configure
this
for
get
lab.
I
can
configure
a
global
job
limit
called
concurrent,
which
is
how
many
jobs,
all
runners,
local
and
auto
scale
can
can
can
be
executed
at
one
time.
B
But
then
I
can
also
limit
the
upper
limit
of
machines
that
are
going
to
be
created
by
the
executor
and
then
I
can
also
set
an
idle
count
middle
time,
which
is
really
useful.
So
this
says
you
know,
always
leave
two
machines
on
but
scale
up
to
10
when
needed,
and
then,
when
those
machines
are
not
needed
anymore,
allow
them
to
be
on
for
x
number
of
minutes
to
see
if
another
job
comes
up.
So
this
is
useful
and
just
can
help
speed
up
the
builds
right.
B
So
here
we're
balancing
smartly
using
compute
time
with
speed
of
builds
and
not
waiting
for
a
machine.
Maybe
every
time
I
have
a
new
build
and
then
actually
actually
there's
even
more
advanced
features
where
I
can
do
an
off-peak
configuration
so
that
when,
at
the
start
of
my
business
day,
I
can
have
it
scale
up
and
have
you
know
two
two
idle
machines
at
all
times,
at
least,
but
then
at
the
end
of
the
business
they
scale
down
to
zero
or
something
similar
to
that.
B
And
then
in
this
scenario,
there's
some
also
advanced
consideration
for
caching,
because
now
the
runner
cache
for
a
given
pipeline
is
not
contained
within
one
runner.
I
have
to
have
a
smart
plan
for
distributed.
Caching,
if
I'm
going
to
use
caching
across
jobs
in
my
pipeline
and
next
we'll
talk
about
ibus,
which
will
help
make
this
a
little
bit
more
real-world
for
anybody.
But
any
questions
before
I
move
on
from
here.
F
F
I'm
currently
working
on
an
opportunity
where
that
really
is
an
issue
that
we
need
to
have
kind
of
proxy
settings
on
it,
and
the
question
would
be
what's
the
where's
the
place
to
do
that
in
that
in
that
machine
environment.
So,
basically,
because
my
understanding
is
when
you
put
it
in
that
section,
this
becomes
a
parameter
to
a
docker
machine,
create
what
effectively
gives
that
docker
host
this
environment
variables,
but
there's
still
the
ability
to
do
that
in
the
cim
of
where
do
I
do
it.
B
Yeah,
I
would
say
in
the
proxy
use
case
that
the
best
place
to
do
it
would
be
in
the
docker
machine
section,
because
then
that
means
that
my
developers
don't
need
to
know
anything
about
the
proxy
environment.
Like
I
mean
they
could,
but
but
I
I'd
want
to
be
able
to
provide
them
a
service
that
they
don't
have
to
think
about
right.
It's.
B
D
B
B
Okay,
so
in
aws
again
we
can
scale
up
instances
in
aws
using
this
docker
machine,
but
there's
some
specific
considerations
for
that
and
some
specific
benefits
you
get
just
because
of
the
way
aws
structures,
what
they
do.
First
off,
of
course
to
spin
up
some.
You
know
a
new
machine
in
ec2,
which
is
what
dr
machine
is
going
to
be
doing.
B
I'll
need
access,
keys
that
have
the
ability
to
do
that,
and
then
I,
of
course,
I'm
going
to
need
to
specify
a
region
specify
what
vpc,
subnet
and
security
groups
are
going
to
apply
to
that
machine,
and
then
I
can
also
tag
the
machine
with
ec2
tags.
So
again
that
can
be
very
valuable
when
it
comes
to
billing
perspective,
I
can
actually
auto
scale
and
go
back.
B
Actually,
a
blog
post
out
there
that
talks
about
reducing
their
their
cost
on
ec2
by
90
when
moving
from
jenkins,
which
would
have
slaves
that
are
running
all
the
time
to
auto
scale,
get
lab
with
spawn
instances.
So
that's
that's
a
huge
benefit
for
large
enterprises
that
might
be
doing
a
lot
of
builds
at
scale.
B
We
have
a
helm
chart
for
the
honor
that
that
can
deploy
gitlab
runner
into
kubernetes
cluster,
but
we
also
have
the
ability
now
to
with
one
click,
if
you've
connected
your
git
lab
project
to
a
kubernetes
cluster,
deploy
a
runner
with
one
click
and
that's
kind
of
just
a
single
runner,
but
then
auto
scale,
runners
and
kubernetes
to
a
similar
one
installation
button.
That's
coming
to
a
gitlab
near
you
soon
any
questions
about
kubernetes.
F
B
Correct
yeah
again,
this
would
typically
typically
be
done
at
the
at
the
instance
level,
but
now
with
the
project
specifically
done
at
the
project
level
and
again,
both
with
docker
machine
and
with
kubernetes
both
of
these
scaling
options,
gitlab
is
handling
as
it
creates
a
new
runner
registering
that
runner
right.
Does
that
make
sense.
So,
with
docker
machine
I'm
going
to
create
a
new
ec2
instance,
it's
going
to
spin
up
it's
going
to
have
gitlab
runner
on
it,
but
I'm
going
to
have
it
installed
and
registered
automatically
same
with
the
kubernetes
executor.
B
Great
so,
first
before
we
get
to
that
just
some
security
considerations.
First
of
all,
there's
a
great
page
on
security
on
a
runner
documentation
right
like
basically,
this
entire
presentation
is
brought
to
you
not
from
brendan's
brain
as
much
as
from
get
labs
and
leaving
documentation.
So
I
definitely
encourage
everybody
to
read
that,
but
I
did
want
to
bring
up
some
of
them
here
right.
So
the
first
one
is
for
the
shell
executor.
B
So
this
is
going
to
run
commands
as
whoever
installed
gitlab
runner,
and
so,
if
our
sudo
installs
gitlab
runner,
it's
going
to
run
as
root,
and
so
because
it's
running
as
that
user
it
has
those
user
permissions
on
the
system,
and
so
if
that
user
has
pseudorights
a
group
that
you
know
can
be
dangerous.
If
someone
wants
to
do
nefarious
stuff
to
your
system,
the
docker
executor,
on
the
other
hand,
is
very
safe,
especially
in
non-privileged
mode
privilege
mode.
B
F
Brendan,
I
need
to
ask
something
here:
sorry
about
that,
but
this
is
actually
with
with
autodevops
and
with
the
security
products.
We
have
running
the
docker,
execute
and
privileged
mode
being
a
mandatory
requirement.
As
far
as
I
understand
that
this
opens
up
a
can
of
warms,
as
in
conversations
with
prospects,
we're
having
the
thing
like
security
fighting
security,
so
we
are
selling
security
products
to
security
where
people
they
then,
by
the
same
time,
raise
kind
of
concerns
because
we
are
using
a
privileged
docker
executor.
F
B
F
For
instance,
I
done
the
same
thing
with
and
that
sort
of
solves
the
problem.
I
said
if
you
with
well
doctor
machine,
create
a
virtual
machine
not
with
the
outer
scaling
stuff
by
itself,
but
just
really
creating
a
separate
docker
environment.
Then
you
would
be
actually
safer
by
using
privileged
mode,
because
you
do
not
worry
about
that,
because
it's
a
specific
virtual
machine
that
has
been
created
is
that
a
fair
statement.
B
Exactly
and
and
and
the
the
analogy
I
would
use
is
look:
we
do
this
at
scale
on
gitlab.com,
so
think
about
the
nefarious
actors
that
can
sign
up
for
gitlab.com
and
try
to
do
a
bunch
of
stuff
right-
and
this
is
you
know
the
entire
world
worth
of
it.
It's
not
even
just
our
organization
right
and
so
our
security
team.
B
B
The
easiest
answer
to
this
is:
we
use
the
certificates
on
the
system,
and
so,
if
you've
got
the
system
that
we're
running
on
configured
to
properly
use
yourself
some
significance,
you
shouldn't,
have
a
problem.
Now
you
can
also
place
the
pm
file
in
a
very
specific
location,
I'm
not
sure
what
it
is,
but
in
the
dock
you'll
see
it's,
you
know,
etsy
get
lab
runner
or
something
or
in
your
when
you're
configuring,
the
promo.
B
You
can
actually
point
us
to
a
specific
place
where
the
certificate
exists,
and
so
those
two
are
our
options
as
well,
but
I
would
say
if
I
was
doing
it,
I'd
want
to
manage
the
machines
they're
running
and
running
on
separate
from
the
runner
itself
and
then
get
lab
runner
wouldn't
need
to
know
anything
about
that.
It
would
just
work.
F
B
Yeah,
I'm
not
sure
I
I
haven't
had
experience
with
that
specifically,
so
I'd
have
to
look
at
it
with
you,
but
but
yeah.
I
I
I'd
ever
look
at
it
and
again
a
lot
of
it.
I
think
we
should
put
as
much
as
possible
onto
the
system
that
we're
running
on,
because
that's
a
much
more
maintainable
thing
than
us
having
to
know
everything
about
the
proxy
in
order
to
get
it
to
work.
B
Okay,
so
next,
let's
talk
about
installation
and
then
a
couple
advanced
configuration
topics,
aka
the
this
tunnel
that
you've
heard
us
alluding
to
throughout.
So
first
of
all,
the
installation,
of
course,
is
a
great
document
piece
of
documentation
on
it,
but
it's
pretty
simple:
you
basically
get
the
binary
for
your
system.
You
can
download
it
from
from
our
package
management
system
or
or
just
download
the
binary
itself.
That's
correct
for
your
system
and
then
you
make
sure
that
that
is
executable.
B
B
I
give
a
description
to
the
runner
that
just
basically
is
the
name
that
displays
in
gitlab.
I
can
add
a
comma-separated
list
of
tags
for
this
runner.
I
can
decide
again
that
check
box
of.
Does
this
want
to
run,
untagged
builds
or
not,
and
then
I
can
also
say.
Am
I
going
to
lock
this
runner
to
this
project
or
allow
it
to
be
set
up
as
a
runner
for
other
projects,
and
then
it
registers
the
runner,
and
it
asks
me
for
my
executor.
You
can
see
the
list
of
executors
there
and
actually
it
will.
B
B
So
the
ci
token
is
either
if
you're
the
admin,
the
ci
token
is
going
to
be
in
slash
admin
runners
right,
as
we
saw
way
back
at
the
beginning
in
a
specific
versus
shared
winter
slide.
Okay,
and
if
I'm,
if
I'm
a
project
owner-
and
I
want
to
register
to
my
project,
it's
under
project
settings,
ci
cd
runners-
to
get
that
token.
B
All
right,
yep,
you
get
that
from
the
guru
all
right,
then
last
just
look
at
config.tomo,
so
tomo
is
just
another
markup
language,
I'm
pretty
sure
it's
tom's
other
markup
language,
or
something
like
that.
So
just
when
you
thought,
yaml
was
the
last
one.
You'd
ever
need
here
comes
tomorrow,
so
this
tomo
file
basically
defines
all
of
the
things
that
we
need
to
know
for
the
runner
to
run
and
that
registration
process
we
just
saw
is
basically
writing
the
minimum
required
items
to
create
the
config.tomo.
B
But
then
I
can
be
a
little
bit
more
advanced
and
configure
some
more
details
within
it.
So
here
we
can
see
that
there's
a
global
settings
at
the
top
level.
This
is
you
know
again
for
this
entire
runner
set
of
runners,
how
many
concurrent
jobs
can
run,
and
then
things
like
log
levels
get
stuff
there
and
proxy
stuff,
and
then
each
runner
that
this
gitlab
runner
instance
is
going
to
run
is
is
started
with
one
of
these
runners
tags
and
then
again
some
generic
information
about
that
runner.
B
The
token
it's
gonna
go
to
the
url,
it's
looking
at
what
executor
it's
gonna
use
and
then,
depending
on
the
executor
you're
gonna
have
you
might
have
specific
executor
definitions
below
so
here
I've
included
all
of
them,
but
or
many
of
them,
but
you
won't
actually
have
all
of
them.
You
would
have
one
or
the
other,
so
you
could
have
docker.
You
could
have
virtualbox,
you
could
have
kubernetes.
There's
specific.
B
You
know
the
specific
considerations
we
talked
about
are
going
to
be
found
within
this
kind
of
sub
settings
area
and
then
there's
also
the
runners.cache
that
defines
where
I'm
going
to
put
the
cache,
if
not
in
my
local
system.
So
if
I
want
to
put
it
into
s3
or
something
like
that,
that's
a
section
where
that
gets
defined
again
great
documentation.
On
this,
it's
called
advanced
configuration
of
git
lab
runners.
If
you
want
to
see
like
all
the
details
behind
it,
I
just
wanted
to
kind
of
demystify
this
in
general,
all
righty.