In the previous post, you probably ran the following and had no idea what you were doing. If you did, shhhh and move along…

Some of this is pretty intuitive. Such as the “docker” part. “image” just means you’re working with Images. “build” does what you think. You are building an image with docker. I’m not making it up, folks.

Now things get a little trickier, you notice we are passing the following options:

  • Two Build-Args (You can have as many as you want)
  • One Tag
  • One Isolation level

We’ll talk about Build Args in a sec. Focusing on the Tag Option, that essentially allows you to reference the image later for builds. It’s nothing fancy except it names the repository first, then the image name second. In the example, the repository is “sitecore-assets” and the image is “9.2.0-nanoserver-1903”. Next is the Isolation. This for windows should always be set to “hyperv” because someone who knows a lot more about this said so, and I’m not inclined to argue much with them.

Looking at build-args now, to make sense of them, we’ll want to pop open the Dockerfile itself. The one sitting in \windows\9.2.0\sitecore-assets. When we do open this up, we see the following

It’s a bit much, yeah. Let’s eat the elephant one bite at a time, though.

This simply changes the escape character from back slack to back tick. Keep it spicy, guys.

These look sneakily like the Args passed in. HRM! Sure enough, the values from the command line are mapped into here. You can reference them later with a dollar sign, such as $BUILD_IMAGE

FROM is a fun one. This guy actually sets a new build stage. Anything run after this is run on that build stage.

SHELL does kinda what you think. Commands run after this will use whatever shell is defined here. We like PowerShell, though. From the bottom of our hearts.

RUN does kinda what you think. It executes something in the shell (which is now PowerShell. So it creates a new folder first in the C drive of the Image. Then it uses curl.exe (we love curl, too) to download some files into that directory. Nothing crazy so far, right?

This post is getting pretty intense. Time to:

OK, back on track:

COPY here is also pretty straight forward. All those zip files we had next to the docker file? They are going in the Image’s C:\downloads now. Same with the folder we had in the local file system called patches. Copy can reference the host’s file system, or even another Image’s file system.

Another RUN, this time to install 7-Zip.

More of the RUN command, just setting up some plumbing and installing utilities that we’ll need later. Again, since we’re layering, all this will be available to downstream images, and we don’t have to jack with it again.

Another simple COPY command to drop off some tools

If you remember from earlier, this is going to pop another Image out and the subsequent commands will run against that. All the previous commands are being run against the BUILD Image, which was from servercore. Now we’re running an new internal image from nanocore. I’m assuming this was for some space savings…

Ah, ha. So what we see here is that the COPY command is grabbing files from the build image (servercore) and copying them over to nancore. Again, hypothesizing this is for space constraints.

If you want to read through all the commands, you can head over to the build reference site.

Now that we understand the basics of a Dockerfile, let’s try to spin up a solr server. Try that out in Part 6: Simply Solr.

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