Tag Archives: Deploy

Deploy Ghost in a Docker Container through ElasticBox in 6 Easy Steps


In this post we are showing you how to deploy the Ghost blogging platform in a Docker Container on any cloud using ElasticBox, digging deeper into Docker as a Service, one of the latest ElasticBox features released in ElasticBox. The following step-by-step instructions will teach you how to build a Box that will allow you to deploy an instance right away. If you haven’t already signed up for ElasticBox, create your account to get started. Read More

Deploying Apps on Google Compute Engine using ElasticBox – How To Configure Networks, Firewalls and Disks

Part 1 of a two part blog post that shows you how we deploy MongoDB Clusters across different providers. Part 1 will cover Disks, Networks, Firewalls, and Tags. Part 2 will focus on network tunnels, routers and connecting VPCs.

As mentioned in a previous blog post, ElasticBox relies on MongoDB clusters internally for our data needs. In order to create redundancy and high availability for our production MongoDB databases, we deploy them in a VPC on AWS and Private Network on Google Compute Engine across different regions. For anyone who’s had the pleasure of trying to configure such a network, you’ll know that it’s no easy feat.

As we started to work on this scenario, we realized that there were better ways to utilize the available services and configurations from Google Cloud Platform and AWS. So today we’re releasing new features that enable full networking support for Google Compute Engine. Specifically, we’ve made changes to  deployment profiles – our default tool for configuring infrastructure – to make better use of Tags, Firewalls Rules, and Routes. While we were at it, we also introduced the ability to specify disk size.

Here are some the production scenarios we have enabled with this update:

  • Deploying machines with specific sets of rules for security purposes or to restrict public access (public IP address)
  • Using either Tags or Firewalls for configuration purposes to make it easier to choose the right settings
  • Specifying Ephemeral IP or IP forwarding configurations
  • Connecting instances in VPCs or private networks (more coming soon)

To demonstrate the changes we’ve made to our deployment profiles to enable better use of Networks and Disks, we’ll be looking at our MongoDB Replica Box. Which, if you caught our previous post on ‘How To Deploy a MongoDB Cluster,’ you’ll know that the MongoDB Replica Box is a replica instance of the Master MongoDB Box.

Tags and Firewalls:

When deploying an instance of MongoDB on your GCE account, you want to enable certain types of traffic to that instance, and so you might use a specific firewall(s) or tag which you would then associate with that instance when deploying.

When configuring your deployment profile, you can choose which firewall you’d like to use by choosing either the firewall, which will then present the associated Tag, or by choosing the Tag instead. This gives you two options for specifying the network configurations for that instance.

In the case of Tags, we’re using what Google Compute called ‘targetTags’, defined as “A list of instance tags that specify which instances on the network can accept requests from the specified sources. If not specified, this firewall rule applies to all instances on this network.”

For Google Compute Engine, you can now use the ElasticBox Deployment profile to specify disk size. Simply turn on the disks feature in the Deployment Profile and specify the disk size you would like to use. You can also add multiple disks if you like.  As a side note, Google recently announced the general availability of SSD persistent disks for all users and projects.

These upgrades to the ElasticBox deployment profile make it much easier to enable the complex scenarios of managing production instances on multiple providers, configuring networks and connecting VPCs. In the next blog post on this topic, we’ll be covering how to connect the MongoDB Cluster instances we have deployed in VPCs across multiple providers such as Google Cloud Platform, Amazon Web Services, and Microsoft Azure.

Deploying a MongoDB Cluster with ElasticBox

With ElasticBox, you can easily deploy a self replicating MongoDB cluster in just a few minutes. In order to accommodate ElasticBox’s data needs, we rely on MongoDB clusters that run on two public clouds and one private data center.

This way we can provide redundancy, high availability and excellent read and write performance around the world. Using ElasticBox, and our concept of Boxes, which are application or infrastructure components made available as a service, we can consistently deploy a MongoDB cluster in just a matter of minutes on any of our Cloud Providers.

To get started deploying MongoDB clusters on ElasticBox, sign up today for our free account! If you’re interested in other resources on MongoDB, check out how you can easily use Splunk to monitor MongoDB using ElasticBox.

The Basics

What is MongoDB? MongoDB is an open-source document store database.

Why would you want to cluster MongoDB? To provide redundancy and high-availability for production deployments.

How We Use MongoDB

In our case, MongoDB is using a replica set model. A replica set is a group of MongoDB instances that host the same data set. One MongoDB, the primary, receives all write operations. All other instances, secondaries, apply operations from the primary so that they have the same data set.

The primary accepts all write operations from clients. Replica sets can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency.


Deploying MongoDB through ElasticBox

ElasticBox provides a default MongoDB box that’s available to the public. It deploys a standalone instance of the MongoDB server. Our MongoDB production box very closely resembles the default box, minus a few configuration settings required for our production scenario.

While the default MongoDB box configuration is suited for development purposes, it needs to be configured further to use in production. To configure the MongoDB default box for production use, follow the steps below:

Step 1. Create a new box called MongoDB Replica. Add a box variable for the MongoDB Server (this is to use the default box settings).


Step 2. Add a text variable REPLICA_SET to hold the replica set name. This value must be shared between all the members of the cluster.


Step 3. Expand the MongoDB Server box. Edit its file variable COMMON_YAML and paste the following:

mongodb::replica_set: {{ REPLICA_SET }}

mongodb::key_file: /etc/mongod.key



This file will be used by hiera to pass arguments to puppet automatically without modifying the existing puppet default.pp file.

Step 4. Add a binding named primary of type MongoDB Replica (the box you just created).


Step 5. Add an install script. Get the script here.



Step 6. Add a start script. Get the script here.


When you deploy the box without a binding, it creates a cluster for you with an initial configuration. On the other hand, if you bind to an existing instance, it adds the instance to the existing cluster!

There, you have it, a MongoDB cluster in a few easy steps!