►
From YouTube: Packaging and deploying .NET Core for Linux - Part 1
Description
In this episode, Rich sits down with Todd Gardner to talk about how his team is building their Request Metrics project. They discuss various topics such as self contained publishing, deploying to 64-bit Linux, and more
[03:35] - What not JavaScript?
[05:27] - Reviewing the architecture
[09:20] - Building and Deploying
[16:23] - .NET Core with System D
[18:16] - Declaring infrastructure with Ansible
[24:22] - Exploring the Request Metrics application
Host ASP.NET Core on Linux with Nginx
https://docs.microsoft.com/aspnet/core/host-and-deploy/linux-nginx?WT.mc_id=ondotnet-youtube-cephilli
Visual Studio publish profiles (.pubxml) for ASP.NET Core app deployment
https://docs.microsoft.com/aspnet/core/host-and-deploy/visual-studio-publish-profiles?WT.mc_id=ondotnet-youtube-cephilli
TrackJS
https://trackjs.com/
Request Metrics
https://requestmetrics.com/
The Building of Request Metrics (YouTube Channel)
https://www.youtube.com/channel/UCIklNDcnPT8_eVFM1oOoQyA/videos
A
A
Hey
welcome
to
another
episode
of
the
on.net
show
today
we're
going
to
be
talking
with
todd.
Gardner
he's
a
co-founder
of
the
track,
js
project
and
he's
going
to
be
telling
us
about
how
they're,
using
dynacore
and
how
they're
packaging
and
deploying
their
app
and
dynacore
on
linux.
Hey
todd
thanks
for
joining
us
and
how
about
you
introduce
yourself
and
then
we'll
get
into
the
topic
sounds.
B
B
B
B
A
I
I
understand
working
on
a
real
project
myself.
I
understand
how
to
deal
with
like
constraints
and
requirements
and
deadlines
and
all
those
kinds
of
things.
Just
one
one
more
question
before
we
get
into
you
know
you
show
us
what
you've
actually
been
doing,
which
is
you
know
you
clearly
have
a
lot
of
experience
with
javascript.
Why
didn't
you
just
use
node.js
on
the
server
and
call
it
a
day.
B
Yeah,
that's
a
that's
a
really
good
question
so
when
you're
writing
something
for
the
web
when
you're
building
a
web
application
that
needs
to
be
super
interactive
and
you
know,
respond
to
user
actions.
It's
really
javascript
is
your
only
option.
You
can't,
like
you
know,
there's
not
a
plethora
of
development
languages
that
you
can
run
and
you
know
have
executed
by
every
browser
on
the
face
of
the
planet.
You
really
have
to
write
it
in
javascript,
so
you're
kind
of
forced
down
that
path.
B
But
when
you
get
to
write
something
on
the
server
when
you're
going
to
get
into
like
you
know,
html
rendering
or
data
processing
or
that
sort
of
thing,
I
have
a
lot
more
options
and
javascript
is
good
at
a
lot
of
things.
But
it's
not
good
at
everything,
and
you
know
the
static
typing
that
you
get
the
the
benefits
of
link
the
benefits
of
performance,
there's
so
many
benefits
of
writing.
C-Sharp,
especially
now
that
I
can
run
it
on.net
core
and
deploy
it
on
linux.
B
B
Yeah
yeah,
so
today
I
wanted
to
talk
a
little
bit
about
how
we,
how
we
build
and
deploy
our.net
core
application
onto
our
linux
servers,
which
is
something
that
we
covered
in
one
of
our
earlier
video
series.
So
if
you
want
to
watch
us
like
bang
our
head
against
the
wall
and
figure
out
how
this
actually
is
working,
there's
a
whole
like
hour,
or
I
think
it's
probably
35
minute
long
video
about
it.
But
I'm
going
to
show
you
like
how
we
actually
got
it
working
and
how
the
whole
thing
fits
together.
B
All
right.
So
here
is
a
high
level
of
the
design
that
we
started
with
for
request,
metrics
and
how
this
fits
in
at
at
the
top.
We
in
we
have
this
javascript
agent
that
we're
going
to
install
into
our
our
customers
web
applications
so
that
that
agent
will
go
out
to
the
end
user
and
it
will
gather
how
long
did
their
pages
take
to
load.
How
long
did
their
apis
take
to
return?
B
You
know:
what's
the
breakdown
between
dns
time
and
ssl
time,
and
all
that
all
that
good
information
and
we're
going
to
funnel
that
information
back
to
us
and
capture
it
with
an
nginx
server.
Nginx
is
like
super
fast,
like
front
end
web
server
that
can
handle.
You
know
caching
and
handling
those
requests.
B
It's
real-time-ish
so
essentially
it's
a
linux
service
that
is
a
executable,
that's
just
doing
a
a
while
loop,
just
an
infinite
loop
and
so
on
different
timers.
It
will
do
different
actions,
but
it's
essentially
once
in
once
a
minute.
It
will
look
for
those
log
files
and
do
a
bunch
of
of
logic
to
figure
out
what
we
need
to
pull
out
of
it.
How
do
we
coalesce
it
and
save
it
into
redis?
It
has
a
few
other
jobs.
A
B
So
the
other
bit
is
the
reporting
ui,
which
is
an
asp.net
application
that
you
know
talks
to
that
redis
system
and
produces
all
the
you
know,
reports
and
you
know
login
functionalities
and
settings
and
all
of
those
other
things
that's
just
going
to
be
running
using
the
built-in
like
kestrel
web
server,
that
comes
with
net.
But
we
front
that
with
nginx,
so
that
we
can.
A
Makes
sense
one
thing
to
clarify:
is
that
that's
all
fine
and
make
sense,
but
there
is
definitely
this
one
misperception
early
days
we
did
tell
people
that
kestrel
was
not
kind
of
public
internet
facing
grade
and
we
did
not
support
it
in
that
way.
I
think,
since
2.1
we
have
supported
kestrel
as
a
public
internet
facing
server.
So
that's
not
a
commentary
on
what
you're
doing,
but
it's
just
a
good
point
place
to
insert
that
that
that
guidance
and
information.
A
B
It
necessary
in
this
architecture
for
sure
cool
all
right,
so
that's
kind
of
it
for
this.
So
let's
take
a
look
at
how
we
actually
built
this.
This
was
you
know
our
sketch
of
you
know
our
roadmap
of
where
we're
gonna
go
and
then
over.
You
know
the
matter
of
a
couple
of
days
or
weeks.
We've
we've
built
a
lot
of
this
in
place,
and
so
I'd
like
to
show
you
kind
of
the
high
notes
of
how
we
package
and
deploy
this
and
get
this
thing
actually
running.
B
Okay,
let's
do
it
cool,
so
here
is
our
solution,
so
we're
I'm
running
on
a
mac,
as
you
can
probably
tell
which,
by
the
way
I
love.
I
love
that
I
can
do
my
development
without
having
to
like
run
inside
of
a
vm
anymore.
It
is,
it
is
amazing,
it
is
a
game.
Changer
our
project
or
our
solution
is,
is
fairly
simple.
B
The
magic
of
our
our
publish
and
deployment
on
from
the
code
site
is
really
all
contained
in
this
file,
our
published
profile.
So
we
have
a
production,
published
profile
for
our
web
project
and
our
processor
project
and
there's
a
couple
of
bits
in
this
that
are
what's
interesting.
The
first
is
first
we're
targeting
linux
x64.
This
is
where
we're
actually
running
we're
not
running
this
on
windows,
we're
running
it
on
linux
and
we
get
a
bunch
of
like
benefits
with
our
infrastructure
automation.
B
By
doing
that,
the
second
bit-
that's
really
really
been
helpful
to
us-
is
this
self-contained
property
which,
as
I
understand
it,
allows
us
to
basically
bake
in
the
version
of
net
core
that
we're
using
as
part
of
this
as
part
of
our
deployment,
and
so
it
becomes
like
this.
Was
always
one
of
the
things
that
was
really
like
fascinating
to
me
about
go
right?
B
Was
that
you,
if
you
were
building
like
a
go
app,
you
could
compile
it
down
and
just
be
an
executable,
and
there
was
done
you
didn't
have
to
install
like
a
java
runtime,
you
didn't
have
to
install
the.net
framework.
You
didn't
have
to
do
any
of
that.
It's
just
like
here.
It's
done,
it's
ready
to
go,
and
I
think
this
is
amazing
and
it
really
simplified
a
bunch
of
our
infrastructure
deployment
by
not
needing
to
figure
out
how
to
get
the
right
version
and
how
to
keep
them
in
sync.
B
I
think
that's
really
the
the
magic
here
there's
no
there's
nothing
else.
That
was
really
all
that
strange
other
than
to
simplify.
You
know
pushing
things
over
the
wire
we
did.
We
opted
for
published
single
file,
which
you
probably
actually
know
more
about
this
than
than
I
do,
but
the
published
single
file
basically
means
it
all
came
down
into
just
a
single
file
like
there.
It
wasn't
you
know
dozens
of
dlls
stripped
out
over.
You
know
a
nested
directory
structure.
We
just
get
a
file.
A
B
B
It
we
publish,
we
publish
single
file,
we
publish
contained,
and
it's
also
going
out
to
linux,
so
how
this
actually
works.
You
know
when
we
actually
run.
This
thing
is
for
our
our
build
and
deploy
process
we're
using
teamcity
and
here's
all
of
our
different
jobs
that
we're
doing
with
with
teamcity
and
the
request
metrics
build,
which
is
this
guy
down
here
after
it's
all
said
and
done.
This
is
what
it
produces
after
it's
done
packaging
package,
everything
up.
B
We
have
this
one
file
here
for
web,
which
got
a
little
bit
bigger
than
the
last
checked
122
megs,
and
we
have
our
processor
file,
which
is
110,
and
so
those
are
our
two
things.
Those
are
the
two
main
things
that
need
to
get
out
in
order
for
everything
else
to
to
work
and
run,
and
so
when
we
deploy
that
we
deploy
that
from
here
as
well,
and
it's
pretty
simple
what
what
I
think
we
do.
Our
build
steps
basically
are.
B
We
we
just
zip
up
the
whole
directory
using
7-zip.
We,
we
tar
it
it's
very
old-school
kind
of
way
of
doing
things,
but
it
works
pretty
reliably.
We,
you
know,
dump
it
out
into
the
server
and
then
we
extract
it.
We
we
pull
the
whole
thing
apart,
dump
it
into
the
directory
that
we
expect
things
to
be
running
in
set
their
set
their
ownership
permissions
and
then
remove
the
garbage
if
it
is
in
order
for
it
to
run
in
order
for
it
to
to
get
everything
kick-started.
A
B
That
is
kind
of
our
overall
development
philosophy
is
there's
a
lot
of
there's
a
lot
of
new
ways
of
doing
things
that
provide.
You
know,
benefits
in
some
circumstances,
but
the
old
stuff
works
really
really
well,
and
so
sometimes
it's
just
about
you
know:
sc
like
copy
a
file
into
the
right
directory,
restart
the
service.
A
B
B
But
the
deployment
of
the
of
the
processor
is
nearly
identical.
It's
about.
You
know
we
zip
up
all
the
contents
of
the
output
we
send
it
up
into.
We
send
it
up
into
a
known
directory
structure,
and
then
we
extract
it
out
and
put
it
into
a
processor
directory
that
we're
expecting
it
to
run
in
and
restart
an
underlying
system
d
process
called
requestmetrics.processor,
and
so
this
allows
us
to
change
the
files
of
our
our
ingestion
pipeline
in
the
same
sort
of
way,
which
I
think
is
really
really
powerful
for
us.
A
B
We
ended
up
punting
on
this
for
now
and
moving
on
to
other
things,
you
can
see
that
right
now
that
service
just
runs
as
root,
which
is
not
ideal
and
is
on
our
list
of
things
to
fix,
but
we
could,
when
we
first
attempted
this
and
you'll
see
some
of
our.
You
know
faffing
about
trying
to
get
this
thing
to
work
in
our
videos,
for
it
we're
trying
to
get.
You
know
all
of
our
services
running
as
our
service
account
id,
but
no
matter
what
we
did.
B
We
couldn't
get
the
the
service
to
run
with
under
that
under
that
id,
the
permissions
of
all
the
directories
that
we
found
like
we
said
everything
and
it
just
would
not
run.
We
did
find
a
couple
of
links
to
like
bug
tickets
in.net
core
about
that,
but
we
couldn't
quite
tell
what
the
status
of
them
were.
So
we
decided
to
move
on
for
now.
Okay,.
A
B
B
B
B
A
B
B
Exactly
and
so
we
have
tons
of
other
stuff
in
here,
we
configure
everything
in
here
we
configure
our.
We
have
an
elastic
search
instance
that
we
use
for
logging.
We
have
our
main
redis
instance.
We
have
some
core
linux
things
that
we
do.
We
have
our
monitoring
that
we
put
in
here,
but
the
the
core
of
the
service
is
here
contained
in
this
rm
app
role.
B
The
other
half
of
this
is
how
we
configure
nginx
itself
and
nginx
itself
just
needs
to
know
how
to
pass
through
to
it,
and
so,
as
part
of
configuring,
that
we
drop
a
an
engine
fig
on
the
server
which
looks
like
this.
If
you've
ever
worked
with
nginx
it's,
this
is
kind
of
how
their
configuration
files
look,
and
it's
basically
just
this
block
right
here.
B
It's
saying:
hey
we're
going
to
listen
on
http
2
ssl
we're
going
to
listen
if
you're
talking
to
the
request,
metrics
application,
url,
here's
our
certificate
information
and
we're
just
going
to
proxy
pass
this
out
to
our.net
application,
which
is
configured
here,
and
so
this
all
happens.
You
know,
within
the
same
box
super
fast
off
and
running.
A
Makes
sense
so
one
thing
I
haven't
seen
yet
is
so
by
virtue
of
publishing
a
self-contained.
You
know
you
skip
having
to
reason
about
deploying
dynacore
itself.
Yeah
dynacorp
does
have
dependencies
like
openssl,
for
example.
Where
do
you
I
would
expect?
Actually
I
I
guess
I
never
asked
you
which
os
you're
running
on,
but
I'd
expect,
like
you
know
some
apt-get
or
yum,
or
you
know,
dnf
calls
depending
on
which
os
distro
you're
running
on.
B
We're
running
ubuntu
long
term
support,
I
think
that's
1404
or
1606,
I'm
not
really
sure
which
one
and
then,
as
part
of
installing
all
of
the
other
stuff
as
part
of
getting
nginx
running.
We
we
have
all
of
the
dependencies
in
it,
so
we
don't
declare
them
directly,
although
maybe
we
should
that.
Might
that
might
be
a.
I
I'd
reckon
I'd
recommend.
A
B
A
B
B
Now
that
we're
logged
in
to
request
metrics,
I'm
going
to
give
you
just
a
brief
overview
of
like
what
we're
actually
doing
with
this.
This
is
all
very
rough,
still
we're
still
actively
in
construction,
we're
a
couple
of
weeks
out
before
delivering
and-
and
we
have
a
lot
of
css
and
design
work
left
to
do
request.
Metrics
is
going
to
allow
you
to
you,
know,
capture
multiple
applications.
B
So
if
we
take
a
look
at
our
performance
of
the
track,
gsweb
site,
it's
going
to
start
producing
some
of
these
reports.
Now
that
remember,
this
is
a
net
app
we're
rendering
most
of
this
on
the
server
side,
using
a
little
bit
of
preact
on
the
front
end
to
handle
some
interactivity
and
chart.
You
know
logic,
but
by
far
the
majority
of
this
is
running
in
in.net
core
on
those
servers.
B
So
we're
looking
at
the
last
24
hours
of
data
from
real
users
who
visited
trackjs.com
and
the
performance
that
they
experienced
while
they
were
there,
we're
charting,
like
the
average
duration
of
how
long
the
site
took
to
load
and
then
breaking
down.
What
were
the
slowest
pages
on
your
site
and
what
were
the
busiest
pages
we'll
automatically
do
some
like
url
collapsing,
so
that
like,
if
you
have
a
product
details,
page
or
urls,
with
unique
ids
and
then
we'll
strip
those
out?
B
If
we
look
at
an
individual
page
like
people
who
went
to
trackjs.com,
we
can
get
like
a
lot
more
detail,
so
we're
producing
these
flame
charts
that
show
you
a
breakdown
of
more
detailed
experience.
So
you
know
how
many
people
had
an
experience
of
less
than
100
milliseconds,
so
an
almost
instant
page
load
time,
it
looks
like
our
average.
Is
closer
to
between
one
and
one
and
a
half
seconds,
and
then
how
many
people
maybe
had
a
really
bad
experience
loading?
B
B
A
B
B
Right
and
so
that's
that's
the
bit
that
we're
working
on
actively
right
now,
which
is
our
alerting
subsystem
and
what
the
alerting
subsystem
is
going
to
be
able
to
do
is,
is
going
to
look
at
the
historical
trends
of
your
data
and
notice
when
things
are
changing.
So
if
we
just
visually
look
at
this
report,
it
looks
like
right
around
the
start
of
the
of
the
next
day.
Something
changed
right.
B
The
the
number
of
requests
went
up
but
like
there
there's
just
the
distribution
of
performance
seems
to
have
adjusted
we're
building
different
kinds
of
alerts
in
our
system,
so
that
we
can
notify
property
owners
or
website
teams
when,
when
these
sort
of
changes
can
occur
so
that
we're
trying
to
make
it
request,
metrics
a
tool
that
you
rarely
ever
have
to
log
into.
But
you
still
depend
on
because
you
need
the
alerts
that
you
get
from
us.
B
So
we'll
funnel
those
out
to
you
that
hey
the
performance
of
your
page
has
degraded
in
this
way,
and
it's
never
done
that
before,
so
that
you
can
look
into
into
those
sort
of
things
and
respond
to
them
makes
sense,
which
you
know
frankly,
is
the
kind
of
of
technology
that
you
know.
Big
enterprise
teams
have
had
forever
right.
You
know
a
lot
of
these.
Things
have
been
available
through
tools
from
from
microsoft
and
new
relic
and
splunk,
and
you
know
all
of
the
big
you
know.
B
A
Yep
makes
sense,
so
you've
kind
of
shown
us
the
whole
kind
of
the
experience
from
like
you
know,
your
initial
choice
to
how
this
is
your
app.
Your
apps
are
built
to
how
they're
deployed
with
ansible,
and
now
we
actually
see
the
the
fruits
of
your
labor
with
this.
What
else
do
you
wanna?
Do
you
wanna
tell
us
or
show
us
before
you
close.
A
A
B
Yeah,
so
we
haven't
launched,
request
metrics
yet,
but
so
far
we
are
incredibly
happy
with
the.net
core
development
experience
and
deploying
to
linux
that
experience
it
wasn't.
It
wasn't
completely
smooth
right.
There
was
still
like
a
couple
of
hiccups.
We
ran
into
along
the
way,
but
it
has
no
more
than
I
would
expect
with
any
development
platform.
B
It
worked.
It
works
stable.
It's
never
failed
in
a
way
that
wasn't
detectable
right,
because
that's
all
that's
always
the
scary
thing
is
when
things
are
breaking
and
you
have
no
idea
why
and
there's
nothing
in
the
logs
like
when
things
have
gone
wrong
for
us.
It's
always
because,
oh
we
misconfigured
this
yeah.
A
A
Sense:
okay!
Well,
thanks
for
coming
by
and
showing
this,
you
know,
I
love
seeing
a
real
application
being
built
with
the
platform
and
all
you
know
also.
You
know
you
made
a
series
of
choices
that
will
resonate
a
ton
with
with
at
least
some
people
and
they'll
be
like
okay.
I
was
thinking
about
doing
it
this
way.
This
is
validation
that
that
actually
proves
out,
and
at
least
made
todd
happy.
So
yeah,
thanks
for
coming
by
thanks.