Christopher Frost

Blog

  • 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.

  • Strict JavaScript for NodeJS

    This post is mostly a short reminder for myself as it’s contents is not new. As many of you probably know NodeJS runs on top of Google’s V8 engine, the same JavaScript engine used in the Chrome browser. V8 can take quite a few configuration options, try listing them out. I’m going to talk about the --use_strict option. Unfortunately the description you get is quite limited.

    node --v8-options | grep strict
	--use_strict (enforce strict mode)

    Strict mode is part of ES5 so it’s quite well support in many browsers (except IE9, big surprise) as well as by NodeJS. By specifying it at the NodeJS command line strict mode is enabled for your entire application but it can be enabled on a per-file or function bases as well. Place a Sting literal at the beginning of a file or function to enable it "use strict";. As it’s just a normal String declaration it won’t break old browsers that don’t support strict mode.

    //Normal code
var foo = 'bar';
(function(msg){
	"use strict";
	//Strict code
	alert(msg)
	...
})(foo);
//Normal code

    Shown here inside a self executing function, this is a good pattern for making strict JavaScript libraries. What does strict mode actually do? It makes JavaScript more grown up and stops you doing bad things in your code.

    • Any attempt to get or modify the global object will result in an error: foo = bar;//Error. No var so foo would get set on the global object.
    • null values of this will no longer be evaluated to the global object and primitive values of this will not be converted to wrapper objects.
    • Writing or deleting properties which have there writeable or configurable attributes set to false will now throw an error instead of failing silently.
    • Adding a property to an object whose extensible attribute is false will also throw an error now.
    • A functions arguments are not writeable so attempting to change them will now throw an error arguments = [...].
    • with(){} statements are gone, if you know what they are you hopefully know why and if you don’t, just pretend you never came across them.
    • Use of eval is effectively banned.
    • eval and arguments are not allowed as variable or function identifiers in any scope.
    • The identifiers implements, interface, let, package, private, protected, public, static and yield are all now reserved for future use (roll on ES6).

    To keep JSLint happy you will need to place "use strict"; at the top of every file and when running Node itself you should run with the --use_strict option. This is easy to do with the NPM start script which I hope your using anyway. Change your package.json to contain the following property and start you application with npm start.

    "scripts": {
	"start": "node server.js --use_strict"
},

    I have kept things short here on purpose, for a more in depth look at strict mode and some new JSON features in ES5 have a look at this excellent post by John Resig, ECMAScript 5 Strict Mode, JSON, and More. I hereby give some (but not all) credit to his post for the content in this one. I think the changes strict mode makes and other changes coming in Harmony ES6 show that JavaScript is growing up and has a bright future, well I’m a fan at least.

  • 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.