Hazelcast is a leading open-source in-memory data grid that provides distributed caching, computing, and data storage capabilities. As applications increasingly demand low latency and high throughput, Hazelcast’s cluster architecture helps scale horizontally with fault tolerance.

Docker Swarm, Docker’s native container orchestration tool, simplifies deploying and managing containerized applications across multiple nodes. Leveraging Docker Swarm for Hazelcast clusters enables resilient, scalable, and highly available deployments without the overhead of more complex orchestrators.

This post dives into the technicalities of containerizing Hazelcast clusters using Docker Swarm. We focus on best practices, configuration tips, and architectural considerations to help intermediate and advanced users build robust distributed systems.

Why Containerize Hazelcast with Docker Swarm?

Containerizing Hazelcast clusters using Docker Swarm brings several advantages:

  • Simplified deployment and scaling: Spin up new Hazelcast nodes as Docker services, scaling horizontally with ease.
  • High availability (HA): Docker Swarm manages node failures and automatically reschedules containers, ensuring cluster continuity.
  • Consistent environment: Containers encapsulate Hazelcast runtime and dependencies, preventing “works on my machine” issues.
  • Seamless networking: Swarm’s overlay networks enable Hazelcast members to communicate securely across hosts.

This approach is ideal for organizations seeking a lightweight orchestration solution that integrates naturally with Docker workflows and requires highly available Hazelcast clusters without complex infrastructure.

Preparing Your Hazelcast Docker Image

Start by building a custom Docker image tailored for Hazelcast:

  1. Use an official OpenJDK base image compatible with your Hazelcast version.
  2. Copy your Hazelcast configuration files (hazelcast.xml or YAML-based config) into the image.
  3. Expose Hazelcast cluster communication ports (default 5701).
  4. Include scripts for dynamic configuration if environment variables will influence cluster behavior.

Example Dockerfile snippet:

FROM openjdk:17-jdk-slim
COPY hazelcast.xml /opt/hazelcast/hazelcast.xml
WORKDIR /opt/hazelcast
EXPOSE 5701
ENTRYPOINT ["java", "-cp", "hazelcast.jar", "com.hazelcast.core.server.StartServer", "-config", "hazelcast.xml"]

Using environmental variables and entrypoint scripts, you can dynamically set cluster names, network interfaces, and discovery mechanisms at runtime.

Configuring Hazelcast for Docker Swarm Networking

Docker Swarm uses overlay networks that span multiple hosts. Hazelcast members must discover each other reliably within this network.

  • Disable multicast: Multicast is generally unsupported inside Docker Swarm overlay networks. Instead, use TCP/IP member discovery.
  • Leverage DNS-based discovery: Docker Swarm service names resolve to the IPs of running replicas, enabling Hazelcast nodes to find peers by service name.
  • Configure hazelcast.xml accordingly:
<network>
  <join>
    <multicast enabled="false"/>
    <tcp-ip enabled="true">
      <member>hazelcast-service</member>
    </tcp-ip>
  </join>
</network>

Here hazelcast-service corresponds to the Docker Swarm service name, which DNS resolves internally to all container replicas.

Deploying Hazelcast as a Docker Swarm Service

After building your image and configuring Hazelcast, deploy the cluster using Docker Swarm:

docker network create --driver overlay hazelcast-net

docker service create \
  --name hazelcast-service \
  --replicas 3 \
  --network hazelcast-net \
  -p 5701:5701 \
  your-hazelcast-image
  • Use --replicas to specify the number of Hazelcast members.
  • Attach the service to the overlay network to enable inter-node communication.
  • Publish the cluster port (5701) on hosts if external access is needed.

Swarm will manage container scheduling, ensuring that if a Hazelcast node fails, a replacement is started automatically, maintaining cluster health.

Handling Persistent Data and State

Hazelcast primarily stores data in memory, but persistence options exist for durability:

  • Use Hazelcast Persistence or WAN replication to replicate data safely across clusters.
  • For stateful applications, consider mounting Docker volumes to external storage for logs or configuration persistence.
  • Design your cluster topology considering network latency and data replication needs for optimal performance.

Monitoring and Scaling Hazelcast Clusters in Swarm

  • Use Hazelcast Management Center or open-source monitoring tools integrated into your Docker environment.
  • Monitor container health via docker service ps hazelcast-service.
  • Scale Hazelcast up and down dynamically using:
docker service scale hazelcast-service=5

This command adds two more members, and DNS-based discovery ensures immediate cluster integration.

Best Practices and Optimization Tips

  • Resource allocation: Assign CPU and memory limits per container based on workload.
  • Security: Use Docker secrets and encrypted overlay networks to secure sensitive configs and data in transit.
  • Logging: Centralize logs using Docker logging drivers or ELK stack for troubleshooting.
  • Health checks: Define custom health checks in your Docker service to automatically detect and recover unhealthy Hazelcast nodes.

Conclusion

Containerizing Hazelcast clusters with Docker Swarm offers a powerful, flexible path to building highly available, scalable in-memory data grids. By harnessing Docker Swarm’s lightweight orchestration and Hazelcast’s distributed architecture, you can achieve fault-tolerant deployments that adapt to changing workload demands.

This approach streamlines deployment, reduces operational complexity, and ensures your Hazelcast clusters remain resilient in production environments. Start building your containerized Hazelcast clusters today and unlock new levels of performance and availability for your distributed applications.