Tutorial

Cloud Foundry Tutorial : Taking a PaaS on the hard stuff - Part 3

        

Working with Cloud Foundry

If everything succeeds, you can now start to ask questions and interact with Cloud Foundry. Here’s my output of the vmc info command.

$ vmc info

VMware's Cloud Application Platform

For support visit http://support.cloudfoundry.com

Target: http://api.cloudfoundry.com (v0.999)

Client: v0.3.16.beta.5

User: jolong@vmware.com

Usage: Memory (1.6G of 2.0G total)

Services (6 of 16 total)

Apps (3 of 20 total)

Another handy command is the vmc apps command, which tells you which applications you’ve got running. I get the following output when I run the vmc apps command:

$ vmc apps

No Applications

Is there anything more depressing? We need to deploy an application!

I’ve created a simple Spring MVC application that runs on both your local machine (working with an in-memory database, called H2, and working with Cloud Foundry-managed instances of PostgreSQL, a powerful relational database and Redis, the lightning fast data-structure service. To get the code, simply clone it from the cloudfoundry-samples GitHub project.

$ git clone git@github.com:cloudfoundry-samples/springmvc-hibernate-template.git

The application is a Java project, and uses Maven for its build. To compile the code, you simply enter the root of the project and then run the mvn install commands, like this:

$ mvn install

Now that we’ve got the platform, and an application, let’s deploy it using the vmc tool. I can imagine your thoughts: “C’mon, man! We can’t deploy this thing yet! It’ll blow chunks – you just finished telling us it needs PostgreSQL and Redis!” And, that’s a good point! But, don’t worry! We’ll take care of deploying the application and configuring those services in one stroke. You see, the vmc tool has to rank among the friendliest of command line tools out there. Let’s walk through the push interaction:

$ vmc --path target/springmvc31-1.0.0 push

This tells vmc to push the compiled code in the directory specified in the --path argument. If you don’t specify --path, it looks for the code to deploy in the current directory. If you’re deploying a project in a language that doesn’t have a compiled form, then specify the root directory of that project instead.

Application Name: springoncloudfoundryforjax

Specify a name for the application. The name you specify must be different than the one I’ve specified here (otherwise, there would be a collision!)

Application Deployed URL [springoncloudfoundryforjax.cloudfoundry.com]: 

Specify the URL (or hit enter to accept the default).  

>Detected a Java SpringSource Spring Application, is this correct? [Yn]: n

1: Rails

2: Spring

3: Grails

4: Lift

5: JavaWeb

6: Sinatra

7: Node

8: PHP

9: Erlang/OTP Rebar

10: WSGI

11: Django

12: Rack

Select Application Type: 5

Selected Java Web Application

vmc has detected the type of the application (“a Java SpringSource Spring Application”). We have instead selected option 5, “JavaWeb,” because our application doesn’t need to be auto reconfigured. Auto reconfiguration is a service that Cloud Foundry provides when applications are uploaded: It redefines the definition of services in certain types of applications and automatically binds them to the appropriate definition for the data source managed by Cloud Foundry. This is useful if you have only one data source, or one Redis declaration, and would simply like to have that automatically rewired to work on Cloud Foundry. The alternative is to dynamically look up the connection information from a well-known context, like the VCAP_SERVICES environment variable that is set in the Cloud Foundry environment. There is also a Java API, called the cloudfoundry-runtime  which provides a type-safe Java API to do the same work. The application already looks up the definition using the cloudfoundry-runtime, and does not need auto-reconfiguration. 

Memory reservation (128M, 256M, 512M, 1G, 2G) [512M]:

How many instances? [1]: 

Next, vmc asks us to specify some of the runtime characteristics of the application: How much memory does it need? How many instances should be started? For now, we’ll just accept the defaults.

Bind existing services to 'springoncloudfoundryforjax'? [yN]: n

Create services to bind to 'springoncloudfoundryforjax'? [yN]: y

1: mongodb

2: mysql

3: postgresql

4: rabbitmq

5: redis

What kind of service?: 3

Specify the name of the service [postgresql-63c39]:

Create another? [yN]: y

1: mongodb

2: mysql

3: postgresql

4: rabbitmq

5: redis

What kind of service?: 5

Specify the name of the service [redis-48adb]:

Create another? [yN]: n

Finally, the services: the Redis and PostgreSQL instances, are set up. Cloud Foundry is nice enough to ask us if we need services for our application and prompts us to specify as many services as we need. Services in Cloud Foundry are not coupled from the applications that consume them: You can specify as many services as you like. They must be bound to the applications that use them. You may share services across applications, and may use as many services as you like for any application. Our application is written to lookup references by type, not by name, so it does not matter how we name the services.

 

Would you like to save this configuration? [yN]: y

Manifest written to manifest.yml.

Creating Application: OK

 

That was tedious! Sure, it did deploy our application and completely configure the services we need, but I’d sure hate to answer all those questions every time I deploy or update an application. No, no. Leave that to somebody else, I say. This is what the Cloud Foundry manifests provide: a manifest of everything Cloud Foundry needs to deploy the application without prompting you. This makes it easy to share your configuration with others. Cloud Foundry’s even willing to write the manifest.yml file for us!

 

Creating Service [postgresql-63c39]: OK

Binding Service [postgresql-63c39]: OK

Creating Service [redis-48adb]: OK

Binding Service [redis-48adb]: OK

Uploading Application:

Checking for available resources: OK

Processing resources: OK

Packing application: OK

Uploading (12K): OK

Push Status: OK

Staging Application 'springoncloudfoundryforjax': OK

Starting Application 'springoncloudfoundryforjax': OK

 

At this point, the application’s available and running! You can confirm this by checking the output of vmc apps (Figure 1).


Figure 1: Output of vmc apps 

That’s much better! Bring up the application by opening the URL specified in the output of vmc apps in your browser. This application has a simple UI to let manipulate records of customer data. There is also a RESTful endpoint that you can hit at /crm/customers. The result is a JSON structure with individual records. When you first deploy the application, there are no records! Let’s fix that.

The light (of data) at the end of the tunnel

We’ve had an easy time of deploying an application thus far, but the operations and DBAs reading this are probably nervously tapping their fingers at this point: “Where is my database console? My backup scripts?” Indeed, the operations people in your organization are the ones who have to wear the beeper when they go to bed, and they want to know that they can get access to the data with ease, or run their routine diagnostic and backup jobs, just like before. Cloud Foundry provides caldecott (named for the caldecott tunnel in San Francisco, in case you’re wondering...), which is a tunnel. Caldecott lets you poke a hole in the cloud, connecting you to your services running inside the cloud from the outside. Let’s connect to our PostgreSQL instance and install some data using the vmc tunnel command.

 

$ vmc tunnel

1: postgresql-63c39

2: redis-48adb

Which service to tunnel to?: 2

 

The command will list the services that we have created, and to which we can establish a tunnel. Specify the number for the PostgreSQL instance in your account, in my case, #2.

 

Deploying tunnel application 'caldecott'.

Uploading Application:

Checking for available resources: OK

Packing application: OK

Uploading (1K): OK

Push Status: OK

Binding Service [postgresql-63c39]: OK

Staging Application 'caldecott': OK

Starting Application 'caldecott': OK

Getting tunnel connection info: OK

Service connection info:

username : u63a3924f90c6446f9737390675f1a9e0

password : p9ccfd8a6b4d04e308396a872a9711155

name : d040a2dbbc977418f9eb599a2245fa96d

 

By default, the command outputs the information you’d need to establish your own connection from any client, command-line or not: the host, port, username, password and name, which basically just means schema, for most databases.

 

Starting tunnel to postgresql-63c39 on port 10000.

1: none

2: psql

Which client would you like to start?: 2

Launching 'psql -h localhost -p 10000 -d d040a2dbbc977418f9eb599a2245fa96d -U u63a3924f90c6446f9737390675f1a9e0 -w'

psql (9.0.5, server 9.0.4)

Type "help" for help.

d040a2dbbc977418f9eb599a2245fa96d=>

 

If that weren’t enough, vmc will even start up many well-known, local command line tools like psql for you! I let it, and it dumps me into the standard psql shell, where I can execute my SQL statements. The project provides some sample data in the file src/main/resources/import_psql.sql. Copy and paste that into the shell, and then revisit the /crm/customers JSON dump page. You should see your new data reflected in the results. The tunnel is a powerful tool, and provides everything you need for ad-hoc queries, as well as operational features like nightly dumps of the data.

Closing Thoughts

We’ve looked at how to deploy a simple Spring application to Cloud Foundry entirely from the command line. We did not look at how to use the Eclipse WTP support, which is ably covered on the Cloud Foundry website and in the SpringSource blog. We also have not looked at the development model support for Spring, Ruby, Node.js, Scala, etc. Cloud Foundry is, after all, a polyglot PaaS!

If you’re a Spring developer, then you have a lot of clean integrations to help you along; it provides a rich set of APIs that maps nicely to the supported services on Cloud Foundry: Spring AMQP and Spring Integration make RabbitMQ-based projects very easy. Spring Core and Spring Batch make batch workloads simply with MySQL and PostgreSQL. Spring Data Redis and Spring Data MongoDB both provide rich support for Redis and MongoDB. If you’re a Java developer, and want to build applications on top of Cloud Foundry, you’re in luck!

At this point you’ve got all you needed to get started and plenty of information on where to go from here. If you have any questions, don’t hesitate to reach out to me at josh.long@pringsource.com, or reach out at one of the numerous public forums on the Cloud Foundry website. So, sit back, relax, and enjoy the flight to the clouds! 

-------

Author Bios:

Josh Long (@starbuxman, and josh.long@springsource.com) is the Spring developer advocate. Josh is the lead author on Apress’ Spring Recipes, 2nd Edition, O'Reilly's “Getting Started with Spring Roo,” Manning’s “Cloud Foundry in Action.” and a SpringSource committer and contributor. When he's not hacking on code (for Spring Integration, Spring Batch, Spring MVC, Activiti, and much more), he can be found at the local Java User Group or at the local coffee shop. He blogs at springsource.org, blog.springsource.org or joshlong.com.

Andy Piper is part of the VMware Developer Relations team, and works as Developer Advocate for Cloud Foundry, the Open Source Platform-as-a-Service. He is probably best known online as a “social bridgebuilder” spanning a number of areas of technology and interest. He was previously with IBM Software Group for more than 10 years, as a consultant, strategist, and WebSphere Messaging Community Lead.

This tutorial originally appeared in Java Tech Journal - PaaS Above The Cloud Hype. Check out more of that issue in the link.

Pages

Josh Long
Josh Long
Andy Piper
Andy Piper

What do you think?

JAX Magazine - 2014 - 03 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions