A new option for developer Solr installs

One of the interesting changes that's part of the coming release of Sitecore v9.3 is the integration of the Solr installation into the SIF scripts for developers. Given I've had a go at doing this myself in the past, I thought it would be interesting to look at their approach and see how it works...

This investigation was based on the "super-secret MVP Preview" of the release, so it's possible this may change a bit before it's released officially...

How is it integrated? url copied!

There's a new SIF file named `Solr-SingleDeveloper.json` which you get in the setup files bundle. This is the setup process for a simple developer's Solr instance. You run it in the same way you have been doing for the `Prerequisites.json` file up until now:

Install-SitecoreConfiguration .\Solr-SingleDeveloper.json

					

So you can take this json, install SIF v2.20, and use them to set up Solr on your developer machine - or onto a remote machine if you don't want your copy of Solr locally.

There are a pile of parameters declared at the top of this file. There are a set that you'll probably want to edit for your installs:

• SolrVersion: Which version of Solr do you want to install? For v9.3 you're going to need v8.1.1, but in theory this can work with other versions if you need it to.
• SolrDomain: The DNS name for your Solr instance, which is used to create the SSL certificate. Sitecore wants Solr to run under SSL, and this is the name it will access.
• SolrPort: The network port that Solr will serve requests from. Defaults to 8983, but you can use whatever you need. This is also part of Sitecore's solr connection string.
• SolrServicePrefix: When the Windows Service to run Solr is set up, this prefix is added to its name. Helpful if you need to run multiple copies of Solr for different Sitecore instances. (Note you probably want to end this with a hyphen, as you'll see below no separator is added after this string)
• SolrInstallRoot: Where do you want the Solr files to be put. Comments in the script say that this should be a root folder, such as C:\\Solr (note the double backslash encoding there) and the service prefix above, and the solr version will get appended to make the final folder name.

And then there are some you probably don't need to adjust for most installs:

• SolrSourceURL: Where to download Solr from – points to the Apache archive by default, but maybe you want to download from elsewhere.
• JavaDownloadURL: Sitecore seem to have hosted a download for Java in their own Azure Blob Storage account, but you might want to download a different release from elsewhere. They're using a RedHat java release, rather than either Oracle or OpenJDK versions I've tended to use.
• ApacheCommonsDaemonURL: This is the tool being used to run Solr as a service, and is being downloaded from the Apache Archives by default.
• TempLocation: Where the script saves downloads. $Env:Temp by default - or your own choice.
• ServiceLocation: Where the registry entries for Windows Services live.

How does it deal with Java? url copied!

As mentioned, this script is using Redhat's OpenJDK rather than Oracle's or the Github version. The tasks configured in the script download the appropriate file and unzip it to your chosen setup folder. I note that the configuration for Solr is rewritten to change the Java home path in config – so this is installing a private copy of java for this particular instance of Solr.

That's not the way I've tended to do this in the past – but it's an interesting idea. If you make use of other things requiring Java, and have issues with version conflicts this could be very useful.

And because of that it doesn't do any of the environment variable setup that I've tended to do in the past.

Certificate url copied!

The config above defines the DNS name for the certificate, and there's a task in the script to generate a file from this. This code makes use of the Java certificate tools rather than the PowerShell ones that the rest of SIF (and my scripts) use. Don't think it makes any difference – but it's a different approach to my "sign it with the same root certificate that SIF uses" from last time.

It still ends up with a trusted PFX file, though.

Solr url copied!

The Solr install is nothing out of the ordinary – download it, unzip it, and rewrite the configuration.

Though interestingly the config-writing code seems to append the changed config to the end of the file – rather than my usual trick of replacing lines to remove the "REM" from the start and set their values.

It also seems to test things like the port number, and not install if they're not free – which is a helpful safety check.

Services url copied!

This is another area where this script takes a different approach to the one I've used before. Rather than my usual NSSM solution, this script makes use of the Apache Commons Daemon. That seems to be the "official" approach to running Java as a Windows Service.

But it seems like it works in a pretty similar way to NSSM in the end.

Outcome url copied!

So what happens when we fire it up? Well, in the first instance you get a pretty standard SIF window:

And when that process finishes, you end up with a folder full of Solr:

You can see the folder has been created under the "SolrTest" folder that I specified in config, and it's put the service prefix of "SIF-Test" on the front of the "solr-8.1.1" folder name as described above...

And there's a similarly named service:

And it does indeed leave you with a happily running server.

One thing this script provides that I never got around to was uninstall support via SIF. If you run

Install-SitecoreConfiguration .\Solr-SingleDeveloper.json -Uninstall

					

Then it will remove the service and the folders.

So overall, a useful addition to your developer-install arsenal, and gives some interesting insight into alternative approachs to those I've tried before...

↑ Back to top

• Feel like sharing?
• ⇒ On BlueSky
• ⇒ On LinkedIn
• ⇒ On Mastodon
• ⇒ On Email