Note: This blog post is related to the legacy Containership Platform and the content is no longer relevant.
It has been a while since we made a post in our “on ContainerShip” series. Today we are excited to release our latest distributed database integration, with HazelCast. You might remember the previous installments we did in this series covering Aerospike, Crate.io, and Cassandra.
HazelCast is an open source in-memory data grid based on Java. It has use cases in caching, as a NoSQL data store, an in-memory data grid, and web session clustering. In this post we will go over the steps you need to take to get your own Dockerized HazelCast cluster running.
Since we wrote our previous on ContainerShip posts our UI has changed pretty substantially, and we have released our integration marketplace that makes it easier than ever before to run distributed systems on your ContainerShip clusters. This video will help get you acquainted with how the new UI works as well as the marketplace.
The first thing you need to do before you can get started with HazelCast is to launch a ContainerShip Cluster on your hosting provider of choice. Luckily it only takes a few clicks with ContainerShip Cloud. If you need help getting up and running, our official documentation is where you want to go first.
Once your cluster is running, you need to visit the integration marketplace within ContainerShip Cloud. You can use the filter options at the top of the page to show only databases, or you can search for HazelCast directly via the search box.
Once you have located HazelCast, click on the Add to Cluster button.
After clicking on Add to Cluster a modal will pop up that will ask you which cluster you want to deploy HazelCast to, and the amount of CPU and memory resources to give to each container in the cluster.
After clicking Add to Cluster, you will be redirected to the cluster overview for whichever cluster you decided to deploy to and will see hazelcast listed as one of the applications running on the cluster.
It may take up to a minute for the containers to start as docker needs to pull the image from the registry before it can run.
You will notice that there are 2 containers running for our hazelcast application by default.
This is because we are launching this application and setting the per_host constraint to 1, which forces one container to live on each follower host in our ContainerShip cluster.
Clicking on the application will take you to it’s detail view where you can see the constraint being set. Editing this constraint and setting it to two will force two containers of the application to run on every follower host.
As you scale up your ContainerShip cluster, HazelCast will automatically be scaled up with it.
In ContainerShip, every application is given a public DNS entry that updates automatically as you scale up or down. This DNS entry can be found in the application detail view.
By default the hazelcast application will be accessible using this DNS entry along with the application specific discovery port. If you would like it to be accessible on a specific port, you will need to create a load balancer.
As you can see, setting up HazelCast and any of our other integrated distributed systems is incredibly easy thanks to the integration marketplace and automation. Now that your database is up and running, you may want to back it up for safe keeping so you can restore it later, or look into launching your other supporting services along side it!