The integration setup has as a primary goal the ability to quickly debug the Druid image and any individual tests. A first step is to move the image build into a separate project. A second step is to ensure each test can run in JUnit in an IDE against a cluster you start by hand.
This section discusses how to use the various debugging features.
See:
Ease of debugging is a key goal of the revised structure.
shared
directory when the test does not make permanent changes.log4j2.xml
file in the shared directory to increase the logging level.When run in Docker Compose, the endpoints known to Druid nodes differ from those needed by a client sitting outside the cluster. We could provide an explicit mapping. Better is to use the Router to proxy requests. Fortunately, the Druid Console already does this.
Modern Docker seems to hide the output of commands, which is a hassle to debug a build. Oddly, the details appear for a failed build, but not for success. Use the followig to see at least some output:
export DOCKER_BUILDKIT=0
Once the base container is built, you can run it, log in and poke around. First identify the name. See the last line of the container build:
Successfully tagged org.apache.druid/test:<version>
Or ask Docker:
docker images
You can log into the Docker image and poke around to see what's what:
docker run --rm -it --entrypoint bash org.apache.druid/test:<version>
Quite a few environment variables are provided by Docker and the setup scripts to see them, within the container, use:
env
To debug an integration test, you need a Docker image with the latest Druid. To get that, you need a full Druid build. So, we break the debugging process down into steps that depend on the state of your code. Assume DRUID_DEV
points to your Druid development area.
If you need to rebuild Druid (because you fixed something), do:
See quickstart for the commands.
Again, see quickstart for the commands.
To run from your IDE, find the test to run and run it as a JUnit test (with the cluster up.)
Depending on the test, you may be able to run the test over and over against the same cluster. (In fact, you should try to design your tests so that this is true: clean up after each run.)
The tests are just plain old JUnit tests that happen to reach out to the test cluster and/or Docker to do their work. You can set breakpoints and debug in the usual way.
Each test will first verify that the cluster is fully up before it starts, so you can launch your debug session immediately after starting the cluster: the tests will wait as needed.
When done, stop the cluster: quickstart again for details.
For the most part, you can stop and restart the Druid services as often as you like and Druid will just work. There are a few combinations that can lead to trouble, however.
rm -r target/<category>/db
before restarting the DB container.