►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Thanks
for
joining
us,
we
are
here
to
hear
our
live
webinar
today,
making
your
app
soar
without
a
container
manifest.
I'm
gonna
read
our
code
of
conduct
and
then
I'll
hand
over
to
jason
smith
customer
engineer
at
google
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak,
but
there's
a
q,
a
chat
box
on
the
right
hand,
side
of
your
screen
drop
your
questions
there
we'll
get
to
as
many
as
we
can.
At
the
end.
A
A
Please
also
note
that
the
recording
in
slides
will
be
posted
later
today
to
the
cncf
online
programs
page
under
online
programs.
They
are
also
available
via
this
registration
link
you
used
to
get
in
today,
and
the
recording
will
also
be
on
our
online
programs,
youtube
playlist
under
the
cncf
playlist
channel.
B
Thank
you
very
much
libby
and
thank
you
everybody
for
joining
us.
We
have
quite
an
open
house
here
and
I'm
on
the
pacific
coast
right
now.
So
thank
you
for
waking
up
early
for
this.
We
can
have
a
great
start
to
the
day,
learning
a
little
bit
more
about
ways
to
make
containers
without
manifest
files.
B
So,
as
mentioned,
my
name
is
jason
smith.
I
go
by
jay.
I
will
always
say
that
I
will
respond
to
either.
If
you
call
me
one
or
the
other,
I
will
raise
my
head
and
acknowledge
you.
So
that's
fine
and
you
can
follow
me
there
on
twitter
and
there's
my
dog,
which
you
may
or
may
not
hear
during
this
session.
So
heads
up
on
that
one.
B
So
on
today's
agenda,
we're
going
to
kind
of
define
environments,
one
of
my
big
things
that
I
like
to
do
is
I
find
it
very
beneficial
to
kind
of
recap
where
we've
been
and
kind
of
set
the
stage,
then
we'll
talk
a
little
bit
about
build
packs,
tecton,
quick
demo
and
then
we'll
jump
into
a
q
a
so.
I
started
computing
seriously
like
running
my
own
web
apps
running
my
own
pcs.
Back
in
I
want
to
say
around
2004
2005
and
this
checklist
might
look
very
familiar
to
a
lot
of
people
here.
B
If
I
want
to
build
my
own
little
php
app
to,
I
don't
know,
let's
say
manage
my
college
schedule
or
something
I
had
to
go
through
this
whole
mess
of
things.
I
had
to
first
find
an
old
computer
and
then
usually
I
could
go
to
like
goodwill
or
something
or
hit
up
some
yard
cells,
get
a
bunch
of
components
put
it
together.
B
B
All
I
pronounced
multiple
ways:
linux
install
apache,
my
sql
php
installs,
the
various
php
plugins
for
like
ssl
whatnot,
configure
apache,
create
virtual
host,
create
new
users,
great
folders,
open
firewalls
and
ports,
and
then,
of
course,
because
it
was
in
my
house,
I
had
to
go
and
find
way
to
port
for
the
network
or
use
dying
dns
or
something-
and
this
was
all
before
I
even
started-
writing
an
application
like
this
is
literally
everything
I
had
to
do
before.
I
started
writing
an
application.
B
I'm
sure
we
all
remember
having
to
do
stuff
like
this,
and
a
lot
of
it
was
just
setting
up
infrastructure.
Like
I
mentioned,
finding
an
old
computer
making
sure
the
full
the
ports
are
forwarded,
making
sure
my
vms
are
are
not,
maybe
I'm
sorry
making
sure
like.
I
have
the
right,
hard
drive.
I've
got
things
mapped
properly,
I'm
doing
the
right
security.
B
All
of
this
stuff,
virtual
machines
came
around
and
I
felt
like
my
world
changed
when
I
got
into
doing
hosted
virtual
machines,
whether
it
was
like
a
vps
system
or
something
on
the
cloud
or
whatever
it
was
in
the
in
those
days
my
world
changed.
It
was
just
like
oh
snap,
I
don't
have
to
mess
with
hardware
anymore.
This
is
great.
B
I
could
declare
how
to
stand
up
my
vms,
how
what
I
want
on
there,
all
that
stuff
kind
of
write
code,
but
I'm
still
kind
of
configuring,
the
operating
system
and
all
of
that
and
patching
and
whatnot
then
comes
this
little
thing
called
containers
which
further
abstracts
away
the
operating
system,
and
now
we're
just
talking
about
my
application,
my
dependencies,
we
all
know
this.
We
all
use
docker
containers.
We
were
all
familiar
with
it,
but
you
know
there.
There
comes
the
question
of
well.
How
do
we
manage
all
of
it?
B
B
Of
course,
there
still
comes
this
little
problem
of
docker
files.
Now
I
would
argue
that
docker
files
are
much
simpler
than
a
lot
of
times.
Your
your
cookbooks
or
vm
manifest
or
anything
like
that.
But
still,
if
you're
a
developer,
you
know
using
a
lot
of
using
a
large
docker
file
is
not
fun.
You
still
have
to
declare
stuff,
and
you
still
kind
of
want
to
just
focus
on
code
like
hey,
can
can
something
just
build
the
file
for
me
like?
B
B
B
If
I'm
not
mistaken,
it's
now
cncf
project,
and
it
also
is
great
for
cicd,
because
well,
what's
the
point
in
having
the
docker
files,
if
I'm
not
going
to
actually
implement
them
somehow
do
I
still
have
to
use
you
know,
docker
push
or
something
like
that
in
order
to
get
the
code
up
there,
or
is
there
a
way
to
automate
that
we'll
talk
a
little
bit
more
about
that
later,
so
build
packs,
allow
developers
to
take
advantage
of
the
benefits
of
the
containers
without
needing
to
understand
them.
So
I
write
the
source
code.
B
Build
packs,
go
ahead
and
turn
it
into
the
container
and
my
ci
cd,
my
cicd
pipeline
will
go
and
deploy
it.
Why
this
is
important
is
again
letting
developers
focus
on
the
things
that
are
important
to
them,
like
with
all
the
new
libraries
that
come
out
all
the
new
dependencies
trying
to
just
keep
up
with
what
standard
in
modern
technology
can
sometimes
seem.
Very
intimidating,
quite
frankly,
just
because
it's
like
what
do
I
learn?
What's
going
to
be
deprecated,
what's
going
to
be
important?
How
do
I
actually
remain
competitive?
B
How
do
I
actually
build
something
that
my
users
are
going
to
like?
On
top
of
that,
I
need
to
keep
up
to
date
with
how
to
make
sure
my
code
deploys
properly
well
into
a
container.
How
do
I
make
sure
these
containers
work
are
secure?
All
that
stuff
is
the
the
point
of
build
packs
is
kind
of
to
remove
that
friction
from
the
developer
and,
as
I
mentioned
it's
an
incubated
project,
it
was
actually
a
sandbox
project.
B
I
don't
have
the
exact
timeline,
but
I
want
to
say
about
a
year
year
and
a
half
ago,
but
now
it
is
actually
incubated,
so
it
is
graduating.
It
is
growing
up
and
it's
kind
of
a
container
within
a
container,
so
build
packs
is
actually
a
container
that
builds
containers
without
docker
files
seems
a
little
seems
a
little
odd,
but
essentially
what
you're
doing
is
you're
deploying
a
special
builder
container
that
will
then
take
the
code
that
you
deploy,
examine
it
and
then
say
hey.
B
B
I
think
a
lot
of
people
are
trying
to
move
away
from
the
term
docker
container,
not
necessarily
because
there's
anything
wrong
with
the
term,
but
because,
like
you
know
it's
like
it's
more
than
just
that
one
company
or
it's
like
trying
to
separate
the
idea
of
the
company,
it's
like
how
you
how
you
might
use
the
term.
You
know
like
kleenex
for
tissue,
where
it's
like
well,
kleenex
is
a
company
tissue
is
the
actual
thing.
B
So
it's
like
okay,
so
a
lot
of
people
will
say
oci
image,
but
just
to
kind
of
set
that
clear,
because
you
might
see
both
here
a
compensation.
So
you'll
have
a
composition
of
build
pack
groups
and
life
cycle
binaries.
What
does
that
mean?
We'll
see
later,
it's
basically
a
long
set
of
of
different
builders
to
create
a
simple
application.
B
As
you
know,
your
application
is
not
going
to
be
just
one
simple
file:
one
simple
docker
file
and
hey.
I've
got
a
running
application
unless
it's
a
hello
world
application
or
something
to
that
effect,
you're
going
to
have
more
complex
and
then,
of
course,
you'll
have
a
full
platform
that
provides
the
users
the
if
the
information.
So
basically,
what
does
this
mean?
I
write
my
code,
the
build
I
deploy
the
code.
The
builder
will
then
just
say:
okay,
this
looks
like
go
line
code.
B
B
B
Now
I
mentioned
build
pack
groups,
as
you
can
see,
when
you
create
yourself,
when
you
create
a
docker
file,
you
notice
that
you'll
have
the
different
steps.
So
you'll
have
like
from
you
know
alpine
and
then
I'm
gonna
take
this
stuff.
I'm
gonna
do
this.
I'm
gonna
copy
this
file
and
create
this
entry
point.
B
B
The
language
as
it
says,
like
okay,
I
can
tell
that
this
is
go
lang
or
I
can
tell
that
this
is
python.
I
think,
in
order
to
make
a
python
application
we're
going
to
need
to
put
in
this
this
this
and
this
the
code
is
in
this
file.
Okay,
so
it's
doing
a
lot
of
reading
and
guess
work
if
you
will,
but
it's
a
little
better
than
just
saying
guesswork,
because
it
is
more
intelligent
than
that
it
is.
B
It
gets
things
right,
but
then,
of
course
you
have
the
stack
which
is
kind
of
the
base
image.
You
know
your
alpine,
your
ubuntu
whatnot.
Each
build
pack
supports
a
set
of
stacks.
Unfortunately,
I
don't
believe
you
can
do
the
I
this
could
be
dated,
but
I'm
not.
I
don't
think
it's
does
the
app
build
yet
app
get,
but
I
think
that
might
now.
To
be
honest,
this
might
be
an
older
slide,
but
ultimately
you
you
have
like
the
stack,
the
base
level
and
you
know
like
okay.
B
This
is
like
an
ubuntu
stack
that
can
support
php
or
this
can
support
python39.
This
can
support
golang
with
xyz
libraries,
so
on
and
so
forth.
So
basically
you
define
your
stack.
You
decide
that
becomes
the
base
image,
then,
on
top
of
that,
the
builders
will
build
the
application
using
the
code,
making
the
guesses
they're,
making
the
educated
guesses,
the
very
educated,
guesses
and
building
out
the
entire
application.
B
It's
not
you,
don't
have
to
really
install
anything
special
or
add
anything,
a
special
to
your
system
in
order
to
make
it
work,
which
is
great,
my
benefit
and
I've
really
been
liking,
buildpacks
lately,
because
it
just
makes
it
so
much
easier
to
deploy
code.
I
think
a
lot
of
times
we're
all
trying
to
find
different
ways
to
containerize
things.
B
I'm
sure
if
I
asked
everybody
here,
what's
the
number
one
way
you
containerize
things
so
a
lot
of
it
will
probably
be
either
docker
build
or
include
something
in
your
ci
cd
pipeline
or
canaco,
but
it
all
requires
you
to
still
have
a
docker
file.
Usually
the
nice
thing
here
is
that
this
kind
of
eliminates
that
unless
you
just
speak
in
the
word
of
code
or
speak
in
the
language
of
code,
something
you're
familiar
with
now
I'm
a
huge
fan
of
tecton,
and
so
is
my
dog.
B
As
you
can
see
there,
a
lot
of
people
are
saying.
Well,
this,
you
might
be
listening
and
saying:
well
that's
great,
but
where
does
the
container
that
builder
container
live
like?
How
does
it
deploy?
Does
it
live
in
my
kubernetes
cluster?
Am
I
actually
just
going
to
have
to
run
it
as
its
own
container
on
my
system?
B
B
B
This
is
such
a
good
product.
It
should
be
a
standalone
thing
like.
Why
should
why?
Why,
should
it
be
a
c
dot
c,
I
c
d
solution
for
one
specific
environment.
It
should
be
a
cic
solution
for
everything,
so
we're
going
to
use
a
few,
I'm
going
to
find
a
few
basic
things
within
tecton,
so
there's
a
pipeline
and
that's
similar
to
what
you
might
think
with
the
standard
ci
cd
pipeline.
B
So
the
step
would
be
an
operation
in
the
workflow,
such
as
running
a
pi
test
on
python
applications.
The
steps
are
the
individual
things
that
it's
doing
a
task
is
essentially
a
collection
of
steps,
and
then,
of
course,
the
pipeline
is
a
collection
of
staff
as
a
collection
of
tasks
triggers
are
the
component
for
eventing.
So
do
I
want
to
actually
have
to
go
in
every
single
time.
Somebody
does
a
git
commit
or
a
branch
is
merged,
or
something
and
manually
trigger
the
build
of
the
code
or
the
deploy
of
the
code.
B
That
doesn't
really
seem
like
a
great
idea
in
the
cicd
world,
especially
when
we're
trying
to
be
more
agile
developers.
So
instead
we
have
what
we
have
an
event
listener,
which
is
essentially
a
crd
that
oh,
that
will
listen
for
a
specific
json
payload.
The
good
thing
is
that,
with
a
lot
of
json
payloads
you,
you
know
there
there's
some
defaults
that
were
there
so
like
it'll,
say:
okay.
Well,
this
is,
we
know
what
a
git
lab
or
github
or
whatever
payload
looks
like.
B
So
we
already
have
the
the
schematic
or
the
schema
there.
So
you
just
tell
us
what,
where
it's
coming
from,
we
got
it
or
you
can
also
just
create
your
own
custom
if
you're
wanting
to
trigger
in
your
own
way.
That's
fine
trigger
template
is
the
resource
for
the
triggers
and
then
the
binding
is
essentially
what
binds
the
trigger
to
the
payload.
B
To
give
you
a
good
idea,
let
me
go
ahead
and
see
if
I
can
expand
this
a
little
bit.
This
looks
like
an
eye
chart
almost
that's
nothing
any
bigger.
I
apologize
for
that.
Well,
in
short,
this
is
essentially
what
a
task
with
steps
would
look
like.
If
you
look
at
it,
you
have
a
few
parameters
that
I
set
like
okay,
here's
my
docker
file.
This
is
where
my
source
code
lives
in
source
path.
This
is
the
this
is
where
my
canico
and
this
expand
example.
B
I've
talked
about
canaco
in
the
past
being
a
way
to
build
containers
without
actually
ever
have
having
to
pull
it
down
to
your
own
machine.
It
builds
containers
in
the
cloud
in
your
kubernetes
cluster,
your
resources,
so
those
are
kind
of
like
the
variables
you'll
put
in
like
okay.
This
is
the
image
I
want
created.
This
is
a
get
and
then,
of
course,
the
the
actual
steps
that
are
executed,
such
as
you
know,
do
a
pie
test
and
do
the
canaco
build.
B
B
The
benefit
of
the
catalog,
as
I
mentioned
earlier,
is
that
there
are
a
lot
of
pipelines
and
tasks
there
that
are
very
common,
that
you
probably
will
use,
and
they
are
all
you
really
do-
is
kind
of
plug
in
the
10
of
the
variables
that
you
need
that
are
relevant
to
you,
such
as
your
git
repo,
or
what
you
want
to
name
your
container
or
things
like
that,
whereas
the
actual
steps
that
do
the
thing
are
already
created.
So
you
know
why
bother
reinventing
the
wheel
when
you
don't
need
to
come
up?
B
And,
of
course
you,
the
nice
thing
here
is
that
we,
the
way
techton
works,
is
it's
a
lot
of
the
tasks
are
reusable
and
then
they're
kind
of
plug
and
play
too,
so
I
can
actually
add
new
tasks
into
a
pipeline
or
new
pipelines.
One
way
to
think
about
techton.
What
I
always
like
to
say
is
it's
not
traditional.
B
Like
simple
cicd
platform,
it's
more
like
building
blocks
like
you
can
build
a
great
ci
cd
platform.
So
it's
not
something
that
I'm
going
to
just
necessarily
click
click
click.
It's
deployed
it's
running
on
my
server.
I
can
do
all
the
great
stuff
to
it
there.
You
know
some
assembly
required,
but
it
allows
you
to
do
a
lot
more
than
what
we've
been
able
to
do.
Historically,
largely
because
we
are,
you
are
getting
those
primitives.
You
are
getting
that
access
to
the
lower
level
components
of
kubernetes.
B
Speaking
about
the
catalog,
did
you
know
that
tecton
has
some
tasks
related
to
build
packs
and
I'm
going
to
include
on
the
slides
when
they're
available,
like
the
like?
A
slide
at
the
end
I'll
have
a
link
to
a
bunch
of
different
resources
that
give
you
kind
of
the
groundwork
to
use,
build
packs
with
tecton,
because
we
want
a
full
solution.
B
You
know,
if
I
say
hey,
I
made
your
life
so
much
easier.
Look
at
this.
You
can
use
build
packs.
You
can
deploy
code
as
you
want,
but
or
you
can
containerize
your
code.
However,
you
want,
but
how
do
I?
Actually?
This
is
great.
The
code
is
containerized.
How
do
I
actually
use
the
code?
How
do
I
actually
consume
the
code?
How
do
I
actually
get
the
code
to
do
something?
B
Whereas
I
get
you
know,
we
all
use
ci
cd
pipelines.
I
think
most
of
us
are
using
ci
cd
pipelines
or
at
least
thinking
about
using
ci
cd
pipelines.
So
by
giving
you
these
tecton
tasks,
it's
making
it
that
much
easier
for
you
to
utilize
the
ci
cd
pipeline
and
in
fact
I
will
go
ahead
and
show
you
real,
quick
how
we
do
this
give
me
one.
Second,
I
need
to
move
some
stuff
around
here.
B
Yeah,
so
essentially
you
have
to
choose.
That's
correct.
You
essentially
have
to
choose
the
proper
stack
now
granted.
You
are
able
to
customize
stacks,
so
in
the
same
way,
there's
default
docker
containers
out
there
that
you
can
download
or
there's
a
boilerplate
code
for
different
pieces
of
software,
etc,
etc.
B
In
the
same
way,
there's
a
lot
of
quote-unquote
boilerplate
stacks
that
you
can
use
that
you
can
build
on
top
of
if
you
need
to,
if
you
have
a
platform
engineer
who's
on
the
team,
that
per
you
know
that
person
be
in
charge
of
it
and
then
just
pass
things
along
along
to
the
developers,
but
yeah
you
do
need
to
use
that
stack.
The
nice
thing
is,
you
can
build
your
own
stacks
you're,
not
like
kind
of
stuck
with
whatever
stacks
are
provided
to
you
grant.
Of
course,
that
is
extra.
B
That's
kind
of
the
nice
thing
about
everything
kind
of
cncf.
I
could
take
a
minute
here,
like
everything,
kubernetes
and
I've
been
a
huge
like
linux
and
open
source
fan
for
who
knows
how
long
I
think
I
lost
count
since
my
college
days
whenever
that
was
and
the
one
thing
I've
always
liked.
Is
it's
like
hey?
If
there's
not
a
solution
there
today,
we'll
give
you
the
basic
building
block,
so
you
can
just
build
it
yourself.
B
If
you
want
to
you
know,
obviously,
that's
not
always
the
best
idea,
if
you're
in
a
if
you're,
in
a
rapid
situation,
but
just
having
that
flexibility
is,
I
think
what
has
allowed
things
like
containers
and
kubernetes
and
tecton,
and
what
not
to
come
to
existence
because
you've
had
a
lot
of
great
people
come
together
and
say:
hey,
let's
take
this
code
and
let's
make
it
a
little
better,
let's
find
a
better
way
to
do
things.
So,
let's
leave
my
little
aside
there
on
the
benefits
of
cloud.
B
So
let's
go
ahead
and
take
a
look
here
so
that
you
can
follow
along
and
I'm
kind
of
one
of
those
no
point
in
rebuilding
reinventing
the
wheel.
Here
we're
going
to
go
ahead
and
take
a
look
at
the
build
pack
tecton
integration
code
and,
like
I
said
I'm
going
to
I
mean
you-
can
easily
find
this
link,
but
I'm
going
to
go
ahead
and
put
it
in
the
in
the
slides
later.
So
that
way,
if
you
know
make
it
a
little
easier
to
find
it.
B
All
right
so
and
then
I'm
using
google
cloud,
because
I
work
for
google,
it's
easy
for
me
to
access
the
google
cloud
environment.
This
will
work
for
any
kind
of
kubernetes
cluster.
This
is
these:
are
open
sources
they're,
not
google
products.
These
aren't.
You
know
these
are
actually
cmcf
and
cd
foundation
products.
So.
A
B
A
B
B
B
B
B
B
So
you
see,
I
can
install
the
text,
so
I
guess
we
can
just
talk
step
through
step
through
this
apologies
again,
so
install
tech
town
on
the
dashboard
super
easy
to
do.
You
know
it's
just
kind
of
cube
ctl
and
then
you
can
apply
the
file
and
then
there's
it's
a
github.
Repo
link
to
the
actual
yamal
dashboard
is
a
pretty
cool
tool.
If
you
want
visualization,
it's
more,
I
wouldn't
say
it's
newer.
B
A
B
Requirement
you
install
the
actual,
build
pack
version
which,
if
we
wanted
to
look
at
it,
I'm
not
gonna
force
you
all
to
listen.
Look
at
a
wall
of
yaml
you
when
you
install
this
special
task
for
pipelines
which
will
clone
the
get
repo,
and
this
should
be
a
smaller
yaml.
So
we'll
take
a
look
at
it.
I
highlighted
it
as
a
large
ammo,
but,
as
you
can
see,
it's
just
a
standard,
github
task
or
not
sorry,
standard
tasks
for
cloning,
a
git
repo
via
tecton.
B
B
You
know
we'll
create
a
secret,
no
big
deal
because
with
whatever,
wherever
it
is,
we're
hosting
our
we
plan
on
hosting
our
docker
containers,
because
remember
at
the
end
of
the
day,
it
is
building
a
docker
container
like
it's
not
just
because
you're,
not
creating
a
docker
file
doesn't
mean
that
you're
not
creating
a
docker
container.
It
is
still
creating
a
docker
container
that
container
needs
to
live
somewhere,
whether
it
is
docker
or
some
other
cloud.
I'm
sorry
excuse
me.
B
Some
other
container
registry
is
fine,
but
you
do
need
to
give
the
access
authorization.
We
create
a
basic
pipeline.
That's
pretty
straightforward!
You
create
some
workspaces.
You
create
a
you
kind
of
list,
the
different
tasks,
what
workspace
they're
a
part
of.
So
we
have
a
task
for
we're
cloning,
the
repo
we
got
tasks
for
using
the
build
pack
and
then
some
parameters
which
you
can
think
of
as
variables
apply
the
configuration
and
then
there's
a
so
remember
when
I
mentioned
triggers.
B
So
the
triggers
just
kind
of
automatically
trigger
the
build
of
a
tecton
pipeline
so
an
event
such
as
I
pushed
something
to
a
specific,
get
branch
or
there's
a
specific,
a
specific
tag
label
or
something
to
that
effect,
and
we
want
it
to
react
to
that.
However,
there's
also
these
tools
called
pipeline
runs
which
essentially
allowed
you
to
run
the
file
manually.
So
if
I
were
to
deploy
this
run.yaml,
it
would
just
go
ahead
and
trigger
the
build
right
away,
and
then
you
can
do
pipeline
runs
see
the
build.
B
You
can
do
some
cleanups,
it's
pretty
straightforward,
yes,
tecton
and
build
pack
are
both
open
source.
As
I
mentioned,
buildpack
is
a
cncf
project,
it
it
is
open
source
and
it
is
a
lot
of
pr
I
I
kind
of
like
to
think
of
it
as
like
a
primitive.
The
reason
I
say
that
is
because,
just
like
the
earlier
question,
we
had
about
different
stacks
and
whatnot,
because
there
are
multiple
stacks
or
multiple
ways
to
do
things.
B
Different
vendors
will
build
on
top
of
build
packs
or
create
their
own
custom
stacks
that
work
great
on
their
environment,
but
build
packs
in
and
of
itself.
Those
primitives
are
open
source.
On
top
of
that
tech
town
is
open.
Source
too
tecton
is
part
of
the
cd
foundation,
the
the
which
is
a
I.
I
would
call
it
a
sister
foundation
to
the
cncfs
they're,
both
part
of
linux
foundation,
as
like
kind
of
the
parent
organization.
B
Whereas
cncf
focuses
on
you
know,
cloud
native
technologies,
cd
is
more
specific
towards
you
know
continuous
delivery,
which
is
important
in
the
cloud
native
world,
but
not
just
a
cloud
native
thing
like
it
exists
in
other.
You
know,
there's
still
legacy
cd
technology
and
everything
like
that,
so
hence
having
its
own
foundation.
But
yes,
they
are
both
fully
open
source.
You
can
contribute.
B
What
we're
seeing
is
with
so
with
tech
town
we're
starting
to
see
a
lot
more
companies
actually
adopt
it
in
terms
of
the
primitives.
As
I
mentioned,
it's
kind
of
a
tool
for
building
tools
or
in
the
same
way
that,
like
kubernetes,
is
kind
of
a
tool
for
building
platforms.
It's
not
the
it's
not
the
end
goal.
It
gives
you
the
the
building
blocks
to
build
your
luck,
your
platform
versus
it
being
just
a
point-and-click
solution,
or
something
like
that
tecton's
kind
of
the
same
way.
B
So
there's
been
a
lot
of
companies
that
have
taken
tecton
and
they're,
building
open
source
tools
or
proprietary
tools
for
that
matter,
using
those
open
source,
apis,
open
source
standards
of
tech,
tom
that
way
kind
of
that
way,
there's
kind
of
a
standard
between
different
environments,
you're
not
having
to
go
from
you
know
this
environment
uses
its
own,
very
proprietary
stack,
and
but
I
want
to
be
cloud
native
and
I
want
to.
I
want
to
be
in
every
environment,
and
you
know
I
want
to
be
able
to
deploy
on-prem
and
in
the
cloud.
B
So
I
don't
have
to
learn
two
different
things.
So
that's
kind
of
a
nice
benefit
to
it
is
the
the
fact
that
it
is
kind
of.
What's
what
I'm
looking
for
it.
It
is
following
that
open
standard.
I
know
google
has
a
solution.
Red
hat
ibm
has
a
solution.
I
know
there's
a
lot
of
other
companies
that
are
contributing
to
it,
but,
as
you
can
see,
it's
all
pretty
straightforward
and
there's
this
whole
list
of
how
to
do
different
things
with
build
packs
like
how
to
build
an
arm
app.
B
I've
built
a
kubernetes
cluster
on
a
series
of
raspberry
pi
4s
recently
so
well
recently
like
a
year
ago,
but
I
guess
in
the
sense
that's
still
recent.
So
if
you
want
to
build
arm
applications,
we
have
setups
for
that
there's
how
to
build
a
windows
app,
which
is
great,
if
that.
Well,
if
you
build
windows
containers,
I
don't
just
you
know
personal
choice,
but
I
know
there's
a
plenty
of
people
who
do
that,
so
it's
nice
to
have
this
option
you're
not
having
to
use
some
kind
of
third
weird
third-party
solution.
B
B
B
But
you
know
you
still
have
to
create
a
a
docker
file
stuff
to
create
a
something
like
that
which
to
some
developers
is
a
showstopper
I've
seen
some
developers,
which
is
understandable,
say
you
know.
Well,
we
don't
know
if
we
can
get
our
entire
team
to
learn
the
ins
and
outs
of
docker
files.
This
makes
life
easier.
You
get
the
build
packs,
but
then,
of
course,
how
do
I
use
the
container?
How
do
I
actually
make
it
one
thing?
Well,
techton?
B
How
do
I
make
it
one
pipeline?
How
do
I
make
it
one
deployment?
How
do
I,
how
do
I
take
my
code
from
code
to
running
and
test
in
ready
for
a
b
testing
or
whatever
techton
is
kind
of
that
middle
ground?
So
you
put
build
pack
tasks
into
your
tech
time
pipeline
and
you
you've
just
enabled
your
developers
to
build
containerized
applications
without
actually
knowing
a
thing
about
containers.
B
If
there
are
any
more
questions,
I
will
be
happy
to
answer
them
and
I
will
put
in,
like
I
mentioned
earlier,
I
will
put
in
a
slide
that
has
a
bunch
of
different
resources
for
anybody
who
wants
to
learn
more.
You
can
also
just
hit
me
up
on
twitter
linkedin,
whatever
I
love
talking
to
people
but
yeah.
This
is
a
somebody
introduced
me
to
build
packs
a
while
ago,
and
I've
been
having
fun
playing
with
them.
B
Yes,
so
yes,
and
no
to
the
question
about
contekton,
also
act
as
an
argo,
cd,
flux,
alternative.
Yes,
you
can
use
event
triggers
to
trigger
a
pipeline,
build
because
something
was
pushed
to
a
repo.
However,
I
have
actually
seen
people
use
argo
and
tecton
together
to
build
a
pipeline.
So
more
of
the
integration
stuff
is
done
on
the
tecton
side
in
terms
of
integrating
the
code,
but
because
of
some
specific
use
cases,
let's
say
canary
analysis
or
whatnot.
B
People
will
use
flux
or
cd
to
do
the
actual,
continuous
deployment,
the
actual
cd
portion.
So
you
can
do
it
all
the
the
entire
ci
cd
portion
with
tecton
or
you
can
kind
of
piecemeal
together
using
tecton
with
argo,
cd
or
flux,
or
some
other
tooling,
integrating
one
into
jenkins
that
existing
whatever
existing
pipelines.
You
have.
B
There
we
go,
have
you
seen
tecton
being
used
for
non-cicd
purposes?
I
personally
haven't.
I
have
kind
of
heard
that
they
exist,
but
I
personally
have
not
tried
it
or
seen
it
used
myself
and
like
a
project,
though
I
have
seen
people
using
it.
I
have
heard
of
people
using
it
for
other
things,
because
again
it's
it
is
not
like
a
tool
as
much
as
it
is
a
what's
what
I'm
looking
for
the
building
blocks
to
build
a
tool,
so
in
theory
you
could
use
it
to
automate
a
bunch
of
different
things.