How to Setup Mongo and Solr on Docker for Sitecore xDB: Part 1
Vasiliy Fomichev
In How To, Infrastructure Posted July 15, 2015
First, Microsoft shocked the world by making .NET open source. Then they punched all the doubters in the face by running a .NET app in a Linux container running on a Windows machine at a Microsoft Build conference this year. Yes, that was .NET running on Linux running on Windows! …what is this wizardry?
Docker
Docker StackEngine survey results.
After watching the video I got intrigued. I saw a huge potential in Docker, especially when I found out abour boot2docker application that allows to run Docker containers inside Windows and Mac operating systems! My eyes got even bigger, as through research I found that Microsoft had already started integrating Docker into Windows servers! I thought I’ve just stumbled upon something great here!
As I continued research, I ventured into Vagrant and other similar technologies, but Docker made the most sense to me. It allows to package up the application by creating an image with everything it needs to run and and make it easily shareable. The fact that the shared image only contained parts required for running it and no other bloatware lit up probably one of the biggest light bulbs for me!
For the sake of keeping this blog post focused, I suggest all readers to take some time and familiarize themselves with Docker before continuing on. Here are some places to start:
These are the most useful features of Docker in my book:
- If you area developer reading this, how many times have you developed something, passed it on to QA and got it kicked back with a bug. After testing it on your machine, you verified that it in fact worked perfectly, commented on the bug hinting towards QA engineers’ incompetence and sent it back? This is a well-known scenario, and happens way to often that both sides, developers and QA engineers joke about it, yet it still happens and slows all of us down.
Docker comes to help in this case. Developers create the application in a Docker container and when it’s ready for QA, simply package it up into an image and share it with QA. QA then simply loads the image into the Docker container on their server and performs testing. The app is now being tested in the same environment it’s been developed in, eliminating room for errors and arguments.
Docker makes it very easy to share images in Docker Hub. Images can be private or public, and are loaded and created very quickly. Since Docker, like Git source control, only keeps track of changes done to the container.
- How many times as a developer or a system admin have you had to setup a server for local research or testing and then replicate the same setup on several other environments? And when you did “replicate”, it didn’t quite work, as well, as it did on your local machine?
Tools we used in the past to solve this problem would include simply creating an image of the entire server and packing that gigantic gorilla to another machine. This worked, but packing that several-gigabyte orangutan was never fun. Plus, if let’s say a developer created it, she was now telling the sys admins how to do their job, and you don’t want to mess with those guys, trust me!
So what other ways are left? Keeping track of every single step is prone to lots of errors. Copying only the application files may result in missing references and library version conflicts on the other machine. This entire time we have been hacking it by mitigating risks and sometimes using a combination of steps above, however, the root of the problem was never addressed.
Not until Docker came along! Docker allows us to setup our application in a container, “image” it up, and simply share it with others. The download of most images is a matter of a few minutes from Docker Hub, and loading it is a matter of seconds, after which we get ourselves an exact replica of the setup! No more human errors, no underwater compatibility issues and the image can be very lightweight, especially when using Dockerfiles.
- How many times, as a developer, have you encountered a bug in production, or any other environment that you just could not reproduce on your local machine? No matter what you tried, that hidden configuration file, library, or environment variable kept you from getting any sleep many times, right?
Docker to the rescue yet again! If you run you applications in production and other environments in containers, it makes it very easy to replicate those environments on any other machine. We would simply export that container into an image (easily done with two commands), and load that lightweight package on any other container for debugging.
As you can see, Docker introduced a new way of keeping application integrity, and Microsoft, Apple and a vast majority of Linux enthusiasts are getting onboard. So how can I, as a Sitecore developer benefit from this amazing tool? Windows kernel does not support containers (yet) and Sitecore is not in vNext (yet), so we cannot run it in a container (yet)! …well, read on.
How Can Docker Help Sitecore Developers?
Virtual machines vs. containers.
“So, how can Docker benefit Sitecore developers?” you ask. Short answer, – “xDB”. No more painful setups of Mongo or Solr! We can now create images that are project specific or generic. Simply create a container on your local machine and then share it with the team and use it to push, for instance, the Solr configuration you have been sweating over trying to get it right, to all machines up to production! And vice versa! If you have your production applications like Mongo and Solr running in containers, it is now just a matter of creating an image on production machines (no downtime here) and installing it on your local development box for debugging. You can have a replica production environment on your local machine in a matter of minutes! On top of that the installation of every container is not intrussive to the main operating system. This is groundbreaking!
I was eager to start trying to create an image of my own! First, I started with a very simple Mongo container, and then I created one with Solr 5.2.1, and configured both to work with Sitecore. Below are the steps I used to setup each one and create your own images. However, if you are so excited by this find that you can’t waste any more time on reading – at the end of the How to Setup Mongo and Solr on Docker for Sitecore: Part 2 I talk about the Solr for Sitecore I’ve created for Sitecore, which installs instances of Solr ready to rock and roll out of the box with Sitecore.
The next part of the Docker series, How to Setup Mongo and Solr on Docker for Sitecore: Part 2, provides a steb-by-step guide on setting up Mongo and Solr, creating, exporting and uploading images to Docker Hub.