The web application now publishes messages, and a handler listens for them, so the final component I need is a message queue to connect the two. Queues need the same level of availability as the rest of the solution, so they're good candidates for running in Docker containers. In a distributed solution that is deployed on many servers, the queue can be clustered across multiple containers for performance and redundancy.
Your choice of messaging technology depends on the features you need, but there are plenty of options with .NET client libraries. Microsoft Message Queue (MSMQ) is the native Windows queue, RabbitMQ is a popular open source queue that supports durable messaging, and NATS is an open source in-memory queue that is hugely performant.
The high throughput and low latency of NATS messaging makes it a good choice to communicate between containers, and there is an official image for NATS on Docker Hub. NATS is a Go application that runs cross platform, and there are Linux, Windows Server Core, and Nano Server variants of the Docker image.
You run the NATS message queue like any other container. The Docker images exposes port 4222, which is the port that clients use to connect to the queue, but you don't need to publish that port unless you want to send messages to NATS outside a Docker container. Containers in the same network can always access one another's ports, and they only need to be published to make them available outside Docker. The NerdDinner web app and message handler are using the server name message-queue to connect to NATS, so that needs to be the container name:
docker container run --detach `
--name message-queue `
dockeronwindows/ch05-nats:2e
The NATS server application logs messages to the console so that the log entries are collected by Docker. When the container is running, you can verify that the queue is listening using docker container logs:
> docker container logs message-queue
[7996] 2019/02/09 15:40:05.857320 [INF] Starting nats-server version 1.4.1
[7996] 2019/02/09 15:40:05.858318 [INF] Git commit [3e64f0b]
[7996] 2019/02/09 15:40:05.859317 [INF] Starting http monitor on 0.0.0.0:8222
[7996] 2019/02/09 15:40:05.859317 [INF] Listening for client connections on 0.0.0.0:4222
[7996] 2019/02/09 15:40:05.859317 [INF] Server is ready
[7996] 2019/02/09 15:40:05.948151 [INF] Listening for route connections on 0.0.0.0:6222
The message queue is an infrastructure-level component with no dependencies on other components. It can be started before other containers and left running when application containers are stopped or upgraded.