August 25, 2015 | Written by: Lee Surprenant
Share this post:
Jeff Sloyer recently wrote a great post Deploying your Meteor app to Cloud Foundry and Bluemix. On the IBM jStart team, we’ve also seen an uptick in the number of clients interested in Meteor. I sat down with Jeff to compare notes and we’d like to share three tips from our experience of running Meteor.js applications on Bluemix:
- Use the MongoDB OpLog
- Enable session affinity
- Optimize your
Tip #1: Use the MongoDB OpLog
In his introductory post, Jeff recommends using the Sandbox plan of the MongoLab Service from the Bluemix catalog. This works great for development, but when you’re ready to roll out to a wider user base, you’ll want to upgrade your Mongo service to a plan that offers access to the MongoDB OpLog.
Unfortunately, at the time of this writing, this cannot be accomplished directly from the Bluemix console. However, users can configure this level of access by either contacting MongoLab to upgrade to a dedicated account, or by signing up for a free 30-day trial of the newly acquired Compose.io (formerly MongoHQ).
In either case, going “off-catalog” will mean that the Meteor buildpack will no longer be able to automatically set the
MONGO_URL from the
VCAP_SERVICES environment variable. Instead, it will be up to you to set the
MONGO_URL environment variable with the proper connection string. This can be accomplished via either the Bluemix console or the Cloud Foundry CLI with a command like:
cf set-env <APP_NAME> MONGO_URL "mongodb://…"
This post will not go into the “why” of enabling Mongo OpLog access, but for more information on how Meteor.js uses the OpLog to scale your application, please see the following resources:
Tip #2: Enable session affinity
One of the often cited features for hosting Meteor.js applications is support for sticky sessions. Although I’m not sure about its continued importance (given the broad support for web sockets in modern browsers, and the impending demise of IE8), Meteor developers will be happy to know that the Cloud Foundry router has supported session affinity since 2013.
To enable session affinity on your application, simply add the
JSESSIONID cookie to your requests and the router will add a corresponding
__VCAP_ID__ in order to route future requests to the same application instance. In Meteor, this can be accomplished either client or server side. In the future, we’d like to publish a simple package on Atmosphere to make this even easier.
Tip #3: Optimize your cf push
One of the issues we’ve hit with the community buildpack for Meteor is that it seems to push the full Meteor runtime with every deploy. When Jeff and I looked into this, we found that this happens when you
meteor run the application before pushing it to Bluemix.
Fortunately, this issue is easily mitigated by making use of the Cloud Foundry
.cfignore file. By adding the following line to a file named
.cfignore in the root of your application, the Cloud Foundry cli will ignore these local Meteor files and drastically improve the speed of your cf push:
We hope that these tips will help you to find that IBM Bluemix provides an interesting new alternative for hosting your Meteor.js applications. Jeff and I would love to hear your feedback and any suggestions you have, please reach out to us on Twitter @jsloyer and @lmsurprenant!
—Lee Surprenant, IBM jStart