The Quest For Process Isolation, Part 3

Introduction

In Part 3 of the Process Isolation series, we will use the Windows Server virtual machine previously configured to install and configure Sitecore Commerce on Docker Containers.

As we are essentially using Docker remotely, there are a few differences with local development that we need to consider. These differences will be discussed in further detail.

This guide assumes that you already know how to install Sitecore / Sitecore Commerce in Containers using the officially provided documentation.

Phase III - Configure Docker CLI

As we are now going to be using Docker remotely, we will need to configure our Docker CLI application to connect to the remote instance. This will be done in your development environment, whether this will be the host machine, another machine on the network or another virtual machine. We previously configured Docker Daemon to listen on port 2375. We must configure Docker CLI to connect to the Windows Server virtual machine on this port to allow it to communicate with Docker Daemon.

  1. As per Step 6 of Phase I in The Quest For Process Isolation, Part 2, you would have noted down the hostname of the Windows Server virtual machine which you need to proceed. It is not advisable to use IP addresses, as they could change any time when the DHCP lease expires for your machine.

    WIN-B2BNR0TKI4R is what I will be using for the remainder of this guide.

  2. On your development machine (not the Windows Server virtual machine), you must configure a Docker Context. This allows you to switch between different running instances of Docker Daemon when you have more than one you need to talk to. In this instance we will be using the functionality to tell Docker CLI to connect to our remote machine.

    docker context create sc10 --description "Sitecore 10 Containers" --docker "host=tcp://WIN-B2BNR0TKI4R:2375"

    After running docker context ls you should see something similar to the following:


  3.  Run the following command to change to the newly created context:

    docker context use sc10

  4. Test the configuration and installation. If this is not successful, something has gone wrong and you will need to go back and do some troubleshooting. Some common things that can go wrong include the Docker Daemon not running inside your Windows Server virtual machine, wrong hostname or firewall still being enabled.

    docker run --rm mcr.microsoft.com/windows/nanoserver:1909 cmd.exe /c echo hello world 
from ^%username^% at ^%computername^%



    If successful, it means that you are able to run Docker Containers remotely with Process Isolation. All Docker commands you were previously executing will now be directed at the remote Docker Daemon running on the Windows Server virtual machine.

  5. Configure docker-compose to use the remote Docker Daemon by default. This is very straightforward and simply involves you configuring the DOCKER_HOST environment variable in your Powershell / Command Prompt.

    $env:DOCKER_HOST = "tcp://WIN-B2BNR0TKI4R:2375"



    You can also make more permanent changes by adding this environment variable into your Windows System Environment Variable settings:


Phase IV - Install Sitecore Commerce Containers

Hopefully you now have a fully functioning remote Docker Desktop daemon at your bidding. We will now install Sitecore Experience Commerce as per the official documentation. My aim here is to outline the key differences you will need to take into account as opposed to walking through end-to-end. Each section mentioned here corresponds to the Installation Guide for a Developer Workstation with Containers.

2. Prepare for Commerce containers deployment

2.1. Prepare the environment variables file

The key difference in this section is that after running UpdateEnvCompose.ps1, you must copy C:\containers from your development machine to the Windows Server virtual machine. This is because in addition to generating the Environment Variables (.env) file, the script also creates the minimum directory structure that contains the volumes that will be mounted into your containers. Without the directory structure in place, the containers will not run.


Back on your development machine, you will next want to ensure that your .env file is configured to use Process Isolation and the matching image tags corresponding to the desired version of Windows:

XP_SITECORE_TAG=10.0.0-1909
SPE_SITECORE_TAG=6.1.1-1909
SXA_SITECORE_TAG=10.0.0-1909
XC_PACKAGES_TAG=10.0.0-1909
ISOLATION=process

You cannot use Process Isolation for traefik as they only ship images compatible with Windows 1803.

TRAEFIK_IMAGE=traefik:v2.2.0-windowsservercore-1809
TRAEFIK_ISOLATION=hyperv

If you use *.localhost hostnames for each role, this will cause issues with Google Chrome, which automatically resolves any hostname with the localhost domain to 127.0.0.1. This is obviously not desirable as our containers will be running on a remote machine. I recommend to change the hostnames to be something else.

2.2. Generate TLS/HTTPS certificates

You can perform these steps on you local development machine, but you will later need to copy the generated certificates and keys into the Windows Server virtual machine. 

If you have changed your hostnames to something other than the default, ensure that the certificates generated match them. Otherwise, traefik will serve invalid HTTPS certificates and you will get certificate errors in your web browser.

After generating the certificates and keys, you must copy them to the Windows Server virtual machine, to a directory such as C:\containers\traefik.

2.3. Update the Windows hosts file

This step is to be performed on the development machine. It is required so that you resolve the hostnames you configured in the .env file to the Windows Server virtual machine. My hosts file looks like this:

192.168.0.249   xc1cm.xc10.dev xc1cd.xc10.dev xc1id.xc10.dev bizfx.xc10.dev authoring.xc10.dev shops.xc10.dev ops.xc10.dev

3. Deploy a Sitecore XC developer workstation

The following steps must be performed on the Windows Server virtual machine instead:

  • 5. If required, generate the required TLS reverse proxy certificates, execute the sample PowerShell script.
    • This is the same as Section 2.2 Generate TLS/HTTPS certificates.
  • The license file and certificates generated must be present in some place on the Virtual Machine. The paths in the .env file refer to paths on the machine where Docker Daemon is running. 
    • By default, Traefik is volume mounting the directory containing the certificates directly from a path relative to the docker-compose.yml file. This must be changed to be an absolute path somewhere on the machine, e.g. C:\containers\traefik.
    • Change the docker-compose.yml file to mount the directory you created, instead of the default:


  • You don't need to do the same for the license file, as this is something that is base-64 encoded and inserted directly into the .env file.

4. Deploy a Sitecore XC developer workstation

Assuming you have configured the hosts file on your development machine as above, you should be able to follow these steps normally, treating the containers as if they were running on the local machine. For example, when using Postman to execute Bootstrap, this will be run on your Commerce Authoring or Ops role which will have the hostname you configured in the .env file.

Other considerations

Beyond what has been discussed above as supplementary to the Developer documentation, my comments below are suggestions on how to work more efficiently with the virtual machine.

Performance

By using Process Isolation for all but the Traefik container, we are seeing much better performance and less resource utilisation compared to Hyper-V isolation. As shown in this screenshot from the Windows Server virtual machine, each container now runs as a series of processes directly within Windows, as opposed to each container requiring one complete instance of Hyper-V "vmmem" per container:


CPU usage as reported by Hyper-V sits at a more acceptable level, leaving resources for use by your IDE, web browser, music player, etc. :)


Decoupling dev / runtime environments

You can use this strategy to decouple your dev and runtime environments. For example, when Sitecore 10.1 is released and it depends on a base image of some other Windows Version, you can configure another virtual machine with the desired version and not have to worry about your host machine's OS.

If you are running macOS or Linux, no worries there either as the Windows VM you use for development can be left completely alone.

Accessing the Container services

The default architecture of Sitecore on Containers contains Traefik, a reverse proxy that routes requests from your browser to the right container, based on the HOST header that your browser sends. 

A common query I have heard is that when browsing to the different roles i.e. CM or CD, a 404 Not Found is unexpectedly returned. The reason for this is that Traefik has been configured by default to only route traffic if the destination container is healthy. 

You will want to make sure that all your containers are healthy:


To see what routers are in operation, we can use the Traefik Admin Interface. You can reach it by navigating to https://<hostname>:8079/.



Accessing the File System

It is somewhat tricky to access the file system of a container. Traditionally this is achieved by running bash or Powershell in the container and with our new development architecture there are no differences here. One key difference is that the container volumes are obviously going to be located in the VM and not on your development machine. You can access the volumes directory on your development machine via network shares:



Accessing SQL Server

Your Sitecore Containers development instance comes with a SQL Server container. You may need to log in to run queries, and this is certainly possible. The approach would be as follows:
  1. On your development machine, install and run SQL Server Management Studio.
  2. In the Connect window, the hostname will be that of the Windows Server Virtual Machine. You must specify port 14330, which is what is configured in the docker-compose.yml by default. The password will be whatever you have configured in your .env file.


  3. Go forth and be free.

Accessing Solr

Another common activity is to access the Solr admin interface to run queries. It's on port 8984:

Summary

In this post I configured the Docker CLI to send commands to Docker Daemon in my Windows Server virtual machine. I installed Sitecore Commerce on Containers in the virtual machine, and went through some of the usual processes to access different services.

I demonstrated the performance benefits of using Process Isolation vs. Hyper-V isolation.

Hopefully this was of some use to you and good luck with running Sitecore on Containers. If you have any questions, please drop me a line.

Comments