Woof, that previous post was a lot. A whole lot to ingest. So now we’ve gone through some pretty basic image creation, we understand some of how the Dockerfile works and honestly, I think we’re ready to rock and roll with some more advanced stuff. Let’s talk solr 🙂

As of this writing, the solr Docker Image is built on three layers:

  1. Windows Nano Server
  2. Open JDK
  3. Sitecore solr

We’ve already downloaded the first image from a previous entry. Here’s a link back in case you missed it. Next up, we’re going to build upon that with the JDK Image, which includes basically downloading and installing JDK, and setting the JAVA_HOME variable. See the contents of the Dockerfile located in \windows\dependencies\sitecore-openjdk:

There’s nothing new in here, aside from the ENV command, which does what you think. It sets an environment variable. We can build this image from the following line:

Nothing mystical about that either. But we’re not done yet. We need solr! If you open the Dockerfile at \windows\9.x.x\sitecore-xm-solr, you see much of the same:

Oooh! There are a couple new commands in place:

  • USER – This performs the next commands as a specific user. In this case “Administrator”. For an explanation, although brief, of the differences between “Administrator” and “ContainerAdministrator, check this SO article.
  • EXPOSE – This opens a specific port to the host (your machine). This makes sense here since solr runs on port 8983 and you see the Boot.cmd noting as much.
  • CMD – This is like RUN, but it happens when the container starts, rather than during the container creation process. Think of your old command.com or the Startup menu in Windows.

Let’s build this image now:

Whoa, that’s a bit more. One thing to point out about our build-args. Notice that BASE_IMAGE here is the previous image we just created above. This creates a layering that looks like this:

Really wanted something more healthy….

Told you layers were Yum. Let’s view a list of our Images again. Run docker image ls, and you’ll end up with a docker image list of the following quality:

Look mom, solr Images!

Why is this so exciting? First of all, if we want to have another version of solr running, we don’t need to go through the hassle of making another JDK image. We can use the same one as before, just provision another solr image using it as the base. See that flexibility? I knew you’d love it too.

Now that we’ve provisioned a solr image, it’s time to make a container! Whee! Following the Sitecore analogy, we’re going to create an item from our template. It’s time to use another docker command called “run” which essentially will provision a new container. Let’s look at the command and then I’ll explain the parameters:

  • Publish – This opens and maps a port. When I request the host port 44011 (in a browser for example) then I need to redirect that port to 8983 for the TCP protocol.
  • Mount – This parameter creates a folder share map between the host and the container. Useful for getting files out of the Container. We’ll talk about the other direction later, though. The Source folder being local, the Target folder being inside the container. Notice the flippy of the slashes. This matters. Also, the Source folder has to exist when you create the container. If it doesn’t, you’ll get an error like “Error response from daemon: invalid mount config for type bind

The last item in that list is the image name “sitecore-xm-solr:9.2.0-nanoserver-1903” which you’ll recognize from the previous docker image build command’s “tag” parameter. All kosher now? When we run that, we’ll see a whole slew of text fly by, which vaguely looks like the starting of solr. You’ll even see the nice solr ASCII logo fly by.

I kinda love they have ASCII art in there. TBT on a Whatever Today Is

Open up a browser now, and head to http://localhost:44011 and you should be greeted with the friendly solr admin screen. Did ya? Good! You have successfully run solr in a container. Now go check the folder that you mounted above. Do you see the indexes in there? If so, then things are looking good! Even cooler, if you watch your powershell window, you’ll see logs streamed right to it:

HttpSolrCall means someone is doing something!

That’s good and all, but…uh what about my command prompt? Hit Crtl+C to break away from the container. Note: this doesn’t stop the actual container. It just gives you control back. In the future, if you append a “-d” flag, it will run in detached mode, aka the background.

Feel free to run a docker container inspect on it, and you’ll notice the following values:

This confirms both our port binding and our mount. Now let’s delete it.

Wait, what? You heard me, let’s delete this container. After all, it’s easy enough to make it again, right? Right. So how do you delete it? Simple enough, once we find the container Id.

Notice the Container ID on the far left. To delete the container, we can do the following:

Running docker container ls again, you’d notice it’s gone. Yay! But why did we do that? If you also look to the right of the screen above, you’ll see a column called “names” with some random words in there (competent_jepsen). This is the auto-generated name for the container. You can change this, however, and we will!

Notice the new “name” parameter. This will allow you to give memorable names to your containers rather than having to auto-generate them or find the fancy container ID. Also, I gave the “-d” parameter so I can get my prompt back. After running that above, you should see the container listed with the new Name specified.

Well that makes more sense.

Now I can reference this container by name, and that name makes sense. I think that about wraps up the solr container. Let’s leave it running and move on to Part 7: Smooth as SQL.

The TL;DR Code

This is a post in the "Yet Another Sitecore Docker Series." Other Posts include