►
Description
Slight change of plans this week, we’ll be rescheduling our planned DevSecOps speaker and instead, Ben Parees – lead developer for the Source-to-Image tool chain will give us a deep dive overview into S2I and demonstrate the workflows for creating enterprise-ready reusable images.
For the latest information on OpenShift 3.2 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally.
The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
A
Well,
good
morning,
everybody
and
welcome
again
to
another
openshift
Commons
briefing.
This
week
we
are
going
to
have
been
furries
talking
to
us
about
source,
to
image
STI,
it's
a
toolkit
or
building
reusable
docker
images
from
source
code.
It's
one
of
my
favorite
things
so
far
besides
origin
to
come
out
of
the
OpenShift
team
and
I
think
you'll
find
that
it's
one
of
the
more
useful
tools
for
building
doctor
images,
especially
if
you
run
even
an
enterprise
with
lots
of
things
that
you
need
to
make
sure
work
and
are
updatable
and
maintainable,
so
I'm
gonna.
A
Let
then
introduce
himself
and
get
started
because
we
have
a
lot
of
content
to
cover.
The
format
for
today
is
we'll
do
Q&A
through
the
chat
and
then
once
then
is
done
with
this
talk
in
this
demo,
we'll
open
it
up
for
a
conversation
for
anyone
to
have
questions
and
answers
answered
there
so
take
it
away.
Then
thanks.
B
Dan,
so
my
name
is
Ben
priests
and
I.
Am
the
team
lead
for
developer
experience
for
the
openshift
product,
which
means
that
we
help
users
coming
to
the
open
ship
platform
with
turning
their
source
code
into
application
images
handling
the
builds
some
of
the
CI
CD,
stuff,
etc,
and
a
big
part
of
how
we
do
that
is
this
source
to
image
tool.
B
So
it
is
integrated
into
open
ship,
but
we've
also
made
it
available
as
a
standalone
command
line
tool
for
developers
who
just
want
a
more
source,
oriented
way
to
take
their
application
source
code
and
produce
a
docker
image
that
they
can
run
either
on
open
shift
or
just
run
on
their
own
system
or
run
anywhere
else
that
they
would
like
to
run
that
image.
So
today,
I'm
gonna
be
taking
you
through
some
of
the
capabilities
of
the
source
to
image
tool
and
what
you
can
do
with
it
and
how
it
works.
B
So
we
had
a
number
of
goals
that
we
set
for
ourselves
when
we
started
this
project,
so
first
off
was
ecosystem
right.
The
docker
is
very
popular.
Docker
images
are
very
popular,
so
we
wanted
to
make
sure
that
we
could
take
advantage
of
existing
docker
images
if
there
is
an
image
out
there
for
Python
or
for
PHP
or
something
else,
somebody
who's
using
the
s2i
tool
should
be
able
to
use
that
image
with
s2i.
B
They
shouldn't
have
to
create
a
whole
new
image
from
scratch,
or
do
a
lot
of
special
work
in
order
to
have
a
s2i,
build
or
image
and
use
it
with
the
s2i
tool.
We
wanted
to
take
advantage
of
all
those
great
images
that
are
already
out
there
and
then,
in
conjunction
with
that,
we
also
did
want
to
create
an
ecosystem
of
our
own
builder
images.
So
while
you
can
use
existing
docker
images
and
I
will
show
you
how
that
can
work,
that
you
can
just
take
any
existing
doctor
image
and
use
it
with
s2i.
B
But
there
are
certain
things
you
can
do
when
you're
creating
a
new
image
for
a
language
or
framework
that
makes
it
immediately
consumable
by
s2i,
so
that
someone
else
who
wants
to
use
your
image
with
s2i,
they
don't
need
to
provide
anything
themselves.
They
can
have
that
straightforward
flow
I
described
earlier
of
providing
their
source
code,
invoking
the
s2i
tool
getting
an
application
image.
So
we
want
to
see
this
ecosystem
grow
of
what
we
would
call
an
s2.
B
We
were
also
going
for
ease
of
use,
so
we
wanted
developers
to
be
source
code
developers
and
they
don't
need
to
learn
and
write.
Docker
files,
there's
a
lot
of
best
practices
around
docker
files
that
you
know
to
write
a
really
good,
docker
image.
You
need
to
know
certain
tips
and
tricks
about
how
to
reduce
the
number
of
layers
that
you
have.
B
What
user
are
certain
things
running
under
is
just
a
tool
and
there's
nothing
wrong
with
doctor
files,
and
you
want
to
write
doctor
files-
that's
great,
but
if
all
you
want
to
do
is
worry
about,
I've
got
my
Java
app
and
I've
written
Java
source
code.
We
wanted
developers
to
not
have
to
worry
about,
then
writing
a
docker
file.
That's
gonna
maim,
build
their
source
code
and
put
it
in
the
right
place
within
the
docker
image
and
debugging.
All
of
that.
B
A
B
We
wanted
reproducible
builds.
We
wanted
to
ensure
that
if
somebody
is
doing
iterative
changes
they're
pushing
something
into
production
that
you
know,
we
have
a
reproducible
way
the
say:
ok,
I'm,
just
changing
the
source,
some
rebuilding
on
top
of
what
is
otherwise
the
same
base
image
which
again,
when
you're
doing
a
full
dockerfile
you've
got
more
potential
things
that
might
change
it.
B
For
example,
you're
doing
a
young
install
or
a
download
of
a
Java
framework
as
part
of
your
docker
file,
then
every
time
you
dock
or
build
that
you
might
be
getting
something
slightly
different,
but
here
we're
minimizing
what
are
the
inputs
into
the
final
application
image
that
you
get
by
saying?
We've
got
the
Builder
image.
It's
got
the
framework.
It's
got
everything
else,
all
we're
adding
is
the
source.
That's
the
only
thing
that
you're
gonna
change.
B
If
you
need
to
fix
a
bug
and
rebuild
it,
you're
not
going
to
pull
in
a
bunch
of
other
inadvertent
changes.
We
want
it
to
be
fast.
We
wanted
to
be
ideally
as
fast
as
somebody
is
used
to
developing
on
their
local
machine
and
when
docker
is
not
in
the
picture
and
again
that
comes
back
to
when
you
write
a
docker
file.
B
Unless
you
do
a
lot
of
work
to
ensure
that
you're
not
creating
a
lot
of
layers,
doing
a
docker
build
is
going
to
commit
each
layer
as
part
of
that
build
process
and
it
can
take
a
while
to
create
an
image
with
s2i.
Everything
is
done
as
a
single
layer,
so
you're
only
adding
one
new
layer
to
the
Builder
image
which
is
efficient
for
pushing
and
there's
only
one
commit
that
has
to
be
performed
during
the
build.
B
So
it's
pretty
fast,
you
actually
produce
that
image
and
then,
finally,
from
a
security
perspective,
we
wanted
to
ensure
that
all
of
the
assemble
logic,
where
we're
building
your
application
to
be
done
as
a
non
privileged
user.
So
a
lot
of
docker
files
they
default
to
root.
Nobody
sets
the
user
in
the
docker
file
and
so
everything's
being
done
as
a
root
user,
not
necessarily
bad,
but
it
is
a
potential
vulnerability
if
there
is
a
way
to
escape
the
container
logic
or
just
you're,
not
really
sure
what
your
application
is
ultimately
running.
B
B
Alright,
so
this
brings
us
to
the
first
demo
that
I'd
like
to
do
just
of
what
the
s2i
tool
looks
like
and
the
experience
of
a
user
running
it,
though
you
don't
have
to
worry
about
this
first
screen,
which
is
probably
too
small
to
read,
but
one
of
the
things
that
we
try
to
do
with
our
images
that
we
produce.
So
in
this
case,
I've
selected,
the
Python
3.4
image,
which
is
s2
I,
enabled
we
set
up
a
default
usage
script.
B
So
if
you
just
run
the
image,
you
actually
get
a
little
bit
of
health
information
telling
you
hey.
What
is
this
thing?
How
can
I
do
something
interesting
with
it
to
build
it
and
run
the
image,
though
just
a
little
helpful
information
for
a
user
who's
new
to
an
image
and
doesn't
know
what
the
heck
this
Python
3
4
image
is
about.
So
with
that
in
mind,
I'm
actually
going
to
go
ahead
and
do
an
s2
I
build
so
here
I'm,
invoking
the
s2
I
tool
with
the
build
command
I'm
specifying
a
repo
on
github.
B
You
can
also
specify
the
local
source,
but
I'll
show
that
in
a
little
bit,
but
here
we're
going
out
to
a
repo
that
is
a
Django,
Python
repo
and
then
we're
specifying
that
we're
going
to
use
that
Python
3
4
image
as
the
Builder
image
and
it's
going
to
produce
a
new
image
for
us
called
my
slash
Python.
And
so
we
just
invoke
this
we're
going
to
see
that
we're
actually
running
through
a
Django
install
of
downloading
various
Python
dependencies.
B
And
this
will
just
take
a
minute
or
so
to
run
through
building
all
the
dependencies
and
packaging
up
the
application.
It's
actually
done
now.
We're
now
committing
the
image.
I've
got
this
on
a
fairly
low
log
level.
If
you
increase
the
log
level,
you
can
see
a
lot
more
information
about
exactly
what
s2i
is
doing,
but
here
it's
committing
our
new
image
with
our
application
added
to
it
as
a
layer
on
top
of
that
Python
3/4
image.
B
You
know
just
a
very
basic
Python
repo
with
a
requirements
file
and
all
of
our
source
code
under
here,
so
nothing
special
about
this
repo,
in
terms
of
it
being
a
s2i,
specific
wreath
or
anything
like
that.
It's
just
a
standard,
Python,
repo,
okay.
So
now
we've
committed
that
image.
So
we
actually
have
a
new
image
named
my
slash,
Python
and
I'm
gonna
go
ahead
and
run
that,
and
we
see
that
our
app
is
actually
coming
up
right
here
and
it's
listening
on
32
7
88.
B
We
also
let
you
separate
out
your
dependencies,
so
you
can
you
notice
that
there
was
actually
a
lot
of
dependency
installation
happening
during
that
Python
build,
but
you
could
include
those
dependencies
within
the
image
so
that
again,
when
you
actually
do
the
build
you're,
not
pulling
down
I'm
sorry
within
the
Builder
image,
so
that
when
you
are
performing
the
build,
you
are
not
actually
grabbing
any
dependencies.
All
you're
adding
is
your
our
source
code
on
top
and
again
that'll
improve
the
speed
of
the
builds
and
reduce
how
many
layers
you're
introducing.
B
The
water
in
these
s2i
builder
images,
as
I
said
earlier,
you
can
use
any
image
as
a
builder
image,
but
if
you
want
to
directly
ask
to
I
enable
it
there's
a
couple
things,
you
can
add
the
image.
So
you
start
with
an
image
that
contains
your
base
language
so
like
a
Python,
runtime
or
a
Java
Runtime,
and
then
any
build
tools
that
you're
gonna
need
for
building
applications
for
that
framework.
So,
for
example,
maven,
and
that
has
been
a
bit
of
a
controversial
thing.
B
There
are
people
who
are
concerned
that
they
don't
want
to
have
both
their
maven
and
their
wildfly
runtimes
in
the
same
image,
and
we
do
have
a
solution
for
that
coming,
which
I
will
talk
about
towards
the
end
of
this
presentation,
but
for
the
most
basic
case,
you've
got
a
single
image
that
has
both
the
application
runtime
and
build
tools
that
can
prepare
source
code
for
that
application.
Runtime.
B
On
top
of
that,
you
then
add
what
we
call
an
assemble
script,
so
the
assemble
script
has
the
responsibility
of
taking
the
source
code
provided
by
the
developer
and
doing
whatever
steps
are
needed
to
turn
that
into
a
runnable
application.
So
if
that
source
code
includes
a
pom.xml
for
maven-
and
you
might
just
run
maven
package-
and
that's
everything
that
needs
to
be
done
really
depends
on
what
steps
need
to
be
done
for
your
framework.
It's
very
generic.
It's
simply
a
shell
script.
It
doesn't
even
actually
have
to
be
a
shell
script.
B
We
can
execute
any
binary,
that's
just
named
appropriately,
but
normally
they
are
shell
scripts.
They
can
also
inject
configuration
into
the
system.
So,
if
you're
running
a,
for
example,
an
application
server-
and
you
want
to
ensure
that
it's
configured
in
certain
ways,
then
that
can
be
done
as
part
of
hints
that
are
provided
by
the
developer
during
this
with
the
source
code
or
hints
that
are
provided
by
the
developer
through
environment
variables,
to
ensure
that
the
runtime
is
all
set
up
correctly
for
running
the
application.
B
So
that's
the
assemble
script
and
then
you
have
the
run
script
and
that's
responsible
for
actually
starting
the
application.
So
when
the
application
image
gets
committed,
the
dart
up
run
command
for
that
image
will
be
this
script.
So
that's
going
to
be
you're,
JBoss
start
script
or
your
rack
up
command
or
whatever
command
is
going
to
start
the
framework
for
the
application
and
again
any
additional
runtime
configuration
that
you
want
to
have
performed
each
time.
B
The
application
is
being
started
out,
possibly
configurable
via
environment
variables,
so
again,
totally
flexible,
just
a
shell
script
or
other
executable
binary
that
will
be
invoked
and
we'll
just
set
the
run
command
of
your
app
image
to
this
thing,
so
that
next
time
you
go
to
dr.
run
that
image,
it
will
start
your
application
and
then
lastly,
there's
an
optional
save
artifact
script,
and
this
is
for
iterative
development.
B
What
it
allows
you
to
do
is
if
you,
for
example,
pull
down
a
bunch
of
maven
dependencies
during
your
build,
and
so
now
those
dependencies
exist
in
the
application
image
that
you've
produced.
Then
next
time
you
build
rather
than
starting
from
the
base
builder
image
that
doesn't
contain
those
dependencies,
we
can
actually
pull
the
maven
dependencies
from
the
previous
version
of
your
application
image
and
then
use
them
as
part
of
the
next
build
so
that
we
don't
have
to
pull
them
down
from
the
internet.
B
So
this
save
artifacts
script
essentially
is
responsible
for
picking
the
files
and
paths
from
the
application
image
that
you
want
to
reuse
and
make
available
to
future
builds
and
that'll
again
improve
the
performance
of
a
what
we
call
an
incremental
build
where
you've
already
built
the
thing
once
them.
So
you've
got
a
lot
of
your
dependencies
already
and
you
can
just
reuse
them.
B
There
is
actually
a
little
bit
of
setup
before
it
even
gets
to
this
point,
which
is,
for
example,
if
you
were
building
from
a
github
repo
that
we're
gonna
have
clone
that
repo
to
the
local
machine
first
before
streaming
it
in.
But
basically
it
starts
up
this
container
streams,
the
artifacts
and
source
into
the
container.
It's
going
to
provide
any
environment.
B
You
can
provide
an
environment
on
the
command
line
when
you
invoke
s2i
or
include
a
s2i
environment
file
in
your
source
repository
itself,
and
then
it's
going
to
run
the
assemble
script
for
the
for
the
builder
image,
which
is
then
responsible
for
consuming
all
that
content
that
was
streamed
in
as
far
as
the
source
and
the
artifacts
perform.
Whatever
activities
make
sense
for
that
assemble
script
and
then
waits
for
the
assemble
script.
To
finish
once
it
finishes
it's
going
to
commit.
The
container
sets
the
command
to
that
run.
B
B
Look
like,
like
I,
said:
here's
here's
just
a
shell
script,
so
it's
going
to
the
the
source
code
in
this
case
is
being
streamed
into
slash,
temp,
slash
source,
so
the
assemble
script
is
going
to
grab
the
source
code
out
of
that
slash,
temp,
slash,
source
directory
and
move
it
into
the
working
directory
of
the
container.
It's
going
to
configure
an
NPM.
This
is
a
no
js'
assembly
script.
I
should
mention
so.
B
An
NPM
you're
just
in
case
somebody
who's
want
to
use
a
mirror.
So
this
is
where
those
environment
variables
that
you
might
specify
come
into
play.
If
the
developer
wants
to
use
a
local
NPM,
mirror
for
performance
reasons
or
something
else,
they
would
have
set
this
NPM
mirror
and
then
the
Samba
script
invokes
just
a
standard
NPM
install
to
set
everything
up,
and
then
once
that
finishes,
we
will
commit
this
container
in
the
state
that
it's
in
with
the
run
script
as
the
startup
target.
B
So
once
the
run
script
look
like
well,
this
one
is
incredibly
simple:
we're
just
going
to
invoke
NPM
run
and
and
the
npm
run
environment
gravel.
You
see
there.
It
does
default
to
start,
but
if
somebody
wanted
to
override
what
command
they
were
actually
wanting
to
run
within
their
package.json
for
their
nodejs
app,
then
they
could
override
it
again
through
environment
variables
for
configurability.
B
The
exec
here
is
important
because
that's
what's
going
to
make
this
the
primary
process
of
the
container
so
that
it
receives
all
the
signals
who
always
want
the
last
command
in
your
in
any
docker
image.
Dell
script:
that's
running
to
be
an
exec
command,
so
that
signal
handling
goes
to
the
place
that
you
want
it
to.
B
So
I've
talked
a
lot
about
source
in
the
sense
of
Java
source
application
source
code,
but
it
can
actually
be
quote-unquote
source
that
the
developers
providing
can
actually
be
more
than
just
that.
It
can
also
be
configuration
files
for
the
framework.
So,
if
you're
using
a
peer
wildfly,
you
might
provide
a
standalone
XML,
that's
specific,
to
tune
the
framework
for
your
application
or
a
PHP
ini
file.
B
There's
really
two
ways
that
you
can
do
config.
So
one
of
them
is
this
way
where
the
assemble
script
could
actually
look
for
I
standalone,
XML
file
being
provided
by
the
user
and
make
sure
that
that
file
ends
up
being
the
configuration
for
the
application
server
by
moving
it
to
the
right
location
before
committing
the
image.
And
then
the
other
way
is
through
the
environment.
Variable
config,
and
it's
it's
really
a
trade-off
right.
B
If
you
do
environment
variable
config,
it
can
be
a
little
bit
easier
for
an
end
user
because
they
can
just
specify
that
one
environment
variable
and
the
value
every
time
they
need
to.
They
don't
have
to
write
a
whole
config
file
and
include
it.
On
the
other
hand,
if
you
write
a
whole
config
file,
you
can
include
it
with
your
source
code
and
manage
it
with
your
source
code.
B
So
a
little
bit
of
thought
goes
into
whether
you
want
to
enable
configuration
through
letting
developers
provide
a
config
file
or
setting
an
environment
variable
or
even
potentially
doing
both
and
letting
them
pick
beyond
framework
configuration.
We've
also
used
s2i
to
enable
something:
that's
not
even
a
application
framework
such
as
database
images.
So
in
this
case,
I've
got
a
my
sequel
image,
but
I
want
to
easily
be
able
to
create
customize
my
sequel
images
where
I
have
fine-tuned
the
database
configuration.
So
in
this
case
my
source
code
could
be
the
config
settings
or
the
database.
B
It
could
also
include
schema
initialization
scripts,
where
it's
going
to
create
some
tables
within
the
database.
I
should
note
you
don't
actually
want
to
create
the
database
content
generally
because,
generally
speaking
with
a
database
image,
you
want
your
database
content
stored
on
a
volume
and
not
baked
into
the
image
itself,
though.
The
pattern
here
would
be
create
some
schema
initialization
scripts,
that
so
the
developer
can
provide
those
equal
commands
that
are
going
to
create
tables
and
things
like
that.
B
The
assemble
script
would
put
those
initialization
scripts
into
a
known
location,
but
not
execute
them,
and
then
the
run
script
on
startup
of
the
image
to
look
for
those
scripts
and
execute
them
on
startup.
That
way,
it's
executing
the
sequel
commands
once
you
have
a
proper
volume
mounted
where
the
database
storage
is
going
to
so
just
a
subtle
point
there,
but
that
is
a
way
to
allow
people
to
provide
database.
B
Human
itial
is
a
ssin
as
part
of
an
STI
build
process,
and
the
last
example
of
configuration
that
we
do
is
we
have
a
Jenkins
image,
and
so,
in
this
case
the
s2
I
assemble
process
allows
a
user
to
provide
Jenkins
job
definitions.
That's
their
quote:
unquote,
source
in
this
case
general
configuration
of
the
Jenkins
server
that
they
want.
B
So
we've
got
a
basic
Jenkins,
but
they
can
configure
it
any
way
they
want
and
they
can
store
that
configuration
in
a
git
repo,
so
they're
managing
revisions
to
their
Jenkins
configuration
through
source
control
with
git,
but
then
they're
able
to
quickly
build
a
new
custom,
Jenkins
image
that
has
exactly
that
config
out
of
that
git
repo
anytime.
They
need
to,
and
the
last
thing
that
the
assemble
process
for
the
our
Jenkins
image
will
do.
Is
you
can
list
plugins
that
you
want
to
installed,
and
so
you
can
just
reference.
B
B
So
I
alluded
a
little
bit
to
incremental
builds
earlier.
This
is
how
we
reuse
dependencies
so
as
a
few
conditions
required
to
take
advantage
of
incremental
builds.
So
first
off
the
builder
image
itself
has
to
be
compatible
with
incremental
building,
which
means
it
has
to
provide
a
save
artifacts
script
or
the
user
has
to
provide
a
save
artifacts
script
themselves
and
I'll
get
into
how
you
can
provide
them
outside
of
the
image
later.
That's
how
we
enable
generic
docker
images
to
be
used
with
us
two
eyes.
B
You
can
provide
them
outside
the
image,
but
one
way
or
another
a
save,
artifact
script
has
to
be
there.
So
we
know
what
dependencies
we
are
reusing.
The
second
requirement
is
that
we
need
a
previous
image
to
exist
that
matches
the
output
name
for
this
build.
So
in
my
case,
I
was
outputting
to
my
slash
Python,
the
first
time.
I
can't
save
anything
from
the
previous
one
because
my
Python
doesn't
exist,
but
on
follow-on
build
since
that
now
exists,
it
would
be
able
to
reuse
the
dependencies
from
there.
And,
lastly,
it's
actually
a
flag.
B
You
have
to
explicitly
enable
in
s2i,
and
the
reason
for
that
is.
We
didn't
want
people
to
get
confused
where
the
system
reused
an
old
dependency
and
they
actually
expected
it
to
pull
a
new
version
down
from
the
internet.
So
we
wanted
it
to
be
an
explicit
choice
that
you
know
you
are
deciding
to
do
this
and
are
aware
that
you're
gonna
get
old
dependencies
and
not
necessarily
the
latest
thing.
That's
out
there.
B
So
the
way
it
actually
works
is
it's
going
to
create
a
docker
container
from
the
old
output
image
and
then
run
that
save
artifacts
command
within
that
container,
which
is
going
to
copy
all
the
dependencies.
The
save
artifacts
script
references
out
and
then
make
that
available
in
addition
to
the
source
code
that
it's
going
to
provide
to
the
new
build
so
I'm
just
going
to
show
you
how
this
works
in
this
case
with
a
maven
image.
B
So
maven
is
a
little
bit
slower
in
this
case,
so
we're
gonna
do
the
first
build
where
we're
not
doing
any
incremental
building
from
a
local
directory
with
a
wild
fly
image,
and
you
see
here,
we
see
all
these
downloaded
messages.
It's
downloading
tons
tons
of
maven
dependencies
takes
a
little
bit
of
time
to
grab
all
those,
and
so
that's
what
we're
going
to
avoid
when
we
do
the
incremental
build
the
next
time
around.
So
we've
built
our
war
again.
We
are
now
committing
the
docker
image
and
we're
done
with
that,
though.
B
And
I'm
gonna
guess
that
we
are
on
the
next
bumped
port
number.
Okay,
so
here
we
are
in
our
wad
fly:
eight
application
that
we
just
built
running
on
my
local
system,
so
that's
cool,
except
that
it
says,
multiply
eight
and
actually
this
is
a
wild
fly.
Ten
application,
so
I'm
gonna
go
ahead
and
fix
that.
B
In
addition
to
the
incremental
flag,
I'm
going
to
exercise
another
option
within
s2i,
which
is
to
actually
go
ahead
and
just
run
the
image
as
soon
as
it's
built
that
way,
I
don't
have
to
actually
do
that.
Docker
run
command
afterwards.
Just
saves
a
little
bit
of
time
when
you're
doing
iterative
development,
you
can
just
do
as
I
build
and
just
run
and
then
immediately
test
your
changes.
B
So
this
time,
when
we
do
the
build,
we're
gonna
see
that
it
does
not
do
all
the
maven
dependency
downloading,
because
it's
gonna
extract
all
that
stuff
from
the
previous
image.
And
so
you
see
it's
actually
already
done
it's
already
extracted
and
built
it
and
committing
the
image
as
soon
as
it
commits
it
will
see.
It
actually
starts
up
the
image.
So
now
it's
starting
it
up,
I
didn't
do
a
docker,
run
it
scrolled
by
the
port
number
that
it
actually
started
it
on.
B
B
So
that's
an
incremental,
build
again
saves
you
time
not
having
to
pull
all
those
dependencies
down
every
time
that
you
do
the
build
another
capability
that
s2i
has
is
what
we
call
layered
builds
so
under
normal
circumstances,
because
we
are
tar
streaming
the
content
into
the
container
for
the
assemble
script.
We
require
that
you've
got
tar
and
shale
binaries
within
the
image
so
that
we
can
do
that
and
that's
not
a
very
challenging
dependency.
B
Most
images
meet
that
dependency,
but
if
we
do
encounter
an
image
where
those
requirements
do
not
exist,
we
have
this
fallback
model
for
injecting
the
source
code
in
which
we
actually
build
a
new
image
with
the
source
code
baked
into
it,
and
then
invoke
the
assemble
on
that.
So
we
actually
write
a
new
docker
file.
That's
going
to
be
based
on
the
Builder
image
and
contains
an
add
command
that
adds
the
local
source
code
from
the
developer
and
we
build
that
commit
that
as
an
intermediate
image.
B
One
warning,
if
you
do
find
yourself
in
the
case
where,
as
2i
is
doing
this,
if
you're
a
builder
image,
contains
on
build
commands,
then
those
are
going
to
get
executed
because
on
build
commands
defined
in
an
image,
get
run
anytime
you
dock
or
build
an
image
based
on
that
image,
which
is
exactly
what
this
is
doing.
So
just
just
a
little
bit
of
a
caution
there.
If,
if
you're
doing
that,.
B
So
our
approach
to
solving
this
is
what
we're
calling
extended
builds
and
we
have
a
pull
request
in
flight.
It's
probably
within
the
next
couple
days
going
to
merge,
but
it's
not
quite
there
yet,
and
the
idea
is
to
allow
people
to
invoke
s2i
builds
in
which
they
provide
a
builder
image
and
a
runtime
image
as
two
separate
images,
and
so
the
Builder
image
looks
a
lot
like
what
we've
discussed
with
the
assemble
script.
So
it's
going
to
contain
your
maven
tooling,
does
not
need
to
contain
your
application.
B
Runtime,
just
just
build
tooling,
like
maven
and
will
invoke
the
assemble
there,
though
it
would
produce,
for
example,
a
war
file
and
commit
that
image.
So
now,
you've
got
a
new
image
that
contains
just
your
war
file
or
whatever
built
artifacts
you
wanted,
and
then
we
will
immediately
start
a
second
build
in
which
we
extract
the
files
you
specify
from
that
artifact
image
and
add
them
to
a
runtime
image
and
we'll
have
a
assemble
script
in
the
runtime
image.
B
That
knows
how
to
move
those
artifacts
around
to
the
right
locations,
but
it's
not
actually
building
anything.
It's
just
shuffling
files
around
and
then
we
commit
that
image
as
the
application
image.
So
because
we
built
that
final
image
on
top
of
a
runtime,
only
image
that
doesn't
contain
maven
your
application
image
also
does
not
contain
maven.
B
It
only
contains
the
runtime
and
then
you've
got
your
image
that
you
can
push
to
the
docker
registry
or
you
can
just
run
locally,
so
I'm
gonna
go
ahead
and
demo
that,
like
I
said
this
is
not
in
what's
in
s2i
today,
but
it
should
be
there
very
soon.
So
I
did
want
to
talk
about
I
know,
it's
been
something
the
community
has
been
interested
in
having
so
first
off
just
to
show
there's
nothing
up.
B
My
sleeves
here,
I'm
just
gonna
run
my
my
this
is
my
wildfly
runtime
image
that
I've
created
that
does
not
contain
maven,
so
you
can
see
I
listed
the
wildfly
directory
and
we
do
indeed
have
wild
fly
there.
But
if
we
look
for
maven,
there's
no
maven
in
this
image
and
then
we've
got
our
maven
image
and
there
is
no
wild
fly
in
that
image,
but
we
do
have
Nathan
available
within
that
image.
So
I'm
gonna
go
and
make
another
change,
so
you
can
see
that
we're
actually
doing
something
here.
B
Changing
that
source
code
committed
it
and
now
I'm
going
to
go
ahead
and
do
one
of
these
extended
builds
so
the
syntax
here,
a
mess
too
I
build
dot,
just
building
my
local
git
directory
I'm,
using
my
maven
image.
As
my
builder
image,
my
output
is
gonna,
be
my
wall
apply
just
like
before,
but
then
I'm
specifying
in
addition
to
runtime
image,
which
is
going
to
be
WF
runtime
and
that's
the
hint
as
to
I
that
is
doing
an
extended
build,
and
so
it
will
use
the
first
one
as
a
builder.
B
Only
and
then
do
this
extended
extract
and
commit,
and
then
the
other
thing
I'm
specifying
is
what
files
I
actually
want
to
extract
from
my
maven
image,
my
quote-unquote
Builder
image.
So
the
maven
image
when
it
builds
my
source
code,
is
going
to
produce
a
root
or
file
in
slash
temp,
slash
war.
So
that's
the
file,
we're
gonna
extract
and
provide
to
the
runtime
image
that
the
runtime
image
will
then
deploy.
You
can
actually
specify
these
files,
as
a
label
on
I
believe
is
on
the
Builder
image
so
that
you
can
actually
have
a
builders.
B
That
knows
what
files
it
produces
and
then
the
user
using
it,
doesn't
have
to
specify
the
files,
but
this
is
a
way
where
you
can
customize
exactly
what
files
we're
still
working
a
little
bit
on
the
experience
there.
So
I'm
gonna
go
ahead
and
run
that
and
we're
gonna
see
once
again
we're
doing
a
maven
build
here.
This
is
not
an
incremental
build,
so
we're
redownload
all
the
dependencies
from
maven.
In
this
case.
B
B
And
now
we
see
we're
in
our
run
time
only
docker
image
that
we
have
produced.
So
that's
the
extended
build
feature
like
said
coming
very
very
soon.
Hopefully
that
addresses
some
of
the
requests
from
the
community
that
we
provide
a
way
to
separate
out
the
runtime
bits
and
the
application
building
bits
in
the
images
just
some
other
options
that
the
s2i
framework
has
available.
B
That
I
want
to
talk
about
I
kept
mentioning
you
can
override
the
scripts,
so
you
can
provide
the
assemble
run
and
save
artifacts
scripts
in
your
source,
repo
itself,
you
put
them
in
a
dot
s2i
directory.
You
can
also
on
the
command
line,
specify
an
HTTP
URL
that
contains
where
it
points
to
a
directory
that
contains
those
files
in
either
case
will
then
pull
those
down.
So
that's
how
you
can
use
s2i
with
a
random
docker
image
that
has
not
been
s2i
enabled
because
you
just
provide
the
assemble
scripts
yourself
and
then
you
can.
B
You
can
just
go
with
that.
You
don't
need
a
docker
image
that
was
specifically
built
for
s2i.
If
you
want
to
provide
the
scripts
yourself
or
if
you
do
not
like
the
assemble
logic,
there's
an
s2i
builder
image
and
you
like
most
of
what
it
does,
but
the
assemble
logic
itself
isn't
quite
to
your
taste.
You
can
simply
create
your
own
assemble
script,
included
with
your
source
code
and
use
that
builder
image.
But
you'll
get
your
assemble
logic.
You
can
specify
full
policies
for
the
images
so
by
default
we
do
pull,
if
not
present.
B
So
if
you
reference
a
builder
image
that
you
have
locally,
we
won't
do
any
pulling.
But
if
you
want
to
make
sure
that
you're
always
pulling
the
latest
one,
you
can
specify
full
policy
of
always.
If
you
want
to
make
sure
that
will
error
out.
If
it's
not
available,
you
can
specify
a
full
policy
of
never
environment
variables.
So
these
are
my
work
variables
that
can
be
fed
in
during
assemble
time,
so
the
assemble
script
can
use
it
to
make
decisions
and
they
will
also
be
part
of
the
final
image.
B
So
the
runtime,
the
runtime
application
image
that
you've
built
will
have
those
environment
variables
defined
as
well.
So
you
can
do
that
either
on
the
command
line
when
you're
invoking
s2i
or
provide
an
environment
variable
in
your
source,
repo
to
control
your
application
assembly
and
runtime
behavior
incremental
build
I
showed
you
is
an
option
by
default.
It
is
disabled
that
you
can
set
a
flag
to
enable
it.
There
is
also
a
way
to
inject
additional
files
during
assembly
that
will
not
be
in
the
final
application
image.
B
So
all
your
source
code
is
obviously
going
to
be
in
the
final
application
image,
but
if
you
have,
for
example,
a
certificate
that
you
need
at
assembly
time,
you
need
to
authenticate
to
a
proxy
to
access
something
or
to
access
a
nexus
repo,
or
something
like
that.
There
is
an
argument
that
allows
you
to
provide
those
files
so
that
the
assemble
script
has
access
to
them,
but
those
files
will
be
truncated
before
the
application
image
is
committed.
So
the
final
application
image
won't
contain
them.
B
B
And
so,
where
are
we
going
in
the
future?
Well
extended
builds?
We
obviously
want
to
finish
up
that
get
the
fit
and
finish
right.
The
experience
right
on
that
and
get
it
delivered.
We
would
like
to
have
the
ability
to
override
parts
of
an
assembler
run
script.
Today
you
have
to
provide
the
entire
assembler
run
script.
B
One
thing
we've
discussed
and
I'd
definitely
be
interested
in
community
feedback
on
this.
One
is
actually
removing
the
get
support
from
s
to
I.
So
we
we
sort
of
there's
a
lot
of
complexity
in
the
sty
tool
today,
with
being
able
to
clone
git
repositories,
deal
with
sub
modules
of
git
repositories,
be
able
to
check
out
a
specific
ref.
So
that's
another
flag,
I
did
not
mention,
but
you
can
specify
on
the
command
line
that
you
want
to
build
a
specific
ref
of
your
git
repo.
B
B
Just
a
couple
of
resources
that
you
might
be
interested
looking
at
so
the
source
image,
repo
itself.
Of
course,
on
github,
we've
got
a
number
of
community
s2i
images
in
our
open
ship,
s2i
github
organization,
there's
also
a
number
of
images
that
are
part
the
OpenShift
product
produced
by
our
software
collections,
library,
team,
those
are
under
the
SCL
org.
They
all
start
with
s
I
something
and
with
container
so
we've
got
images
from
nodejs,
Perl,
PHP,
Python
and
Ruby.
There
is
a
wild
fly
image
under
that
open
ship.
Yes,
I
community
as
well.
B
A
Right
well,
thank
you
very
much.
Ben
there's
been
a
couple
of
questions
in
the
chat.
I
think
you've
covered
most
of
them,
Jonathan
had
asked
them
and
he
was
jumping
the
gun.
I
think
a
couple
of
times
on
things
and
you
covered
them
because
I
won.
One
of
his
point
was
at
the
very
beginning,
was
it
it
looked
like
this.
I
was
really
good
for
beginners,
but
I
think
you've
covered
off
the
payoff
for
complicated
systems
and
he's
pushed
him
there.
You
want
to
add
any
more
to
that.
B
C
And
then
this
one
with
the
answers?
Yes
to
this,
you
make
my
life
perfect
and
wonderful,
and
always,
if
the
answer's
no
well,
you
know
you
know
the
faster
is,
but
we
have
a
lot
of
ice
bees
who
are
interested
in
pleadings
of
an
open
ship
is
it
possible
is
an
envision
that
will
have
a
be
able
website
where
someone
could
just
go
and
we
have
a
wizard
that
we
guide
them
through.
C
B
Know
there
is
some
work
internally,
I,
don't
know
how
much
I
can
really
discuss.
I,
don't
know
a
whole
lot
about
it,
but
to
to
do
that
sort
of
is
via
enablement
of
yeah
of
saying.
Ok,
your
urine
is
B
who's
got
this
application,
but
you
really
don't
know
much
about
docker.
How
can
we
make
it
easier
for
you
to
doctor
package
your
application.
C
C
B
I
know
there
is
some
discussion
around
that.
How
simple
that
could
be
is
is
a
little
bit
hard
to
say
there.
There
is
definitely
some
thought
that
needs
to
go
into
container
izing
and
application
and
understanding
some
of
the
the
differences
of
what
it
means
to
be
running
in
a
container
and
where
you're
getting
the
content.
C
A
Saying
we'll
probably
be
having
a
talk
shortly
about
what
that
roadmap
looks
like
so,
hopefully
you
can
answer
that
question
again
and
make
that
everybody
wants
a
wizard,
I'd
love
a
wizard
too,
but
some
of
the
stuff
that
the
ISV
they're
doing
is
even
more
complicated
than
and
have
numerous
computers
and
I
think
Jeff,
deparment
who's
been
listening
in
on
this,
too,
is
a
good
example
of
one
of
the
ISPs
from
crunching
data,
who's
managed
to
containerize
up
his
application,
and
it's
multiple
containers,
not
just
a
single
one.
So
there's
some
complexity
for
doing
that.
A
Now
really
out
loud
is
there
okay
for
Jonathan?
You
can
unmute
yourself
and
ask
the
question:
is
there
a
potential
for
a
maven
or
Gradle
plug-in
to
trigger
the
STI
command?
This
seems
like
a
great
way
for
developers
to
automate
the
process
of
deploying
the
doctor
image
to
run
on
their
local
machine
so
that
it
matches
production
environment,
a
local
testing
and
stephenie
code.
Yeah.
B
So
there
there
is
not
a
plug-in
today,
but
is
there
potentially
that
would
make
plenty
of
sense
to
me.
If
that's
the
you
know
the
workflow
that
a
developer
reviews
as
they
prefer,
you
know
they're
working
in
maven,
and
they
want
to
just
do
that
as
a
maven
step
to
package
things
up
yeah.
That
would
be
a
very
logical
thing
to
do.
B
Don't
think
you
would
have
to
customize
her
for
anything
that
would
that
would
purely
be
a
plug-in
made
available
to
you,
no
maven
or
Gradle
as
just
a
standard
name
and
her
Gradle
plugin.
That
would
just
contain
the
logic
to
do
the
s2i
invocation,
so
it
would
just
yeah
sort
of
a
standalone
additional
tool
that
certainly
we'd
be
happy
to
reference
from
from
the
s2i
tools
say
you
know
to
point
people
to
if
they
were
interested
in
doing
that.
A
B
Open
open
an
issue
on
github,
if
you
have
a
feature,
you're
interested
in
or
or
you're
hitting
a
bug,
and
we
can
discuss
it
and
decide
you
know,
is
it
the
right
fit
and
shape
up
what
we
want
that
to
look
like
and
if
you're
interested
in
contributing
the
code
then
submit
a
pull
request?
If
not,
we
will
put
the
feature,
requests
on
our
backlog
of
things
to
get
to
and
try
and
make
that
improvement.
A
B
You
can
share
so,
like
I
said
in
the
next
couple
of
days,
I'm
hoping
that
we
actually
land
the
pull
request,
and
we
will
do
an
official
s2i
release
once
that
merges
since
it
is
a
big
change,
so
I
I'm
going
to
optimistically
say
you
know
by
the
end
of
next
week.
I
would
expect
that
we
would
have
that
gun.
If,
if
not
it
is,
it
is
certainly
within
that
timeline.
It's
not
months
away.
It
is.
It
is
days
away
so.
B
It
is
particularly
useful
for
sort
of
the
DevOps
separation,
where
the
ops
team
would
like
to
ensure
that
developers
aren't
just
going
nuts
and
putting
everything
in
the
world
into
their
docker
files
or
that
they
evolve
a
system
of
every
every
single
developer
and
every
single
application
has
a
slightly
different
docker
file
and
set
of
things.
So
it
gives
the
ops
team
the
ability
to
say
here
are
the
frameworks
we
support.
B
We
know
these
have
the
right
versions
and
you
just
your
developers,
you
bring
the
source
code,
we
provide
the
framework
that
you're
running
on
and
you
can
do
that
with
docker
files,
but
you
have
to
be
a
lot
more
careful
to
make
sure
that
whoever
is
writing
those
docker
files
isn't
doing
things
you
didn't
want
them
to
be
doing
in
it.
So
that's
another
advantage.
If
you
have
a
large
team
or
a
complicated
system
where
you're
you're
bringing
a
little
more
control
of
the
process
of
what
is
going
into
those
images.
A
And
we've
heard
various
times
on
in
the
Commons
briefings
from
Kota
bond
and
other
of
the
large
enterprises
that
are
running
large
teams,
developing
lots
of
applications
that
this
is.
This
is
one
of
the
use
cases
that
they're
really
keen
fit
to
have
supported
so
it'll
be
interesting
to
see
if
we
can
get
some
more
community
support
and
to
use
this
with
other
container
platforms
they
rocket
and
other
things
and
how
it
moves
forward.
So
really
thank
you,
Ben
and
your
team
for
all
the
work
you
guys
have
been
doing.
A
B
So
can
I
pull
artifacts
from
a
remote
location
like
Nexus
and
create
a
new
image
based
on
some
base
image
yeah.
In
fact,
that's
exactly
what
the
wild
quad
build
was
doing
there.
It
was
calling
dependencies
down.
That's
really
not
the
s2
I
tool,
doing
it.
It's
the
assemble
script
and
the
logic
in
the
assemble
script
is
going
to
pull
dependencies.
So
in
that
case
it
was
doing
a
maven
package
and
part
of
the
maven
processing
was
to
pull
those
dependencies
down.
The
assemble
script
could
have
curl
commands
that
are
pulling
artifacts
as
well.
A
B
Certainly,
one
of
the
advantages
is
that
Jenkins
configuration
flow,
I'm
I'm,
not
sure.
As
far
as
the
less
about
talk
polish
is
true,
somebody
needs
to
write
a
docker
file
somewhere
with
or
without
s2i.
The
question
is:
who
is
that?
That
needs
to
write
it
and
without
as
to
why
that?
Who
is
the
developer,
needs
to
write
it
with
s2i?
The
developer
doesn't
have
to
do
it.
The
developer
can
rely
on
that
Eko
system.
B
A
That's
actually
a
wonderful
thing
as
a
developer,
ticular,
so
alright
going
going
gone.
Thank
you
very
much.
That
brings
us
almost
to
the
end
of
the
hour.
It's
been
great
to
have
you
here,
Ben
and
I'm.
Sure
we'll
have
you
back
again
soon,
so
maybe
we'll
get
that
what
we've
done
and
get
all
the
ISPs
happy
all
right.
Take
care
all.