Meteor Deployment On DCHQ
Meteor Deployment On DCHQ
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Hosting software remains a pain-point, though. It's never quite as easy as people want it to be. Perhaps that’s because developers now have so many options for establishing basic server tasks — and the foundation of our applications can change fairly quickly. A software framework typically has pretty specific ways of getting things done, and that legacy may span years or decades. On the server side, often you’ll see many different ways of doing the same thing. Most custom server approaches tend to be somewhat different from one another — , depending on the individual experience of the team or individual building it.
Successful Drupal hosting platforms Acquia and Pantheon may serve to highlight this point. Each features a starkly different backend implementation (Pantheon uses Docker; Acquia uses typical VMs) and user interface driving the backend. Each platform leverages completely different philosophies on how things should be done. As a user, it makes you wish you could elect to use the best aspects – and forego the weaker characteristics – of each. That said, the Project Ricochet team recommends both services and use them heavily to deploy Drupal sites.
For many developers, the new dedicated framework hosting options can indeed make projects easier. But if your app has exceptions, services are cost-prohibitive, or there are unique security concerns, tasks can quickly regress from easy to complicated.
When it comes to Meteor, you’ve actually got a lot of options. First, there’s Modulus and Galaxy (which is Meteor’s all-in-one solution for production deployment). You could also opt to “roll your own” (write the core code yourself). Yet still, with dedicated platforms there are three potential problems:
- If you’re a development shop or a company with several apps, pricing can vary from unattractive to quite challenging. Providers seem to want to charge per container — and when you’ve got 10-20 apps in development (or more), you’re rarely leveraging the resources behind the ones you’ve committed to. So, paying for this larger digital footprint seems like a waste of budget dollars.
- If your client is a bank, health care provider, or other large company with highly sensitive data, then a cloud service like Amazon or Rackspace, may just be out of the question. Situations like these often force developers to use a solution that allows you to use your own infrastructure.
- Many of the plug-and-play services don’t provide a database layer. So you’re forced to add another SaaS service on top of the hosting provider.
When none of the prepackaged solutions seem appropriate — you may just need to “roll your own.” Writing your own code from the ground up may seem a bit scary — and frankly it should be if you can’t justify why you’re making that choice. But new tools like Docker and DCHQ do enable you to launch complex architecture on an easy-to-use platform. DHCQ makes deploying containers easier, in part, because it helps you simplify the complex network mapping between hosts on your cluster.
Discover How to “Containerize” Meteor Apps on Docker and DCHQ
When considering Docker and DCHQ, consider how the various services it takes to run Meteor are constructed. Typically you’ll want to begin by isolating each of the individual services and define what needs to come in and out of that service/container. Let’s review a few of the basic services you’ll need to “containerize” a Meteor app:
You’ll need a define build process for generating images for your app.
To scale your app, you’ll need a Load Balancer in front of your node services. This way, when new node processes come on board or drop off as needed, the load balancer can update its configs and reload that configuration.
You’ll need a Docker image for your node app, which should include the source code and node process. If you’re running SSL, you’ll need to consider where the SSL is terminated. You’ll also want to make sure your app will continue to run in the event an error is encountered or the node app crashes.
Meteor is driven by a Mongo database, so make sure to provide one in production. But there are a few options here. You can:
- Use a hosted version like compose.io
- Run dedicated Mongo servers and setup a cluster of VMs each running Mongo
- Spin up a cluster on Mongo containers on DCHQ.io
If you’d rather just get up and running without having to worry about Mongo management, I’d suggest compose.io. If compose.io is out of the question and you’re new to containers and learning on the way, you could invest more time to understand Docker and your MVP by getting your Node app running, and deploying Mongo to a cluster of VMs. (There are lots of articles online to help you explore this.).
If you’re more familiar with Docker, you might consider learning how to launch a Mongo cluster across Docker, since this can offer a fair amount of flexibility going forward. DCHQ provides a Mongo Replica Set Cluster that supports service discovery for typical scale in/out scenarios while rebalancing the replica set. An official blog will be available very soon. Here's the template:
A Closer Look at the Details
How to Build Your Meteor Application Docker Image for Deployment
To deploy your Meteor app, you’ll need to build an image that can run your node app. It’s actually pretty simple for Node and Meteor apps. Below is an example Docker file. It leverages ubuntu 14.04 as a template image, installs some basic packages, installs node 0.10.40, installs npm’s forever package, adds the meteor bundle, installs remaining npm packages, and then sets up the runtime command for any container that is built from this image.
How to Load Balance Your Meteor App
At DCHQ it's pretty easy to load balance your app using an nginx image and a plugin. A plugin allows you to issue a command in your container— in this case, to refactor the nginx load balance config to add/remove nodes as needed.
Essentially you’ll define the Load Balancer instance and also run a plugin that keeps the nginx config up-to-date with recent nodes jumping in or out.
Here’s the example Meteor app definition:
If you decide to use Docker for MongoDB, there’s a great blog post that shows you how to setup a Mongo replica set with MEAN.JS. An official blog post from DCHQ will be available very soon -- covering Mongo Replica Set deployment with service discovery for rebalancing the replica set post scale in/out.
If, like most developers, you’re new to Docker, you could also perhaps focus on scaling your Meteor app node processes and use something like compose.io in the meantime. Using Docker on something that has persistent storage typically requires a bit more planning.
Put it All Together
Once you have your defined app up and running, you’ll easily be able to monitor your app in the DCHQ dashboard.
DCHQ takes care of the hard part about using Docker and containers. Learning how Docker itself works and the idea of containers is really the easy part. Now, you need to orchestrate all these containers across a network. That’s really where DCHQ shines — it handles much of the hard work for you. DCHQ enables you to scale and add nodes to your app as needed without having to worry about complex networking behind the scenes. Additionally, DCHQ can run inside your local network. That allows you to run on dedicated hardware in your own datacenter.
Published at DZone with permission of Amjad Afanah , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.