Solr Docker FAQ

Solr’s Docker image is pre-configured with container path /var/solr/ as a volume. What this means is that all index data, log files and other variable data will be persisted on the Docker host, even if you remove the container instance.

By default Solr’s volume is persisted in Docker’s default storage location on the host. On Linux systems this is /var/lib/docker/volumes. This is the recommended way to store Solr’s data. You have flexibility to use a bind mount host folder as well:

But this is both dependent on the host operating system and may run into different kind of file system permission issues.

While you could re-define SOLR_HOME inside the container, we instead recommend you to use the existing SOLR_HOME defined at /var/solr/, see above. You can give the volume a meaningful name instead of the auto generated hash, example name solrData:

Yes. You can simply start your Solr containers in "Cloud mode", pointing them to a Zookeeper Ensemble.

For local development, using a single zookeeper container is enough. Please consult the Zookeeper docker image for details.

For production purposes, we discourage rolling your own Zookeeper orchestration, as there are many pitfalls. Instead, use a well-supported container orchestrator with support for Solr and Zookeeper. For Kubernetes, we provide the Solr Operator sub project. There are also 3rd party Helm charts available.

See the docker compose example.

When starting the docker image you typically see these log lines:

If your set up can run without huge pages or you do not require it, the least-friction way to remove this warning is to disable large paging in the JVM via the environment variable:

In your Solr Admin UI, you will see listed under the JVM args both the original -XX:+UseLargePages set by the GC_TUNE environment variable and further down the list the overriding -XX:-UseLargePages argument.

The different invocations of the Solr docker image can look confusing, because the name of the image is "solr" and the Solr command is also "solr", and the image interprets various arguments in special ways. Let’s illustrate the various invocations:

To run an arbitrary command in the image:

Here "solr" is the name of the image, and "date" is the command. This does not invoke any Solr functionality.

To run the Solr server:

Here "solr" is the name of the image, and there is no specific command, so the image defaults to run the "solr" command with "start -f" to run it in the foreground.

To run the Solr server with extra arguments:

This is the same as the previous one, but an additional argument is passed. The image will run the "solr" command with "-f --host myhostname".

To run solr as an arbitrary command:

Here the first "solr" is the image name, and the second "solr" is the "solr" command. The image runs the command exactly as specified; no "-f" is implicitly added. The container will print help text, and exit.

If you find this visually confusing, it might be helpful to use more specific image tags, and specific command paths. For example:

Finally, the Solr docker image offers several commands that do some work before then invoking the Solr server, like "solr-precreate" and "solr-demo". See the README.md for usage. These are implemented by the docker-entrypoint.sh script, and must be passed as the first argument to the image. For example:

It’s important to understand an implementation detail here. The Dockerfile uses solr-foreground as the CMD, and the docker-entrypoint.sh implements that by by running "solr -f". So these two are equivalent:

whereas:

is slightly different: the "solr" there is a generic command, not treated in any special way by docker-entrypoint.sh. In particular, this means that the docker-entrypoint-initdb.d mechanism is not applied. So, if you want to use docker-entrypoint-initdb.d, then you must use one of the other two invocations. You also need to keep that in mind when you want to invoke solr from the bash command. For example, this does NOT run docker-entrypoint-initdb.d scripts:

but this does: