Sometimes I’m a smart guy. Then there’s other times. I’ll let you be the judge of which time that is. I’ve been doing docker for my local environment for a while. Enough to simplify the process and find something that works for me and for the dev team here. One of my devs, however has been struggling with solr. Same image. Same setup. Same code base. Same literally everything aside from the machine we’re on. This kinda flies in the face of docker though and how it should remove the “works on my machine!” crap.

Needless to say, this was pretty frustrating. Looking at the solr logs, I saw the following initial error:

ZooKeepeerServer not running

That seems pretty important considering this is SolrCloud we’re talking about. You need this to run. Further on down the log file, there’s this set of shenanigans:

CoreContainer is either not initialized or shutting down

Ok, so that’s not amazing either. In fact, anytime Sitecore tries to use solr, that’s solr’s stupid face response. It’s super annoying.

Now, I was seeing the same first message, but not the second message. Why? I don’t know. I noticed a blog post over on Jeremy Davis’ blog with the EXACT SAME THING! This sparked me to ping him with a “oh dang yo, I’m getting this as well!” Much commiseration was had because we both had no idea why it was happening. There was some speculation that it might be related to the performance of the computer running. He was seeing it on a slower laptop, and my coworker had a slower machine than my own rig. Could it be that? I don’t now, but I wasn’t about to pour a ton of time into finding out.

The solve!

If we’re talking about a performance issue, there’s not going to be a fix that keeps us within the same topology (Solr+ZK in a single container). I think there’s a possibility of two options. One option would be to run ZK in its own container, and then configure multiple solr containers. There’s a few different guides out there, just a quick google away.

The other approach would be to remove zookeeper and run solr in standlone mode. Is that even possible? Uh, yes. It’s quite possible. We run the on-prem installs on solr, why wouldn’t it work here?

The only limitation is how the solr-init image works. It uses the RESTful API methods. If there was a way to run the solr-init without the API calls, we should be fine to swap to using standalone vs solrcloud.

Well, look no further: https://github.com/RAhnemann/sitecore-solr-init

Ok, so what do we have? Essentially, it’s a simple container that contains a template of a sitecore core and xdb core. Based on configuration, it will create the right cores by copying to new folders in your mutually-shared solr data folder. Phew, that was a mouthful!

There’s two main parts here: The mainfest.json and the Start.ps1.

The manifest.json is just that. A list of cores to create based on the topology. If you pop open the Start.ps1, you’ll notice it does essentially one thing. Copy the core template into your shared folder. That’s it. It grabs the list of cores from the topology you defined (xm, xp, xm-sxa or xp-sxa), copies the appropriate type of index (xdb isn’t the same as the regular SC ones), and viola. There’s of course, some environment variables, you’ll need to be aware of:

SOLR_CORE_PREFIX_NAME – The prefix of the cores. Default: sitecore

TOPOLOGY– Which topology do you want to use for your cores This maps directly into the manifest.json to determine what’s created. Possible Values: xm, xp, xm-sxa, xp-sxa. Default: xm

INCLUDE_REBUILD – Do you want to include rebuild cores? If you’re using the SwapOnRebuild provider, you’ll want to set this to “true”. Default: false

ADDITIONAL_SITECORE_CORES – If your solution requires additional cores aside from the ones defined, you can pass them in a pipe-separated list. These core names will get prepended with the prefix specified. Default is empty.

Note: If your additional cores require rebuild cores, you’ll need to specify them here, too. It will NOT automatically duplicate these additional cores, even if you set the INCLUDE_REBUILD flag.

ADDITIONAL_XDB_CORES – Same as the above, but for xdb-related cores without the schema enhancements. Default is empty.

Where do I get this?

I’ve published the images into docker hub: https://hub.docker.com/r/rahnemann/solr-init/tags

If you’re using the xm boilerplate solution I wrote about, you’re golden. If not, you’ve got a couple small tweaks:

1. Update your solr mode. Anywhere you see SOLR_MODE: solrcloud, update it to SOLR_MODE: standalone
2. Update your connection strings. Remove the ;solrCloud=true from Sitecore_ConnectionStrings_Solr.Search
3. Update your compose files. Based off the boilerplate solution, it would go from this:

  solr-init:
    isolation: ${ISOLATION}
    image: ${REGISTRY}${COMPOSE_PROJECT_NAME}-solr-init:${VERSION:-latest}
    environment:
      SITECORE_SOLR_CONNECTION_STRING: http://solr:8983/solr
      SOLR_CORE_PREFIX_NAME: ${SOLR_CORE_PREFIX_NAME}
    depends_on:
      solr:
        condition: service_healthy

To this:

  solr-init:
    isolation: ${ISOLATION}
    image: rahnemann/solr-init:1.0-servercore-1809
    environment:
      TOPOLOGY: xm-sxa
      SOLR_CORE_PREFIX_NAME: ${SOLR_CORE_PREFIX_NAME}
    volumes:
      - type: bind
        source: ${LOCAL_DATA_PATH}\solr
        target: c:\solr

A couple notes to watch:

• We removed the dependency on solr. Simplicity is better.
• We are binding to the same folder as the solr image. While we can have both mapped and running at the same time, we really shouldn’t need to.
• There are a bunch of tags out there, if you want to run this in your own isolation mode. Have at it.

When you run the container, you should see something like this in the output:

So how do you get to this simpler solr from an existing install?

1. Docker compose down
2. Delete the files in \docker\data\solr
3. Update your docker-compose files per the above
4. docker-compose -f .\docker-compose.override-init.yml up -d (this is for the boilerplate version… yours may differ
5. docker-compose up -d –remove-orphans
6. You’ll now need to log into Sitecore and rebuild your indices.

And that’s it. With this approach, you should have a less-bulky solr and a overall simpler topology.

Running into issues? Hit me in slack or drop me a note in the comments below.

OVERLY LATE UPDATE: If you’re looking to work with XM Cloud, there’s a small update you need to add the Horizons index. Your solr init would look like the below. Extra thanks to Gert for the find: https://ggullentops.blogspot.com/2023/02/xmcloud-sxastarter-local-setup-solr.html:

  solr-init:
    isolation: ${ISOLATION}
    image: rahnemann/solr-init:1.0-servercore-1809
    environment:
      TOPOLOGY: xm-sxa
      SOLR_CORE_PREFIX_NAME: ${SOLR_CORE_PREFIX_NAME}
      ADDITIONAL_SITECORE_CORES: _horizon_index
    volumes:
      - type: bind
        source: ${LOCAL_DATA_PATH}\solr
        target: c:\solr