Now I have a database image that can work for new deployments and for upgrades. The image can be used by developers who might run it without mounting a volume while they're working on a feature, so they can start with a fresh database every time they run a container. And the same image can be used in environments where the existing database needs to be preserved by running the container with a volume that contains the database files.

This is how you run the NerdDinner database in Docker, using the default administrator password, with a host directory for the database files, and naming the container so that I can access it from other containers:

mkdir -p C:databases
d

docker container run -d -p 1433:1433 ` --name nerd-dinner-db ` -v C:databases
d:C:data ` dockeronwindows/ch03-nerd-dinner-db:2e

The first time you run this container, the Dacpac will run to create the database, saving the data and log files in the mounted directory on the host. You can check whether the files exist on your host with ls, and the output from docker container logs shows the generated SQL script running, and creating resources:

> docker container logs nerd-dinner-db
VERBOSE: Starting SQL Server
VERBOSE: Changing SA login credentials
VERBOSE: No data files - will create new database
Generating publish script for database 'NerdDinner' on server '.SQLEXPRESS'.
Successfully generated script to file C:initdeploy.sql.
VERBOSE: Changed database context to 'master'.
VERBOSE: Creating NerdDinner...
VERBOSE: Changed database context to 'NerdDinner'.
VERBOSE: Creating [dbo].[Dinners]...
...
VERBOSE: Deployed NerdDinner database, data files at: C:data

The docker container run command I used also publishes the standard SQL Server port 1433, so you can connect to the database running inside the container remotely through a .NET connection, or with SQL Server Management Studio (SSMS). If you already have a SQL Server instance running on your host, you can map the container's port 1433 to a different port on the host.

To connect to the SQL Server instance running in the container with SSMS, Visual Studio, or Visual Studio Code, use localhost as the the server name, select SQL Server Authentication, and use the sa credentials. I use SqlElectron, which is a very lightweight SQL database client:

Then, you can work with the Dockerized database just like any other SQL Server database, querying tables and inserting data. From the Docker host machine, you use localhost as the database server name. By publishing the port, you can access the containerized database outside of the host, using the host machine name as the server name. Docker will route any traffic on port 1433 into SQL Server running on the container.