►
Description
In session 12 of the group dedicated to sharing tips and tricks for building and deploying CMSs on Kubernetes, we dive into our favorite topic: making life easier for devs.
Learn more about DDEV’s mission: https://bit.ly/2LzAvr1
Catch up with the group on GitHub: http://bit.ly/338dXC5
A
Start
that-
and
here
we
are
again
for
another
meeting
of
our
kubernetes
6
CMS
i6
CMS
over
cig
Drupal's,
specifically
because
we're
looking
at
addressing
a
broader
range
of
CMS
patterns
that
allow
people
to
host
a
multitude
of
CMS
is
on
kubernetes
I.
Think
that
that's
a
developing
space
and
there's
a
lot
of
very
active
people
in
it
so
happy
to
be
a
part
of
that
conversation.
A
Typically,
what
we
do
is
just
go
around
the
room
with
some
quick
introductions
and
lots
of
familiar
faces.
So
I
expect
that
should
be
pretty
quick,
we're
going
to
go
through
a
quick
lightning
talk
from
Nick
Santa
Maria
on
skipper,
which
is
a
pretty
fantastic
looking
product
that
they've
put
together
very
interested
to
see
and
learn
more
about
it.
We're
going
to
open
it
up
to
discussion
shortly
after
that,
basically,
any
success
stories,
war
stories
things
people
would
like
or
typically
have
on
their
mind.
A
So
let's
go
ahead
and
kick
and
dive
right
in
I'm,
Kevin
bridges,
I'm
the
CTO
and
founder
of
a
company
called
nighty
death.
We
make
local
development
pools
and
are
very
interested
in
doctors
and
kubernetes
space
specifically
and
I.
Think
let's
go
with.
Let's
get
you
last
next
Santa
Maria
and
let's
move
on
to
Tom.
B
Yeah,
hey
Kevin,
yeah
Tom,
good
I'm,
like
from
engineering,
a
meze,
I/o
and
yeah
part
of
this
group,
and
thanks
guys
for
supporting
it
and
they're
really
just.
Unfortunately,
they
were
scheduled
and
conflicts
with
our
usual
care
thing
like
I
got
out
of
that
one
today,
so
yeah
well,
past
I
would
have
been
he's.
A
colleague
of
mine.
C
D
A
F
F
So
it's
our
managed
cloud
hosting
platform
built
with
kubernetes
and
AWS.
So
we've
been
running
kubernetes
in
production
for
about
four
years
now
and
skipper
is
the
culmination
of
all
our
learnings
over
that
time.
So
we
had
a
few
design
goals
in
mind.
The
first
was
for
the
tool
to
just
get
out
of
the
way
of
our
developers.
F
We
also
wanted
to
minimize
operational
hazards,
so
we're
a
very
small
team
and
we
don't
want
to
spend
all
of
our
resources
battling
with
outages
or
trying
to
configure
finicky
tools
like
glare
our
cluster
FS.
So
this
is
one
of
the
main
reasons
that
we're
on
AWS
and
we
heavily
leveraged
the
managed
services
they
provide
to.
You
know
make
sure
that
all
the
components
in
our
stack
are
highly
available,
so
the
CLI
is
a
simplified
interface
for
the
system.
F
This
is
a
overview
of
the
stack
so
at
the
edge
we're
using
CloudFront
and
Amazon
certificate
manager
and
Amazon's
laugh
service.
Our
Drupal
stack
runs
nginx
and
PHP
fpm,
which
independently
scalable,
so
each
each
project
is
has
its
own
namespace
and
each
environment
is
then
it's
own
set
of
deployments.
Config
Maps
volumes
within
that
kubernetes
namespace,
the
backend
services
are
mostly
AWS,
managed
services,
so
we're
using
Aurora
for
our
database
EFS
for
our
shared
file
systems
SES
for
outbound
mail,
and
we
have
the
option
to
use
other
AWS
services.
F
So,
to
make
the
nginx
fpm
architecture
work,
we
need
to
bake
multiple
images
with
identity,
identical
copies
of
the
source
code
in
it.
So
we've
done
this
with
the
skipper
package
command,
this
command
orchestrates,
the
front-end
back
and
compiling
steps
and
copies
the
compiled
artifact
into
all
the
images
that
need
to
be
deployed
on
the
cluster
once
the
images
are
baked
their
then
pushed
to
the
ACR
registry.
F
So,
okay,
quick
demo
of
what
that
might
look
like
to
so
parts
of
this
is
sped
up
by
basically
saying
package
with
version
zero
point.
One
point:
two
first
step
is
creating
a
layer
with
all
of
the
composer
dependencies
once
that's
completed
or
jump
on
to
all
the
front-end,
then
copies
those
two
layers
into
a
single
image
and
then
the
next
like
the
engine,
acts
the
fpm
and
the
CLI
image
all
copied
the
artifact
into
their
own
images
before
it
gets
pushed
up
so
yeah.
F
F
Alright,
so
once
the
image
is
a
built
and
pushed
they're
deployed
to
an
environment
with
a
single
command,
so
skipper
deploy,
updates
the
environment
objects
on
the
cluster,
and
then
these
changes
cascade
into
lower
level
CRTs
and
end
up
creating
kubernetes
and
AWS
resources,
which
are
all
wired
which
I
head
to
the
app
with
a
config.
That.
F
It
hey
Dennis,
he's
really
easy
yeah.
He
loves
kubernetes.
Yes,
so
this
skipper
deploy
does
a
lot
under
the
hood.
This
is
a
workflow
diagram
of
how
all
of
our
CR
DS
fit
together.
So
the
details
of
this
aren't
you'll
important
but,
as
you
can
see
like
up
here,
is
where
your
developers
touching
the
CLI
and
then
it
just
explodes
into
you
know.
Tens
of
of
controllers
down
here
which
result
in
kubernetes
objects
and
AWS
objects
being
created.
F
F
Yes,
next
up
is
configuring
the
app
so
the
skipper,
config
command,
allows
us
to
keep
configuration
out
of
the
git
repo.
It
also
allows
us
to
you
know,
avoid
sensitive
credit
and
credentials
being
exposed
through
the
Skippy
UI,
so
we
have
a
secret
flag
which
marks
it
as
a
secret
and,
as
you
can
see
in
this
like
output
here,
that
it
actually
obfuscates
it
from
the
user
interface.
So.
F
Monitoring
is
the
next
big
pillar
of
the
product,
so
we
do
have
some
of
this
exposed
in
the
command
line
with
the
logs,
but
some
of
the
cooler
stuff
is
in
the
AWS
interface
in
the
console
there.
So
we
every
we
like
collect
everything
into
cloud
watch,
so
that's
metrics,
it's
logs
and-
and
it
really
is
a
very
powerful
tool,
so
exposing
these
through
dashboards.
F
You
know
we
can
give
developers
some
pretty
compelling
information
just
right
at
their
fingertips.
So
you
know
latest
errors.
You
know
just
a
stream
of
log
messages
coming
through.
We
can
even
do
pretty
gnarly
stuff
with
the
cloud
watch.
Insights,
query
language,
so
this
is
an
example
of
taking
the
cloud
front
logs,
so
we
ingest
those
in
and
pausing
out
each
of
the
component
parts
of
the
log
message
and
then
finding
you
know
say,
for
example,
the
top
five
slowest
and
pages
on
the
site.
So
that's
super
neat.
F
Another
thing
we
can
do
we
see
on
the
right-hand
side
is
you
know
seeing
who
the
most
active
clients
are?
So
you
know
that
one
has
been
invaluable
for
projects
where
we've
had
you
know
a
scraper
or
something
trying
to
have
a
starter
off
the
site,
and
we
can
just
easily
identify
the
offender
and
put
them
into
the
wife
block
list.
F
Yeah,
so
that's
that's
it
I
was
there
anything
else.
I
want
to
show
all
there
was
so
yeah
there's
one
other
feature.
I
thought
was
a
pretty
neat
thing
to
show
off,
which
is
our
the
way
that
we've
implemented
giving
developers
SSH
access
to
environments
so
rather
than
having
them.
You
know,
rather
so
common
options
are
opening
up
like
a
SSH
port
and
allowing
people
to
just
get
straight
into
a
running
pod.
Another
one
might
be
having
like
exact
capability
so
giving
you
know
like
with
Kubb
cuddle.
You
can
do
an
exec
into
the
pod.
F
What
we've
done
is
a
nice
system
where
we
actually
on
a
shell
session
initialization.
We
actually
create
a
new
pod
and
set
the
user
up
in
that
this
pod
isn't
like
connected
up
to
the
ingress,
so
there's
no
request
coming
in,
so
they
are
free
to
do
whatever
they
like
in
there.
You
know
they
can
really
do
some
heavy
CPU
intensive
work
without
impacting
on
the
production
site,
so
show
how
that
looks.
F
So
for
a
day
skipper,
shell,
prod
and
yeah.
We've
got
read-only
file
systems
enabled
so
you
know
they
try
and
you
know
override
index
dot.
Php
they're
gonna
have
a
hard
time
and
on
the
cluster
that
looks
like
yes,
so
I've
just
got
a
watch
here
for
any
pods,
with
the
name
exec,
and
so
when
skipper,
shell
is
run,
we'll
see
a
new
pod
open
up
here,
any
second.
There
we
go,
and
you
know
the
person
has
the
shell.
F
Yes,
so
that's
a
that's
a
pretty
neat
little
security
feature.
Another
neat
feature
that
we're
quite
proud
of
is
our
automated
database
images
that
are
packaged
nightly
for
developers.
So
we
from
the
backups
that
are
taken
each
night,
the
docker
image
is
built
which
developers
can
pull
to
the
local
environment,
and
so
this
will
have
you
know,
tables
truncated,
certain
values,
sanitized,
and
this
just
means
that
you
don't
have
to
worry
about
doing.
F
A
I
think
it's
a
pretty
efficient
approach,
allowing
people
to
build
the
containers
out
locally
and
I'm
sure
that
helps
with
a
lot
of
your
overhead
and
processing
times
when
it
comes
to
and
discrepancy
between,
essentially
local
and
live
so
did
they
have
the
ability
to
go
through
build
out
their
own
containers
and
push
those
up.
It's
a
pretty
nice
approach,
yeah.
F
Yeah
yeah,
like
so
far,
we've
been
very
pleased
with
just
like
everything
you
know
the
performance
of
the
platform
and
the
developer's
experience
on
it.
Our
operational
experience.
You
know:
we've
had
very
few
teething
issues
since
we've,
you
know,
watch
this
version
of
it
and
yeah.
So
so
far,
so
good.
A
F
Yes,
so
so
just
to
be
getting
the
weeds
a
little
bit,
so
we've
got
we're
running
eks
as
our
managed
creep
cluster
and
so
eks.
All
the
authentication
is
based
on
and
you
know,
Amazon's
iron
policies
and
then
roles
there.
So
what
that
allows
us
to
do,
is
you
know
so
really
the
authentication
from
our
perspective
is
giving
a
set
of
iron
credentials
to
an
end
user
and
that
limits
them
to
specific
namespaces
and
within
those
namespaces
specific,
our
back
permissions.
F
So
if
you
can
get
quite
fine-grained
with
that
in
terms
of
you
know
what
you
can
less
than
what
you
can
get
and
what
you
can
exact
into,
and
things
like
that-
and
it's
been
so
like
we've
taken
a
you
know,
policy
of,
like
least
privilege,
which
is
you
know
like
a
little
bit
of
a
painful
way
to
get
started.
You
know
in
terms
of
always
hitting
you
know,
access,
denied'
issues
when
you're
doing
the
initial
development,
but
it
does
mean
that
you're
really
only
giving
your
role
your
roles
exactly
the
permissions
that
they
need.
D
And
I
think
the
other
side.
Sorry
actually
I'm
the
other
side
to
the
security
on
it
for
doing
a
cube,
CTL
exact
versus
this
SSH
spin
up
approach
is
that
developers,
especially
on
the
CLI,
require
a
set
of
tools
like
a
whole
slew
of
tools,
whereas
your
fpm
container
just
needs
code
and
PHP
fpm
to
run,
and
it
needs
a
much
lower
set
of
packages
and
things
installed
on
there.
D
So
so
the
idea
is
we
have
that,
like
fpm
and
the
CLI
container
and
the
skipper
SSH
mechanism
then
allows
you
to
spin
up
that
CLI
container
versus
shelling
into
an
existing
web
head.
That
has
a
whole
bunch
of
software
installed
on
there.
That's
not
not
actually
required
and
also
contention
for
resources,
so
like
I'm,
not
sure
if
anybody
has
any
stories
of
in
the
past,
but
I
definitely
do
we're.
D
Jumping
on
like
a
web
head
instance
and
running
drush
or
running
some
big
command
and
that's
sharing
resources
with
your
web
instances
who
are
serving
your
clients,
there's
quite
a
bit
of
overlap
there
as
well,
so
yeah,
so
that's
kind
of
the
other
side
of
the
security
as
well.
You
know
just
split
up
those
packages
as
well
as
yeah
and.
F
Then
and
yeah,
and
also
like
you
know
not
necessarily
related
to
that
issue
but
running
the
nginx
PHP
fpm
architecture
means
that
you
know,
for
example,
you
don't
have
to
mount
the
private
file
system
into
your
nginx
container.
So
that's
just
you
know
one
less
thing
that
can
pretend
be
exposed
if
someone
does
get
access
to
the
cholesterol
to
that
particular
component.
A
And
as
far
as
next
steps
or
yeah
I
mean
you,
you
basically
have
a
public
forum
here.
So
what
would
you
like
to
see
from
the
community
to
help
support
you
or
maybe
try
out
Witcher?
You
have
anything
that
we
can
look
at
or
what
are
you
thinking
of
doing
next
with
the
product
or
where
can
we
see
which
shows
yeah.
F
F
And
personally,
I
am
a
little
pessimistic
on
whether
it's
possible,
just
the
the
sheer
amount
of
ways
that
you
can.
You
can
skin
the
rabbit
mean
that
there's
just
a
huge
amount
of
configuration
options
and
things
that
will
you
know
inevitably
need
to
make
their
way
into
a
CID
definition.
So,
yeah,
you
know,
I
would
encourage
people
if
you
you
know
wanting
to
discuss.
You
know
you're,
building
your
own
platform
or
you
know
wanting
to
discuss
any
certain
aspects
of
our
tool.
You
know
we're
very
happy
to
talk
about.
F
A
A
One
of
the
things
that
we've
just
stumbled
across
recently
and
that
generic
CRD
conversation
is
that
it
might
actually
make
more
sense
to
have
a
generic
set
of
go
based.
Libraries
that
specific
CR
DS
can
implement.
So
essentially,
a
lot
of
the
functionality
tends
to
be
relatively
similar,
but
there
are
instances
where
you
need
to
do
additional
configuration
and
we've
landed
on
a
pattern
we're
using
those
libraries.
A
Genera
size
it
a
little
bit
more
than
just
Drupal,
specific
or
or
wordpress
specific
or
whatever,
and
that's
coming
up
soon.
So
yeah.
Let's
turn
it
over
to
the
group
day.
Basically
anything
that
you'd
like
to
share
with
us
any
challenges
that
you've
had
recently
any
celebrations
that
you'd
like
to
announce
or
anything
interesting
in
the
cube
space
that
you're
keeping
your
eye
on.
B
I'm
happy
to
I
just
just
do
a
quick
update
on
the
lagoon
side
of
things.
Yeah
we've
been
just
the
last
few
weeks,
been
really
pushing
to
to
get
a
native
community
support
before
Lagoon
we're
very,
very
close
and
we've
actually
on
board
of
customer
last
week.
So
it's
a
been
a
lot
of
work
over
the
last
few
months
to
make
it
happen,
most
likely
going
to
be
coming
out
in
the
1.4
release,
where
we've
actually
just
got
almost
a
like-for-like
functionality
with
the
summer
OpenShift
system.
B
So
that
will
sort
of
give
us
some
feature
parity.
But
we
are
pushing
forward
to
look
at
silver
lagoon
to
dodo,
which
will
be
more
of
a
native
support
for
for
a
whole
lot
of
sort
of
managed
services
and
the
idea
really
being
that
we
yeah
we
have
most
of
those
functionality
all
those
managed
services
built
into
the
platform.
But
we
can
sort
of
plug
in
and
leverage
any
managed
services
of
the
provider
where
we're
going
towards.
B
A
F
B
Yes,
I
mean
in
this
stage
on
the
on
the
one
series.
Essentially
you
you
like
for,
like
your
project.
Compatibility
with
native
Cuban
ship
will
be
identical,
so
they
won't
mean
anything
changing
from
a
project
point
of
view,
but
your
so
we're
working
on
that
migration.
There
might
be
likely
API
changes.
B
D
B
A
F
A
A
If
anybody
is
interested
in
presenting
oh
yeah
I
believe
Florian
might
move
into
that
slot,
but
it's
still
open.
If
anybody
wants
to
claim
it
we're
considering
moving
this
to
a
monthly
meeting
instead
of
every
two
weeks,
so
that
we
can
basically
get
a
little
bit
more
content
happy
because
it
seems
that
we're
a
little
thin,
as
things
are
still
start
to
take
off,
but
yeah
outside
of
that
I
I.
Think
we've
reached
the
conclusion
of
this
meeting.
So,
thank
you
all
very
much.
Thank
you
very
much.