In my previous post about hosting an ASP.NET core application in docker for production use I fudged a little bit in terms of what it means to production-worthy. Using the dotnet run command starts the web application on the Kestral web server. Kestral is a great web server for development and maybe production use in an intranet environment but should not be exposed to the internet in a production environment.
So I started exploring how to set up a reverse proxy in docker to work with a basic asp.net core application in a docker container. There are a couple of options:
- Install the reverse proxy web server in the same container as your application, and
- Install the reverse proxy web server in a different container from your application.
These articles are the best on the web that I’ve found, and they even include SSL support which is essential these days.
Now, let me explain when I’d use each approach and why I’m using neither approach right now.
Reverse Proxy in the Same Docker Container
You could use this approach if your docker host machine is dedicated to the single dotnet application you are working on (assuming you only host one application/service per container – which is considered best practice). The advantage is that there are fewer parts to your system. Any version control/automation for your application will also extend to the reverse proxy.
Reverse Proxy in a Separate Docker Container
If you have more than one application/service running in separate docker containers on the same docker host server then you’re unable to colocate your reverse proxy in the same container as one of these applications. But if all of the applications on that host machine are in docker then you’re able to setup a separate docker container for the reverse proxy.
The advantage of this is simplified version control on your reverse proxy configuration. You can check in the dockerfile to its own git repo, automatically bulid the docker image, and deploy it automatically.
Conclusion – Manual Reverse Proxy on the Host
Let’s acknowledge that the reverse proxy configuration should change minimally over time in comparison to your asp.net application. The effort for security the host firewall is the same no matter which approach you use.
In my case, the docker hosting server is also hosting a non-docker-container application (LAMP stack). Sure I could move it into a docker container and set up a reverse proxy in a separate docker container but I don’t want to do that right now (downtime, more time not spent on the application I need to be working on).
That’s why I’ve decided to manually configure the reverse proxy on the host for the time being.