►
From YouTube: Orchestrator CLI in Go 2020-09-14
A
I
figured
since
this
is
as
far
as
I
know,
this
is
our
first
go
big
go
project
for
the
distribution
team,
so
we're
gonna
walk
through
just
the
setup
of
it.
Some
of
the
architectural
decisions
we've
made
and
then
I'll
show
a
demo
of
what
we
have
working
so
far,
all
right.
So
on
my
screen
here,
let
me
make
it
a
little
bigger.
We
have
the
get
lab
orchestrator
project,
and
so
this
cli
is
actually
part
of
the
project.
It's
embedded
in
here
in
the
cli
folder.
A
There's
a
few
reasons
for
this.
One
is
just
we're
working
towards
releasing
the
cli
as
an
alpha
pretty
soon
here
and
the
the
cli
is
really
just
kind
of
currently
we
have
some
bash
scripts
that
run
ansible
and
terraform
code
to
stand
up
a
cluster
and
then
orchestrate
it
or
provision
it
together
and
the
cli
is
really
tied
to
those
ansible
and
terraform
modules
and
playbooks,
and
so
embedding
it
in
the
projects
seemed
the
least.
Friction
way,
thankfully,
now
you
can
do
this
with
go
previously.
B
A
A
So
one
thing
that
we've
done
here
is
we
followed
the
lead
from
other
go
projects
in
gitlab.
So,
specifically
the
get
lab
runner
project
is,
you
know
pretty
mature
at
this
point,
go
cli,
so
we
adopted
a
lot
of
their
conventions
instead
of
making
our
own.
This
should
make
it
easier
for
other
people
across
get
lab
to
be
able
to
bootstrap
into
this
project
and
understand,
what's
going
on
and
contribute
as
we
go
we're
using
the
same,
your
fav
cli
library
that
they
are
testify
for
testing
things.
A
So
it
was
great
to
have
an
example,
get
loud
runner
project
to
kind
of
look
to
our,
I
believe
the
orchestra
cli
will
will
still
be
simpler
than
the
gitlab
runner
project,
but
as
far
as
like
organizing
the
source
code
and
everything,
it
was
great
to
have
an
example
already-
and
this
was
part
of
this
issue
277-
that
mitch
worked
on
setting
up
all
this.
So
there's
a
lot
of
discussion
there,
so
the
next
well,
okay,
so
the
get
lab
runner.
The
runner
team
actually
set
up.
A
One
other
thing
that
we've
done
for
this
project-
and
this
is
really
something
that
robert
spearheaded
is
to
document
our
architecture
decisions
there's
this
in
the
doc
folder
there's
this
decision,
subfolder
that
has
some
markdown
files
and
so
in
in
respect
to
this,
what
we've
done
so
far
previously
we
had
our
cli
commands.
You
know
documented
that
we've
had
meetings
on
it
and
then,
as
as
our
understanding
grew
and
we
we
knew
better
what
we
needed.
A
So
this
is
also
something
that
mitch
worked
on,
so
the
init
command
will
pull
down
the
the
docker
container.
That
is
also
part
of
this
project,
and
so
really,
what
we're
doing
is
wrapping
putting
terraform
and
ansible
into
a
docker
container.
So
users
don't
have
to
have
the
right
version
on
their
systems.
A
A
A
A
I've
got
it
open
here
as
well
and
so
to
build
a
cli
from
here.
We
have
a
make
file,
which
is,
you
know,
has
some
standard
go
stuff?
One
of
the
other
nice
things
about
go
modules
is
that
it
kind
of
transparently
pulls
in
your
dependencies
for
you.
So
previously
you
had
to.
If
you
were
using
something
like
depp
or
any
number
of
like
third-party
dependency
managers
for
go,
you
would
have
to
like.
A
If
you're
building
the
cli
in
the
container,
you
would
have
to
first
get
depth,
then
you
would
have
to
use
it
to
grab
the
dependencies
and
then
you
would
have
to
build
the
project,
whereas
with
modules
you
just
say,
go
build
and
it'll
fetch
the
dependencies,
if
they're
not
always
there.
So
that's
really
nice,
especially
when
you're
trying
to
keep
down
the
steps
of
building
the
binary.
B
A
Just
run
make
and
now
you
can
see
in
the
cli
subfolder
we
have
this
orchestrator
binary
since
I'm
on
mac
it
build
it
for
mac.
So
let's
pop
open
the
help
text
for
this,
and
we
we
only
have
the
indent
command
so
far,
but
I
expect
you
know:
we've
done
a
lot
of
work,
setting
up
the
project
and
so
adding
new
commands
will
be
easier
as
we
move
forward.
B
A
Our
options,
and
so
one
of
the
things
we're
trying
to
do
here
is
not
be
not
be
tied
to
docker
itself,
because
there's
other
container
runtimes
that
we'd
like
to
support
as
well
apartment
pod
man
is
a
big
one
of
them,
and
so
we
have
this
runtime
flag
here
that
does
default
to
docker.
But
if
you
pass
runtime
pod
man
it'll
use
that
all
the
same,
and
so
the
the
hap.
The
easiest
path
here
is
just
around
orchestra
and
that
dash?
U-
which
is
auto,
update
dependencies
and
so
I'll
just
run
this.
A
So
this
is
pulling
the
image
from
get
lab.
Org
get
lab
orchestrator
for
the
for
the
project,
so
this
is
the
first
command
you
would
run
before,
starting
the
orchestrator
any
commands
from
then
on
out
will
use.
This
image
will
be
run
inside
this
image,
so
you
can
see
it
successfully
downloaded
the
dependencies.
A
B
A
So
docker
save
is
creating
a
tarball
of
this
image
now
and
you
can
see
it
now,
it's
in
the
cla
project.
So
if
I
don't
want
to
automatically
reach
out
to
the
docker
registry,
now
I
can
say
orchestrator
init
and
then
pass
it,
the
f
flag,
which
is
image
file,
flag
and
then
pass
it,
this
tarball
file,
and
so
now
you
can
see
that
it
loaded
this
image
successfully
and
now
that
will
be
used
from
then
on.
A
So
we
cover
both
the
online
and
the
offline
use
cases
that
way
so
yeah
we've
we've
got
a
good
amount
of
work
to
do
like
yet
on
the
cli,
but
we've
got
our.
You
know
our
cl
our
project
structure
in
place
again
just
kind
of
following
what
the
gitlab
runner
group
did.
We've
got
a
command
folder
with
the
name
of
the
project
and
then
a
main
file
that
just
reaches
out
to
the
app
object
which
is
defined
in
the
internal
folder
of
the
cli
project.
Here
and
breaking
it
out.
A
This
way
has
a
number
of
benefits
like
number
one.
We
end
up
with
smaller
source
files,
like
you
could
define
everything
in
main.
Like
your
whole
cli
application,
but
then
you're
going
to
end
up
with
like
several
hundred
lines
of
command
declarations
and
especially
with
the
the
nested
style
of
go,
it
can
quickly
get
pretty
confusing
about
what's
happening.
A
Where
and
of
course
that
leads
to
testing
issues,
because
it's
hard
to
pick
apart,
specific
commands
to
test,
and
so
instead
we
have
under
commands
here's
the
init
command,
so
we're
defining
the
flags
and
then
we're
we're
running.
This
manage
dependencies
function
and
passing
it
in
the
cli
context,
and
so
that
means
we're
able
to
unit
test.
This
manage
dependencies
function
on
its
own
without
having
to
you
know,
load
up
the
whole
cli
object
and
parse
through
it.
So
that
makes
unit
testing
a
lot
easier.
A
C
A
Okay
yeah,
so
this
will
be
a
way
for
we're
working
on
figuring
out
a
config
file
format
for
the
orchestrator.
You
know,
it'll,
probably
be
just
a
yaml
file
where
you
specify
your
options,
but
this
set
and
get
will
be
a
way
to
work
with
this
file
in
an
less
error-prone
way.
And
so
let's
say
you,
you
want
to
set
the
runtime
in
this
config
file.
A
If
you
want
to
orchestrate
straighter,
set
runtime,
docker
or
runtime
pod
man
we'll
be
able
to
do
some
validation
on
that
coming
in
and
so
it'll
make
it.
You
know
I
don't
want
to
say
impossible,
but
very
difficult
for
users
to
do
the
wrong
thing,
because
if
you
put
in
a
wrong
option,
it'll
say
something
like
you
know:
docker
2
or
so
some
typo
is
not
a
supported
run
time,
even
before
you
write
it
to
the
file.