08. Setting up and Deploying eShopOnContainers to Windows Containers

This is a draft page which will be evolving while our tests and dev regarding Windows Containers are completed. eShopOncontainers on Windows Containers is still under tests at the windows-containers-test branch.

For now, we're just adding the current "Windows Containers" support.

Windows Containers support:

Windows Server 2016 - Production Environments

• Install Docker Enterprise Edition (Docker EE)
• Designed to run apps in production
• Call Microsoft for support. If it's a Docker rather than Windows problem, they escalate to Docker and get it solved

Windows 10 - Dev Environments

• Install Docker Community Edition (Docker CE, formerly Docker for Windows)
• Support via forums/GitHub
• Can switch between Windows container development and Linux (in VM). There is no plan to drop either OS from Docker CE
• Designed for devs only. Not production

Docker might provide per incident support system for Docker Community Edition, or provide a "EE Desktop" for developers, but it's their call to do so. Not Microsoft's.

Set Docker to use Windows Container (Windows 10 only)

In Windows 10 you need to set Docker to use "Windows container" instead of Linux containers (in Windows Server 2016 Windows Containers are used by default). To do this, first you must have enabled container support in Windows 10. In "Turn Windows features on/off" select "Containers":

/img/win-containers/enable-windows-containers.png

Then right click in the Docker icon on the notification bar and select the option "Switch to Windows Containers". If you don't see this option and see the option "Switch to Linux Containers" you're already using windows containers.

Start Windows Containers

The easiest way to start the windows containers is using Powershell and use call the cli-windows/start-windows-containers.ps1 script. This script will do three things:

1. Compile all projects (calling cli-windows/build-bits.ps1)
2. Create windows images
3. Start application

If don't want to compile all projects (because you have already published them) you can pass the parameter -buildBits $false:

.\cli-windows\start-windows-containers.ps1 -buildBits $false

You can use docker-compose directly to start the containers if you want:

docker-compose -f docker-compose-windows.yml -f docker-compose.override.yml -f docker-compose.override.windows.yml up

Note: You need to use these three files in docker-compose!

RabbitMQ user and password

For RabbitMQ we are using the https://hub.docker.com/r/spring2/rabbitmq/ image, which provides a ready RabbitMQ to use. This RabbitMQ is configured to accept AMQP connections from the user admin:password(this is different from the RabbitMQ Linux image which do not require any user/password when creating AMQP connections)

If you use start-windows-containers.ps1 script to launch the containers or include the file docker-compose.override.windows.yml in the docker-compose command, then the containers will be configured to use this login/password, so everything will work.

Using custom login/password for RabbitMQ (if needed)

Note: Read this only if you use any other RabbitMQ image (or server) that have its own user/password needed.

We support any user/password needed using the environment variables ESHOP_SERVICE_BUS_USERNAME and `ESHOP_SERVICE_BUS_PASSWORD. These variables are used to set a username and password when connecting to RabbitMQ. So:

• In Linux these variables can be unset (or empty)
• In Windows these variables should be set

To set this variables you have two options

1. Just set them on your shell
2. Edit the .env file and add these variables

If you have set this images and you want to launch the containers you can use:

.\cli-windows\start-windows-containers.ps1 -customEventBusLoginPassword $true

When passing the parameter -customEventBusLoginPassword $true to the script you are forcing to use the login/password set in the environment variables instead the default one (the one needed for spring2/rabbitmq).

If you prefer to use docker-compose you can do it. Just call it without the docker-compose.override.windows.yml file:

 docker-compose -f docker-compose-windows.yml -f docker-compose.override.yml up

The localhost loopback limitation

Due to a default NAT limitation in Windows (see https://blog.sixeyed.com/published-ports-on-windows-containers-dont-do-loopback/) you can't access your containers using localhost.

Instead of localhost you can use the host's IP inside the DockerNAT, that is 10.0.75.1. If you use start-windows-containers.ps1 to start the containers the script do the needed configuration for you, but if you use docker-compose then you have to set the following environment variables:

• ESHOP_EXTERNAL_DNS_NAME_OR_IP to 10.75.0.1
• ESHOP_AZURE_STORAGE_CATALOG_URL to http://10.0.75.1:5101/api/v1/catalog/items/[0]/pic/
• ESHOP_AZURE_STORAGE_MARKETING_URL to http://10.0.75.1:5110/api/v1/campaigns/[0]/pic/

Note that the two last must be set only if you have not set them (so, if you are not using Azure Storage for the images). If you are using azure storage for the images, you can leave them.

Once these variables are set you can run docker-compose to start the containers and navigate to http://10.0.75.1:5100 to view the MVC Web app.