We thought we were done with infrastructure work. We were wrong. Just as we’ve started work on application code, it turns out our server configuration needs a couple changes. Our application loads its environment config based off of an environment variable. We need to ensure this variable is actually set on the server. We also want to fix our Ansible playbook which fails when run on fresh servers.
Use Systemd to Set an Environment Variable Specifying Dev/Prod
Our ASP.NET Core application needs to know which environment it is running in order to load the proper configuration. The application looks for an environment variable named
WHAT_ENVIRONMENT_AM_I which is used to select the correct configuration. The variable is specified in the systemd unit file which is more contained than setting it globally:
Fix Ansible Failure When Service Executable Does Not Exist
We have a chicken and egg problem when provisioning brand new servers. Our .NET Core app’s systemd service is configured through Ansible. Ansible fails to start the service when code has never been deployed to the new server.
The playbook checks for the application’s binary before starting the service to avoid the error. The service is still configured ahead of time to ensure the server is ready to go when the first code deploy happens.
These are both little changes, but polish makes all the difference. Now our Ansible playbooks work when spinning up entirely fresh machines and our application knows what environment it’s running in! Next, we’ll get back to code and explore how to do unit testing with .NET Core.