►
From YouTube: London GitLab Virtual Meetup
Description
This is a recording of the London GitLab Virtual Meetup from 2020/04/21 featuring GitLab Heroes Will Hall and Nico Meisenzahl.
Talk 1: Building, testing and improving your container workflow inside GitLab
Talk 2: How Containerized Pipelines and Kubernetes Can Boost Your CI/CD:
Learn how to eliminate any dependencies on your CI/CD build nodes and don’t bother yourself with multiple versions of your toolchain and any corresponding constraints. Walk away with knowledge and best practices that will help you to optimize your builds and deployments with containerized pipelines!
Use containerized GitLab CI/CD pipelines and Kaniko to move your build and deployment workloads into your Kubernetes cluster. Build your apps and infrastructure without any external dependencies and constraints. If you are building a Go project, deploying an app to Kubernetes or just building your infrastructure. It doesn’t matter, anything is possible!
Join Nico on a deep dive into the secrets of building hassle-free containerized build and deployment pipelines with GitLab CI/CD, Kubernetes and Kaniko.
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
Speaker bios:
1. Will Hall is a DevOps Consultant at HeleCloud, GitLab Hero and Docker Community Leader.
He has been architecting and delivering successful solutions with software since 2005, most recently using DevOps tools and processes with Terraform, Vault and Ansible, and distributed applications with Docker.
Currently, he's interested in the evolution of DevOps, exploring the great opportunities to modernize existing applications and infrastructure and run them alongside new tools and services including containerisation, serverless and infrastructure as code.
And you can thank him for adding Yamllint to GitLab (or not!)
Will on Twitter https://twitter.com/HN_Will
2. Nico Meisenzahl works as a Senior Cloud and DevOps Consultant at white duck. He is an elected Docker Community Leader and GitLab Hero. His current passion is for topics around Kubernetes, CI/CD, Automation, DevOps, and the Cloud.
Nico is a frequent speaker at conferences, user group events and Meetups in Europe and the United States.
Nico on Twitter https://twitter.com/nmeisenzahl
A
And
I'm
not
just
it's
just
a
quick
one
actually
just
to
welcome
everyone
to
the
first.
I
guess
virtual
git
lab
london
meetup.
My
name
is
anthony
work
at
gitlab
with
john
and
hope.
Everyone
is
doing
well
in
this
new
normal
and
transition
yeah.
Everyone
is
welcome
to
participate
today.
So
we
look
forward
to
hearing
your
questions
in
case
anyone's
forgotten.
What
day
it
is
given
that
every
day
feels
the
same.
It's
21st
of
april
2020.,
so
it's
the
first
one.
A
A
Any
issues
just
feel
to
click
your
video
off.
Take
it
off
off
of
you.
So
we
can't
see
you
but
we'll
love
to
see
your
faces.
So
please
do
keep
it
on.
If
you
can,
there
are
two
or
they
would.
I
guess
there
are
two
lucky
winners
today,
so
it
wouldn't
be
a
gitlab
event.
If
there
weren't
any
winners
or
prizes
in
terms
of
what
the
prizes
are,
I'm
not
gonna
announce
that
that'll
be
brian
towards
the
end
of
the
event.
A
But
in
order
to
win
how
you
enter,
is
you
ask
the
best
questions?
So
we
have
two
people.
Two
people
can
win.
The
two
best
questions
asked:
will
win
a
prize
so
the
more
questions
you
ask,
the
more
opportunity
or
chance
you
have
to
win,
and
the
winners
will
be
chosen
by
the
speakers
so
absolutely
subjective
in
regards
to
in
regards
to
the
winners
chosen,
and
that's
it
really
without
further
ado
I'll
hand
over
to
will
who
will
kick
us
off
we'll
take
it
away.
B
Excellent
yeah
thanks
everyone
for
coming
I'll
I'll
start
sharing
my
screen,
and
then
I
can
talk
you
through
some
of
the
exciting
fun
that
we've
already
had
today.
So
I
think
that
if
people
also
see-
I
don't
know
if
we've
gone
over
this,
but
there
is
reactions
at
the
bottom
that
you
can
make,
which
are
like
a
lovely
little
clap.
B
B
B
B
So
hopefully
you
can
see
my
screen.
Okay,
I
say
thumbs
up,
which
is
a
good
thing.
It's
like
visual
feedback,
yeah
super.
So
what
I
wanted
to
cover
today
was
just
a
few
bits
about
building
testing
and
storing
docker
containers
in
gitlab
and
how
that
can
be
used
as
a
really
good
introduction
into
you
know,
actually,
both
using
gitlab
but
also
understanding
some
of
the
features
and
powers
that
gitlab
have
to
to
separate,
separate
us
out
from
the
other
git
providers.
B
Now
straight
away,
I
was
going
to
have
a
segue
into
isn't.
You
know
github
as
a
dev
devops
platform
and
that's
what
I
wanted
to
do,
but
I've
also
been.
I
had
a
slight
change
today,
which
means
that
we
had
an
exciting
change
of
speaker
bringing
me
in
and
then
I
ran
into
a
lovely
challenge
which
was
git
la
github
status.
B
In
the
last
hour,
no,
the
demo
doesn't
work
because
it
relies
on
github
to
build
its
packages
and,
amazingly
enough.
This
is
not
the
first
time
that
this
has
happened
to
me
in
the
last
two
weeks.
So
I
was
also
doing
this
with
kodi
packages
and
I've
debugged
this
problem
now
for
about
45
minutes
to
find
out
why
these
packages
not
building
turns
out
the
packages
aren't
building
because
yeah
github's
down.
B
Okay.
So
when
I
say
about
github
being
a
devops
platform,
I
what
I
want
to
try
and
suggest
is
that
it's
it's
not
really
a
tool
just
to
host
where
you
have
your
your
git
repos,
but
it's
a
lot
more
of
a
platform
to
enable
a
lot
more
of
the
jobs
that
we're
generally
running
in
devops
nowadays.
So
from
my
opinion,
devops
is
obsessed
with
process
improvement,
making
everything
code
automating
things
and
delivering
visibility
and
understanding
to
others
in
its
core
efforts
to
to
deliver
that.
B
B
This
is
about
me.
I
didn't
want
to
put
too
much
because
actually,
I'm
also
the
the
organizer
and
I
got
roped
into
to
speaking,
but
I'm
so
passionate
about
it
that
I've
managed
to
find
time
today
and
when
we're
looking
at
gitlab
ci.
What
I
am
really
looking
at
is
process-based
iteration
for
software
management.
Now,
whether
that's
software
as
in
javascript
and
java,
and
writing
applications
in
python
or
whether
that's
software,
that's
configuring,
your
infrastructure
as
code.
B
For
me,
there
is
no
definition
in
between
you
know
the
platforms
you're
running
and
the
code
that
you're
running
on
them,
and
what
we're
looking
at
gitlab
ci
to
do
is
be
the
the
tool
to
process
it
to
deliver
the
tools
and
the
techniques
for
software
teams
to
innovate.
So
we're
actually
asking
people
to
do
things
inside
gitlab
ci.
You
know
we're
looking
at
being
able
to
automate
the
build
test
release
of
software,
and
it's
ensuring
that
you
know
I've
put
here.
B
B
You
know
a
real
driver
for
people
to
deliver
that
security
a
lot
earlier
and
whether
that's
through
compliance
or
policy,
is
code
or
through
other
tools
that
are
doing.
You
know,
security
scanning
and
application
scanning
and
those
kind
of
things.
It's
all
about
being
proactive.
You
don't,
if
possible,
you're,
making
sure
that
your
errors
are
tracked
before
they're
even
released
okay.
So
I
wanted
to
get
people
into
a
demo.
B
I
don't
know
if
my
assumption
is
that
people
have
turned
up
at
a
gitlab
meetup
and
therefore
they
know
lots
about
git
love
and
I
just
raise
raise
your
hand
or
make
some
kind
of
mark.
If
you
haven't
used
gitlab
a
lot
and
that's
that's
interesting-
I
can't
really
see
that
too
much
at
the
moment,
but
hopefully,
and
we
can
cover
a
kind
of
overview
of
what
what
people
are
are
using
themselves.
So.
B
And
so
that's
that's
interesting
for
me
to
see
now
I'm
going
to
go
gitlab.com
and
I'm
already
logged
into
my
my
personal
account,
and
so
you
can
see
some
of
the
things
that
I'm
working
on
at
the
moment
and
I'm
going
to
start
up
a
new
project
and
the
reason
that
I'm
starting
out
this
new
project
is
really
so
that
people
can
get
an
understanding
of
of
that
process
of
delivering
containers.
So
I've
got
a
new
project
for
me
here
and
I'm
going
to.
B
I'm
going
to
call
it
hugo
gogo,
because
it's
going
to
be
with
hugo-
and
I
can
make
this
public
because
you're
all
nice
guys
so
I'm
creating
this
project
and
what
we've
now
done.
We've
created
a
project
in
gitlab
and
I'm
going
to
start
delivering
containers
on
top
of
this
project
so
directly
into
the
into
the
registry.
B
So
knowing
what
I
already
need
to
to
to
put
in
is
a
core
part
of
this,
and
actually
what
I'm
going
to
be
building
is.
I
think
people
should
be
able
to
see
this.
I
make
it
slightly
larger
in
case
you're,
on
a
smaller
screen,
but
what
we've
got
here
is
we've
got
an
image
of
hugo,
which
is
like
a
go
static,
site
builder,
and
so
this
is
a
docker
file
and
then
we
have
yaml
link
for
it
as
well.
B
B
B
Okay,
so
we've
got
the
project
here
and
what
I'm
going
to
start
doing,
I'm
going
to
go
and
create
a
new
file
and
I'm
going
to
create
I'm
going
to
create
a
docker
file
and
we
see
we
could
create
a
template
from
the
existing
templates
that
are
in
here.
So
we've
got,
you
know
ones
around
golang
or
we
could
use
node
or
we
could
use
php
or
python,
but
I'm
just
going
to
paste
in
the
one
that
I've
already
made.
B
B
B
So
we've
got
yaml
lint
in
here
and
then
what
I'm
going
to
put
in
is
I'm
going
to
start
putting
in
my
my
my
ci
file,
so
what
we
have
inside
here,
we've
got.
You
know
various
stages
that
we're
running
through
for
this
container.
Now,
if
I
went
to
go
for,
I
can
go
for
the
ci
that
we
have.
It
already
is
a
template,
and
that
will
do
you
know
a
pretty
good
job
of
actually
just
putting
up.
I
can
do
a
new
file
and
I
can
make
it.
B
And
I
can
put
on
the
template
for
docker
and
I
can
actually
stop
there,
deploy
that
and
that
will
go
and
make
me
containers
I
can
then
all
of
you
could
then
go
and
pull
those
containers
down
straight
away.
So
we've
now
got
an
entire
process
in.
I
think
that
was
about
about
three
minutes
that
you
could
go
and
actually
make
a
container
and
make
it
publicly
available.
B
I
don't
know
how
many
people
have
tried
pushing
to
docker
hub
that
kind
of
thing,
but
this
is
you
know
a
way
of
linking
those
two
together
you're
not
having
to
build
anything
in
in
sync
with
you
know,
github
and
docker
hub
to
push
it.
We
can
do
it
entirely
through
gitlab,
but
actually
I'm
not
going
to
do
this
one,
I'm
going
to
use
my
pre-prepared
one,
because
it's
actually
starting
to
deliver
a
bit
more
value
to
people
who
are
who
are
using
it.
B
So
what
we've
got
in
here,
you
know
we
can
see
in
that
we'd
be
building
our
master,
and
this
is
going
to
push
to
the
latest
latest
tag,
and
then
this
is
going
to
use
a
commit
reference
as
its
docker
tag
name,
but
I'm
gonna
put
my
one
in
so
actually
what
we're
starting
to
do
here
is
deliver
more.
So
not
only
are
we
allowing
you
know,
we
we've
got
had
a
link
running
to
to
lint
our
docker
file.
B
We've
got
yaml
lint
running
to
lint
our
yaml
and
then
enable
us
to
do
a
build
of
our
build
of
our
docker
image,
and
we
can
also
put
in
here
a
base
image.
So
I'm
using
our
point
3.11,
but
I
could
move
that
out
for
being
3.10
or
if
I
wanted
to
make
some
security
things
fail,
I
could
put
3.7
and
then
I'm
also
putting
in
that.
We
were
able
to
do
a
tag
and
we're
putting
in
here
that
we're
using
a
commit
tag.
B
B
Maybe
he
was
being
like
an
evangelist
in
and
I
was
going
to
say
raising
his
hands
to
that.
That's
definitely
the
word
okay.
So,
as
we
move
on
we've
got
in
down
here,
we've
got.
You
know
the
ability
to
use
trivi
we've
got
the
ability
to
use
trivia
which
is
going
to
do
container
scanning
on
the
the
item
that
we've
just
done,
and
we
also
have
the
ability
at
the
end
we're
going
to
run
it
and
and
do
hugo
version.
So
this
would
this
would
version
our
file.
B
So
what
we've
kind
of
shown
in
this
really
quick
overview-
and
this
will
take
a
couple
of
minutes
to
complete-
is
that
actually
what
we've
we've
built
is
a
pipeline
for
delivering.
You
know
relatively
improved
docker
containers
in
10
minutes
and
I
realized
I
I'd
established
a
couple
of
these
things
in
advance,
but
actually
I'd
established
them
by
copying
and
pasting
stuff
that
I
had
in
other
containers
already,
and
so
we
see
it's
not
particularly
challenging.
I've
got
a
failure
because
the
ambulance
failed
because
I'm
missing
and
the
end
of
file.
B
E
F
B
B
B
This
starts
to
be
able
to
deliver
people
a
lot
more
of
of
the
things
that
that
they're
going
to
want
to
use
eventually
and
also
a
lot
more
of
the
tools
in
a
really
easy
place
to
do
it.
So
we
have
not
left
gitlab
to
do
all
of
this.
Apart
from
the
fact
I've
copied
and
pasted,
I
don't
know
if
we're
going
to
take
questions
now
I
don't
know,
I
don't
think
I
saw
any
questions
from
the
chat,
but
that's
kind
of
my
really
quick
overview
of
building
improving
containers
inside
gitlab.
B
B
F
B
No
sorry,
I
I
if
I
show
you
inside
some
of
these
that
have
already
succeeded,
so
the
process
has
already
passed
for
them.
What
it
will
do
is
you
will
run
docker
inside
docker
so
like
that
as
a
as
a
container
and
then
you're
able
to
this
is
building
alpine,
so
it
builds
the
container
inside
there
and
then
because
gitlab
runs
a
registry
and
you
log
into
your
registry.
You
can
push
that
container
back
into
the
gitlab
registry.
That
you're
running
and
ones
are
public
are
available
to
download
straight
away.
B
F
B
H
B
Muted
is
where
I
sound
most
intelligent,
yeah,
so
docker
and
docker
works
on
the
the
shared
runners.
I'm
running
this
in
gitlab
on
the
free
runners,
so
yeah.
Actually
what
you
end
up
doing
is
you
add
it
as
a
service?
That's
available,
so
there's
an
idea
of
running
services,
so
the
image
itself
is
docker
latest
and
then
you
run
docker
in
docker
as
a
service
available
to
it.
B
B
D
Yeah
I
asked
this
question
earlier
in
the
chat,
but
for
folks
it
seems
like
we've
had
a
lot
of
folks
join
since
the
first
time.
I
asked
this
question
if
you
could
just
share
where
you're
joining
from
it's
pretty
interesting,
to
see
like
the
kind
of
global
reach
that
this
london
gitlab
group
is
getting
today,
feels
like
the
london
folks
might
be
outnumbered,
so
maybe
they
want
to
step
up
and
represent.
You
know,
london,
by
sharing
their
location
in
the
chat.
C
F
H
H
H
A
short
intro
of
mine,
so
I'm
nico,
meisenster,
I'm
senior
cloud
and
defense
consultant
at
whitetail
greater,
is
a
small
consulting
development
company
in
southern
germany.
So
we
are
located
near
munich
and
normally
I
would
have
been
in
london
this
week
for
a
conference
where
we
decided
to
put
up
the
meetup
and
meet
in
person
and
have
some
fun
so
now
everything's
different,
I'm
back
near
munich
and
doing
this
remotely.
But
it's
it's
still
fun.
H
So
my
agenda
today
so
just
a
brief
introduction
about
gitlab
and
kubernetes
itself
how
it
works.
Then
we
talk
about
containerized
pipelines
and
why
those
are
pretty
nice
and
then
we
talk
about
how
you
could
move
your
pipeline
workload
into
a
kubernetes
cluster
and
then
we'll
talk
a
little
bit
about
how
you
could
build
container
images
within
containerized
pipelines.
So
container
images
within
containers
are
slightly
different
than
document
docker,
which
welded
but
just
providing
some
some
more
input.
H
And
then,
of
course,
if
you
would
like
to
get
swag,
please
ask
questions
and
please
ask:
will
not
me,
would
be
nice
okay,
so
let's
get
to
the
slides,
so
get
lightning
coordinated,
yeah,
it's
a
perfect
fix,
so
you
can
different
things
between
github
and
coordinators.
First
of
all,
you
can
host
if
you're
a
self-hosted
installation
you
can
completely
run
and
host
it
on
a
kubernetes
environment,
to
share
resources.
H
You
can
use
and
integrate
your
gitlab's
ci
or
your
whole
gator
project
with
monitoring
and
tracing
stack
which
could
be
installed
in
your
kubernetes
cluster.
Then
you
have
options
like
functions
and
serverless
apps.
So
basically,
just
caring
about
your
code
just
committing
your
code,
your
node.js
application
go
application
then
commit
it,
and
then
the
pipeline
will
run
the
whole
dockerfire
will
be
generated
on
its
own.
H
The
deployment
into
your
kubernetes
cluster
will
be
done
for
you,
and
then
you
have
to
service
application
which
completely
scales
out
from
zero
to
undefined
count
of
pots.
As
you
see
here.
Wasn't
this
example
for
me
from
some
weeks
ago,
so
pretty
nice
option
for
kubernetes
to
to
easily
scale
out
and
then
last
but
not
least,
you
have
the
option
to
run
or
containerize
your
build
pipelines,
and
this
is
the
main
topic
I
would
like
to
talk
about
today.
H
Yeah,
so
why
containers
pipelines
so
basically
containers
pipelines
are
pretty
nice
because
of
the
same
reasons
containers
are
so
your
processes
are
isolated.
So
container
image
is
nothing
else,
an
isolated
process,
so
resistant
players,
you
can
run
multiple
pipelines
next
to
each
other
and
nobody
is
seeing
the
other
pipeline
and
you
don't
get
any
issues
and
so
on.
H
That's
the
first
one,
so
isolation,
second
one
dependencies.
So
if
you
have
a
complex
build
pipeline
or
deployment
pipeline
with
any
kind
of
dependencies,
sdks,
clis
and
other
tools-
and
you
would
like
to
always
get
the
tools
in
the
version
you
would
like
to
add
them.
So
let's
say
you
are
depending
on
on
java,
then
you
would
like
to
have
a
specific
java
version
in
place
for
your
build
pipeline,
and
you
only
would
like
to
change
this
version
if
you
would
like
to
change
it.
H
So,
if
you're
running
on
the
shared
runner,
you
might
get
a
newer
version
or
older
versions.
If
you
have
different
different
build
runners
on
your
own,
you
might
have
some
issues
because
I
don't
know
your
five
machines
and
they
all
need
to
look
the
same
and
all
the
same
software
installed
or
dependency
installed.
The
address
containers,
it's
just
a
container
image,
so
it's
you,
define
your
requirements
in
the
dockerfile
building
the
container
and
using
container.
So
all
your
dependencies
are
within
your
build
process,
which
is
pretty
nice.
H
So
if
you
need
java
just
put
in
java,
if
you
need,
I
don't
know,
ansible
or
so
just
put
in
ansible,
and
you
can
use
it
and
and
run
your
pipeline
in
then,
of
course
scalability.
So
with
containers
and
kubernetes
in
place,
you
easily
can
scale
out
even
your
pipeline.
So
it's
if
your
kuan
is
less
than
big
enough.
You
can
scale
out
as
you
need
and
then
a
very
important
one
immutability.
H
So
a
container
image
is
immutable.
Every
time
you
recreate
in
the
container
image
or
starting
a
new
instance
of
your
container
image,
it
looks
the
same
every
time.
So,
with
this
in
place,
you
can
make
sure
that
every
pipeline
run
looks
the
same
or
has
the
same
dependency
in
place
is
defined,
so
doesn't
matter
on
which
of
your
host
host
this
pipeline
image
or
the
pipeline
choppers
is
generated
and
started.
H
It
looks
the
same
all
the
time,
because
the
whole
pipeline
drop
is
triggered
in
your
container
image,
which
is
pretty
nice
and
those
there
are
no
limitations.
So
it's
working
just
nearly
every
project
with
every
project,
and
you
just
need
to
put
the
dependencies
into
your
into
your
build
image
which
you're
using
for
your
for
your
bedroom.
So
it
doesn't
matter
at
all
so
any
kind
of
software,
any
kind
of
deploy,
dependencies,
nodejs.comgo
for
building
applications
or
for
infrastructures
code
or
configuration
things,
terraform,
instability
and
so
on.
So
it's
everything
works.
H
H
This
is
a
quite
similar
pattern,
so
many
of
the
people
are
doing
so,
but
it
somehow
has
some
some
issues.
So
if
you
let's
say
you
have
a
build,
build
house
running
your
your
pipelines
and
would
like
to
to
run
a
job
in
a
pipeline,
you
can
just
do
a
docker
run
script
or
a
docker,
build
and
and
and
and
run
your
scripts
and
run
the
container
and
doing
things
within
your
container
are
injected
in
the
entry
point
and
so
on,
then
you
have.
H
The
advantages
of
containers
are
immutable,
but
in
this
case
it's
also
a
disadvantage.
So
let's
think
you're
building
an
artifact
java.js
doesn't
matter
and
you're
building
it
in
your
container
image,
and
then
you
would
like
to
deploy
this
artifact
in
a
later
step.
You
need
to
think
about
things
like
caching,
artifact,
managing
management
and
so
on.
H
So
with
that
that
there's
a
pretty
nice
option,
it's
called
the
github
runner,
kubernetes
executor.
This
is
basically
you
get
the
runner
as
we
know
it,
so
it's
just
schedules
or
pipeline
shops
and
and
runs
or
headband
shops.
But
this
one
is
aware
of
kubernetes,
which
means
it
itself
runs
in
a
kubernetes
cluster
and
it
schedules
the
workload
of
the
pipelines
in
the
kubernetes
cluster,
which
basically
means
it's
integrates
your
csd
with
your
kubernetes
cluster,
and
this
works
with
any
kind
of
kubernetes
cluster.
H
So
any
cloud
provider,
any
on-premise
deployment
works
with
everything.
With
this
in
place
they
get
the
runner
itself
is
running,
is
a
pot
or
container
in
a
kubernetes
cluster
that
can
also
scale
out.
If
you
need
it
and,
as
already
said,
the
pipeline
shops
itself
are
scheduled
as
pots
within
your
kubernetes
cluster.
So
every
five
night
shop
is
a
pot
running
a
quad
data
cluster.
After
it's
finished,
it
gets
deleted
and
schedule
is
as
needed.
H
With
this
in
place,
it's
pretty
nice
option
to
to
share
your
compute
and
even
scale
your
pipelines.
So
I
have
some
customers
using
this
they're.
Just
using
their
development
coordinates
clusters
to
run
all
pipe
edge
tops,
so
they
do
not
have
dedicated
build
posts
for
the
pipeline.
They
just
run
it
within
their
development.
H
H
As
we
already
know
it
in
the
kubernetes
world,
so
with
this
that
there's
a
pretty
or
some
pretty
nice
feature,
so
the
github
runner
can
handle
all
yeah
the
the
advanced
topics
like
cloning,
your
your
repo
managing
your
cache
and
artifacts.
As
you
know
it
within
your
normal
github
runner,
so
you
just
need
to
define.
I
would
like
to
have
caching
this
directory.
H
I
I
would
like
to
to
store
this
artifact
and
they
get
that
run.
A
coordinated
executor
is
just
executing
this
one
to
get
this
in
place.
The
pipeline
shop
itself,
which
is
running
in
the
container,
has
multiple
stages,
so
we
have
let
me
put
in
the
laser,
so
we
have
first
of
all
comparison
which
creates
the
pot
for
the
pattern
runner
and
within
the
pot.
It
creates
multiple
containers.
H
H
You
can
include
services
for
any
kind
of
build
dependencies
like
the
docker
and
docker
example
build
it
and
you
can
also
define
if
you
have
a
big
kubernetes
cluster,
you
can
select
the
nodes.
The
runner
should
run
workload,
so
yeah
you're,
pretty
nearly
all
all
advanced
topics
or
topics
you
know
from
negative
runner
are
configured
within
the
kubernetes
executor.
H
So
let's
have
a
short
demo.
How
this
is
working
now.
First
of
all,
I'm
gonna
get
a
project.
It's
it's
it's
available
out
there,
so
you
can
just
access
it
with
the
url
and
I
added
already
kubernetes
cluster.
So
in
your
project
we
have
the
kubernetes
tab
where
you
can
add
kubernetes
cluster,
which
I
already
did.
If
you
did
this,
you
get
some
some
basic
information,
so
you
get,
you
should
get.
H
H
Second
version
option
would
be
to
use
the
hamster
which
got
spread
by
gitlab
and
this
in
this
ripple,
and
he
have
the
option
to
install
the
github
runner
with
helm.
So
here
is
a
package
manager
in
the
kubernetes
world
and
have
a
value
yaml
definition
file
where
you
can
then
can
define
any
kind
of
settings.
So
you
can
define
your
github
url
self,
hosted
url,
you
can
define
your
runner
tokens
and
so
on.
You
can
define
how
many
chops
should
run.
H
So
yeah
and
then
you
have
option
to
configure
your
cache
to
configure
service
containers,
upfront
and
so
on.
So
it's
pretty
advanced
configuration.
You
can
enable
nearly
everything
you
need
so
in
a
production
world,
I
would
recommend
to
to
install
the
runner
with
the
hand,
script
and
connect
it
to
your
to
your
environment.
H
So
if
you
have
to
run
in
place,
we
then
can
can
use
it
in
our
cluster.
Here
the
example
pipeline
pretty
basic
one.
We
only
have
one
stage
and
we're
only
doing
one
deployment,
so
we
do
not
build
anything.
It's
just
deploying
an
application
into
our
kubernetes
cluster,
we're
defining
some
variables
important
one
is
the
helmet
image
so
we're
once
again
using
helm
to
install
our
application
and
we
are
defining
our
image
here
for
later
use.
H
H
H
So
I
already
run
this
pipeline
as
you
see
here
and
got
my
application.
So
it's
just
a
hello
world
with
our
logo.
So
it's
it's
freed
and
now
I
would
like
to
run
the
pipeline
again
and
just
change
some
some
text.
So
let's
change
the
hello
world
in
this
case
already
said
it's
a
variable
where
I
can
define
the
value
so
just
run
it
manually.
H
H
So
this
one
is
the
actual
runner
waiting
to
get
chops
and
trigger
pots,
and
now,
if
I
go
back
to
my
pipeline
and
run
this
pipeline,
so
I
will
directly
head
over
to
our
kubernetes
cluster.
We
get
a
new
container
schedule
and
this
container
is
used
to
execute
our
pipeline,
so
it
was
pending.
Now
it's
creating
and
some
second
should
be
running.
H
H
So
we
should
already
see
it
somewhere,
oh
here,
so
the
new
part
schedule
this
one
is
our
application
part
it's
it's
up
for
22
seconds
now.
So
if
I
head
over
to
our
demo
application
and
just
reload
we're
seeing
the
hello
gitlab
so
pretty
easy
pipeline,
but
completely
containerized
running
within
our
kubernetes
cluster.
F
D
H
H
My
core
data
executor
is
running,
is
also
deploying
to
the
same
kubernetes
cluster,
but
you
could,
of
course,
also
deploy
into
a
different
kubernetes
cluster,
but
then
you
would
need
either
to
yeah.
You
need
to
to
add
some
more
steps
and
also
indicate
again
the
different
cluster
and
then
deploy
to
the
different
cluster,
like
you
would
do
with
with
this
helmet
and
coupe
sedale,
or
you
just
deploy
a
gitlab
runner
into
the
second
cluster.
H
H
So
next
one
so
now
we
are
doing
containerized
pipelines,
so
we
need
some
more
containers,
so
every
pipeline
job
we
are
using-
and
I
already
did
in
my
example-
we
put
in
our
binaries
and
our
libraries
into
it.
So
in
my
example,
it
was
just
help,
but
it
could
be
anything
any
kind
of
sdk
any
kind
of
build
requirements
and
so
on
and
any
kind
of
external
dependencies.
H
H
Now
this
one,
it's
just
a
gitlab
repository
hosting
some
kind
of
images
that
you
could
use
in
this
example
or
in
this
project.
I'm
rebuilding
those
images
once
a
week
doing
some
security
checks
on
it
and
then
publish
them.
So
if
you
build
your
own
container
image,
it
doesn't
matter
if
it's
a
python
image
or
application
image
rebuild
them
to
be
sure
to
have
all
security
fixes
in
and
of
course,
you
should
also
define
a
fixed
version
in
your
container
image
as
well.
H
Without
this,
you
would
get
newer
versions
without
knowing
it
so
same
thing
like
you
would
do
on
a
on
a
normal
runner
machine
and,
of
course,
because
containers
are
immutable.
You
need
to
think
about
caching,
so
you
need
to
make
sure
you
have
cash
in
place
to
be
able
to
to
fasten
your
your
pipeline.
H
Okay.
This
is
an
example
chop
image.
This
one
is
basically
yamlin,
so
we
already
used
it
before
so
it's
based
on
airplane-
and
I
just
defined
my
version,
my
yama
lint
version
and
just
used
the
packet
manager
of
airplane
installing
it
and
now
added
some
entry
points
and
cmd.
So
now
I
can
run
this
image
in
my
pipeline.
Shops
just
provide
a
cd
line
and
so
on,
and
I'm
can
run
my
my
pipeline
job
once
again,
it's
an
easy
one,
but
this
would
be
an
example.
H
My
my
hand
chart
looks
basically
the
same
or
my
apartment
job
for
my
handshake
yeah.
This
demo
was
part
of
my
last
demo,
so
I
already
did
it
it's
just
example
how
you
can
use
the
hem
chart
and
install
it,
so
we
can
skip
this
one
and
now
I
would
like
to
talk
about
different
topic.
Any
questions
adjusting
lines
of
lines,
but
I
think
already
is
everything's
covered
already.
H
H
If
you
run
multiple
instances
against
one
directory
and
or
you
need
to
expose
your
docker
demon
socket,
which
is
always
a
security
issue,
so
on
a
machine
just
running
docker,
it's
totally
fine
to
use
docker
and
docker
in
in
build
shops,
but
within
kubernetes
within
a
kubernetes
cluster.
Most
of
the
things
will
not
work
because
of
security
reasons,
or
at
least
should
not
work
because
of
security
reasons.
So
you
need
to
find
another
other
option
to
to
run
it.
H
And
with
this
I
would
like
to
talk
about
kaneko.
So
kaneko
is
an
open
source
project
by
google,
which
allows
you
to
build
container
images
within
containers
without
the
need
of
any
privileges
or
dependencies.
So
you
don't
need
docker
daemon
to
to
build
the
images
so
just
a
container
without
any
privileges
and
so
on.
H
So
I
like
the
the
docker
image
here,
so
it's
just
in
binary
running
in
a
container
image.
It's
pretty
easy
to
use
we'll
talk
about
it
in
a
second
and
once
again,
because
also
kaneko
is
running
in
a
container.
You
need
to
think
about
caching
to
speed
up
your
pipelines
and
connect
offers
two
ways
of
caching.
So,
first
of
all,
you
can
cache
your
layers.
So
if
you
build
your
docker
docker
image
based
on
dockerfile,
you
have
different
layers.
It's
those
layers
can
be
pushed
to
a
registry.
H
It
could
be
the
registry,
your
final
image
gets
pushed
through,
but
it
could
also
be
a
different
registry
and
then
every
time
kaneko
builds
your
docker
images.
It
knows:
okay,
there's
a
image
layer
in
my
registry
I
can
use
and
then
it
just
pulls
the
image
layer
instead
of
rebuilding
it.
Now
this
is
the
first
option
to
get
the
build
faster
and
the
second
option
is
to
also
cache
the
base
images.
H
So
basically
those
images
you
define
in
your
dockerfile
in
the
from
from
line
and
and
those
images
can
be
cached
with
the
volume
or
in
a
file
system
and
for
a
container.
It's
file
system
is
not
a
good
idea,
so
this
one
could
could
be
cached
with,
but
they
get
that
cache
option
with
the
runner.
You
know
with
this
two
in
place,
you
nearly
get
the
same
same
performances
as
in
normal.
Normal
builds
just
an
example
how
kiniko
works.
H
H
H
H
H
This
is
the
sample
pipeline
once
again
pretty
easy
one
stage.
We
define
one
variable.
This
one
is
the
kaneko
image
tech.
We
would
like
to
use
well
this
one
here.
It's
important.
This
one
needs
to
be
debugged
at
the
moment,
because
the
let's
say
normal
kaneko
image
does
not
include
doesn't
include
the
shell,
so
your
scripts
in
line
fifteen
to
21,
wouldn't
work.
So
you
would
don't
need
the
debug
image
it's
a
little
bit
bigger
than
normal
one,
but
doesn't
matter
since
some
weeks.
H
H
So
once
again,
we
are
defining
the
tag
to
tell
gitlab
to
execute
this
in
our
kubernetes
cluster.
We
are
defining
the
kineco
image
we
would
like
to
run
in,
and
then
we
have
two
lines
of
before
scripts
source
that
just
doesn't
needed
to
authenticate
with
a
registry
so
to
be
able
to
push
the
image
after
we
build
it.
In
this
case,
we
are
pushing
it
to
the
registry
attached
to
our
project
here.
H
So
we
have
our
package
container
registry
here,
which
is
pretty
easy,
so
we
just
can
use
predefined
variables
and
do
not
think
about
any
any
any
names
on
authentication.
So
this
one
provides
the
url
to
the
registry.
Then
we
provide
a
username
which
is
our
gitlab
ci
token
and
then
we're
providing
password,
which
is
our
see
our
job
token.
So
those
are
only
valid,
or
this
is
only
valid
in
this
job.
H
H
H
H
Here
we
go
so
the
output
is
pretty
similar
to
docker
build,
so
it's
just
installing
all
the
stuff
running
the
different
lines
from
our
docky
file.
Taking
the
snapshot
defining
the
entry
points,
cmd
everything
I
already
find
and
the
job
is
already
done.
So
if
we
go
back
to
kubernetes,
the
chop
pot
got
terminated
already.
So
it's
it's
already
deleted
from
our
cluster
and
then
we
now
go
to
the
container
h3.
H
H
H
D
It
might
be
easier
to
just
ask
folks
to
verbalize
their
questions,
because
there
is
a
lot
of
back
and
forth
in
the
chat.
I'm
not
sure
how
many
of
the
questions
are
still
unanswered
or
people
are
looking
for
further
clarification.
Does
anyone
want
to
verbalize
a
question
you
can
just
unmute
and
ask
nico.
E
H
H
If
you
use
some
external
artifact
management
tools,
you
will
need
to
download
them
on
your
own,
like
you
would
need
to
do
on
on
your
on
your
hosted
runner
on
your
normal
runner.
I
I
it
depends
how
fast
changing
they
are,
so
maybe
you
could
also
just
download
them
put
them
in
the
cache
directory
and
use
cache
to
get
it
to
every
pipeline
shop
or
maybe
also
build
them
within
the
pipeline
shop.
So
if
it's,
I
don't
know
changing
once
a
year,
the
artifact
for
testing
purpose.
H
You
can
also
put
it
in
the
in
the
dockerfile
and
build
your
pipeline
image
with
with
the
artifact
in
it.
So
it
depends,
but
basically
you
have
the
artifact
options.
Git
fci
provides
which
you
can
use
in
a
containerized
environment
or
not,
and
everything
else
would
need
to
build.
You
would
need
to
build
on
your
own.
F
H
G
A
In
that
case,
I
guess
if
anyone
else
has
any
questions
generally
about
git
lab
or
in
in
also
wants
to
get
involved
with
organizing
or
helping
to
organize
some
events.
Please
feel
free
to
reach
out
to
us.
You
can
shoot
me
an
email
at
ao,
thomas
getlab.com,
if
you
want
to
have
a
chat
or
just
shoot
us
a
response
via
the
meetup
group
and
we're
happy
to
have
a
chat.
A
B
I
think
the
only
bit
that
we'd
added
we're
probably
going
to
look
at
doing
an
another
one.
Sometime,
probably
it's
going
to
be
june
now
of
the
london
meet
up,
whether
we'll
actually
meet
in
person
or
meet
in
the
glory
of
our
own
homes,
again,
which
certainly
I'll
have
a
lot
longer
hair
by
then
as
well
and
yeah.
I
think
there's
also.
If
you
look
online,
I
think
that
there's
a
linux
in
london
session
tomorrow,
I
was
with
about
gitlab
as
well.
G
Yes,
thank
you.
Yes,
yes,
yes
and
I'm
gonna,
groom
myself
tomorrow,
a
little
bit
get
the
old
beard
shaved.
You
know
the
rest
of
it.
I
I
look
like
the
wolverine
under
here
so
yeah,
I'm
I'm
looking
grim
yeah,
but
the
content
is
really
good.
We're
doing
an
introduction
to
get
lab
and
all
the
goodies
with
it
with
michael
and
I'll
leave
a
link
in
the
meetup
and
thank
you
will
for
reminding
me.
D
One
thing
our
team
at
get
lab
you
know
is
really
proud
of.
Is
our
transparency.
We,
you
know,
keep
our
issues
open
and
people
can
comment
on
them
and
we
love
hearing
feedback
from
the
community.
So
for
folks
who
are
asking
questions,
whether
it's
about
spinnaker
or
some
of
the
artifacts
functionality,
I
would
encourage
you
to
you
know:
do
a
search
on
google
to
find
relevant
issues,
gitlab
issues
about
those
features
and
go
and
give
us
feedback
and
provide
us
some
direction.