►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Trickle
in
yet,
but
let's
go
ahead
and
get
started.
Does
that
sound
good,
so
welcome
folks?
This
is
the
kubernetes
clinic
on
powering
your
infrastructure,
with
git,
ops
and
git
lab
go
ahead
onto
the
next
slide
here,
abubakar
we're
going
to
start
with
a
quick
poll.
Some
people
are
still
coming
in
so
results
all
I'll
read
off
where
we're
at
but
tell
us
where
you
are
on
your
kubernetes
journey.
So
we
know
how
to
tailor
this.
A
We
do
ask
this
every
time
if
you've
been
a
repeat
attendee,
but
just
trying
to
have
a
good
feeling
for
where
folks
are
at
for
who's
attending
this,
so
that
that
poll
should
be
up
on
your
screen
right
now,
we'll
give
it
a
few
seconds
and
then
close
that
and
I'll
read
you
the
results
historically,.
B
A
Finding
that
the
vast
majority
of
people
even
attending
these
and
our
other
events
are
pretty
early
in
their
kubernetes
journey,
they're
just
getting
started
starting
to
fiddle
with
things.
So
all
right,
we
can
go
on
and
I'll
wait
for
dave's
going
to
collate
those
results
in
the
background
and
send
them
to
me
and
let's
see
oh
yeah,.
A
In
looks
like
about
three
quarters
of
you
are
still
learning
about.
A
quarter
of
you
are
running
kubernetes
in
production,
so
that's
gives
us
some
feeling
there.
So
abu
bakr,
you
want
to
introduce
yourself
as
the
speaker
today
then
I'll,
introduce
myself.
B
Yeah
sure
thank
you,
I'm
abbakar
siddiq
ango,
I'm
originally
from
nigeria,
but
moved
to
the
netherlands.
Recently
I've
spent
most
of
my
career
in
community
development,
organizing
meetups
and
training
and
mentoring
other
members
of
the
community,
especially
in
sub-saharan
africa,
but
since
last
year
I've
moved
to
a
full-fledged
devops
role
and
their
very
role
at
kit
lab
helping
the
developer,
evangelism
team
work
better
and
faster,
and
also
evangelizing
with
focus
in
the
cloud
native
ecosystem
communities
and
so
on.
I'm
also
a
certified
communities
administrator.
A
Nice
yeah
well
and
thanks
for
being
with
us
for
this
today,
abu
bakr.
I
appreciate
it
I'm
kendall,
so
I'm
president
at
fairwinds,
which
we'll
tell
you
a
little
bit
about
in
just
a
minute,
but
I
was
the
first
hire
here.
So
I've
been
involved
in
the
kubernetes
landscape
for
a
while,
we've
been
kubernetes
only
as
a
company
for
about
four
and
a
half
years,
which
was
a
little
too
early
to
the
market.
A
Kubernetes
was
just
getting
started
when
we
pivoted
that
direction
as
a
company,
but
yeah
I've
been
been
involved
in
just
about
every
role
in
a
company.
That's
focused
on
kubernetes,
except
for
hands-on
keyboard
engineer.
I
just
haven't
written
meaningful
code
in
a
very
long
time.
So
when
I
dig
into
the
yaml,
everything
gets
messy,
but
you
can
go
on
to
the
next
slide,
so
real,
quick
about
kubernetes
or
about
about
kubernetes
about
fairwinds
and
then
I'll
turn
it
over
to
abu
bakr.
A
Fairwinds
is
a
kubernetes
enablement
company,
so
we
we
offer
enablement
platform
things
all
around
that.
So
we
have
services
hand
us
your
infrastructure,
we'll
make
your
infrastructure
problem
go
away.
That's
usually
smaller
to
mid-sized
businesses
that
are
willing
to
or
not
willing
to
interested
in
giving
over
the
entire
ownership
of
their
infrastructure.
So
we
run
24
7
pager
on
the
infrastructure,
make
sure
everything's
up
build
you
a
kubernetes
infrastructure,
that's
customized
to
your
needs!
That's
our
core
service!
It's
a
managed
service!
Long
term
partnership
is
what
we're
looking
for
there.
We.
B
A
A
sas
offering
called
fairwinds
insights
that
does
policy
driven
configuration,
validation.
Basically
so
many
people
out
there
running
kubernetes,
but
it's
a
new
paradigm.
It's
complicated
it's
hard
to
know.
If
what
you're
doing
you're
doing
right
and
that's
where
fairwinds
insight
sits,
it
runs
on
your
cluster
reveals
to
you
all
kinds
of
things
from
security,
efficiency
and
reliability
fix
this.
Here's!
How
change
this
optimize
that
and
then
it
also
has
policy
pieces.
So
you
can
write
custom
policy
to
enforce
what
gets
deployed
into
your
kubernetes
clusters
across
the
or
across
an
organization.
A
B
Yeah
hi
everyone
today
I'll
be
talking
about
how
you
can
use
githubs
with
gitlab
to
find
infrastructure
first
about
gitlab
gitlab
is
an
all-in-one
platform
for
your
devops
needs
right
from
you
coming
up
with
an
idea
straight
to
production
and
monitoring.
We
have
quite
a
lot
of
solution
that
you,
as
a
company,
can
only
maintain
on
build
one
invoice
for
all
your
devops
lifecycle
now
like
introduced
earlier.
I'm
a
developer,
evangelism
program
manager
at
gitlab.
Most
people
ask
me:
what
do
you
do
in
that
role
like
like?
B
Okay,
we
have
developer
evangelism
team
members
who
focus
on
evangelism.
My
job
is
basically
to
make
sure
they
are
able
to
do
their
jobs
right,
handle
all
the
metrics
and
everything
for
them.
So
they
can
talk
more
and
get
more
customers
for
gitlab
yeah
today
I'll
be
talking
mainly
about
githubs
and
how
you
can.
What
is
it?
Why
do
you
need
it?
B
B
The
first
is,
everyone
knows,
or
almost
everyone
is
getting
to
know
that
now
with
tools
like
terraform
ansible
chef,
you
can
write
your
infrastructure
as
code
right
from
provisioning,
all
your
infrastructure
to
configuring
them
with
the
right
services
and
everything
that
is
necessary,
which
is
infrastructure
of
as
good
as
already
done
by
terraform
and
the
rest.
But
what
happens
when
new
changes
need
to
be
made
to
your
infrastructure?
The
game
made
mistakes
happen.
B
How
do
you
revert
back
to
the
whole
state
of
your
infrastructure?
How
do
you
see
the
growth
of
your
infrastructure?
The
different
versions
that
happened
along
the
way,
that's
where
git
comes
in
git,
allows
you
to
use
the
normal
tools
you
are
used
to
before.
Writing
your
code.
You
write.
We,
your
infrastructure
would
be
that's
desired
state.
B
Then
you
use
normal
tools
that
we
are
used
to
in
version
control,
which
includes
we
call
it
match
request.
Mr
github
calls
it
pull
request.
You
write
your
code.
Make
changes
to
your
infrastructure
as
code,
submit
your
merge
request
for
code
reviews
within
your
team.
It's
always
a
good
idea.
Even
if
you
are
the
boss
for
someone
else
to
review
the
changes
you
are
making
for
second
opinion
or
any
other
thing.
So
once
you
do,
that
then
comes
in
cicd.
B
Cicda
helps
you
to
be
able
to
test
the
changes
you've
made,
for
example
with
terraform.
We
have
terraform
plan
where
you
first
see.
Okay,
what
are
the
changes
that
are
going
to
happen
or
a
dry
run
for
ansible?
You
see
all
the
necessary
changes
that
are
going
to
happen.
What's
going
to
be
removed,
what's
going
to
be
added
and
what,
if
in
case
there
is
any
destructive
action,
that's
going
to
be
performed?
You
are
aware
before
any
changes
is
made,
then
you
move
to
continuous
deployment
or
delivery.
B
Continuous
deployment
is
where,
as
soon
as
all
tests
passed,
it
just
deploys
or
executes
whatever
it
needs
to
do.
But
delivery
is
where
you
have
to
go
in
check.
Okay,
even
if
the
test
has
passed,
you
still
want
to
do
it
manually
to
make
sure
nothing.
Bad
goes
wrong.
So
that's
where
all
the
different
components
that
we
are
already
used
to
comes
together
to
make
well.
A
A
That's
going
to
make
all
your
problems
go
away
right,
but
I
mean
it
is
best
practices
around
that
and
then
you
know,
get
ops
is
just
another
best
practice
it's
taking
an
existing
devops
best
practice,
which
is
infrastructure
as
code
and
then
creating
a
new
process
for
that
within
git
right
I
mean,
instead
of
I
think
that
some
companies
well.
First
of
all,
I
think
a
lot
of
companies
find
basic
devops
ideas
outside
their
reach,
like
it
looks
great
on
paper,
but
they
can't
get
there.
A
But
then
you
know
git
ops
is
this
next
level
where
okay,
we've
got
infrastructure
as
code,
maybe,
but
then,
once
we
deployed
that
we
clicked
some
things
in
a
gui
and
now
our
infrastructure,
as
code
doesn't
match,
what's
actually
going
on
in
our
infrastructure
right
and
that's
what
this
is
seeking
to
solve.
Is
that
problem
right,
yeah.
B
Exactly
in
infrastructure
as
codes,
the
code,
you've
written
for
your
infrastructure
is
like
the
desired
state.
You
want
your
infrastructure
to
be,
but
most
times
anything
can
happen,
especially
with
kubernetes.
Some
board
might
have
gotten
destroyed,
or
some
things
might
have
happened
now.
Your
actual
stage
is
no
longer
matching
to
infrastructure
desired
states
so
with
githubs.
A
B
Yeah,
exactly
and
one
of
the
beautiful
things
about
githubs
are
the
direction
the
industry
is
moving
towards.
It's
no
longer
you
waiting
for
things
to
happen
before
you
fix
it.
It's
now
moving
towards
the
infrastructure
itself.
The
githubs
process
itself
should
be
able
to
recognize
when
something
has
happened,
then
pulls
the
desired
state
and
makes
the
correction
sometimes
even
without
necessarily
triggering
a
pager
duty
for
you
to
come
and
fix
things,
but
just
to
let
you
know
that
okay,
this
happened,
and
this
is
how
it
has
been
fixed.
B
Yep
yep
sounds
good
now
quickly.
Next,
okay,
okay,
thank
you.
Now
next
thing
is
how
does
github's
compare
to
infrastructure
as
code
or
almost
everything
now
is
going
to
code?
You,
your
configuration
as
code,
your
infrastructure
itself,
as
code,
almost
anything
even
to
the
extent
of
we
now
have
service
providers
that
allows
you
to
deploy
infrastructure,
metal
infrastructure.
B
Where
you
have
the
physical
devices,
you
don't
have
to
go
to
the
store
to
buy
the
devices
your
server
hold
on
amazon,
just
for
you
to
write
some
code
and
it
will
be
deployed
in
one
way
or
the
other.
Now
githubs
uses
infrastructure
or
everything
as
code
with
necessary
best
practice
like
we've
defined
earlier,
to
make
sure
your
infrastructure
is
up
up
to
date,
almost
every
time,
and
if
you
want
automated.
Like
I
explained
when
kendall
was
asking
the
question,
you
can
move
to
a
continuous
deployment
strategy
where
it's
not
any
time.
B
A
fault
happens
in
your
infrastructure
that
you
will
have
to
come
and
fix
it,
but
when
any
time
an
issue
of
course,
processes
can
be
on
ground
to
fix
things,
and
it's
I'll
explain
later,
where
the
pool
strategy
that
most
people
are
shifting
towards
most
times
our
ci
cd
is
still
using
the
push
environment.
Where
a
strategy
where
you
write
your
code,
you
have
your
ci
runner,
you
push
your
code,
your
cr-runner
runs
it
and
it
deploys
the
ci
runner
or
whatever
ci2
you're
using
has
to
the
code
has
to
be
pushed
to
it.
B
For
you
to
do
anything
needs
to
do
that
has
a
lot
of
security
challenges
and
problems,
especially
for
people
who
walk
behind
a
nut
or
have
some
security
requirements
with
the
new
githubs
process
that
is
happening
now.
The
pool
strategy
is
used.
The
runner
or
whatever
ci
that
is
handling
your
ci
cd,
is
sitting
within
your
infrastructure
and
constantly
monitors
any
change
that
has
happened.
B
It
pulls
the
new
update,
the
new,
manifest
for
the
new
changes
and
it
implements
it.
It
can
also
do
status
checks
and
other
health
checks
within
your
infrastructure
to
make
to
actually
determine
if
the
desired
stage
has
changed
in
any
way
and
it
pose
changes
or
pose
whatever
new
updates
that
is
required
to
fix
the
problem.
So
that's
the
major
difference
between
what
gitops
is
and
what
infrastructure
has
code
is
now.
B
Basically,
github's
infrastructure
has
code
downright
now.
Let's
move
to
the.
Why?
Why
exactly
do
you
need
githubs
itself?
First,
the
first
component
of
github,
which
is
everything
has
code?
Let
me
just
put
it
that
way.
Is
you
get
the
benefit
of
being
able
to
version
your
infrastructure
or
your
application,
and
you
can
work
collaboratively
within
your
team?
You
can
have
a
team
who
basically
works
on
your
application.
B
The
next
thing,
which
is
part
of
the
benefits
you
get
with
version
control,
is
the
mean
time
to
resolve
is
much
more
shorter
because
you
already
have
everything
documented.
You
can
easily
roll
back
when
it
an
update
that
was
pushed
causes
a
problem.
You
can
easily
roll
back
or
revert
whatever
commits
that
was
done,
that
messed
things
up
so
and
the
fact
that
you
have
different
versions
of
your
application.
You
can
easily
know
which
version
was
working
and
which
one
version
is
feeling
and
move
roll
forward
or
backward
as
necessary.
A
Yeah
then,
the
the
roll
back
roll
forward
and
it's
all
tied
into
the
self-documented
environment
like
if,
if
you
know
the
reason,
that's
significant
right,
somebody
makes
a
change.
It's
in
your
infrastructure
is
code
if
they
had
made
the
change
in
a
gui,
and
it
wasn't
documented.
Then
when
something
goes
wrong,
you
don't
know
what
was
changed,
especially
if
somebody
else
changed
it
and
I'm
on
pager
when
something
goes
wrong
versus
it
all
being
in
code.
A
B
B
He
couldn't
also
fix
it
on
time
because
he's
not
too
familiar,
he
was
running
some
backup
configuration
and
that
backup
configuration
deletes.
The
infrastructure
then
restores
it
back
any
infrastructure
there
and
restores
it
back.
So
he
kept
pressing
the
up
key
on
his
terminal,
so
he
ended
up
retrying
the
backup
process
even
before
it
has
ended
so
it's,
but
when,
if
you
are
using
githubs,
he
doesn't
have
to
worry
or
concern
himself
about
okay.
B
What
exactly
is
happening?
The
first
thing
he
would
check
is
okay,
which
update
was
done
and
immediately
he
can
revert
back
now.
The
next
thing
is
automation,
as
developers
and
devops
engineers
and
infrastructure.
Almost
everyone
you
take
loves
to
automate
almost
anything.
There
was
a
memory.
I
saw
earlier
that,
okay,
you
want
to
do
something.
B
You
spend
five
minutes
on
it.
You
notice.
Okay,
I
can
automate
this.
You
spend
the
next
one
hour
trying
to
automate
something
you
will
have
probably
done
within
five
minutes.
It's
because
we
all
love
automation,
okay,
next
time,
I
don't
have
to
do
it
manually
since
I've
automated
it
same
thing
with
github's.
Here
you
can
make
sure,
like
I
mentioned
earlier
anytime,
any
change
or
any
new
development,
maybe
yeah
bumping
up
to
a
newer
version,
or
there
are
certain
security
challenges
that
are
called.
B
B
B
One
thing
that,
although
it's
becoming
lesser
recently-
but
one
thing-
that's
a
major
issue,
especially
when
you
are
using
github-
is
privileged
escalation.
Does
this
particular
developer
have
access
to
the
environment
he
needs
to
work
with?
Does
he
have
access
to
the
canary
environment?
Does
he
have
access
to
the
production
environment?
B
Probably
someone
gets
fired
and
he
feels
like
okay.
I
think
I
need
to
nuke
the
infrastructure
of
this
company
and
he
decides
to
go.
Make
changes
in
the
production
repo.
That's
going
to
be
disastrous,
so
using
githubs
with
version
control
allows
you
to
set
up.
This
person
can
only
make
changes
to
the
repo
he
cannot
push,
he
can
do
tests,
but
he
cannot
push
the
production.
It's
only
this
set
of
people
that
can
deploy
that's
continuous
deployment
that
can
deploy
to
live
environment.
B
A
And
this
is
this
is
actually
two.
You
know,
we've
seen
a
lot
of
traction
in
our
software
at
this
stage
because
being
able
to
if
anybody
can
ssh
into
any
box
in
your
infrastructure
and
make
changes,
you
have
all
kinds
of
problems
happening
real
quick,
but
if
the
entire
infrastructure
is
managed
as
code
and
what
can
be
deployed
into
the
infrastructure
is
all
gated
by
git,
then
you
can
set
permissions
and
policy
and
all
of
that
all
the
way
down
at
the
code
level
so
that
it's
not
deployed
into
the
infrastructure.
A
B
Yeah
exactly
you
need
to,
and
there's
also
these
feature
in
git
lab
environment,
where
you
can
box
certain
branches
into
specific
environments
anytime,
any
developer,
because
most
of
the
developers
want
to
test
what
they've
done.
So,
let's
say,
for
example,
you
have
a
test
branch
anytime.
Any
commit
is
done
to
the
test
branch,
it's
restricted
to
the
test
environment.
So,
and
probably
you
already
have
some
kubernetes
clusters
or
some
environment
test
environments
already
fixed
to
that
test
environment.
B
It's
easy
for
them
to
build
and
there's
another
environment
that
you've
set
that
okay,
anytime,
someone
merges
to
the
staging.
So
this
is
the
infrastructure
to
use,
and
these
are
the
set
of
individuals
that
need
to
be
able
to
approve
or
confirm
that
that
should
proceed.
Then
you
can
have
like
a
like
kendall
mentioned,
a
production
area
that
needs
more
security.
Even
if
you
require
the
cto
should
be
the
last
person
to
hit
the
button
for
it
to
deploy,
you
can
make
sure
for
it
to
even
get
merged.
B
Probably
an
engineering
manager
has
to
review
it
and
make
sure.
Okay,
everything
is
fine.
It
gets
merged
after
getting
matched.
Another
person
probably
needs
to
okay
deploy
so
that
there's
several
levels
of
checks
and
balances,
because
in
most
companies,
even
if
mistakes
are
bound
to
happen
and
it's
part
of
the
learning
process
but
being
able
to
manage
those
mistakes
and
not
allied
escalate,
is
one
of
the
responsibilities
of
any
company
using
any
form
of
infrastructure.
B
Now
the
next
thing
is
the:
how
first
this
is
how
a
normal
conventional
cicd
pipeline
looks
like
with
gitlab.
First,
you
create
an
issue,
that's
the
ideal
stage.
You
have
some
feature
you
want
to
implement,
you
create
a
mod
request
and
you
can
set
the
magic
quest.
Okay,
once
this
is
done,
it
should
close
automatically
close
this
issue.
Once
this
mod
request
is
matched,
it
means
it
has
resolved
this
issue.
You
mix
your
commits.
The
comments
appear
under
the
merge
cis
runs
any
necessary
tests
that
is
required.
B
B
It
gives
a
long
report
of
all
the
necessary
changes
that
will
occur
in
your
infrastructure.
Then
you
proceed
to
where
peer
review
and
discussion
within
the
merge
request.
You
can
add
a
comment
and
set.
Is
that
all
these
questions
within
the
match
request
must
be
resolved
before
it's
allowed
to
match
that
way.
If
there's
any
pending
issues
it,
the
magi
request
will
not
be
allowed
too
much
that,
and
you
must
make
sure
once
every
comment
that
is
included
has
been
resolved.
B
Everyone
is
notified.
Okay,
these
are
the
changes
that
have
been
made
by
email
or
by
slack
integration.
Approval
comes
in
then
the
continuous
deployment
takes
off
and
deploys
to
production.
Now
for
githubs,
it's
not
just
you
committing
any
code.
It's
you
working
with
things
like
terraform,
ansible
or
cisco,
or
any
type
of
environment
that
you
you
are
using.
It
can
also
be
kubernetes
yaml
files
where
you've
or
some
helm,
charts
the
way
you've
defined
the
entirety
of
your
infrastructure,
for
example
like
gitlab
itself.
I
once
worked
with.
B
We
were
speaking
with
kendall
earlier
about
visits
to
prague.
The
customer
I
went
to
see
in
prague
was
a
customer
that
was
using
gitlab
to
maintain
gitlab
more
like
they
have
the
home,
chats
that
configures
gitlab
and
everything
necessary.
B
C
B
They
and
they
are
running
the
gitlab
on
kubernetes
itself,
so
new
changes
come
in
new
ports
get
deployed
while
they
are
still
using
gitlab.
It's
a
nice
way
to
be
able
to
manage
your
infrastructure
even
to
me,
even
gitlab
itself
can
be
managed
with
githubs
to
make
sure
you
know
every
single
change
that
is
occurring
and
every
single
issue
that
is
happening
now,
not
just
making
changes.
Of
course,
when
you
get
to
the
review
app,
you
want
to
make
sure
the
change
you've
made.
B
Probably
a
new
version
is
out.
You
don't
want
to
just
want
to
push
it
out
straight
to
put
for
everyone
within
the
company
and
break
everyone's
work.
You
want
to
make
sure
everything
is
fine.
You
want
to
make
sure
everything
is
running
the
way
it
should
before
it
goes
out.
So
that
is
where
the
review
up
comes
in
within
gitlab,
where
you
test
everything
you
make
sure
your
infrastructure
is
fine
within
the
test
environment
before
you
now
move
to
deploy
into
production
at
any
time,
any
new
change
occurs.
B
Gitlab
also
has
this
monitoring
feature
where
probably
you've
noticed
where
your
nodes
are
not
able
to
handle
the
kind
of
load
they
have
been
thrown
at.
It
should
automatically
shoot
the
reporting
functionality
within
gitlab
create.
B
Okay,
you
probably
need
to
add
more
notes
to
your
communities
cluster
or
you
need
notes
with
much
more
memory
or
you
need
to
change
your
requests,
configuration
within
your
kubernetes
cluster,
so
that
more
nodes
can
get
allocated
and
not
keep
some
waiting
and
more
ports
can
get
allocated
to
nodes
and
it
keeps
on
waiting
once
the
issue
is
automatically
created
and
probably
triggers
slack
that
okay,
we
have
an
issue
on
our
kubernetes
cluster
that
needs
someone's
attention.
Someone
comes
on.
B
Okay,
let
me
edit
the
hem
chart
and
kubernetes
configuration,
allow
more
requests
to
come
in
or
with
stereo
form,
create
more
nodes
and
make
them
connect
to
the
communities,
cluster,
etc.
The
changes
gets
pushed
and
you
are
able
to
stay
ahead
of
any
new
changes
or
of
or
any
new
issues
that
are
happening
within
your
infrastructure.
A
B
Earlier
I
was
I
mentioned:
I
would
talk
more
deep
into
the
new
strategy
of
using
ci
cd,
especially
with
kitops
the
normal
one
we
are
used
to
with
gitlab
ci
and
almost
all
other
ci
providers
is
the
push
strategy
when
using
ci.
That's
where
your
ci
runner
is
connected
to
your
gitlab
instance
and
anytime.
You
make
changes
to
your
code.
It's
pushed
to
the
runner
to
execute
and
most
times
the
runner
might
probably
be
in
a
different
environment
and
more
information
have
been
transferred
over
the
internet.
B
There
might
be
firewall,
of
course,
definitely,
but
it
will
be
more
secure,
especially
when
you
are
doing
githubs,
where,
instead
of
your
code,
having
to
push
your
git
server
having
to
push
any
new
changes
to
your
gitlab
runner,
your
git
lab
runner
is
already
within
your
infrastructure,
probably
as
a
port
within
kubernetes.
B
It's
now
calls
your
gitlab
server.
Okay,
are
there
any
new
changes
that
has
occurred?
Then
it
pulls
those
changes.
This
is
a
very
good
use
case
for
people
that
host
their
infrastructure
on
premise
and
have
several
layers
of
firewalls
or
not
and
don't
want
to
expose
their
owners,
because
runners
have
access
to
a
lot
of
credentials
and
a
lot
of
other
things.
They
don't
want
to
risk
the
potential
of
exposing
anything.
So
instead
it
stays
within
behind
their
firewall,
then
pulls
the
git
instance
the
gitlab
server.
Okay,
any
new
changes
has
occurred.
Okay,
fine!
B
It's
only
when
you
want
to
deploy
to
production
that
those
changes
are
pulled
from
the
github
repo,
where
you
can
also
take
it
further,
that
both
your
live
environment
and
the
production
you're
pushing
to
and
the
process
whether
it's
canonical
or
it's
docker
itself.
That
builds
your
images
and
push
them
to
your
position.
You
are
all
behind
the
firewall,
so
it's
not
just
your
production
environment.
Your
registry
also
is
behind
the
firewall
and
they
pull
any
new
changes
that
have
occurred,
so
your
ci
mainly
now
will
be
doing
the
testing.
B
Now,
to
make
this
work
for
gitlab,
we
created
kubernetes
agent
based
up
on
based
on
the
key
github's
engine
that
we've
worked,
has
created
and
what
basically
it
does
is
to
stay
within
your
communities,
cluster
integrate
with
the
gitlab
server
and
post
real
time
for
changes
from
your
gitlab
server
anytime.
Any
new
changes
are
called,
it
executes
them
within.
If
you
see
the
from
the
image
here,
you
have
the
developer,
push
this
code
to
the
application
repository,
which
then
updates
the
repository
manifest.
A
A
B
Exactly
sorry,
keep
going
yeah
go
on,
so
that's
how
it
works
on
any
other.
It
goes
further
to
make
sure
that,
depending
on
your
configuration,
it's
not.
B
If
anything
has
occurred
within
your
infrastructure,
okay,
maybe
for
some
reason
some
pots
are
constantly
failing,
even
after
trying
to
spin
up
new
pots
any
time
the
old
ones
fail,
they
keep
failing,
it
can
pull
and
make
sure
it
gets.
The
latest
changes
from
your
application
repository
and
apply
those
change
within
your
kubernetes
cluster.
B
B
Yeah,
that
will
be
all
for
all
the
explanations
and
the
introductory
parts
now
proceed
to
showing
you
a
demo
of
how
you
can
use
github
for
your
infrastructure
with
gitlab.
B
Now
this
is
a
layout
of
the
demo
I'll
be
sharing
with
you
I'll
also
be
sharing
the
link
to
this
source
code
for
it,
so
that
you
can
preview
all
different
scripts
that
are
used
and
how
you
can
use
them.
So
now
the
environment
we
have
here.
B
Has
the
infrastructure
team,
which
is
here
you
have
the
application
developers?
Then
you
have
your
other
stakeholders,
the
ceos
and
others.
So
when
the
infrastructure
team
makes
changes
or
add
any
new
infrastructure,
they
use
something
like
terraform.
This
example
is
using
terraform
makes
the
change
the
change
gets
applied
to
your
infrastructure.
This
example
has
code
for
the
eks,
gke
and
aks
environment.
B
Then
application
developers
can
make
changes.
We
have
example
codes
here
with
ruby,
spring
python
and
so
on.
Deploy
the
applications
with
helm
is
get
deployed
to
the
same
set
of
clusters.
Now
one
of
the
beautiful
things
that
gitlab
provides
is
you've
been
able
to
integrate
your
kubernetes
cluster.
We
have
support
for
eks,
we
have
support
for
gke,
you
can
even
integrate
right
from
within
gitlab
itself
and
if
you
are
using
aks,
we
also
provide
documentation
on
how
you
can
integrate
manually.
Your
aks
cluster,
once
you've
done
that
we
have
this
functionality
called
autodevops.
B
B
It
automatically
detects
what
language
is
application
written
in.
Is
it
ruby?
Is
it
java?
Is
it
anyone,
then
it
automatically
builds.
You
don't
need
to
write
your
own
ci
configuration.
It
does
everything
right
from
push
to
deployment
for
you.
It
builds
the
application,
it
runs
all
the
necessary
testing
it
needs
to
run,
for
you
then
deploys
so
just
like
heroku,
but
now
you
are
taking
advantage
of
that
kind
of
easy
functionality
within
your
infrastructure.
B
Gitlab
provides
that
and
that's
a
an
example
that
was
used
in
this
demo,
so
I'll
be
showing
you
a
video
of
my
colleague
who,
showing
you
exactly
how
this
works,
then
I'll
be
sharing
a
link
to
the
resources
that
we
used.
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
A
B
B
Yeah
sure
now,
for
those
that
might
want
to
experiment
and
see
the
source
code
that
has
been
used
for
this
particular
demo,
you
can
access
it
in
this
web
group,
gitlab
group
that
I've
created
all
the
developers
for
both
infrastructure,
the
application
and
a
detailed
description
of
how
you
can
experiment
with
it
is
here
now.
Also,
if
you
want
to
learn
more
about
how
gitlab
works,
awesomely
well
with
githubs,
you
can
check
our
solutions
page
and
learn
more
about
the
different
components
and
how
gitlab
can
allow
you
to
use
githubs.
A
All
right,
thank
you
thanks
abu
bakr
and
let's
see
here,
I
can
just
share
screen
for
the
last
couple
of
slides
here.
Okay,
you
can
stop.
A
And
let
me
pull
this
up
oops.
I
hit
the
wrong
button
in
google
slides
a
lot
where
I
say
share
instead
of
present.
A
Yeah
right,
okay,
so
just
to
wrap
up
here
a
couple
things
we
have
one
more
upcoming
kubernetes
clinic
this
year
with
ingw,
so
we'll
be
joined
by
the
cto
of
ingw.
For
that.
Well,
let's
see
I'm
moving
this
window
around
and
it's
getting
confusing
if
you're
curious
in
participating
in
one,
you
can
get
a
hold
of
dave.
His
email
address
is
here
and
then
finally,
we
do
have
a
kubernetes
assessment.
A
If
you're
interested
in
going
and
finding
out
how
you're
doing
where
you
are,
we
have
a
maturity
model
around
kubernetes
also
welcome
to
go
kick
the
tires
with
any
of
our
tools
or
software.
That's
out
there.
So
thanks
so
much
for
being
here
and
abu
bakr.
I
appreciate
the
the
time
we'll
wrap
up
here.
So
thanks
folks.