►
From YouTube: CloudNative Development & Deployment w Kubernetes & GitOps Jaime Magiera UMich OpenShiftCommons 2022
Description
OpenShift Commons Gathering 2022
Speaker: Jaime Magiera (ICPSR at University of Michigan Institute for Social Research)
Full Agenda:
https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_on_GitOps.html
Learn more at OpenShift Commons https://commons.openshift.org
A
It
could,
because
we
managed
to
get
him
to
talk
here
about
get
ops,
but
I
also
get
him
to
co-chair
the
okd
working
group
with
me,
which
is
the
open
source
side
of
openshift,
and
he
is
just
a
wonderful
speaker
and
today
he's
going
to
tell
us
a
little
bit
about
get
ops
at
the
university
of
michigan.
So
if
we
can,
let
you.
B
B
B
All
right,
excellent,
so
cloud
native
development
and
deployment
with
kubernetes
and
git
ops.
What
we're
calling
icpsr
ops-
and
I
am
jamie
mcgarrett,
and
so
the
agenda
for
this
quick
talk-
is
an
introduction
and
some
foundations
and
where
we
are
at
icpsr
and
then
some
suggestions
for
devops
engineers
and
developers
and
then,
as
diane
mentioned
question
and
answers
will
be
moved
to
the
section
at
the
end.
B
So
an
introduction
about
icpsr,
the
inter
university
consortium
for
political
and
social
research
provides
leadership
and
training
in
data
access,
curation
and
methods
of
analysis
for
social
science,
research,
community,
the
social
science,
research
community.
We
provide
research
data
to
organizations
across
the
globe
via
a
variety
of
web
services
and
portals
recently
we
began
to
transition
our
application,
development
and
deployment
to
the
cloud
native
paradigm
in
particular
kubernetes
and
get
ops.
B
We've
learned
a
lot
during
this
process
and
would
like
to
share
that
knowledge
and
experience
with
others
to
shed
some
light
on
the
challenges
and
advantages
of
moving
to
kubernetes.
In
the
cloud
and
about
me,
I've
worked
in
education,
research
technology
for
25
years,
with
a
focus
on
higher
education.
B
B
B
B
So
the
solutions
in
a
general
sense.
We
separated
out
our
application
code
from
the
deployment
code.
We
create
code
to
define
external
dependency,
configuration
and
I'll,
be
talking
more
about
that.
We
store
the
microservice
code
and
cluster
configuration
in
the:
u
of
m's
git
lab
repository
and
we
created
helm,
charts
for
the
services
and
for
the
infrastructure
configuration
and
we
automated
the
process
of
loading
computer
code
and
cluster
configuration
continuously
with
argo
cd.
B
So
a
little
bit
about
what
we
have
for
infrastructure,
we
have
kubernetes
clusters
and
development
is
okd,
which
is
the
upstream
of
the
commercial
openshift
product.
We
use
that
for
development
and
the
quality
assurance
stages
and
for
production
we
use
ocp
for
our
user
acceptance,
testing
and
production
stages
and
in
terms
of
deployment
resources.
What
we've
done
is
we've
separated.
We've
created
separate
repositories
for
each
microservice
deployment.
B
Each
repository
for
the
deployment
has
a
helm
chart
for
the
respective
image
and
environmental
variables
and
whatnot
and
the
helm
charts
are
packaged
and
published
to
registering.
This
is
a
step
that
not
everyone
does,
but
we
like
the
ability
to
move
things
around
and
not
be
reliant
directly
on
the
repository.
So
we
actually
do
the
help
chart
packages
and
pull
the
packages
down.
B
B
I
always
use
that
for
testing,
I
love
tacos
and
then
we
have
applications,
and
these
are
all
helm,
charts
repositories
with
helm,
charts
and
the
associated
resources
and
you'll
notice
that
one
of
them
is
the
app
deployment
and
then
the
there's
other
ones
that
are
the
api,
the
ui
etc.
So
these
are
all
in
individual
helm,
charts,
but
then
the
application
one
assembles
them
and
here's
an
example
of
the
application
helm
chart.
B
B
There
are
no
templates
or
very
few
templates
in
this
top
level.
Helm,
chart
they're
basically
used
as
a
reference
to
all
of
the
micro
services,
and
this
is
the
library
that
I
wrote,
which
basically
has
yaml
files
that
allow
us
to
very
quickly
assemble
some
common
manifests
in
our
helm,
charts,
elastic
search,
credentials,
database,
credentials,
data
site,
oauth
credentials
for
node
applications
and
then
oauth
for
java
applications.
B
And
the
cluster
configuration
helm
charts
contain
much
of
our
day
two
configuration
or,
as
I
call
it
hour
two
because
you
spin
up
the
cluster
and
you
have
these
helm
charts
and
you
have
your
argo
cd
and
you
just
get
things
running
very
quickly.
Manifests
within
these
helm.
Charts
are
active
directory,
binding,
backup
configuration
project
templates
links
that
go
in
the
in
the
console.
B
Icpsr
has
a
lot
of
security
requirements
that
require
a
lot
of
redundancy
and
a
lot
of
sort
of
siloed
configurations
between
different
stages
and
between
projects.
So
we
often
do
a
lot
of
copy
of
containers
to
different
projects
and
registries,
as
opposed
to
just
allowing
cross
communication
and,
of
course,
argo
cd
to
continuously
monitor
the
helm,
charts
and
other
resources
and
reconcile
them
as
needed.
Here's
an
example
of
a
helm
chart
for
managing
pipeline
resources,
and
it
groups
pipeline
resources
based
on
function
and
allows
for
clear
version.
B
Management
and
argo
cd
can
reconcile
against
the
chart
for
full
get
ups.
This
is
an
example
of
a
tecton
pipeline
with
a
a
web
hook,
so
you
have
the
binding
and
the
listener,
which
is
basically
what
listens
for
the
incoming
connections
and
then
maps
that
and
then
directs
that
to
a
route
which
then
directs
that
to
a
pipeline,
and
so
we
actually
have
this
in
a
help
chart
and
then
a
values
file
allows
us
to
tweak
on
have
particular
values
when
this
chart
gets
deployed,
and
then
configuring
and
managing
external
resources.
B
We
have
repositories
that
contain
external
configuration
components
which
are
applied
via
the
pipeline
for
terraform
for
aws
email
templates
for
amazon's,
ses
service
schema
for
databases
schema
for
apache,
solar
and
a
lot
more,
and
so
we're
getting
to
the
point
where
the
promotion
of
a
get
commit.
Hash
means
not
just
the
code,
but
the
developers
are
working
on
the
devops
engineers
are
working
to
make
it.
So
it's
all
of
the
resources
that
git
commit
hash
represents.
B
B
So
we
have
a
what's
called
a
comment
gate
and
so
I'm
starting
to
build
sort
of
a
bot,
basically
infrastructure,
where
using
sort
of
a
chat,
ops
model
commands
can
be
issued
from
the
git
repository
to
trigger
the
pipelines,
and
so
we
have
a
comment
gate.
I
wrote
this
to
filter
comments
and
you
can
set
what
comment
you
want
to
look
for
and
who
it
should
come
from
and
that
allows
the
rest
of
the
pipeline
to
run,
and
so
we've
got
a
git
clone.
B
We've
got
a
a
to
generate
a
new
helm
chart
and
then
pack
package
and
then
publish
that
package
up
to
the
registry
and
so
here's
our
process.
Basically,
we've
got
developers
and
devops
working
together
with
helm,
charts,
get
lab
open
shift,
ocp,
argo
cd,
all
of
this
running
on
top
of
aws,
and
you
can
sort
of
see
a
little
bit
of
the
flow
there.
Obviously
there's
a
lot
more
nuance
going
on,
but
that's
the
basic
process
and
the
results
of
git
ops
of
implementing
git
apps.
B
B
B
If
you're
interested
in
getting
into
this
separate
out
your
deployment
from
your
service
code
strongly
recommended
it,
it
makes
things
a
lot
easier
in
terms
of
management
and
allows
you
to,
if
necessary,
sort
of
control,
access
to
these
things
and
and
separate
out
the
need
of
developers
necessarily
to
have
to
worry
about
learning,
helm
pipelines,
etc.
If
they
don't
want
to
and
or
worry
about,
making
changes
to
that
create
top
level
application
repos
in
git.
B
I
found
this
is
very
helpful,
create
a
an
application,
create
a
group,
a
git
group
within
that
an
application
level
repo,
and
then
your
micro
service,
repos
and
then
references
to
other
resources
if
necessary,
create
top-level
application.
Helm
charts,
as
I
showed
you,
those
sort
of
empty
helm,
charts
that
just
reference.
The
re
respective
microservices
clarify
delineation
of
software
for
an
application
and
software
to
multiple
applications.
So
start
thinking
about.
B
It's
counter-intuitive
to
some
traditional
developers
and
software
engineers
and
sysadmins
to
think
in
terms
of
git
hashes.
But
it's
it's
it's
helpful
because
once
you
start
going
into
this
model
of
git
having
everything
that
hash
is
the
point
in
time,
that's
all
of
the
resources
where
you
want
them
to
be
for
deployment
and
avoid
using
floating
tags.
B
B
Thank
you
very
much,
and,
of
course,
none
of
this
could
be
done
without
the
hard
work
of
developers
and
devops
engineers
in
icpsr
and
the
support
of
the
get
ops
community,
christian
and
a
lot
of
other
folks
that
are
doing
the
great
work
to
flesh
out
these
ideas,
and
so
that's
my
presentation.
Thank
you
very
much.