►
Description
Simpler Releases, Faster Upgrades: BOSH Package Vendoring and Colocated Errands - Maria Ntalla & Maya Rosecrance, Pivotal
Until now, authors of BOSH releases have had to package any dependencies their software needed in their release. While this offers great flexibility, it means that for more complex deployments, there is unnecessary duplication of third-party dependencies. This also makes it difficult to patch external dependencies as they are kept in so many places.
One-off tasks are typically packaged as BOSH errand jobs. Until now, running BOSH errands would require spinning up a VM at the IaaS level. That’s costly and can take up to several minutes, depending on the IaaS.
BOSH recently introduced two very powerful features: package vendoring and errand colocation. Attendees will learn how to use them to simplify release package management, make deployments smaller in footprint, speed up operating and upgrading BOSH deployments.
https://cfseu18.sched.com/event/GATl/simpler-releases-faster-upgrades-bosh-package-vendoring-and-colocated-errands-maria-ntalla-maya-rosecrance-pivotal
A
Okay,
so
a
quick
look
at
what
we're
going
to
talk
about
in
the
next
30
minutes
or
so
I'm
going.
To
be
honest,
the
the
title
gives
away
quite
a
bit,
but
we
will
start
with
a
very
high
level
view
of
Bosch,
and
the
intention
of
that
is
not
to
cover
everything
that
Bosch
does
in
a
very
comprehensive
way,
but
rather
give
us
a
little
bit
of
context
and
build
a
little
bit
of
a
foundation
to
help
us
frame.
A
The
second
part
of
the
talk
we
will
focus
then
on
a
package
rendering,
which
is
a
feature
that
was
added
over
the
last
year
or
so,
and
it
allows
additional
flexibility
and
abstraction
when
it
comes
to
specifying
dependencies
within
the
context
of
Bosch
releases.
And
after
that
we
will
talk
about
Aaron
colocation.
That
offers
additional
flexibility
on
where
one
of
tasks
that
run
on
both
deployed
instances
also
referred
to
as
Aaron's
run.
A
Exactly.
How
does
it
do
that?
What
what
are
those
three
dots?
The
first
step
is
by
offering
a
framework
for
software
packaging.
What
comes
under
that
packaging
includes,
first
of
all
instructions
on
how
to
prepare
the
software,
a
description
on
a
description
of
dependencies
of
what
other
libraries
or
binaries
or
what
other
software
our
software
depends
on,
and
there
are
a
few
Bosch
concepts
that
come
into
play
here.
That
are
quite
interesting.
A
The
first
one
is
a
lot
of
bas-reliefs,
and
that
is
a
flexible
structure
that
both
source
code,
but
also
precompiled,
binaries,
can
fit
in
and
can
be
expressed
by
within
releases
themselves.
Code
is
organized
into
packages
that
contain
the
specification,
but
also
any
supporting
scripts
for
the
software
to
be
prepared
on
the
instance
that
it
will
run
on,
and
that
means
that
it's
copied
in
the
right
places
that
it's
properly
compiled
and
so
on.
A
Alright,
so
after
software
packaging
second
step
is
orchestration,
and
that
again
is
a
huge
umbrella
of
things
that
happen,
but
really,
in
short,
orchestration
is
the
business
of
organizing
packaged
software
into
a
running
topology
and
arranging
it
into
components,
coordinating
those
components
taking
on
the
deployment
of
these
components
and,
more
specifically,
things
like
provisioning
things
like
interacting
with
the
underlying
infrastructure
layer
and
finally,
addressing
configuration
management
so
ensuring
that
the
software
that
ends
up
on
instances
that
Bosh
has
deployed
is
correctly
configured
specifically.
How
does
it
do
it?
A
A
References
to
packaged
software
and
a
deployment
on
the
other
side,
and
but
it
creates
that
bridge
through
Bosch,
manifests
when
running
on
the
instances
themselves.
The
next
step
software
is
represented
as
both
jobs,
and
then
there
is
a
mapping
of
between
bas
jobs
and
a
set
of
processes
on
the
instance
itself,
typically,
a
one
to
one.
A
Things
like
updates
come
into
play
here
as
well,
and
that
those
refer
to
the
versions
of
the
software
that
run
on
the
vm
themselves
and
Bosch
both
manages
that
changes
well,
topology
changes
any
additions
of
instances.
Removals
of
instances
are
under
the
responsibility
of
Bosch
and,
finally,
any
health
monitoring
in
lifecycle
management
of
instances
with
things
like
Bosch
agent.
A
That
is
responsible
for
keeping
a
specific
instance
alive
and
healthy
things
like
monotone
the
instances
to
ensure
health
of
the
very
specific
processes
and
concepts
like
Canaries
and
deployments,
where
Bush
will
choose
to
essentially
try
out
a
change
and
a
subset
of
a
deployment
before
extending
it
out
to
the
whole
thing.
Okay.
So
this
was
a
very
high-level
view
of
all
the
stages
in
software
lifecycle
that
bottle
for
strolling
and
gets
involved
in
later
on.
A
We're
going
to
focus
in
two,
so
we're
going
to
talk
about
vendor
packages
that
come
into
play
in
the
software
packaging
stage
and
then
co-located
errands
that
are
most
active
during
orchestration
and
the
responsibilities
of
boss
over
a
long-running
system
and
without
Molly.
We'll
take
you
over
package,
rendering
all.
B
Right,
it's
all
over
this
diagram
and
this
diagram
Maps
very
very
closely
to
that
process
that
me,
I
just
walked
you
through.
So
you
have
your
your
source
code
or
maybe
you're
strapping
a
binary,
and
your
source
code
would
also
have
its
language
dependencies
or
any
kind
of
like
test
binaries.
You
have
your
package
that
kind
of
wraps
it
and
that
gets
provided
to
a
job
which
handles
the
orchestration
of
it.
B
B
If
you
look
at
the
package
itself,
when
you
make
a
package
with,
you
know,
Bosch
giant
package,
you
end
up
with
these
two
files.
You
have
a
packaging
file
which
will
copy
the
actual
bits
into
the
correct
portion
on
the
Bosch
VM,
and
then
you
have
a
spec
file
which
will
specify
any
compile
time
dependencies
and
the
files
that
actually
make
up
the
package.
B
Another
problem
is
that
if
you
are
specifying
your
own
configuration,
you
might
have
to
be
specifying
go
path
or
go
route.
You
might
be
doing
that
differently
in
different
releases.
So
if
you're
making
updates
you,
hopefully
will
do
it
right
now
and
it's
not
really
transparent.
What
versions
you're
using
all
right
so
bashment
packages
are
trying
to
address
that,
so
they
kind
of
have
rolled
out
five
initial
languages
or
foreign
national
languages
and
nginx
they're
in
this
get
repo
great
board
and
then
CF
CLI
actually
lives
in
there
as
well.
B
What
it
actually
will
do
is
we'll
make
a
SPECT
out
walk
file
rather
than
the
spec
in
packaging
file
that
was
there
before,
and
that
pretty
much
just
references,
a
fingerprint
of
what
Bosch
vendor
package
version
you're.
Using
what
that
kind
of
looks
like
in
more
practical
terms,
is
you
kind
of
have
this
link
so
rather
than
the
arrow
going
straight
from
you
know
your
boss
release
to
kind
of
the
third-party
blob
or
wherever
that
lives
in
the
cloud?
It
goes
via
this
and
venerable
going.
B
Many
of
these
languages
also
provide
these
two
files
called
compiled
in
from
runtime
bump
and
they
specify
the
configuration
most
of
the
time
they're
pretty
identical
between
the
two
of
them,
because
you
kind
of
need,
go
route
and
go
path
or
a
job,
a
home
or
a
Python
path
in
kind
of
any
use
case
you
have
for
for
these
languages,
so
the
compiled
and
ultimately
called
from
kind
of
like
your
other
packages
when
you're
compiling
and
your
runtime
then
might
be
called
from
your
jobs.
When
you're
executing
code.
B
In
terms
of
the
benefits
of
using
these,
rather
than
a
kind
of
a
more
roll-your-own
approach,
they
kind
of
have
cross
OS
support
by
default,
so
going
roles
with
Darwin,
Linux
and
Windows.
It's
standardized
package
interactions.
So
now
you
just
source
this
compiled
m4
runtime
done
file,
and
you
don't
need
to
set
this
yourself
and
it
simplifies
package
patching.
B
So
if
you
know
a
new
going,
110,
4
or
111,
one
I
think
just
came
out
a
week
ago,
you
can
just
pull
down
the
people
down
the
the
Boche
bender
package,
iterate
through
your
releases
and
then
run
Bosch
vendor
package
and
bullet
AMA
CLE
update.
That
said,
you
do
need
to
cut
new
release
versions,
because
packages
are
spunda
mental
units
of
your
Bosch
release.
You
have
to
recut.
B
B
B
You
make
your
own
release.
You
create
a
package
of
whatever
it
is.
You
want
to
make
ven
durable.
If
you
have
configuration
you
can
make
your
own
compiling
but
runtime
them,
but
it's
just
a
binary.
You
don't
even
need
that
upload
it
to
a
blob
store
and
you
can
password
protect
that
if
you
want
and
if
you're
willing
to
give
that
password
to
your
end-users
cut
a
final
release
and
then
you
can
just
use
it
so
I.
B
Terms
of
why
not
to
use
them
the
existing
manual
package
creation
flow
makes
a
lot
more
sense.
If
you're
it's
your
source
code
right.
If
it's
not
reusable,
then
don't
make
it
reusable.
Also,
if
you
need
find
control
for
patch
versions,
so
the
way
the
existing
language
ones
go,
it
floats
on
a
minor
but
not
the
patch.
So
if
you
actually
want
specifically
go
110
zero
and
you
don't
want
to
float
on
it,
then
this
tool
hasn't
been
built.
Yet
for
that,
that's
what
I
say
it
couldn't
be.
B
Another
thing
is
maybe
consider
if
co-located
jobs
are
the
right
tool
if
it's
just
a
runtime
dependency
and
cutting
new
releases
is
very
painful,
but
maybe
that
makes
more
sense
so
for
CFC
allies
use
case,
they
started
as
a
venerable
package
and
decided,
but
actually
doesn't
make
sense,
because
most
people
are
using
it
in
their
Bosch
start
scripts.
So
then,
you'd
talk
to
the
clog
controller
before
they
actually
execute
their
code
or
whatever
that
is
in
which
case
you
know.
B
If
you
want
to
make
a
new
update
to
CF
CLI,
maybe
you
don't
want
to
cut
a
new
release.
Maybe
all
you
want
to
do
is
do
Bosch,
upload
releases,
CF,
CLI
and
then
redeploy
your
your
Bosch
deployment
so
from
here
I'm
gonna
hand
it
back
to
Maria
we're
gonna
talk
about
specific
strain
of
co-located
jobs
and
that's
co-located
Aaron's.
A
Thanks,
ok,
so
quick
step
back
to
talk
about
Aaron's
super
quickly,
they're,
nothing,
but
a
special
category
of
a
boss
job
really
in
that
they
started
to
perform
a
task,
then
just
get
themselves
teardown
once
that
task
is
completed
as
opposed
to
service
jobs
or
just
jobs
usually
which
are
long-running
and
our
expected
to
be
to
have
uptime
and
be
healthy,
ok,
so
so
far,
pre
co-located
Aaron's
world.
This
is
what
a
deployment
with
an
arrant
would
look
like.
A
Imagine
that
this
is
a
very
simple
deployment
that
just
has
a
long-running
job
called
up,
and
it
also
has
an
errant
deployment
time.
Porsche
would
create
the
VM
for
the
long-running
instance
and
would
run
the
process
there.
Now,
when
the
moment
comes
for
the
errand
job
to
run,
the
operator
would
invoke
it
typically
by
running
something
like
posture
and
Aaron
tests
and
then
would
Bosch.
Then
Bosch
would
go
ahead
and
create
a
brand
new
instance,
which
means
VM
for
most
of
the
cloud
providers.
A
It
would
run
the
script
there
and
it
would
then
tear
down
that
VM
once
the
task
was
completed
now
there
are
advantages
and
disadvantages
with
that
approach.
The
main
benefit
is
that
it
implements
a
design
of
single
responsibility
in
that
software,
with
this
design
will
live
on
its
separate
VM
until
unless
it
has
a
good
reason
to
coexist
with
other
software,
and
that
gives
us
isolation
and,
by
extension,
some
level
of
security.
A
This
can
end
up
adding
hours
to
the
process,
and
that
is
exactly
the
problem
or
one
of
the
problems
that
Aran
colocation
comes
in
to
solve,
and
the
main
idea
is
that
the
Aran
job
is
placed
on
the
same
instance
as
the
same
instance
group
as
a
long-running
job,
and
that
way
boss
does
not
need
to
create
a
new
VM
to
run
the
errand
script
from
there.
But
instead,
when
invoked,
it
simply
execute
the
script
that
it
has
previously
co-located
and
then
the
existing
long-running
vm.
A
There
are
a
couple
of
obvious
instant
benefits
to
this
approach
and
they're
mostly
related
to
time
and
cost
savings.
So,
first
of
all,
there
is
no
need
to
spin
up
a
separate
vm.
It
means
that
deployments
go
way
faster
than
before.
Secondly,
the
the
vm
footprint
is
smaller
and
that
means
radically
lower
costs,
but
it's
also
an
elegant
solution
for
a
scenario
where
an
aaron's
responsibility
is
to
reach
out
to
a
number
of
instances
or
all
instances,
in
an
instance
group,
for
example,
and
run
the
exact
same
thing
on
all
of
them.
A
So
previously,
this
would
look
something
like
that.
You
would
have
an
arrant
vm
that
would
be
sort
of
like
central
and
it
would
need
to
be
configured
with
all
of
the
destinations
that
it
needs
to
reach
out
to
and
perform
checks
on
them.
Some
examples
that
releases
are
doing
are
like
periodic
smoke
tests
or
specialized
health
checks
on
top
of
the
boss,
provided
ones
with
co-located
errands.
That
looks
a
little
bit
more
like
that.
A
A
The
second
point
talks
about
resource
allocation
again,
the
Aaron
job
is
not
a
special
process,
and
in
that
there
are
no
specific
limits
in
place
on
it
in
terms
of
how
much
of
the
resources
it
can
use.
So,
if
we're
not
careful,
we
can
end
up
with
Aaron's
eating
up
all
of
the
resources
on
a
VM,
not
living
space,
for
the
other
processes
to
run.
A
Additionally,
when
boss
is
asked
to
collocate
Aaron's,
it's
going
to
place
a
copy
of
the
errand
on
every
instance
of
the
instance
group
that
we
mentioned
in
the
manifest
that
the
errand
is
co-located
on.
If
that
makes
sense,
so
this
could
be
a
requirement
specifically
on
the
use
case
that
we
saw
just
before
with
self
checks.
But
if
not
one
question
to
ask
is:
is
it
appropriate
if
the
errand
runs
multiple
times?
A
Is
the
functionality
idempotent,
and
is
it
going
to
be
fine
if
it
runs
multiple
times
rather
than
one,
and
if
not
it's
worth,
considering
the
more
granular
eqx
that
was
introduced
with
co-located
errands
and
that
we're
about
to
cover
in
a
moment,
okay,
a
couple
of
requirements
to
keep
in
mind?
If
you
decide
that
co-located
errands
are
a
good
solution
for
your
use
case,
you
will
need
a
version
of
Polish
director
of
two
hundred
and
sixty
three
and
above
and
that's
to
support
colocation
at
the
director
level.
A
Linux
time
zones
need
a
version
of
three
four
four
five
and
up,
and
that
is
so
that
you
can
have
a
boss
agent
that
understands
co-located
Aaron's
jobs
at
the
instance
level.
Finally,
if
you
want
to
take
advantage
of
the
more
granular
UX
that
came
in
support
of
co-located
errands,
you
would
need
a
posse
Ally
of
two
0:31
or
up
all
of
these
were
released
in
August
2017,
so
you
might
already
be
on
them.
A
Ok
in
terms
of
how
we
would
go
about
implementing
them.
What
needs
to
change
the
good
news
is
that
not
very
much
release
authors
really
don't
see
much
of
a
change.
They
still
create
a
job
in
a
release
still
has
a
bass
bin
slash
transcript,
just
like
old
errands
did
a
little
bit
of
a
change
on
the
manifest
author
side
of
things
and
that's
the
human
operator
or
the
system
that
composes
the
manifest
for
a
Bosch
deployment.
The
change
that
has
to
happen
there.
A
It
could
be
interesting
to
mention
a
couple
of
approaches
that
we've
seen
in
releases
out
in
the
wild.
The
first
one
is
a
kind
of
a
hybrid
flavor,
where
some
errands
will
be
co-located
with
other
jobs,
and
some
will
choose
to
live
into
to
live
in
their
own
VM.
There
are
a
couple
of
reasons
why
this
might
be
appropriate
again.
It
could
be
just
a
mix
of
use
cases,
some
of
the
jobs.
Some
of
the
errands
perform
tasks
that
are
applicable
to
more
than
one
instance
again.
A
A
The
the
second
pattern
that
we've
seen
is
using
co-located
errands
in
combination
with
some
process.
Isolation
component,
an
example
is
BPM
Bosch
process
manager
and
the
the
interesting
functionality
that
it
adds
on
top
is
that
it
namespaces
processes,
including
errands,
and
that
allows
for
an
additional
layer
of
isolation
and
could
reassure
operators
that
have
a
particular
focus
on
processes
being
isolated.
A
The
last
piece
case,
which
is
quite
interesting,
is
the
the
more
granular
control
that
comes
with
operating,
collocated,
errands
and
specifically
on
air
identification.
Let's
have
a
little
bit
of
a
more
detailed
look
into
that
invocation
for
corrugated
errands
works
just
like
before,
mostly
and
what
I
mean
by
that
is
yes.
In
the
simplest
case,
you
could
run
the
exact
same
command.
A
You
could
say:
boss
run
errands
tests,
but
now
the
difference
is
that
the
errand
that
boss
will
trigger
the
errand
job
on
all
of
the
instances
of
the
instance
group
where
it's
been
co-located
in
contracts.
In
contrast
to
previously
where
it
would
trigger
the
one
the
one
instance
group
you
might
be
interested
to
run
only
copies
of
the
errand
on
a
specific
instance
group,
and
you
can
do
that
by
passing
in
the
dusters
instance
flag
and
mentioning
the
instance
group
name.
A
You
can
also
choose
to
run
the
errands
on
the
copy
of
the
errand
on
one
specific
instance
of
one
specific
instance
group,
and
you
can
specify
that
with
interest
groups
last
first,
if
you
care
about
which
specific
instance
you
want
the
errand
to
run
on,
you
can
simply
pass
the
UID
of
that
instance.
When
calling
dusters
instance-
and
you
can
extend
that
previous
pattern
by
passing
a
list
of
instances
in
an
instance
group
or
multiple
instance,
groups,
and
that
gives
you
complete
flexibility
in
what
in
where
the
errands
will
run.
A
Okay,
just
a
very
quick
recap
of
the
things
that
we
went
through,
we
looked
at
a
couple
of
features
added
to
both
over
the
last
year
or
so.
The
first
one
is
package
rendering
that
allows
service
author,
sorry,
release
authors
and
operators
to
create
more
modular
packages
and
they're
quite
simple
to
make
in
that
they
are
really
under
the
covered
boss
releases
and
secondly,
era.
Collocation
is
an
idea
and
the
boss
implementation
that
allows
for
faster
deployments
and
a
smaller
VM
proof
footprint.
A
It's
there
to
offer
more
run
time,
granularity
and
more
choice
to
operators
about
how
many
times
and
where
Aaron
jobs
are
going
to
run.
But
it
does
come
with
trade-offs.
The
more
important
one
being
isolation
for
speeds
without
I
think
we
want
to
thank
you
very
much
for
coming
along
and
enjoy
the
rest
of
the
conference.