Feasibility Report on HC deployment on Docker Desktop
Purpose of this document
This document will cover the limitations, pros/cons of each approach, performance test results, deployment feasibility - ease of use, operate, upgrade, Offline deployment and hardware/software requirements of Hybrid Chat solution
Methods of Deployment on Windows
There are three main deployment scenarios available on windows operating systems with Docker.
- Deployment with Docker Desktop (Hyper - V)
- Deployment on Docker Desktop using WSL
- Deployment on WSL by Deploying Docker Linux
The following table describes the pros and cons of all types of deployment.
Deployment with Docker Desktop (Hyper - V)
This type of deployment includes installation of Docker Desktop on Windows Environment with Nested virtualization enabled which will be used by Windows Hyper V to create DockerDesktopVM.
Deployment process is described in this document. One drawback is that the Simplified deployment script won’t work because it only works in Linux and need to find a log retention mechanism like ELK stack.
Windows Virtual machine has consumed 8.5 GBs of RAM out of 12 GB and almost 40% of CPU of 8 Cores.
Followings are the distribution of resources
Windows RAM | 12GB |
CPUs | 8 |
RAM assigned to Docker Desktop | 4.75 GB |
CPUs assigned to Docker Desktop | 4 |
Docker Desktop does not work as smoothly and keeps on crashing. Sometimes the Windows itself gets crashed and logs out the user. This behavior continues even when the resources are increase in the following fashion:
Windows RAM | 16GB |
CPUs | 8 |
RAM assigned to Docker Desktop | 8 GB |
CPUs assigned to Docker Desktop | 4 |
Deployment on Docker Desktop using WSL
The main advantage of using this set-up is that it enables us to use the simplified deployment script for the deployment of HC. We can use Windows Subsystem Linux (Ubuntu Linux shell) to run SDS script on it and it will deploy the HC on Docker Desktop.
There's something we need to understand first. The Docker Engine does not run on WSL, we have to have Docker For Windows installed on the host machine. What we end up with is the Docker client running on Linux (WSL) sending commands to your Docker Engine daemon installed on Windows.
Below is the architecture of the scenario.
Ubuntu 20.04 is used as a Linux shell to deploy HC using SDS and Docker client was installed on it. Deployment was not as stable as it should be. The Windows got crashed many times with the following configuration
Windows RAM | 12GB |
CPUs | 8 |
RAM assigned to Docker Desktop | 4 GB |
CPUs assigned to Docker Desktop | 2 |
After increasing the resources of Windows VM and Docker Desktop, the Docker Desktop began to stall. Resources were increased in the following manners.
Windows RAM | 16GB |
CPUs | 10 |
RAM assigned to Docker Desktop | 6 GB and then 8 GB |
CPUs assigned to Docker Desktop | 4 |
Windows was getting crashed when there was load on the system, specifically during the time when SDS was running for deployment. Sometimes Docker stops working during the deployment process and never made it to a complete deployment of the Chat solution by showing the following error:
docker ps
Error response from daemon: open \\.\pipe\docker_engine_linux: The system cannot find the file specified.
The above error was faced even when the Docker Desktop resources are increased in the following manners:
Windows RAM | 20GB |
CPUs | 10 |
RAM assigned to Docker Desktop | 11GB |
CPUs assigned to Docker Desktop | 4 |
First it seemed like this could be because of the Virtualization provisioning software (KVM) or the underlying hardware but after switching to other virtualization software i.e. VMware Vsphere on different underlying hardware, the issue persists. Which means it's because of poor support of Docker Desktop on Hyper-V.
There were some more issues with Docker Desktop itself. Like whenever Docker Desktop starts, it tries to start the Hyper V Virtual Machine (DokcerDesktopVM). But if the VM is already started before even the Docker Desktop is started, it throws the following error.
System.Threading.Tasks.TaskCanceledException:
Cancellation token triggered before we finished reading from the stream.
at HttpOverStream.ByLineReader.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Deployment on WSL by Deploying Docker Linux
This scenario is not possible on Windows Server environment. In this scenario, We deploy a Linux Container in windows (WSL 2-Ubuntu) and install docker inside that linux shell (WSL 2 - Ubuntu). But it's not possible to install Docker inside WSL in windows Server 2019. WSL-2 is currently available in Semi Annual Channel Releases and Windows 10.
WSL-2 is only available in the following releases of windows.
OS | Build |
Windows 10 | 2004 |
Windows Server (Semi-Annual Channel Release) | 2004 |
while Windows Server latest stable release has Windows Server 2019, 1809 build.
To know more about windows releases: Windows Server servicing channels | Microsoft Docs
Comparison
Docker Desktop (Hyper - V) | Docker Desktop (WSL) | |
Pros | - Does not need Linux container to deploy | Could be deployed with SDS, Could have log retention |
Cons | - Relatively harder to deploy, no log retention methods - Takes a while after deploying the solution (almost 20 minutes) to start the solution - Docker stops working after sometime | - Unstable, crashed multiple time while deploying, Docker Desktop takes more resources to deploy - Did not work. Didn't make it to complete deployment of the solution - Needs WSL1 Linux Container to deploy |
deployment feasibility | Difficult to deploy as SDS won’t work. | Used SDS to deploy |
upgrade | Just need to update the coreversion.env file. | Same as Linux |
Offline deployment | Same as Linux offline deployment | Same as Linux offline deployment |
performance | ||
HW/SW requirement | Deployed on: Win Server 2019 10 GB RAM Docker Desktop 4.75 GB RAM 4 vCPUs | Deployed on: Win Server 2019 16 GB RAM Docker Desktop 8 GB RAM 4 vCPUs |
Conclusion
The final verdict on the reliability of Hybrid Chat solution deployment on Docker Desktop is that it is not production ready. One can deploy it as fun exercise or where reliability is not a concern but we won’t recommend it to use in a production environment.