How to build Docker image for Windows desktop applications.

It used to be that people first downloaded software onto a physical computer and then ran it. Now, with cloud computing, you no longer need to worry about awkward downloads. Instead, you can use all the same services online from anywhere and see updates in real-time.

Why businesses migrate their legacy applications to clouds?

1. Probably the first main reason for moving to the cloud is access to virtually unlimited computing resources. Cloud elasticity and scalability are essential elements of cloud computing.
   • Cloud elasticity is the ability of a system to manage available resources based on current workload requirements dynamically.
   • Cloud Scalability is a scalable system infrastructure to meet growing workload demands while maintaining consistent performance appropriately.
2. Moving from legacy Windows app to cloud computing lets you work anytime, anywhere with an internet connection. A cloud-based web service is accessible from any device.
3. In the current pandemic situation, team members are forced to work from their home offices. Using the clouds, your teammates can open, edit and share documents anytime and from anywhere; they can do more together and do it better. Before the advent of the cloud-based workflow, employees had to send files back and forth as email attachments that a single user worked on simultaneously.
4. A public cloud provider owns the hardware infrastructure and is responsible for managing and maintaining it, so you don't have to worry about maintenance. With a public cloud, you only need to focus directly on meeting your business goals.
5. Cloud computing reduces high hardware costs. You pay only for the actual consumption of resources.

Virtual Machines vs. Containers.

Containers and virtual machines (VMs) are the two main approaches to deploying multiple isolated services in the cloud. So how are they different?

Virtual machine (VM).

Before the advent of containers, "virtual machine" was a technology used to optimize server capacity. Virtual machines (and hypervisors) emulate physical computer hardware with a complete operating system. It's as if you were running multiple computers with several different operating systems on the same physical server.

The hypervisor orchestrates and distributes available resources (processor, memory, storage, etc.) across multiple virtual machines as needed.

Containers.

The container shares the host OS kernel as well as binaries and libraries with other containers. Common OS components are read-only.

Containers are lightweight so that you can deploy multiple containers on a single server or virtual machine. You no longer need to dedicate an entire server to one application.

Advantages of Containers.

The biggest advantage of containers (if we are talking about Docker) over virtual machine images is resource usage.

• Containers are lightweight, so they are fast.
• Containers consume fewer resources.
• Docker containers typically start in seconds, which speeds up deployment.
• Tearing down a Docker container is as easy as running the docker stop command and usually takes less than a second.

On the other hand,

• virtual machines take longer as they go through the entire process of booting the entire virtual operating system each time!
• Each VM includes a separate operating system image, which adds overhead in memory and storage footprint.

Scaling container instances is far faster and easier than deploying additional VMs.

Data volumes can be shared and reused among multiple containers.

Docker containers.

Docker is currently the leading container toolbox to deploy microservices to the cloud.

A software container packages the code, its libraries, frameworks, and other dependent components. As a result, the application runs quickly and reliably in any environment, be it a local data center, a public cloud, or a developer's laptop.

Software containerization solves many of the challenges of software development and deployment, so we embraced this concept when moving our Windows desktop applications to the cloud.

The most suitable types of software to embed in a docker container are non-user interface applications that are run from the command line. Typically Linux-based Docker images are lightweight and widely used in cloud environments.

Unfortunately, in most cases, rewriting all of your Windows application code from scratch to make it cross-platform is too expensive and time-consuming.

Besides, when it comes to platform design, sharing the kernel between Dockerized applications has significant limitations. For example, Windows containers will not be able to run on a Linux host.

Windows container base images.

Microsoft offers Windows containers to deliver containerized services on the Windows platform.

Check out a good article from Microsoft that describes Windows docker container images that users can build from.

I will use an Insider Windows Server Core image as a base . This image includes a subset of the Windows Server APIs and is suitable for packaging typical .NET framework applications.

• Insider images are >50% smaller than the .Net Framework Runtime Images.
• Container startup into Windows PowerShell is 30-45% faster.

Dockerizing DBConvert tools.

As an example, I will show how to build a Docker image for DBConvert Studio. It is a classic .NET Windows application running either in GUI mode or in headless mode from the command line. It is also a good source of Docker-related techniques if you want to customize your own Dockerfiles further.

FROM mcr.microsoft.com/windows/servercore/insider:10.0.18362.1

RUN echo "Downloading dbconvert studio"
ADD https://dbconvert.com/downloads/dbconvert_studio.zip /
COPY DBConvert-Studio.reg /
RUN powershell -Command "Write-Host 'Expanding dbconvert archive'; \
    Expand-Archive dbconvert_studio.zip; \
    Write-Host 'Installing dbconvert'; \
    Start-Process msiexec -ArgumentList '/i', 'C:\dbconvert_studio\dbconvert_studio_x64\DbConvertStudioSetup_x64.msi', '/quiet', '/norestart' -NoNewWindow -Wait; \
    Start-Process reg import DBConvert-Studio.reg; \
    Remove-Item -Path c:\dbconvert* -recurse -force; \
    Set-Location -Path 'C:\Program Files\DBConvert\DBConvert Studio x64';"
CMD ["powershell"]

Let's dive deeper into what the Dockerfile actually does.

• The first FROM line pulls the Insider Windows Server Core image.
• The next RUN simply displays the status of the following ADD command. It downloads the installation zip package directly to our new image.
• COPY DBConvert-Studio.reg / command copies the DBConvert registration file info to the root of the image. We will use it later to remove all restrictions on the DBConvert studio unregistered copy of the. (See the reg import command, which will appear later).

Let's take a look at the rest of the PowerShell commands combined into the following RUN command.

• The Write-Host command displays the current status of the operation.
• Expand-Archive - extracts the contents of the newly downloaded zip archive to the root directory of our image.
• Start-Process msiexec command installs the unpacked archive.
• The next " Start-Process reg" command imports the registration file's contents into our docker image's Windows registry.
• Remove-Item removes all unnecessary intermediary files from the final image.
• Set-Location sets the specified location as a working directory.
• CMD ["powershell"] specifies what command to run within the container. In fact, we can call straight CMD ["DBConvert.exe", "/ Session:", "mysql2mysql"] , but each time it may be a different session configuration file. Therefore, it is better to bind the directory on the host to the directory inside the container with the --volume (-v) flag

Building Docker image and starting container.

Launch the following command in the terminal to build your Docker image.

docker build -t slotix/dbconvert-studio .

The next command docker run starts a container from the newly created DBConvert Studio image.

docker run --name studio -it --rm -v "c:\dbconvert-docker\studio\workSettings:C:\PROGRAM FILES\DBCONVERT\DBConvert Studio x64\workSettings" slotix/dbconvert-studio:latest DBConvert.exe /Session:"my2my_copy"

Containers are immutable in design. This means that the container will not be changed during its life cycle: no updates, no patches, no configuration changes.

When starting DBConvert studio from the command line, you need to pass in a ready-made session file that includes the configured database connections involved in the migration and some other parameters.

-v flag mounts c:\dbconvert-docker\studio\workSettings directory on the host machine into the folder C:\PROGRAM FILES\DBCONVERT\DBConvert Studio x64\workSettings inside the running container.

• This way we can feed DBConvert Studio with jobs located outside of the container.
• Another advantage of directory binding is that it works and vice versa. When a process completes, a log file is generated. It appears both inside the container directory and on the host computer.

Check out github repository with Dockerfile from this article at https://github.com/slotix/dbconvert-docker

Conclusion.

1. Typically, the core business logic of a legacy monolithic application is tightly coupled to its GUI.
2. Legacy applications may not scale well enough to meet new customer needs, resulting in decreased performance and increased customer frustration.
3. Developers often get stuck in old code when there are so many exciting new technologies available to innovate.

The good news is that moving from a legacy desktop application to a microservice architecture stops the monolithic nightmare.
Dividing a monolithic application into subsystems that can be scaled, developed, and deployed individually is your entry point into the microservices realm.
If there is a requirement to run multiple copies of a single application, Docker is a perfect choice for packaging Windows applications.

This is why we ourselves adopted this concept when migrating existing Windows-based DBConvert products to the cloud infrastructure.