►
From YouTube: GitLab Virtual Meetup - How Containerized Pipelines and Kubernetes Can Boost Your CI/CD
Description
This is a recording of the GitLab Virtual meetup from 2020/07/03 featuring GitLab Heroes Adrian Moisey and Nico Meisenzahl.
Title: How Containerized Pipelines and Kubernetes Can Boost Your CI/CD
Description: 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.
----
We would love for you to contribute to our virtual meetups.
You can find upcoming virtual meetups and resources to plan your own here: https://about.gitlab.com/community/virtual-meetups/
We want to hear your ideas for topics. Remote? Security? Contributing to OS? Email suggestions to evangelists@gitlab.com.
We also love when community members present at GitLab meetups. Send an email to evangelists@gitlab.com if you’re interested in being the featured speaker at a future remote meetup.
A
Okay,
welcome
everybody.
Welcome
to
the
skit
lab
virtual
meetup,
just
before
we
begin,
which
will
let
you
know
that
this
meetup
is
recorded
and
will
be
published
on
youtube.
So,
if
you're
not
comfortable
with
having
your
image
shared,
please
turn
off
your
video
and
keep
your
microphone
off.
If
you
are
comfortable
with
having
your
face
shown,
you're
welcome
to
turn
on
your
camera,
I
think
seeing
some
seeing
some
faces
is
a
is
a
nice
thing.
It
makes
it
a
bit
more
personal
in
these.
A
A
A
A
B
Perfect,
okay,
yeah
so
adrian
also
mentioned
it.
I
would
like
to
talk
about
how
containers
pipelines
work
with
kubernetes
and
how
they
can
boost
your
crcd
pipeline,
so
some
birds
on
my
side,
I'm
nick
meister,
I'm
from
munich,
like
some
people
in
the
cooler
today
pretty
cool.
I
live
near
near
munich,.
B
So
what
I
would
like
to
talk
about
today
is
first
of
all
how
gitlab
and
kubernetes
works
together
and
some
advantages
of
using
it
was
together.
Then
I
would
like
to
talk
about
click
of
the
topic
containers
pipelines
and
why
you
should
use
them
so
the
pros
and
maybe
some
cons,
and
then
we
will
show
we
have
a
look,
how
the
pipeline
workload
can
be
moved
to
kubernetes
with
github
cicd
and
then
last
piece.
We
are
talking
about
containerization
all
the
time,
so
how
we
can
build
container
images
in
a
container.
B
So
in
our
coordinate
this
environment
with
the
open
source
tool
called
kaniko,
I
will
have
some
demos,
so
all
of
the
demos
already
available.
So
if
you
would
like
to
have
a
look
while
I'm
talking,
this
is
your
help,
but
they're
also
posting
the
url.
It's
on
the
on
the
last
slide
again,
if
you
would
like
to
check
it
out
later:
okay,
so
gitlab
and
kubernetes
yeah,
it's
a
it's
a
perfect
fake
fit.
So,
first
of
all,
you
can
run
your
gitlab
instance
on
kubernetes.
B
If
you
like
to
run
gitlab
containerized,
you
can
run
your
whole
gitlab
environment
and
kubernetes
and
scale
it
out.
You
can,
of
course,
run
containers
pipelines.
This
is
what
I
will
talk
about
later
in
this
stock.
You
can
use
the
monitoring
and
tracing
stack
of
gitlab,
which
is
completely
containerized
and
based
on
open
source.
So
you
can
monitor
your
deployed
applications
or
build
applications
which
are
built
with
gitlab
cssd
and
monitors
them
and
trace
them
right
out
of
gitlab,
based
on
cloud
native
and
open
source
tools
running
in
the
same
kubernetes
cluster
you're.
B
Building
your
apps
and
you're
running
you'll
get
the
bits
song.
So
it's
pretty
nice
integrated.
You
can
run
functions
and
serverless
applications
with
get
lab
and
kubernetes,
and
you
can
do
some
nice
stuff,
like
review
apps,
which
allows
you
to
review
any
kind
of
changes
in
a
match
request.
So
every
time
you're
creating
a
match
request.
Reaver
apps
will
create
a
new
instance
side-by-side
of
your
application,
and
you
can
review
it
check
if
everything
is
working.
Everything
is
fine
and
match
the
metric
list,
so
pretty
nice
feature.
B
On
the
other
hand,
you
have
auto
devops,
which
allows
you
to
use
a
whole
cisd
pipeline
with
any
kind
of
tests
and
deployment
and
so
on
without
coding.
Any
single
line
of
of
your
pipeline
so
just
enable
it
and
you
have
a
full-blown
pipeline
for
your
containerized
apps
that
will
be
deployed,
combinators
that
will
be
tested
and
so
on.
So
pretty
nice
integrations,
but
this
time
we're
focusing
on
the
containerized
part
and
why
we
should
do
so.
B
B
B
Then,
of
course,
you
can
because
of
using
containers
you
can
put
in
all
the
dependencies
you
need,
so
it's
just
defining
the
container
image,
maybe
building
your
own
container
image,
putting
all
things
into
the
container
image
this
particular
pipeline
run
needs
so,
let's
say
you're
building
a
node
js
application
you're
putting
in
node
in
the
specific
version
you
like
to
use
it
putting
in
some
other
dependencies,
and
then
you
can
make
sure
that
all
the
dependencies
are
met.
It
doesn't
matter
on
which
host
the
job
is
actually
scheduled.
B
B
Let's
say
you
have
five
machines
running
made
a
mistake
installing
node.js
on
the
on
the
third
one
and
then,
if
the
build
is
running
on
that
one,
it
might
get
to
get
an
issue
or
some
of
the
application
is
built
differently,
is
running
behaving
different
in
your
conduction
environment
and
so
on.
So
with
this
containerized
image
to
make
sure
that
all
this
dependencies
are
met
and
yeah
every
every
run
pipeline
run
is
looking
the
same.
Then
scalability,
of
course,
is
just
a
container.
B
You
can
still
scale
out
if
you
would
like
and
immutability
is
also
pretty
nice
and
clcd
shop,
so
every
shop
you're
starting
is
running
the
same
because
every
time
a
new
container
instance
coming
up,
so
you
don't
have
any
things
left
from
the
previous
run
and
so
on.
It's
everyone
is
looking
the
same,
every
time
which
is
pretty
important
and
once
again
it's
in
container,
so
it
doesn't
matter
how
the
host
looks
like
everything
is
within
the
container
image.
It's
immutable
and
everything's
fine.
B
So,
with
this
in
place,
you
can
really
build
nearly
anything
or
deploy
anything.
You
just
need
to
put
all
the
dependencies
and
binaries
you
need
into
your
image,
which
you're
using
for
this
kind
of
pipe
and
shop.
You
can
use
different
images,
so
every
pipe
and
shot
can
get
its
own
image
and
it
works
with
everything.
So
node.js
dot
co
go
terraform
ansible
if
you're
talking
about
infrastructure
development
and
so
on,
it
doesn't
matter.
You
just
need
to
put
in
the
things
independent
things
you
need
into
into
your
image.
B
So,
but
how
do
we
run
those
kind
of
containerized
image?
So
maybe
you
can
think
of
just
using
gitlab
cicd
using
a
bash
script
or
something
and
just
do
a
docker
run
and
run
our
container
and
so
on.
It
would
work,
but
it's
not
so
so
fine
and
it's
supposedly
basically
because
the
containers
are
immutable.
B
But
you
end
up
needing
to
manage
all
the
caching
all
the
artifact
handling
and
so
on
on
your
own,
so
we'll
end
up
mounting
volumes
from
the
file
system.
Then
you
have
a
dependency
to
a
file
system
of
your
build
node.
You
cannot
scale
out
anymore,
so
it's
not
really
pretty
nice
and
at
the
moment
we
are
only
talking
about
bill
jobs,
not
about
talking
containers,
so
which
means
you
would
need
to
build
a
container
in
a
container,
and
then
you
get
some
other
kind
of
traveler.
B
So
docker
one
run
would
somehow
work,
but
it's
not
really
nice
and
yeah.
So
how
do
we
fix
it?
Basically,
there's
a
nice
github
runner,
which
is
aware
of
kubernetes,
which
we
can
use
in
this
place,
so
it's
called
github
runner,
kubernetes
executor
and
it's
completely
integrated
so
csd
with
your
kubernetes
cluster.
B
So,
first
of
all
the
gitlab
runner
itself
is
containerized
and
running
in
your
kubernetes
cluster.
So
it's
just
a
pod
and
I
will
show
you
in
a
second
and
then
this
gitlab
kubernetes
runner
will
then
schedule
your
shop
images
or
your
job
tasks
as
containers
in
your
kubernetes
cluster,
so
you're
having
a
pipeline
with
one
job.
B
B
With
this
in
place
and
the
kubernetes
cluster,
which
can
scale
out,
you
can
scale
out.
Also
your
csct
pipeline
doesn't
matter
at
all.
You
just
need
to
scale
logic
when
it
is
less
than
everything's
fine.
So
how
do
we
install
the
github
kubernetes
runner?
You
have
different
options.
We
have,
let's
call
it
one
click
options
or
you
can
just
go
into
your
repo
in
the
settings
page
when
nature
space
and
install
it.
B
I
will
show
you
the
page
in
a
second
second
option
is
to
use
a
help
chart
which
is
provide,
regulate
lab,
which
is
somehow
more
production
rate
deployment.
In
my
opinions,
where
you
have
different
options
and
settings
you
can
define
and
the
third
one
is
pretty
new
one.
It's
an
alpha
feature,
but
you
can
also
add
two
lines
of
code
in
your
pipeline
definition
and
just
tell
your
pipeline
hey.
I
need
to
get
a
runner
in
this
environment
and
then
the
pipeline
itself
will
make
sure
that
the
github
runner
is
installed
somewhere.
B
Of
course,
in
this
case
with
the
github
runner,
it
doesn't
work
on
the
same
cluster
because
there
isn't
rather
needed
to
install
the
runner,
but
you
can
just
run
a
dockerized
thing
somewhere
and
then
use
it
afterwards
anyway.
This
also
works.
The
csd
integration
also
works
with
any
kind
of
other
managed
application,
which
I
will
show
you
in
the
second.
B
So
that's
it.
We
can
run
our
images
with
the
github
runner
in
our
cluster,
but
the
github
runner,
kubernetes
executor
is
also
rare
how
to
work
with
cloning,
our
rapports,
how
to
work
with
caching
and
artifact
management.
So
you
don't
need
to
think
about
this
stuff.
You
just
need
to
run
to
tell
the
git
runner
in
your
pipeline
definition
hey.
I
would
like
to
cache
this
directory
this
file.
I
would
like
to
upload
this
artifact
somewhere
and
the
github
runner
knows
how
to
do
it.
B
B
Next
to
your
build
container
and
sauce
are
used
to
manage
all
this
stuff.
So
actually
your
pipeline
job-
and
this
is
every
job-
contains
of
some
of
multiple
stages.
So
we
first
of
all
have
the
prepair
stage
which
create
the
pot
and
creates
the
containers
in
this
pot,
so
the
build
container,
which
is
actually
that
one
running
your
the
image
to
define
and
the
service
containers,
and
then
we
have
a
so-called
pre-built
step,
which
then
clones
the
repo
that
the
rapid
files
are
accessible
in.
B
Your
build
container
restores
cache
if
you
defined
so
downloads,
artifacts
and
so
on,
and
with
this
in
place,
your
build
container
can
then
start
and
has
everything
in
place
it
needs.
It
has
a
ripple
files,
caching,
restored
and
artifact
restart.
Then
you
can
start
your
build
or
deploy
it
doesn't
matter.
B
B
Yeah
and
of
course,
you
have
some
advanced
topics
which
are
also
shown
in
a
second,
so
you
can
define
resource
limits
for
those
builds
jobs
which
is
pretty
nice
and
in
a
containerized
combination
environment
that
you
make
sure
that
the
build
chop
does
not
bother
any
other
kinds
of
deployments
in
your
cluster.
You
can
define
ci
services
which
allow
you
to
add
any
kind
of
dependencies
for
your
build
or
testing.
Let's
say
you
need
a
database
for
any
kind
of
testing,
propose
you
can
define
those
and
they
will
be
containerized
and
started
along.
B
B
B
You
can
add
a
cluster
to
a
group
and
then
use
it
in
multiple
project,
or
you
can
also
add
it
to
the
to
the
project
itself.
Doesn't
matter
it
looks
completely
the
same,
so
in
this
case
I
also
added
already
added
the
cluster,
but
if
you
do
not
have
any
cluster,
you
can
the
kubernetes
page
and
just
get
the
cluster
button
here.
In
my
case,
I
already
have
one
which
you
will
need
to
edit
at
the
cluster.
It's
just
yeah
the
api
and
your
credentials,
certificates
and
so
on.
B
So
it's
pretty
pretty
basic,
just
some
clicks
and
it's
configured.
You
can
also
create
a
cluster
out
of
gitlab
and
the
google
cloud
and
so
on.
So
if
you
created
it,
you
now
see
the
health
section
which
shouldn't
bring
any
kind
of
errors.
So
there
was
no
kind
of
area.
Everything
fine
see
some
basic
information,
so
you
see
cpu
usage
memory
usage
of
your
cluster,
which
is
a
pretty
nice
insight.
B
This
is
based
on
the
promises
integration.
So
it's
not
here
out
of
the
box.
You
need
to
install
prometheus
to
get
it,
but
it's
also
completely
managed
by
gitlab,
and
then
you
have
this
kind
of
application
tab
where
you
can
install
gitlab
managed
applications.
This
is
a
thing
I
already
talked
about
all
the
time.
So
here
you
can
say:
hey
I
would
like
to
have
and
somewhere
I'm
blind
with
the
here.
B
You
can
install
increase
third
manager,
crossplane
and
some
other
stuff,
canadian
for
serverless
and
functions,
and
here
we
also
have
elasticsearch
deck
for
locking
and
matrix
stuff,
and
here
you
see
once
again
there's
a
new
update
and
I
could
hear
click
update
to
update
my
managed
environment
and
gitlab,
and
this
is
all
deployed
into
microvoltage
cluster
and
completely
managed
by
get
lipsticks
pretty
nice
yeah.
Then
I
have
some
advanced
settings,
but
that
doesn't
matter
at
the
moment.
B
No,
this
is
one
option,
just
go
to
the
quince
cluster
and
install
your
runner.
Second
one.
As
I
said,
the
more
production
one
would
be
using
a
hamster
it's
available
out
there.
Just
let
me
paste
url
just
to
make
sure-
and
here
it's
ion
chart,
so
you
just
need
to
deploy
it
on
your
own.
And
if
you
have
a
quick
look
in
the
values
file,
you're
seeing
all
the
settings
you
can
define
so
we're
gonna
jump
in
on
everything,
but
you
can
tell
them
hey.
I
would
like
to
get
matrix.
B
You
can
define
the
default
image
of
your
runner,
so
the
default
build
image.
It
should
be
used.
You
can
tell
if
whether
it
should
schedule
privileged
pots
or
unprivileged
ports.
You
can
define
things
like
like
the
poll
time
here
you
can
define
which
caching
options
for
the
gitlab
case
should
be
used
and
so
on.
Those
are
the
advanced
features
which
you
cannot
define
if
you
install
it
with
the
with
the
git
wi
and
so
on.
B
So
I
have
pretty
pretty
much
settings
like
this
on
the
node,
selector,
tolerations
and
so
on.
You
maybe
would
like
to
add
labels
or
annotations
to
your
bot
to
your
pods,
which
get
deployed
and
so
on.
So
I
have
pretty
advanced
settings
here
and
you
can
just
install
it
with
ham
install
and
it's
it's
ready
to
go.
B
If
you
check
how
it
looks
from
the
kubernetes
side,
so
just
get
my
pods
from
the
gitlab
managed
namespace,
and
here
we
see
all
the
gitlab
managed
applications.
So
we
have
the
elastic
stack.
We
have
inquiry
and
promises
and
so
on,
but
we
also
have
our
gitlab
runner
running
as
pod,
and
this
is
the
runner
which
is
running
and
writing
to
schedule
our
overclock
our
pipeline
workload,
so
pretty
nice.
So.
B
B
Let
me
just
check
I
using
hand
too
yeah
so
there's
a
question
in
the
chat
if
it's
based
on
m2
or
m3
at
the
moment,
if
you're
using
the
github
integrated
prawn,
it's
still
hand
too,
but
it's
a
secure,
helm
setup.
So
it's
totally
fine
to
use
it.
It
was
tiller,
but
it's
it's
secured,
but
I
think
youtube
is
already
working
on
moving
it
to
him
3.0
pretty
soon.
I
think,
there's
an
issue
out
there.
B
Yeah
so
put
everything
in
your
pipeline,
which
you
would
like
to
have
available
in
your
pipeline
shop,
any
kind
of
binaries
libraries
tools,
external
dependencies
and
so
on,
and
then
you
should
also
consider
rebuilding
those
kind
of
images.
I
saw
it
many
times
customer
sites
that
they
built
their
pipeline
pipeline
images
two
years
ago
and
still
are
using
them.
So
once
again
make
sure
those
are
some
how
up
to
date,
at
least
for
security,
fixes
every
dependency
versions.
B
I
have
a
pin
to
make
sure
that
they
are
the
same
all
the
time
but
for
the
qt
filters
make
sure
to
install
them
yeah
and
once
again
we
are
running
containers.
So
those
are
immutable
if
you're
running
containerized
pipelines
so
need
to
make
sure
that
you're
using
caching
without
caching,
you
will
slow
down
your
pipelines
so
make
sure
you
implement
the
caching
options.
Gitlab
provides
you
use,
caching,
to
speed
up
speed
up
your
builds.
B
B
Okay,
so
this
is
how
a
pipeline
image
could
look
like.
So
it's
a
pretty
pretty
simple
one:
it's
based
on
airplane
and
it's
just
installing
some
kind
of
stuff.
In
this
case
it's
just
yama,
linda
installs,
this
binary
and
then
it's
an
entry
point
and
then
cp
section.
But
with
this
image
we
only
have
yamahanter
and
we
can
blend
some
some
yam.
So
it's
pretty
easy,
but
you
can
install
any
kind
of
things
you
would
like
to
use.
B
B
So
pretty
simple,
and
we
just
have
in
this
repo
the
integration
of
the
github
sample
and
on
a
pipeline
definition
file.
Now
the
pipeline
is
once
again
pretty
pretty
easy.
We
have
only
one
stage,
we
have
some
kind
of
variables
and
we
have
our
job,
which
is
part
of
the
one
stage
we
have
so
once
again,
we
are
telling
gitlab
to
run
this
on
kubernetes,
so
it's
just
done
via
attack.
B
The
kubernetes
tag
is
the
basic
take
for
the
kubernetes
runner,
but
you
can
also
change
it
to
any
other
kind,
but
with
this
line
you're
telling
gitlab
to
schedule
this
workload
in
onto
your
kubernetes
cluster,
then
of
course,
because
it's
containerized,
we
need
to
tell
gitlab
the
image
which
you
would
like
to
use.
This
is
done
within
the
image
section,
so
you
can
tell
hey.
I
would
like
to
use
an
image
you
can
provide
a
name
in
this
case.
It's
just
a
variable.
B
We
can
overwrite
the
entry
point
if
we
would
like,
in
this
case
we're
doing
so
and
then
we're
just
scheduling
our
script
in
this
case
once
again,
pretty
easy
one.
It's
just
an
upgrade
doing
some
installations
and
passing
a
variable.
So
at
the
moment
the
variable
is
hello
world.
So
if
you
check
our
application,
we're
seeing
hello
world
and
freight,
so
this
is
our
company
logo
he's
called
freight,
and
now
we're
just
running
our
pipeline.
B
So
if
you
know
schedule
a
pipeline
run
and
just
change
the
message,
the
application
gets
redeployed
and
you're
seeing
the
new
message.
So
let's
do
this:
let's
go
to
pipelines,
run
a
new
pipeline
run
from
master
we
put
in
the
message
and
some
kind
of
new
text,
and
before
we
run
this
one
I
will
go
over
to
my
kubernetes
cluster
and
do
a
watch
on
my
gitlab
managed
app
workspace.
B
B
If
we
check
the
locks,
we
should
now
see
a
message
that
the
pot
gets
triggered.
If
you
go
over
to
the
companies
cluster
once
again
see
the
runner
pot
gets
started.
We
have
two
containers
in
this
pot,
so
one
is
our
build
container
and
the
service
container
it's
depending
now.
The
container
is
creating.
Now
it's
running
so
now.
If
we
switch
back,
we
should
see
the
output
of
our
pipeline.
B
You
see
the
ham
upgrade
and
the
job
is
done.
So
now
we
came
back
to
our
kubernetes
cluster
and
we're
seeing
that
the
job
the
pod
gets
terminated
and
it's
already
gone.
So
we
scheduled
our
pipeline.
The
kubernetes
runner
decided
to
schedule
a
pot
with
our
build
image
or
in
this
case,
deploy
image
with
the
service
container.
B
B
Okay,
so
that's
it!
This
is
how
the
gitlab
container
kubernetes
integration
is
working,
but
now
we
are
in
a
completely
containerized
world.
So
how
do
we
build
our
container
images
and
maybe
not
only
our
application
images,
perhaps
also
our
pipeline
images,
because
we
are
now
containerized?
We
are
running
containers
pipelines.
We
somehow
need
our
pipeline
images
built,
and
so
you
can
of
course,
use
docker
and
docker.
I'm
sure
if
you're
familiar
with
it
so
docker
docker
is
basically
the
different
options
to
use
it,
but
it's
difficulty.
B
It's
basically
meaning
you're
running
docker
inside
a
container,
so
you're
running
a
docker
inside
docker
container
and
doing
stuff
with
it
different
options.
Every
option
is
somehow
not
the
best
one
and
has
issues
first
option
is
that
you
expose
your
docker
socket
into
your
container
and
then
just
using
your
docker
cli
and
talking
to
the
docker
socket
from
your
host,
which
of
course
works.
But
with
this
you
can
completely
access
your
host
files
team,
create
different
containers,
doing
stuff
on
your
host
and
so
on.
B
B
B
Third,
one
is
you're
actually
running
the
docker
daemon
inside
a
docker
container,
so
this
one
is
actually
running
docker
in
docker,
but
therefore
you
will
need
privileged
mode
to
be
able
to
do
so
and
also
privileged
mode
is
not
so
nice,
and
so,
if
you're
talking
about
you,
have
a
linux
machine
where
you're
running
your
builds,
it
might
be
okay
with
the
security
issues.
All
these
issues
at
all
might
be
quite
to
use
it.
B
But
if
you're
running
this
kind
of
stuff
in
a
kubernetes
cluster
with
a
completely
different
workload
on
the
same
hood,
you
will
get
issues
or
you
even
shouldn't
be
allowed
to
do
so.
You
shouldn't
be
allowed
to
mount
your
docker
circuit
or
mount
a
local
volume
from
a
kubernetes
nodes
or
run
a
port
in
privilege
mode,
so
we'll
somehow
get
issues
and
can't
build
your
container
images.
So
we
need
another
solution,
so
multiple
open
source
projects
out
there.
I
will
talk
about
one
particular
in
this
talk
really
like
it.
B
B
So
just
run
a
container
based
on
the
kaneko
image,
providing
your
source
code,
providing
your
docker
file
and
can
eco
will
build
it
for
you
and
will
upload
it
to
a
docker
registry
without
you
thinking
about
any
kind
of
dependencies
or
privileges
outside
of
this
container.
So
it's
pretty
easy
to
use.
I
will
show
you
examples,
just
one
line
or
depending
on
how
you
build
it,
four
lines,
five
lines,
of
course,
and
you
can
use
it
and
once
again
we're
talking
about
running
things
inside
the
container
so
also
with
koniku.
B
You
should
think
about
caching
to
speed
up
your
docker
bits.
So
it's
once
again
the
same
thing:
kaniko
provides
two
different
options.
First,
one
is
kaneko
can
cache
the
layers,
so
not
the
whole
image,
also
all
the
different
layers
and
push
it
into
a
docker
registry
and
then
pulls
it
from
there.
Every
time
kaneko
uses
this
layer,
so
it's
still
not
the
best
options,
but
it's
faster
pulling
and
pushing
it
instead
of
rebuilding
it
all
the
time.
B
You
can
cache
this
one
and
for
kunico
it
needs
to
those
images
need
to
be
on
a
specific
volume
or
a
specific
path
in
the
container,
and
this
one
could
be
mounted
through
volume
and
manage
through
git
lab
cse
cache.
So
with
those
both
in
place,
you
can
pretty
speed
up.
Your
containerized
builds
with
kaneko.
B
If
it's
just
called
dockerfile,
we
can
basically
skip
it
because
it's
the
default.
We
can
define
a
context
if
you
to
do
so,
though
the
base
directory
you
would
like
to
run
can
equate
and
you
can
define
a
destination
destination
is
also
optional.
So
if
you
like
to
just
build
it
and
test
it
and
not
push
it,
you
can
lift
this
just
skip
the
destination
part,
and
then
you
can
test
the
image,
but
don't
not
push
it.
B
If
you
like
to,
if
you
like,
to
add
multiple
text,
you
just
put
in
multiple
destinations
and
then
it
partial
pushes
the
text
to
the
same
registry,
same
name
with
different
text,
but
you
can
also
provide
different
registry,
different
image,
name
and
so
on.
So
just
use
multiple
destinations
for
all
the
examples
and
with
this
kaniku
was
able
to
to
build
the
image
so
actually
three
three
lines
which
could
be
one
and
everything
is
fine.
B
Once
again,
I
have
a
sample
ripple
here
we
have
a
dockerfile
once
again
pretty
basic.
This
one
is
basically
the
docker
file
or
the
container
image
I
used
in
my
first
example,
so
it's
just
providing
hem
cli.
So
it's
based
on
a
club,
ctl
image
of
mine
and
then
just
installing
hair
heading
ham
is
an
entry
point,
and
with
this
we
have
a
container
containing
help
and
we
can
use
the
mcli
to
do
our
stuff.
B
Of
course,
we
have
a
gitlab,
cicd
armor
once
again
easy
just
one
stage.
We
have
a
variable
which
I
will
talk
in
a
sec
about,
and
we
have
our
pipeline
chop
once
again.
The
kubernetes
tag
to
tell
gitlab
to
schedule
it
on
our
kubernetes
runner
we're
defining
the
image,
which
is
the
official
canico
image
and
we're
defining
a
version
in
this
case.
B
It's
the
debug
check
and
this
is
needed
because
in
the
latest
or
any
other
kind
of
image,
kaniku
does
not
provide
any
kind
of
shell
and
without
a
shell,
the
get
the
better
cannot
inject.
Your
repo
called
current
and
check
all
the
other
stuff.
So
you
need
to
run
the
debug
image,
but
until
some
month
I
think
kaniko
also
provides
specific
versions
for
the
debug
image.
So
in
this
case
it's
the
debug
image
of
latest,
but
you
can
also
define
a
specific
version.
B
A
pinned
version
with
a
debug
tick
so
make
sure
that
you
use
the
debug
click.
Then,
once
again,
we're
overwriting
the
entry
point
just
to
give
you
the
whole
details,
and
then
we
have
a
before
script
and
a
script
section.
The
before
script
section
does
only
one
thing,
because
we
are
running
this
in
gitlab
and
pushing
it
also
into
our
registry
from
our
gitlab
repo.
We
need
to
provide
authentication
because
we
need
to
authenticate
to
be
able
to
push.
B
This
is
done
by
just
passing
our
ci
registry,
which
is
available.
The
gitlab
runner
injects
and
then
just
passing
the
gitlab
top
token,
which
is
also
available,
which
the
runner
provides
you
with
and
put
all
the
stuff
in
the
docker
configuration
of
konico.
So
with
this
line,
you're
adding
everything
kaneko
needs
to
authenticate
against
your
repo
and
then
we
once
again
of
our
script,
we're
running
the
connector
executor,
providing
context.
B
Once
again,
it's
a
default
variable
of
gitlab,
just
providing
the
project
directory
we're
defining
the
dockerfile,
which
is
dockerfile
and
we're
defining
the
destination,
and
in
this
case
the
destination
is
once
again
a
variable.
It's
our
registry
image
name.
So
our
registry
and
the
image
name
of
our
ripple,
the
file,
the
image
name,
is
him
and
we're
just
putting
pushing
the
latest
stick
in
this
example.
B
B
And
so
on,
so
now
it's
building
and
installing
our
ham
cli,
taking
snapshot
of
the
file
system,
defining
the
entry
point
defining
the
cmd
and
it
should
be
nearly
finished
chop-
is
done.
So,
let's
jump
back
to
our
kubernetes
cluster,
the
port
is
already
terminated,
so
the
port
is
already
done
and
now
we
should
get
if
we
go
to
package
and
registry
and
container
industry
and
here's
a
nice
little
bug
with
the
new
dark
ui.
B
So
now
we
see
the
gitlab
commit
our
image
or
head
chart
redefined
and
if
we
exit
once
again,
we
have
a
small
bug
with
the
latest
image
and
it's
published
43
seconds
ago
so
pipeline
run
built
the
image
uploaded
it
into
our
registry
in
gitlab
and
everything
worked
pretty
well.
Of
course
you
don't
need
to
use
the
registry
within
gitlab.
You
can
also
use
docker
hub
or
any
other
thing,
but
it's
pretty
nice
integrated.
So
why
not.
B
B
B
B
B
B
D
B
B
B
Does
gitlab
have
a
have
some
kind
of
web
hooks
that
can
send
me
an
alert
on
pipeline
failure.
I
think
you
can
gather
this
information
using
the
api
and
I
think
you
can
also
integrate
web
hooks
into
into
your
pipeline,
but
I
would
have
to
check
the
details
on
this
one.
If
someone
has
details
in
the
call,
just
just
let
me
know,
are
there
other
ways
of
containerizing
the
pipelines
of
jenkins
other
than
gitlab
they
like
an
environment
where
we
have
docker,
kubernetes
and
jenkins?
B
B
Sorry,
just
my
brutus
connections
of
my
of
my
efforts
and
so
of
course,
with
skitlab
runner.
You
can
containerize
all
the
stuff.
You
can
also
use
jenkins
x
if
you
just
would
like
to
containerize
your
workload
and
use
kubernetes
not
get
not
jenkins
but
jenkins,
x,
yeah,
and
if
you
use
good
lab
and
move
over
all
your
ci
cd
configurations,
you
wouldn't
need
changes
anymore.
So
I
think
you
need
just
to
decide
which
one
to
use
to
be
honest.
B
B
Then
we
have
a
question
related
to
google
answers
and
never
tries
to
use
gitlab
with
enters,
but
enters
is
once
again
just
a
managed
kubernetes
cluster.
So
it
should
be
pretty
fine
and
two
does
work,
but
I
never
did
it
before,
but
it's
basically
a
kubernetes
cluster.
So
if
you
have
the
api
url,
if
you
have
your
token
your
certificates,
you
can
integrate.
B
A
Okay,
we
we
don't
have
much
time
left.
We
were
thinking
of
doing
the
breakout
room,
but
I
think
we
can
skip
that
because
there's
only
eight
minutes,
it's
not
much
time
to
have
a
chat.
So
thank
you
nico
for
putting
this
together
and
and
sharing
your
information
with
us.
We
really
appreciate
it
cool
thanks
to
everyone
on
the
call
who
who
joined
it's
great,
having
you
all,
or
I
think
I
think
we
peaked
at
about
45
people.
A
D
A
A
A
D
Everyone-
and
one
last
thing
I
promise
to
plug
this,
but
we
are
doing
a
conference,
a
virtual
conference
next
month
august
26th,
it's
free
to
attend
it's
24
hours.
So,
regardless
of
your
time
zone
there'll,
be
you
know,
content
that
you
can
enjoy.
You
know
and
all
the
speakers
will
be
doing
q
a
following
their
sessions.
So
I
would
highly
encourage
you
to
check
that
out
and
hopefully
you
know,
keep
coming
to
the
meetups
and
I'd
love
for
you
to
stay
engaged
with
the
community.