Saturday, April 19, 2014

Developing OpenShift Node apps with local Grunt

The last episode didn't really have an ending. I decided that perhaps it wasn't the right approach. While I enjoyed what Yeoman angular-fullstack offered, it may be a bit too opinionated/confined. I still think that OpenShift is a platform worth playing with, and my new aim is to find a way to make local development (perhaps with livereload) play nicely with OpenShift. So my new approach is to start with OpenShift, and gradually load other parts in. Ideally, I'd like this to work from my Windows machine without having to run a local OpenShift Origin.

If you want to follow along, you'll need to create an OpenShift account.

I started by creating a new node.js app on OpenShift Online, which I called nodule. OpenShift gives me the command line to clone the app locally:
> git clone ssh://5350ba6be0b8cd0c52000024@nodule-yesberg.rhcloud.com/~/git/nodule.git/
> cd nodule/
The app consists of  5 files and an empty directory.
nodule> ls -l
total 47
-rw-rw-rw-   1 user     group         178 Apr 18 15:51 README.md
-rw-rw-rw-   1 user     group         457 Apr 18 15:51 deplist.txt
-rw-rw-rw-   1 user     group       39855 Apr 18 15:51 index.html
drwxrwxrwx   1 user     group           0 Apr 18 15:51 node_modules
-rw-rw-rw-   1 user     group         701 Apr 18 15:51 package.json
-rw-rw-rw-   1 user     group        4790 Apr 18 15:51 server.js
I want to be able to develop this code locally, so I need to be able to run it. I tried node server.js, but it gave an error at (ironically) "throw err;". Time to delve a little more.

The README.md file points to the OpenShift documentation for the nodejs cartridge. The deplist.txt file contains a message noting that it's deprecated and that dependencies should be described in package.json. The package.json file shows that the app has a single dependency, express.js 3.4.4. To install that, I used npm.

nodule> npm install
A screen full of npm http GET commands rolled past, and there is now an express directory inside node_modules, and another dozen inside express\node_modules. Now I can successfully run the app:

nodule> node server.js
No OPENSHIFT_NODEJS_IP var, using 127.0.0.1
Warning: express.createServer() is deprecated, express applications no longer inherit from http.Server, please use:
  var express = require("express");
  var app = express();
Fri Apr 18 2014 16:01:40 GMT+1000 (E. Australia Standard Time): Node server started on 127.0.0.1:8080 ...
I pointed Chrome to http://127.0.0.1:8080 and saw the familiar OpenShift app boilerplate index.html. That's a good start.

Before I make a change to index.html and commit and push, I want to check out what the local file system is like on the server. I would like to be able to avoid committing the node_modules, so I want to understand how that works. After using ssh to connect, and tree to see the file system hierarchy, it seems that the server has a bunch of node_modules available (async, connect, express, formidable, generic_pool, mime, mkdirp, mongodb, mysql, node-static, pg, and qs) at /dependencies/nodejs/node_modules.

So the next step is to make a small change to index.html, and to see if I can see that in the browser. Refresh. Refresh. Change isn't appearing. Stop the node server and restart - works. Well it's good to see, but it's not satisfactory for a development environment. Can't wait to get the livereload going! But ideally it will be part of the development environment only, and not the OpenShift one. It would be nice to have a staging/testing server in the cloud, and it might not matter if such a server had dev-dependencies loaded. But I want to make sure that I can configure a production-shaped system there.

Well perhaps it's best to exercise the commit/push process once before playing with connect-reload. I'm pretty new at git...

nodule>git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       modified:   index.html
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       node_modules/.bin/
#       node_modules/express/
no changes added to commit (use "git add" and/or "git commit -a")
nodule>git add index.html
nodule>git commit -m "Modify index"
[master c25d1a4] 
Modify index 1 files changed, 
263 insertions(+), 270 deletions(-) 
rewrite index.html (83%)
nodule>git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 313 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Stopping NodeJS cartridge
remote: Fri Apr 18 2014 03:55:55 GMT-0400 (EDT): Stopping application 'nodule' ...
remote: Fri Apr 18 2014 03:55:55 GMT-0400 (EDT): Stopped Node application 'nodule'
remote: Saving away previously installed Node modules
remote: Building git ref 'master', commit c25d1a4
remote: Building NodeJS cartridge
remote: npm info it worked if it ends with ok
remote: npm info using npm@1.2.17
remote: npm info using node@v0.10.5
remote: npm info preinstall OpenShift-Sample-App@1.0.0
remote: npm info trying registry request attempt 1 at 03:56:01
remote: npm http GET https://registry.npmjs.org/express
remote: npm http 200 https://registry.npmjs.org/express
remote: npm info retry fetch attempt 1 at 03:56:01
remote: npm http GET https://registry.npmjs.org/express/-/express-3.4.8.tgz
remote: npm http 200 https://registry.npmjs.org/express/-/express-3.4.8.tgz
remote: npm info shasum aa7a8986de07053337f4bc5ed9a6453d9cc8e2e1
remote: npm info shasum /tmp/npm-452368-ggNewZcR/1397807761356-0.1033226354047656/tmp.tgz
remote: npm info shasum b9556fdb117f47bb5a97bc61ab5af7fc2dad8928
remote: npm info shasum /var/lib/openshift/5350ba6be0b8cd0c52000024/.npm/express/3.4.8/package.tgz
remote: npm info install express@3.4.8 into /var/lib/openshift/5350ba6be0b8cd0c52000024/app-root/runtime/repo
remote: npm info installOne express@3.4.8
remote: npm info /var/lib/openshift/5350ba6be0b8cd0c52000024/app-root/runtime/repo/node_modules/express unbuild
remote: npm info preinstall express@3.4.8
remote: npm info trying registry request attempt 1 at 03:56:02
remote: npm http GET https://registry.npmjs.org/connect/2.12.0
And about 10 screenfuls later,

remote: npm info ok
remote: Preparing build for deployment
remote: Deployment id is d0a8dd36
remote: Activating deployment
remote: Starting NodeJS cartridge
remote: Fri Apr 18 2014 03:56:18 GMT-0400 (EDT): Starting application 'nodule' ...
remote: -------------------------
remote: Git Post-Receive Result: success
remote: Activation status: success
remote: Deployment completed with status: success
To ssh://5350ba6be0b8cd0c52000024@nodule-yesberg.rhcloud.com/~/git/nodule.git/   
105dafe..c25d1a4  master -> master
Yes, it seems that the OpenShift Online page now shows my update --- good. When I login via ssh, it seems that the /app-root/runtime/repo/node_modules directory now has express and below that all its dependencies. I don't understand. Why did it work before with express elsewhere? Was it something I did that made node want to install express in the application itself? That's a mystery for another time, I suppose.

Now to start with the development environment. It seems that for now the essential tool is Grunt. That will run karma tests, jshint, and the live reloading that I find so neat. It took me quite a while to get the live reloading working. There are so many plugins that all seem to do similar things. I found it hard to understand how they should work together - each one seems to publish only a fraction of a gruntfile on its own readme.

I found that Romaric Pascal's tutorial at Rhumaric was the best way to get started with live reloading.

To start with, I need to install Grunt and some plugins.

> npm install grunt grunt-contrib-watch grunt-express grunt-open load-grunt-tasks --save-dev
Then I created a Gruntfile.js to get things started:

'use strict';

var path = require('path');

module.exports = function (grunt) {

  // Load grunt tasks automatically
  require('load-grunt-tasks')(grunt);

  // Define the configuration for all the tasks
  grunt.initConfig({

    express: {
      options: {
        port: 8080
      },
      devServer: {
        options: {
	  bases: path.resolve('.'),
	  livereload: true,
        }
      },
    },
    open: {
      server: {
        url: 'http://localhost:<%= express.options.port %>'
      }
    },
    watch: {
      all: {
	files: 'index.html',
	options: {
          livereload: true
        }
      }
    },

  });

  grunt.registerTask('default', [
      'express:devServer', 'open', 'watch'
  ]);
};

This file sets up three tasks (express, open, and watch), and then runs them all as the default target. It's very basic for the moment, with no karma or jshint, and only serving the index.html as a static file (rather than through the express app). I saved that file at the top level of my project and started it all up from the command line.

nodule>grunt
Running "express:devServer" (express) task

Running "express-server:devServer" (express-server) task
Web server started on port:8080, no hostname specified [pid: 10184]

Running "open:server" (open) task

Running "watch" task
Waiting...

It was nice to see that a new tab opened on my browser (Chrome) and showed the index.html page. I edited and saved the file, and magically the page in my browser updated! The console showed

>> File "index.html" changed.
Completed in 0.001s at Sat Apr 19 2014 15:25:25 GMT+1000 (E. Australia Standard Time) - Waiting...
Now, I need to git add the package.json and Gruntfile.js, git commit, and git push, and see what OpenShift makes of it all. There is heaps of line noise as OpenShift tries to install all the devDependencies, but it finally all breaks because grunt-cli isn't installed. There are other 3rd-party cartridges you could use if you wanted grunt on OpenShift, but I don't. What I want is to make OpenShift only install the production dependencies. And it seems this is now possible.

nodule>rhc env set NODE_ENV=production -a nodule
Password: *********
Setting environment variable(s) ... done
I touched the package file and added, committed, and pushed, and OpenShift deployed the system successfully.

That's all I have time for at the moment. Next steps will be to improve the Gruntfile to add some karma and jshint, and to make sure that it's running the express app, rather than just serving static html.

Monday, January 27, 2014

Adventures with the MEAN Stack and Openshift

I'm rewriting an application. The existing user experience isn't too bad, but it could be better. And the code... But I'm also trying to stay up-to-date, or at least not-too-far-behind. So my aim is to use some modern technologies to make a Good single page application. Technologies of interest include:
  • Node. I'm learning more and more about just how great Javascript can be. 
  • Angular. Before choosing angular, I read a few comparisons with Ember, Knockout, and others. I think Angular was a fairly easy choice, but I wanted to be sure that I would have company.
  • Mongodb. I haven't used a NoSQL for anything more than a tutorial or two. This one seems to be pretty popular. My application will certainly not qualify as Big Data, so I'm sure that just about any SQL/NoSQL system would be fine. But at least I'll learn. Mongoose seems to be the obvious object-database bridge.
  • Bootstrap. I've played with YUI and Google Web Toolkit, but never used Less or any serious CSS framework.
  • Karma and Grunt for rapid testing and development.
  • Openshift: Red Hat's PaaS offering.

MEAN stack running Locally

I decided that the Yeoman angular-fullstack generator would be a good ramp to get me going. There are a few pre-requisites (Node, Yeoman, Bower) which I had already installed before documenting this. If I get time, I'll try on a fresh VM to clarify these. But to start my application, I made myself a nice fresh directory and typed
yo angular-fullstack
I declined the offer to use Sass and Compass for now, but did choose Twitter Bootstrap, all the Angular components (resource, cookies, sanitize, and route), and Mongo & Mongoose. The screen filled with all sorts of downloads. I'm sure I won't even see most of these, let alone learn what they actually do or how to use them in anger. But that's layering (complexity management) for you. After a few minutes, my scaffolded app was ready, and all I had to do was type
grunt serve
and the Node server started, warned me that it couldn't connect to a Mongo on localhost, and then my app page appeared in my browser. It was a little short on detail, but I didn't know that at the time.

I installed mongo in c:\mongodb, and created a config file which simply included a line "dbpath = c:/mongodb/db". I started mongo daemon with the command
bin\mongod --config conf\mongodb.conf
Now I can terminate grunt (ctrl-c) and restart it. A new page appeared, this time with  list of "awesomeThings" retrieved from the database. But that wasn't the most awesome thing: if I edit one of the files, such as app/views/index.html, and save, the browser refreshes. And if I edit server-side javascript and save, the server restarts, and then the browser refreshes. Thank you connect-livereload!

After experimenting with, and learning a little about angular, express, and bootstrap, I wanted to show what I had to a friend. I decided I'd look for a cheap cloud host. Openshift (Paas) was the winner (small app for free), closely followed by DigitalOcean (IaaS). (I've also been playing around with Vagrant and noticed that Packer.io supports DigitalOceans nicely.)

MEAN on Openshift

The question was: how to get the Yeoman app onto Openshift. On Openshift, I created an account, and then started a new app with Node 0.10.0 and Mongo 2.2. It came with a default starter app, which I could clone with git. I could also log in using Putty, which is useful for debugging. It's great that something as simple as "git push" can stop, rebuild, and restart the Openshift app. Similar to Jenkins, but still great.

So after cloning the repository to my local pc, I can download all the dependencies and start the system with 
npm install
node server.js
Then I can point my browser to http://localhost:8080 and there's the app (a single page with some helpful links to Openshift/Node info. And for fun, I can look at the other route installed: http://localhost:8080/asciimo .

The Openshift default app is much smaller than the Yeoman angular-fullstack one. It only has a single npm dependency in the node_packages directory (express), compared to the Yeoman's 45 (including a variety of Grunt support, Karma testing support, and mongoose). So perhaps I should simply copy the Yeoman app into the Openshift directory and commit & push. That way I could have the Karma and Grunt benefits locally.

One significant challenge with this approach is that Openshift installs all those dependencies - even the ones which are for development only. It's true that Openshift has Jenkins support, so running tests is quite feasible. But it means that the post-git-push build step takes fifteen minutes (in stark contrast to the 2s Grunt connect-livereload!), and it uses 75MB of storage and more than 12,000 files! Not ideal for a free system, even if there's 1GB quota per gear, with the first 3 gears free. I'd like to be able to tell my Openshift npm to only install the production npms. I decided (at least for this test) not to commit the node_packages directory. The advice seems to be that node_packages should be committed, but only for long term stability.

So I commit and push, and wait the 15 minutes for all the npm activity (which shows up as part of the git push) to finish. It finishes with 
remote: npm info ok
remote: Preparing build for deployment
remote: Deployment id is a6d28b2f
remote: Activating deployment
remote: Starting MongoDB cartridge
remote: Starting NodeJS cartridge
remote: Result: success
remote: Activation status: success
remote: Deployment completed with status: success
To ssh://52e60ad95004463c5b000384@test2-yesberg.rhcloud.com/~/git/test2.git/
   809f542..5897269  master -> master  

The words "Status: success" sound good. But when I go to my app page, I get a 503 Service Temporarily Unavailable. To locate the problem, I need to login with Putty. (Or I could use the rhc app: rhc ssh). To see the log files, I need to use the tail_all command. (Note that this only works from the home directory.) Every couple of seconds, it seems there's a new copy of the following error:
Error: listen EACCES    at errnoException (net.js:884:11)    at Server._listen2 (net.js:1003:19)    at listen (net.js:1044:10)    at Server.listen (net.js:1110:5)    at Function.app.listen (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/application.js:533:24)    at Object. (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/server.js:39:5)    at Module._compile (module.js:456:26)    at Object.Module._extensions..js (module.js:474:10)    at Module.load (module.js:356:32)    at Function.Module._load (module.js:312:12)DEBUG: Program node server.js exited with code 8
DEBUG: Starting child process with 'node server.js'
It looks like the listen() call on line 39 of server.js is failing. The default with Yeoman had been 9000 (although the server.js code has 3000 as another possibility), whereas the Openshift port was 8080. And if I type "export" at the Openshift shell, there is an environment variable 

 OPENSHIFT_NODEJS_PORT="8080"

On systems I'm used to, listening on the wrong port wouldn't give an EACCES error. But I notice that there are SELINUX environment variables - perhaps this is all part of multitenant hosting (assuming that's what Red Hat does with Openshift). I decided to try to adjust my local app to use 8080. And then I need to ensure that the livereload facility doesn't cause problems - it uses websockets on a high numbered port to ask the browser to reload.


I don't really understand exactly how it's all working under the hood at this stage. But I notice the following snippet in server.js
// Start server
var port = process.env.PORT || 3000;
app.listen(port, function () {
  console.log('Express server listening on port %d in %s mode', port, app.get('env'));
});
It looks like something must be setting the PORT environment variable to 9000 - otherwise we'd be using 3000. So if I grep for 9000, I find the Gruntfile.js includes
    express: {
      options: {
        port: process.env.PORT || 9000
      },
      dev: {
        options: {
          script: 'server.js',
          debug: true
        }
      },
      prod: {
        options: {
          script: 'server.js',
          node_env: 'production'
        }
      }
    },
So I could just change the 9000 to 8080 in the Gruntfile, but then Openshift isn't using Grunt. So I decided to use a Console.log just before the listen command (instead of just after it) to display the value of port. And given the length of time it takes to deploy (only 5 minutes this time), I thought I'd add in another "or":
var port = process.env.OPENSHIFT_NODEJS_PORT || process.env.PORT || 3000;
console.log("Attempting to listen on port %d",port);
The push, deploy and activation succeeds again.but still gives a 503 error. The log shows the following every 2-3s.


connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0
Attempting to listen on port 8080
events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: listen EACCES
    at errnoException (net.js:884:11)
    at Server._listen2 (net.js:1003:19)
    at listen (net.js:1044:10)
    at Server.listen (net.js:1110:5)
    at Function.app.listen (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/application.js:533:24)
    at Object. (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/server.js:40:5)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
DEBUG: Program node server.js exited with code 8
DEBUG: Starting child process with 'node server.js'
So it is now attempting to use 8080, but still throwing the EACCES error. An answer on Stackoverflow suggests that it might be the hostname, rather than the port. I guess I need to add another argument to the listen().
var port = process.env.OPENSHIFT_NODEJS_PORT || process.env.PORT || 3000;var ip = process.env.OPENSHIFT_NODEJS_IP || "127.0.0.1";console.log("Attempting to listen on port %d on IP %s",port,ip);app.listen(port, ip, function () {  console.log('Express server listening on port %d in %s mode', port, app.get('env'));});
While I'm there, it seems that I should adjust the database connection details. Rather than hard coding, I can use an environment variable. This is an extract from lib/db/mongo.js
var uristring =
    process.env.OPENSHIFT_MONGODB_DB_URL ||
  process.env.MONGOLAB_URI ||
  process.env.MONGOHQ_URL ||
  'mongodb://localhost/test';
The 503 error has now disappeared, but is replaced by:
Error: Failed to lookup view "index" in views directory "/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/app/views"    at Function.app.render (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/application.js:493:17)    at ServerResponse.res.render (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/response.js:798:7)    at exports.index (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/lib/controllers/index.js:18:7)    at callbacks (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/router/index.js:164:37)    at param (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/router/index.js:138:11)    at pass (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/router/index.js:145:5)    at Router._dispatch (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/router/index.js:173:5)    at Object.router (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/lib/router/index.js:33:10)    at next (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/node_modules/connect/lib/proto.js:193:15)    at Object.methodOverride [as handle] (/var/lib/openshift/52e60ad95004463c5b000384/app-root/runtime/repo/node_modules/express/node_modules/connect/lib/middleware/methodOverride.js:48:5) 
GET / 500 46ms - 1.52kB
Using Putty, it seems that there's no "app/views" directory. I am more comfortable with hg than git, but could I have forgotten to commit the views somehow? Then I noticed that the .gitignore file provided by Yeoman included a line "views". I don't understand why that would be appropriate, so I deleted the line, committed and pushed.

This time, when I refresh my Openshift app page, the result is a blank white page. View Source shows that the index.html file is there. The problem is that all the css and javascript files refer to the bower_components folder, which is absent.
       

When Grunt starts up the system locally, it runs Bower, which downloads the appropriate js & css components according to bower.json. But Grunt isn't running on Openshift.  I decided to check to see whether the browser was receiving a 404 error for those files. But it wasn't. In fact, it was receiving a copy of index.html for each one of the files. The server.js file was routing any default GET to the index.index function:

// Angular Routes
app.get('/partials/*', index.partials);
app.get('/*', index.index);

So I need to choose one of the following approaches
  • run bower on Openshift
  • install all the framework files (.js and .css) into the repository,
  • or point to the CDN instead of bower_components
(To be continued...)