At times, it is important to do manual testing on a running server, and in many
cases it is a good idea to test in a clustered environment to ensure that features
play nice both locally and across nodes. To lower the barrier for realistic local
testing, there is a script at dev-tools/scripts/cloud.sh
.
Note
|
This script only supports POSIX environments. There is no similar .bat script at this time. |
Typical usage of the script is:
-
Copy the script to a location outside the
./solr/
working copy such as<GIT_CHECKOUT>/../solr-testing
. Trying to use it from within the working copy will leave you fighting version control to avoid checking in files. -
Edit the script to provide a proper back reference to your working copy for
DEFAULT_VCS_WORKSPACE
(the default is../code/solr
) -
Start a local zookeeper instance. This zookeeper must be running on localhost, but the port can be adjusted with a
-z
option passed to the script.docker run -p 2181:2181 zookeeper
is one option to start up a local Zookeeper. -
run
./cloud.sh new -r
The command in the final step will:
-
Recompile and package (
-r
) the solr checkout found atDEFAULT_VCS_WORKSPACE
(but not run the tests). -
The tarball produced by step 1 is then extracted in a directory that is a peer to cloud.sh and named for the current date (such as
./2021-02-21
). -
A node at the top level of zookeeper is created and named for the canonical path of this directory to serve as a zkchroot for this deployment.
-
Start solr on ports 8981, 8982, 8983 and 8984 with listening debugger ports on 5001, 5002, 5003, and 5004.
-
Each solr instance will place its data and solr.log in a corresponding directory such as
./2021-02-21/n1
,./2021-02-21/n2
etc.
The script supports start
, stop
and restart
commands, and a variety of options
detailed in the extensive introductory comment in cloud.sh.