Docker-Based MEAN.JS w/ Mongo Replica Set Automation on Any Cloud

A user who signed up to try DCHQ.io Hosted PaaS a couple of days ago asked me if we had an out-of-box template for MEAN.JS. So I told him that we’ll build a basic template for him before checking if there were any official images on Docker Hub.

Luckily, I came across the MEAN.JS official GitHub project, which had a Dockerfile and a Docker Compose template. So I went ahead and modeled the template on DCHQ and connected the Node.js container to a Mongo Replica Set. Here are the key advantages in the DCHQ app model:

• The Mongo Replica Set and the Node containers can run on different hosts in order to comply with affinity rules. This is possible because of our integration with Weave and the host parameter that we have introduced to the Docker Compose app template.
• The container IP for Mongo’s primary node is resolved dynamically at request time and is used in configuring the development.js file on the Node.JS container. This avoids container name conflicts if a compute resource is shared with many developers.
• A BASH script plug-in is used to configure the Mongo Replica Set on the primary node using the container IP’s of the secondary nodes that are resolved at request time.

DCHQ simplifies the containerization of applications and makes it possible to replicate very complex application environments on multiple hosts through a one-click deploy button. DCHQ does not just automate the application deployments, but it also integrates with 12 different cloud providers to automate the provisioning and auto-scaling of Weave-enabled clusters consisting of distributed virtual machines.

In this blog, we will go over the deployment automation of a Docker-based MEAN.JS stack that’s connected to a Mongo Replica Set.

First, we’re going to build the Node.js image of the MEAN.JS stack by navigating to the Builds section and then clicking on the + button to select Git. The required fields here are:

• Git URL of a project that has a Dockerfile and all the associate artifacts. In this case, we’re using the official MEAN.JS project (https://github.com/meanjs/mean) 
• Cluster to be used for creating the image. The DCHQ agent automates the build or Docker image creation on one of the hosts in the cluster.
• Registry for pushing the new image. This can be registered by navigating to Manage > Repo & Cloud Provider. A user can register his/her account with Docker Hub in order to start pushing to his private or public repositories.
• The actual repository name
• The tag for the new image (e.g. latest)
• (Optionally) A cron expression can be provided to schedule the creation of images from this Git project.

Once the image has been pushed to your repository, then we’ll navigate to Manage > Templates to create the application template for the MEAN.JS stack.  Here are the key things to notice in this template:

• The Node.js image is being pulled from the newly created image that we pushed to dchq/mean
• We’re invoking a BASH script plug-in in the Node.js container to add the following line in development.js file at request time – uri: 'mongodb://$MONGO_IP/mean-dev',
• You will notice that $MONGO_IP is resolving the container IP of the primary Mongo node at request time as indicated by the environment variable MONGO_IP={{mongo_rs1_srv1 | container_ip}}
• The primary node of the Mongo Replica Set (mongo_rs1_srv1) is invoking a BASH script plug-in to initialize the replica set using the container IP’s of the secondary nodes that are resolved at request time.

Additionally, the host parameter allows you to specify the host you would like to use for container deployments. In this example, we split out all the containers of Node.js and the Mongo Replica Set on different hosts. Here are the values supported for the host parameter:

• host1, host2, host3, etc. – selects a host randomly within a data-center (or cluster) for container deployments
• <IP Address 1, IP Address 2, etc.> -- allows a user to specify the actual IP addresses to use for container deployments
• <Hostname 1, Hostname 2, etc.> -- allows a user to specify the actual hostnames to use for container deployments
• Wildcards (e.g. “db-*”, or “app-srv-*”) – to specify the wildcards to use within a hostname

A user can deploy this application by navigating to the Self-Service Library and then clicking on Run to deploy the application on the user’s default cluster (or data center). The default cluster needs to be Weave-enabled in order to facilitate the cross-container communication across different hosts.

You will notice that the Node.js (or MEAN.JS) container is running on one host while the Mongo Replica Set containers are running on another host. The Mongo Replica Set container ports are not exposed on the host. The Node.js container however is exposing port 3000 on the host using port 32779.

Once the application is up and running, a user can monitor the CPU, Memory, & I/O Utilization of the running containers and perform day-2 operations like Backup, Container Updates using BASH plug-ins, Scale In/Out and Continuous Delivery.

Alerts and notifications are available for when containers or hosts are down or when the CPU & Memory Utilization of either hosts or containers exceed a defined threshold.

Sign Up for FREE on DCHQ.io Hosted PaaS  (http://dchq.io) to get this template along with other templates like Java, PHP, Ruby, Python, and many others.