►
Description
werf is a CLI tool that glues well-established software (Git, Docker, Kubernetes, Helm, a variety of container registries & CI systems) to facilitate applications' delivery. In this webinar, developers, release engineers & SREs will learn how they can benefit from werf in their infrastructure, release management & CI/CD pipelines. Using Git as a single source of truth, we will build images of a simple Node.js application, push them into registry, deploy to Kubernetes and integrate with GitLab CI. You will also see how actual Kubernetes deployments are kept always in sync with your defined state via GitOps push-based approach.
Presenter:
Dmitry Stolyarov CTO, @Flant
A
Okay,
let's
get
started,
welcome
everyone
to
today's
cncf
webinar,
delivering
cloud-native
apps
to
kubernetes
using
worf,
I'm
jerry
fallon,
and
I
will
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenter
today,
dimitri
stoliarvov,
cto
flam,
just
a
few
moments
a
few
housekeeping
on
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
There
is
a
q,
a
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
A
At
the
end,
this
is
an
official
webinar,
the
cncf
and
as
such,
is
subject
to
the
cncf
code
of
conduct.
So
please
do
not
add
anything
to
the
chatter
questions
that
are
in
violation
of
the
code
of
conduct.
Please
be
respectful
of
your
fellow
participants
and
presenters.
Please
also
note
that
the
recording
on
slides
will
be
posted
later
today
to
the
cncf
webinar
page
at
cncf,
dot,
io
webinars,
and
with
that
I
will
hand
it
over
to
dimitri
for
today's
presentation.
B
Thank
you
very
much
jerry
for
the
invitation
to
this
webinar
and
I'm
starting
so
hello.
Everyone.
B
My
name
is
dmitry
stolleroff
and,
as
you
already
know,
I
am
cto
and
co-founder
of
land.
Basically,
the
only
thing
I've
done
in
my
life
is
working
in
this
company,
so
it
was
quite
a
nice
journey
and
it
says
10
years
with
the
linux.
Actually,
it's
like
15
or
17
years
with
linux.
So
what
I've
been
doing
during
my
professional
life
almost
all
the
time
it
was
linux,
containers
and
everything
around
linux
and
containers.
B
Okay
and
today
I'm
talking
about
our
open
source
project
and
the
name,
the
right
name
would
be
not,
but
because
it's
it's
dutch
name
that
came
actually
in
russian.
We
also
use
the
same
name
and
it's
the
name
for
the
shipyard.
B
So
it's
a
dutch
word
for
a
shipyard
that
came
into
russian
in
17th
century.
I
suppose
so
before
talking
about
any
details,
I
want
to
just
quickly
go
quickly,
walk
through
about
what
verve
does
and
basically
what
you
can
do
with
with
it
and
like
basic
principles
of
how
how
it
is
working.
B
Okay,
so
basic
idea
is
that
we
have
three
main
things
that
are
interacting
with
each
other:
it's
git
repository
kubernetes,
cluster
and
docker
registry,
and
in
git
repository
when
we,
when
we
talk
about
where,
in
git
repository,
we
usually
have
it's
it's
git
repository
for
our
application.
It
might
be
one
single
application
or
it
might.
It
might
be
a
repository
having
several
applications
like
back-end
and
front-end
written
in
different
languages.
B
So
for
each
application
we
of
course,
have
source
code
and
a
docker
file,
and
for
some
application
we
might
have
only
docker
file
if
we,
for
example,
want
to
deploy
radius
as
part
of
our
spot
as
part
of
our
installation
and
also
we
have
a
helm
chart
with
with
the
manifests
for
for
kubernetes
and
what
verv
does
it's
kind
of
very
simple
and.
B
But
what
is
important
is
that
if
we
have
one
commit
in
in
the
git
repo
having
this
this
state
and
if
at
some
moment
we
already
built
images
for
this
comment,
there
will
not
rebuild
them
and
therefore
give
you
item
potency,
add
importance,
determinism
and
kind
of
consistency
of
a
building
process.
So
you
can
rerun
verv
as
many
time.
Oh
one,
one
important
thing
that
I've
I've
missed
versus
just
a
cli
tool.
B
So
it's
not
an
operator,
as
you
usually
can,
as
you
usually
see
when,
when
we
talk
about
githubs,
it's
a
just
cli
tool
that
can
be
run,
for
example
from
ci
system
or
from
your
laptop
or
from
anywhere.
So
what
it
does?
It's
synchronizes
the
state
of
the
registry
to
the
state
defined
in
the
git
and
the
state
of
kubernetes
to
the
state
defined
in
the
git
okay.
B
So
when
you
commit
when,
when
we
run
verve
what
it
does
it,
it
calculates
digests
for
for
each
docker
file
checks
them
in
docker
registry,
whether
they
exist
there
or
not.
And
then
checks
the
state
of
kubernetes,
whether
it
matches
it
matches
the
manifests
defined
in
git
repository
and
if
something
something
doesn't
match,
it
just
changes
the
state
to
to
the
state
definitions.
Again
it
converges.
B
I
I
very
much
like
converge.
It
converges
the
state
of
the
dock
registry
to
the
state
defined
in
the
kit
and
it
converges
the
state
of
kubernetes
to
the
state
defined
in
the
git.
So
if,
for
example,
some
user
will
change
anything
in
kubernetes
directly
and
you
can
then
rerun,
therefore
the
same
commit
it
might
be
branch
or
or
git
tag
or
just
check
out
any
any
random
checkout
commit.
B
So
it
makes
kind
of
kind
of
small
fans
that
protects
kubernetes
from
direct
changes
from
users
and
this
kind
of
motivates
a
user
to
make
his
changes
directly,
not
to
not
to
make
changes
directly
to
kubernetes
to
make
changes
to
the
single
source
of
truth
in
the
git.
So
that's
kind
of
a
basic
idea.
B
Then,
if
we
change
something,
for
example,
in
this
example,
we
changed
source
code
of
front
end,
and
if,
after
that,
we
rerun,
it
will
detect
that
only
one
source
code
has
changed
only
one
of
application
existing
repo
changed,
so
it
will
rebuild
only
one
image
and
roll
out
only
one
of
the
deployment
and
basically
same
same
happens
with
health
chart.
If
we
change
only
helm
chart,
for
example,
only
only
manifest
for
a
inverse
resource
verb
will
only
will
only
change
ingress
resource
in
kubernetes.
But
that's
that's
merit
of
helm.
B
That's
merit
of
kubernetes
api,
so
that's
kind
of
we
just
we
just
send
them.
We
just
sent
to
the
kubernetes.
B
Manifests
and-
and
it
does
it
does
what
it,
what
what
it
does.
One
important
thing
is
that
verve
provide
provides
very
good
feedback.
So,
basically,
when
you,
when
you
run
it,
it
says
you,
okay,
let
me
let
me
be
clear
here
when
you
run
helm,
install
or
when
you
run
kubectl
apply
both
of
them
says
you,
like
successfully
successfully
completely
successfully
applied
successfully.
B
Successfully
finished,
but
you
know
that
when,
when
helm
says
you
that
chart
is
installed
or
when
kubstell
says
you
that
file
is
applied,
it
doesn't
mean
that
your
changes
were
really
applied.
It
means
that
it
doesn't
mean
that
they
were
rolled
out
it.
It
only
means
that
kubernetes
received
the
request
for
rollout
and
then,
if,
for
example,
new
version
of
your
application
is
not
is
not
responding
well,
the
deployment
will
not
will
not
roll
out
new
version.
So
from
these
tools
from
helm
and
from
capstail,
you
usually
don't
have
like
direct
feedback.
B
Whether
you
successfully
deployed
whether
whether
your
change
changes
were
successfully
rolled
out,
you
have
only
only
part
of
feedback.
So
what
what
verv
does
and
we
worked
on
this
part,
a
lot
is
providing
feedback
on.
What's
what's
going
on?
What's
how
it's
how
rollout
is
going
on,
and
I
will
show
you
I
will
show
you
show
you
during
the
demo
time
this
this
part
extensively
so
okay.
Another
thing
that
verve
does
is
basically
when
there
is
a
difference
between
like
big
difference
between
two
commits.
B
Of
course,
it
can
build
what
what
what
should
be
built
and
apply.
What
should
be
applied,
so
you
can,
you
can
think
of
verv
as
of
just
a
thing
that
can
change
docker
registry
to
the
desired
state
and
change
kubernetes
to
the
desired
state.
In
one
simple
run,
and
you
can
you
can
make
many
many
many
commits
change
between
them
and
you
just
check
out
commit
run
one
cli
comment
and
you
change
kubernetes
to
the
desired
state.
B
Okay,
so
that's
kind
of
a
very
quick
overview
of
of
what
what
verve
does
and
now
I
want
to
show
you
I
want
to
quickly
show
you
like
to
walk
you
through
all
the
all
the.
B
Steps
you
need
to
do
to
deploy
some
simple,
some
small,
simple
application
with
with
the
dev,
and
I
will
start
with
a
with
a
very
basic
thing
with
the
installation
and
to
do
this
I
have
already
a
completely
clean
virtual
machine,
a
completely
clean
vm.
The
only
thing
I
did
is
I've
run
up
to
update
I've
installed
a
docker
and
I've
pulled
few
images
just
to
not
to
waste
a
just
to
not
to
waste
time
during
the
presentation.
B
So
it's
completely
new,
completely
clean
vm
with
just
docker
installed,
and
if
we
open
verv
dot,
io
installation,
we
can
find
that
I
will
use
alpha
version
of
1.2
and
that's
because
for
1.2.
B
Unfortunately,
websites
has
different,
but
for
1.2
there
are
only.
There
is
only
one
version
that
that
exists.
There
is
only
one
channel
for
now
it's
alpha
and
I
want
to
use
version
1.2
because
we
switch
to
helm
three
and
I
think
it's
it's
kind
of
important
change
and
I
don't
want
to
to
show
during
this
webinar,
like
version
that
that
will
be
kind
of
deprecated
in
a
few
months.
So
it's
much
more.
B
It
seems
for
me
much
more
reasonable
to
show
yes,
it's
alpha
version,
but
it
will
be
stable
in
at
least
in
in
early
access
channel,
but
by
the
way
we
we
deliver.
I
will
tell
I
I
will
talk
a
little
bit
more
about
delivery
about
how
we
how
we
deliver
new
versions,
but
it
will
be
in
early
accessing
or
stable
in
them
in
a
month.
B
So
I
suppose
you
can
kind
of
try,
try
it
now
during
development
and
when
you
will
be
ready
for
deploying
something
to
production,
it
might
be
already
unstable.
B
So,
first
of
all,
you
need
to
install
dependencies
and
the
only
dependence.
Okay
verv
has
two
dependencies
git
and
docker.
So
I
don't
know
why.
But
it
looks
like
git
is
pre-installed
in
ubuntu,
and
I've
already
installed.
Docker
and
documentation
for
verv
suggests
you
to
add
kind
of
yourself
to
group,
to
user
group
docker
to
be
able
to
run
a
docker
without
any
any
permission
problems
because
by
default
you
cannot
do
this,
so
the
only
thing
I'm
doing
is
just
adding
myself
to
the
group
and.
B
Yeah,
I
can
run
docker
and
that's
probably
the
only
dependency
we
need.
Then.
B
We
need
to
create
a
bin
directory
in
in
our
home.
Of
course,
you
can
choose
to
any
other
location,
but
that's
kind
of
the
easiest
and
and
then
you
can,
you
use
just
one
one
liner
to
get
not
vertf,
but
multiverse.
Multiverse
is
a
tool
that
does
two
things:
it's
basically
checks
whether
new
version
is
released
and
if
it
released
it
downloads
it
and
then
it
garbage,
collects
old
versions.
B
So
it's
kind
of
a
simple
delivery
tool
and
it's
very
very
convenient
to
use,
and
we
recommend
instead
of
downloading,
like
exact
version
like,
for
example,
for
now
it's
1.2.0
alpha
9..
Instead
of
like
downloading
one
version
and
sticking
to
one
version,
we
strongly
recommend
using
multiverse
and
with
multiverse
we
can
use.
B
It's
it's
it's
easier
to
show
now
I've
added
this
line
to
to
my
bash
rc
so
and
when,
when
we
when
we,
if
I
re-enter
restart
my
session,
you
can
see
that
it
just
downloaded
the
latest
version,
and
now
I
have
I
have
like
the
latest
version
of
verv
and
you
can.
You
can
easily
switch
between
between
different
versions
between
different
channels
and
it's
very
convenient
if
you
use
it
from
ci
system.
So
you
don't
have
to
install
exact
version
on
on
runner
on
ci
runner.
B
You
have
to
just
choose
1.1
or
1.2
like
minor
version,
and
then
all
all
the
bug
fixes
you
will.
You
will
get
all
bug
fixes
automatically
and
we
guarantee
we
really
work
a
lot
on
backward
compatibility
and
we
guarantee
full
compatibility
between
inside
in
science
minor
version,
so
it
can
be
updated
automatically.
We
recommend
updating
it
automatically.
B
So
that's
it.
We
have
now
verve
installed
it's
written
in
go
so
it's
a
just,
a
single
binary,
static,
binary
and
it's
it's
very,
very
easy
to
install
okay
next
step.
We
want
to
deploy
something
to
kubernetes
and
to
do
that
we
need.
We
need
this,
something
we
need
application
to
deploy
to
kubernetes
and
I
already
have
some
something
prepared
and
I
will
just
clone
it.
B
B
B
We
don't
have
docker
file
and
I
will
use
just
prepared
comments
from
from
I
have
I
have
prepared
commits,
so
I
will
use
them
and
show
you
what's
what
changes
what's
what's
happening,
so
I've
added
two
things,
two
repository
one
is
a
docker
file
and
another
is
a
perf
yaml
and
where
vmware
lives
in
the
in
the
root
of
the
repository
and
docker
file
leaves
in
there
in
the
directory
with
with
the
back
end
and
what
we
have
in
the
in
the
docker
file.
It's
very
very
basic
thing.
B
B
It's
also
very
simple
thing:
we
have
one
section
describing
the
name
of
the
project
and
one
important
thing
that
the
name
of
the
project
should
be
unique
and
it
shouldn't
change,
because,
based
on
this
name,
a
lot
of
things
are
automatically
generated
like
namespace
or
the
name
of
the
helm
chart
or
the
name
of
the
helm,
release
and
and
so
on.
So
you
better,
you
better,
choose
unique
and
stable
name,
and
then
you
can
add
as
many
as
many
these
sections
as
you
as
you
need.
B
For
example,
you
have
backhand
and
front-end
you
can.
You
can
call
one
image
back-end
another
image,
front-end
and
use
just
two
different
docker
files,
or
you
can
use
one
docker
file
and
if
you
have
named,
if
you
have
multi-stage
docker
file-
and
you
have
named
stages
in
this
docker
file,
you
can
you
can
tell
there,
use
this
docker
file
and
build
this
stage,
and
it
will
do
it.
B
Okay
and
now
the
only
the
only
thing
we
need
to
do
is
to
execute
verb.
I
will
start
with
building
and
we
need
to
execute
verb
build,
but
we
need
to
path.
We
need
to
provide
the
address
of
the
docker
registry
that
we
will
use
for
storing
images
and,
as
I've
already
told
it's,
it's
this
registry,
so
kind
of.
If,
if
we
execute
their
build,
it
converges
the
state
of
the
wreckage
of
the
registry
to
images
defined
in
the
in
the
git
okay.
B
B
What
is
important
is
that
you
can
okay,
you
can
have
distributed
runners
and
you
can
execute
from
different
runners
they're
built,
and
it
will
synchronize
itself
and
it
will
make
everything
correctly.
Okay,
during
build
verv
pushes
all
the
stages
to
registry,
and
if
you
run
concurrently,
multiple
multiple
instances
of
just
of
I
don't
know,
docker
build
docker
push,
they
can,
they
will
be,
they
will
be
competing
with
each
other
on
on.
B
There
might
be
race
condition,
okay,
distributed
race
condition,
so.
B
We
just
use
synchronization
algorithms
and
we
have
different
implementations
of
locking
of
lock
server.
We
can
use
kubernetes
api
to
synchronize,
multiple
ins,
multiple
instances
of
verv
or
we
can
verv,
has
its
own
kind
of
embedded
log
server
and
we
just
run
publicly
available
version
and
because
the
only
things
that
that
are
sent
to
this
server
is
digest.
So
it's
nothing
nothing.
B
There
are
no
security
problems
with
that.
So,
okay,
I'm
executing
verb,
build
and
explaining
what's
going
on
first
thing:
that
happened
is
that
verve
acquired
a
lock
from
our
publicly
available
synchronization
server,
so
you
can
run
multiple
instances.
I've
already
told
you
about
that.
Second,
it
created
so-called
staple
container.
It's
just
an
internal
container
with
us
special
tools
we
use
during
build
process
and
staple
is,
is
also
dutch
word
and
it's
kind
of
sleep
way.
B
So
so
when,
when
you,
when
you
build
a
ship,
you
need
to,
you
need
to
launch
it
to
the
to
the
sea.
So
you
use
sleep
way
and
we
of
course,
like
everything
around
kubernetes.
We,
we
usually
use
words
from
from
seamanship.
B
B
It's
just
pretty
printed
and
it
shows
that
it's
successfully
builded
our
docker
file
and
I
don't
know,
what's
happening,
but
I
suppose
it's
just
docker
push.
B
B
B
And
I'm:
oh
everything
went
well,
so
it
it
builded
it
built
and
pushed
the
reason
for,
for
that.
Is
that
not
js
image?
I'm
using?
I
don't
know
why
I'm
using
such
a
large
image,
but
it's
like
900
megabytes
and
it's
just
our
diy
openstack
that
we
use
only
for
development,
so
it
has
its
little
problems.
B
Okay.
So
what
we
have
now
is
image
that
is
built
and
pushed
in
registry,
and
it
was
tagged
and
for
tech.
We
use
such
a
long
string,
but
that's
basically
a
digest
of
the
of
the
source
code
and
all
the
things
you've
you
have
used
in
them
in
the
docker
file
and
it's
a
it's
a
digest
that
is
stable
across
multiple
runners.
B
B
Okay.
From
this
moment,
I
will
switch
to
another
vm.
Having
this
same
sorry,
having
this
same
repository
with
with
my
commits
and.
B
To
show
you
that,
to
show
you
that
I
can
run
the
same
command.
B
From
multiple
vms
and
it
will
give
the
same
result
so,
as
you
can
see,
the
tag
is
same.
Four,
seven,
two,
a.
B
Four
seven
to
a
and
it
ends
with
nine
two,
seven,
four,
nine
two,
seven
four
yeah
that's
the
same,
and
we
can
run
as
many
time
as
as
we
want
this
command
and
whoa,
and
now
it's
running
garbage
collect
because
on
the
other
vm
I've
already,
I've
already
have
been
using
there
for
some
time
and
it
use
it
utilize.
A
lot
of
it
generates
a
lot
of
cash,
but
it
garbage
collects
it.
So
it's
it's
kind
of
built
to
run
from
from
ci.
B
B
Okay,
next
step,
we
want
to
deploy
this
app
to
kubernetes
and
on
the
second
vm
I
already
have.
I
already
have
kubectl
and
I
already
have
access
to
some
kubernetes
cluster
and.
B
Hard,
okay,
so
what?
What
was
added
to
the
repository?
Maybe
this?
Oh,
no,
that's
not
yeah
helm.
So,
basically,
the
only
thing
that
was
was
added
to
the
to
the
repository
to
with
the
new
commit
was
a
directory
with
a
helm
template.
So
it's
it's
called
dot
helm
and
you
can
change
this
name
to
another
by
d,
but
by
default
verfuse.helm
and
it's
simplified
chart
it's
simplified
helm
chart.
B
Value
it's
like
is
the
back
with
a
with
a
with
a
true
value,
and
in
templates
we
have
director
with
backhand,
and
here
we
have
deployment
service
and
ingress,
let's
just
very
quickly,
walk
through
them,
so
name,
nothing
interesting.
It's
just
basic
deployment
select
or
nothing
interesting,
nothing,
interesting.
What
what's
what's
interesting
is
an
image,
so
we
use
just
special
template
that
returns
name
of
the
docker
registry.
We
used
and
tag
that
verb,
calculated
and
generated.
B
Yeah,
that's
that's
basically
like
the
most
the
most
important,
the
most
important
part
in
ingress.
We
have
just
basic
definition
for
ingress.
We
use
nginx
ingress,
so
it's
it's
it's
for
nginx
and
in
service
is
just
basic
basic
declaration
of
service
that
points
to
our
deployment.
Okay.
B
And
most
of
the
time
you
need
to
pass
two
or
three
arguments
to
converge.
One
is
the
same
as
for
build
the
address
of
the
dock
registry.
Another
is
a
name
of
your
environment,
it
might
be
staging
test,
production
and
so
on,
and
the
third
one
that
I
I'm
not
using
is
cube
config,
if
you,
if
you,
if
you
need
to
if
your
config
is
not
in
standard
location,
you
you
need
to
pass.
B
Where
it
resides
okay,
so
north
converge
and
I
press
enter
and
what's
happening,
is
first
of
all,
it
builds
images
but
because
I've
already
executed
verb
build.
It
has
nothing
to
build.
So
it
goes
to
the
next
step
and
it
converges
kubernetes
to
desired
state.
But
basically,
verv
has
a
helm
compiled
in
with
a
small
additions
and
like
the
largest,
the
largest.
B
What
we
we've
changed
in
helm
is
the
way
how
we,
how
we
show
feedback,
as
you
can
see
here,
it
says,
release
with
the
name.
Verv
demo
staging
and
verb
demo
is
the
name
of
our
our
project
from
from
yaml
file
from
vmware
file
and
staging
is
is
because
I
passed
minus
minus
and
staging
to
them
to
the
comment.
B
Let
me
let
me
let
me
just
quickly
change
something
in
helm.
I
will
show
you
what
what
we
will
change.
B
So
what
we
are
changing
is
we
are
introducing
the
first
version
deployed
on
the
on
the
domain
example.com
and,
of
course
we
don't
own
examplecom.
I
don't
know
who
owns
and
probably
it's
just
recommended
by
rfc
domain-
to
use
an
example,
but
so
of
course
it's
it's.
B
It
will
not
work,
but
now
we
can,
we
use,
we
use
values,
we
use
helm
values
to
get
to
read
hostname
from
so
ctl
namespace
demo
staging
get
ingress
and
it
says
example.com
and
if
I
use
a
command
like
that,
passing
with
a
minus
minus
set
app
dot
hostname
with
the
value
with
some
really
long
cost
name.
B
B
This
param
each
time,
so
we
use
values
yaml
and
we
have
value
for
staging
and
for
production
so
and
different.
We
use
different
host
names
for
staging
for
production.
So
now
I
don't
need
to
pass
this.
This
param-
and
I
also
can
can
create
another
environment
just
by
using
just
by
using
bypassing
another
argument,
and
so
what
will
happen
is
we
have?
We
will
have
another
namespace
so
now
we
have
two
one
for
staging
one,
one
for
production:
okay,
what
next?
B
Okay,
I
know
what
next
what
next
I
want
to
change
my
application
and
to
do
it.
What
I
can
do
is
just
modify
app.js
and
say
instead
of
hello
world
say,
for
example,
hey,
hey
world,
that's
and.
B
B
And
it
takes
some
time
as
you
can
see,
because
it's
it's
it's,
it's
rebuilding
docker
file
from
from
the
beginning,
and
then
it
will
be
pushed
to
registry
and
then
changes
will
be
applied
to
kubernetes.
B
So
now
yeah,
it's
done
so
and
you
can
show
you
can
see
that
verse
says
that
one
pod
is
terminating
another
one
is
already
running
and
we
can
use
we
can.
We
can
check
that
yeah.
We
have.
We
have
new
text
from
our
back
end.
Okay,
one
more
important
thing
from
verve.
B
Instead
of
using
docker
file,
you
can
use
our
our
own
builder,
that
is
called
staple,
but
what
is
what
is
very,
very
good
is
that
it
has
very,
very
powerful
integration
with
git.
I
will
show
you
just
just
one
example.
So
what
what
we
in
previous
example,
we
had
only
only
three
lines
here
with
the
image:
it's
better,
it's
better
to
show
it's
better
to
show
changes
from
the
git,
so
image
name,
same
docker
file
and
context
removed
and
added
from
it's
the
same
as
a
docker
from
git
is
smart
integration
with
git.
B
I
will
not
go
into
the
details,
but
what
is
important
is
when
package.json
changes
it
will
re-execute
npm
ci,
but
if
package.json
hasn't
changed,
mpm
ci
will
not
be
re-executed.
Okay,
I
run
verv
converge.
It
will
take
some
time
to
build
it
once
again,
because
it's
not
it's
not
built,
we
switch.
We
switched
builder
from
docker
file
to
staple,
so
it's
it
needs
some
time
to
rebuild
it
again.
B
We
better
wait
just
a
few
seconds
and
it
says
images
build
but
then
what's
what's
really
beautiful
is
that
when
we
change
our
app.js
once
again,
oh
it's
hello
world
again
because
I
use
git
reset
so,
but
we
will
change
into
it
to
hello,
comma
world
and
now,
when
we
run
verb
converge
you
can
you
can
see
that
image
is
built
in.
Oh
sorry,
that's
too
fast
because
I
haven't
committed
it.
B
I've
made
a
mistake
and
my
container
is
listening
on
the
port
on
on
part
of
his
number
3000
and
I'm
checking
3001..
So
of
course
it
will
not
work.
But
what's
what's
important
is
that
if
you
run
verb
converge,
it
will
go
through
image,
building,
part
fastly,
and
then
it
will.
B
B
Is
it
adds
another
container
to
our
deployment,
noisy
sidecar,
and
it's
just
it
just
logs
some
log,
each
each
second,
and
if
we,
if
you,
if
we
try
to
converge
this
comment,
what
we
will
have
is
you
will
just
you
will
you
will
see
in
just
a
moment,
so
you
can
see
that
verve
outputs
log
messages
from
from
containers
during
waiting
waiting
phase?
And
you
can
you
can
control
how
much
of
this
logs
you
receive
by
different
annotations.
B
For
example,
you
can
use
skip
logs
to
completely
disable
log
printing
on
or
you
can
skip
blocks
from
several
containers
in
in
a
pod
or
you
can
show
logs
for
only
from
some
containers.
B
You
can
basically
filter
by
regular
expressions
and
so
on,
and
also
you
can
define
how
verb
will
will
track
failure
mode,
for
example,
by
default.
We
allow
some
amount
of
failures
per
replica
and
therefore
wait.
While
you
know,
while
your
application
will
be
deployed.
B
The
last
commit
I
have,
which
I
will
show
you
today
is
just
just
this
one
and.
B
What
it
does
is
just
fixes
the
port
for
for
a
readiness
prop
and
now,
if
you,
if
we
use
verb
converge
it
will,
it
will
finish
successfully
this
time.
It
should
finish
successfully.
B
Yeah
and
it's
successfully,
it's
successfully
finished
okay,
it's
only
eight
minutes
left,
so
I
probably
will
go
to
presentation
and
make
some
final
final
notes
quickly
and
then,
if
we
will
have
time
we'll
go
through
questions
if
there
are
any
so
what's
next,
this
demo
project
that
I've
used
will
be
published
just
a
few
minutes
after
after
this
presentation
on
the
on
the
shown
on
the
link
shown,
so
it's
github
verv
and
the
repository
name
will
be
demo
and
today's
date
we
have
a
very
good
quick
start
with
more
comprehensive
project.
B
So
you
can
try
it.
We
also
have
a
lot
of
information
about
how
you
can
use
verb
from
ci
and
you
can
start
with
a
using
with
ci
cd
systems.
So
if
you
open
verve
dot
io
documentation,
you
can
find
using
with
ci
cd
systems
and
that's
kind
of
basic
generic
information.
B
Okay,
we
have
also
very
comprehensive
guides,
but
for
now
only
in
russian,
but
they
they
are
under
translation.
Sorry,
it's
really
hard
for
us
for
all
my
colleagues
to
fluently
write
in
english.
For
now
we
are.
We
are
learning
english,
but
sometimes
so
some
of
things
are
written
in
russian.
So
but
as
far
as
we
know,
you
can
use
google
translate
and
to
try,
but
probably
in
a
month
it
will
be
in
english.
B
Okay,
I'm
going
very
quick
where
to
ask
questions.
We
have
a
discourse
server
and
basically
this
right
button
will
lead
you
to
the
community.plan.com.
We
just
launched
it
and
we'll.
We
will
be
very
happy
to
answer
any
questions
there.
Oh
it
should
say
it
should
be.
Do
we
need
help?
Yes,
and
if
you
can
proofread
the
commentation,
if
you
will
be
trying
verve
and
you
will-
and
if
you
will
find
you
will
find
some
mistakes,
please
send
the
pr
it
would
be
beautiful.
B
One
important
thing
about
github's,
verb
site
website
says
githubs
done
another
way.
I
have
a
not
yet
published
video
about
what
we
think
about
gitobs
and
like
our
approach
to
githubs
and
the
link
is
in,
you
can
see
it
on
the
slide
and
please
subscribe
it's
our
actual
first
video
in
english.
So
we
will
be
very
happy
if
you
subscribe
to
our
channel.
Thank
you
very
much
for
for
your
attentions.
Thank
you
very
much
for
your
time.
B
A
A
B
While
we
are
waiting
for
questions,
I
can
just
quickly
walk
through
what
we
have
in
the
documentation.
So
it's
like
overviews
shows
basically
what
I've
already
shown
you
in
presentation
introduction.
It's
just.
Oh
sorry,
introductions
what
I've
shown
you
in
the
presentation
overview
is
just
how
how
the
communication
is
structured,
quick
start
is,
is
a
quick
start.
B
B
B
Verve
has
part
that
can
clean
registry
based
on
the
state
of
the
kubernetes
and
state
of
the
gate.
So
if
we
know
that
this
image
is
not
used
in
in
kubernetes
and
according
to
git
history,
it
was
it
it's
it's
very
far.
We
we
clean
it
in
the
dock
registry
and
because
we
use
delete,
we
are
deleting
images
from
registry.
This
part
is,
is
not
implemented
in
the
same
way
between
all
the
registry,
so
we
have
some
limitations,
but
we've
done
a
lot
of
work
to
support
as
many
as
we
can.
So.
B
Basically,
like
all
major
major
registry
docker
register
implementations
are
supported.
Jerry
do
we
have
any
any
questions.
B
Okay,
I
I
would.
I
will
think
that
I
I've
done
a
good
presentation
and
answered
all
questions.
A
All
my
friend
of
that
that
well,
that
being
said,
that
will
wrap
up
today's
presentation,
dimitri.
I
want
to
thank
you
again
for
your
time
and
for
the
wonderful
presentation
and
for
everyone
who
joined
us
today,
we'll
see
what
the
next
cncf
women
are.
Everyone
take
care
stay
safe
and
we
will
see
you
next
time.