In Chapter 3, Developing Dockerized .NET Framework and .NET Core Applications, I built the replacement NerdDinner home page as an ASP.NET Core web application, and in this chapter, I have the REST API and the Elasticsearch message handler as .NET Core applications. These can be packaged as Docker images, using variants of the microsoft/dotnet image on Docker Hub.

The Dockerfile for the REST API dockeronwindows/ch05-nerd-dinner-api:2e is very simple: it just sets up the container environment and then copies in the published application from the builder image:

# escape=`
FROM microsoft/dotnet:2.1-aspnetcore-runtime-nanoserver-1809

EXPOSE 80
WORKDIR /dinner-api
ENTRYPOINT ["dotnet", "NerdDinner.DinnerApi.dll"]

COPY --from=dockeronwindows/ch05-nerd-dinner-builder:2e C:dinner-api .

The Dockerfile for the message handler dockeronwindows/ch05-nerd-dinner-index-handler:2e is even simpler—this is a .NET Core console app, so there are no ports to expose:

# escape=`
FROM microsoft/dotnet:2.1-runtime-nanoserver-1809

CMD ["dotnet", "NerdDinner.MessageHandlers.IndexDinner.dll"]

WORKDIR /index-handler
COPY --from=dockeronwindows/ch05-nerd-dinner-builder:2e C:index-handler .

The content is very similar to the .NET Framework console app used for the SQL Server message handler. The differences are the FROM image; here, I'm using the .NET Core runtime image and the CMD instruction, and here it's the dotnet command that is running the console application DLL. Both the message handlers use the builder image as the source for copying the compiled application, and then set up the environment variables and startup commands they need.

Both the .NET Core applications are bundled with default configuration values in appsettings.json, which can be overridden at container runtime using environment variables. These capture the URLs for the message queue and the Elasticsearch API, and the connection string for the SQL Server database. The startup command runs the .NET Core application. ASP.NET Core apps continue running in the foreground until the application is stopped. The .NET Core console app for the message handler stays alive in the foreground with a ManualResetEvent object. Both write log entries to the console, so they integrate well with Docker.

When the index handler application runs, it will listen for messages from NATS, with the dinner-created message subject. When events are published from the web application, NATS will send copies to every subscriber, so the SQL Server save handler and the Elasticsearch index handler will both get copies of the event. The event message contains enough detail for both handlers to operate. If a future feature requires more detail, then the web app can publish a new version of the event with additional information, but the existing message handlers will not need to change.

Running another container with Kibana will complete this feature and add self-service analytics to NerdDinner.