Over the course of several months I have had the opportunity to introduce the use of docker within development teams as an alternative approach for developing with Sitecore. Developing with Sitecore on Docker requires a bit of a mind shift from your normal way of working with Sitecore. But if offers many benefits like the ability to stand up a fully scaled instance of Sitecore in seconds rather than hours. This blog provides a introduction to docker and getting started developing with Sitecore on Docker.
What is Docker
Docker is a platform that enables you to develop, ship, and run applications as containers. The Docker Daemon process (or engine) runs on your host OS which manages images and containers.
The Command Line Interface (CLI) communicates with the docker daemon via rest API.
Containers vs VMs
Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes.
- take up less space.
- more portable and efficient.
- require fewer VMs and Operating systems.
- reduce cost as fewer licenses are required.
- start in seconds.
- are ephemeral – treated like cattle in your DevOps service model.
VMs are an abstraction of physical hardware turning one server into many servers. The hypervisor allows multiple VMs to run on a single machine.
- includes a full copy of an operating system, the application, necessary binaries and libraries – are much larger in size.
- VMs can also be slow to boot.
- start in minutes
- tend to hang around longer – treated more like pets in your DevOps service model.
By combining Containers and VMs in your infrastructure provide a great deal of flexibility in deploying and managing your application.
Sitecore Docker Repo
The Sitecore Docker Repo contains docker files for a plethora of Sitecore versions and their variants including: JSS, SXA, SPE. Also necessary scripts, tools and supporting documentation to help you build Sitecore Docker images and ultimately run a containerized instance of Sitecore.
Lets backup for those of you that may not be familiar with some of these terms:
- Dockerfile – is a text document that contains all the commands you would normally execute manually in order to build a Docker image.
Docker can build images automatically by reading the instructions from a Dockerfile.
- Docker Images – are the basis of containers. An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered filesystems stacked on top of each other. An image does not have state and it never changes.
- Docker Container– is a runtime instance of a docker image.
Thanks to the hardwork and dedication to the individuals in our community that contribute to the Sitecore Docker repo. Which is continually evolving.
The ability to monitor your Sitecore instances is essential. Knowing your application is available and performing in production as expected is critical. To be proactive and respond to changes in performance as opposed to reactive after an incident has occurred, you need a continuous overview of the state of the application and the underlying infrastructure. This involves gathering metrics like CPU, memory usage, and storage consumption as well as any application-related metrics. However, when monitoring a containerized Sitecore instance we cannot apply our usual methods and tools to provide us with all the data we need. In this post, I will show you some of the native tools to help you monitor Sitecore containers.
The docker stats command display a live stream (updated every second) of running containers resource usage statistics docker stats:
- CPU % – the percentage of the host’s CPU the container is using.
- PRIV WORKING SET – refers to the total physical memory (RAM) used by the process.
- NET I/O – the amount of data the container has sent and received over its network interface.
- BLOCK I/O – the amount of data the container has read to and written from block devices on the host.
In this post, I will show you some useful commands and tips for managing your Sitecore containers, images and other docker resources that get created when standing up your containers. The Docker documentation is awesome but it is fairly extensive so I’ll cover some useful commands you should be familiar with.
PS> docker container ls – lists running containers by default, you need to use -a flag to list all containers not just running containers. You can use -f flag to filter containers.
PS> docker container ls -f “name=93x*”
If you want to see the most recently created use -l flag.
If you have built your Sitecore container images and they reside locally and you want to share them with your team the recommended approach is a private registry and there are a few services available. However, Azure Container Registry (ACR) allows you to store docker images in repositories and can take advantage of the azure pipelines to automatically rebuild these images when they need to be updated. In this post, I will show you how to push your local images to a private ACR. This also works if you need to move your images from one private registry to another.
If you are running Sitecore in a container then you’ve most likely switched Docker desktop to Windows container mode. But what if you want to run a Linux container simultaneously? For example, you might want to fire up, JMeter and Grafana on Linux containers. It turns out this is possible in your local development environment and is fairly straightforward.
Don’t worry this is not another post about running Sitecore in a container! No this is a post about getting the Sitecore HabitatHome demo solution up and running quickly and I mean quickly without too much effort. I just happen to use docker in the process. HabitatHome is a solution built using SXA on Sitecore XP following Helix principles. It is extremely useful if you need to showcase SXA capabilities to an existing or a potential new customer.
This is where my good friend Andy Uzick found himself a few weeks ago but had already started down the path of standing up the SXA HabitatHome demo on a temporary Azure PAAS instance not using docker. I thought with docker surely this would be much easier.
Okay, so we all know the difference between Renderings and Final Renderings right? Final renderings were introduced in Sitecore 8 to make it possible to have different layouts for the various language and versions of an Item. Awesome!!
- __Renderings – a shared field where you specify the common layout for all languages and versions of the item.
- __Final Renderings – a versioned field where you specify individual layouts for languages and versions of the item.
I ran into an issue where I needed to modify the __Final Renderings for specific templates. A parameter of a component for a specific language in use on a site, needed to be updated. Continue reading
Okay, so we all love and appreciate something that has been packaged up nicely. There are some really useful features built into Sitecore package designer that can make a huge difference in the packages we create and even save us time.
Saving & Opening Existing Packages
If you have spent time creating a package you should save it so that if you need to modify it later, you can. After you have generated and installed the package but discover you have forgotten to include something rather than go through the pain of creating a new package you can simply open the existing package. Opening a package allows you to modify the items contained in the package or add new items. This is a no-brainer. Continue reading
Often while working on projects, a team member may ask you to share your local Sitecore instance with them. Or you might even want to expose your local site to an external service for performance testing/analysis. There is a handy dandy tool that makes this really easy, ngrok. Using secure tunnels ngrok exposes local sites behind NATs and firewalls to the public internet. By connecting to the ngrok cloud service which accepts traffic on a public address and relays that traffic through to the ngrok process running on your machine and then on to the local address you specify.
There are various plans available including a free plan which supports:
- HTTP/TCP tunnels on random URLs/ports
- 1 online ngrok process
- 4 tunnels/ngrok process
- 40 connections / minute
With support for Sitecore 8.2 coming to an end 31st Dec 2019, several clients are planning their migration to Sitecore 9 if they have not done so already. This post describes the process and some of the tasks involved in upgrading from Sitecore 8x.
There are two main approaches when upgrading you might consider:
1. Upgrade existing instances – the upgrade is performed against the existing instances and rolled out to all environments.
- Additional infrastructure is not required for the upgrade
- Usually Requires a code freeze while the upgrade is rolled out to all environments.
- Unanticipated Issues can arise during the upgrade that can cause delays in the development lifecycle.
2. Clean Approach – setup a clean environment and clean Sitecore instances, migrate data.
- Upgraded and tested in isolation of the current production instance.
- Provides an opportunity to upgrade the OS & SQL.
- Easily rollback if issues occur.
- Code freeze to existing solution not required for the entire duration of the upgrade and bug fixes and new features can be rolled out and worked on in parallel to the upgrade.
- Additional Infrastructure is required for the new environments to run in parallel. We would need to spin up new servers to support the new environment as these would be running on different versions of the operating system and version of software to meeting the requirements of Sitecore 9.
- We will have the additional overhead of managing two sets of environments for a period of time while.
The clean approach effectively means you a Sitecore 8x environment – current site and a brand new Sitecore 9 environment – for the upgraded site.
Once you have switched over to 9 you can decommission the old environment. Continue reading