aka the Docker Post I wish someone had written before I had to. No servers, no service subscriptions, no configuration. Let’s just get into it.
This is part 1 in a series about Sitecore and Docker.
- Part 1: Docker for Dummies - Docker 101 or Docker basics…
- Part 2: Docker for Dummies - Setting Up Sitecore Docker Images
- Part 3: Docker for Dummies - Deploying and Debugging your Visual Studio Solutions (using Sitecore and Docker)
I’m not the first person to pick up new technology as it arrives. I’m really not. And while I’m writing today about Docker and this can hardly be called new by any standard, it is new to me. And it is new to a lot of the people I hang out with. So I’m just going to assume, it’s new to a lot of us.
Seems odd to start with this, but I might as well get it out of the way. There are a lot of this around Docker that I do not fully understand yet. There’s even more that I probably will never bother to get fully into the details of. This weekend marks my first succesful experience with Docker, and I’ll explain how I got here to help you get here as well. Nothing more. Not now.
So expect some practical advise on how to get started; don’t expect any “why” or “what next”.
Without further ado…
How about I tell you what it’s for, to begin with. This is what will motivate you to read on.
Ever had problems getting your local Sitecore development environment up and running, in this post-SIM age? Ever struggled with getting the right certificates trusted, get that https:// connection to Solr going, get those durned Sitecore Commerce Business Tools installed correctly? Now ever tried to do all of the above in an identical consistent manner across a 5 man development team?
If you’re grinding your teeth right about now, Docker is for you.
Docker is a way for you to represent, configure, manage, and run all the infrastructure required to spin up a modern day Sitecore XM. Or XP. Or Publishing Service. Or all of the above. You don’t really need to understand the hows and the whys of this unless you’re tasked with actually setting up this infrastructure. For now let’s just focus on consuming it, the setting up bit is largely being done by a very enthusiastic Sitecore Docker Community - thank you so much for that :-)
So with Docker, you will be able to spin up all these services (in Dockeresque they’re called “containers”) that you need, like a SQL Server 2017 Developer Edition, a Windows with IIS and .NET, some .NET Core for your xConnect, and so on and so forth. By spinning up I mean getting these services up and running and interconnecting (in containers), allowing you to run your Sitecore as if you’ve already put in the hours, and blood, and sweat, and tears, of installation time and gotten your local environment running.
And once you’re done. Or you’re switching to another client. Or you’re taking off for the day. You just tell Docker to tear the whole thing down, and it’s gone. Nothing (almost true) is left over, your machine is “clean” again. Go ahead and switch to another directory where your other client project resides, this time on Sitecore 8.2 running SQL 2016 - not a problem. Spin it up and you’re on your way.
Let’s start with some basics. And a few assumptions.
- I am on Windows 10 Pro build 1903. I will make no attempt to sugar coat this post to accomodate anything else (another way of me saying, I don’t know how to help you otherwise :D)
- I have enabled Hyper V services in Windows. You need Intel Virtualization enabled in your BIOS for this. Google it if you have to.
- I have chocolatey installed. So should you. This is no time to be afraid of the command-line.
Right let’s go. If not stated otherwise, I am assuming you run commands listed here in an elevated PowerShell Command Prompt.
Just to make sure we’re all set, start by relaxing your local PowerShell a bit. Chill.
Set-ExecutionPolicy -ExecutionPolicy UnRestricted
Then it’s time to get Docker involved.
choco install docker-desktop -y
I can’t actually recall if it forces a reboot on you at this point. In any event you are going to need to restart your PowerShell command prompt.
Once back, switch to somewhere you like (I use
D:\docker-experiments but whatever floats your boat).
And in keeping with time honoured tradition
docker pull hello-world
If all is well, you should be pulling the docker image “hello-world” from the Docker Hub. I’ve done it a couple of times, so for me the output looks like this. Yours will vary a bit.
Moment of truth
docker run hello-world
Which should produce the following result:
It’s not much, I know. But since when was a “Hello World!” ever supposed to be much more?
I am not blind to the irony I am about to present you with. But I would really recommend your next step be, spinning up something real and useful (all things being relative) - and I want you to not worry about all the intricacies of what comes next, the building of images more complex than hello-world.
So instead I’m going to show you how to get WordPress up and running in just a couple of minutes 😁 I did warn you about the irony.
So for our hello-world example, things were quite simple. For an application such as WordPress, it gets slightly (only slightly) more complicated. WordPress relies on an underlying database server, in this case MySql. So to get things going, we’re going to need to spin up 2 containers - one for MySql and one for WordPress. Don’t worry about this for now, consider a docker-compose file much like a manifest or a service-order of things you’d like Docker to provide for you.
As we know, WordPress is Open Source, so images and docker-compose files are already made for us and freely available. For this example, I’m going to use this one.
Open up VSCode or whatever strikes your fancy, and paste this text in. Save it as
Don’t worry too much about what’s going on here, but since this post is For Dummies, I’ll give you the Executive Summary:
Two services (containers) are requested:
- db (MySql 5.7)
- wordpress (latest version)
And a little bit of configuration
- MySql is configured with some known passwords (don’t roll these out in production lol)
- WordPress is configured with a dependency on MySql (db) and with matching passwords
- Docker is instructed to map port 8000 to the WordPress container port 80
(I know I’m simplifying. That’s literally the point)
Right. Let’s spin this up. Don’t forget to save the file like I mentioned above.
docker-compose up -d
You’re telling Docker to run your compose file (docker-compose.yml is the default filename,
-d tells Docker to “let go” of it when fired up and give you your command prompt back).
You should see something like this.
Now wait a minute. Or two. WordPress and MySql are setting themselves up - this only happens the first time.
Then fire up a browser and go to
http://localhost:8000 (remember, Docker was instructed to send that to port 80 on WordPress). You should see the following.
If you’re so inclined, go ahead and play around with WordPress for a while.
When you’re done, go back to your PS and instruct Docker to tear this whole thing down again.
For some reason, MySql takes a long while to shut down. But wait it out, and you should see this.
And voila. WordPress is gone and we can move on to bigger and better things :-)
That’s it for part 1. I hope this is of some use to you. Especially those of you who, like me, have been lurking around Docker for a while but never really mounted up enough momentum to actually take it for a spin.