It was not long ago when you need to mention Docker at least once during your presentation to make it cool and trendy. And actually, there is a good reason for that. Containerization provides a way to make environments portable and immutable. Immutable infrastructure for Sitecore would be much desired, but containers are on Windows are not so cool yet. It doesn’t mean that you cannot get it but we will need to bake it a bit differently. Let me show you how…
Containers for Windows
While Microsoft did an awesome job supporting containers API in Windows, its architecture is way too different from Unix. For example, there is no concept of ***cgroups ***in Windows, to provide isolation for processes or layers in a file system. As a result, you have quite fat images 6-10GB that use hyper-v and uses tons of symlinks. It is also important to mention that you could not run both Windows and Linux on the same machine and you might want to for SOLR. To my taste, they are not so far from the average VM created with VirtualBox or Hyper-V.
Virtual Machines
In my practice, many developers coming from SharePoint development are used to work on VMs. However, in most of the cases, they used it to completely isolate the whole dev environment from the host machine. Which resulted in gigantic machines that are barely movable. On the other hand, VirtualBox will work on any host OS and you do not need to move your front-end developers from MAC that they like so much.
So what if …
… we take a development approach that is used with containers and apply it to virtual machines. Containers are usually used as hosting for your app, and it is possible to do the same with VM. Just install everything you need in one VM, configure port forwarding or host-only network and you are ready to deploy your code to the VM. If you want to share this VM you can export it to .ova/.ovf format.
One part that is different from the container approach is “Just install everything” as in the case of Docker this installation step is automated and repeatable via Dockerfile.
Sitecore Packer + Vagrant + Chef
This is where Packer + Vagrant + Chef comes into play.
- PACKER - provides functionality to build VM images for a large set of providers. You can separate the process in many steps, e.g. you create the first image with Windows only, then you install some basic dependencies like dotNET, IIS, MS SQL, and on top of that you create an image that handles installation of Sitecore.
- **CHEF **- is one of the options that you can use to automate provisioning. You can replace it with just PowerShell or Ansible or whatever is supported by Packer now. In this case, I found an awesome repository was the significant part of automation was done already and it was done in Chef.
- VAGRANT - you can compare vagrant to docker CLI. It allows you to create a file with a configuration to start your VM, and infrastructure to download shared images and commands to start/stop VMs. Depending on your virtualization provider, vagrant will connect to it and do all configuration once you write “vagrant up”.
I’ve many a first pass and cover all plumbing required for Sitecore 9.0 installation in one box.
Github
https://github.com/asmagin/sitecore-packer README.MD in the repo has a detailed description of the build and installation processes. ** The first thought was to call it similar to Sitecore+Docker repository, but that analogy didn’t sound right :)*
SUMMARY
Images created with Packer allow you to do “docker-like” development, configure your local development environment once and share it with colleagues and unify the process for local and remote deployments.
Also, it will save you from “works on my computer” or “cannot install on my computer because I have/do not have #{place reason here}”.
Follow me on Twitter @true_shoorik. Would be glad to discuss the ideas above in the comments.