►
Description
OpenShift Commons Gathering at Kubecon/EU 2021
Title:
End to End OCP 4 clusters deployment automation in IT context at Amadeus
Speakers:
Thibaud Castaing (Amadeus)
Maria Emmanuelli (Red Hat)
Vincent Bronikowski (Red Hat)
Abstract:
Who doesn’t like listening to a success story full of challenges and wins? This story starts with a challenge, with the covid-19 pandemic. The project’s objective was to repurpose abandoned blades, by using OSP. It involves an innovative way to save resources and reduce the business impact of covid-19, using Red Hat Solutions. We’ll share the story of how Red Hat worked with Amadeus following Agile principles to deliver a disconnected install of OpenShift 4.6 with Calico on OpenStack. This process was automated End to End by combining several technologies into a tool following while adhering to Amadeus' need for synergy across platforms.This automation allows for the creation of clusters on demand in a repeatable way, serving as Cluster as a Service. Interested already? There’s more. Because a demo is worth a thousand words, we will show you the automation tool and share Amadeus’ testimony.
https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_at_Kubecon_EU.html
A
So
hello,
thank
you
for
attending
our
tag.
End-To-End
openshift,
4
clusters,
employment,
automation,
innovation
in
amadeus
iit
context.
So
my
name
is
marie
alejandra
manueli.
I'm
an
open
shift
red
head
consultant
working
in
the
iron
man
amadeus
project.
With
my
colleagues
vance
and
bernie
koski
and
tivo
casten.
I
will
let
them
introduce
themselves.
C
C
So
before
digging
into
the
project
itself,
let's
start
by
introducing
amalus
in
a
few
words
or
those
who
don't
know
what
amilus
is
doing.
Ramadis
is
a
global.
Is
a
technology
company
dedicated
to
the
global
travel
industry?
We
are
present
in
almost
200
countries,
with
a
worldwide
team
of
more
than
19
000
people.
C
C
C
As
you
all
know,
the
major
event
of
2019
is
a
covet
19
crisis
and
being
in
the
travel
industry
business.
We
have
been
impacted,
so
we
could
not
grow
our
man
private
cloud
as
intending
which
became
quite
a
blocker
adidas
migration
to
the
cloud
as
there
was
still
the
need
to
further
clarify
our
operation
model
and
applications.
C
So
in
2020,
the
low
use
of
our
classic
infrastructure
brought
the
opportunity
of
potential
repurpose
of
several
hundreds
of
servers
to
create
a
new
yes
cloud
and
due
to
the
usage
of
older
hardware,
this
stack
has
been
called
iron
man
light
and
the
purpose
of
this
iron
man
light
project
was
to
leverage
existing
unused
hardware
and
provide
new
cloud
platforms
with
a
minimal
cost
and
an
excellent
operational
model.
Thanks
to
openg4
and
this
to
continue
amadous
migration
to
the
cloud.
C
So,
let's
talk
about
amalu's
technical
requirement
for
this
project,
so
in
amadeus
we
have
quite
some
experience,
deploying
openshift
4
in
the
public
cloud,
mainly
on
azure,
but
deploying
it
on
premise
was
a
completely
different
challenge
and
that's
why
we
requested
the
expertise
of
red
hat
to
help
us
on
this
task.
As
the
core
of
this
project
was
around
two
red
hat
products
openg4,
so
it
was
4.6
at
the
time
of
the
project
and
openstack
16..
C
C
C
Finally,
the
idea
of
this
project
was
to
be
able
to
create
a
full
cluster
with
like
a
single
command,
consuming
a
single
config
file
and
input,
and
this
reusing
some
automation
already
built
internally
by
melus.
We
deploy
some
cluster
on
azure,
so
we
don't
have
to
struggle
to
recreate
clusters
and
we
cannot
cluster
the
service
model.
B
Thanks
tibo,
so
the
main
thing
we
want
to
share
with
you
in
this
talk
is
the
experience
of
intercollaboration
with
a
client
and
the
red
hat
in
a
consulting
project.
So
we
started
this
project
with
the
week
of
navigate
workshop.
The
red
hat
navigate
is
a
tried
and
test
framework
that
helps
our
customers,
identify
obstacles
and
align
their
business
goals
to
deliver
successful
solutions.
B
So
the
project
was
delivered
by
the
red
hat
as
the
principal
leader
with
a
collaboration
of
americas
and
as
a
team
radar
constantly
worked
as
an
autonomous
team
within
madison
and
the
delivery
was
has
worked
very
well,
given
the
maturity
of
amadeus
in
the
openshift
adoption
journey.
So
I
will
talk
a
little
bit
to
you
about
the
implementation
and
delivery
of
the
platform
that
amadous
required
so
based
on
the
prerequisite
that
tibo
caston
told
us,
so
we
deployed
on
premises
cluster
which
were
on
three
eights
it
so
to
prevent
crashes.
B
If
some
server
went
down,
it
was
the
same
thing
for
the
all
the
storage
which
were
using
cinder
in
different
exits,
so
everything
was
well
dispatched
on
the
infrastructure
and
as
a
prerequisite,
everything
is
being
deployed
with
the
ipi
fashion.
So
you
don't
have
to
provision
machines
manually
when
scaling
up
the
clusters.
B
I
will
not
talk
a
little
bit
about
the
big
challenges
that
we
had
during
the
implementation
of
this
project
and
the
first
one
was
the
calico
integration.
So
it
was
a
big
challenge
because
basically,
the
use
case
of
having
calico
as
an
sdn
on
openshift
on
openstack,
as
basically
as
basically
no
documentation.
So
we
had
to
do
a
lot
of
work
and
research
is
to
understand
how
this
component
could
be
working
on
this
specific
integration.
B
We
had
to
do
a
lot
of
back
and
forth
and
testing
to
in
order
to
understand
how
calico
worked
and
how
to
make
it
viable
with
the
needs
of
amarillos,
and
in
addition
to
that,
after
having
calico
well
configured,
we
had
to
configure
and
understand
the
tiger
operator,
which
was
the
component
that
basically
deploys
it
automatically
when
creating
clusters.
So,
in
short
terms,
the
the
thing
that
we
had
to
do
a
lot
was
diving
into
the
code
of
this
component
to
understand.
B
What's
what's
happening,
to
make
it
work
and
and
make
amadeus
happy
about
the
calico
sdn.
The
next
thing
that
we
had
as
a
challenge
is
having
an
open
stack
on
premise
versus
cloud
provider
solutions.
So,
since
amadeus
wanted
to
have
a
an
excellent
operational
model,
we,
it
was
kind
of
complex
to
start
from
simple
deployment
using
on-premise,
openstack
and
iterate
through
everything
and
all
the
prerequisite
that
openstack
can
can
have
so
starting
from
the
storage
from
a
network,
configuration,
etcetera,
etcetera
and
how
to
deploy,
for
example,
multi-asset
cluster.
B
So
this
has
kind
of
complicated
to
have
an
on
premise:
environment
that
was
working
as
well
as
a
cloud
provider
and,
for
example,
even
some
really
specific
features.
We
weren't
working
as
intended
that
we
had
to
do
exchange
with
the
engineering
teams
to
have
everything
fixed
for
the
next
releases
of
openshift
on
openstack.
B
The
last
thing,
the
challenge
that
we
have
seen
as
a
big
challenge
was
being
reactive
with
all
the
amadeus
assets
and
needs.
So
the
integration
were
quite
complicated
and
with
every
with
the
everything
of
that,
we
had
them
to
integrate,
with
the
all
the
tools
that
our
amadeus
already
processed.
So
since
they
are
really
mature,
for
example,
they
have
a
tool
that
is
called
the
meduse
wrapper
that
helps
them
to
integrate
manifest
when
creating
clusters.
B
A
Thank
you
very
much
so,
while
performing
navigate
workshops,
we
do
this
exercise
where
we
ask
the
client
to
identify
business
priorities,
we
get
them
to
vote
on
their
top
three,
and
then
we
go
deep
into
the
explanation
of
why
these
were
chosen.
So
from
those
the
main
business
priority
identified,
was
operational
excellence
and
then
efficiency.
So
at
the
heart
of
this
conversation
there
was
the
topic
of
automation.
A
A
This
wasn't
something
new
for
amadeus
either
they
had
already
advanced
quite
a
lot
in
the
automation
topic.
As
advanced
song
and
tiva
mentioned,
there
was
the
existence
of
what
they
called
a
wrapper,
which
leveraged
the
openshift
installer
to
add
to
add
manifest
like,
for
example,
the
calico,
manifest
or
day
two
operations
during
the
install,
as
well
as
an
automation
tool
based
on
terraform
to
atomize
the
installation
of
openshift
clusters
in
asia.
A
So
the
easy
adoption
of
amadeus
daisy
adoption
of
automation
by
amadeus
made
it.
So
we
could
work
side
by
side
to
create
a
process
that
allowed
us
to
spun
up
clusters
on
one
click.
So
automation
became
very
quickly
one
of
the
top
priorities
of
this
project,
so
the
openshift
installation
was
automated
from
start
to
end.
So
how
did
we
do
with
this?
Let's
look
a
little
deeper
on
the
technical
side,
so
the
automation
tool
was
based
on
two
technologies:
heat
orchestration
and
terraform.
So
first,
let's
talk
about
e-templates.
A
So
he
templates
described
the
openstack
infrastructure
for
a
cloud
application
in
a
text
file
such
as
the
one
you
see
on
the
slide.
This
text
file
is
leveraged
to
create
a
stack
of
infrastructure
resources
such
as
networks,
subnet,
the
bastion
server
and
others.
The
high
integration
of
e-template
as
an
orchestration
technology
for
openstack
made
it
an
obvious
choice
as
a
technology
to
use
this
allowed
us
to
deploy
all
the
prereq
openstack
prerequisites
to
install
openshift
on
top
of
openstack.
A
So
now
that
we
know
the
vestment
server
was
automatically
deployed
by
e-templates,
you
may
be
wondering
how
did
we
did
to
actually
I
configured
the
bastion
server
so
for
this
we
used
cloud
indeed.
So
cloudy
need
is
an
industry
standard
that
identifies
the
cloud
is
running
on
during
boot.
Reads:
any
provided
metadata
and
configures
the
system
accordingly,
so
this
allowed
us
to
configure
the
bastion
server
during
boot
time
automatically.
A
So
the
moment
the
bastion
server
spun
up
repositories
are
configured
as
tibon
mentioned,
it's
a
disconnected
install,
so
we
needed
to
configure
the
repository
the
internal
repositories
of
amadous.
Then,
packages
are
installed.
The
client
and
the
openshift
installer
clients
such
as
the
oc,
client,
openshift,
client
and
swift
client
are
installed.
Then
the
installation
objects
such
as
configuration
files,
are
downloaded
in
this
case
from
a
swift
container
and
finally,
with
the
run
command
resource
cloud.
Init
launches
the
cluster
installation.
A
So
where
does
teraform
come
in
so
the
terraform
is
the
glue
that
brings
all
to
all
of
this
together.
So
to
give
it
a
little
context.
Terraform
is
an
open
source
infrastructures
code
tool
that
includes
an
openstack
provider
which
allows
us
to
create
openstack
resources
such
as,
for
example,
leveraging
e-templates
to
create
an
orchestration
stack.
A
The
terraform
also
includes
an
azure
provider,
which
is
why
it
was
used
as
a
tool
to
create
the
automation
for
azure
clusters.
So
how
is
there
from
the
glue?
Well,
we
have
three
main
things
that
we
needed
from
this
automation
tool,
so
we
needed
to
deploy
dates
and
plates
in
a
sequence.
So,
for
example,
we
need
to
deploy
first,
they
template
with
the
project
to
install
up
and
shift,
and
then
everything
else
that's
deployed
on
the
project.
A
Then
we
needed
to
create
installation
objects
and
installation
configuration
configuration
files
from
different
templates
and
we
needed
the
ability
to
variabilize
these
files
and
these
objects.
So
all
of
this
was
allowed
by
terraform.
So
at
the
end
the
automation
looks
something
like
the
diagram
you
see
on
the
screen.
A
So
if
we
go
a
little
deeper
on
the
diagram,
the
terraform
creates
a
orchestration
stack,
which
is
the
one
you
see
right
right
now
as
tag
tenant
on
the
diagram
that
deploys
the
project
where
openshift
will
be
installed,
sets
up
the
user
role
assignments
configures
the
code
test
for
this
project,
then
terraform
creates
the
floating
ips
for
the
ingress
and
for
the
api,
as
well
as
the
swift
container
that
will
store
the
installation
objects.
The
installation
objects
are
created
from
a
terraform
template
and
the
floating
ips
cluster
parameters.
A
Project
names
are
added
accordingly
and
then,
finally,
an
orchestration
stack,
which
is
the
one
ucs
tax
server
is
created,
which
is
which
deploys
the
openstack
prerequisites,
the
bastion
server
and
finally
launches
the
openshift
cluster.
So,
as
you
can
see
here,
this
tag
deploys
the
networks,
subnet
router,
the
floating
ap
for
the
server
the
ports
and
as
well
the
cloud
config
resources
that
will
configure
the
bastion
server
the
this
automation
tool
allowed
amadeus
to
deploy
clusters
in
a
repeatable
and
repeatable
way
and
on
demand
serving
as
cluster
as
a
service.
A
So
this
already
made
this
project
really
really
interesting,
but
in
my
opinion,
there's
something
even
less
tangible
than
technology
that
made
this
project
interesting
and
is
the
fact
that
this
part
of
the
project
was
looking
to
standardize
processes
within
amideos,
so
this
required
to
create
a
synergy
between
redhead
and
amadeus.
So,
while
creating
this
tool,
there
was
always
the
conversation
where
would
this
tool
be
compatible
with
what
is
already
done
or
will
be
compatible
with
the
existing
infrastructure
and
workflows?