Monday, December 15, 2014

Choose IBM’s Docker-based Container Service on Bluemix for your I/O intensive code

Roughly a week ago IBM announced a new Docker-based service[1] as part of Bluemix PaaS[2]. It is still early but the service looks very promising, especially for I/O heavy workloads like databases and analytics. This post will help you create your own container instance running on Bluemix and provide some pointers on how you can evaluate whether the I/O performance of the instances matches your application’s needs. It will also describe nuances of using boot2docker[5] if you are running Mac OSX or Windows.

Even if you are not familiar with Docker, chances are you know about virtual machines. When you order a server hosted in a cloud, in most cases you get a virtual machine instance (a guest) running on a physical server (a host) in your cloud provider’s data center. There are many advantages in getting a virtual machine (as opposed to a physical server) from a cloud provider and arguably the top one is quicker delivery. Getting access to a physical server hosted in a data center usually takes hours while you can get a virtual machine in a matter of minutes. However, many workloads like databases and analytics engines are still running on physical servers because virtual machine hypervisors introduce a non-trivial penalty on I/O operations in guest instances.

Enter Linux Containers(LXC) and Docker. Instead of virtualizing the hardware (as the case with traditional virtual machines) containers virtualize the operating system. Start up time for containers is as good or better (think seconds not minutes) than for virtual machines and the I/O overhead all but disappears. In addition, Docker makes it easier to manage both containers and their contents. Containers are not a panacea and there are situations where virtual machines make more sense but that’s a topic for another post.

In this post, you can follow along with the examples to learn whether I/O performance of Docker containers in IBM Bluemix matches your application’s needs. Before starting, make sure that you have access to Bluemix[3] and to the Container Service[4]. In short, once you have provisioned an instance of the Container Service, you should have received an email notifying you that you have been approved for access and you should be able to see an API key as described in the example here[1].

Getting Started

The instructions below describe how to use boot2docker[5] for access to a Docker installation. boot2docker deploys a VirtualBox guest with Tiny Core Linux to OSX and you’ll ssh into this guest to access docker CLI. The same approach should also work on Windows although I am yet to try it.

Start of boot2docker specific instructions

Install boot2docker as described here[5]. Make sure that the following commands work correctly

boot2docker init
boot2docker start
$(boot2docker shellinit)
Use the following command to connect to your boot2docker Tiny Core Linux guest

boot2docker ssh

Install python and the ice tool in your boot2docker guest to interface to the IBM Container Environment. The approach used in these steps to install python is specific to TinyCore Linux and shouldn’t be used on other distros.

tce-load -wi python
curl -o - | sudo python
curl -o - | sudo python
curl -O
sudo pip install

End of boot2docker specific instructions

If you are not using boot2docker, you should follow the standard ice CLI installation instructions[6]

Before proceeding, create a public/private key pair which you’ll use to connect to your container. Replace the email address below with yours. The examples below assume that you’ll save your public key file to ~/.ssh/

ssh-keygen -t rsa -C "<>"

Make sure that you have provisioned an instance of the Container Service in Bluemix and copy/paste the API key into the command below. Details on how to obtain the API key are here[1]. Also make sure that you note the registry key you specified when provisioning the Containers service. You’ll need it later in the instructions.

ice login -k <api_key> -H -R

The login command should complete with a Login Succeeded message.
Next, you will pull one of the base IBM Docker images and customize it with your own Docker file:

ice --local pull

Once the image completed downloading, you will create a Dockerfile that will customize the image with your newly created credentials (so you can ssh into it) and with sysbench scripts for performance testing.

Create a Dockerfile using your favorite editor and the following contents:

COPY .ssh/ /root/.ssh/
RUN cat /root/.ssh/ >> /root/.ssh/authorized_keys
ADD *.sh /bench/
RUN apt-get install -y sysbench

Next, create with the following contents

sysbench --test=fileio --file-total-size=$SIZE prepare
sysbench --test=fileio --file-total-size=$SIZE --file-test-mode=rndrw --init-rng=on --max-time=30 --max-requests=0 run
sysbench --test=fileio --file-total-size=$SIZE cleanup
And containing:
sysbench --test=cpu --cpu-max-prime=$PRIME run
add execute permissions to both scripts
chmod +x *.sh
At this point your custom Docker image is ready to be built. Run
ice --local build -t example/sysbench .
which should finish with a Successfully built message followed by an ID.

Push your custom Docker image to Bluemix

When you got access to the Container Service, you should have noticed a registry URL which is shown right above your API key. For an example, see here[1]. The registry URL should end with a postfix which you specified when provisioning the Containers service  . In the commands below, replace <registry_id> to ensure you are specifying your registry URL.

ice --local tag example/sysbench<registry_id>/sysbench
ice --local push<registry_id>/sysbench
ice run -n sysbench<registry_id>/sysbench

After you have completed executing the commands above, your container should be running. You can verify that by executing
ice ps
Request a public IP address from the Container Service and note its value.
ice ip request
Bind the provided public IP address to your container instance with

ice ip bind <public_ip_address> sysbench
Now you can go ahead and ssh into the container using
ssh -i ~/.ssh/id_rsa root@<public_ip_address>
Once there, notice it is running Ubuntu 14.04
lsb_release -a
on a 32 core server with Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz CPUs

cat /proc/cpuinfo
processor : 31
 vendor_id : GenuineIntel
 cpu family : 6
 model : 62
 model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
Now you can also test out the I/O performance using

. /bench/ 100M
Just for a comparison, I ordered a Softlayer virtual machine (running on a Xen hypervisor) and ran the same Docker container and the benchmark there. In my experience, the I/O benchmark results were roughly twice better on the Container Service than on a Softlayer VM.You can also get a sense of relative CPU performance using
. /bench/ 5000


Benchmarks are an artificial way of measuring performance and better benchmark results don’t always mean that your application will necessarily run better or faster. However, benchmarks help understand if there exists potential for better performance and help you design or redesign your code accordingly.

In case of the Containers Service on IBM Bluemix, I/O benchmark performance results are significantly superior to those from a Softlayer virtual machine. This shouldn’t be surprising since Containers runs on bare metal Softlayer servers. However, unlike the hardware servers, Containers can be delivered to you in seconds compared to hours for bare metal. This level of responsiveness and workload flexibility enable Bluemix application designers to create exciting web applications built on novel and dynamic architectures.





Monday, February 24, 2014

Top 10 reasons why you should choose IBM Bluemix for your Cloud Platform as a Service.

This post is going to add some variety to all the technical content you've been seeing on this blog. So without further ado, here are the top 10 reasons why you should choose IBM Bluemix for your cloud Platform as a Service...

1. Partner with IBM to reach into enterprise for go to market opportunities. If you are trying to grow your Software as a Service (API economy) business beyond initial phases, you know that landing an enterprise customer can really make an impact to your bottom line[1].  IBM operates in more than 170 countries around the world and has direct and inside sales forces that reach out to top companies in the world. Find a way to work with IBM to jointly pursue opportunities in cloud and drive enterprise customers to your applications and services running on IBM Bluemix. For example, OnFarm[2], a startup, worked with IBM to receive ongoing coaching, access to technology, mentorship and connections to venture capitalists, clients and partners.

2. Leverage a pipeline of talent grown by IBM through university & development outreach. Even if you have a phenomenal business plan, you will struggle to execute without the right talent in your company. Did you know that IBM University Outreach is working with US universities[3] to get students engaged with Bluemix? Combine that with developer focused conferences like Innovate@InterConnect[4] along with many other outreach efforts and you have a growing talent pool of development candidates for your company. If you are a student or even just a developer interested in growing your skillset, you will want to know that Bluemix is built on Cloud Foundry[5], an open source platform as a service technology. This means that if you pick up IBM Bluemix skills you can apply them to any other Cloud Foundry deployment, including the one that you can build yourself[6].

3. Monetize your services through the IBM Bluemix services catalog. Shortly after the launch of Bluemix, many IBM business partners, including Ustream[7], started to offer services through the IBM Cloud Marketplace. You too can get a head start on your competitors by contributing your service to the IBM Bluemix catalog. Networked marketplaces like IBM Bluemix have a strong first mover advantage[8]. Develop on Bluemix, create a service plan[9], become an IBM Cloud Marketplace business partner[10], and make your service a category leader!

4. Build on a responsive, global cloud infrastructure with world’s largest webhosting marketshare. Did you know that Softlayer, IBM's Cloud Infrastructure as a Service hosts more than websites than GoDaddy[11]? You shouldn't be surprised if you've been reading about the reliability of the IBM infrastructure. IBM uses Softlayer not just for Bluemix, but also for customers like the Australian Open[12] tennis tournament to ensure high availability and a great user experience. In contrast, offerings from Amazon Web Services has been suffering from numerous outages over the past year[13][14], including one as recently as Christmas time[15].

5. Meet enterprise class quality of service requirements in the cloud. Not all applications are created equal. Some need high availability & high performance relational databases. Others must satisfy complex regulatory compliance requirements. It is easy to become disparaged when you have to say no to a government or an enterprise customer because your service is missing a capability which you cannot afford to build yourself. Bluemix gives you a roadmap for how to evolve your application to introduce enterprise class capabilities[16] that can help you pursue lucrative opportunities in large enterprise and government space.

6. Support migration of complex legacy applications to cloud with IBM’s flexible infrastructure . IBM Softlayer, the underlying infrastructure for Bluemix has been highlighted by Gartner[17] for its range of features: from bare-metal to cloud servers, all managed through a common API. This broad supply of capabilities is why gaming companies[18] like Multiplay and KUULUU with complex demands for their resource intensive games moved to the same infrastructure as Bluemix.

7. Deliver innovative services by working with IBM Research & Development(R&D) labs. IBM Bluemix is the only Platform as a Service out there featuring IBM Watson technology -- a recent Jeopardy winner[19]. In addition to Watson, you can take advantage of other services created by IBM R&D, including a log analysis, auto-scaling, and many others. IBM labs also have customer advocates who can explore how IBM can help you on your opportunities.

8. Discover opportunities for innovation from a palette of IBM business partner services. IBM business partners have adopted Bluemix and made their services available for your use. For example, Zend Technologies provides support for their enterprise class PHP container[20] which can be deployed to IBM Bluemix. Access to IBM business partner ecosystem[21] can help you build your application faster, regardless of the technology, industry, or geography you are targeting.

9. Create trusted and secure offerings by reusing services reviewed and certified by IBM. A company can develop a service for Bluemix without any restrictions from IBM. However, for a service to be posted to the Bluemix catalog, IBM has to review and certify the service based on IBM's internal guidelines. If you are interested in this process, you can find out more about IBM's terms and conditions on our partner landing page[22]

10. Depend on IBM’s history of industry leadership for what is essential to your customers. IBM has been around for more than a century supporting technology needs of companies around the world. Some have said that the Western Civilization runs on the mainframe technology[23] which IBM has developed and has been maintaining since 1960s. With IBM commitment to Cloud Foundry[24] you can be certain that IBM Bluemix is the right foundation to develop applications for your most valuable customers.



Sunday, February 9, 2014

Develop a REST Service using Play and PostgreSQL on IBM Bluemix: Part One

This post will show how to use the Play framework[1] with IBM Bluemix to develop and run a very simple REST style web application. The application supports APIs to create, retrieve, update and delete objects represented by JSON in HTTP requests. On the backend, the application connects to a Bluemix managed PostgreSQL database to persist and query data parsed out by the application from the HTTP requests. The data used in the application describes a note -- modeled as two fields of text for note's title and its contents. The application is just a sample and is not intended to be used in production. Future posts on this topic are going to describe how to address production concerns such as automated testing, authentication, authorization and more.

Security considerations are entirely out of scope for this post. While the REST API described here has some rudimentary protection against some attacks (e.g. SQL injection), the application should not be used to store sensitive information or be exposed to the web as part of anything other than a learning exercise. More sophisticated security features for the application are topics for future posts.

The steps in this post can be followed without an understanding of SQL, REST and Scala but those who invest some time in getting familiar with these technologies are going to get more value out of the content here.

Connect a Scala application to a PostgreSQL database in the IBM Bluemix environment

Earlier posts explained the basics of the manifest.yml deployment descriptor used for Cloud Foundry based platforms. The manifest used in this post relies on the services capability of Cloud Foundry(CF). The difference between CF applications and CF services amounts to a conceptual difference between units of development (former) and units of reuse (latter). This means that CF applications can depend on (and reuse) CF services but not vice versa. However an appropriately architected CF application[2] can be repackaged and deployed to Cloud Foundry as a service thus becoming a unit of reuse for other CF applications. A detailed explanation of CF services[4] is outside the scope of this post; the example here will focus on describing how to use a PostgreSQL database service available on IBM Bluemix.

In contrast to the manifest files used in the previous posts, manifest.yml for the application described here includes a section declaring services references (line 8 in the following snippet) and a name of a service instance to be available to the application (line 9 in the snippet). The details of how the service is instantiated and the specific parameters that should be used for the service are covered in a later section. The Play application in this post is going to rely on a PostgreSQL database version 9.1

Prepare Play framework code for deployment to IBM Bluemix

Start by downloading and unzipping a standalone distribution of the Play framework[3] to a directory. Before proceeding you will need to make sure that the directory is in your path variable and then execute play new play-rest-api-sample command. Use play-rest-api-sample as the name of your application and choose to create a Scala application as shown in the following snippet.

Before proceeding, change your working directory to play-rest-api-sample created by the play new command and delete build.sbt file as it will interfere with the rest of the build code used in this application.

As with previous posts, you can choose to continue by fetching files from a git repository[10]. If you decide to take the git option, you can skip directly to the Deploy and test section of this post but for a deeper understanding of the code continue to read on from here.

First, you will need to configure the newly created application to take advantage of the database instance specified in the manifest.yml. The framework takes care of database management but to do so it needs the SQL code to create database tables, maintain primary keys and to delete tables in cases when the application is deleted from Bluemix. SQL for the application in this post is shown below. Lines 3-7 define a note table has having an integer ID / primary key and two varchar columns for title and text of a note. Line 9 defines an increasing sequence of numbers starting from 1000 that will be used by PostgreSQL to automatically set the primary key values for the notes added to the database. Lines 13-14 remove both the table and the sequence when the application is deleted.

Once Bluemix instantiates the database, the application can rely on Bluemix to provide the parameter values needed to establish a database connection. Note that in lines 8-10 of the application.conf file in the play-rest-api-sample/conf directory, variables in the namespace define the values need for the connection.

The application is structured following the Model View Controller (MVC) pattern. The model piece, a file named Note.scala resides in the play-rest-api-sample/app/models directory. The Note Scala case case represents possible values for a note, while the Scala object (snippet below) in the file defines key methods responsible for performing create, retrieve, update and delete (CRUD) operations on the Note tables in the PostgreSQL database.

Notes.scala (shown below) implements the controller piece of the application. For each of the CRUD operations this Scala object mediates between HTTP requests and the Note object by parsing HTTP parameters and data fields and relying on Note to perform database transactions.

The routes file located in the play-rest-api-sample/conf directory instructs the Play framework as to which of the Notes.scala controller methods to invoke depending on the URL of the HTTP request to the application.

Finally, before the application can be compiled, some of the build files need to be modified to an earlier versions of SBT supported by Cloud Foundry. To complete the changes

  • replace the contents of play-rest-api-sample/project/ with

  • modify the line in play-rest-api-sample/projects/plugins.sbt that starts with addSbtPlugin to be

    addSbtPlugin("play" % "sbt-plugin" % "2.1.1")
  • create a Build.scala file in play-rest-api-sample/projects with the following contents

Build, deploy and test a Play REST application on IBM Bluemix

To build a deployable binaries for the sample application, run play dist from the command line with  play-rest-api-sample as the working directory. Once the build completes, check for the existence of a dist/ file.

You will also need to run the following sed script to create a unique URL for your application by replacing $RANDOM string in the manifest.yml.template file with a random number and writing the result to manifest.yml.

As you recall from the beginning of this post, the application depends on a PostgreSQL service instance which is declared as notes-db in the manifest.yml file. For a more detailed explanation of service instantiation and service binding, have a look at PostgreSQL for IBM Bluemix[5] documentation. Before the application can be deployed, this service instance should be created using cf create-service command as shown in the following snippet. As with earlier posts on this blog, your create-service session with have a different value instead of the <Your IBM ID> string.

Next, issue a cf push command and note that the URL provisioned for the application should match the one in your manifest.yml file.

The following session illustrates the use of the REST API with curl utility. Note that you will need to replace the Bluemix URL in the session with the URL returned to you by cf push. Lines 1-2 show an HTTP POST to create a new note which is assigned an ID of 1000 by the application. The existence of the new note object is confirmed with the GET request show in lines 4-5. In lines 7-8, the note is modified with an HTTP PUT which is then confirmed by querying all of the notes available from the application via a GET request shown on lines 10-11. The final part of the session involves creation of another note which is assigned an ID of 1001 (lines 13-14) while the original note is deleted in lines 16-17. Correct completion of the deletion request is confirmed through query for all notes in lines 19-20. The result of the query shows that the original note with an ID 1000 no longer exists.



[10] Instead of using git clone, which will not overwrite files in your play-rest-api-sample directory, use the following sequence of git commands
git init
git remote add origin
git fetch origin
git checkout -b master --track origin/master --force

Tuesday, February 4, 2014

Deploy a Hello World PHP Application to Zend Server on IBM Bluemix

The previous post demonstrated how to deploy a trivial Node.js application to IBM Bluemix. There I also introduced the basics of manifest.yml file used by Bluemix and Cloud Foundry as a deployment descriptor. This post goes deeper into features available for creating reusable manifest.yml files and covers Cloud Foundry buildpacks used during deployment. By the end of the post you will have deployed a trivial Hello World application written in PHP to a Zend Server's PHP container running on IBM Bluemix.

Variables in manifest.yml

The post about deploying a Node.js application to Bluemix warned about a potential problem with having a single manifest.yml in use by multiple developers. The problem occurs in a situation where the deployment subtarget (hostname) of an application has a fixed value in the manifest. If two developers try to deploy their application to the same hostname, Bluemix rejects second and subsequent deployment attempts because of the conflict as to which of the two applications should run on the hostname, e.g.

The post suggested manually changing a postfix in the manifest.yml file in case if Bluemix rejects deployment attempts due to the same hostname error.  Of course, this approach is not acceptable in most cases, especially if one tries to automate the deployment process. One way to address this problem is to use features of bash[6] and sed[7] to introduce randomly generated numbers characters into the manifest.yml file. For example, you can create a manifest.yml.template file where the host parameter is specified as follows:

Then, prior to performing a push using the Cloud Foundry cf tool, you can execute the following sed command to generate a manifest.yml file where the string $RANDOM is replaced with a randomly generated number.

Use of random numbers in the application hostname makes the possibility of name collisions unlikely but introduces another problem: finding out the URL of an application after the deployment process completes. The cf tool has a command to help called cf routes that returns up to date information about active hostname URLs and corresponding applications.

Zend Server Buildpack

During the deployment process described in the previous post, the package.json[1] file provided a hint for Bluemix to use the Node.js runtime. Without this hint the application would have failed to stage because Bluemix would not know which runtime to prepare for the application.

Buildpacks are used by Cloud Foundry to prepare the environment for running an application (e.g. setting environment variables, copying settings files into the right places), compile binaries (if any) and launch the application in the runtime. A detailed explaination of buildpacks is outside the scope of this post and more detail is available from Cloud Foundry[2] and Heroku documentation[3]. It is important to note that some buildpacks, such as the one for Node.js, are built into Bluemix which means that the buildpack does not have to be specified explicitly to the cf push command.

Given enough time and effort one can create a custom buildpack for a runtime that is not built into Bluemix. Once the buildpack is available on the web via git, Bluemix can use git clone of the buildpack repository to copy the buildpack to the execution environment during the deployment process and launch an application in the custom runtime. The next section describes how to use a custom buildpack for a Zend Server, a PHP runtime to run a simple Hello World application on Bluemix

PHP Hello World Application

As with the post covering Node.js deployment, you may either use git to clone a repo for this application[4] or if you prefer, create a new directory and save the index.php and manifest.yml files shown below to the directory.

The Hello World application in index.php is very simple. The <?php prefix on line 1 instructs the PHP interpreter to process the code between the prefix and the closing ?>  bracket on line 3. The actual code on line 2 just prints "Hello World" to any HTTP request sent to the PHP container running the application.

The parameters in the manifest.yml are covered earlier in this post and in the previous post while a more detailed explanation is available from the Cloud Foundry documentation[5].

The following is a snippet of the application deployment session to Bluemix, starting with 
cf push hello-world-php command.

Note that due to variability of download speeds it may take a while to deploy the application. If you are seeing problems with timeout when deploying the application, try setting the CF_STARTUP_TIMEOUT and CF_STAGING_TIMEOUT to be at least 15 minutes.



Monday, February 3, 2014

Deploy a minimal Node.js application to IBM Bluemix

IBM Bluemix documentation[1] provides broad coverage of the platform's many features. Instead of trying to address all these features at the same time, this post will take a layered approach starting with an absolute minimum number of features need to run a Hello World application written for Node.js[2] on Bluemix. Minimum here means that taking away any of the parameters from the code will definitely break the deployment to Bluemix. The concluding section of this post will describe how to use Cloud Foundry[3] manifest.yml file feature to reduce the amount of manual effort needed to deploy an application to Bluemix.

Verify your IBM Bluemix account

Make sure that you have a working IBM ID before you start trying out the application and the instructions in this post.  To obtain an IBM ID:

  1. Visit
  2. Complete the 2 step registration form
  3. In case you have questions check out the IBM ID registration FAQ here:

To verify that your IBM ID is working, visit IBM Bluemix and sign in with the IBM ID by using the Login button on the upper right. Note that login to IBM Bluemix may break when using Google Chrome with incognito browsing. While writing this blog post, I found that using Chrome in this mode redirected me to
and generated an HTML page with the following error message

Error 404: SRVE0190E: File not found: /public/nullnull

If you encounter a similar problem you should complete the rest of these instructions with incognito browsing turned off.

Prepare the application source code

If you don't have git[4] installed or don't want to use git, you can manually create a separate directory and then copy and paste the source code for main.js and package.json files described here. Otherwise, the git repository for this post is available via

Here is the JavaScript source code for main.js file. It is explained in detail below the snippet. main.js is the entry point into the application and has the instructions for the Node.js runtime to start a web server. Anyone familiar with Node.js will immediately recognize that this code snippet returns a "Hello World" message to any HTTP request sent to the web server running the code. There are two variables in the snippet that might be new to you if you haven't worked with Bluemix or Cloud Foundry in the past. The code on line 1:
var port = (process.env.VCAP_APP_PORT || 8192); 
relies on process.env.VCAP_APP_PORT variable which is automatically initialized by the Bluemix environment to 80,  a default port for HTTP traffic.  Use of the || operator  (logical or) on the same line ensures that if we run the main.js code on a local Node.js runtime (i.e. outside of the Bluemix environment), the port number will default to 8192 since VCAP_APP_PORT would be null. Line 2 uses similar logic to set the hostname of the application.

The following JSON code for package.json file is needed to describe to BlueMix that the application requires a Node.js runtime. Regardless of whether you have cloned the git repository for the application or copied and pasted the source code from the snippets above, at this point you should have a directory containing main.js and package.json files.

Deploy and run the application on Bluemix

Both Bluemix and Cloud Foundry rely on a Go based command line tool (called cf) to script common application management tasks. The getting started[5] section of the Bluemix documentation provides references on how to install cf the Cloud Foundry command line tool[7].  Once cf is installed, you can use it to connect to IBM Bluemix[8] as the deployment platform

and then login to Bluemix[9] using your IBM ID (in line 1)

If the target and login commands completed successful you should be ready to deploy and run the application on Bluemix. Ensure that your working directory contains the application files main.js and package.json before running the cf push operation shown in the following snippet. Note that the -n argument specifies that hello-world-node-js-0123456789 should be used as the subdomain(hostname) for the application, -m tells Bluemix to allocate 128 megabytes of memory to the application, while the -c argument tells the Node.js runtime in Bluemix to run the code in the main.js file.

Once started, the cf tool will show you information about the progress of the deployment. If the deployment processes finishes correctly, you should see the "App started" message and your browser should show the Hello World message when visiting An example of a push session is shown below. Note that parts with your <Your IBM ID> will be different for your session.

Since multiple Bluemix users may try to deploy an application to the same subdomain you may see the 'host is taken' error message (example below) during the deployment process. To work around this problem, simply change the subdomain to a different, unique value.

Simplify deployment with manifest.yml

A better alternative to having the deployment parameters in the command line is to create a Cloud Foundry manifest.yml file. As shown in following snippet the manifest file contains the values that can be specified during the push process. By convention the file starts with three dashes followed by YAML[11] based markup. A detailed description of the manifest file specification is available from the Cloud Foundry website[3]. The next time you will execute cf push, the cf tool will automatically use the contents of the manifest to deploy the application to Bluemix.