A web application isn’t much use if it isn’t running. We’ll 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.
Create a New Systemd Service with Ansible
We need a few tasks to add a new systemd service. Code deploys will happen later once the server is configured by Ansible. This will cause our service to fail on startup until the first deploy is done. This chicken and egg situation is addressed with some conditionals in the Ansible playbook.
Run ASP.NET Core as a Systemd Service
Each service managed by systemd has its own “unit” file which describes how the service should work. Our service file was largely copied from the Microsoft .NET Core with NGINX documentation.
NOTE: We run our application as root in the service file. We shouldn’t do this but did anyway to keep moving forward. Using root fixed file permission errors caused during startup of our single-file app. This is a known issue in .NET Core 3.1 which will be addressed in a service release.
The application is now properly hosted on our Linux server. NGINX will front requests from the public internet and systemd will ensure our application stays running.
Next we’ll install Redis using a pre-built role from Ansible Galaxy. Also, our Ansible playbook needs some cleanup to keep things maintainable.