Separating dependencies

In the last chapter, I dockerized the legacy NerdDinner app and got it running but without a database. The original application expected to use SQL Server LocalDB on the same host where the app is running. LocalDB is an MSI-based installation, and I can add it to the Docker image, just by downloading the MSI and installing it with RUN commands in the Dockerfile. But this means that when I start a container from the image, it has two functions hosting a web application and running a database.

Having two functions in one container is not a good idea; what would happen if you wanted to upgrade your website without changing the database? Or, what if you needed to do some maintenance on the database, which didn't impact the website? What if you need to scale out the website? By coupling the two functions together, you've added a deployment risk, test effort, and administration complexity and reduced your operational flexibility.

Instead, I'm going to package the database in a new Docker image and run it in a separate container using Docker's network layer to access the database container from the website container. SQL Server is a licensed product, but the free variant, SQL Server Express, is available from Microsoft as an image on the Docker Hub and comes with a production license. I can use that as the base for my image, building on it to prepare a pre-configured database instance, with the schema deployed and ready to connect to the web application.

上一章目录下一章