►
From YouTube: CERN's 1500 Drupal Websites on Kubernetes: Sa... Konstantinos Samaras-Tsakiris & Rajula Vineet Reddy
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
CERN's 1500 Drupal Websites on Kubernetes: Sailing With Operators - Konstantinos Samaras-Tsakiris & Rajula Vineet Reddy, CERN
Follow the learning journey of junior developers towards a Kubernetes-native SaaS and hopefully get some ideas for your next (or first!) design. This talk is the development chronicle of a service provisioning Drupal websites that are CERN's public face, to replace the ageing physical infrastructure and reduce dependency on homebrew components. The presenters give their junior engineer's perspective, thrust into a world of Microservices, Observability and Operators. They will walk you through the design implementing the specific requirements of a service that targets varied user groups and is supported by a small team of engineers. Contrary to the old website management system that was a standalone application, now Operators play this role, leveraging Kubernetes as a common API to control different kinds of resources.
A
A
B
A
One
of
the
four
big
experiments
at
cern.
We
try
to
understand
nothing
less
than
the
origins
of
the
universe
at
the
heart
of
cms
collisions
happen
many
times
per
second
between
particles
of
two
opposing
particle
beams
and
out
of
those
collisions.
An
explosion
of
secondary
particles
washes
through
the
building-sized
three-dimensional
camera.
A
A
A
There's
people
that
are
that
come
from
many
backgrounds,
there's
like
physicists,
whose
responsibilities
also
include
site,
building,
and
also
administrative
personnel
and
communications
expert,
and
actually
a
very
small
minority
of
the
site.
Administrators
are
actually
web
developers,
people
with
site,
building
experience
or
drupal
experts,
and
all
of
these
people
need
to
have
the
same
easy
experience
or
very
reliable
hosting,
where
they
don't
have
to
take
a
lot
of
responsibilities
upon
themselves,
to
respond
to
security
incidents
or
be
responsible
for
upgrading
their
websites
or
from
recovering
from
made
from
common
failures.
A
And
at
the
same
time,
they
need
to
have
the
flexibility
to
use
custom
modules
and
themes
that
are
not
part
of
the
standard,
central
distribution.
So
all
of
these
requirements
are
what
our
infrastructure
has
to
satisfy.
We
are
not
talking
about
a
basic
drupal
hosting
service,
but
about
a
managed
and
complex
software
as
a
service.
A
Drupal
itself
is
very
complex
because
it
has
a
lot
of
modules
that
can
be
included
with
quadruple
and
and
in
our
case
they
need
to
actually
be
injected
by
the
users
at
the
instant.
At
the
time
when
a
site
is
instantiated
and
also
a
single
website
has
two
pieces
of
state,
it
has
a
database
and
also
it
has
a.
A
So
take
now
1500
instances
of
a
complicated
thing
and
then
try
to
automate
the
business
and
operational
logic.
Let
users
self-provision
websites
and
then
do
all
this
with
a
very
small
engineering
team
that
is
more
or
less
the
recipe
for
the
problem
that
we
are
solving
today.
So
how
do
we
actually
create
our
sites
on
kubernetes?
Let's
see
our
design.
A
A
This
entity
is
operated
by
an
external
component.
That
is
aptly
named
an
operator,
and
we
will
see
this
external
component
creating
other
kubernetes
resources
that
the
drupal
site
needs
to
be
instantiated,
but
the
drupal
site
on
its
own
needs
to
also
integrate
with
external
services,
provided
by
other
certain
teams.
A
A
That
is
not
enough,
though,
because
the
site
needs
to
pass
through
an
initialization
phase
that
ensures,
for
example,
that
the
sso
page
has
the
sso
integration
has
been
set
up
and
only
after
that
it
can
be
made
accessible
to
the
public
through
an
ingress
route.
So
all
of
this
is
functionality
that
is
handled
by
the
drupal
site
operator.
A
So
we've
been
talking
about
operators,
but
what
are
they
exactly?
Let's
try
to
understand
them.
This
is
etcd
kubernetes,
key
value
store.
It
holds
all
the
information
about
what
should
be
in
the
cluster
and
actually,
I
believe
that
you
are
familiar
with
many
of
those
entities,
a
pod,
a
job,
an
ingress
resource.
A
So
the
controller
is
a
piece
of
code
that
knows
the
internals
of
the
behavior
of
how
this
resource
should
behave
and
when
it
is
notified
that
something
has
happened
with
a
resource
that
it
is
watching.
It
then
takes
action
and
its
action
is
to
make
sure
that
the
world,
the
actual
state
of
the
cluster,
represents
what
is
specified
by
the
resource.
A
B
A
What
an
operator
is
as
well
an
operator
is
essentially
taking
all
of
what
we
have
described
now
for
basic
kubernetes
and
extending
it
to
custom
types
that
we
have
defined
as
users.
That's
it
and
in
this
case
the
custom
type,
which
is
actually
called
the
custom
resource
definition
or
crd.
For
short,
it
is
a
drupal
site,
and
this
piece
of
code
is
the
drupal
site
controller
together
and
with
a
way
to
deploy
them
in
the
cluster.
We
form
the
drupal
site
operator.
A
A
A
We
can
benefit
from
software
development
kits
the
operator
sdk
and
coop
builder,
which
make
all
the
scaffolding
which
put
in
place
all
the
scaffolding
for
us
and
make
it
much
easier.
We
write
most
of
our
operators
in
co,
with
a
few
exceptions
in
ansible,
and
essentially
all
that
we
have
to
do.
We
take
already
scaffolding
that
can
run
the
reconciliation
loop,
the
reconciliation
logic
in
a
loop
and
access
the
kubernetes
api,
and
all
that
we
have
to
do
is
to
actually
input
the
reconciliation
logic
itself.
B
Thank
you,
constantinos.
Now
that
we
have
covered
infra
design
and
some
concepts
about
the
operator.
Let's
talk
about
the
operators
we
have
developed,
the
first
one
would
be
the
drupal
set
operator.
The
functionality
of
this
is
to
create
drupal
sets.
Here
you
can
see
the
custom
results
of
a
sample
site.
B
B
Now
say:
I
give
an
incorrect
url,
which
is
in
the
byte
by
any
dns
rules.
Then
the
operator
will
try
to
enforce
it
and
then
it
realizes
that
it's
an
error
and
then
it
comes
back
and
then
it
sets
the
state
back
to
the
previous
working
url.
So
this
is
exactly
how
an
operator
syncs
with
the
world
and
then
maintains
a
state.
B
We
also
have
an
object
and
called
status
in
the
same
cr
in
the
same
custom
resource,
so
the
status
represents
the
current
status
of
a
drupal
site.
If
something
goes
wrong
internally,
the
operator
will
update
the
status
accordingly
in
order
for
the
adventure
users
to
understand
what
actually
went
wrong.
B
So
what
is
the
capability
of
our
operator?
What
exactly
can
it
do?
So
there
are
five
levels
of
capabilities
defined
by
the
operator
framework.
We
are
currently
at
the
end
of
level
2
with
other
culture
operator,
but
our
goal
is
to
be
at
level
4..
So
currently
we
are
able
to
provision
sites
and
do
basic
upgrades.
B
Remember
the
other
operators
mentioned
earlier,
like
the
authorization
operator
and
the
external
db
operator,
etc.
So
these
operators
are
not
providing
the
application
like
a
drupal
site
or
any
other
service,
but
they
are
very
critical
in
fraud
like
they
take
care
of
ssr
integration.
They
take
care
of
a
database,
since
it's
already
mentioned
that
we
have
different
teams
providing
different
services,
etcetera.
B
B
B
B
B
Once
a
new
ports
are
running,
the
operator
tries
to
update
the
tv
schema,
but
this
is
a
required
part
for
drupal
updates,
say
if
something
fails
in
either
of
these
cases.
The
operator
performs
a
rollback
and
it
also
updates
the
same
in
the
status
of
the
custom
resource
and
after
this
it
will
put
the
site
back
in
maintenance
mode
and
then
continues
to
reconcile.
B
So
at
the
end,
if
you
have
a
successful
update,
we'll
have
a
new
version
of
the
drupal
site
serving
requests,
if
not
we'll
still
have
the
same
old
version
serving
requests
now
coming
back
to
the
demo,
so
the
workflow
is
still
happening.
While
that
happens,
there
is
one
other
thing
I
want
to
talk
about.
B
So
we
tried
to
migrate
around
thousand
plus
websites
on
our
pre-prod
just
for
this
demo,
but
we
were
only
able
to
do
around
420,
plus
we've
seen
some
scaling
issues
that
prevented
us
from
migrating
more
websites
which
are
figuring
it
out.
So
in
a
way,
every
step
we
take
we're
having
to
look
at
our
infrastructure
and
then
adapt
accordingly.
B
B
Version,
okay,
so
I
see
the
new
version
here,
which
is
19.1.5
and
if
I
go
back
check
the
status,
I
see
that
the
update
needed
has
also
been
set
to
false.
So
this
is
a
successful
upgrade.
Now,
let's
try
something
else,
so
we
have
another
site
which
is
kubecon
b,
which
is
already
serving
if
I
go
look
at
the
spec
same
as
the
previous
one.
So
if
I
go
look
at
the
web
page,
the
web
page
is
serving
if
I
can
confirm
the
version
of
the
drupal
from
the
web
page.
B
B
It
is
still
serving
with
the
older
version
as
it
should
so
because
the
upgrade
didn't
go
ahead
just
keep
serving,
and
I
see
that
there
is
a
new
status
condition
that
tells
the
user
of
the
admin
that
there
has
been
a
failure.
So
we
have
seen
two
scenarios
here
in
the
first
one
we
have
seen
a
successful
upgrade,
the
second
one
we
have
seen
a
failed
upgrade
now
back
to
constantinos.
A
A
A
It
essentially
enables
the
process
of
auto-provisioning
clusters
for
development
purposes
or
for
ci
purposes
for
running
the
end-to-end
tests,
and
this
thing,
taken
together,
makes
it
makes
us
have
development
clusters
that
are
really
close
to
the
production
environment.
Essentially,
the
difference
between
our
production
environment
and
our
development
cluster
is
a
few
helm
values,
and
that
is
all
so
taking.
If
we
take
these
things
together
and
then
the
learning
material
that
we
used
from
the
coop
builder
book
and
operator
framework,
we
really
had
a
very
good
head
start
to
get
going
on
this.