A web application isn't much use if it isn't running. We hand in our neckbeard cards and copy+paste our way out of the problem. Last episode, we configured NGINX to act as a reverse proxy for our Asp.Net Core application. We tested our setup by manually running the .Net Core app from an SSH session. Today we'll fix that stop-gap step by running our application as a service with systemd. We'll add the new service by running a few tasks in Ansible.

ASP.NET Core applications have a built-in webserver called Kestrel. This internal webserver is not intended to serve requests directly. It must be placed behind a production quality webserver such as NGINX or IIS. We use Ansible to provision NGINX on our Linux server.

It's time to provision our Request Metrics server. There is some common configuration that applies to all Linux servers. We want this base configuration regardless of what that specific server is doing. This a great use case for an Ansible role. Our "linux-common" role includes these among other things:

Purchasing a certificate can be the simplest way to get an SSL certificate. Even though it's simple, there are a fair number of steps in the process. Let’s shell out some money to “the man” and stumble through those steps!

SSL support is table stakes for any modern website. Browsers and search engines penalize un-encrypted websites to such an extent that SSL is necessary just to participate in the modern web. In many cases it is a quick, easy option for configuring SSL. Let's Encrypt is held up as a one-size-fits-all solution to everything SSL, but there are downsides. Situations differ between applications and LE is not always the best fit. Let’s Encrypt isn't a fit for Request Metrics. For now, we’ll buy a certificate like grumpy old men.

We're ready to deploy our code to a Linux based development environment. Previously, we built our code in TeamCity and stored the artifacts. We also created an SSH key for our development server. Now, TeamCity can deploy artifacts to the server using SSH.

Request Metrics is a web performance tool that records how fast your production Page and API endpoints are from your users’ perspective. We are doing something a bit different as we build Request Metrics: all our development sessions are recorded! Follow along as we work our way towards the Version 1 release. We’ll edit out the wrong turns and dead ends, saving you the time we lost along the way.

Development on Request Metrics begins! Before we can write any fun, (hopefully) money making code, we need to get some unexciting ground work out of the way. First on the list: making a new project in Visual Studio 2019.

The unexciting ground work for Request Metrics continues. We've got a basic ASP.NET Core project up and committed to Github. Now we need to build it! We have used TeamCity to build TrackJS for years. Since we don’t like change, we’re using it for Request Metrics too.

In the previous video, we created a build for our new project. Now we are configuring access to the development server using SSH keys. Follow along as we create a new SSH key pair using Git Bash. We'll use PuTTY and the new key to SSH to our Linux server from a Windows machine. Generating a new SSH key is not too difficult, but there are a few gotchas when using Windows. We are going through this exercise because Eric and Jordan develop on Windows. Todd watches in amusement as his MacOS machine "just works".