How to set up a development environment on your physical machine using the ElasticBox MyServer Edition, VirtualBox, and Vagrant

On Friday we announced our newest feature, ElasticBox MyServer Edition which lets you bring your own infrastructure to ElasticBox, including your physical machine. This means that you can now deploy applications on your laptop using ElasticBox. Sure, you could deploy applications to physical machines before, but we’re bringing all the goodness of cloud to your physical machines. You can take advantage of all our features such as service catalog, workload mobility, and management capabilities in your physical environments. 

ElasticBox’s support for physical machines also means more agility for developers. In my last blog post, I talked about one of my biggest pain points as a developer. In this blog post, I will talk about how ElasticBox alleviates that pain. Specifically,  you’ll see how  our development team has solved this problem using  ElasticBox MyServer Edition, VirtualBox, and Vagrant.

As you  probably already know, we use ElasticBox to deploy ElasticBox. I know, it’s pretty awesome! So for the development environment at ElasticBox we use a MongoDB Server box, a RabbitMQ Server box, an ElasticBox Services box, an ElasticBox Workflow box and a Bastion box. Most of these are already available to you in the public service catalog in ElasticBox.

ElasticBox Development Environment

So, with all these ideas in mind, the proposed Box structure is shown in the following diagram:

Some of the boxes used here are public boxes (for example, Mongo DB Server or RabbitMQ Server), but other boxes have been created and customized for this purpose (for example, ElasticBox Workflow, ElasticBox Services and ElasticBox Bastion).

We will also create a “parent box”, i.e. a box which will orchestrate all the process in Elasticbox, called “Local Development Environment” which will contain the other five boxes:

  1. A MongoDB Server Box (public box), in which we will provision our ElasticBox database
  2. A RabbitMQ Box (public box), which will manage the queues used by ElasticBox
  3. A ElasticBox Services box (custom box), which will execute our services for ElasticBox to work. Because it must use MongoDB Server and the RabbitMQ Server, we will add bindings to these boxes in the Services Box. This will make the services box wait for the bindings to initiate before starting itself.
  4. A ElasticBox Workflow box (custom box), which will manage the ElasticBox workflow. Like the services box, it has bindings to the MongoDB Server and the RabbitMQ Server.
  5. Finally, a ElasticBox Bastion Box (custom box), which will contain a NGNIX, a HTTP and reverse proxy server which will serve the static web content and redirect the traffic to the services box when necessary.

ElasticBox MyServer Edition

The Local Development Environment box is the one which will be directly deployed by us in our local machine. The others will be deployed automatically as they are part of the Local Development Environment Box. This deployment of the Local Development Environment box will be done by using our latest MyServer Edition, which allows us to deploy any existing box in our local machines.

With the MyServer Edition, ElasticBox installs an agent in a physical or virtual local machine (not in the cloud). Then, the agent can deploy any box that exists in ElasticBox. We can also execute any lifecycle actions for those boxes as usual (reinstall, reconfigure, terminate and delete) but everything is deployed in a local machine, not in the cloud. This way we are creating a local private cloud.

VirtualBox and Vagrant

Although the agent used can be run from any local machine, in our scenario we will use a virtual machine running in VirtualBox, a free well-known virtualization system. To automate the lifecycle of our virtual machine, we will use Vagrant too. Vagrant allows us to create a description file which defines the virtual machine we want to create, and provide us two important features:

  1. It allows us to create a shared folder between our physical machine and the virtual machine (for example, using NFS). This is very useful to share documents between the hosting and the hosted machine. We are going to use this feature to make our source code, located in our physical machine, visible to the virtual machine. This way, we will be able to deploy our applications directly from our source code, instead of having to make copies and avoiding mistakes.
  2. It allows us to provide a provision script or command in order to execute something once the virtual machine starts. This way, we can provide our BYOI agent to the virtual machine and execute it there.

For this scenario, we will be using an Ubuntu image valid for Vagrant. If you need one, you can create it using a public ISO from Ubuntu website with Packer, another interesting free software used to create virtual machine images.

We will be using Grunt too and its Grunt Watch plugin. Grunt is a Javascript task runner which we will use to look for changes in our source code directories. It is as simple as telling Grunt which directories we want to watch and what to do if any change occurs. Once a change is detected, we will launch a task consisting of restarting the services or the workflow in order to publish our changes in the development environment immediately.

The last element in this scenario is a bash script to deploy this development environment. This script will automate and orchestrate the other elements. The script will be responsible for:

  1. Defining necessary environment variables
  2. Launch vagrant task to create and power on the virtual machine, provisioning the BYOI agent and indicating that the parent box, ElasticBox Development Environment, must be deployed
  3. Start the grunt task to watch for source code changes

This is one of the multiple solutions that ElasticBox MyServer Edition provides us.

For example, we could decide whether we want to deploy each service in a different virtual machine or whatever combination. The important fact is that we do not need to be subscribed to any provider (Azure, Amazon, etc.) and we are able to do the deployment in our own local servers. And, what is better, we can do this by just executing a simple script in our local machine.

Here at ElasticBox we are continuously developing features and solutions to help our customers achieve the highest level of integration and improve their development environments. This post has shown how we can use the same boxes to deploy our production environments and our development environments. Using ElasticBox will ensure that everything will work whatever cloud provider you use, and the ElasticBox MyServer Edition will ensure that the local development environment is identical to the production one.

So, do you still want to keep “old fashioned gaps” between the development environments and the production environments when deploying for the cloud? If not, try out ElasticBox today at

Categories: Cool Features & Tutorials