When we eventually look back on the current decade, one of the truly defining tech trends will be Docker containers. Containers are available on nearly every platform imaginable, and are quickly beginning to replace virtual machines for a variety of tasks. Simply put, containers are becoming the new way of doing things. Even so, containers tend to be used primarily by developers who need to ensure portability for the applications that they build, and by systems administrators who are looking for a way to make applications run in the cloud. But what about containerization on the desktop — yes, running desktop applications in containers.
At first the idea of running desktop applications in containers might sound ludicrous. After all, there is a whole laundry list of issues related to running GUI applications within a container. But that’s another discussion for another article. For right now, I want to talk about what some of the benefits might be to running desktop applications in containers.
One of the primary benefits to running desktop applications in containers is that of application isolation. Although containers share a common kernel, containerized applications run within a dedicated space, and are therefore isolated from one another. This makes it possible to run applications that would ordinarily conflict with one another, side by side.
As nice as this benefit may be, however, container isolation provides another benefit that is potentially even more useful. Containerized applications may have the ability to protect users against malware.
Imagine for a moment that a web browser is running inside of a container. Because multiple containerized applications are presumably sharing the host kernel, none of those applications are allowed to write to the kernel. Instead, write operations are directed to a dedicated, nonpersistent storage mechanism. With this in mind, imagine what would happen if you were to accidentally open a malicious web page. The malicious code on the page would only be able to execute within the confines of the container. As such, it would be unable to harm the rest of the system. Because containers are designed to be nonpersistent, the web browser container could easily be killed, and a new container could just as easily be created in its place. As such, containerized web browsers could go a long way toward protecting users against ransomware and all manner of drive-by downloads.
Keep in mind that these security benefits could be mitigated if a persistent storage volume is attached to the container, or if the system is configured incorrectly.
Easy removal of unwanted applications
I’ve already touched on this one a little bit in the last section. When an application is running in a container, it does not get installed onto the system in the usual way. That means that an application can be removed simply by ending the container.
In the case of a containerized web browser, this could be a huge benefit. Ending the container would eliminate the browser, taking with it things like tracking cookies, the browsing history, and temporary Internet files. The next time the user wants to use the browser, they simply start a new container, and are presented with a new and pristine browser that is free of the clutter that accumulates over time.
At the same time, though, the fact that containerized applications do not get installed in the usual way can be of a benefit to more than just web browsers. Often times, applications have dependencies upon external code. A Windows application, for example, might require the visual C runtime library, or perhaps SQL Server Express Edition. The problem with such dependencies is that uninstalling the application may not remove the dependencies.
In the case of a containerized application, removing an unwanted application is as simple as stopping the container. Doing so removes the application and any dependencies that were installed along with it at the time that the container was created. Best of all, because containers are designed to be portable and isolated, removing an application and its dependencies should not pose any risk of breaking other applications that might share those dependencies, because each application is presumably bundled with its own dependencies.
Potential solution for apps that require a legacy OS
Yet another benefit to running desktop applications in containers is that doing so could potentially solve the problem of ancient applications that have to run on legacy operating systems. We all have these types of applications in our organizations, and it is always a challenge to figure out how to securely run such applications on modern operating systems.
A containerized environment could make it possible to run an outdated application that requires an ancient operating system build. There are limits of course. You can’t, for example, run a Windows container on Linux or run a Linux container on Windows.
In a way, I tend to think of this benefit as being kind of like what Microsoft did when they introduced Windows 7. At the time, Microsoft was trying to convince customers to upgrade to Windows 7, but many of the applications that were designed for Windows XP would not run natively in Windows 7. Microsoft’s solution was to introduce Windows XP mode. Windows XP mode ran a virtualized copy of windows XP in the background, thereby allowing legacy applications to seamlessly run on an otherwise incompatible system. Even though containers use different technology from what I just described, the end result is essentially the same.
Downside to desktop applications in containers
Although there are a number of benefits to running desktop applications in containers, there is at least one disadvantage. Because containers are designed to be immutable, they pose a challenge when it comes to patch management. Imagine that a containerized application realizes that it needs to be patched, and so it downloads and installs those patches. At the end of the user’s session, the container is destroyed. The next time that a user starts a containerized version of the application, those patches are gone. As such, the IT department may find themselves frequently rebuilding container images as application patches are released.
In case you are wondering, there are tools that can make patch management for containerized environments a little bit easier. One such tool is Zypper-docker, which provides a quick way to patch Docker images that are based on either SUSE Enterprise Linux or openSUSE.
Even though containers have thus far been used much more heavily in server or cloud environments, the idea of containerizing desktop applications is not entirely unprecedented. There are people who are already doing it, and there are a number of containerized desktop applications that are publicly available. For example, it is relatively easy to run Google Chrome in a container on a desktop. There are also Firefox containers available for some platforms.
The idea of containerizing applications on the desktop has actually existed for quite some time. Microsoft has long offered a product called App-V. Although App-V is not technically a containerization product and is not based on Docker, the underlying technology has a lot of similarities to containers. As such, I tend to think of App-V virtualized applications as being something of an early proof-of-concept illustrating the value of running desktop applications in an isolated space.
Photo credit: Pixabay / PNG Mart
1 thought on “Desktop applications in containers: Not as crazy as it sounds”
The ones that doesn’t know debian packages are condemned to re-implement them poorly.
And, more important: for containers, emphasys on isn’t in the easiness of deploying the app, but the safety of running it on a confined environment and this is valid for servers. On desktop… well, highly questionable.