NOTE
StrongLoop Arc and slc are no longer under active development, and will soon be deprecated. Arc's features are being included in the IBM API Connect Developer Toolkit: Please use it instead.
Skip to end of metadata
Go to start of metadata

Overview

Best practices for deploying Node applications are still evolving. The challenges are many-fold: packaging and dependency management, single-step deploy, and starting/re-starting applications with minimal downtime.

StrongLoop Controller supports an integrated deployment workflow:  

  • Use slc build to package your application for deployment.
  • Set up StrongLoop Process Manager on your deployment hosts as an application supervisor and manager.
  • Finally use slc deploy to deploy your application packages to the Process Manager.

Using this workflow with the best practices outlined here will improve the efficiency and reliability of application deployment.

Use the workflow that suits your needs

You can use StrongLoop tools (slc build, slc deploy) with StrongLoop Process Manager in multiple ways, depending on your needs; for example:

  • If you are deploying to Heroku or other cloud platforms, you can benefit from slc build, and its git push capability, but you don't need Process Manager.
  • If you already have a build process that commits your build products into Git or creates a deployable package with the dependencies built into it, you don’t have to replace it with slc build, but you can still use slc deploy and StrongLoop Process Manager.

Build dependencies into your deployable packages

While the package.json file describes application dependencies, it's not suitable for use at deploy-time because running npm install during deployment can fetch different versions of modules, leading to untested combinations and potential breakage.  Although using npm shrinkwrap avoids this issue, npm install still fetches dependencies live at deploy time. If your npm server or npmjs.org is down, you won’t be able to deploy. This is not acceptable.

You can bundle your dependencies, but maintaining bundle specifications manually in the package.json can be problematic: When npmjs.org is down, you won’t be able to deploy. So, you need to automate the bundling using slc build.

Bundling of Node dependencies is only part of the story. While JavaScript doesn’t require compilation, many applications still require building. At deploy time, you may need to fetch front-end dependencies (using Bower, for example).  You might need to minimize Javascript code, and fetch or generate other assets. All of this build output needs to be part of the deployable package. This is not trivial, because npm doesn’t know what it should include in a package. It usually uses the .gitignore to avoid putting ephemeral files into the package, so you’ll need to maintain or generate an .npmignore file.  slc build can help with this, too.

And finally, while using an npm package as your deployable artifact works well for some workflows, particularly when the package is archived in something like Artifactory that prefers a single-file package, many workflows prefer Git for archiving builds. Using Git may even be required, if you are deploying to a platform such as Heroku.

Instead, slc build will commit your dependencies and source onto a deploy branch, not your development or production branches. It will do this for both npm-installed dependencies and the products of custom build tools such as Bower, Grunt, or Gulp.  It will not commit compiled Node binaries from add-ons (unless requested).

Basic use:

Be able to push deploys

You want to push deploys when you decide your new app version is deployable, or perhaps have it automatically pushed to staging by your CI tools.

You should only push apps that have been pre-built to deployment, and staging, but alpha servers can have unbuilt apps pushed, for continuous testing against the latest matching dependencies.

And you want to push either Git branches, or npm packages, as appropriate for your workflow.

slc deploy does all of the above, pushing your app to the StrongLoop Process Manager. If using Git, it can also push to third-party platforms, though in this case its just a thin wrapper around git push remote deploy:master.

Deploy and run your app inside StrongLoop Process Manager

When running an app in deployment (as opposed to development), you need to manage:

  • Logging
  • Application start/stop/restart (hard and soft)
  • Deploying new application versions with zero-downtime upgrade
  • Clustering
  • Profiling and performance monitoring, etc.

You can use StrongLoop process manager to start an app on your workstation with slc start. Once started, you can interact with your app through either a CLI (slc ctl) or a graphical interface (Arc), profile it, try out features, and so on.

StrongLoop Process Manager (StrongLoop PM):

  • Runs under the control of your system process manager.
  • Receives applications deployed to it (with slc deploy).
  • Runs applications under supervision. 

You can deploy both npm packages and Git branches to StrongLoop PM.

Besides exposing all the capabilities of a supervised app (run-time heap snapshot and CPU profile generation, object tracking, worker status and upgrade, and so on), it also supports different application configurations, hard/soft stop and restart, restarting the application on machine boot.

Installing a service so that it runs under your application's process manager is tedious, so the process manager also comes with an installer that will do this for you, creating a specific user to run the manager as, setting up its run directories, and so on. The automated install currently supports systemd and Upstart 1.4 or 0.6.

First, follow the instructions in Setting up a production host to install StrongLoop PM.  Then you can give it a try as a transient process.  in the terminal where you did slc build:

  • No labels