Getting to grips with Docker: Part 2 – Docker Compose

In my previous post, I sert up a very simple Docker supported web api project using a Dockerfile to determine the set up and launch. To consider the maintainability of production-deployable scenario, we can look towards Docker Compose to organise our setup.

This can be initiated in VS2019 by right-clicking on your web api project, navigate to Add then select the Container Orchestration Support option:

Select Docker Compose from the dropdown options, and then, I recommend you target Linux as the OS. This will create a new, docker-compose (.dcproj) to your solution.

If it has not automatically become the new startup project, set it to be. You should also notice that the target launch option is now set to be Docker Compose so we have switched from launching the web project in Docker mode to launching a Docker Compose project which will deploy the container and then launch its entry point. If you you hit F5 now, and monitor the output from Container Tools, you should notice that the new project also takes care of creating a network for you. When your web app launches though, you will probably find that it’s launched under a new port that you cannot find in your files or settings. That’s because the internal ports of 80 and 443 have not been explicitly mapped and so a random, free port is chosen. If you look at the docker-compose.override.yml file, you can see which ports the container is exposing. It’s here where you can map your ports:

version: '3.4'

services:
  dockerweb:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=https://+:443;http://+:80
    ports:
      - "80"
      #explicit https port set here
      - "44301:443"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro

Of course, what you declare in here may need to be different depending on the environment you are targeting and that’s where env files come in. These allow you to create environment tokens to be injected into the environment settings during release, allowing different environments to have different settings without you requiring a separate setup for development purposes. An env file is created as a .env file within the docker-compose project. Take the following development env file contents:

ASPNET_ENV=Development
EXT_PORT=40301

This can then be used by amending the override yaml as follows:

version: '3.4'

services:
  dockerweb:
    environment:
      - ASPNETCORE_ENVIRONMENT=${ASPNET_ENV}
      - ASPNETCORE_URLS=https://+:443
    ports:
      - "${EXT_PORT}:443"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro

Note, I have also removed the non secure http options as best practice. Token replacement can go one step further by creating a separate .env file as part of a deployment resource and declaring the values as tokens themselves:

ASPNET_ENV=#{DockerWeb.Environment}#
EXT_PORT=#{DockerWeb.ExtPort}#

These can then be substituted with environment variables during release (for example as part of your Azure DevOps CD pipeline). These two settings are some what a little contrived but at least demonstrate the process of token declaration and replacement.