You make config objects available to containers when you create the service, using the --config option. You should then be able to use them directly in your application, but there may be a catch. When config objects are presented as files to the container, they're secured so only administrative accounts can read them. If your application is running as a least-privileged user, it can see the config file, but it can't read it. This is a security feature, intended to keep your configuration files safe if someone gains access to the filesystem in the container.
This is different in Linux containers, where you can specify the ID of the user who has file ownership inside the container, so you can give least-privileged accounts access to the file. Windows containers don't support that feature, but Windows containers are evolving to be feature-complete with Linux containers, so this should come in a future release. At the time of writing, to use config objects, the application needs to be running as an administrator account, or as an account with local system access.
I've updated the Dockerfile for the REST API from Chapter 5, Adopting Container-First Solution Design, to use the built-in admin account in the container:
# escape=`
FROM microsoft/dotnet:2.1-aspnetcore-runtime-nanoserver-1809
EXPOSE 80
WORKDIR /dinner-api
ENTRYPOINT ["dotnet", "NerdDinner.DinnerApi.dll"]
USER ContainerAdministrator
COPY --from=dockeronwindows/ch05-nerd-dinner-builder:2e C:dinner-api .
All that's changed is the USER instruction, which sets the user for the rest of the Dockerfile and for container startup. The code is exactly the same: I'm still using the builder image from Chapter 5, Adopting Container-First Solution Design. I've built this new image as dockeronwindows/ch07-nerd-dinner-api:2e, and I can upgrade my running API service and apply the new configuration with docker service update:
docker service update `
--config-add src=nerd-dinner-api-config,target=C:dinner-apiconfigconfig.json `
--image dockeronwindows/ch07-nerd-dinner-api:2e `
nerd-dinner-api;
Updating a service replaces the running replicas with the new configuration, in this case, using a new image and applying the config object. Now when I make a GET request to the REST API, it's logging at an information level, and I can see a lot more detail in the service logs:
> docker service logs nerd-dinner-api
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | Hosting environment: Production
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | Content root path: C:dinner-api
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | Now listening on: http://[::]:80
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | Application started. Press Ctrl+C to shut down.
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | Request starting HTTP/1.1 GET http://api.nerddinner.swarm/api/dinners
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
nerd-dinner-api.1.cjurm8tg1lmj@win2019-02 | Route matched with {action = "Get", controller = "Dinners"}. Executing action NerdDinner.DinnerApi.Controllers.DinnersController.Get (NerdDinner.DinnerApi)
You can use this approach for feature flags and behavior settings that change between environments. It's a really flexible approach to application configuration. Developers using a single Docker Engine can run the container with the default settings in the image, or override them with environment variables, or replace the whole config files by mounting a local volume. In test-and-production environments using Docker Swarm, admins can manage configuration centrally with config objects—still using the exact same Docker image in every environment.