►
From YouTube: Improving Visibility and Traceability of Deployed Container Artif... Nima Kaviani & Manabu McCloskey
Description
Improving Visibility and Traceability of Deployed Container Artifacts via Spinnaker’s BuildCi - Nima Kaviani & Manabu McCloskey, Amazon Web Services
As containerization becomes an integral part of deploying software reliably, traceability and visibility over what gets deployed becomes ever more important. Ideally, as part of the deployment process, release engineers would be able to track deployed containers back to the right version of the written code, investigate changes, and gain insight over the build process. While baking code into container artifacts has been a core part of Spinnaker, the introduction of CiBuild as a mechanism to increase insights into what gets built, is a new feature enabled in a collaboration between Netflix and AWS. In this talk, we will discuss architecture, implementation, and enablement of the new CiBuild plugin, and how it empowers the Spinnaker community to integrate their build systems, code repositories, and container registries into their Spinnaker deployments.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Hello:
everyone,
my
name,
is
nima
cabiani
and
I'm
a
solutions
architect
with
aws,
I'm
here
with
my
colleague,
manabu
maklovsky,
and
we're
going
to
talk
about
improving
visibility
and
traceability
of
deployed
container
artifacts
via
spinnaker's
cigarette
all
right.
So
to
start,
ci
cd
is
about
enhanced
productivity
right.
What
and
devops
engineers
want
from
their
cid
cicd
system
is
to
have
a
system
that
actually
allows
them
to
have
control
over
the
rollout
of
their
software
system.
A
You
know
the
rollout
process
of
their
software
system
and
also
create
interfaces
and
integrations
between
different
systems
that
they
have
in
place
so
that
they
can
improve
visibility
and
traceability
right.
So
I
don't
know
about
you,
but
one
of
the
bigger
challenges
that
I
had
when
I
was
constantly
rolling
out
software
to
the
infrastructure
was
that
you
know
every
now
and
then
something
in
the
delivery
pipeline
would
go
red
and
I
had
to
go
figure
out
what
the
problem
was
and
especially
for
software
systems
that
follow
microservices
architecture.
A
There
are
a
lot
of
moving
pieces
right,
so
really
nailing
down
what
the
problem
is
and
what's
causing.
The
failure
is
quite
difficult
in
an
ideal
world.
What
we
want
is,
you
know.
Your
system
is
actually
designed
in
such
a
way
that
you
can
quickly
identify
the
component
at
fault
and
then
you
can
identify
and
trace
back
the
failure
to
the
changes
that
are
made
to
the
code
and
then
fix
those
changes
and
re-initiate
a
new
roll
out
of
your
software
system
right,
pretty
easy
so
for
spinnaker.
A
Spinnaker
traditionally
did
not
integrate
with
build
tools
right
so
for
developers
and
for
engineers
to
figure
out
what's
wrong
with
the
deployment
of
their
software
system.
They
had
to
go
back
and
forth
between
the
build
tools
and
spinnaker,
and
it
would
result
in
a
lower
productivity
of
these
engineering
teams.
It
would
slow
down
progress
and
it
was
error-prone
because
you
would
lose
track
of
things.
A
So
what
ci
builds
aims
to
do
is
actually
to
solve
the
problem.
It
aims
at
integrating
build
systems
with
a
spinnaker
so
that
you
can
have
a
one
stop
shop,
for
you,
know
tracking
everything
from
the
creation
and
build
up
your
software
system
all
the
way
through
the
rollout
and
deployment
of
the
services.
The
way
spinnaker
actually
takes
care
of
software
deployment
is
that
it
monitors
your
software
artifacts.
A
Let's
say
your
software
containers
and
by
looking
basically
at
the
registry
and
clearing
the
registry
for
changes
in
your
software
artifacts
and
the
moment
it
actually
notices
a
change
in.
Let's
say
the
tag
that
your
container
has.
It
actually
picks
up
that
new
container
version
and
deploys
it
to
the
cluster
right.
A
A
You
know,
failures
and
the
the
version
of
the
software
that
gets
deployed.
So
in
this
case,
if
it
happens
that
there
is
a
failure
in
the
system,
you
can
go
back
to
spinnaker
and
ask
okay
what's
failing,
and
then
it
has
enough
integration
with
everything
else
that
you
can
eventually
point
you
back
to
the
piece
of
code
that
is
resulting
in
the
fader,
so
ci
bill
at
this
point
integrates
with
jenkins
and
with
github,
and
this
is
something
that
we
plan
to
extend
to
other
build
systems
and
to
other
source
control
management
systems.
A
So
let's
talk
about
the
integration
and
the
open
source
collaboration
that
resulted
in
this
integration
all
right,
so
the
ci
build
integration
is
something
that
netflix
already
had
internally.
Basically,
netflix
has
something
called
the
ci
wrapper
that
sits
in
between
a
spinnaker
and
their
source
control
system
and
their
build
system,
which
I
believe
is
jenkins
and
when
it
happens
that
you
know
spinnaker
wants
to
roll
out
a
new
software
artifact.
It
can
go
to
that.
Ci
wrapper
and
query.
A
What
we
wanted
to
do
in
the
integration
work
that
we
did
as
part
of
the
open
source
collaboration
was
that
we
wanted
to
utilize
efforts
from
netflix
delivery
engineering
team
in
basically
reusing
what
they've
already
built
into
spinnaker,
we'll
also
enable
it
so
that
it
doesn't
require
the
cracker
that
netflix
is
using
internally.
We
wanted
to
extend
the
spinnaker
for
the
feature
to
be
available.
We
did
not
want
to
introduce
a
new
component
into
spinach.
A
So
there
are
two
parts
into
integrating
build
information
into
spinach.
One
is
showing
build
information
to
the
end
users
right.
So
what
happens
when
you
actually
install
this
new
integration,
plug-in
that
we
built
to
your
spinnaker
deployment
is
that
in
your
spinnaker
environment
you
get
a
build
tab
and
once
you
navigate
to
that
build
staff,
it
actually
brings
in
all
the
build
information
from
your
build
tool,
in
this
case
jenkins
into
your
spinnaker.
So
you
can,
you
can
actually
look
at
everything
right
there.
A
A
We
enhance
igor
in
such
a
way
that
it
actually
queries
jenkins
for
build
information
and
collects
the
community
information
as
as
well
as
the
job
id
of
a
given
build
from
jenkins.
Then,
with
the
committee
information
and
with
and
the
information
about
the
where
the
source
code
for
the
software
artifact
lives,
it
actually
queries
and
the
source
control
system.
In
this
case,
the
integration
has
been
done
with
github,
so
it
queries.
A
Github,
for
you
know,
commit
information
of
you
know
the
particular
commit
that
has
caused
the
creation
of
the
software
artifact,
and
then
it
collects
all
that
information
and
makes
them
available
through
gate
to
the
spinnaker
users.
So
when
users
go
to
debt
and
click
on
the
build
tab
that
I
just
showed
you
gate
navigates,
that
request
to
igor
that
information
is
pulled
from
these
external
sources,
is
put
together
and
is
reported
back
to
the
user.
So
that's
what
they
see
when
they
go
and
visit
the
built-in
now
there's
another
part
to
it.
A
Right
because
build
information
is
cool,
but
most
of
build
information
you
can
already
get
by
going
to
into
your
build
system
right
and
the
the
one
benefit
that
build
information
integration
inspector
does
is
that
you
have
one
stop
for
everything,
but,
more
importantly,
you
want
to
actually
be
able
to
track
back
the
artifacts
that
you
create
to
the
sources
of
creation
of
those
artifacts.
So
this
is
where
the
integration
with
you
know
the
rolex
system
that
comes
to
play
for
managed
delivery.
If
you're
familiar
with
managed
delivery,
it's
and
they
get
off
cta.
A
That
spinnaker
has
for
rolling
app
software
and
and
so
and
build
ci
integrates
very
nicely
and
with
managed
delivery.
And
if
you
go
to
a
given
version
of
an
artifact,
you
see
that
it
provides
information
about
the
author,
the
committee
information
and
also
the
branch
and
the
repository
right,
and
you
can
always
click
on
the
commit
information.
And
it
actually
takes
you
to
the
source
control
system
and
shows
you
that
for
the
set
of
changes,
so
this
integration
was
a
little
bit
harder
and
to
be
provided
in
the
in
the
build
plugin
that
we
built.
A
The
way
it's
done
is
when
jenkins
create
the
container
artifact
from
the
source
code.
It
actually
adds
some
metadata
into
that
artifact
by
actually
labeling
the
artifact,
with
some
extra
information
that
relates
to
the
commit
id
that
that
software
artifact
is
actually
built
from
build
number,
the
name
of
the
job
from
your
build
system,
and
once
all
of
that
labeling
is
done.
A
It
then
uploads
that
artifact
to
the
container
registry,
so
the
new
version
of
the
artifact
actually
triggers
identification
of
changes
in
cloud
driver,
which
is
the
component
responsible
for
you
know,
consistently
checking
and
to
see
whether
or
not
there
is
a
new
version
of
artifact
available
in
the
container
registry
or
your
artifactory
stream,
and
when
a
cloud
driver
notices,
changes
and
then
it
pulls
information
about
container
registry.
But
with
the
plugin,
you
can
enhance
cloud
driver
in
such
a
way
that
you
can
tell
cloud
driver
to
also
inspect
the
container
artifact
for
extra
metadata
information.
A
In
this
case
the
commit
id
and
the
build
number
and
the
job
name
and
so
cloud
driver,
gets
that
information
and
returns.
That
information
to
igor,
which,
as
I
mentioned,
is
responsible
for
tracking
changes
in
in
software
artifacts
and
then,
when
it
happens,
that
the
user
queries
for
that
information
for
managed
delivery.
A
B
B
This
github
repository
this
is
this.
This
is
the
repository
that
jenkins
is
going
to
build
the
docker
image
off
of
within.
Here
I
have
a
jenkins
file
on
this
jenkins
file.
Just
defines
the
the
job
that
jenkins
is
going
to
be
going
to
do
it
for
us
since
we're
doing
the
docker
build
within
the
docker.
B
B
B
So,
let's
change
to
hello
number
two,
then
I'm
just
going
to
commit
this
change,
and
this
is
going
to
kick
off
on
job
by
jenkins.
Oh
there
you
go
so
you
can
see.
Our
number
12
was
just
kicked
off
right
here.
Then
you
know
you
can
do
all
the
tank
and
stuff.
You
can
look
at
console.log
what
changed
and
whatnot
right,
but
what
is
actually
more
interesting
is
if
I
were
to
go
to
my
spinnaker
instance
here.
B
And
then
go
to
my
application,
which
is
just
led
demo,
and
if
I
were
to
go
to
the
build
tab
here,
you're
going
to
be
able
to
see
this
build.
That
was
just
kicked
off,
so
this
is
build.
Number
12
corresponds
to
this,
build
that
we
were
just
looking
at,
and
you
can
also
see
the
paths
built
like
so
here
as
well.
B
So
you
can
see
you
know
what
code
changes
led
to
this
particular
build.
If
you
click
on
this,
you
can
see,
you
know,
changes
that's
made.
The
whole
button
shows
you
as
well
as
who
made
the
change
and
a
message:
that's
that's
associated
with
it.
And,
finally,
you
can
click
on
this
to
see
what
a
job
the
actual
job
within
jenkins.
B
B
B
Okay,
so
what
is
next
for
this
plugin
right?
So
there
are
a
few
things
we
would
like
to
do
with
this
plugin.
First,
we
would
like
to
add
support
for
more
build
systems,
as
you
may
have
noticed,
we
only
support
jenkins
as
build
systems.
At
this
moment,
although
jenkins
is
still
a
popular
cs
system,
there
are
other
popular
css
systems
out
there,
so
you
know
we
would
like
to
support
other
cs
systems
like
github
actions
and
airbase
code
commit,
and
second,
we
would
like
to
add
support
for
more
source
control
systems.
B
A
B
B
A
A
But
if
you
have
any
questions,
oh
here,
he
is
I'm
not
hey.
If
you
have
any
questions,
if
you
have
any
thoughts,
please
feel
free
to
ask
I'm
monitoring
q
a
in
chat.
I
think
the
important
message
here
is
that
you
know
we
are
doing
open
source
work
for
the
spinnaker
community
here
at
aws
and
the
ci
building
integration
and
the
manage
delivery.
Plugin
are
two
of
them
that
are
available
to
the
community.
A
I
know
some
of
you
in
the
audience
have
already
experimented
with
the
managed
delivery
plug-in,
which
is
like,
as
I
mentioned
during
the
talk.
It's
the
get
off
c
twist.
The
two
spinnaker
which
we
are
super
excited
about.
If
you
we're
at
the
sick
meeting
yesterday
by
my
good
friends,
luis
and
fletch
from
netflix,
they
told
you
that
they
doubled
the
use
of
or
the
deployment
of
their
software
within
netflix
using
manage
delivery.
A
So
if
you
can
drop
the
github
links
into
chat
yeah
for
sure
so
there
is,
there
is
one
for
ci
build.
These
are
under
my
personal
github
account,
but
soon,
as
manabu
mentioned,
we're
going
to
donate
them
to
the
spinnaker
repo,
that's
definitely
coming.
We
just
wanted
to
make
sure
that
you
know
it
doesn't
have
like
too
many
bucks
when
we
when
we
shifting
so,
but
this
will
definitely
happen
and
yeah.
B
A
So
these
two
are
the
open
source
plugins
that
we're
working
on
right
now,
we're
doing
a
lot
of
work
with
netflix
on
improving
keel
and
improving
other
speaker
micro
services,
as
I
mentioned
so,
and
it's
all
open
source.
So,
if
you're
interested
and
please
join,
we
are
an
open
community
and
we
are
nice
people.
I
hope.