- Common issues in software development, deployment and hosting
- Containers to the rescue!
- Containers vs. virtual machines
- Image and layers
- Further reading
Containers are far more lightweight than a virtual machine, meaning you can run far more of those on the same amount of hardware.
Watch the video accompanying this article below, which includes demos of these concepts. Or watch it on Discover Sitecore on YouTube.
Common issues in software development, deployment and hosting
- Have you ever had the issue getting a new project set up on your machine with all the required dependencies?
- How about then managing those dependencies throughout all your non-production and production environments?
- What happens when you need to upgrade one or more of those dependencies?
- Have you ever mistakenly developed against one version of a dependency only to discover a different version is live in production?
- How about having a team with developers who want to run different operating systems (OS)?
- The problem here is that you’re deploying just the application on its own and relying on the host environment to provide the dependencies. In reality, the host should be responsible for the OS and not much else.
What all of these problems have in common surround issues of consistency, isolation, and reproducibility. These are the problems that Docker, and containers in general, were created to solve.
Containers to the rescue!
When you deploy a container, you’re actually deploying everything that is required to run that application, inside of a single artifact.
As you can see in the image, you’re not just packaging up your application but also its dependencies and libraries, its configuration assets, and anything else that it needs to run. All wrapped up nicely in a single asset that you can move between your different environments.
Containers vs. virtual machines
One common question is how does a container differ from a virtual machine. They have some overlap in the functionality they provide, but how they achieve it is fundamentally different.
If you look at the virtual machine diagram on the left, each of the green boxes represents an entire OS. This means there are four complete operating systems present on that host infrastructure and this can place a heavy load on the system resources and disk space required.
Compare that with the container-based approach on the right. Here, the host operating system’s kernel and resources are directly shared by the containers through the Docker daemon. This means that the containers are far more lightweight than a virtual machine, meaning you can run far more of those on the same amount of hardware.
Image and layers
Now the containers seen in the previous example will have been created from an image. An image is a read-only template with instructions for creating a Docker container. Images themselves are built on the concept of layers, each layer building upon the layer below it. This concept means it makes it very simple to customize existing images to build out your custom functionality.
If you look at the image above, you can see that the Sitecore® Experience Platform™ (XP) image is built on top of the 4.8-windowsservercore-ltsc2019 image. We take the Windows Server Core image released by Microsoft and we add a custom layer on top of it to include the Sitecore code. This could be an image to build a Content Management (CM) role, or Content Delivery (CD) role, but the concept remains the same.
We can also then take that Sitecore XP image and build on top of it to provide further functionality. The middle image shown above takes the XP image and then layers Sitecore PowerShell Extensions (SPE) on top. The diagram on the right takes this a step further, using the SPE image we just created and adding a layer for Sitecore Experience Accelerator (SXA) on top of that.
The powerful concept with the layered approach is that these layers are shared. So, that Windows Server Core image we started out with only needs to exist on disk once, and all three of the images above build on top of it.
You can read a good overview of Docker, its use cases and the application architecture on Docker Docs.