Docker Hosting: Compare Hosting
Oops! No Hosting Plans Match Your Search
You've selected a combination of features that none of the web hosts we profile offer. We suggest you remove your last filter or reset & start again.
Ask Our Experts
Need help with your hosting? Tell us exactly what you are looking for and we’ll do our very best to help. Please allow one working day for a response.
Please fill in all fields.
Thanks! Your request has been sent. We'll reply within 24 hours.
Recommended Web Host
Docker is a relatively new containerization technology. It allows web application developers and system admins to deploy apps to web servers inside of isolated virtual containers which provide all needed dependencies and a operating system abstraction layer.
The Environment Problem
No app is an island. Every software application relies on dependencies outside itself — frameworks, libraries, plugins, web servers, databases, are all used when building modern software. These, in turn, rely on other libraries and depend on particular environment settings and configurations. Each application or dependency might rely on a particular version, or create conflicts if used in conjuction with other software.
In short — the complex ecosystem of software on a typical computer running many different applications can create unforeseen problems.
For example — you might find that an app has some bugs when run on one particular version of a web server, but is fine on another. You could track down the source of those bugs (which you may not be able to find, or fix), or you could simply choose to use the version that works. But what if you are running two apps on the same server that each have a similar problem, but with different versions of the web server software. Or some other dependency, for that matter.
Every computer system has a unique environment. The particular combination of hardware, firmware, operating system (including specific distribution and version), installed languages, particularly specific version of each installed extension, DLL, library, plugin, configuration options, and seemingly-unrelated applications all contribute to this unique environment.
Once an application reaches a sufficient level of complexity, these environmental idiosyncrasies can start to have an effect on performance. Some of the more conventional solutions to dealing with this problem include:
Attempting to write better software. This seems like a noble direction to head in — trying to write perfect software code that somehow doesn't conflict or collide with other software, that doesn't rely on outside dependencies, that is backwards compatible with older versions of things. The problem is that this is actually impossible in real life.
Maintaining duplicate environments. Usually there will be a production environment and then a test and/or development server that is cloned from production. New versions are tried out in a non-public environment before being deployed to production. Assuming the environments are truly identical, this at least gives developers the chance to see if there are any problems.
Segregating apps onto different (virtual) machines. If a company is running multiple web applications, they will often have each one running in its own machine (real or virtual) in order to minimize or eliminate the problem of conflicting needs (for example, two apps needing different versions of the same library).
Virtual machines for development. Most developers work locally on their laptop or desktop computer. Since that environment is filled with applications and multiple versions of things (due to typical personal-use practices), some developers will isolate app development into special-purpose virtual machines, often mirroring (as much as possible) the production environment.
Often, a combination of these strategies is employed; we try to write better software, while segregating production environments for separate apps, and cloning test environments onto our local virtual machine.
The Problem with Conventional Solutions
Conventional solutions are either not independent enough, or are so independent that they create an onerous amount of overhead and bulk.
From the above solutions, the best option would be to have a virtual machine on the local development computer for each app being worked on, and to use the same exact virtualization technology on the test and production servers. The environment would need to be cloned down from production to test to development for each development cycle, and cloned back up for each deployment.
That is a huge amount of inconvenience, and is not consonant with typical rapid development methodology — not to mention that none of this works well for an application that needs to be packaged and distributed for customer use.
Containerization is something like a middle-ground between the mess of natural computing environments and rigidly segmented virtual machines.
There's a perfect analogy here to shipping. On the one hand is a giant cargo ship in which each small piece of cargo is packed into the hold and everything can slam into everything else and it all has to be loaded and unloaded by hand. On the other hand is a multitude of individual boats, one boat for each piece of cargo. The best solution is somewhere between these two: interchangeable, self-contained storage and shipping units which can be loaded easily onto many different types of transportation, from giant cargo ship to railroad.
A software container has a copy of the primary application, as well all dependencies — libraries, languages, frameworks, and everything else. The containerization system provides APIs to the operating system so that the interface between the container and the OS on one machine is the same as the interface between them on another machine.
This means that an app that runs in a container on a local development machine can be deployed easily onto another server by simply copying the entire container — moving it like a shipping container from boat to dock — without having to worry about environmental configuration details or installing dependencies.
Several different containered apps on the same machine might be using different versions of the same libraries, or might have other conflicting dependencies, but its okay because they are separated from each other. This does end up potentially using up more storage space (because of the need of having multiple copies of some things on the same machine), but this is a negligible cost in comparison to the benefits.
Docker is one of the leading containerization technologies. It is Open Source, and can run on any Linux environment with a modern kernal.