Deploy to Windows containers
This is a draft page which will be evolving while our tests and dev regarding Windows Containers are completed.
CONTENT
- Supported platforms
- Set Docker to use Windows Container (Windows 10 only)
- The localhost loopback limitation in Windows Containers Docker hosts
- Deploy Windows Containers of eShopOnContainers
- Test/use the eShopOnContainers MVC app in a browser
- RabbitMQ user and password
- Using custom login/password for RabbitMQ (if needed)
Windows 10 - Development Environment:
- 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
Windows Server 2016 - Production Environment:
- 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
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.
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":
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.
Due to a default NAT limitation in current versions of Windows (see https://blog.sixeyed.com/published-ports-on-windows-containers-dont-do-loopback/) you can't access your containers using localhost from the host computer.
You have further information here, too: https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/
Although that limitation has been removed beginning with Build 17025 (as of early 2018, still only available today to Windows Insiders, not public/stable release). With that version (Windows 10 Build 17025 or later), access to published container ports via “localhost”/127.0.0.1 is available.
Until you can use newer build of Windows 10 or Windows Server 2016, instead of localhost you can use either an IP address from the host's network card of (for example, let's suppose you have the 192.168.0.1 address) or you could also use the DockerNAT IP address, that is 10.0.75.1. If you don't have that IP (10.0.75.1) shown when you get the info with ipconfig, you'll need to switch to Linux Containers so it creates that Docker NAT and then go back to Windows Containers (right click on Docker icon on the task bar).
If you use start-windows-containers.ps1 to start the containers, as explained in the following section, that script will create environment variables with that IP for you, but if you directly use docker-compose, then you have to set the following environment variables:
Where you see 10.75.0.1 you could also use your network card IP discovered with ipconfig, or a production DNS name or IP if this were a production deployment.
-
ESHOP_EXTERNAL_DNS_NAME_OR_IPto10.75.0.1 -
ESHOP_AZURE_STORAGE_CATALOG_URLtohttp://10.0.75.1:5101/api/v1/catalog/items/[0]/pic/ -
ESHOP_AZURE_STORAGE_MARKETING_URLtohttp://10.0.75.1:5110/api/v1/campaigns/[0]/pic/
Note that the two last env-vars must be set only if you have not set them already because you were using Azure Storage for the images. If you are using azure storage for the images, you don't need to provide those URLs.
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.
Using start-windows-containers.ps1 is simpler as it'll create the env-vars for you.
Since eShopOnContainers is using Docker Multi-Stage builds, the compilation of the .NET application bits is now performed by Docker itself right before building the Docker images.
Although you can create the Docker images when trying to run the containers, let's split it in two steps, so it is clearer.
In order compile the bits and build the Docker images, run:
cd <root-folder-of--eshoponcontainers>
docker-compose -f docker-compose.yml -f docker-compose.windows.yml buildNote Be sure to pass both -f when building containers for windows containers!
The easiest way to run/start the Windows Containers of eShopOnContainers is by running this PowerShell script:
start-windows-containers.ps1
You can find this script at /cli-windows/start-windows-containers.ps1
Otherwise, you could also run it directly with docker-compose up but then you'd be missing a few environment variables needed for Windows Containers. See the section below on the environment variables you will also need to configure.
Under the covers, in any case, the start-windows-containers.ps1 is running this command to deploy/run the containers:
set ESHOP_OCELOT_VOLUME_SPEC=C:\app\configuration
docker-compose -f docker-compose.yml -f docker-compose.override.yml -f -f docker-compose.windows.yml -f docker-compose.override.windows.yml upIMPORTANT: You need to include those files when running docker-compose up and the ESHOP_OCELOT_VOLUME_SPEC environment variable must be set to C:\app\configuration. Also you have to set the environment variables related to the localhost loopback limitation mentioned at the beginning of this post (if it applies to your environment).
Just for reference here are the docker compose files and what they do:
-
docker-compose.yml: Main compose file. Define all services for both Linux & Windows and set base images for Linux -
docker-compose.override.yml: Main override file. Define all config for both Linux & Windows, with Linux-based defaults -
docker-compose.windows.yml: Overrides some previous data (like images) for Windows containers -
docker-compose.override.windows.yml: Adds specific windows-only configuration
Open a browser and navigate to the following URL:
http://10.0.75.1:5100
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.
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 should be unset (or empty) unless you're using any external RabbitMQ that requires any specific login/password
- In Windows these variables should be set
To set this variables you have two options
- Just set them on your shell
- Edit the
.envfile 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 $trueWhen 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:
set ESHOP_OCELOT_VOLUME_SPEC=C:\app\configuration
docker-compose -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.windows.yml up