Cloud Foundry Blog

New Runtime Module for Node.js Applications

In the previous blog post, Cloud Foundry Now Supports Auto-Reconfiguration for Node.js Applications, we saw that Node.js applications deployed to CloudFoundry.com can be automatically reconfigured to connect to Cloud Foundry services. However, there may be situations where you want to opt-out of that feature to have finer control over service connections or to overcome its limitations. In those cases, your applications would be required to parse JSON-formatted environment variables to perform that same function. While this is not overly complex given that JSON is trivial to parse with JavaScript, you will be required to understand the environment variable names and their payload schema. The new cf-runtime module introduced in this blog simplifies this by providing a way to obtain application information and service connection objects. This module moves Cloud Foundry’s Node.js support forward to the match the support for Java and Ruby applications.

Installation

Cf-runtime is available in the npm registry and can be easily installed with the Node Package Manager (npm). Run the following command in the base directory of your Node.js application.

npm install cf-runtime

Usage

This node module provides access to two types of objects. The first is a preconfigured object named CloudApp that contains application information. This includes the application’s host and port configured by Cloud Foundry, list of services bound to the application and their properties.

Additionally, each service that is bound to the application can be accessed via <ServiceName>Client object (i.e. RedisClient, MysqlClient). This object provides a convenient way to obtain the corresponding service connection with just a single function call. You can either create a service connection by the name used to create the service instance or by providing a general service name (e.g. redis or mongo) if there is only one service of this type that is bound to your application. This function may also accept additional parameters depending on the node module it uses (see details below in Service Clients section).

var cf = require('cf-runtime')
var app = cf.CloudApp

// Check if application is running in Cloud Foundry

app.runningInCloud

// Get application properties

app.host
app.port

// Get the list of application service names

app.serviceNames

// Obtain connection properties for single service of type Redis

app.serviceProps.redis

// Obtain connection properties for service named 'redis-service-name'

app.serviceProps['redis-service-name']

// Obtain the list of service names of specific type

app.serviceNamesOfType.redis

// Check if service of the given type is available

cf.RedisClient !== undefined

// Connect to a single service of type Redis

var redisClient = cf.RedisClient.create()

// Connect to redis service named 'redis-service-name'

var redisClient = cf.RedisClient.createFromSvc('redis-service-name')

Service Properties

All services have the following common properties:

  • name: specific name of the service
  • label: name of service type, for example “redis”, “mysql”
  • version: software version of the service type
  • host
  • port
  • username
  • password
  • url: service connection url

Additionally, PostgreSQL, MySQL and Redis include this service property:

  • database: the name of the database that is provided by the service

RabbitMQ provides access to these additional properties:

  • vhost: the name of the virtual host

MongoDB provides access to these additional properties:

  • db: the database name

Service Clients

The following table shows the available methods and parameters for each service type:

Node module Returns Functions Parameters
MongoDB
mongodb null cf.MongoClient.create([options], callback)
cf.MongoClient.createFromSvc(name, [options], callback)
name- the name of a service bound to the appoptions- optional {object} non-connection related optionscallback – {function} connection callback
MySQL
mysql Mysql client instance cf.MysqlClient.create([options])
cf.MysqlClient.createFromSvc(name, [options])
name- the name of a service bound to the appoptions – optional {object} non-connection related options
PostgreSQL
pg {boolean} cf.PGClient.create(callback)
cf.PGClient.createFromSvc(name, callback)
name- the name of a service bound to the appcallback – {function} connection callback
RabbitMQ
amqp AMQP client instance cf.AMQPClient.create([implOptions])
cf.AMQPClient.createFromSvc(name, [implOptions])
name- the name of a service bound to the appimplOptions – optional {object} non-connection related implementation options
Redis
redis Redis client instance cf.RedisClient.create([options])
cf.RedisClient.createFromSvc(name, [options])
name- the name of a service bound to the appoptions – optional {object} non-connection related options

Summary

The main purpose of cf-runtime is to make your Node.js applications understand their cloud better, retrieve the environment properties, find the available services, and connect to them easily. If you are writing Node.js applications, cf-runtime just made it easier to deploy your applications to Cloud Foundry.

- Maria Shaldibina
The Cloud Foundry Team

Don’t have a Cloud Foundry account yet?  Sign up for free today

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Drivers Behind Intel’s Choice of Cloud Foundry

The choice of application platform can have tangible consequences on development agility and productivity, especially when the developer community is as large as that at Intel.

In this guest blog, Catherine Spence, the Enterprise Architect and PaaS Lead for Intel IT’s Cloud Computing program, explains why Intel chose Cloud Foundry open PaaS for an enterprise private PaaS pilot.

Our goal at Intel was to let software developers get an innovative idea into production in less than a day.

One of the large aspects of meeting this goal is delivering a robust PaaS solution. We made a decision in mid-2011 that PaaS would enable this goal, and for our wide range of data and security requirements, running it in our private cloud was paramount. In searching for a PaaS solution for our enterprise private cloud, we conducted a study of solutions that could be landed within an enterprise. We specifically wanted a solution that could run on an IaaS and help address our key challenges.

We needed greater agility, simplicity, standardization, and efficiency, and these needs served as an impetus for our Cloud Foundry cloud. Though our journey from proof of concept to enterprise standard is still underway, we are sharing our vision of “how to help developers get apps to production in one day” at VMworld along with lessons learned and technical approaches. This post provides some additional detail on the business drivers and what led us to select Cloud Foundry.

1. More Agility

When custom applications were initially developed at Intel, the apps still took several months to deploy into production. Without any question, these delays impacted business metrics. There were 75 individual steps and little automation during a deployment. The process could take 130 to 140 days for new custom applications, and 30 to 40 days for version updates (see Figure 1 for steps in each lifecycle stage). Maintenance, new releases, and end-of-life deployment processes all faced error-prone, manual slow-downs. Business units and functional departments needed to move quicker.  


2. Greater Simplicity

Application development teams were responsible for provisioning their own infrastructure and needed to understand the infrastructure in detail. For example:

  • How much storage area network and network attached storage?
  • What middleware and how will it interface with infrastructure?
  • What IP addresses and device names?

Determining this information was not a straightforward process. On top of it, our developers would hard-code the infrastructure details, which made migrations difficult. As well, governance review processes were lengthy and rigorous regardless of application scope and size. There was a benefit in simplicity, but we were far from it.

3. More Standardization

Without standard templates, processes, step-by-step instructions, policies, or configurations, every development team did things a little different. The high degree of variation created problems. For example:

  • Back-ups and business continuity tests became more cumbersome and expensive due to the variation. It just takes more work when there might be 100s or 1000s of completely different configurations instead of a few standards.
  • Subcontracted web applications or microsites added variation. These also increased complexity when hard-coded to various third party infrastructures.
  • No standard monitoring existed, making centralized application support a challenge.
  • Some applications and environments had redundancy, others didn’t. The proliferation of models for redundancy produced no economies of scale.

4. Greater Efficiency

Historically, our development teams had no easy way to automatically scale or add resources to applications. So, we significantly over-estimated resource requirements such as  compute and storage; our teams would order an infrastructure to meet the demands of high-use scenarios. When applications weren’t used as much, the servers sat idle. As well, multiple instances like development and test sat idle for the life of the app, even if they were only required a few days per release.

Choosing Cloud Foundry

So, how did we choose a complete application stack? Of course, we knew what chipset to use, but what about frameworks, middleware, application servers, and other components? To answer this question, we began looking at an open source model for a cloud environment. Like others, our journey led us to CloudFoundry.org.

We narrowed the field down to several possible options and after running a proof of concept (POC) we ultimately choose Cloud Foundry as the basis for private PaaS in our next phase pilot. Cloud Foundry met our requirements in terms of technical capabilities and was differentiated by its availability as open source software and its array of supported programming languages.

Open source enables Intel to benefit from the fast pace of community updates while remaining open to customizing the solution for Intel’s business. Cloud Foundry’s vibrant community provides many advantages including feature contributions, knowledge sharing, and third party support options. While many IT shops are wary of the risks associated with open source, for many years Intel has had great success using open source software in our Design Grid. Our past experience makes us comfortable with the open source approach and the Cloud Foundry open source project.

The other key factor in our decision to use Cloud Foundry is that its flexible architecture supports a number of popular programming languages and frameworks such as Java, Ruby, Python and PHP. This aligns with Intel developer requirements, with the exception of a gap in support of .NET applications. Fortunately, near the end of our POC, a new open source software project became available called Iron Foundry which extends Cloud Foundry for .NET applications. This means that all developers can use the same toolset and platform for application deployment, which is a huge win in terms of platform flexibility and addresses the current and emerging needs of Intel’s developer community. While there is still much work to do to meet all of our requirements for a hybrid PaaS solution, we have made great progress establishing our initial PaaS offering for Intel software developers.

About the Author: Catherine Spence is the Enterprise Architect and PaaS Lead for Intel IT’s Cloud Computing program. Since joining Intel in 1996, she has also served as a Computing Director, Consulting Practice Manager, and Senior Software Engineer. Catherine holds degrees in Engineering, Computer Science, and Software Engineering from Trinity College and Harvard University.

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Cloud Foundry Now Supports Auto-Reconfiguration for Node.js Applications

Cloud Foundry has long supported auto-reconfiguration for Spring and Ruby applications. Now we are pleased to add auto-reconfiguration support for Node.js applications as well. Deploying Node.js applications to Cloud Foundry previously required parsing of environmental variables and overwriting server and service connection function calls to use Cloud Foundry specific parameters. This approach was not intuitive to developers who just started to use Cloud Foundry to deploy their applications. They would need to consult the documentation and figure out what port and host they need to connect to. Moreover, if an application uses services, developers would need to configure their applications to use the proper service connection parameters.

Auto-Reconfiguration in Action

Let’s look at the basic Node.js application. We are going to take some sample code from the Node.js official website homepage and save it to a file called app.js:

var http = require('http');
http.createServer(function (req, res) {
 res.writeHead(200, {'Content-Type': 'text/plain'});
 res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

As we can see, this code sets up your server to listen on your local port 1337. What if we now push this application to CloudFoundry.com ‘as-is’?

$ vmc push example-app
Would you like to deploy from the current directory? [Yn]:
Detected a Node.js Application, is this correct? [Yn]:
Application Deployed URL [example-app.cloudfoundry.com]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [64M]:
How many instances? [1]:
Bind existing services to 'example-app'? [yN]:
Create services to bind to 'example-app'? [yN]:
Would you like to save this configuration? [yN]:
Creating Application: OK
Uploading Application:
 Checking for available resources: OK
 Packing application: OK
 Uploading (0K): OK   
 Push Status: OK
Staging Application 'example-app': OK                                           
Starting Application 'example-app': OK                                          

$ curl example-app.cloudfoundry.com
Hello World

We can see that the application is up and running. But how is this possible if we didn’t configure it to listen on a Cloud Foundry application-specific port? This is when auto-reconfiguration comes into play. It automatically detects and modifies server and service connection parameters, so that the application can run and connect to Cloud Foundry services without manually specifying configuration values. As a result, an application that is developed and tested locally can work seamlessly on CloudFoundry.com without any code changes.

This was only a basic example of auto-reconfiguration in action. Let’s take a look at a more complex application that needs a database service to run. We are going to create our application using the content management system Calipso. It is based on the Express framework and uses the MongoDB database.

First, we pull Calipso source from Github and install its dependencies. As Calipso depends on a native module, bcrypt, we should use Cloud Foundry’s npm support feature that recently became available. Following that blog post on npm support we create npm_shrinkwrap.json and set “ignoreNodeModules” in cloudfoundry.json.

That’s it! Our application is ready to be deployed to CloudFoundry.com. As we deploy the application, we will be creating and binding a MongoDB service to the application.

$ vmc push calipso-app --runtime=node06
Would you like to deploy from the current directory? [Yn]:
Detected a Node.js Application, is this correct? [Yn]:
Application Deployed URL [calipso-app.cloudfoundry.com]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [64M]: 128M
How many instances? [1]:
Bind existing services to 'calipso-app'? [yN]:
Create services to bind to 'calipso-app'? [yN]: y
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
6: vblob
What kind of service?: 1
Specify the name of the service [mongodb-c88a9]:
Create another? [yN]:
Would you like to save this configuration? [yN]:
Creating Application: OK
Creating Service [mongodb-c88a9]: OK
Binding Service [mongodb-c88a9]: OK
Uploading Application:
 Checking for available resources: OK
 Processing resources: OK
 Packing application: OK
 Uploading (95K): OK   
Push Status: OK
Staging Application 'calipso-app': OK                                           
Starting Application 'calipso-app': OK

As you can see from the output, the application was deployed successfully. If we go to its homepage we can see a welcome message from Calipso where we confirm that we are “awesome”!


Now we can follow the installation wizard steps. With auto-reconfiguration it means that we can just use any value, including the default, for the database setup.

After the database is set up, we are ready to create a new article on our blog.

And we can see that the connection to the data service is functioning, as the new article is published to our blog:

To recap, we downloaded the application source, set up its dependencies, and deployed it to CloudFoundry.com using default connection parameters. The result is a working application. Let’s look now at the technical details on how this was accomplished.

Under the Hood

When your application is staged during the deployment process, Cloud Foundry makes two modifications:

  • Add a cf-autoconfig node module to the application
  • Preload the cf-autoconfig module while bootstrapping your application

The cf-autoconfig module uses the Node.js caching mechanism for module loading. Once a module is loaded, it is cached and requiring the same module elsewhere will take advantage of the cached code. The cf-autoconfig module searches for popular modules node.js applications use for connecting to services. It loads them before application code to redefine functions that connect to a service. Each modification replaces the original connection parameters (host, port, credentials, etc.) with equivalent parameters associated with a matching Cloud Foundry service bound to the application. With this arrangement in place, when application code subsequently loads the same module, attempts to connect to a service will yield a connection to an appropriate Cloud Foundry service. For an example, let’s see how it redefines the connect function of the MongoDB node module:

      if ("connect" in moduleData) {
        var oldConnect = moduleData.connect;
        var oldConnectProto = moduleData.connect.prototype;

        moduleData.connect = function () {
          var args = Array.prototype.slice.call(arguments);
          args[0] = props.url;
          return oldConnect.apply(this, args);
        };
        moduleData.connect.prototype = oldConnectProto;
      }

Other functions are redefined the same way. Take a look at the cf-autoconfig module’s source code on Github, and feel free to provide feedback or even a pull request.

Supported Modules

The following is the list of supported modules:

According to search.npmjs.org, most Node.js applications and other modules are dependent on the modules listed above. By providing support for these popular modules, any other modules that use them to form the database connection layer will inherit the benefit of auto-reconfiguration.

Limitations

Auto-reconfiguration of services works only under the following conditions:

  • You are only using one service of a given type. For example, only one mysql or one redis service.
  • You are using service node module from the list of supported modules above, or one that is based on a supported node module for service connections.
  • Your application does not use cf-runtime or cf-autoconfig node modules directly.
  • Your application is a typical Node.js application. (For a complex application you may want to consider opting-out of auto-reconfiguration and using the cf-runtime node module instead, which will be described in the next blog post in this series.)

Opting Out of Auto-Reconfiguration

Auto-reconfiguration can be turned off by providing cloudfoundry.json file in application base folder with the option “cfAutoconfig” set as false.

{ “cfAutoconfig” : false }

In addition, as mentioned above, auto-reconfiguration will not work if the application is using the cf-runtime node module.

Summary

Using the auto-reconfigurationis a great way to quickly start deploying Node.js applications to Cloud Foundry. As your application grows and demands more precise control over its services you may need to consider using the cf-runtime node module to get easy access to application properties and services. In the next blog post we are going to show you how to use the cf-runtime node module to simplify connections to Cloud Foundry services.

- Maria Shaldibina

The Cloud Foundry Team

Don’t have a Cloud Foundry account yet?  Sign up for free today

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Students Compete Building Apps on Cloud Foundry for Social Good

On July 13, VMware Foundation kicked off #ContributingCode, a two-week long event in Palo Alto, California, to encourage local students to build applications focused on a social and community benefit. With over 100 local students and VMware interns participating, we encouraged the students to develop in teams. Their projects were judged on their potential social impact, alignment with the sponsored app challenges, and competent software engineering.

Using Cloud Foundry as their platform, the teams could choose to develop their applications among several frameworks, including Spring, Node.js and Ruby on Rails. They could also use a variety of application services. In our experience, such events have produced great ideas and apps, but there is precious little follow though after the competition. Since social good was the theme of the event, we also required the teams to open source their code, so others could leverage and continue the good work.

We were delighted by the level of interest and creativity shown by the participants. In keeping with the larger development trends, a majority of the apps submitted were mobile apps and apps that integrate with social platforms like Facebook and Twitter. Use of multimedia and geo location features was popular and several teams chose to work with Node.js, Spring and MongoDB.

Here are the top three apps.

Grand Prize Winners

First place:

Team Dotly built a mobile app named Civicly for Android using Node.js and received the top score. Civicly enables community residents report and track local issues. The app serves to warn others of malfunctioning civic resources and helps keep municipal authorities more accountable. The Parse API is used to store the user data and the issues posted from the Android app. The Node.js app running on CloudFoundry.com receives notifications of the issues in real time and updates the web application via web sockets.

Second place:

Team Buddy built the Charity Match Facebook app which helps Facebook users find charities by mining the interests identified in their Facebook account and suggests charities to donate to. The app was built using the Spring MVC web application framework, Facebook and the Charity Navigator APIs. As shown in the architecture diagram provided by the team below, the Login view and its corresponding controller communicates with Facebook security APIs to authenticate users and authorize the app to collect user information. The Home view and its corresponding controller fetch and analyze the user’s information to derive the charity search keywords that are then fed into Charity Navigator search. The results are then parsed and displayed so the user can select and donate to a list of charities that are most aligned to his or her interests.

Third place:

Team RedThread placed third. RedThread is an app to help you post and view photos of places of interest in real time. This way you are always up to date with information on suspicious or unsafe activity and helps you to know the most relevant information in the location you want to visit. This app is written using Node.js.

To see a complete list of winners, click here.

Conclusion:

A big thanks to all the participants and our partners Code for AmericaSocialCoding4Good and GitHub! It was surprising how much was accomplished in just two weeks. We look forward to doing more of these in other locations as well.

Follow #ContributingCode on Facebook.

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Next Generation Cloud Controller: The VMC View

In my last post, I introduced you to some of the new features we are rolling out with the new cloud controller. For reference, I’ve included a block diagram of the new structure to refresh your memory.

In the previous post, the focus was on introducing the objects and briefly discussing how they are used for operational collaboration. In this post, I want to show you how the objects are used for resource accounting, how to navigate around the objects using the Cloud Foundry Command Line Interface (VMC), and then briefly show how features like custom domains use these objects as their foundation.

Resource Accounting

From the diagram above, you can see how the organization (a.k.a., org) object acts as the root object holding a collection of spaces. Each space contains a number of applications and service instances. From a resource tracking perspective, what this means is that we can easily account for memory and services in aggregate at both the space and organization level.

If you used an org to represent a project, and then used spaces to hold your production apps, your staging playground, and a playground for each developer, you might end up with a structure that looks something like this:

org: mhlsoft
  spaces:
    - name: production
      - apps:
        - name: pds
    - name: staging
      - apps:
        - name: pds
    - name: markl
      - apps:
        - name: pds_ng_node
        - name: pds
    - name: patb
      - apps:
        - name: pds_ng_go

With this structure in place, Cloud Foundry is able to tell you the resource consumption of each space and the aggregate consumption across the entire org.

Suppose your Cloud Foundry provider sold you 16GB of RAM for $380/mo. It would be nice to know how much memory you are using in aggregate, how much is being spent on your production facing apps, and how much is being used for internally facing playgrounds.

The next generation cloud controller is designed to support exactly this scenario. This allows Cloud Foundry tooling to show an organization summary like this:

The same tooling could also show a space summary, for each space, that might look something like this:

From this small description, you can see how the next generation system is designed to support the resource accounting and quota enforcement requirements of a wide variety of commercial systems based on Cloud Foundry.

Navigation with VMC

Enough of the system is working now where we can run the next generation cloud controller alongside the existing cloud controller. Given where we are with the work, I thought it would be a good idea to show you how to navigate around the system using the next generation VMC while targeting a next generation cloud controller.

The first thing to note is that we have extended the “vmc target” command to accept an optional org and space switch:

$ vmc help target
Set or display the current target cloud
Usage: target [URL]
Options:
 --url URL Target URL to switch to
 -i, --interactive Interactively select organization/space
 -o, --organization, --org ORGANIZATION Organization 
 -s, --space SPACE Space

The new -o and -s switches allow you to select an org and space within the target cloud. In  one of my test clouds, I have two orgs set up, and in one org have a few spaces, in the other, just a single space. Watch as I navigate around using “vmc target”:

# show my current context (cloud, org, and space)
$ vmc target
target: https://api.fakedomain.com
organization: pds
space: production

# switch to the staging space
$ vmc target -s staging
Switching to space staging... OK
target: https://api.fakedomain.com
organization: pds
space: staging

# switch to my other org
$ vmc target -o mhlsoft
Switching to organization mhlsoft... OK
Switching to space blaster... OK
target: https://api.fakedomain.com
organization: mhlsoft
space: blaster

The new “vmc orgs” command and “vmc spaces” command are simple enumeration commands that display the orgs that the current user belongs to and that she can target, and the spaces within that org:

# enumerate the orgs that are available to be within this cloud
$ vmc orgs
Getting organizations... OK
pds
mhlsoft

# enumerate the spaces within the current org
$ vmc spaces
Getting spaces in pds... OK
markl
production
qa
staging

# enumerate the spaces within my other org
$ vmc spaces -o mhlsoft
Getting spaces in mhlsoft... OK
blaster

The next new command to note is “vmc org”. This command lets you take a look at an org and see its spaces and options.

$ vmc help org
Show organization information
Usage: org [ORGANIZATION]
Options:
     --full                Show full information for an org 
 -o, --organization, --org ORGANIZATION Organization to show 

# show the current org
$ vmc org
pds:
  domains: none
  spaces: markl, production, qa, staging 

# show another org
$ vmc org mhlsoft
mhlsoft:
  domains: none
  spaces: blaster

As a peer to the “vmc org” command, there is the new “vmc space” command. This command lets you take a look at a space and see its org, its apps, its services, and its options:

$ vmc help space
Show space information
Usage: space [SPACE]
Options:
     --full                             Show full information 
     --space SPACE                      Space to show
 -o, --organization, --org ORGANIZATION Space's organization 

# show the current space
$ vmc space
production:
  organization: pds
  apps: pds-mgmt, pds
  services: redis, rabbitmq, redis-stats

# show a different space
$ vmc space staging
staging:
  organization: pds
  apps: stress, pds, pds-mgmt
  services: postgres, redis-e6ebd, rabbitmq-e1a06, redis-stats

As discussed in the previous post, the app names and service names are scoped to a space. This means that you can re-use app names across spaces. To see this from a different command’s perspective, take a look at the enhanced “vmc apps” command:

$ vmc help apps
List your applications
Usage: apps
Options:
     --framework FRAMEWORK    Filter by framework
     --name NAME              Filter by name
     --runtime RUNTIME        Filter by runtime
     --space SPACE            Show apps in a given space
     --url URL                Filter by url

# list apps in the current space
$ vmc apps
Getting applications in production... OK

pds-mgmt: started
  platform: sinatra on ruby19
  usage: 256M × 8 instances
  services: rabbitmq, redis-stats, redis

pds: started
  platform: node on node06
  usage: 256M × 16 instances
  services: redis, redis-stats 

# list only node apps in the staging space
$ vmc apps --space staging --runtime node*
Getting applications in production... OK

stress: started
  platform: node on node06
  usage: 256M × 1 instances
  services: rabbitmq-e1a06

pds: started
  platform: node on node06
  usage: 256M × 1 instances
  services: redis-e6ebd, redis-stats

Hopefully this will give you a good feel for how to use VMC to navigate around the system, how you can segregate apps into spaces, and how these new features will help with basic operational collaboration. All of the code that backs this system is being developed in the open, so poke around the vmc and cloud controller repos if you are curious, or better yet, come on in and help us out!

Organizations, Spaces, and Custom Domains

Finally, some of you very careful readers might have noticed that in the “vmc org” output, there is a row for “domains:”. This code is still under development, part of this phase’s work stream. This is the first step in rolling out official, integrated support for custom domains. We will talk more about this feature as it starts to take form. The short story is simple: an org can be assigned one or more domains or wild-card domains. This same capability extends into spaces with the restriction that a space may only attach to a domain enabled for the org. Once a space is enabled for a domain, then apps within that space can use that domain. Semi-fake output is included below to illustrate this point.

# show the current org, note that
# it's enabled for *.cloudfoundry.com as well
# as a custom wildcard domain
$ vmc org
pds:
  domains: *.cloudfoundry.com, *.mydomain.com
  spaces: markl, production, qa, staging 

# show the production space
# note that it is ONLY enabled for
# the custom domain, production apps
# can not accidentally live on *.cloudfoundry.com
$ vmc space production
production:
  organization: pds
  domains: *.mydomain.com
  apps: pds-mgmt, pds
  services: redis, rabbitmq, redis-stats

# show the staging space
# note that it is ONLY enabled for *.cloudfoundry.com
# staging apps can not accidentally live on *.mydomain.com
$ vmc space staging
staging:
  organization: pds
  domains: *.cloudfoundry.com
  apps: pds-mgmt, pds
  services: redis, rabbitmq, redis-stats

# list apps in production. note their URLs
$ vmc apps --space production
Getting applications in production... OK

pds-mgmt: started
  platform: sinatra on ruby19
  usage: 256M × 8 instances
  urls: manage.mydomain.com
  services: rabbitmq, redis-stats, redis

pds: started
  platform: node on node06
  usage: 256M × 16 instances
  urls: www.mydomain.com, mydomain.com, pds.mydomain.com
  services: redis, redis-stats 

Summary

The next generation cloud controller introduces the new organization and space objects. These objects provide the foundation for a wide range of commercial class features including operational collaboration, advanced quota management and control, custom domains, etc. While the code speaks for itself, I will continue to provide added color and commentary in these blog posts.

-markl Mark Lucovsky, VP of Engineering – Cloud Foundry

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Deploying vert.x Applications to Cloud Foundry

NOTE: Modified to use 0.8.2 version of cloudfoundry-runtime dependency together with the 1.2.3.final version of vert.x (Jan 2, 2013)

Developers can now use vert.x, a framework for highly scalable web applications, with CloudFoundry.com. Cloud Foundry has been a leader in providing an open Platform as a Service (PaaS), which allows for polyglot programming with a choice of multiple languages and frameworks. With recent releases of standalone application feature and Java 7 on CloudFoundry.com, developers now have a perfect environment to create vert.x applications, which can be written in any language that can run on the Java Virtual Machine (JVM), and deploy them to run on the JVM at CloudFoundry.com.

About vert.x

vert.x is a framework that builds on event-driven architecture and asynchronous I/O, similar to Node.js, but utilizes JVM’s internal capabilities to handle multiple processes and inter-process communications. Using Java threads, vert.x applications can easily scale over available cores making better use of available resources. This is ideal for applications with a large number of concurrent users, such as client applications running on mobile devices.

Furthermore, running on the JVM means that it can work seamlessly with code written in other languages that run on the JVM, such as Java, Groovy, Ruby, JavaScript, Coffeescript, Python and others, in the same application. Since vert.x requires Java 7, the addition of Java 7 as a runtime to CloudFoundry.com has enabled developers to use this highly flexible, polyglot framework.

  • vert.x is a community project sponsored by VMware.
  • vert.x includes a distributed event bus that spans the client and server side so your applications components can communicate incredibly easily. The event bus even penetrates into in-browser JavaScript allowing you to create effortless so-called real-time web applications.
  • vert.x also includes Web Sockets and SockJS support plus a MongoDB persistor so you can write real applications from the get-go.

Running vert.x Applications on CloudFoundry.com

vert.x ships with a number of example applications, so let’s take one of the applications–vToons Groovy example app–and adapt it to run on CloudFoundry.com. This is a simple shopping cart app for an online music store. It mostly consists of client side Javascript, but the server side is written in Groovy and the data is persisted in MongoDB.

We have to make some modifications to deploy this application to CloudFoundry.com. The resulting modified application source code can be found under the cloudfoundry-samples GitHub account at https://github.com/cloudfoundry-samples/vertx-vtoons/. We will use the most recent stable release of vert.x (1.2.3.final), which can be downloaded from here: http://vertx.io/downloads.html.

The modifications we have to make are the following:

  • Access system properties when app is running on CloudFoundry
  • Configure host and port setting for HTTP server
  • Configure database settings
  • Package the application for deployment including a vert.x runtime and any dependent jars

Let’s start with the application changes. You can read about the changes below and see all of source modifications in this commit in the repository.

CloudFoundry.com environment properties:

When your app is running on CloudFoundry.com, there are some environment properties that are available for your app to inspect. This allows you to find the information regarding the services that are bound to the app, such as host and port. We will use the Java cloudfoundry-runtime support library (version 0.8.2) for this task.

import org.cloudfoundry.runtime.env.CloudEnvironment
import org.cloudfoundry.runtime.env.MongoServiceInfo

def cloudEnv = new CloudEnvironment()

We add the import and create a new instance of the general CloudEnvironment class. Additionally, we added an import for the MongoServiceInfo class since we know that we will be binding a MongoDB service to the application.

Web server:

In order to run on CloudFoundry.com, the application must know the host name and port of the provisioned instance on CloudFoundry.com. The following code reads the host name and port from the CloudEnvironment object that we created above, but default to localhost:8080 if a Cloud Foundry environment is not detected:

  port: (cloudEnv.getValue('VCAP_APP_PORT') ?: '8080') as int,
  host: cloudEnv.getValue('VCAP_APP_HOST') ?: 'localhost',
  /* ssl: true, */

Note: In order to simplify this example, the SSL support was removed from the application.

Mongo Persistor:

When we push the application to CloudFoundry.com, we will bind it to a MongoDB. The connection parameters for the MongoDB service can be read from the CloudEnvironment object. Here we use the MongoServiceInfo to access the service settings:

// Configuration for MongoDb
def mongoConf = [:]

if (cloudEnv.isCloudFoundry()) {
  mongoSvcInfo = cloudEnv.getServiceInfo("mongodb-vtoons", MongoServiceInfo.class)
  mongoConf.host = mongoSvcInfo.getHost()
  mongoConf.port = mongoSvcInfo.getPort() as int
  mongoConf.db_name = mongoSvcInfo.getDatabase()
  mongoConf.username = mongoSvcInfo.getUserName()
  mongoConf.password = mongoSvcInfo.getPassword()
}

We then modified the mongo-persistor deployment to use these configuration settings:

deployVerticle('mongo-persistor', mongoConf, 1) {
  // And when it's deployed run a script to load it with some reference
  // data for the demo
  deployVerticle('StaticData.groovy')
}

At this point we are done with the code changes and can move on to packaging the app.

Package and deploy to CloudFoundry:

To simplify the build and deployment we will move the application code to a vert.x module – you can see this change in this commit in the repository.

While we could package the application by copying a few directories from vert.x distribution and then using ‘vmc push’ as usual, let’s simplify by creating a Gradle build script as seen here.

This build script provides the following:

  1. Defines repository locations for Maven Central, Spring milestone releases and vert.x release distributions
  2. Defines two configurations, one for runtime and one for dependent jars, as well as their dependencies
  3. Provides a “runtime” task that downloads and packages the vert/x runtime
  4. Provides a “build” task that packages the app source into a module directory
  5. Provides an “assemble” task packages the application as a zip file to be deployed
  6. Provides a “clean” task to clean up the build directory
  7. Configures the Gradle CloudFoundry plugin so we can use the build script to deploy the app

With everything in place, let’s just build and deploy the app:

$ ./gradlew assemble
:runtime
Download http://vertx.io/downloads/vert.x-1.2.3.final.zip
:build
Download http://repo.springsource.org/libs-snapshot/org/cloudfoundry/cloudfoundry-runtime/0.8.2/cloudfoundry-runtime-0.8.2.pom
:assemble

BUILD SUCCESSFUL

Total time: 18.586 secs

$ ./gradlew cf-add-service -PcfUser=user@email.com -PcfPasswd=secret
:cf-add-service
CloudFoundry - Connecting to 'http://api.cloudfoundry.com' with user 'user@email.com'
CloudFoundry - Provisioning mongodb service 'mongodb-vtoons'

BUILD SUCCESSFUL

Total time: 7.435 secs

$ ./gradlew cf-push -PcfUser=user@email.com -PcfPasswd=secret
:cf-push
CloudFoundry - Connecting to 'http://api.cloudfoundry.com' with user 'user@email.com'
GET request for "http://api.cloudfoundry.com/apps/vtoons" resulted in 404 (Not Found); invoking error handler
CloudFoundry - Creating standalone application 'vtoons' with runtime java7
CloudFoundry - Deploying '/Users/trisberg/Projects/github/cloudfoundry-samples/vertx-vtoons/build/vertx-vtoons.zip'
CloudFoundry - Starting 'vtoons'

BUILD SUCCESSFUL

Total time: 21.358 secs

We can now open a browser and enter http://vtoons.cloudfoundry.com/ to see the vert.x vToons application come to life and order some tunes.

vToons

Try vert.x on CloudFoundry.com

Cloud Foundry continues its goal of creating the best open PaaS for developers to run applications based on a choice of languages and frameworks. In this blog, we detailed the few simple steps required to deploy a vert.x app, an exciting new Javascript framework for the JVM, to CloudFoundry.com. Feel free to experiment with and deploy the numerous other sample apps that are part of the vert.x download on CloudFoundry.com.

Peter Ledbrook (@pledbrook) took the open source Collide collaborative IDE project and deployed it to CloudFoundry.com, take a look at it here: http://collide-pal.cloudfoundry.com.

Thanks to Tim Fox (@timfox), who created vert.x, and to Scott Frederick and Peter Ledbrook, who also contributed to this blog post.

- Thomas Risberg
The Cloud Foundry Team

Don’t have a Cloud Foundry account yet? Sign up for free today

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email