The official Apache Geode Docker image lives here on Docker Hub:

https://hub.docker.com/r/apachegeode/geode/

Each Geode release pushes a new Docker image to that page. If you look at the tags tab on that page, you'll see links to images for recent releases. At the time of this writing, the latest is for Geode version 1.12.0. The Dockerfile for version 1.12.0 is also linked from Geode's Docker Hub page.

That version of the Geode Docker image defines a single CMD and no ENTRYPOINT. The CMD is:

CMD ["gfsh"]

So with no arguments, running the official Geode image like this:

docker run -it --rm apachegeode/geode

Puts you into an interactive gfsh prompt. You can type version at that prompt and see the Geode version, and you can type quit to exit gfsh (and exit the Docker container.)

Unfortunately, since the official image defines a CMD and no ENTRYPOINT, there is no convenient way to run gfsh commands via the image. Here's what you have to do, e.g. to get gfsh to run its "version" command for you (non-interactively):

docker run --entrypoint gfsh --rm apachegeode/geode -e version

We set the ENTRYPOINT to gfsh. All the content after the image name ("apachegeode/geode" above) is sent to the gfsh command. We use the gfsh -e option to execute the script non-interactively. The script is just the "version" command.

We can use the same technique to start a locator:

docker run --entrypoint gfsh --rm apachegeode/geode -e "start locator --name=Locator1" -e "start server --name=Server1"

The problem with this is that as soon as gfsh has run the script(s) (in this case starting a locator and a cache server) gfsh exits and the container exits. Not very useful!

To start a locator and cache server non-interactively and leave them running takes a bit more fiddling. One approach, which is used in the Geode SNI acceptance tests (e.g. SingleServerSNIAcceptanceTest.java) is to start a Geode container that isn't actually running any locator or cache server—instead it is just running an infinite loop.

Here's how it works. That test is using the Palantir DockerComposeRule to use docker-compose to start the services defined in a docker-compose.yml file. If you look at the geode service defined there:

You'll see that the entrypoint and command conspire to run the forever script in that geode container. The crux of that script is:

#!/usr/bin/env sh
while true; do sleep 600; done

That's a script that sleeps 10 minutes at a time, and when it wakes up, it goes back to sleep again. Forever.

You can do the same thing without docker-compose of course. It's just convenient to use docker-compose for starting and stopping services (and dependent services too).

Here is how you can start a Geode container that's blocked in a forever loop (I am running this from the ./geode-assembly/src/acceptanceTest/resources/org/apache/geode/client/sni directory in a clone of the Geode repository):

 docker run -p 1099:1099 -p 10334:10334 --name geode -v $PWD/scripts:/geode/scripts --entrypoint sh --rm apachegeode/geode -c /geode/scripts/forever

If you run that it'll block. You can open another terminal and use docker exec to run commands inside that running "geode" container.

This is where gfsh comes in. Remember when started a locator and server via gfsh -c above, only to have gfsh and our Docker container exit? Well we can run that exact gfsh command, this time via docker exec instead of docker run. We'll run the command inside the already running container so it'll be ok for gfsh to exit—our container will keep running, along with our locator and cache server processes:

docker exec geode gfsh -e "start locator --name=Locator1" -e "start server --name=Server1"

And now our locator and cache server are running in the geode container. You can verify this, if you have gfsh installed on your host. I've got one built from sources:

$ ./geode-assembly/build/install/apache-geode/bin/gfsh
…
gfsh> connect
Connecting to Locator at [host=localhost, port=10334] ..
Connecting to Manager at [host=172.17.0.2, port=1099] ..
Could not connect to : [host=172.17.0.2, port=1099]. Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: 172.17.0.2; nested exception is: 
java.net.ConnectException: Operation timed out (Connection timed out)]

Well I've got some work to do there! But you can exec sh inside the geode container and look at the logs:

docker exec -it geode sh

Check out /Server1/Server1.log and Locator1/Locator1.log and run ps to see the two Java VMs running your Geode processes.


  • No labels