Christopher Frost

Category: Cloud Foundry

  • Sample Apps for Cloud Foundry

    Working on the Java Buildpack means lots of testing with unit (over 99% coverage) and integration tests but we also have a suite of sample applications to do complete system wide testing. They are all tested during our CI builds and might be useful for people that want to play around with different application types on Cloud Foundry. Find them here in GitHub. The project has a good README so I won’t duplicate it but we have various apps for Spring Boot, Grails, Groovy, Java Main, Play, Ratpack and Spring MVC. Each app supports a number of URL end points that allow exploration of the environment the application is running in from the classpath and environment variables to bound services. These are also all well documented. Getting the applications running is simple. The cf cli tool is required to push applications from the command line, install instructions are here.

    git clone https://github.com/cloudfoundry/java-test-applications.git

    cd java-test-applications

    ./gradlew

    cd ***-application

    To give the application a more descriptive application name the manifest.yml file should be modified.

    cf push

    That’s it. The console output will show the URL the app is bound to. It’s now possible to start looking at the endpoints documented in the README and exploring the applications environment and any bound services.

  • Configuring the Cloud Foundry Java Buildpack

    Until now the preferred way to make changes to the Java Buildpack has been to fork it and edit one of the yaml files in the config directory. If a bigger change is required then the code has to be edited directly. For a configuration change forking can be a pain so there is a new feature that allows an environment variable to be set on an application that will update the value of an existing configuration property.

    The environment variable name must be capitalized, match the name of configuration file to override minus the .yml extension and have a prefix of JBP_CONFIG. The value of the variable should be valid in-line yaml. For example, to change the default version of Java to 7 and make an adjustment to the memory heuristics:

    cf set-env myapp JBP_CONFIG_OPEN_JDK_JRE '[jre: {version: 1.7.0_+}, 
                 memory_calculator: {memory_heuristics: {heap: 85, stack: 10}}]'

    EDIT: This example has been updated.

    Notice that an array is being used so that multiple values can be updated by separating them with a comma. If only one value is being updated then square brackets must still be used to specify an array. If the key or value of a property contains a special character such as : it should be escaped with double quotes. For example, to change the default repository path for the buildpack:

    cf set-env myapp JBP_CONFIG_REPOSITORY '[ default_repository_root: "http://repo.example.io" ]'

    Once the new environment variable has been applied, a running application will need to be restaged for the changes to take effect. Environment variable can also be specified in the applications manifest file. This means that changes can be checked in to source control and don’t need to be specified with every push.

      env:
    JBP_CONFIG_REPOSITORY: '[ default_repository_root: "http://repo.example.io" ]'

    Only existing values can be changed, attempts to add a new configuration property or replace values with hashes (and vies-versa) will result in a warning message and be ignored.

    This new feature will be released shortly and become available in Cloud Foundry but until then it is available for use from the master branch of the Java Buildpack repo.

  • Session Replication on Cloud Foundry

     

    CloudFoundry-2

    I’ve done a short blog post about the new support for using Redis to do session replication on Cloud Foundry with the Java Buildpack. It’s been posted over on the Pivotal Blog, give it a read.

  • Cloud Foundry Video Shorts

    Firstly, CloudFoundry has a shiny new logo. It’s a little more abstract, harder to understand at first glance but I like it, much cleaner.

    CloudFoundryVertical-2

    I’ve done two short videos demoing some new features in the Cloud Foundry Java Buildpack with my finest monotone voice. The first is about using New Relic, it’s now easy. Bind you application to a New Relic service instance and the Java Buildpack will take care of the setup in your application. The second video is about DBaaS auto-reconfiguration. You can rebind your application to different data sources and provided the right Spring beans are available in your application they will be changed to connect to the new database automatically.

    http://youtu.be/qIYU3uOVqTc?list=UU0ZYS0Y7b5oiVLvxGf4magw – DBaaS auto-reconfiguration (1:32)
    http://youtu.be/UMwPj1nTm3U?list=UU0ZYS0Y7b5oiVLvxGf4magw – Binding New Relic to Applications (1:52)

    Enjoy.

  • Checking in Bower dependencies

    I’ve seen a few places recommending that the bower_components folder should be checked in to your version control system. This is wrong, it will just add unnecessary bloat to your repo and risk your dependencies going stale. The only good reason I think of is to avoid having to run bower install all the time but if your developing a Node app there is no need. I can think of some bad reasons as well, like changing the code in the Bower managed dependencies. Least said about that the better.

    I’ve talked before about the NPM lifecycle scripts before, well these can be used to integrate Bower. When you run npm install to install your NPM dependencies you can hook in to it and call out to Bower.

    "scripts": {
    "prepublish": "node_modules/.bin/bower install"
}

    I recommend giving the NPM docs a read. It’s important to understand the possible impact of the different hooks. When you want to run in the install phase it’s recommended to use the prepublish hook instead of any of the actual install hooks. For the above code snipet to work you will also need to ensure Bower is listed as an NPM dependency in the package.json file. If not then the Bower executable will not be available when the script tries to call it and you shouldn’t rely on Bower being available globally. This is also how it’s recommended to setup your apps for deployment to Cloud Foundry. The Cloud Foundry build pack for NodeJS will call npm install --production while staging the application. No need to commit your Bower dependencies when deploying to the cloud either.

  • NodeJS on Cloudfoundry – New Buildpack

    CloudFoundry-1

    Since my last post about monitoring NodeJS applications on CF (CloudFoundry) things have changed, both the NodeJS and CF worlds are fast moving ones. The default Node buildpack is currently a fork of the Heroku one, so most things explained here are relevant to Heroku as well.

    You no longer require a special buildpack to deploy an application on CF and have it monitored by StrongLoop. This also applies by to the New Relic and NodeTime (by AppDynamics) solutions as well. For all three solutions you just have to add a dependency in your applications package.json file and then require it at the beginning of your main JS file. For New Relic and StrongLoop you also have to add a file in the root of your application containing your api key and other config. NodeTime lets you supply this after the require statement, it’s personal taste but I prefer this as it’s one less file in your application root.

    require('nodetime').profile({
  accountKey: your_account_key
});

    The new Node buildpack also brings with it some other changes. Previously you had to specify the command: in the manifest.yml file or provide a Procfile to tell CF how the application should be started. NodeJS, or more specifically NPM (Node Package Manager), provides a set of standard lifecycle hooks for a package that can be specified in your package.json file. Providing a manifest command or the Procfile still work but it’s best practice to use the NPM lifecycle scripts. The hook of interest is the start script, this shows an example scripts property in a package.json.

    "scripts": {
	"start": "node server.js --some_arguments",
	"test": "gulp test"
}

    The CF NodeJS buildpack will look for a manifest command first and then fall back to the Procfile if no command is given. If the Procfile isn’t present it will check for the NPM start script hook and if it exists create a Procfile for you with web: npm start. Finally, if there is no start script, the buildpack will look for a server.js file in the root of the application and if it exists create a Procfile for you specifying web: node server.js. So it is enough just to call your main application file server.js for it to run but it’s best practise to be explicit and specify your NPM start script. Another benefit of using the script hooks is that other services can just call npm start (or any other lifecycle phase) to start your application without having to know the correct command and arguments. Starting with NPM will also add a number of potentially useful environment variable to your application. Remember that manifests and procfiles are specific to PaaSs like CF and Heroku. You can read more about NPM scripts here https://www.npmjs.org/doc/scripts.html.

    Finally, I have created a sample NodeJS application that includes everything I have talked about here and will display the applications environment variables to you. It’s ready to run on any V2 instance of CF. https://github.com/cgfrost/cf-sample-app-nodejs. In this sample application the buildpack is actually specified in the manifest but this is only to ensure you are using the latest NodeJS buildpack as some CF providers haven’t updated yet. As long as you application has a package.json in the root it will be detected and run as a NodeJS application.