►
From YouTube: Distribution - Exploration of Registry metadata database
Description
Exploration of implementing gitlab.com/gitlab-org/container-registry with metadata in PG12 database, within the Cloud Native GitLab environment.
See https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2579
B
B
So
I
just
want
to
get
everything
up
and
online
and
then
we'll
figure
out
what
we
actually
need
to
do
inside
of
the
application
suite
what
we
have
to
do
to
the
database.
What
we
have
to
do
in
terms
of
configuring
things
what
we
have
to
do
to
actually
migrate
things
across
and
how
we
can
do
this
without
having
you
know
the
ability
to
necessarily
run
the
commands
inside
of
the
operational.
B
B
B
D
So
the
second
link
that
I
shared
is
the
registry
configuration
documentation.
So
if
you
open
that
and
search
for
database,
I
could
have
linked
the
proper
anchor,
but
it's
the
database
section.
You
will
see
all
options
that
we
need
to
support
right
now
and
you'll
see
the
documentation
for
each
one
of
the
parameters.
D
D
Okay
and
nothing
changed
for
for
the
outside,
so
no
one
will
actually
be
able
to
tell
if
the
registry
is
running
backed
by
a
database
or
not.
Probably
the
only
difference
that
they
will
notice
is
that
with
a
database
it
will
be
much
faster
to
serve
most
of
the
api
requests,
but
other
than
that,
it's
transparent.
B
D
D
D
E
C
B
B
D
C
C
B
B
D
A
A
B
B
E
D
B
B
B
B
B
B
B
C
B
B
B
A
C
A
C
B
A
B
B
B
A
B
B
E
B
A
B
C
A
D
B
E
B
C
B
B
I'm
configured
to
use
midio,
so
my
keys
are
transient,
but
now
I
can
go
back
to
the
pods
and
because
I've
updated
the
config
map
to
spit
out
the
configuration
we
can
inspect
from
the
logs.
What
actually
happened
like
did
it
have
a
problem
with
the
password
did.
Is
the
format
wrong?
Did
it
not
actually
populate
the
content?
A
E
B
C
D
B
There
you
go
and
then
there's
your
fatality.
You
were
talking
about
the
database,
so
the
only
problem
is
in
kubernetes
unless
you
have
something
that
goes
and
does
that
you're
going
to
have
anywhere
between
1
and
10
of
these
things.
Just
doing
this
constantly
right,
because
it's
going
to
come
up
looking
at
the
database,
realize
that
nothing
is
there
and
then
scream
at
us.
B
B
Prefect
I'm
using
this
as
an
example
because
they
have
it
built
in.
They
will
actually
run
the
migrations
at
start,
but
again,
pre-effect
doesn't
behave
the
way
the
registry
does
because
it
operates
as
a
stateful
set,
so
it
only
ever
starts
one
container
at
a
time,
whereas
the
registry
will
restart
anywhere
between
1
and
30
at
a
time
and
that's
where
the
the
race
happens.
B
B
C
B
C
B
E
C
E
E
C
B
C
B
I
could
run
a
second
init
container
and
have
it
just
do
that
at
every
single
startup
that
will
prove
this
out.
It's
not
the
right
way
to
do
it
in
the
end,
because
then
we're
trying
to
run
migrations
on
every
single
pod
start,
which
gets
us
into
that
race
condition
as
we
described
before,
but
that's
kind
of
the.
I
can
do
that
quick
and
try.
It.
C
B
B
D
B
D
D
B
B
F
B
C
B
C
E
A
B
B
Way
to
run
these
without
actually
popping
into
a
registry
which
is
somewhat
counter
to
the
way
that
admins
currently
expect
to
interact
with
the
application
suite
or
at
least
as
deployed
by
our
helm,
chart
they
don't
directly
run
commands
on
the
registry
binary
or
on
any
binary.
You
don't
go
into
the
web
service
container
and
then
run
rails
because
that's
actually
serving
application.
B
We
have
the
task
runner.
So
if
you
want
to
do
get
a
rails
console
or
do
a
task
runner
or
run
a
rate
command
that
all
happens
inside
of
that
container,
we
may
have
to
find
slash
document
the
way
that
we
want
to
do
this
for
the
registry
and
or
include
the
registry
binary
and
configuration
inside
of
the
task
runner
so
there
we
so
that
we
have
that
administrative
interface
so
that
people
can
pop
in
and
look
at
what's
going
on
with
the
database,
where
its
migration
states
are.
If
everything's
happy
anything
like
that.
E
B
E
B
B
E
E
B
B
A
A
B
In
regards
to
the
container,
I
don't
see
any
additional
dependencies
in
terms
of
compilation.
I
do
see
that
we
need
to
have
a
functional
database
where
to
function
so
we
need
to
have
access
to
a
server.
There
has
to
be
an
appropriately
configured
database
and
someone
has
to
have
actually
populated,
said
database
with
the
expected
structure
runtime
dependencies.
B
B
B
C
B
E
B
B
B
B
B
B
Okay,
so
what
should
be
tried
here,
then
also
is
to
run
this
without
the
database.
Steve
still
leave
it
with
postgres12
run
it
with
the
database
configuration
off
right.
So
the
register
is
running
in
that
fashion,
upload
a
different
container
and
then
turn
the
database
back
on
and
then
try
to
import.
B
D
B
A
D
Because
we
will
likely
only
use
the
import
to
laser
service,
not
really
as
a
separate
cli.
It
was
for
small
registries.
If
people
want
to
use
that
to
do
the
imports,
but
at
least
for
now
and
at
least
for
new
club.com,
we
will
need
a
separate
service
running
that
to
continuously
to
move
the
data.
So
I
don't
think
we
will
need
support
in
charts
for
that
in
the
street
chart.
That
is.
B
B
We
will
need
to
document
how
to
generate
a
pod
that
has
the
capability
of
doing
that,
but
it'll
probably
be
wherever
we
put
this
administrative
container
behavior
right.
If
we
do
it
in
the
task
runner,
then
we
can
tell
people
how
to
do
that
or
how
to
generate
a
cron
job
that
does
batches
at
a
time
right,
something
that
can
trigger
that
kind
of
behavior
moving.
B
B
B
B
B
B
B
C
A
B
B
B
C
B
B
B
B
E
F
But
yeah,
but
by
default
we
are
mirroring
to
the
boss
system,
as
we
write
to
the
database
just
in
case
there
is
something
that
really
goes
wrong.
We
have
a
way
to
just
like
move,
get
all
the
kids
off
out
of
the
pool
move
back
to
the
file
system,
at
least
until
we
are
more
sure,
more
burned
in
time
with
the
database.
B
A
B
A
B
B
G
B
Okay,
so
the
good
news
is,
it
looks
like
you
can
only
just
flip
the
database
on
or
off
without
too
much
of
an
issue
like
this.
Is
us
testing
it
out?
Yes,
I
know
that
joao
and
la
you
already
know
this,
but
we
don't
so
now.
We
know
it's
not
going
to
break
anything
if
somebody
turns
it
on
and
then
turns
it
back
off
again
so
per
design.
F
B
B
B
B
B
B
So,
for
the
sake
of
the
chart,
what
we
may
end
up
doing
is
having
the
property
there
be
the
same
name,
annoying
as
that
might
be,
and
then
pulling
that
in
as
a
part
of
our
template
behaviors.
Yes,
I
know
that's
uncomfortable
to
think
about,
but
we'll
make
it
work
is
the
point
yeah,
but
don't
worry.
I
can
give
you
more
headaches
if
you
want
to
see
the
problems
I
was
facing
last
night.
A
B
B
So
the
next
question
after
this
now
that
we
know
that
it
can,
we
can
get
it
up,
we
can
get
it
running
and
there's
very
little
real
world
modification.
That
needs
to
be
done.
We
need
to
figure
out
the
right
way
to
run
migrations
and
where
to
run
them
at
so
normally
you
would
expect
to
only
ever
run
one
copy
of
the
migrations,
correct,
yeah,
that's
right.
B
C
B
Is
there
is
a
job
that's
generated
and
that
that
job
generates
this
pod,
and
this
is
basically
sitting
inside
of
the
same
task
runner
container.
So
if
we
put
the
registry
binary
and
its
configuration
into
the
task
runner
container,
we
can
do
the
same
kind
of
migration
as
a
part
of
this
job.
Here
we
would
have
a
script
such
as
db
migrate,
but
then
we
would
have
a
different
script
that
was
like
registry
db
migrate.
B
And
then,
after
that
job
fires,
everything
gets
deployed,
and
then
this
fires
up
now
what
this
this
job
does
is
go
and
actually
wait
for
the
postgres
and
redis
to
be
up
and
reachable
and
then
proceeds
to
very
shortly
thereafter
turn
around
and
run
the
migrations.
If
they're
deemed
necessary
the
registry
container,
we
would
need
to
add
something
in
there
similar
to
what
we
have
for
web
service,
which
tells
it
to
wait
until
it's
at
a
happy
state
and
that's
the
trick.
B
A
C
B
That's
just
still
the
giant
one:
okay
in
it
containers
we
have
our
certificates,
which
basically
it
makes
sure
that
our
custom
cas
work,
and
then
we
have
our
next
image,
which
is
configure,
which
runs
the
same
configuration
script
very
similar,
which
is
a
very
similar
script
to
the
way
the
registries
configure
container
does
to
populate
its
configuration,
and
then
we
have
dependencies
what
this
container
does.
Is
it
actually
contains
that
same
wait
for
depth
script
that
the
task
runner
does,
but
it
has
one
more
thing
where
it
actually
goes
and
checks.
E
E
B
D
B
Container
scrolling
and
scroll
way
up,
so
what
dependencies
does
is
it
actually
reaches
out
through
the
configuration
and
tries
to
talk
to
the
the
database
like
it
makes
sure
that
it's
actually
there
before
it
tries
to
just
check
on
what
the
status
of
the
migrations
are,
and
you
can
see
as
the
container
started.
You
know,
there's
no
migrations,
and
this
is
what
I'm
expecting
and
then
once
the
database
has
actually
been
initialized,
it
will
come
up
and
say:
oh
yeah,
migrations
are
up
to
date
now,
meaning
in
in
terms
of
rails.
B
Their
migrations
are
time
stamped,
so
they
know
that
this
one
is
after
this
one
in
in
an
ordinal
fashion,
so
they
can
actually
distinctively
say.
Well,
I'm
now
newer
than
that.
When
I
we're
good
right
the
migrations,
there
follow
the
same
pattern
that
you're,
employing
in
the
registry,
which
is
there
forward
only
so
an
older
copy
should
safely
be
able
to
run
right.
D
B
F
C
D
D
B
F
Yeah
I
mean
we,
the
exit
error
code.
Flag
makes
a
lot
of
sense,
but
I
think
we
can
either
put
it
on
the
status
command
or
we
can
put
it
on
the
dry
run
or
they
up
command.
Withdraw
it
just
depends
on
like
what
kind
of
output
you
want.
If
you
want
something,
because
I
think
the
status
command
is
more
like
a
humorous
looking
at
this,
and
it's
not
really
designed
to
be
machine
parsed.
B
G
F
C
B
G
D
But
under
a
specific
flag,
if
it
is
okay,
aggression
wise,
if
not
okay,
then
there
are
some
migrations
to
be
applied,
and
in
that
way
we
can
distinguish
between.
We
don't
have
to
mess
with
the
exit
codes
and
we
won't
run
in
any
fun
issues,
for
example
connected
a
lot
of
ways,
and
then
we
really
don't
know
if
that's
a
problem
with
the
connection
or
if
the
database
is
updated
or
not.
So
I
think
if
you
were
to
return
just
not
okay,.
C
D
Okay,
and
that
would
be
better
to
be
a
separate
command
which
only
outputs
that
single
line
right
instead
of
adding
something
to
the
status
command
like
another
line.
At
the
end,
because
from
where
I
understand
the
the
the
problem
is
looking
at
this
output
and
try
to
figure
it
out.
If
there
are
any
lines
without
the
opponent
right.
B
A
C
B
B
D
F
F
B
F
F
D
B
C
A
B
Mitch,
what's
running
through
my
head
is:
if
we
can
do
up
dash
d
and
then
there's
we
have
obviously
have
to
see
what
the
up
is.
When
we
do
po
pre
and
post
as
we
would
with
the
operator,
you
would
run
it
when
you're
operating
in
a
mode
that
has
pre
and
post.
You
would
run
it
with
the
dash
s
to
skip
and
then
that
status
would
be
there.
The
only
concern
would
be
being
certain
that
migrate
up
dry,
run,
respects
that
flag
and
only
outputs
those
items
that
it
would
operate.
F
A
A
B
B
Does
that
command
doesn't
require
the
service
to
be
operational
at
all,
effectively
is
like
a
secondary
command
outside
of
serve
and
everything
else
correct.
It
would
need
to
have
the
configuration
file
to
match
and
it
would
need
to
have
oh
boy,
we're
going
to
relocate
properties
like
crazy.
If
we
do
that.
C
C
C
B
G
B
A
B
B
A
B
A
B
B
G
D
B
Is
that
we'll
have
the
job
which
will
deploy
only
if
migrations
are
directly
enabled,
and
there
still
has
to
be
some
kind
of
means
for
our
sres
to
actually
go
in
and
manually
run
them,
which
is
semi-problematic,
as
we
saw
earlier.
If
you
can't
get
the
pod
to
start
because
it's
expecting
a
service,
it's
really
hard
to
run
a
command
in
it.
G
B
B
B
C
A
B
D
Yeah,
regarding
that
have
a
look
at
the
the
message
that
I
just
posted
here
in
the
chats.
So
I
think
we
could
do
something
like
this
on
the
version
comment
just
that
just
having
an
up-to-date
flag,
and
if
that
is
passed,
we
just
return.
Okay,
not
okay,
depending
if
there
are
migrations
to
be
applied
or
not,
and
we
can
also
filter
out
post
deployment
so
that
the
job
can
check
them
separately
so
check
if
the
pre-migrations
are
up
to
date,
check
if
both
are
up
to
date
or
check.
B
D
B
Should
only
be
post
migrations,
the
only
other
thing
would
be
some
sort
of
indicator
on
every
migration
that
told
us
whether
it
was
whether
it
was
a
pre
or
a
post,
and
that
would
be
a
matter
of
the
joy
of
figuring
it
out
from
an
output.
I
mean
your
program
knows
whether
the
prayer
boasts.
The
output
doesn't
really
tell
me.
B
Starting
with
something
that
gives
us
less
that
we
have
to
do,
that's
that's
good
enough,
because
we
can
work
with
that.
That's
a
very,
very
simple
shell
script
that
we
don't
even
have
to
write
a
shell
script
for
because
we
can
just
pass
it
as
one
command
right,
because
you
know
what
we
would
do
is
we
would
run
this
command
and
then,
if
it
was
successful,
check
its
output
and
if
it's
output
was
n.
B
Okay,
then
our
shell
script
would
exit
2.,
whereas
if
it
failed
to
run
it
would
terminate
the
shell,
which
would
then
result
in
us
exiting
1..
So
if
it's
all
good
and
exit
0
and
the
init
containers
move
down
to
the
next
one,
if
it's
a
failure
of
the
database,
it
will
exit
one
and
we'll
know
as
a
failure
with
the
migration
status.
B
F
B
B
For
now
we're
going
to
put
off
any
alterations
to
the
task
runner
because
as
mitch-
and
I
pointed
out
this
just
this-
it's
too
broad
and
sweeping
to
make
that
change.
At
this
point,
the
chart
is
going
to
be
the
significant
portion
of
things
that
need
to
get
done.
I
don't
see
anything
inside
the
container
itself.
That
needs
an
alteration.
B
E
B
B
Having
you
on
hand
versus
us
trying
to
read
through
the
docs
probably
saved
us
over
an
hour,
and
we
definitely
appreciate
that
from
here.
I
think
mitch
and
I
can
take
it
we'll
put
the
entry
into
the
issue
we'll
make
sure
that
you
get
followed
up
and
we
will
begin
the
work
that
we
can
manage
from
there
mitch.
B
B
B
C
C
E
C
C
B
B
G
C
A
C
C
B
E
B
B
G
B
C
A
C
E
C
C
C
C
B
B
A
G
E
C
B
A
G
C
G
B
B
So
the
only
trick
is
that,
like
task
runner
doesn't
have
the
postgres
user
password,
it
doesn't
get
it
because
it
doesn't
need
it
needs
a
super
user
and
I
don't
think
gitlab
has
the
ability
to
create
in
in
our
chart
on
our
postgres.
I
don't
believe
that
it
has
the
ability
to
do
that,
but
let's
find.
B
B
C
G
C
G
E
B
That's
not
my
immediate
concern,
because
technically
the
init
db
should
be
what's
needed.
So,
let's
finish
walking
through
the
process
of
what
actually
happens
in
my
route,
ensure
the
user
exists.
You
know
create
the
that
for
the
daemon,
my
route
change,
my
read,
write
pre-init
pre-initialization
scripts.
What
does
this
do
and
then
initialize
and
then
custom
and
net
scripts
allow
running
custom,
initialization
scripts,
so
at
least
in
theory,
we'll
have
to
find
out
exactly
when
this
fires
and
when
this
fires
it
looks
like
a
net
fires
after
the
database
is
up.
B
A
B
B
B
E
B
C
C
E
B
B
A
A
B
C
D
C
B
C
B
B
G
G
B
C
B
A
B
A
A
B
G
Yeah,
I
guess
we'd
have
to
have
that
one
secret
and
have
keys
for
each
user.
We
want
to
create
and
and
then
in
this
loop,
just
lock
them
all
behind
if
blocked
like,
if
prefect
enabled
create
the
user,
if
registered
database
enabled
create
the
user
and
do
the
same
thing
in
the
shared
secrets
when
you're
creating
that
postgresql
password
secret,
I
guess
about
to
do
new
lines
or
something
and
condition
those
new
lines
on.
B
B
They
would
get
it
on
a
major
upgrade
when
you
go
from
11
to
12,
but
they
would
not
get
it
on
an
upgrade
of
just
the
chart
if
they've
already
installed,
and
they
want
to
turn
this
on.
They
have
to
go
manually,
create
either
the
user
and
the
database
or
just
the
database
and
use
the
same.
That
kind
of
thing.
A
C
A
D
C
C
G
E
A
B
B
G
G
C
B
C
B
A
A
B
B
B
B
E
B
And
what
I
would
probably
do
is
have
it
create
them.
Anyways,
like
have
shared
secrets,
generate
the
passwords
one
way
or
another
so
that
when
it
came
on
it'll
happen,
the
way
shared
secrets
works,
it
checks.
If
the
secret
already
exists,
it
doesn't
actually
check
if
the
key
exists
in
the
secret
and
it
wouldn't
hurt
to.
G
A
C
B
G
B
F
B
C
G
C
B
C
E
F
G
B
E
G
C
E
C
C
C
C
C
G
G
G
C
C
B
A
B
E
G
B
B
C
C
A
C
B
B
B
B
C
A
C
B
E
C
C
B
G
B
G
A
B
A
G
G
C
B
B
B
G
B
E
B
B
C
C
G
B
C
E
C
B
G
E
C
E
A
E
E
B
C
E
E
B
B
B
E
E
C
D
B
B
B
C
G
B
Okay,
this
recording
is
now
like
four
and
a
half
hours
long.
So
I'm
going
to
let
that
stop
and
we
can
go
from
here.
We
know
we
prove
that
we
can't
automate
the
database
with
actual
without
actually
having
to
touch
task.
Runner
task
runner
is
needed
in
order
to
be
able
to
have
the
registry
commands
operate
inside
of
it.
That's
a
no
go
for
now,
so
we
can
make
it
and
they
can
run
the
individual
commands
from
one
of
the.