►
Description
Ortelius solves a complex problem - the tracking and organization of microservices across cluster. In this video, Steve Taylor shows us just how Ortelius does its job.
A
Looks
like
we
got
a
lot
of
people
doing
some
work
in
the
background
or
other
people
in
the
room,
doing
work
for
as
well.
So
today
we're
going
to
go
over
how
artelias
and
the
cicd
process
fit
together,
and
I'm
gonna
take
a
look
at
what
we
have
as
far
as
the
ci
process,
as
well
as
some
of
the
pieces
where
we
kind
of
insert
in,
and
this
is
to
tie
into
some
of
the
blog,
the
blog
that
sasha
put
together.
A
So
one
of
the
things
of
the
way
the
triggers
that
we
set
up
in
the
google
cloud
build
was
to
look
at
any
any
branch
that
came
in
and
we're
gonna
go
ahead
and
build
and
record
it.
Some
of
them
will
only
do
it
on
a
pull
request,
we'll
only
be
looking
at
the
the
main
part.
So
one
of
the
things
that
if
we
pick
one
of
these,
this
is
one
of
the
last
ones
deployed
is
this
is
the
container
that
is
going
to
be
for
the
documentation.
A
So
what
we
can
see
is
we
did
a
hook
into
our
cloud
build
and
we
recorded
you
know
information
about
the
build.
We
have
the
chart,
that's
used
to
install
it,
and
then
we
have
information
about
what
was
produced
in
the
build
process.
So
we
have
the
registry,
the
digest,
the
tags
and
the
the
get
info.
Now.
A
Why
the
why
this
is
important
is
if
you
look
at
the
cicd
process
overall
anytime,
that
there's
a
build
that
happens,
we
want
to
treat
that
as
a
potential
version
that
can
go
out
to
production,
so
there
may
be.
If
we
go
back
to
our
list
here,
we
may
have
a
lot
of
versions
of
components
that
may
never
make
it
out
to
production.
You
can
see
in
this
list
here
a
bunch
of
them
were
never
deployed
the
last
one
that
was
was
this
this
one
build
985
or
deployment
985..
A
So
that's
one
of
the
things
that
in
us
in
the
cicd
process,
we
want
to
capture
that
information
about
what's
being
created
where
it
was
stored,
and
how
can
we
get
to
it
because
everything
we're
dealing
with
here
is
is
basically
docker
containers.
It
makes
it
pretty
easy.
You
know
we're
going
to
be
pushing
to
a
registry
we're
going
to
know
where
that
registry
was
pushed
to.
We
want
to
grab
some
information
about
that.
A
So
and
sasha's
blog
does
a
really
good
job,
explaining
the
different
steps
into
the
the
cloud
bill.
So
I'm
not
gonna
go
into
super
detail
about
what's
happening
at
that
level,
but
some
of
the
I'll
point
out
some
of
the
key
points
that
we
have
things
that
we
need
to
know
are
going
to
be
like.
What's
going
to
be
the
application
that
we're
going
to
associate
this
version
of
the
component
too,
you
know
what
is
the
name
of
the
component
like
the
base
name.
A
A
A
So
I
could
have
you
know
a
a
new
microservice
that
we're
going
to
be-
or
let's
say,
a
new
sign
on
that
we're
gonna
have
to
deal
with
privacy
issues,
so
we
may
have
a
new
terms
of
agreement,
and
that
may
be
the
feature.
Branch
should
be
in
terms
of
agreement
that
we
want
to
track
as
a
variant
versus
what's
out
there
as
part
of
the
existing
pieces.
So
variant
is
optional
and
then
we
have
our
versions.
These
are
schematic
versions.
A
In
this
case
I've
just
defined
basically
hard
coded
the
the
beginning
part.
The
ending
part
you
will
see
here
is
I'm
doing
a
little
trick
with
the
git
repo,
where
I'm
actually
going
in
and
counting
the
number
of
commits
on
the
branch,
and
that
allows
me
then
have
a
like
a
build
number
for
lack
of
a
better
word
because
in
google,
if
we
remember
back
on
the
google
quiz,
I
mean
on
the
google
side
on
the
cloud
build
our
build.
A
Is
this
weird
hexadecimal
number
it's
great
for
having
uniqueness
and
stuff
like
that?
But
it's
not
practical
for
the
the
the
versioning
schema.
So
that's
where
I
do
this
little
trick
to
go
ahead
and
get
the
commit
count,
and
then
I
like
to
tack
on
with
it
prefixing
it
with
like
a
dash
g
to
to
identify
that
it's
a
git
commit
the
short
sha
and
that's
where,
at
the
end
of
the
day,
we
end
up
with
our
name.
A
A
It's
a
scripting
language
that
we
ended
up,
writing
phil,
gibbs,
ended
up
writing
and
because
it's
its
own
language,
things
like
the
dash
here
when
you
get
into
the
scripting
language,
gets
interpreted
as
a
minus
sign.
So
it
tries
to
subtract
the
the
two
words
which
which
throws
an
error,
so
we
actually
have
to
go
through
and
and
kind
of
scrub
the
names
and
put
them
into
underscores.
A
The
other
thing
that
you'll
see
is
there's
no
periods
as
well,
because
periods
actually
end
up
as
part
of
the
domain
name
structure,
so
global.ortulus.sas,
so
user
ids
like
if
you
do
like
first
dot
last
name,
we
actually
convert
that
to
first
underscore
last
name.
So
there's
a
couple
weird
quirks
that
we've
had
to
deal
with
that
we've
been
carrying
along
when
we
eventually
get
to
the
point
where
we
can
rewrite
the
deployment
engine,
we
can
fix
those
restrictions
down
the
road.
A
Yeah,
it's
a
weird
one
that
just
got
carried
along,
and
it's
just
you
know
unpinning.
It
is
a
bigger
project
than
we
were
that
I
was
hoping
for
it
to
be
some
of
the
other
things
that
we
are
kind
of
grabbing
or
setting
up.
This
point:
where
is
this
going
to
get
pushed
to?
This
is
just
the
action
that
we're
going
to
run
to
do
the
deployment.
A
A
B
A
So
when
we
update
the
attributes,
so
everything
with
a
comp
adder
is
we're
updating,
attributes
all
the
way
through
into
the
ui
and
storing
them
to
the
database.
Certain
keywords
we
pick
out
and
we
put
on
certain
places
on
the
the
detail
dialogue.
So
things
like
that.
We
have
coming
down
the
road
for
the
service
catalog
like
slack
channel
pagerduty
url
logs
those
types
of
attributes
will
map
across
as
part
of
that
process.
A
So
this
dhcomp
update
is
actually
a
python
script
and
it
is
separated
into
two
pieces
there's
the
main
driver.
If
I
can
get
up
to
the
top
here
close
this
here
for
you,
so
the
main
driver
is
the
the
dhx,
basically
the
executable
part
of
it
and
then
there's
the
api
piece.
The
api
piece
has
all
the
basically
the
restful
api
calls
that
we
need
to
do
so
if
we
want
to
clone
that's
a
bad
example
like
here
assign
a
a
component
to
an
application.
A
A
Another
one
that
comes
into
play
is
key
value
pairs.
This
is
where
we
could
actually
pull
in
like
a
properties,
file
and
load,
those
in
as
attributes
to
the
component
version
as
well.
So
if
you
have
key
value
pairs
that
we
want
to
like
config
maps,
those
can
come
in
and
be
associated
to
the
component
version.
Now,
that's
a
separate
step
so
on
our
cloud
build.
If
we
wanted
to
do
that,
we'd
actually
have
to
run
the
comp
update
twice
the
dh
twice
once
with
comp
up
with
update
comp
and
the
other
one.
A
A
A
Both
this
whole
python
piece
gets
pushed
over
to
pi
pi,
so
you
can
download
it
just
doing
a
pip
install
of
that,
and
you
can
then
incorporate
it
into
your
cicd
process.
Now.
One
of
the
things
that
we're
doing
at
this
one
in
our
cloud
build
is
we're
actually
doing
a
deployment
as
well,
so
we're
kind
of
like
wrappering,
both
things
at
once
so
after
everything's
been
updated,
we're
actually
going
to
deploy
to
that
deployment
environment
that
we
defined,
which
is
going
to
be
our
aks
cluster.
A
So
after
everything
gets,
it
gets
updated
we're
going
to
go
ahead
and
deploy
right.
After
that,
you
could
do
the
two
steps.
You
could
do
the
update
comp
and
then
come
back
and
do
the
deploy
we
just
kind
of
did
it
as
convenience.
The
wrapper
at
all
is
one
as
part
of
that
steps,
so
that's
kind
of
what's
happening
at
the
ci
level.
A
A
A
A
A
So
that's
kind
of
what's
happening
on
the
deployment
side.
Now,
in
a
tradition
in
a
traditional
ci
process,
we
would
want
to
do
like
on
the
ci
level.
We
probably
want
to
do
a
a
check-in,
build
it
and
deploy
it
to
the
dev
environment,
so
that's
kind
of
like
what
we
have
going
on
with
our
deployment
environment
as
if
in
the
regular
pipeline
you
think
about
we
got
to
go
to
qa.
A
We
would
then
at
the
application
level.
I
don't
have
it
set
up
because
we
don't
have
we're
doing.
Qa
is
slightly
different,
but
I
would
go
ahead
and
pick
which
environment
I'd
want
to
go
to.
So
I
would
have
to
have
a
qa
environment
or
pod
environment
listed
here
that
I
want
to.
I
would
go
ahead
and
deploy
that
version
of
the
application
to
that
environment
and
because
we
have
everything
basically
tied
at
the
component
level,
all
the
metadata
that
we
need
to
retrieve
the
the
image
out
of
the
docker
registry.
A
We
can
go,
do
this
and
repeat,
it's
basically
rinse
and
repeat
at
any
stage
of
the
pipeline,
whether
we
have
something
going
on
at
dev
or
at
prod
we're
going
to
do
the
same
process.
We're
going
to
pass
in
different
data,
we're
going
to
pass
in
key
value
pairs
around
the
the
production
environment
versus
key
value
pairs
for
the
development
environment,
but
we'll
be
able
to
move
that
in
repeat
and
pass
in
the
data
down
the
the
pipeline.
A
A
A
So
it's
the
same
concept
underneath
the
covers
the
the
groovy
library
is
doing
the
same.
Basically,
the
same
restful
api
calls,
but
we
do
have
a
little
more
flexibility.
From
this
point
I
actually
have.
One
of
our
customers
is
doing
a
deployment
they
go
and
check
to
see.
If
the
deployment
is
successful,
if
it's
not,
then
they
actually
automatically
do
a
rollback
of
the
deployment,
so
they
deploy
out
to
an
environment.
They
run
their
test
cases
through
their
jenkins
pipeline.
A
A
A
So
one
of
the
things
that
we've
been
kind
of
moving
to
this
is
a
dealing
with
salesforce,
and
here
we
can
see
that
we're.
Basically
I'm
just
I
just
stubbed
it
out,
but
basically
we're
calling
update
the
the
python
library
from
just
the
command
line,
call
in
the
jenkins
script
in
the
jenkins
file.
So
that's
the
other
way
that
I'm
looking
at,
but
when
you
get
into
this,
there's
not
as
much
flexibility
to
make
those
decisions
like
the
automatic
roll
back
and
pieces
like
that.
A
A
You
know,
gather
information
from
the
ci
process,
store
it
at
the
component
level,
make
our
associations
that
are
going
to
be
pulled
together
as
part
of
an
application
version
and
then
go
ahead
and
be
able
to
deploy
it
right
then,
or
be
able
to
deploy
it
down
the
road.
Now
one
of
the
other
modes
that
the
the
python
library
kind
of
works
in
is
to
be
able
to
record
a
deployment,
and
this
is
where
most
people
start
with
is
they'll.
A
Have
some
sort
of
process
like
to
have
helm
running
or
like
in
the
salesforce
case?
They
have
jenkins
calling
salesforce
through
the
sales
source
plugin,
but
we
want
to
record
what
those
deployments
are
doing
so
there's
another
mode
where
we
can
pass
in
a
list
of
components
that
were
deployed
to
an
environment
and
we
can.
B
A
A
We
have
the
basically
know
the
image,
because
we
have
we
can
concatenate
together
the
registry
and
the
tag
we
can
actually
go
backwards
and
figure
out
what
is
the
actual
component
version
that
is
running
in
the
cluster,
so
that
is
one
way
that
we
are
going
to
be
able
to
pull
together.
What
is
an
application
version
running
in
a
in
a
cluster?
A
One
of
the
things
that
we
we
ran
into
is
handling
multiple
container
tags
that
point
to
the
same
digest.
So
this
customers
is
renaming
or
re-tagging
as
they
go
from
from
stage
to
stage
those
they'll
say.
Qa
latest
would
be
like
one
of
the
tags
that
they
put
on
this
digest
and
then
they'll
do
prod
latest
that
way
when
they
get
to
their
their
production
deployment.
They're
always
pulling
prod
latest
tag
as
part
of
that
process.
A
A
C
D
A
No
because
it
would
be
like,
let's
say,
jenkins
was
doing
the
build
and
it
felt
it
failed.
The
compile
the
next
step
would
be
to
go
ahead
and
tell
ortillius
that
it
was
successful
that
a
new
component
was
created
in
the
docker
registry
and
because
it
never
got
to
the
docker
registry
we'd,
never
record
it.
B
B
A
Yeah,
that's
one
of
the
things.
That
is
that
we
need
to
do
as
a
a
way
to
make
the
ui
load
faster
is
when
you
get
a
lot
of
these
component
versions
and
application
versions
that
never
made
it
out
of
the
the
initial
ci
build
that
they
do
get
in
the
way.
So
an
archiving
feature
is
something
that
we
need
to
look
at
and
if
you
could
open
a
an
issue
for
that,
that
would
be
great
because.
C
B
D
A
Right
so
the
initial,
so
one
of
the
things
in
components
is
and
in
applications
we
like
to
start
with,
what's
called
a
base
version,
the
base
version,
we
basically
kind
of
strip
off
all
the
the
variant
in
the
like
the
the
version
number
and
that
becomes
our
base
version
that
we
start
with
from
there
on
out.
We
then
create
version,
one
of
the
component
or
so
components
and
applications
and
pretty
much
everything
works.
A
The
same
way
for
versioning
in
artelias,
so
we'll
go
ahead
and
create
the
new
the
new
version.
So
we
have
our
base
version
version,
one
so
base
version
you
can
think
of
as
base
zero
version,
zero
and
then
version
one
is
gonna,
be
our
our
component
that
we
just
created
and
then,
if
we
have
another
update,
that
comes
along
we'll
go
ahead
and
look
for
the
parent
of
there's
a
whole
parent,
a
parenting
tree.
A
A
A
A
D
A
A
I'm
sorry,
you
you
it's
when
you
create
a
new
microservice.
So
if
you
create
a
new
microservice
and
you
have
five
applications
that
are
consuming
it,
you
would
then
go
ahead
and
find
where
the
previous
version
of
that
component
was
used
in
which
applications.
So
we
know
there's
these
five
different
applications
that
we're
consuming
the
the
minus
one
of
our
component
version
and
then
we'll
go
ahead
and
create
new
component
versions
for
all
five
applications
consuming
the
new
component
that
we
just
created.
A
So
there
are
some
tricks
that
we
do
behind
the
scenes.
But
in
order
to
do
that,
we
need
to
have
a
starting
point
and
that's
the
hard
part
is
getting
the
starting
point
and
that's
why
I've
been
looking
at
basically
reverse
engineering,
a
cluster
to
give
us
based
on
a
name
space,
to
give
us
a
starting.
A
Artelias
and
deploy
up
don't
do
anything
on
transaction
monitoring
or
health
status,
or
anything
like
that.
So
in
our
proposal
for
the
service
catalog,
one
of
the
things
that
that
we're
going
to
add
is
links
to
monitoring
tools.
So
if
you
wanted
to,
for
example,
for
this
microservice,
we
know
that
the
datadog
url
for
this
service
is
x
and
that's
some
of
the
service
catalog
data
that
we
want
to
embed
at
the
component
level.
A
Where
are
the
logs
for
production
but
developers
when
they're
doing
work?
You
know
qa
says
something's
broken.
The
first
thing
they
want
to
do
is
go
look
at
the
logs
and
if
they
know
where
the
qa
logs
are
for
this
cluster
for
this
micro
service
and
they
could
just
get
to
it,
really
quick
they're
going
to
be
much
happier
and
that's
where
you
know
it's
like
this
end
and
and
relationship
that
we
have
to
deal
with
when
we're
talking
about
this
version
of
this
component
lives.
A
D
Sorry
also,
regarding
that,
so,
like
my
blog
was
regarding
that
part
like
microsoft,
generation
or
basically
observability,
so
I
came
across
that,
so
basically,
three
systems
are
there
like.
So
basically,
the
three
kind
of
data
are
log,
metrics
and
traces.
So
basically
the
transactions
and
most
of
the
systems
have
different
screens
and
there
is,
there
doesn't
exist,
any
correlation,
so
the
manual
labor
goes
so
much
to
like
suppose.
D
If
some
problem
strikes
us
down,
we
have
to
like
manually,
do
all
those
things
and
correlate
on
our
own
so
like
this
is
the
moving
trend
that
towards
a
generic
solution
where
we
can
get
all
these
three
data
together
and
correlation
between
them.
Yeah
the
service
goes
down.
We
get
the
logs,
we
can
get
the
logs
traces
as
another
metrics
of
the
system.
We
want.
C
D
Also,
and
also
like,
if
you
were
mentioning
the
links
for
different
tools
like
there's,
a
standard
being
developed
currently
like
open,
telemetry
right,
so
the
so,
basically
the
so
basically
the
currently
all
this
we
need.
Basically,
standardization
is
needed.
We
are
having
lots
of
tools
that
do
they
are
doing
this
thing,
but
there
is
no
standardization
in
the
format
of
the
data,
so
basically
to
open
telling
me
project
is
around
that,
and
if
we
can
utilize
that
data
we
can
maybe
in
the
future
we
can
show
that
directly.
A
A
What's
the
email
address
and
phone
number
of
the
owner
for
this
microservice?
What's
the
page
or
duty
service
sheet?
Look
like
you
know,
those
types
of
of
things
are
important
as
well
and
then,
like
you,
said
overall,
if
we
could
start
bringing
in
some
base,
you
know
a
green
red
for
a
service
at
for
at
an
environment
level.
That
would
be
a
huge
now,
there's
a
whole
other
thing
around
policies
as
well.
How
is
how
is
this
service
conforming
to
the
policies?
A
A
A
Now
one
of
the
things
that,
as
part
of
the
service
catalog
that
we're
looking
at
I'm
doing
is
it's
kind
of
along
the
the
policy
ish
side
is
when
we
have
a
a
docker
container.
Let's
say
it's:
a
python
container
python
is
going
to
have
all
of
its
modules
that
were
installed
into
the
container.
Now
we
can
run
a
scan,
a
security
scan
against
that
container
and
we
can
grab
all
the
there's
two
things
we
need
to
grab.
A
One
is
what
are
all
the
licenses
for
all
the
module,
because
we
need
to
know
if
we're.
If
we
have
some
module,
that's
a
license
that
the
attorneys
don't
like
and
then
the
second
one.
What
are
the
cbes?
You
know
what
are
the
vulnerabilities
that
are
out
there,
so
those
will
will
need
to
roll
up
at
the
container
level,
and
that
would
be
here
are
all
the
licenses
and
all
the
cves
for
this
component
version
and
then
from
there
because
of
our
relationships.
A
You
know
everybody
asks
that,
so
if
we
can
go
through
and
roll
these
things
up
to
the
application
layer,
I
can
just
click
and
say
print
and
I'm
done
within.
You
know
a
couple
seconds
providing
somebody
about
what
my
license
consumption
is.
So
that's
kind
of
the
where
we're
headed
with
with
the
service
catalog
data.
A
D
A
Now,
some
of
the
things
that
you
know
we
could
look
at
to
start
with.
You
know
like
just
start
with,
like
maybe
a
prometheus,
you
know
open
telemetry
with
a
prometheus
or
you
know
if
they
have
some
some
way
that
we
can
initially
integrate
and
wait
for
other
tools
to
be
brought
into
the
open
telemetry.
A
A
Now
we
have
to
take
the
other
side
and
make
sure
that
it's
matched
up,
that
we
don't
have
straight
transactions
that
somebody
has
a
bad
route,
so
we
want
to
be
able
to
marry
what
the
developers
are
wanting
and
what
the
operations
side
is
giving
them
to
make
sure
that
both
sides
are
are
meshing
together.
So
we
have
a
good
view
of
the
what's
happening
for
the
application,
because
one
of
the
things
that
we're
hearing
a
lot
now
is.
A
Is
it
works
in
my
cluster
scenario
and
part
of
it
is
the
people
when
they
came
to
kubernetes
they
didn't
change,
they
didn't
take
the
opportunity
to
change
to
make
their
their
development
practices
and
their
operation
practices
better.
Basically,
what
they
ended
up
doing
was
they're
treating
a
kubernetes
cluster
as
a
server,
and
everybody
gets
their
own
server.
Just
like
we
used
to
have
server
farms
for
every
application
team
now
we're
having
cluster
farms
of
every
single
application
team
getting
their
own
cluster,
but
there's
no
need
for
that.
A
If
you
look
at
the
way,
kubernetes
is
designed,
it
can
scale
to
500
nodes.
I
mean
5
000
nodes
that
you
can
scale
to
so
there's
plenty
of
room
for
multiple
application
teams
to
live
in
the
same
cluster
and
be
separated
by
smartly.
I
should
say,
put
the
word
smartly
around
it.
Smartly
separate
applications
based
on
namespace,
and
when
I
talk
about
that,
you
want
to
have
reusable
pieces
in
your
domain
driven
design.
A
Those
should
be
in
a
a
name
space
that
can
be
shared
by
other
applications
as
part
of
the
process.
So
you
want
you,
don't
want
to
have
copied
the
same
microservice
into
15
namespaces
and
it's
the
same
container
in
all
15
namespaces,
just
because
they
don't
want
to
figure
out
namespace
security
in
our
back.
You
know
you
want
to
have
it
those
reusable
pieces
in
ones
one
namespace,
and
then
you
set
up
the
routing
and
the
security,
so
they
can
be
shared
across
the
15
other
name
spaces.
As
part
of
that
process.
A
E
Yeah,
so
there's
been
some
pretty
heavy
technical
stuff,
I
kind
of
gone
through.
If
there's
anybody,
if
anybody
out
there
wants
to
you
know,
have
a
further
discussion
on
it.
I'm
totally
open
to
chatting
as
well,
because
I
know
there's
some
of
you
out
there
who
are
sort
of
new
to
this
space,
so
don't
feel
if
you're,
if
it
was
overwhelming
today
that
you
can't
reach
out,
say
okay,
I
didn't
understand
this
part.
It's
totally.
C
E
Because
we
are
going
to
start
coding,
we
got
next
week
because
our
steve's
going
to
start
pushing
issues
out
there
so
it'll
be,
and
I
think
that
we
have
everything
set
up.
We
still
have
to
the
the
cloud
build
stuff
that
sasha
documented.
We
still
have
to
apply
that
to
building
our
or
tla's
container.
Is
that
correct?
No,
it's
all
done
all
done.
So,
hey.
C
A
So,
on
that
front
we
have,
I
believe,
zach
I
saw-
was
picking
up
some
of
the
microservices
that
we
did
back
in
october
to
add
in
the
home
part
and
the
cloud
build
part.
So
there's
some
of
those
microservices
that
we're
adding
in
that
will
need
the
cloud
build
and
those
pieces
added
to
it
in
helm,
charts,
but
that's
just
part
of
the
the
new
development
that
we
have
going
forward
here.
So
you
know
everything
is
all
pretty
much
in
in
sync:
the
zero
clusters
up
there.