Thursday, December 18, 2014

Wordpress on CloudFoundry

If you're looking for a guide on how to run Wordpress on CloudFoundry, I've written a blog post for work which walks through the process.

Here's a quick overview of the article. It shows you how to...

  • Obtain an account with the Cloud Foundry provider of your choice
  • Install the cf client on your PC
  • Setup persistent storage for your WordPress assets
  • Create a MySQL Service
  • Configure WordPress
  • Deploy to Cloud Foundry
  • Optionally scale the application to meet your performance and redundancy requirements
There's also short video that shows the process.

Friday, August 22, 2014

Debugging Java Applications on CloudFoundry

In many cases, it’s possible to run applications locally and when doing so it’s easy enough to debug them using Eclipse or your favorite Java IDE. In some cases, perhaps due to required third party services or maybe just because you want to see how it runs in a different environment, you want to run the application in CloudFoundry.

Because of the way that CloudFoundry deploys your applications and isolates them, it’s not possible to just connect to your application with the remote Java debugger. Instead you need to flip things around and instruct the application to connect to you.

Here are the instructions for setting up remote debugging when using bosh-lite or a CloudFoundry installation that can connect directly to your PC or laptop.

  1. Open Eclipse and your project.
  2. Right click on your project, go to Debug as and pick Debug Configurations.
  3. Create a new Remote Java Application.
  4. Make sure your project is selected, pick Standard (Socket Listen) from the Connection Type drop down and set a port (make sure this is open if you’re running a firewall).
  5. Press the Debug button.

The debugger should now be running. If you switch to the Debug perspective, you should see your application listed in the Debug panel and it should say “Waiting for vm to connect at port ”.

The next step is to push your application to CloudFoundry and instruct it to connect to the debugger running on your local machine. Here are the steps to accomplish that (note I’m using the Spring Music application for this demo).

  1. Edit your manifest.yml file. Set the instances count to 1. If you were to set this greater than one, you’d end up with multiple applications trying to connect to your debugger.
  2. Also in manifest.yml, add the env section and setup a variable called JAVA_OPTS. In that, you’ll want to add the remote debugger configuration which looks like this -agentlib:jdwp=transport=dt_socket,address=<your-ip>:<your-port>.
  3. Save the manifest.yml file.
  4. Run cf push.

When that completes, your application has started successfully and you see that the application is now connected to the debugger running in your IDE you are all set. From here, you can add breakpoints and interrogate the application just as you would if it were running locally.

If this does not work, try running cf logs --recent to investigate what happened when the application started. If there was a connection problem, you’ll see it in the output.

Firewalls & NAT

Previously I mentioned that these instructions would only work if the remote debugger could connect directly to your PC or laptop. If you’re like most people and behind a corporate or personal firewall and NAT, debugging from a public cloud offering like PWS is not going to work. It simply won’t be able to connect to your machine. Fortunately, there are a some approaches to working around this.

Port Forwarding

One options is port forwarding. If you’re behind a home router, this may be an option for you. Most home routers (enterprise ones do too, but your admin probably won’t want to do this) support the option for forward a request to the router on a designated port to a machine on the local network. As you can probably guess, if we set up port forwarding on our home router for the debug port, we can then redirect those requests to our PC or laptop.

The basic steps for this would look like this.

  1. Pick an incoming port and configure the router to forward this to your PC or laptop. Your router may support forwarding this to a different port on your local machine. For simplicity, I’d suggest using the same port for both.
  2. Start the debugger and listen on the port that the router is going to forward requests to on your machine.
  3. Edit your manifest.yml file. Set JAVA_OPTS to -agentlib:jdwp=transport=dt_socket,address=<your-ip>:<your-port>.
  4. Run cf push.

If port forwarding works correctly, you should see the same results as above with the remote application connecting to your IDE’s debugger. If not, you may need to look at the application logs or even your router’s logs to troubleshoot further.

SSH Tunnel

Another option, if you have a publicly accessible server somewhere, is to tunnel the connection to your machine over SSH. With this option, you simply connect to your public machine with SSH and setup a reverse tunnel. The application will connect to the tunnel, which is listening on your public machine and it’s traffic will be forwarded to your local machine over SSH.

The basic steps for this would look like this.

  1. Obtain a public server.
  2. Install SSHD. Edit /etc/ssh/sshd_config, add or set GatewayPorts to yes. Restart SSHD.
  3. On your local machine run ssh -f -N -T -R<public-port>:<debugger-port> <user>@<public-server-ip> (Windows users can use cygwin or possibly Putty, although the command will be different). This will instruct SSH to connect to the remote host, setup a reverse tunnel and go into the background. The reverse tunnel will listen on your public server on the port you specify (i.e. public-port) and forward traffic to the debugger port on your local machine. You can use different port numbers, but it is easiest if you just use the same port.
  4. Start the debugger and listen on the same port (i.e. debugger-port) that you used in the SSH command.
  5. Edit your manifest.yml file. Set JAVA_OPTS to -agentlib:jdwp=transport=dt_socket,address=<your-ip>:<your-port>.
  6. Run cf push.

If the SSH reverse tunnel works correctly, you should see the same results as above. If not, you’ll need to check the application logs or public server logs for more details.

Concerns / Risks

When using an SSH tunnel in this manner, there are a few things to keep in mind.

  1. By routing the debugger through an SSH tunnel, you’re going to add latency to the connection, especially if it goes over the public Internet. This latency will be noticed through the debugger and can slow down the startup of an application. To compensate for this, you may need to increase the application startup timeout with the -t argument to cf push.
  2. If there is a firewall on your public server, it may may block the connections from your application to the public server. In other words, it will likely prevent the tunnel from listening on the . You’ll need to adjust your firewall rules to allow this.
  3. You must set the GatewayPorts setting in your sshd_config file. This enables remote hosts (i.e. your application’s debugger) to connect to the <public-ip>:<public-port>. Without this, SSHD will only bind to the localhost.

Thursday, July 31, 2014

SpringOne 2GX 2014 is being held in Dallas, TX and I've been lucky enough to be selected to speak again this year.   I'll be co-presenting at the event with Stuart Williams, our presentation is Fastest Servlets in the West.  The session will talk about, you guessed it, performance of Servlet based applications running in Apache Tomcat.  We'll also talk about load testing, tuning the container and offer some tips for squeezing every bit of performance out of your app when it's running on Apache Tomcat.

The conference runs from Sept 8th to Sept 11th this year, with our talk scheduled for the first day at 12:45 PM.  If you're planning to come, register soon as early bird registration (saves you $150) ends, August 9th!

Tips on Migrating to Tomat 8 - Resources

One of the major changes from Tomcat 7 to Tomcat 8 was a refactoring with how Tomcat handles web application resources.  With Tomcat 7, there are features like aliases, VirtualLoader and VirtualDirContext that provide admins with a way to pull external resources into an app.  Unfortunately, each one of these features was implemented separately so to consolidate things and make them easier to maintain in Tomcat 8, all of these different implementations were combined into one resources framework which now handles all of that functionality.

Because of the consolidation and refactoring, several attributes from the Context configuration were removed and replaced with the Resources configuration.  This migration tip discusses how to switch from using common variations of the old Tomcat 7 configuration to the new Tomcat 8 Resources configuration.


In Tomcat 7, the Context configuration tag has an attribute called aliases which can be used to provide a list of external locations from which Tomcat will load resources for the context.  There were a few reasons to use this, but one common reason was to use it to include static resources or configuration that an administrator wanted to place outside of a WAR file.

Here's an example configuration using aliases.
<Context aliases="/images=/var/www/images" />

Here's an example of the same configuration using Tomcat 8's Resources.
    <PostResources className="org.apache.catalina.webresources.DirResourceSet"
                   base="/var/www/images" webAppMount="/images" />


The VirtualDirContext feature is similar to aliases but was targeted as a development feature.  The suggestion for using it is so that you do not have to deploy an entire WAR file.  Instead, you can point to the location of your static resources in your project and only copy, zip and deploy the code itself.

Here is an example of how this was used under Tomcat 7.  In this case, I'm using it to point to picture and movie assets that need to be included with the application.
    <Resources className="org.apache.naming.resources.VirtualDirContext"
               extraResourcePaths="/pictures=/Users/theuser/mypictures,/movies=/Users/theuser/mymovies" />
The same configuration under Tomcat 8 would look like this.
    <PostResources className="org.apache.catalina.webresources.DirResourceSet"
                   base="/Users/theuser/mypictures" webAppMount="/pictures" />
    <PostResources className="org.apache.catalina.webresources.DirResourceSet"
                   base="/Users/theuser/mymovies" webAppMount="/movies" />

It's also possible to use a PreResources tag, instead of the PostResources.  The difference would be that resources listed with a PostResources tag are checked after resources bundled in the web applications and resources with the PreResources tag are checked prior to resources bundled in the web application.  In other words, PreResources can be used to override a resource that is included with an application.


The VirtualWebappLoader feature is used to add additional directories or JAR files onto the class path.  This is different from the previous two options because it allows you to add JAR files, classes or configuration to the class path and not just the file system.  Again, there are a few reasons why you might want to do this, one common reason was so that you could pull JAR files out from the WAR file to a centralized location.

Here's an example of how this was configured with Tomcat 7.
  <Loader className="org.apache.catalina.loader.VirtualWebappLoader"
          virtualClasspath="/apps/shared/lib/*.jar,/apps/shared/classes" />
Here's an example of how this is configured with Tomcat 8.
    <PostResources className="org.apache.catalina.webresources.DirResourceSet"
                   base="/apps/shared/lib" webAppMount="/WEB-INF/lib" />
    <PostResources className="org.apache.catalina.webresources.DirResourceSet"
                   base="/apps/shared/classes" webAppMount="/WEB-INF/classes" />
If you were using the searchExternalFirst attribute of the VirtualWebappLoader class, switching from using a PostResource tag to a PreResource tag should allow you to achieve the same behavior.

Additional Information

That covers some of the common configuration scenarios that have been changed due to the new Resources API.  For more information on this change, I would suggest the following resources.

Feel free to drop me a comment if I missed anything.

Thursday, March 20, 2014

SpringOne2GX Video

My presentation from SpringOne2 GX 2013 is now available online.  It's hosted on InfoQ here.

This is similar to the Webinar that Stuart and I presented last month, but a bit longer (90 mins vs 60 mins).

If you're curious about one of the other sessions from SpringOne 2GX 2013, you can the list of currently available sessions online here.

or on the SpringSourceDev YouTube channel.

Don't see the session you want yet, hang in there.  More sessions are being posted all the time.

Tuesday, March 11, 2014

CloudFoundry & PHP: Update

Back in July, I released a build pack for running PHP applications on CloudFoundry.  Today I'm happy to announce a significant update to the build pack!

This effort is a total rewrite of the original build pack with the following goals.
  • Maintain clean and easily understandable detect, compile and release scripts
  • Execute quickly. Run detect, compile and release scripts with minimal effort, downloading as little as possible.
  • Utilize a default configuration that "just works" for the majority of users.
  • Allow application developers to override default build pack behavior and settings through configuration.
  • Allow the build pack to be extended easily via extensions.
  • Allow application developers to include custom extensions.
  • Not be tied to one particular HTTP server. Support multiple and allow application developers to pick which they use.
  • Provide better insight into the application environment. Allow application and servers to be easily monitored.
  • Integrate all logs and output into loggregator.
The result is a huge improvement, with all the functionality of the old CF PHP & Apache Build Pack and lots of new features including... 
  • Executes quickly. Run detect, compile and release scripts with minimal effort, downloading as little as possible.   
  • Support for the latest versions of Apache HTTPD 2.4 and Nginx 1.5 
  • Support for the latest versions of PHP 5.4 and 5.5 
  • Support for a large set of PHP extensions, including amqp, apc, bz2, curl, dba, gd, gettext, gmp, imap, ldap, mcrypt, mongo, openssl, pdo_pgsql, pgsql, pspell, redis, xdebug and zlib 
  • Versions of HTTPD, Nginx and PHP are automatically upgraded to the latest release just by re-staging an application 
  • Allows for application developers to control which PHP extensions are installed 
  • Allows for application developers to custom configure HTTPD, Nginx and / or PHP 
  • Download location is configurable, allowing users to host binaries on the same network (i.e. run without an Internet connection) 
  • Support for an extension mechanism that allows the build pack to provided additional functionality 
  • Allows for application developers to provide custom extensions 
  • Support for NewRelic with both bound services and when manually specifying a license key 
  • Easy troubleshooting with the BP_DEBUG environment variable 
  • All logging output is routed through stderr & stdout which is sent to loggregator 
If you’re interested in developing PHP applications or running a packaged PHP application on CloudFoundry, please take a look at our “30 Second Tutorial” or one of the build pack samples like PHPMyAdmin, Wordpress or the CodeIgniter Tutorial

Enjoy, and as always, feed back and PR’s are welcome! 

Wednesday, February 26, 2014

Webinar: Introduction to Apache Tomcat 8

I had the opportunity to present a webinar on Apache Tomcat 8 for my employer Pivotal.  It's through the series of free public webinars that they produce on community topics such as the Spring Framework, Groovy, Grails and Java development.

Here's a link to the video and slides.

Here's a link to the code that I demo in the presentation.