►
From YouTube: Webinar: Automating Kubernetes Deployments
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Kubernetes abstracts and simplifies many aspects configuring and scaling infrastructure, but still requires DevOps. Building CI/CD pipelines to correctly deploy to Kuberentes clusters is a time-consuming process. In this webinar, we'll look at how GitLab is thinking about "CI/CD as code" with versionable and template-able pipelines. With re-usable code snippets, we'll show how building pipelines can be simplified to just a few clicks while remaining fully customizable.
A
We're
gonna
go
ahead
and
get
started.
Welcome
to
today's
C&C,
f,
webinar
automating,
kubernetes
deployments,
I'm
Chris
short
CN,
CF,
ambassador
and
principal
product
marketing
manager
at
Red,
Hat
work
on
the
ansible
team.
There
like
to
thank
everyone
who
is
joining
us
today.
We
would
like
to
welcome
our
presenter
William
Chia
Senior
Product
Marketing
Manager
at
gitlab
few
housekeeping
items.
Before
we
get
started
during
the
webinar.
You
were
not
able
to
talk
as
an
attendee.
There
is
a
Q&A
box
at
the
bottom
of
your
screen.
A
P,
please
feel
free
to
drop
your
questions
in
there
we'll
get
to
as
many
as
we
can
at
the
end.
I
will
also
be
monitoring
there,
a
general
chat.
So
if
there's
questions
there
feel
free
to
mention
them
there
as
well,
the
session
is
being
recorded
and
will
be
sent
out
afterwards,
along
with
the
link
to
the
presentation.
A
B
B
So
just
kind
of
to
map
out
what
I'd
like
to
talk
about
today,
basically
in
three
sections,
I
wanted
to
briefly
go
over
what
is
gitlab
and
why
you
know
kind
of
the
viewpoint
that
we
have,
as
you
know,
I'm
talking
here
about
automating
and
scaling
deployments,
doing
continuous
integration
and
conduce
delivery.
What
are
what
our
viewpoint
is
and
where
we're
coming
from
and
then
do
a
demo
and
then
the
code
and
the
reason
is
that
often
you'll
go
to
an
engineering
focus.
B
Talk
and
they'll
show
a
bunch
of
code
and
then
they'll
show
you
what
the
code
does,
but
in
this
case
I
think
that
showing
the
demo
first
and
spending
the
majority
of
the
time
showing
you
what
everything
does
will
actually
inform
how
all
of
the
code
works.
So
then,
when
we
actually
go
to
dig
into
the
code
and
what
the
code
is
doing,
it'll
make
sense
in
that
context.
So
in
brief,
that's
kind
of
the
outline
and
the
bit
of
a
theme
or
a
flavor
I'd
like
to
overlay.
B
On
top
of
that
is
the
concept
of
composable
building
blocks,
or
sometimes
here
at
gate
lab.
We
use
the
term
small
primitives
and
so
just
like
api's
or
building
with
Legos
the
engineering
concepts
of
building
a
small
composable
elements
and
then
being
able
to
use
that
to
build
other
bigger,
more
complex
things
is
something
that
I'm
a
big
fan
of
and
that
I
like
to
interweave
and
how
that
that
plays
in
how
we're
talking
about
continuous
delivery.
B
So
this
is
a
CN
CF
cloud
native
trail
map,
so
I've
put
the
link
here
and
what
I'll
do
is
throughout
this
presentation.
I'll
have
a
git
lab
repo
and
I'll
share
the
URL
for
that
repo
and
all
of
the
links
that
I
have
and
a
link
to
my
presentation
will
be
in
that
repo
I'll.
Put
that
all
in
before
the
end
of
the
talk.
B
B
The
way
I
think
about
kubernetes
is
that
you
can
have
whatever
infrastructure
you
want,
so
whether
that's
a
bare-metal
server
or
at
any
type
of
cloud
platform
and
kubernetes
is
an
abstraction
layer.
On
top
of
that,
that
does
all
of
your
container
scheduling
all
of
your
orchestration
manages
scaling,
and
so
you
don't
have
to
really
think
about
that
underlying
infrastructure,
or
it
allows
you
to
have
this
great
portability
where
you
have
a
cluster
on
AWS
or
a
cluster
on
IBM
cloud
or
on
bare
metal,
and
it
just
behaves
the
same
way.
B
B
Of
course,
you
are
going
to
want
to
do
some
type
of
application,
security
testing
to
make
sure
your
app
is
secured,
and
then
once
that
is
deployed
and
in
production
you
want
to
do
some
monitoring.
This
is
a
great
simplification.
I
think
that
the
tool
chain
could
get
broad,
but
I
just
wanted
to
show
this,
because
I
think
that
most
folks
that
are
familiar
with
get
lab,
this
kind
of
comes
down
to
what
does
get
lab
most
folks
that
are
familiar
with
get
lab,
know
that
get
lab
does
source
code
management.
B
So
you
it
handles
your
version
control,
it's
your
git
repos,
but
what
folks
may
not
know
is
we
also
have
a
really
really
robust,
CI
CD,
which
is
what
I
want
to
focus
in
today
and
the
at
CSC
dues
and
forms.
In
fact,
not
only
do
we
have
source
code
management
CD,
but
gitlab
is
actually
a
single
tool.
Actually
does
all
of
these
things.
It's
we
call
it
a
single
DevOps
tool
and
you
can
drop
the
chain.
In
fact,
we
have
this
graphic
on
our
home
page.
B
That
shows
these
are
all
the
things
that
we
have
shipped.
Our
functionality
has
grown
and
grown
and
grown,
so
we
started
out
just
as
source
code
management
in
2011
and
then
had
this
massive
accelerated
pace
and
there's
even
more
on
the
roadmap.
The
idea
is
like
how
how
did
you
get
such
a
big
product
and
how
did
that
grow
so
fast?
B
Well,
the
way
that
we
did,
that
is
through
a
very,
very
high
velocity
of
development
and
I,
attribute
that
to
being
open
core,
so
git
lab
is
an
open
court
means
that
our
core
product
is
open
source.
We
have
over
2200
contributors
to
that
open
source
project
and,
in
fact,
Dan
cone.
He
did
like
a
blog
post
here,
I've
linked
it
I'll
link
it
in
the
notes
that
talked
about
the
top
30
highest
velocity,
open
source
projects
and
Gil
lab
was
one
of
those
projects.
B
So
by
being
an
open
source
project,
we
have
many
many
folks
contribute
and
even
our
paying
customers.
We
share
the
code
of
the
the
paid
product
with
them
and
they
actually
even
contribute
back
to
the
project.
So
that
is
how
we've
been
able
to
at
this
high
pace
of
velocity
shift
so
much
functionality
and
have
this
this
product
that
spans
the
what
we
call
the
whole
DevOps
lifecycle.
So
I
show
that,
as
a
bit
of
background
to
say
as
I'm
going
through
the
demo.
This
is
our
perspective.
B
Our
viewpoint
is
that
when
all
of
these
things
on
our
single
application,
when
your
pipelines
are
together
with
your
code
and
your
your
issue
track
and
your
monitoring
there
are
some
nice,
interplays
and-
and
maybe
I'll
show
some
of
those
as
well,
so
with
that
I
really
would
just
like
to
jump
in
to
a
demo.
So
before
I
do
that
I
will
ask
a
question:
I'll
see
if
any
folks
are
hanging
out
in
the
chat.
B
What
I
like
to
do
is
I
like
to
set
up
right
now
a
CI
CD
pipeline,
and
so
my
question
to
the
folks
in
chat
is
starting
from
scratch.
How
long
on
average
does
it
take
you
to
build
a
CI,
CD
pipeline
and
so
I
wonder
if
folks
will
be
brave
if
anyone's
gonna
weigh
in
someone
says,
maybe
a
half
hour
a
couple
hours
and
now
we're,
depending
on
the
requirements.
B
We
have
a
couple
so
build
test,
deploy
less
than
five
minutes
using
some
different
tools,
so
one
line
and
a
yam
will
commit
so
that
this
is
really
good.
It
seems
like
there
is
a
wide
variety
of
experiences
here
and
I
would
continue
folks
to
maybe
continue
to
drop
in
some
chatter
to
share
a
story
about
why
it
takes
you
less
or
more
time,
there's
a
wide
degree
of
variance
what
we've
seen
is
in
order
to
build
a
really
robust
pipeline
it
can.
It
can
take
some
time
so
to
spin
up
something
quickly.
B
B
This
progress
and
the
one
thing
I'm
going
to
do
before
I
walk
through
the
code
is
I,
am
going
to
add
a
kubernetes
cluster
to
get
lab.
So,
let's
go
over
to
kubernetes
and
I'm.
Going
to
add
a
cluster
and
what's
nice
is
I
can
add
an
existing
cluster
any
type
of
cluster
at
all.
As
long
as
it's
what's
called
upstream
kubernetes
and
the
vast
majority
of
cloud
providers
support
these,
but
we
do
have
some
really
nice
integration
with
gke,
and
so
what
that
allows
me
to
do
is
basically
to
create
a
cluster.
B
So
when
one
does
not
exist,
I'll
call
this
one.
The
demo,
my
vironment
scope
is
going
to
be
this.
I
could
have
different
environments
and
get
labs,
so
I
might
have
a
staging
environment
in
a
prod
environment,
or
there
might
be
different
reasons.
An
asterisk
is
just
going
to
say,
use
this
cluster
for
everything
it's
integrated
with
gke.
B
So
if
it
knows,
I
already
have
a
demo
project
there
and
I'm,
just
gonna
leave
the
zone
and
machines
default
and
able
are
back
and
create
my
cluster,
so
this
usually
takes
I,
don't
know
about
five
minutes
to
spin
up
a
kubernetes
cluster.
So
this
is
the
the
view
point
here
is
if
I'm
just
starting
from
scratch.
Of
course
something
went
wrong
and
it
failed.
Let's
just
see
for
a
moment.
Yes,.
B
B
B
Credentials,
that's
a
that's
alright,
as
I
mentioned,
I
do
have
a
project
spun
up
for
just
such
an
occasion.
So
what
I
will
do
is,
let
me
just
go
really
quick.
I
am
gonna,
show
what's
in
this
project.
So
if
we
look
at
this
is
a
really
basic,
node,
app,
so
I
suspect,
there's
some
some
problems
with
creating
the
cluster
but
really
basic
node
app
based
on
Express.
So
there's
an
app
j/s
and
you
can
see
this
is
really
bare-bones
simple,
Express
app,
nothing
very
fancy
here.
B
This
is
the
same
project
and
what
I've
done
is
I've
enabled
the
kubernetes
cluster,
and
we
can
show
you
that
over
here-
and
so
here
is
where
I've
connected
that
cluster
and
then
I've
enabled
what
we
call
Auto
DevOps
and
the
way
I
think
about
this
is
DevOps
is
about
automating
things
that
would
normally
be
manual,
and
so
you
would
have
all
of
these
scripts
all
of
these
testing
scripts
and
all
these
deployment
scripts
and
when
you
start
to
automate
those
that's
a
key
tenant
of
DevOps.
But
what,
if
you
even
automated
the
automation?
B
And
so
then
you
get
Auto
DevOps,
where
you
just
get
pipelines
out
of
the
box,
so
there's
no
yellow
file
in
here
there's
no
pipeline
to
find.
But
if
I
go
over
to
my
list
of
pipelines,
I
can
see
that
I've
already
got
a
few
that
have
run
on
this
project,
and
so
looking
at
this
is
the
commit
and
I
can
look
at
this
pipeline,
so
just
by
enabling
Auto
DevOps
it
automatically
enables
a
pipeline.
B
It
can
show
me
what
the
runner
is
actually
executing,
and
so
in
order
to
explain
this
a
little
bit
further
I'll
pop
over
to
slides
just
for
a
moment
and
I
want
to
talk
about
the
gitlab,
Runner
and
the
architecture
so
that
as
I'm
describing
the
pipeline
and
how
its
deploying
into
the
cluster
it'll
make
a
little
bit
sense
of
how
it
works.
So
the
the
CI
CD
architecture
for
gitlab
is
that
your
main
gate,
lab
instance,
is
where
your
pipeline
is
defined.
B
This
could
be
either
in
a
yamo
file
which
I'll
show
a
little
bit
later
on
or
as
I
mentioned,
via
Auto
DevOps,
where
I
simply
enable
that
or
it's
enabled
by
default
when
I
add
a
cluster,
it
automatically
builds
a
pipeline
for
me
and
then
the
the
executor
or
the
agent
is
what
we
call
get
lab
runner
and
so
get
lab.
Runner
is
a
separate
project.
B
It's
a
go
binary
and
that's
going
to
pick
off
various
jobs
in
the
pipeline,
so
you
can
see
that
this
is
a
build
job
and
this
is
being
executed
by
the
runner.
So
what's
nice
about
this,
is
you
can
have
multiple
jobs
executing
in
parallel
and
another
runner
can
then
just
pick
up
the
job?
So
because
it's
a
go
binary,
it
means
you
can
install
it
on
any
platform:
Linux,
Mac,
Windows
or
basically
anywhere
that
will
compile
a
go
binary
or
any
anywhere
that
supports
docker.
B
You
can
run
a
git
lab
runner,
so
you
can
have
multiple
runners
and
they
can
go
and
pick
up
jobs,
but
the
other
nice
thing
about
this
architecture
is
that
runners
can
be
auto
scaling
and
so
by
using
auto
scaling,
and
this
uses
doctor
machine
so
any
cloud
platform
or
any
system
that
you
would
build.
That
uses
your
machine.
You
could
even
do
this
with
anywhere
that
uses
doctor
machine.
You
could
have
essentially
a
bastion
runner
that
will
then
spin
up
additional
runners
to
pick
up
more
jobs.
B
So
you
get
that
same
amount
of
auto
scaling
nicely
out
of
the
box
and
then,
when
there's
no
more
jobs,
execute
they
scale
down
to
save
on
costs.
So
this
is
the
architecture
that
is
in
the
runner.
So
maybe
the
pipeline
makes
a
little
bit
more
sense
when
it
kicks
off
this
test.
Phase.
It'll
kick
off.
You
know
both
the
coat
quality
and
the
test,
and
what
this
test
is
going
to
run.
Is
it's
going
to
run
what
is
in
my
test,
folder
and
I?
B
So
in
this
test
say
s:
you
can
see
that
inside
the
test,
folder,
it
is
just
has
a
really
really
simple
testified.
It's
going
to
make
a
request
out
to
the
app
it's
going
to
get
that
root
path,
and
it's
going
to
expect
it
to
say
welcome
to
Express,
which,
as
I,
showed
in
the
index
layout,
it
says
welcome
to
Express
and
I
would
say.
B
I
want
to
make
the
title
of
this
page:
the
CN
CF,
webinar
and
I
wanted
today
a
hateful
people,
that've
joined
me
on
webinar
today
welcome
to
the
CN
CF
webinar
and
in
addition
to
this,
if
I
just
made
that
change
that
my
test
is
gonna
fail.
So
I,
don't
I
no
longer
want
to
check
for
the
body
to
be
welcome
to
Express,
but
I'm.
Just
gonna
expect
a
200.
B
So
what
I
showed
you
here
coming
out
of
the
box
is
a
production
pipeline.
It's
build
test,
deploys
to
production
and
then
on
that
running
production
instance.
It
runs
some
performance
analysis,
but
when
I
create
a
merge
request
and
get
lab
and
a
merge
request
is
the
exact
same
thing
as
a
pull
request.
We
just
call
it
a
merge
request
because
you're
making
a
request
to
merge,
you
get
a
few
additional
stages.
So,
let's
take
a
look
at
this
merge
request
pipeline.
B
And
what
this
is
going
to
have
its
that's
gonna
have
to
build
the
test
and
this
review
stage.
So
there's
a
couple
different
differences,
so
one
is
review.
It
has
desks
in
front
of
performance
and
a
clean
up
stage.
So
the
main
differences
are.
This
review
stage
is
going
to
for
this
change
it's
going
to
because
it's
connected
to
kubernetes.
It's
going
to
spin
up
environment
just
for
this
merge
request.
B
So
for
this
one
branch,
it's
going
to
have
its
own
environment
in
kubernetes,
and
it's
going
to
spin
up
a
review
app
so
that
I
can
review
those
changes
now.
I'll
show
that
in
just
a
moment
the
other
thing
is
you'll
notice
that
a
bunch
of
additional
tests.
So
what
I
did
is
I,
went
and
made
this
project
public
and
with
git
lab
we
as
an
open
source
project
as
open
core.
B
We
want
to
support
other
open
source
projects
so
on
git
lab
comm,
we
allow
any
open
source
project
to
have
all
of
the
features
of
our
top
tier
for
free,
so
I'm,
showing
now.
There
are
some
features
and
get
labs
open
source
project
that
you
can
download
and
install
or
use
a
free
planet
get
lab
comm
and
there
are
some
features
that
are
part
of
our
paid
product.
B
But
if
you
have
an
open
source
project
and
you're
on
your
lab
calm,
you
just
get
those
for
free
anyway,
and
so
a
lot
of
those
include
automatic,
say,
container
scanning
dependency
scanning,
license
management,
static
and
static
application
security
testing.
Then
it
deploys
in
the
review
environment.
Then
it
runs
a
dynamic
application
security
test
on
that
running
environment
so
that
all
of
the
security
functionality
is
again
I
haven't
defined
a
pipeline.
I
haven't
done
anything
yet
I.
This
I
just
made
a
merge
request,
and
here
is
the
pipeline
that
it
pulls
up.
B
B
It
has
one
instance,
and
so
this
it
means
I
just
have
one
pod
scheduled
and
my
my
kubernetes
cluster
and
I
can
look
at
look
at
this
pod
and
these
are
the
pod
logs
within
kubernetes,
and
so,
if
there
was
something
funky
or
I
had
a
bunch
of
instances,
I
could
I
could
click
into
those
and
what
I
can
do
is
I
can
go
and
open
that
live
environment.
So
here
it
is
it's.
This
is
my
production
environment.
B
It's
got
this
old
generic
message
that
I
don't
like
very
much
but
in
my
merge
request,
I've
got
this
review
environment,
and
so
it's
fun
this
just
up
for
that
merge
request
that
I
can
go
in
and
look
at
that
review
environment.
So
here
it
says:
hey
you
want
to
pull
people
and
welcome
to
the
CN
CF
webinar.
So
this
is
not
just
showing
a
web
change,
but
because
it's
an
entire
environment,
it
means
you
can
test
the
differences
between
anything
at
all
on
your
code
or
deployment
process.
B
So
this
type
of
model
of
continuous
delivery
is
something
that
we
think
is
really
really
powerful
and
it's
something
that
kubernetes
enables
and
it's
why
we
at
gillip
have
engineered
this
tight
coupling
so
that
the
the
pipeline's
just
work
with
kubernetes.
This
is
something
again:
it's
kind
of
what
we
call
this
Auto
dev
off
experience.
You
can
use
git
lab
with
with
anything
you
can
deploy
to
bare
metal
if
you
want,
but
when
you're
deploying
to
kubernetes
and
connected
kubernetes
cluster.
This
is
the
experience.
So
what
happens
is.
B
Go
ahead
and
I'll
show
it
one
of
the
things.
So
one
thing:
that's
really
nice
is
in
this
merger
quest.
We
think
of
this
as
the
developers
view
of
the
world.
So
this
is,
of
course,
going
to
show
any
changes
in
the
code
where,
if
I
was
doing
code
review
for
a
colleague,
I
would
go
look
at
this
and
I
could
I
get
out
of
comments.
B
So,
in
order
to
move
faster,
we
want
to
shift
left
and
we
want
to
just
show
that
vulnerability
right
in
the
merge
request
with
the
code,
because
the
developer
is
going
to
be
able
to
see
oh
by
adding
this
I've
now
added
these
vulnerabilities,
and
this
is
something
that
either
the
security
team
or
the
developer
could
resolve,
but
they
can
click
in.
They
can
look
at
the
CVE
and
then
they
can
either
decide.
I
want
to
dismiss
this
I've
accept
this
vulnerability
or
I
can
see.
B
Thinking
about
this
idea
of
I,
like
the
Adam
says,
to
do
security,
this
idea
of
having
everything
integrated
one
tool
having
your
security
tool
showing
the
same
place
or
showing
the
same
view
from
the
merge
request
being
able
to
create
an
issue
to
remediate
that
later
on.
This
is
why
we've
put
all
of
these
things
into
a
single
application
instead
of
having
to
have
folks
integrate
with
all
of
these
other
points,
so
in
addition
to
getting
kubernetes
and
all
the
value
out
of
that
you
get
this
functionality
altogether.
So
this
looks
good
to
me.
B
B
It's
going
to
go
through
and
run
those
additional
tests
as
it
goes
off
and
deploys
to
production,
so
we'll
let
that
pipeline
chug
on
for
for
a
little
bit
and
we'll
let
that
one
go
and
what
I
do
want
to
show
is
what
does
this
look
like
if
I
now,
if
I
actually
use
code
to
go,
do
this
so
everything
I've
shown
up
to
this
point?
The
only
thing
to
make
that
happen
is
literally
to
add
some
code
and
make
a
merge
request.
Add
some
code
add
a
kubernetes
cluster
and
make
it
a
merge
request.
B
So
I
basically
just
commit
my
code
and
get
lab
has
created
a
pipeline.
For
me,
it's
added
all
the
security
testing.
It's
even
picked
up
some
basic
tests
and
it's
created
a
review
environment.
All
this
is
done
for
me,
but
this
is
not
just
magic
under
the
covers.
This
is
actually
all
nicely
defined
in
a
yamo
file
and
I
can
show
you
what
that
looks
like
so
the
way
that
Auto
DevOps
the
functionality
works
is
there's
no
docker
container
in
here,
but
as
the
script
is
running,
it
will
try
to
detect
what
language
this
is.
B
So
it
figures
out.
Oh,
this
is
a
node
app,
so
it's
going
to
use
a
node
container
and
some
other
things.
If
I
have
a
docker
file,
it
will
just
use
that
docker
file
and
do
everything
else
automatically
right.
The
same
thing
with
a
CI
llamó
file.
If
there's
a
CI
mo
file,
Auto
DevOps
will
use
that
and
will
file
first
and
then
implement
the
rest
of
functionality.
B
So
I'm
actually
show
you
what
that
code
looks
like
so
I'm
going
to
add
a
new
file
to
this
directory,
and
this
is
the
value
of
defining
pipelines
as
code.
So,
as
I
mentioned,
I
show
you
the
demo.
First,
you
see
everything.
That's
done.
All
of
that
was
done
via
this
ya
mole
definition,
so
you
can
see
that
you
can
choose
several
different
types
of
CI
templates
but
I'm
going
to
use
the
auto
dev
ops,
template
and
we're
gonna
go
ahead
and
commit
commit.
B
And
that
will
open
up
a
new
merge
request
to
use
the
DevOps
template
and
it
will
kick
off
this
pipeline
and
now
this
pipeline,
that's
running
in
this
murder
quest,
is
actually
running
off
of
this
file.
That
I
just
committed.
It's
not
running
off
of
the
auto
dev
ops,
but
it's
the
exact
same
thing.
So
let's
go
ahead
and
take
a
look
at
this
file
and
see
what's
actually
happening
in
and
unpack
what's
inside,
of
a
robustly
defined,
gitlab
CI
mo
file,
so
you
can
see
at
first
glance.
B
This
is
about
a
thousand
lines,
so
not
a
lot,
but
it's
not
skimpy
either,
and
so
what
all
that
this
auto
dev
ops
functionality
is
were
I
can
just
start
off
and
I
can
commit
my
code
and
everything
just
starts
running
for
me.
It's
just
a
nicely
defying
the
mo
file
and
I
saw
some
other
folks
that
are
already
experiencing
this
type
of
C
ICD
pipeline
say
that
it
takes
me
five
minutes.
I,
just
I
pop
in
my
llamo
file
and
I.
B
Go
because
it's
defined
as
a
template,
so
I'll
walk
through
some
of
what
the
syntax
is
and
how
these
things
are
built.
And
then
we
can
look
at
some
other
ways
that
you
can
use
these
as
composable
building
blocks.
So
to
start
out,
an
image
is
literally
just
going
to
be
a
container
image
so
as
a
base,
if
no
other
image
is
defined
is
going
to
use.
Alpine
Linux,
which
is
just
a
very,
very
small,
spelt
version
of
Linux
I.
B
Think
it's
like
five
megabytes,
so
there
might
be
a
different
image
to
find,
but
that's
just
going
to
be
the
base
image
and
then
I'm
going
to
find
some
variables
and
you'll
notice
here
that
again,
this
auto
dev
ops
template
is
designed
to
just
get
you
up
and
going
really
really
fast.
So
you
can
connect
that
kubernetes
cluster
and
just
be
up
and
going,
but
you
may
want
to
do
some
things
differently.
So,
for
example,
you
may
want
a
different
Postgres
password.
You
may
want
to
use
that
as
what
we
call
a
secret
variable.
B
Some
environment,
variables
and
I
can
make
sure
that
they
are
protected
and
so
anything
that
I
want
to
pass
in
as
credentials.
This
is
a
better
spot
for
them.
Of
course
you
need
to
input
these.
You
know
manually
as
opposed
to
having
them
a
configuration,
but
there's
a
few
other
ways
to
do
it.
You
could
have
it
in
a
separate
part
of
your
configuration
and
then
port
them
in,
and
then
you
can
also
we
just
released
this
feature
where
we
call
it
a
kubernetes
secret.
B
This
would
be
is
if
I
need
to
pass
credentials
into
something
that's
running
inside
my
cluster,
so
perhaps
a
service,
maybe
I've
integrated
with
some
type
of
service
like
let's
say
Twilio
and
I-
need
my
API
key,
but
my
application
running
in
kubernetes
needs
access
to
that.
I
could
use
this
kubernetes
secret.
So
after
defining
some
variables,
then
I
am
going
to
build
out
the
stages,
and
so
you
can
see
that
these
stages
map
to
what
you've
seen
in
this
pipeline
with
the.
B
Build
test
review,
DAST,
etc,
but
there
are
some
additional
files
that
we
are
some
additional
stages
in
the
file
that
we
didn't
use
yet
so
maybe
I'll
I'll
get
to
use
these
before
we
are
up
on
time,
but
you
can
see,
there's
a
canary
there's,
an
incremental
rollout
and
then
performance
and
cleanup.
So
first
you
define
the
stage,
and
then
you
define
jobs,
and
so
this
is
the
job
name
now.
B
This
can
be
any
arbitrary
name
that
I
want,
in
this
case,
I've
named
the
job,
the
same
thing
as
the
stage,
and
we
can
see
in
the
build
stage.
There's
only
one
build
job,
and
so
that's
why
the
stage
defined
for
this
job
is
build
in
the
test
stage.
There
is
a
test
job,
but
you
can
also
see
like,
for
example,
the
code
quality
job
is
in
the
test
stage.
We
can
also
define
here
a
docker
image
to
run
that
job
in
docker
services
and
so
for
gitlab.
B
A
service
is
essentially
a
separate
image
that
I
want.
That
can
talk
to
my
initial
image
without
me
having
to
build
everything
manually.
So
a
really
good
reason
to
do
this
would
be
as
if
I
wanted
a
database
available.
Let's
say,
Postgres
I
could
just
add
Postgres
as
a
service
that
way
I
don't
need
to
build
it
from
scratch.
In
that
step
and
case
this
one
is
using
docker
and
docker.
B
So
that's
what's
running
the
build
stages,
docker
and
docker,
and
then
these
scripts-
and
these
are
literally
shell
scripts,
as
you
saw
earlier-
and
you
could
see
it
running.
For
example,
in
the
build
stage
it
is
executing
set
up
docker,
and
that
here
is
where
that
script
is
defined,
and
so
in
this
file
inside
of
the
job
I've
just
made
it
a
very
simple
script.
Now,
I
could
add,
you
know
anything.
You
know
you
can
see.
This
is
literally
bash
commands
or
I
can
have
it
a
bit
more
sophisticated
and
organize
it.
B
So
a
script
is
literally
any
type
of
bash
scripting
and
then
I
can
even
define
it
as
a
function
and
and
reuses
it
to
do
code,
reuse,
and
then
we
have
a
keyword
only
or
except
this
means
it's
only
going
to
run
on
branches.
If
I
kick
off
a
pipeline
via
API
call,
it's
not
going
to
run.
It'll
only
run
on
branches
things
like
that,
and
then
this
one
is
interesting
and
let's
see,
if
we
can
make
use
of
this
here
is
the
idea
that
don't
run
this.
B
B
And
here
I
have
an
artifact
browser
where
I
can
download
or
I
can
browse
this
code.
Quality,
artifact
and
I
can
look
at
this
JSON
report
and
see
what
it
says
in
this
case
and
looks
like
everything
is
pretty
solid.
So
if
I
wanted
to
keep
this
artifact
it's
available
for
that
job
and
I
can
make
any
type
of
artifact
available
or
pass
it
on
to
the
next.
B
B
We
use
the
syntax
of
a
period
or
a
dot
to
create
what
we
call
a
hidden
job
in
our
CI
pipeline,
and
so
all
this
means
is
I'm
defining
a
job,
but
it's
it's
never
going
to
execute
so
I'm,
basically
just
using
this
as
a
template,
so
that
I
can
put
it
into
another
job
that
does
execute
again.
Coming
down
to
this
idea
of
reusable
composable
block.
Excuse
me:
I
can
build
a
set
of
scripts
and
in
this
case,
I
have
this
production
script
where
it
does
a
lot
of
things
and
I
know.
B
I'm
gonna
want
to
do
this
a
few
times
so
then
I
can
use
this
as
a
yeah
mol
functionality
or
a
bit
of
yeah
mol,
syntax
called
an
anchor
and
so
I'm
using
the
get
lab
hidden
job
and
a
yamo
anchor,
and
with
that
yeah
my
anchor.
It
allows
me
to
put
that
so
all
of
this
just
gets
injected
here
and
then
I
can
run
my
only
and
accept
so
that
allows
me
to
do
a
production,
deploy
just
continuous
delivery
or
continuous
deployment.
B
Sorry,
and
then
it
also
lets
me
to
say:
okay
I
want
to
do
manual,
so
this
one
has
a
when
manual,
which
means
I
need
to
click
a
button
in
order
for
it
to
go
so
with
these
small
primitives
stages,
jobs
and
templates.
This
type
of
template
really
build
something
very
sophisticated,
and
you
can
see
that
you
could
take
this
file.
It
has
a
lot
of
stuff
in
there
and
now
you
can
start
to
build
it
out
or
compose
it.
B
B
B
You
may
want
your
operations
team
to
actually
manage
that
file
and
have
individual
product
teams
put
it
into
their
service,
and
then
they
can
add
additional
things,
but
you
have
some
type
of
master,
that's
managed
by
by
an
outside
team,
but
essentially
what
I've
done
in
this
project
is
I
created
a
new
project
and
instead
of
node
I,
think
this
time
I
created
a
spring
app
or
no
I'm.
Sorry,
this
is
a
ruby
app,
so
completely
different
language.
B
I
made
I
just
imported
this
as
a
ruby,
app
and
I
added
a
gitlab
CI
yellow
file,
but
all
this
does
is
it
uses.
This
include
clause,
and
it
says,
hey,
go
over
to
this
other
project
and
suck
in
that
Gil,
AB
CI
mo
file
and
then
I
want
to
set
a
few
different
variables
here.
So
first
I
want
to
bump
up
the
replicas
to
ten.
So
instead
of
one
pod,
I
want
to
have
ten
pods
that
are
running.
Maybe
four.
B
Where,
in
this
case,
it
emitted
the
code
quality,
but
it
did
the
rest
of
my
security
testing,
it
ran
the
build
and
now
it's
waiting
to
rule
this
out.
And
so,
if
I
look
at
my
environments,
I
can
see
that
I
haven't
deployed
anything
to
production.
Yet,
but
here
are
my
10
instances
in
the
review
app
and
so
let's
go
ahead
and
roll
this
out
to
10%
and
we
can
watch
that
as
it
goes.
B
While
this
runs
off
I
do
want
to
show
one
of
the
link
that
we
do
a
lot
of
things
with
health
charts,
so
something
I
didn't
quite
show,
but
is
being
able
to
one-click
install
different
applications,
things
like
helm,
tiller
and
ingress
and
the
cert
manager,
and
we
do
that
via
helm,
charts,
so
I
can,
while
this
builds,
I
can
actually
show
that
in
the
so
here
inside
the
kubernetes
cluster.
When
you
add
a
cluster,
what
it
does
is
it
lets
you
just
click
to
install
these
things.
B
Now,
if
you're
running
this
in
production,
you're
probably
gonna
manage
this
all
yourself
anyway,
but
the
idea
is
to
extract
this
for
the
beginner,
make
it
really
easy.
So
just
go
ahead
and
install
helm,
install
ingress,
install
the
cert
manager
install
Prometheus,
and
we,
of
course,
do
that
I'll
be
at
home.
Charts
which
are
in
this
and
I'll
share
the
stock,
and
so
we
can
see
that
that
job
succeeded.
B
So
I
should
now
be
able
to
go
to
environments,
although
the
pipeline
is
still
running,
but
here
I
have
one
instance:
it's
rolled
out
to
10%
I
can
go
and
look
at
these
logs
I
can
say
you
know
this
looks
solid.
I
can
go
and
test
test
that
open
up
the
live
environment.
It
probably
is
404
for
me
for
some
reason:
let's
just
take
a
look
at
monitoring.
B
It's
waiting
for
that
data
there,
but
let's
go
ahead
and
kick
that
out
to
let's
say
50%
and
it's
going
to
do
a
roll,
a
roll
out
so
inside
of
this
inside
this
pipeline.
So
that
is
an
example.
Here
is
some
of
these
metrics
that
are
coming
out
of
Prometheus
now.
This
is
an
example
of
taking
the
same
exact
yamo
file.
B
You
know
in
the
pipeline
now
I'm
rolling
out
to
50%
and
it's
a
manual
roll
out
and
it's
on
a
ruby
versus
on
a
node,
so
with
all
of
that,
I
will
just
show
a
few
more
slides.
So
what
I've
kind
of
showed
you
today
is
some
basic
building
blocks.
If
you
have
a
few
Legos,
you
can
build
something
really
simple
get
up.
B
It
started
pretty
darn
fast
and
start
to
customize
it,
of
course,
with
these
primitives
and
composable
building
blocks,
you
can
then
build
something
really
sophisticated
and
someone
who
has
done
that
is
the
CNC
FCI
working
group,
and
so,
if
you've
seen
this
dashboard,
it's
pretty
impressive
and
it
is
running
on
git
lab
for
the
CI.
So
this
is
a
really
complex
thing.
B
Where
this
working
group
said
hey,
we
want
to
run
cross
project
cross
cloud,
so
I
want
to
see
how
kubernetes
prometheus
core
D&S,
linker,
D,
envoy,
etc,
perform
on
AWS
and
Azure,
and
GCP
and
IBM
cloud
and
OpenStack
and
I
can
go
and
look
at
any
of
these
jobs.
So
here
this
one
was
successful
and
this
is
their
instance
of
gitlab,
which
is
the
similar
interface
to
what
I've
just
been
showing
you,
where
you
can
review
that
job.
B
You
can
browse
the
artifacts
for
that
job,
and
so
this
is
something
that's
a
bit
more
complex
that
is
built
out
of
those
primitives.
So
with
that
I'll
leave
you
with
hey,
what's
coming
next,
in
addition
to
be
an
open
source
company,
we
also
do
a
lot
of
things
publicly.
So
we
keep
all
of
our
issue.
Trackers
public
and
all
of
our
vision
and
roadmap
are
public.
So,
as
I
mentioned,
I'll
share
these
links,
and
here
you
can
basically
go
in
and
see
what
are
we
building
what's
coming
up
in
future
releases?
B
B
There's
a
page
on
our
pricing
page.
So
if
you
go
to
about
about
docket,
lab
calm
and,
for
example,
there's
a
link
here
that
says
see
all
features,
and
this
will
show
you
a
comparison
of
what's
in
the
free
tier
and
what
specific
features
are
in
various
tiers.
So
I
just
went
ahead
and
showed
the
top
tier,
and
my
rationale
for
that
was
that,
if
you
are
an
open-source
project,
you
can
just
go
ahead
and
have
a
public
project.
So
any
of
these
features
that
you
want
to
test.
B
B
B
B
A
B
So
that
is
a
huge
question:
they're
using
there's
a
lot.
You
can
see
that
there
was
so
talk
kind
of
talking
about
those
primitives
each
each
one
of
those
things.
So
sassed
is
like
its
own
set
of
security,
application
testing
and
at
the
high
level
there
was
a
security
company
named
gymnasium
and
we
felt
that
gymnasium
was
really
doing
the
best
at
dependency
tree
graphing,
and
so
the
idea
here
is
I,
have
a
project
and
I've
NPM
imported
a
module
and
that
imports
a
module
that
imports
a
module.
B
The
dependency
tree
goes
really
really
deep
in
seven
levels.
Deep
is
a
vulnerability.
I
didn't
know
about
so
gymnasium.
Had
this
really
great
dependency
tree
resolution,
we
acquired
that
company
and
ported
that
gymnasium
feature
and
that
started
our
security
team.
Since
then,
we've
built
a
ton
of
security
functionality
and
the
a
great
way
to
get
to
all
of
that
stuff.
Because
of
course
not
only
is
the
code
open
source,
but
the
roadmap
and
such
so
you
can
see,
for
example,
here
are
links
on
the
home
page
in
this
graphic
I
show.
B
But
if
you
click
on
this
coming,
you
can
see
this
is
the
direction
for
get
labs
secure
what
we
categories
we
have,
what
we
shift
in
and
that's
a
that's
a
launching
off
point
to
see
the
different
bits
of
functionality.
So,
for
example,
just
that
quickly
static
application,
security
testing
is
I'm.
Gonna
scan
the
code
itself
and
see
if
there
are
patterns
in
there
that
are
known
to
cause,
wonder,
abilities,
dynamic
application.
Testing
is
I'm
going
to
deploy
that
into
environment
and
scan
that
running
that
running
code
right
dependency
scanning
is
I'm.
Gonna.
B
Look
at
that
tree
and
say:
ok,
you
have
a
something:
a
security
module
module,
seven
layers
deep
that
has
a
vulnerability
license
management
would
be
what
open
source
licenses
do.
I
have
there's
some
more
here.
Some
of
these,
like
fuzzing
I
a
star
on
the
roadmap,
but
I
will
add
this
link
into
my
thank
you.
Repository.
A
B
Can
bring
your
own
container
registry
so
you
can
use
docker
hub
or
you
could
use
any
container
registry.
You
want
in
fact
a
lot
of
folks
in
aggregate
lab
with
other
things.
So,
for
example,
if
you
wanted
to
use
something
else,
as
your
code
repository,
let's
say,
bitbucket
or
github,
or
even
just
your
own,
get
running
on
a
server,
and
you
then
want
to
use
get
labs,
CI
CD.
You
could
use
most
of
the
things
that
I
show
today.
Certainly
the
CI
CD
and
just
have
your
get
somewhere
else.
B
B
Yes,
so
obviously
I
don't
recommend
having
environment
variables
in
the
code.
Right,
don't
commit
secrets
to
your
code,
but
there
there
are
a
few
different
ways
to
do
this.
So
essentially
you
could
have
a
secrets
file
in
a
you
know,
in
a
private
repo,
that's
that's
not
accessible,
publicly
and
whatnot
and
then
import
that
in
or
suck
that
in
that
would
be
one
way
to
do
it
or
you
could
add
secrets
into
get
lab
and
those
secret
variables.
A
B
So
the
auto
dev
ops,
not
per
se,
but
it
is
essentially
what
it's
doing
is
its
running.
That
file
that
I
showed
so
the
way
to
get
to
that
file,
and
maybe
I
will
even
link
that
in
here
in
the
repo
you
can,
you
can
actually
see
it
in
the
repo
and
it's
literally
a
so.
This
I
will
link
my
other
repo,
which
also
has
the
file.
B
So
let
me
do
this,
so
these
are
my
other
other
repos,
but
yeah
it's
it's
literally.
It's
just
a
template
and
if
you
go
to
add
a
new
file,
as
you
saw
earlier
in
the
webinar
and
add
a
file
from
the
template,
you
can
just
choose
that
Auto
DevOps
template,
so
that
is
it's
not
generating
that
it's
all
the
way
around.
It's
that's
all
specified
in
the
mo
file
and
auto
DevOps
is
sucking
it
in
okay.
A
B
Absolutely
so
that's
a
really
good
question.
There's
a
couple
ways
to
do
that,
so
we
I'm
showing
you
at
the
project
level
attaching
a
project
to
a
cluster,
but
we
also
have
group
level
clusters.
So
this
you
know
you
would
create
a
git
lab
group
and
that
would
have
many
projects
underneath
it
and
then
each
of
those
projects
could
deploy
into
that
cluster.
B
So
you
might
allow
most
of
your
projects
to
deploy
into
your
let's
say
stage:
cluster
your
dev
cluster,
but
only
a
particular
release
team
has
access
to
deploy
into
the
prog
cluster,
so
those
could
be
managed
as
a
group
level.
That's
what
I
recommend,
but
what
you
can
also
see
is
that
at
a
at
a
project
level
I
can
just
add
another
cluster
and
I
believe
this
is
a
paid
feature.
B
A
Awesome
well,
thank
you
so
much
today,
William
for
your
great
presentation.
We
appreciate
everyone
joining
us
today
and
we
look
forward
to
seeing
you
again
soon.
I
I'm,
sorry,
I
normally
would
tell
you
when
the
next
one
is,
but
I
don't
have
the
details
on
that.
Yet
so
see
you
again
soon
and
have
a
great
day.