►
From YouTube: Containing the Container: Developer Experience vs Strict... Brian Bagdzinski & Sharat Nellutla
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
Containing the Container: Developer Experience vs Strict Security Posture - Brian Bagdzinski & Sharat Nellutla, Verizon
Within Verizon IT we manage multiple multi-tenant Kubernetes clusters across on-prem and multiple clouds hosting hundreds of applications. Containers, Kubernetes, and cloud-native are central pillars: both for our application modernization strategy, and for our north star architecture. However we operate in a highly regulated environment, and our security posture is such that our developers are not permitted to run tools locally that might be considered essential to deliver on this strategy: Docker and Minikube! In this talk we will candidly discuss how we are evolving the developer experience in this space, despite the security constraints, leveraging open source tooling such as Skaffold, Harbor, Kaniko, and Jib.
https://sched.co/UaXC
A
A
It
is
even
harder
at
the
larger
enterprises
where
the
security
takes.
The
frenzied
today
we'll
be
talking
about
the
container
developer
experience.
Was
this
a
strict
security
posture
at
the
end
of
this
session,
you
will
walk
away
with
a
bad
flow
that
will
help
you
to
improve
the
developer
productivity
using
the
open-source
tools.
A
B
Right,
I'm,
Brian,
Baek,
Jin,
ski
I'm,
also
on
the
Coverity
platform
team
at
Verizon,
I
specifically
focused
that
develop
on
the
developer,
experience
and
the
tooling
prior
to
that
I
helped
stand
up
the
service
platform
at
Verizon
and
did
app
development
for
several
years,
pretty
sure
I'm
the
only
person
with
that
last
name
in
this
world.
So
if
you
search
me,
you'll
find
me
and
my
family,
if
you
need
to
know
more.
A
All
right,
let's
quickly
see
who
we
are,
we
are
better
than
us:
the
most
reliable
wireless
networking
service
with
130
billion
dollars
of
revenue
in
2018,
and
it's
a
fortune
20
company,
and
we
recently
launched
the
first
commercial
fire
service
in
the
world.
Also,
we
own
several
other
brands
like
a
well
Yahoo,
Verizon
media
and
visible
who
we
are
all
using
our
own
phones.
A
A
So
to
give
a
sense
of
the
scale
at
which
we
operate,
we
have
around
2000
plus
applications,
ranging
from
brownfield
applications
to
the
Greenfield
applications
monoliths
to
the
modern,
Phi
G
apps.
We
have
80,000
plus
workloads,
10,000
plus
developers
and
the
engineers
and
300
k,
plus
deployments
or
the
past
90
days
and
1000
plus
commits
every
day.
We
all
do
this.
We
do
this
all
to
support
our
hundred
million
plus
customers
and
the
connected
devices.
The
scale
is
used
so
to
modernize
this
landscape
of
applications.
We
put
together
a
grand
strategy
of
app
modernization.
A
The
second
core
component
of
the
strategy
is
implementing
the
nostril
audition
itself,
so
that
you
know
all
the
applications
can
be
modernized.
The
kubernetes
is
called
key
component
of
this
architecture,
so
we
have
the
several
various
different
needs
for
that.
We
have
the
kubernetes
platforms
an
on-prem,
because
some
of
the
way
everyday
we
manage
with
that
we
deal
with
the
customer
sensitive
data.
So
we
cannot
move
some
of
the
apps
to
the
cloud,
so
we
have
the
kubernetes
clusters
and
on
Prem
we
have
it
on
AWS.
A
A
This
can
be
possible
only
by
improving
the
developer
experience
right,
but
this
is
where
we
started
getting
into
the
problems
and
the
challenges
security
posture
at
Verizon
is
pretty
strict.
The
first
problem.
We
cannot
run
the
darker
runtime
or
the
darker
daemon
on
a
developer,
desktop
or
a
laptop.
A
A
If
there
are
any
vulnerabilities,
we
cannot
promote
them
to
the
next
production
and
next
environment,
so
bringing
the
developer
community
to
use
the
latest
and
the
greatest
images
and
upload
images
and
integrating
the
scanning
with
the
pipeline,
so
that
the
developers
can
get
the
visibility
of
these
vulnerabilities
in
a
real-time
and
they
can
fix
it.
This
is
the
another
major
challenge
that
we
faced.
The
third
one.
As
I
mentioned,
we
have
several
cluster
endpoints
one
is
on
the
cloud
on
is
on
the
on
Prem
one
is
on
the
edge.
A
We
believe
that
a
developer
writes
a
line
of
code
that
is
more
impactful
if
satisfies
the
business
need
than
spending
a
lot
of
time
on
building
the
pipelines
and
connecting
to
the
clouds.
So
we
need
to
solve
the
challenge.
So
there
are
several
challenges
that
we
wanted
to
solve.
So
our
first
answer:
how
can
we
enable
the
developers
actually
develop
and
innovate
with
the
security
posture
right?
So
our
answer
for
this
one.
This
is
the
first
solution
that
we
iterated
last
year.
A
Okay,
you
cannot
run
the
docket
locally,
so
build
that
easy
to
image,
run,
set
up
the
docker
environment,
build
and
develop
and
build
the
images
and
scan
it
push
it.
So
that
means
we
enabled
a
remote
environment
to
the
developers
on
the
cloud,
but
you
can
imagine
as
a
developer.
This
is
not
a
ideal
solution.
A
So
again
we
ran
into
the
several
problems.
The
first
one
is
running
the
docker
in
a
docker.
It
gave
us
a
poor
performance,
the
second
one.
If
you
are
running
a
developer
environments
on
the
cloud,
you
have
a
public
law
jurisdictions
again,
that
it
started
hindering
the
developer
productivity
so
also
it
started.
Adding
the
cost-
and
we
know
that
this
is
not
a
user
friendly,
so
at
the
end
it
started
impacting
the
developer
productivity.
A
So
that
means
one
daughter
was
not
a
real
solution
and
it
will
not
help
us
to
achieve
our
lofty
goal
so
now.
This
is
the
time
to
redefine
the
developer
tools,
redefine
the
developer
workstation,
so
that
we
can
put
the
tools
we
can
tool.
The
workstation
and
developers
can
build
the
applications
without
a
docker
demon
or
the
docker
run
time
that
is
running
on
the
laptop.
So
we
need
to
find
a
solution
for
that.
A
So
we
spend
a
lot
of
time
putting
together
what
our
tools
can
help
us
to
solve
these
problems,
these
security
problems.
So
when
we
identify
the
entire
container
workflow,
we
identified
the
six
stages.
One
is
the
code,
one
is
the
build
and
then
the
developers
will
test
it
and
then
scan
the
images.
Then
they
will
deploy
the
images
and
they'll
run
the
images
on
the
clock
on
the
kubernetes
clusters.
So
for
the
code
and
build
and
test
we've
identified
three
amazing
open-source
tools,
the
first
one
is:
can
eco.
A
A
Also,
we
have
almost
30
to
40%
applications,
our
Java
applications.
When
you
want
to
modernize,
we
don't
want
our
developers
to
spend
a
lot
of
time
in
writing
the
docker
files,
so
the
helped
us
to
take
the
entire
Java
code
base
without
writing
a
docker
file
and
create
the
image
and
push
it
to
the
kubernetes
cluster.
A
The
third,
the
one
I
like
most
is
the
scaffold
scaffold
is
totally
transformed.
Our
local
kubernetes
developer
environments.
You
can
build
the
images,
you
can
push
the
images
and
you
can
run
these
images
on
the
clouds
sitting
on
in
the
IDE
and
it
has
a
great
integration
with
the
file
system
so
that
as
a
developer,
when
I
go
there
and
make
the
change
automatically
triggers
the
pipeline,
it
builds
the
image
and
applies
it
on
the
on
the
cluster.
A
So
these
three
tools
helped
us
a
lot
for
the
code
and
building
tests
for
the
scan
and
deploy
for
some
applications.
They
are
not
Java,
but
I
need
to
write
docker
file.
How
can
we
make
the
life
simpler
so
that
I
can
just
write
the
docker
file
and
put
it
on
the
clusters?
So
gitlab
donors
helped
us.
We
are
going
to
showcase
a
demo
today
of
all
these
three
use
cases.
The
next
one
is.
The
hardware
is
our
image
registry.
A
A
Finally,
for
the
run
part,
we
are
in
trade.
The
two
tools-
one
is
octane
and
QE
octant
easily
provides
the
visualization
of
the
different
clusters
and
provide
the
logs
of
the
pots
and
the
containers
in
real
time
and
also
qui,
is
an
amazing
CLI
visualization.
Today
we
can
see
that
how
best
we
can
use
it.
With
this
further
nude,
you
I
will
have
you
know
to
Brian
to
showcases
these
three
use
cases
and
give
a
demo
how
we
use
these
tools
at
the
enterprise
level.
Okay,.
B
Okay,
so
let's
go
ahead
and
get
this
started.
So
the
first
thing
we're
gonna
look
at
is
jib
and
I've
shot
mentioned.
We
have
a
huge
Java
footprint
and
Verizon
and
jib
is
a
pretty
excellent
option
if
your
developers
aren't
super
well-versed
in
doing
container
development.
So
what
I've
got
here
in
this
example
is
the
basically
the
getting
started
a
prime
spring
boots.
Documentation
just
pulled
it
off
github,
it's
a
simple
rest
service
that
returns.
That
message
there
and
I've
also
put
together
a
manifest
real
quick.
B
So
once
I
have
a
built
image,
I
can
go
ahead
and
deploy
this
to
a
cluster
and
just
kind
of
see
it
visually
in
the
browser
and
then,
if
you're
kind
of
looking
at
the
left
side,
the
hierarchy
there.
If
the
project
you'll
notice,
there's
actually
no
docker
file
present
as
I
mentioned
jib
does
not
actually
require
one.
B
Here
you'll
see
Jib
in
action
and
it's
basically
analyzing
the
dependencies
and
splitting
them
into
layers
so
that
if
I
do
a
subsequent
build
it'll
go
a
little
bit
faster
and
only
rebuild,
what's
necessary,
so
kind
of
flash
there
quickly.
But
essentially
you
saw
the
two
tags
get
pushed
to
the
registry,
so
Jib
successfully
built
it
and
pushed
it
so,
with
the
manifest
prior
to
this
I
just
did
a
cube.
Cuddle
apply
just
to
make
sure
that
it
was
running.
B
Who
could
see
it
on
the
cluster,
so
I'm
gonna
go
ahead
and
tear
that
down,
and
then
the
next
tool
I
want
to
show
is
scaffold.
So
scaffold
is
basically
letting
us
kind
of
orchestrate
pipelines
within
the
developers
environment
itself.
So
you
do
have
the
ability
to
build
images
through
scaffold
as
well,
but
since
I've
done
that
through
maven
I'm
kind
of
skipping
that
for
now
and
I'm
just
doing
a
deployment
here.
B
So
what
you'll
see
is
it's
actually
built
a
skeleton
for
me
if
you
run
scaffold
in
it,
but
the
Clyde
tool
and
it's
discovered
that
I
have
a
manifest
in
there,
and
it's
basically
created
this
little
template
for
me
and
it's
using
cube
Caudill
to
deploy
the
manifest
so
I
have
a
valid
cube,
configure
ID,
I've
logged
in
to
my
cluster
and
it's
using
that
to
figure
out
how
to
reference
the
FO
it
needs.
So
really
it's
just
a
matter
of
hanging.
Scaffold
run
you'll
see
here.
It
basically
did
the
push.
B
B
Basically,
is
the
watcher
that
sharat
mentioned
where
it's
going
to
look
at
the
file
system
anytime,
there's
a
change
it'll
create
a
dirty,
commit
push
an
image
with
that
ID
and
will
also
temporarily
spin
up
the
things
until
you
terminate
the
process
where
it
will
tear
down
your
resources
again,
but
I
think
that's
not
too
intuitive
for
how
our
developers
work
at
least
in
Verizon.
Typically,
people
aren't
going
to
want
every
single
little
change
in
the
code
that
they
do
to
be
pushed
and
then
they're
gonna
refresh
your
browser
and
check.
B
They'll,
probably
do
maybe
a
handful
of
changes
and
then
do
a
reinstall,
so
I'm,
just
using
the
maven
antrum
plug-in
here,
I'm
calling
scaffold
run
as
part
of
my
build
and
I
think
that's
a
little
bit
more
in
line
with
how
our
developers
work.
So
now
they
don't
really
have
to
leave
their
IDE
in
order
to
see
these
changes
so
I'll
just
go
ahead
and
update
the
message
here,
just
to
show
that
this
is
working
just
add
cue,
con
2019
there
and
keep
it
festive
and
then
I'll
do
another
maven
clean.
B
B
This
is
pretty
useful
for
Jib,
for
teams
that
are
largely
written
in
Java
already,
and
you
don't
want
to
have
to
go
through
the
effort
of
having
to
retrain
people
onto
how
to
do
container
development
and
also
additionally,
doesn't
need
a
docker
demon.
So
that's
pretty
valuable,
but
let's
say
you
don't
have
a
Java
app,
for
instance,
or
maybe
you
have
docker
files
that
you've
already
invested
in
and
you
would
like
to
just
build
those,
but
you
don't
have
a
docker
daemon
running
in
your
developer's
local
workstation.
B
So
what
I
want
to
show
here
is
Kaneko,
so
this
is
an
option
for
building
basically
offloading
the
docker,
build
itself
to
an
external
container
or
kubernetes
cluster.
So
in
my
demo
here
I've
just
got
a
really
simple
node
app.
It's
basically
the
same
thing:
just
written
a
node,
it's
an
Express
app
returning
a
message
exposed
on
port
8080,
as
you
can
see
here,
and
then
I've
also
got
a
docker
file
to
go
with
this
based
on
node.
B
Just
does
the
NPM
install
copies
dependencies
in
exposes
the
port
and
sets
the
entry
point
to
the
service
itself?
So
let's
take
a
look
at
my
new
scaffold
config.
So
this
time
we
see
I
actually
have
a
build
key
in
there,
defining
that
I
want
to
build
a
docker
image
and
in
scaffold
it
has
a
native
integration
with
Kaneko.
B
So
it's
one
of
the
options
for
building
docker
images,
so
you'll
see
in
there
I've
got
a
tag
policy
set
and
I'm,
basically
just
defining
that
I
want
to
push
the
latest
tag
just
for
the
sake
of
this
demo.
I've
also
got
Kaneko
defined
and
since
my
docker
files,
locally
I've
set
it
to
the
local
directory
for
the
build
context.
B
Additionally,
since
I'm
pushing
to
a
private
registry,
in
this
example,
I
have
to
set
I,
have
a
secret
that
I
already
placed
prior
to
the
demo
into
my
cluster,
and
it's
basically
just
a
docker
config
file
with
the
credentials
that
it
needs
to
access
it
and
it's
in
its
own,
dedicated
and
namespace,
and
then
at
the
very
bottom.
There
we
still
see
the
same
manifest
I
didn't
change
anything
about
it.
It's
exactly
the
same.
B
So
what
we're
gonna
do
here,
take
a
look
at
the
video
okay,
so
I'm
going
to
go
ahead
and
run
scaffold
run
on
this
now
and
what
we'll
see
is
now
Kaneko
output
as
it's
offloading
to
my
cluster
and
building
it.
So
it
kind
of
is
a
little
bit
slow,
admittedly,
I
kind
of
fast
forward,
the
video
for
the
demo,
but
basically
what
it's
doing
here
is
unpacking
the
root
filesystem
and
the
pod
that
it
spun
up.
Making
the
changes,
as
requested
by
the
docker
file,
then
basically
recompiling
it
and
shipping.
B
So
our
first,
our
first
foray
into
CIT
CD
with
kubernetes
we're
using
basically
co-located
Jenkins
slaves,
and
we
were
using
basically
a
doctor
and
docker
model
where
developers
could
provide
their
image
with
the
dependencies
they
need
to
do.
Their
builds
and
deployments
run
that
on
the
slave.
Obviously,
there's
issues
with
docker
and
docker
from
the
security
and
performance
standpoint,
so
we
kind
of
want
to
get
away
from
that.
So
the
user
experience
wasn't
super
great.
So
what
you're?
B
So
this
time,
I'm
using
a
docker
file,
you'll
see
why,
in
a
second
instead
of
jib,
jib
is
an
option
as
well
and
probably
a
better
choice
but
I
think
I
kind
of
show
some
stuff
off
here.
Instead,
so
everything
in
get
live,
runner
is
controlled
via
this
get
lab
the
ml
file.
That's
in
the
root
of
the
directory,
Lee
Travis
uses
something
similar.
If
you're
familiar
with
that
and
I
guess,
it
could
be
a
little
overwhelming
if
you're
not
familiar
with
what
a
get
labs.
B
Ci
llamó
file
looks
like
so
I'll
kind
of
just
highlight
the
main
things
here
to
save
some
time.
So
let
me
zoom
in
so
it's
a
little
bit
easier
to
read.
So
what
we've
got
here
are
basically
two
jobs.
A
lot
of
the
other
stuff
in
here
is
just
caching
optimizations
to
make
builds,
go
faster,
so
sort
of
just
try
to
ignore
those.
For
now,
the
main
things
to
look
out
for
is
that
you
have
the
job
name
and
then
within
a
job.
You
have
a
stage
for
the
maven
when
it's
built.
B
The
image
is
basically
the
runtime
that
we're
going
to
run
this
job
in
and
then
the
list
of
scripts
is
basically
commands
to
execute
within
that
docker
container.
So
in
this
case,
I'm
using
a
maven
environment,
the
gate
lab
runner
will
automatically
fetch
the
repo
and
attach
it
to
that
container
so
that
you
can
access
anything
in
your
source
in
your
source
code.
So
what
I'm
doing
there?
It's
just
basically
doing
a
maven
clean,
install
to
build
a
jar
file
and
then
our
good
friend
koneko
makes
a
return
and
get
lab
runners.
B
There
is
support
for
this,
and
this
is
get
labs.
Recommendation
for
doing
docker
builds
within
get
lab
runners
to
avoid
doctrine,
docker
situation,
so
here
we
have
koneko
it's
in
the
stage
deploy
I'm
using
the
koneko
image.
I
am
overriding
the
entry
point
here,
because
by
default
it
will
just
try
to
run
the
executor
and
I
want
to
wait
a
second.
So
instead,
what
I'm
doing
is
again
I'm
echoing
permissions,
the
docker
config
file
I
need
to
push
my
image
and
then
I'm,
calling
the
executor
and
you'll
see
a
couple
variables
to
find
in
here.
B
These
are
actually
stored
and
masked
within
get
lives,
project
settings
itself,
so
they're
not
stored
within
the
code.
The
only
people
who
actually
have
access
to
that
or
admins
of
the
project
so
go
ahead
and
run
this
pipeline
just
to
kind
of
show
the
visual
output
you'll
see
and
what
developers
can
kind
of
expect
when
they
use
a
get
live
runner.
B
So
here
I've
run
it
I've
got
the
maven
and
the
Kaneko's
jobs
that
I
expected
and
then
I
have
that
commit
there,
which
I'm
going
to
be
using
as
the
image
tag
for
the
finally
built
image.
If
I
click
into
one
of
these
jobs
I'm
going
to
get
the
console
output
again,
it's
just
going
to
be
a
big
dump
of
maven
output
pulling
dependencies
and
things
like
that,
so
I'll
just
kind
of
back
out
of
here
and
now
that
that's
done.
B
Let's
take
a
look
at
kind
of
like
what's
going
on
in
the
background,
while
this
Kaneko
job
is
running.
So
if
I
pull
the
cluster
back
up,
we'll
see
that
there's
this
extra
pod
here
and
what
it's
doing
is
for
each
job.
That's
in
your
pipeline.
It
spins
up
a
separate
pod
to
manage
that.
So
it's
going
to
scale
in
and
out
as
per
demand.
So
here
in
the
output
we
can
see
it's
basically
fetched
my
repository.
B
It's
running
all
the
commands
that
I've
defined
in
Kaneko's,
so
it's
echoing
the
docker
config
and
then
sure
enough
it
completed
if
I
refresh
here
you'll
see
that
I've
got
my
new
tag
and
it
built.
So
this
is
obviously
the
next
step
would
then
be
deploying
a
manifest
or
something
but
for
the
sake
of
the
demo.
I'll
just
cut
this
part
off
here,
but
this
is
just
a
great
option
if
you
are
kind
of
in
the
same
boat
as
we
are
or
you're
currently
running,
doctor
and
doctor,
you
want
to
get
out
of
that.
B
It
also
has
its
own
internal
Postgres
database.
If
you
want
to
do
some
kind
of
integration
of
your
own
with
that.
But
more,
more
importantly,
I
think.
Is
this
feature
here
that
I'm
demoing,
in
the
configuration
of
one
of
the
projects
and
you'll,
see
there's
a
checkbox
here
to
prevent
vulnerable
images
from
running
so
what's
going
on?
B
Is
we've
chosen
to
include
Clair
in
our
installation
of
harbor
here
and
Clair
is
an
open
source
vulnerability
scanning
tool
and
it
is
integrated
in
harbor,
so
you
can
actually
select
images
and
scan
them
all
within
the
GUI,
and
you
can
also
prevent
images
from
being
run
that
don't
meet
certain
thresholds.
So,
for
instance,
here
I
don't
want
anything.
That's
detected
with
high
vulnerabilities
to
be
allowed,
so
I've
pushed
just
the
Debian
stretcher
slam
image
in
here.
So
you
can
kind
of
see
what
that
looks.
B
Like
visually
you'll
see,
there's
kind
of
a
little
color
graph
here
depicting
the
vulnerabilities
that
were
scanned.
There's
some
other
features
here
too.
So
if
you're
using
a
notary
which
is
included
as
well,
it
will
show
a
check
or
an
X
if
it's
been
signed
or
not,
and
then
information
about
the
last
push
and
pull
time
little
copy
command.
If
you
need
that,
for
whatever
reason-
and
if
you
look
in
here,
you'll
actually
get
a
deeper
dive
into
the
vulnerabilities,
so
you'll
see
there's
a
couple
severity
here
that
are
low.
B
In
our
case,
this
would
be
acceptable
since
we
set
it
to
high,
but
you
can
also
kind
of
click
down
here,
see
what
they
are
specifically,
and
this
is
great
for
the
developer,
so
they
can
actually
kind
of
have
the
scan
integrated
into
the
registry
that
they're
pushing
to
see
what
the
issues
are
that
they
need
to
resolve
and
we'd
like
to
couple
this
feature
with
another
feature
which
is
basically
replications.
So
it's
harbor,
you
can
push
from
harbor
to
another
registry
of
your
choosing
or
pull
from
an
outside
registry
and
staged
it
in
harbor.
B
So
I'm
gonna
quickly
kind
of
skip
ahead
here,
because
I
think
it's
mostly
just
me
setting
up
a
replication
here,
but
in
the
example,
what
I'm
doing
is
I'm
gonna
replicate,
let's
say
from
docker
hub
and
it's
gonna
take
the
300
images,
pull
them
into
harbor
and
you
kind
of
think
of
this
as
a
quarantine,
which
is
how
we
plan
to
use
it.
So,
generally
speaking,
we
don't
want
people
pulling
images
straight
from
docker
hub
from
GCR,
whatever
external
repo
and
running
them
in
the
cluster.
B
So
instead,
what
we'd
like
to
do
is
basically
create
a
quarantine.
Have
people
look
at
the
images
that
get
pulled
in
look
at
the
vulnerabilities
and,
if
they're
acceptable,
they
can
just
get
promoted
into
say,
like
a
production
grade
registry
or
the
developers
can
iterate
on
it
patch
it
and
then
push
it
to
that
registry.
So
we'll
see
here,
I
triggered
a
replication.
B
These
can
be
scheduled
on
a
cron
to
happen
regularly,
but
I
just
did
a
manual
scan
and
with
any
luck,
I
should
see
here
that
the
3.0
images
the
tags
were
pulled
into
this
registry.
So
there's
library,
eight
tags
prior
to
this
I
scan
three
to
just
to
test
it.
It
was
working
so
let's
say
I
want
to
scan
3
6
and
see
if
there's
vulnerability,
I'll
go
ahead
and
click
there.
B
Click
scan
and
it'll
queue
it
up
with
Claire
you'll
see,
does
the
scanning
and
then
again
it
gives
me
that
visual
layout,
so
those
are
the
main
things
I
wanted
to
show
with
Harbor
again
it
has
a
lot
of
other
features.
It
also
function
as
a
chart
museum,
if
you
guys
are
looking
for
a
location
to
store
or
home
charts
and
share
them
in
the
notary
as
well.
So
definitely
take
a
deeper
look
at
at
this
option.
B
If
you
are
looking
for
a
more
feature-rich
registry
option
and
then
finally,
I
just
want
to
quickly
wrap
up
on
these
tools,
because
I
know
time
is
kind
of
running
out.
So
once
our
developers
have
something
running,
what's
the
best
way
for
them
to
kind
of
start,
troubleshooting
it
and
make
their
life
a
little
easier.
So
if
you
guys
are
familiar
with
the
currents
dashboard
octant,
which
is
the
first
one
I'm
demoing
here,
it
looks
pretty
similar.
It's
a
little
bit
different,
though
because
it
runs
on
the
client
itself
again,
driven
by
the
cube
config.
B
So
on
the
top
right
there
you
can
see
if
I
have
multiple
clusters
defined.
In
my
context,
I
can
flip
between
them.
I
can
flip
between
the
namespaces
I
have
permission
to,
and
then
what
it's
doing
is
basically
taking
the
same.
Output
I
would
get
from
cube,
Caudill
commands,
putting
them
in
tables
putting
them
in
charts
and
visualizations,
making
clickable
links
to
kind
of
browse
the
various
chains
of
dependencies
there,
and
it
makes
it
easier
for
developers
to
basically
understand
what's
going
on
with
their
deployments.
B
So
if
another
nice
little
feature
I'm
going
to
jump
ahead
here,
just
a
tiny
bit,
you
can
see
the
actual
raw
resource
output.
If
that's
what
you
prefer
to
do,
or
you
want
to
share
it.
But
if
you
have
say
a
pod,
specifically
one
another
ice
option
here
when
I
scroll
back
up,
you
have
the
ability
to
kind
of
tell
the
logs
in
the
browser
as
well.
So
cuy
has
some
overlapping
functionality,
which
I'll
get
into
real
quick.
B
So
for
those
of
us
that
prefer
working
in
cube
cuddle
and
do
like
the
command
line,
experience
cooee
is
what
I
would
probably
describe
is
kind
of
like
an
enhanced
cube,
cuddle
the
shell.
So,
as
you
can
see
here,
just
doing
a
get
pot,
there's
a
little
bit
more
visual
flair,
showing
the
status
and
whatnot,
but
also
it's
an
electron
app
and
it
provides
clickable
links
here
and
again.
B
It's
just
another
way
to
kind
of
more
easily
view
my
deployments
and
understand
how
they're
doing
if
I
want
to
click
into
the
containers
of
a
deployment
and
kind
of
look
at
the
logs.
That's
also
an
option
here
as
well.
One
little
caveat
with
cuy
is
that
right
now,
I
believe
it
only
runs
on
Linux
distributions
and
Mac
OS.
There
is
no
windows
option
which
may
not
be
an
issue
for
a
lot
of
you
anyway.
B
A
In
nutshell,
there
are
like
several
open
source
tools
that
are
helping
us
to
improve
our
developer
productivity
either
you
can
write
the
code
and
build
the
images
or
scan
it
or
deploy
it.
So
there
is
an
entire
set
of
the
tool
set
that
can.
That
is
helping
us
our
developers
to
improve
the
productivity
so
that
we
can
achieve
our
app
modernization
goals.
So,
at
the
end,
we
don't
want
to
focus
more
time
on
the
infrastructure
side,
our
developers,
we
want
them
to
focus
on
writing
the
code
that
really
satisfies
the
business
needs
right.
A
So
there
are
like
so
many
new
tools
are
popping
up
every
day.
They
probably
these
are
the
few
of
them,
maybe
by
the
next
cube
con.
You
might
say
few
more,
but
all
these
all
these
tools
are
helping
us
on
day
to
day
developer.
You
know
activities
as
a
part
of
a
Verizon
is
a
member
of
our
C
and
C
F,
and
a
part
of
this
one
will
embrace
all
the
open
source
tools
and
we
support
the
open
source
community
with
this
you
know.
A
D
Great
presentation,
gentlemen,
Scott
Fulton
from
ZDNet.
You
did
a
wonderful
job
of
showing
how
and
why
Verizon
is
bypassing
the
docker
daemon
from
being
run
locally.
But
could
you
explain
kind
of
if
I
didn't
catch
it
the
first
time
incapsulate?
What
is
it
about
Verizon
policy
that
prevents
you
from
having
the
permission
to
run
the
docker
daemon
locally.
B
Yeah
I
can
take
that
so,
admittedly,
it's
probably
somewhat
antiquated,
and
it
is
actually
something
we're
actively
discussing
with
our
security
teams
to
kind
of
get
a
better
understanding.
What
the
problem
is
so
I
mean
right
out
of
the
gate,
like
a
lot
of
our
developers
are
using
Windows
laptops,
hyper-v
is
disabled
and
VirtualBox
is
blocks,
so
there's
really
no
way
for
them
to
even
go
about
using.
A
E
So
you
mentioned
that
the
need
for
understanding
kubernetes
for
developers
is
going
down,
and
you
mentioned
all
these
technologies,
but
you
haven't
mentioned
how
much
training
right
now
your
developers
need
with
kubernetes.
Could
you
give
just
a
brief
synopsis
of
like
what
recommendations
you
have
for
that
type
of
training,
yeah.
A
I
think
you
know
you
hit
the
right
point.
This
is
very
important.
We
can't
transform
it
without
the
developers,
understanding,
the
talker
and
kubernetes.
The
training
is
very
important.
It
doesn't
mean
that
hey
I,
don't
know
anything
about
the
kubernetes,
but
I
can
build
the
community's
applications.
So
that
is
part
of
your
strategy.
The
training
and
you
know,
ops,
killing
your
employees
and
partnering
with
I
know
CNC
a
foundation
getting
the
Linux
Linux
Foundation,
getting
the
courses
and
making
them
available.
A
B
In
addition
to
that,
I
would
add,
having
kind
of
an
open
community
of
where
people
can
ask
questions.
So
I
can't
name
certain
products,
but
we
have
certain
forums
and
different
tools
for
people
submit
tickets
questions
the
rest
of
the
community
can
come
in
and
help
answer
and
kind
of
take
some
of
the
workload
off
of
our
team
to
go
and
upscale
everybody
and
we've
also
developed
our
own
internal
training
plans
and.
C
I
know
there
are
other
questions,
of
course,
when
we
need
to
have
the
other
presenters
who
were
coming
in
next
present,
but
these
guys
will
be
around
if
you
want
to
ask
some
questions
just
off
stage
and
please
don't
forget
to
rate
the
presentation
on
the
website.
I'll
give
you
guys
very
much.
Thank.