►
From YouTube: London OpenShift Commons Gathering 2019 OpenShift at BIX Michael Sauter Boehringer Ingelheim
Description
London OpenShift Commons Gathering 2019 OpenShift at BIX
Michael Sauter
Boehringer Ingelheim
A
There
we
go
all
right,
we're
back
on
customer
use
cases
and
really
excited
to
have
a
new
open
ship,
Commons.
Member
and
new
to
me
case
study
around
open
shift
on
OpenShift
dedicated
and
Michael
Sauter
from
BICS
and
he'll.
Explain
what
VIX
stands
for
and
take
it
away
and
there'll
be
a
little
we're
gonna
get
a
little
room
at
the
end
for
a
little
Q&A
with
him.
Probably
so,.
B
On
and
off
again
not
this
time,
I
guess
all
you
see
is
that's
a
no
words.
So
what
is
bi
X
BX
is
very
engli,
Himes
digital
lab
and
for
those
who
also
haven't
heard
of
growing
English
I'm
bi
is
one
of
the
largest
pharmaceutical
companies
worldwide
and
we
had
bi
X.
We
use
digital
innovation
to
accelerate
the
development
of
Health,
mint
of
health
care
cures
and
also
the
discovery
of
breakthrough
treatments.
So
we
use
openshift
as
a
platform
where
we
deploy
our
services
to
as
additional
lab.
B
Probably,
okay
and
I
want
to
focus
a
little
bit
about
what
these
initiatives
are
and
how
their
life
is,
how
we
develop
on
those-
and
this
will
also
be
somewhat
related
to
the
previous
talk
about
open
source
and
enterprise,
because
we
had
VIX
and
digital
labs.
We
have
a
little
bit
more
freedom
and
we
actually
use
a
lot
of
open
source
technology
and
are
also
contributors
to
open
source.
So
everything
that
you
will
see
what
I'm
going
to
talk
about
today
is
actually
also
open
source.
B
So
when
the
initiative
starts,
the
goal
is
obviously
to
develop
the
MVP
as
fast
as
possible.
However,
there
are
many
boring
tasks
that
are
in
the
way,
so
every
initiative
will
have
the
same
requirements
roughly
that
have
nothing
to
do
with
what
the
product
is
actually
about
right.
The
product
might
be
very
exciting,
AI
technology
whatever,
but
for
the
team
that
works
on
this,
you
still
need
the
same
set
up,
so
you
need
something
for
team
collaboration
use,
for
example,
JIRA
confluence.
You
need
to
set
those
up
for
the
team,
then
infrastructure.
B
Yes,
we
use
open
shift
as
a
platform,
but
just
the
platform
itself
is
not
enough
right.
You
need
various
environments
where
you
have
your
development,
your
staging
and
so
on.
You
also
need
to
think
about
CI
NCD.
How
do
you
build
your
software?
How
do
you
test
your
code?
How
do
you
scan
code?
How
do
you
analyze
code?
How
do
you
deploy
to
open
ship,
and
also
many
of
those
initiatives,
will
work
with
the
same
primitives?
So,
for
example,
you
might
want
a
springboard
application
or
a
node
application,
an
angular
front-end,
an
ionic
app.
B
These
boiler
plates
are
always
the
same
and
going
even
a
bit
further
than
boiler
plates.
You
might
even
want
the
same
components
so,
for
example,
user
authentication
right
we
want
to
have
the
user
service
people
can
authenticate.
We
want
to
try
out
our
idea
quickly
and
not
work
on
the
user
authentication
in
every
team,
so.
B
B
They
is
not
prescribed
how
your
process
looks
like
how
your
pipelines
look
like,
and
so
the
desig
we
build
around.
It
solves
those
issues,
and
this
is
not
only
our
deficit
againi,
more,
it's
open
source.
That's
why
we
call
it
the
open,
def
stack
and
it
allows
you
to
set
up
required
infrastructure
and
continue
delivery
processes
for
new
projects
in
less
than
five
minutes.
So
it's
kind
of
an
opinionated
way
to
develop
your
applications.
B
Let's
step
a
bit
through
what
you
get
with
open,
devstack,
to
show
you
a
little
bit
what
it
gives
you.
So
one
part
is
that
you
can
provision
a
new
project.
A
new
project
for
us
means
you'll,
get
a
confluence
into
your
space
set
up.
You
will
get
a
company
bid
packet
project
set
up,
you
get
openshift
environments,
so
initially
you
get
two
for
development
and
staging,
and
you
can
add
more
as
you
go,
and
every
initiative
also
gets
their
own
CI
CD
set
up.
B
So
you
get
your
own
Jenkins
instance,
and
if
you
side
things
around
that
which
I'll
get
to
later
so
with
this
set
up,
a
ninja's
initiative
is
ready
to
go.
There
is
no
code,
yet
there's
no
application
yet,
but
you
basically
have
the
space
in
which
you
can
operate
and
once
you
provisioned
a
new
project,
you
can
then
go
on
and
provision
components
so
components.
B
Also
you
can
provision
them
with
one-click.
Basically,
you
pick
from
a
list
of
quick
starters.
We
call
new
quick
status,
so
this
again
might
be
a
spring
boot
application
or
a
proxy
or
a
mobile
application,
and
this
will
provision
you
a
repository
with
some
boilerplate,
that
the
developer
then
is
ready
to
start
developing.
You
also
get
openshift
resources
so,
for
example,
for
spring
boot
application
you
would
get
an
image
stream,
a
buildconfig
service
deployment
configure
route,
so
everything
will
be
connected
and
set
up
for
you
after
provisioning,
and
you
also
get
a
CI
LCD
pipeline.
B
So
with
this
provisioning
you
it
can
build
the
code,
it
analyzes
the
code
and
applies
the
code.
So
basically,
after
you
click
provisioning,
everything
is
fully
auto
deployed
until
in
the
in
the
development
or
staging
environment,
let's
but
deeper
into
what
open
deaf
psyche
is
made
out
of
if
it's
basically
four
different
components.
So
we
have
a
core.
There
are
certain
things
that
the
other
parts
need,
for
example,
based
images
and
so
on.
There
is
also
setup
of
the
atlantean
products,
so
JIRA
confluence.
There
is
a
central
Nexus
to
store
artifacts
in
OpenShift.
B
There
is
also
a
central
sonar
cube
server
for
code
analysis
that
each
initiative
can
use.
Then,
next
to
the
core,
there
is
the
provisioning
app.
This
enables
users
to
provision
new
projects
and
quick
status
within
those
projects.
The
provisioning
app
itself
is
kind
of
an
example
using
the
same
process.
It's
actually
made
out
of
the
same
quick
starter
and
it
runs
within
open
ship.
So
it's
kind
of
eat
your
own
dog
food
uses
the
same
pipelines
to
go
a
bit
more
into
detail.
What
those
quick
starters
are,
quick
starters,
are
sort
of
skeleton
apps.
B
The
basics
would
be,
for
example,
for
spring.
Would
you
have
a
you
run
a
CLI
and
you
get
a
spring
good
application,
but
it
also
does
some
modifications
to
make
it
actually
run
on
openshift.
The
quick
starter
has
also
the
information
on
how
to
build
that
project.
So
there
will
be
Jenkins
agent
images
that
the
Jenkins
pipeline
can
use.
There
is
a
Champions
file
which
describes
how
to
build
and
deploy
this
application.
B
It
also
delivers
how
to
run
the
application,
so
the
the
docker
file,
the
deployment
config
and
so
on,
and
it
sets
up
openshift
resources.
And
finally,
there
is
Jenkins
shared
library,
so
this
Jenkins
allows
you
to
have
to
import
a
shared
library
into
your
pipeline,
and
that
allows
you
to
extract
generic
tasks.
You
need
to
do
in
your
pipeline,
so,
for
example,
the
shared
library
checks
out
code.
It
selects
which
environment
to
deploy
to
it
also
does
a
bit
of
integration.
So,
for
example,
it
communicates
bill
status
with
bitbucket.
B
B
Function
from
from
the
shared
library
ODS
pipeline,
where
you've,
where
you
reference
an
image,
an
agent
image
that
comes
with
a
quick
starter,
it
maps
branches
to
environments.
So
you
can
say,
for
example,
where
the
master
environment,
master
branch
should
go
to
test
and
all
other
branches
should
go
to
def.
You
can
set
this
up
whatever
you
want,
and
then
you
can
see
the
stages
that
the
quick
starter
will
do
by
default.
B
So
the
thing
looks
very
much
like
a
normal
champions
file,
just
that
you
can
define
some
stages
yourself
and
other
stages,
you
just
reference.
So,
for
example,
in
this
case
this
is
a
Java
project,
so
it
builds
with
Gradle.
The
shared
library
does
not
know
how
to
build
Java
projects
as
such,
but
it
knows,
for
example,
the
next
step.
How
do
you
scan
and
put
that
to
sonarqube?
B
Now.
There
are
a
few
nice
things
in
open
devstack,
which
are
not
part
of
a
default
setup.
One
thing,
for
example,
is
we
call
the
Vepr
proxy
openshift
has
a
integration
with
jenkins,
so
you
can
create
a
pipeline
and
openshift
that
will
be
mirrored
in
Jenkins,
but
it
is
a
bit
tricky
to
have
basically
one
pipeline
per
branch,
which
is
what
we
wanted.
So
the
workflow
is
that
you
push
co2
to
bitbucket.
Then
bit
package
will
trigger
a
webhook
triggering
the
build
config
in
OpenShift
right.
B
But
then
you
already
have
some
preset
build
config
and
you
don't
know
how
many
you
will
need
and
we
don't
want
the
application
developers
to
set
up
their
own
pipelines.
So,
instead
of
triggering
the
buildconfig
directly,
we
trigger
a
backup
proxy
and
then
this
replica
proxy
deals
with
creates
pipelines
on
the
fly
and
removes
them
as
needed.
So
with
that,
you
get
one
pipeline
per
branch,
and
this
is
quite
nice
for
the
for
the
build
history
and
to
keep
things
separate.
B
We've
also
built
in
an
ad
hoc
cloning
of
environments
via
Jenkins.
So,
for
example,
you
can
say
that
for
in
JIRA
I
have
user
stories
and
for
all
my
user
stories,
I
want
to
spin
up
a
separate
review
environment
that
is
cloned
from
my
normal
deaf
environment.
I
want
to
have
the
same
openshift
resources,
but
I
want
them
separately
under
a
separate
URL.
So
what
you
can
do
is
you
can
instruct
Jenkins
to
basically
say
ok
for
this
particularly
user
story
that
I
am
receiving.
B
B
Then
there
are,
of
course,
many
small
things
that
open
tastic
provides,
for
example,
that
all
the
creek
starters
are
configured
to
pull
that
dependencies
via
Nexus.
So
I
just
use
this
as
an
example
to
to
say
that
often,
if
you
just
provide
a
nexus
instance,
it
doesn't
mean
that
everyone
uses
them
right,
but
if
you
make
sure
that
all
the
boilerplates
people
are
start
with
are
already
correctly
configured,
then
those
things
actually
used
and
then
the
open
def
stack
also
comes
with
a
few
migration
scripts
to
move
projects
from
one
cluster
to
another.
B
B
Now
I
want
to
take
a
little
bit
of
a
detour
and
talk
about
one
particular
thing
we
built
into
opened
a
stack
or
a
problem
we
faced
and
the
solution
we
came
up
with,
and
this
problem
is
basically
around
how
our
resource
is
set
up.
So
I
talked
about
that
we
have
a
sonarqube
instance
or
Nexus.
So
if
users
want
to
install
the
DEF
stack
in
their
own
openshift
cluster,
how
do
you
actually
set
up
those
things?
So,
as
many
of
you
know,
I
guess
there
are
ways
to
do
this.
You
have
it.
B
You
have
templates,
you
have
a
manifest
that
you
can
bring
up,
so
this
is
kind
of
solved,
but
afterwards
so
say
you
have
an
instance
deployed
then
later
on,
a
new
version
of
open
desta
comes
around
and
you
want
to
see
what
has
changed.
What
is
the
difference
between
what
the
new
version
is
and
what
is
running
in
my
hosta?
What
is
the
drift?
How
do
I
detect
that
drift
and
how
do
you
I
review
what
the
difference
is?
B
And,
finally,
once
you
know
what
the
drift
is
between
two
different
classes,
two
different
configurations:
how
do
I
sync
them
back
up
and
we
didn't
find
a
solution
that
was
very
easy
to
use.
It's
still
based
on
the
open
chef
templates
and
that
is
very
low
entry.
Basically,
so
we
developed
a
small
tool
on
top
of
the
OC
commands,
which
does
that
I
call
this
as
basically
a
terraform
for
open
shift,
as
most
people
know,
terraform.
B
Of
course,
terraform
has
varied
as
a
lot
of
providers
it.
It
doesn't
have
like
a
nice
open
shift
target
so
to
say
where
you
can
manage
your
deployment,
configure
your
build
config
via
code,
so
this
I
think
is
partly
because
there
is
some
weird
mixture
between
config
and
state
in
the
resources
in
open
chef.
So
this
tailor
is
standard
tool.
We
use
it
a
lot
in
open
des
X.
B
So
basically,
when
you
install
open
devstack,
you
setup
all
the
infrastructure
on
open
shift
with
this
tool
and
when
new
versions
come
around,
you
can
update
with
this
tool.
How
it
works
is
pretty
simple.
So
first
you
get
the
desired
state.
This
is
what
is
in
your
templates,
so
your
OpenShift
templates,
we
use
OC
process
to
process
them
with
parameters
and
then
compare
the
desired
state
with
a
current
state,
which
is
an
export
from
your
cluster.
You
compare
that.
You
get
the
drift.
B
You
can
see
this
as
textual
diff,
so
people
can
review
what
the
differences
are.
For
example,
you
add
some
new
environment
variables
to
your
deployment.
Config
and
tailor
can
then
generate
chase
and
patches
from
that
and
pass
these
chase
patches
to
apply
those
updates.
This
is
crucial
because
the
standard
or
C
apply,
for
example,
does
not.
It
does
not
delete
configuration
there.
So,
for
example,
if
you
want
to
change
the
deployment
strategy
of
a
deployment
config,
you
cannot
do
that
with
a
OC
apply,
because
it
will
not
delete
the
other
deployment
strategy.
B
So
you
will
need
to
use
OC
patch
and
Aussie
patch
is
tricky
to
use.
If
you
don't
have
a
tool
that
generates
those
patches
for
you,
because
you
need
to
alright
them
by
hand.
So
Taylor
does
that
by
himself
it
figures
out
what
to
do
and
does
that
so
yet,
as
I
said,
a
standalone
tool.
So
if
you
want
to
do
something
like
that,
that's
pretty
cool
too
also.
We
can
manage
your
whole
resources
that
way
and
it's
a
very
low
entry,
because
you
still
use
the
standard
openshift
templates.
B
B
So
if
there
is
some
kind
of
glitch
we
solve
it
once
and
open
def
stick
tries
integrate
tools
very
tightly
so,
for
example,
integration
between
open
Geoff,
Jenkins
and
big
packet
I
think
it's
very
nice
that
you
don't
get
out
of
the
box
and
all
of
that
what
I
described
is
completely
open
source.
So
at
github
calm,
slash
opened
s
Tech
and
we
basically
run
our
dev
sick.
Just
based
on
that.