10 Reasons OpenShift is the Best Place for Hosting Node.js Apps

When it comes to application hosting, Node.js developers have it easy. This innovative community has spawned several of their own excellent hosting solutions, where basic free-access plans are often readily available. Many of these shops are also excellent open source citizens, making significant contributions to projects that they like to use – helping to advance the status of tools and best-practices employed by the greater community. OpenShift is the first open source application hosting platform to include full support for multitenancy and application auto-scaling over your own open cloud – establishing a new community space for advancing the state of open source computing.

1. OpenShift is Open Source

Although this post puts more focus on using OpenShift to host node.js projects – keep in mind that OpenShift is an open platform built from reusable standards-based components, and is equally capable of being used to host Java, Python, PHP, Ruby, or other types of web applications.

In fact if your project runs on Linux, OpenShift’s extensible tooling can likely be used to build, host, and horizontally scale your solution.

By providing consistent access to pre-configured Linux environments, OpenShift helps to ensure that your applications will be instantly portable across open clouds, while advanced kernel-level resource controls provide hooks for managing the automation of application monitoring and scaling as you grow.

If you are interested in running your own open cloud – Read the docs, get involved, and join the upstream Origin community at openshift.github.io.

When available, OpenShift’s Node.js cartridge will automatically publish connection information to your application via the system environment  (OPENSHIFT_NODEJS_PORT, OPENSHIFT_NODEJS_IP).

In order to maximize your project’s portability, you’ll need to include a small check to test for the presence of these environment variables:

var port = process.env.OPENSHIFT_NODEJS_PORT || 8080
var ip_address = process.env.OPENSHIFT_NODEJS_IP || '127.0.0.1'
server.listen(port, ip_address, function () {
  console.log( "Listening on " + ip_address + ", port " + port )
});

The above example code shows how instance-specific configuration details can be abstracted out of your source, while providing sensible default values that allow your project to run in a variety of environments.

2. Open Source Professionals Support

Red Hat provides free access to it’s own hosted OpenShift deployment: OpenShift Online. It’s the easiest way to get started with OpenShift hosting, and the most convenient way to verify that your project is capable of being run on an open cloud platform.

It is possible to pay for additional system resources as your application scales beyond the initial capacity granted in OpenShift Online’s Free tier.

Red Hat also offers premium support for running your own OpenShift deployment with Openshift Enterprise.

Professional support from a well recognized community of Linux experts, combined with a reliable and consistent release schedule, helps ensure that OpenShift will continue to exist as an active and sustainable open source solution.

3. Automatic Application Scaling

OpenShift-hosted applications can be configured to run as a single instance, or to be part of a scaling group.

For scalable applications, OpenShift can automatically clone additional application instances and shift extra capacity to your application array in response to resource usage and other triggers.

Scaling limits are easily configured via the command line (rhc), the REST API, or the OpenShift web interface.

For example, configuring an application to use a minimum of two instances and a maximum of five can be done in a single command:

rhc scale --cartridge nodejs-0.10 --app YOUR_APP_NAME --min=2 --max=5

This gives developers the ability to instantly provision and manage their own software-defined horizontally-scalable application architectures on-demand.

Support for defining custom haproxy scaling rules, or coding your own application-driven scaling triggers are both possible when working with scaled applications.

4. WebSockets

Websocket support is available on OpenShift!

This is great news for anyone who is interested in incorporating realtime features into their project.

No additional changes are required to your server-side code in order to take advantage of this feature. However, there is one minor complication for client-side connections: For now, clients must be instructed to connect to port 8000 (or 8443) in order to successfully negotiate the websocket connection upgrade.

OpenShift will also make your application externally available on standard web ports (80 and 443), which will eventually gain full support for websocket connections as well.

Server-side connections should always be made to the provided OPENSHIFT_NODEJS_PORT, andOPENSHIFT_NODEJS_IP in order to connect to OpenShift’s automatic routing interface.

5. Persistent Access to Secondary Storage

OpenShift Online provides 1GB of persistent disk storage to each application container. We use RAID5 over Amazon’s EBS to offer additional speed and resiliency for your runtime storage requirements.

The location of this persistent storage area is provided via the OPENSHIFT_DATA_DIR environment variable. This a a great place to stash user-generated content, or other persistent runtime information that should be kept through reboots and deploys (without being checked in to your project’s source tree).

On OpenShift Onine, you can pay for additional storage space. OpenShift Origin and OpenShift Enterprise both allow disk resource allocations to be easily configured per container type. These resource allocation plans are selectable during the app creation process as a “gear size”.

6. Composable Applications

OpenShift provides a convenient and extensible abstraction for including additional service runtimes into your application environment. These packaged Cartridges can be dynamically added to existing hosted applications, or they can be declared as service dependencies during the initial application creation process.

This provides consistent access to advanced technologies such as PostgreSQL, MongoDB, Jenkins, Cron, or other projects that are outside of the scope of npm.

Cartridges which require authentication credentials automatically generate passwords and other secret tokens, and share pertinent connection information with your application via environment variables.

For example, if I wanted to spin up a fresh copy of my recent Node.js and PostGIS mapping application, I could do so with the following command:

rhc app create parks nodejs-0.10 postgresql-9.2 --from-code=https://github.com/ryanj/restify-postGIS.git --env MY_GA_KEY=MY_GOOGLE_ANALYTICS_TOKEN

In this single step, OpenShift will spin up a new hosted Linux environment including nodejs-0.10, postgres-9.2, and the application source code that I listed. The  --from-code flag allows you to initialize your gear by supplying the git source url for your OpenShift-compatible Nodejs project. A nice web-based workflow for creating applications is also available.

Additional developer keys, credentials, or secrets, can also be supplied during your app creation step, or can be configured after the fact (see  rhc env).

When the process completes, OpenShift will return a publicly available URL for accessing the application, and help establish a local clone of the application source that is pre-configured for deployment to your selected OpenShift hosting environment.

OpenShift also includes support for loading experimental cartridge bundles directly from an external Git repo. This provides an easy way for cartridge maintainers to test and share their work.

7. Git Push to Deploy

I can’t think of an easier deployment mechanism than git push.

It’s really become the de-facto deployment workflow for most cloud-centric hosting platforms.

Additional documentation on using OpenShift’s developer workflow, and on deploying and building reusable applications is available on OpenShift.com.

8. Customizable Build Processes

When a simple git push is no longer sufficient, consider taking advantage of OpenShift’s enhanced support for tracked deployments and rollbacks, or plug-in a Jenkins cartridge for instant access to your own hosted continuous integration environment.

rhc cartridge add jenkins

OpenShift also provides a great way to customize your build process by firing off developer-supplied build scripts when appropriate.

9. NPM Integration

OpenShift is designed to read your project’s package.json file and automatically resolve outstanding npm module dependencies as a part of it’s build process.

Tell OpenShift how to start your server by including similar initialization information in your application’s package.json file:

"scripts": {
  "start": "node server.js"
},
"main": "server.js"

OpenShift’s default behavior involves using supervisor to start, watch, and restart your applications.

As usual, local development environments should be initialized by running npm install followed by npm start.

10. Enhanced System Security, Port-Forwarding, and SSH

Unfortunately, many hosting platforms contain proprietary code, or fail to address many system security concerns. With OpenShift, all of our source is publicly available for review, and SELinux is a major part of our stack – helping provide safe access to secure multi-tenant Linux environments.

OpenShift can not guarantee that your code is secure, but it can definitely help ensure that your data and system resource allocations are not impacted by other users on a shared machine.

It’s one of the few platforms that is secure enough to allow direct SSH access to hosted application environments.

Port forwarding is also available for making local connections to hosted services (rhc port-forward).

Built-in tools for setting up SSL connections to your custom domains are another recent addition to the platform.

Add all of this up, and it’s easy to see why OpenShift is my favorite web hosting platform.

Reposted From : OpenShift's Blog