►
From YouTube: Repeatable DB creation Demo (2021-08-11)
A
At
the
first
discussion
point
so
yesterday
we
discussed
how
we
were
feeling
with
omnibus
for
postgres.
It
sounds
like
we're
okay
for
now,
but
we
are
gonna
keep
on
evaluating
this
moving
forward.
The
biggest
blocker
is
pg
bouncer,
and
I
think
this
is
gonna
require
us
to
not
use
omnibus,
at
least
until
this
issue
is
resolved,
but
for
now
we
can
use
omnibus
for
petroni.
A
A
A
We
have
this
one
libsonic
file,
which
is
the
source
of
truth
for
shards
and
environments.
Environments
are
defined
here.
These,
hopefully
won't
be
changing
that
often,
in
fact,
I
don't
think
they'll
be
changing
at
all.
We
don't
really
have
an
automated
way
to
create
new
environments.
If
you
do
add
an
environment
to
this
file,
it
does
require
you
to
create
the
gcp
project
first
and
to
create
the
service
account
and
configure
the
ssh
key,
which
is
all
done
through
terraform,
but
it's
kind
of
like
a
multi-step
process.
A
A
These
are
ansible,
plays
that
you'll
be
using
to
configure
the
shard
and
then
a
list
of
secrets,
and
for
now
I
just
have
these
in
variables,
because
they're
common
for
all
of
the
shards
you
can
see
like
for
in
environments,
it's
just
basically
every
shard
right
now
is
applicable
to
all
environments.
So
I'm
just
using
the
keys
in
the
environments
object.
Above
then,
we
have
secrets
all
shards
are
using
the
same
three
secrets:
postgres
pg,
bouncer,
patrony
and
then
all
shards
are
using
the
same
place,
and
these
are
the
plays
that
we
support.
A
A
A
A
A
Okay,
so
like
before
we
have
environments
and
there's
a
child
pipeline
per
environment.
Eventually,
these
sandbox
alphabet
and
gamer
are
going
to
go
away
and
we'll
just
probably
have
the
three
within
each
environment.
You
can
have
n
number
of
shards.
I
added
this
shard
to
well.
I
added
it
to
all
environments,
but
maybe
I
would
only
add
it
to
alpha
to
start.
If
I
click
alpha,
we'll
be
able
to
see
it.
A
So
I've
arranged
things
so
that
there
is
a
stage
per
shard
and
this
is
just
for
ansible.
So
each
one
of
these
jobs
corresponds
to
an
ansible
play.
You
can
see
here's
the
new
dd
shard.
Previously
I
had
ci
in
registry.
Now
we
have
three
once
the
chart
is
created,
then
I
need
to
provision
and
configure
it.
Provisioning
happens
with
these
three
jobs
here.
Well,
just
the
first
two,
the
last
ones
to
destroy
it,
but
the
first
two.
A
What
it
does
is
it
just
runs,
terraform,
admit
terraform
plan
and
then
deploy
it
once
the
shard
infrastructure
is
created,
then
you
can
configure
it
by
running
ansible
and
right
now,
like
you
have
to
do
it
in
a
particular
order,
like
you
have
to
do
console
before
post
frizz,
I
was
thinking
ahmad
and
alexandra
I
was
thinking
like.
Maybe
we
should
have
a
play
that
combines
the
other
plays.
So
that's
like
a
one
shot
for
initial
provisioning.
A
I
think
once
we
have
things
configured,
then
we
might
want
to
just
run
postgres
by
itself,
but
at
least
when
you're
bootstrapping
a
new
server.
You
have
to
run
console
before
before
postgres
after
the
shard
is
created.
Then
you
run
these
plays,
and
then
you
have
a
functioning
postgres
petroni
cluster.
A
A
What
I
kind
of
would
like
is
that
I
could
just
hit
this
like
play
all
and
it
would
just
work,
but
in
order
for
that
to
work
like
you
would
just
have
to
have
one
job
or
two
like
you'd
have
to
collapse
like
there's
certain
things
that
we'll
be
able
to
run
in
parallel,
but
for
now
these
three
jobs
kind
of
can't
run
well.
The
patch
doesn't
matter
right
now,
like
you
said,
but
so
I
guess
like
maybe,
and
we.