DevOps Zone is brought to you in partnership with:

Passionate about technology and startups. Have worked for the BBC in London, Livedoor.com in Japan, Cloudera in San Francisco and MailChannels in Vancouver, Canada. Currently reside in Vancouver where I'm working on building PaaS based on Cloud Foundry, called Stackato. I enjoy writing about technology, especially when it relates to interesting startups. Phil is a DZone MVB and is not an employee of DZone and has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

Debugging Node.js Applications in Stackato

11.14.2013
| 6437 views |
  • submit to reddit

This post was originally written by Ho Ming Li.

Let’s face it, there will be bugs...in my applications and yours. From println/echo debugging to using full-on debuggers, a developer will no doubt spend a portion of his or her time debugging applications. By now, most developers are familiar with the various debugging tools in their local development environment, but as they step towards cloud deployments, how can they achieve the same? Is remote debugging even possible in the cloud? Well of course it is.

We have seen earlier how to debug Java applications in Stackato using the Harbor service. Recently I asked whether or not we can debug Node.js applications in Stackato, and so I took a look at node-inspector.

Straight from the project's README file, "Node Inspector is a debugger interface for node.js using the Blink Developer Tools (former WebKit Web Inspector)."

Without further ado, here are the steps for setting up node-inspector to debug a Node.js application. We'll use haste-server as an example.

Note: The commands in this article are for Stackato version 2.10.6 (based on Cloud Foundry v1). Some of the commands and app config will be slightly different using Stackato 3.0.

  1. Make sure to include node-inspector in your package.json:

        "dependencies": {
        "winston": "0.6.2",
        "connect": "1.9.2",
        "redis-url": "0.1.0",
        "redis": "0.8.1",
        "uglify-js": "1.3.3",
        "node-inspector": "0.5.0"
      },

  2. Change the default stackato.yml config file to add a Harbor port service and a --debug flag to the command used to start the server:

      name: hastebin
      mem: 128M
      services:
        file-backing: redis
        debug-port: harbor
      processes:
        web: node --debug server.js
  3. Target the client, authenticate, then push the application code and config:

      $ stackato target api.stackato-demo.local
      ...
      $ stackato login
      ...
      $ stackato push -n

  4. Once the app is running, SSH into the app container and run node-inspector with the port number returned by $STACKATO_HARBOR:

      $ stackato ssh hastebin
      hastebin.stackato-demo.local:~$ node-inspector --web-host 0.0.0.0 --web-port $STACKATO_HARBOR
      Node Inspector v0.5.0
       info  - socket.io started
      Visit http://0.0.0.0:4100/debug?port=5858 to start debugging.

  5. From the local machine, find out the external Harbor port:

     $ stackato service debug-port | grep port
     debug-port 
    | - port      | 39023 
    | - tags      | harbor harbor-1.0 {Persistent external ports service} | 

  6. Open browser and navigate to http://<app url>:<ext-harbor-port>/debug?port=5858

    node-inspector

  7. With the Harbor port service available in Stackato, you can now easily debug your Node.js application running in the cloud with node-inspector. However, like any other awesome feature, it is not without its caveats. In order to run node-inspector, be prepared to increase the memory limit for the application as overhead for the debugger. Also, this approach is for debugging a single instance Node.js application - when scaled out to multiple instances, things can get a little more complicated.

    If you are a developer with a Node.js application that you want to move to the cloud, download the Stackato microcloud and give it a try.

Published at DZone with permission of Phil Whelan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)