By Changping Chen

Galaxy delivers an effortless DevOps experience for the deployment and monitoring of production Meteor apps. Behind the scenes, our Galaxy production engineering team constantly works to improve the application build and deployment experience for thousands of customers around the world. We are excited to share the results from the latest major upgrade we deployed last week during our scheduled maintenance for the US and EU regions.

Galaxy now builds your Meteor app in to a runnable Docker image and stores that image in our secure internal registry. Galaxy will run once and cache the application build steps like npm install . This architecture enhancement significantly improves container start time and reliability during application updates and while scaling your application up.

Also, Galaxy now displays the entire build log in your application log web interface. This provides new insights our customers have been requesting to debug build errors that affect application deploys. You can filter to view only build logs by clicking the “Service” tab in the application logs page.

Design and Implementation

To enable these improvements, we created a new builder service in our Galaxy backend systems. In simple terms, it’s a neat wrapper for docker build and docker push commands.

This new builder service, just like the rest of the Galaxy architecture, is designed with reliability and scalability in mind. The builder service polls and dequeues build tasks using the findAndModify primitive in MongoDB, which we use to implement race-free queue operations. This allows our builder service to consist of independent workers that can horizontally scale as needed.

When you deploy your app to Galaxy through meteor deploy , Galaxy utilizes temporary 1GB/1ECU containers running on dedicated builder machines to build the application images. These dedicated builder machines are configured with physically-attached SSD for storage (“instance store” in AWS terminology), providing enough sustained IOPS for the disk-intensive task of building your app.

Galaxy further protects against potential application build failures affecting the system by imposing a timeout for all builds. To deal with any transient error that may occur during a build, Galaxy will retry up to three times with a delay between builds.

Once the build succeeds, the output image is pushed to the Galaxy Docker registry. We built this internal registry to run on multiple instances, proxied by an internal Elastic Load Balancer. The Galaxy container scheduler then proceeds to deploy new containers using the freshly built application image. When a container starts, it immediately starts executing your app without any need to do build-time steps. This makes scaling up your app and recovering from crashed containers much faster and more reliable.

Looking ahead

The use of Docker images elegantly abstracts away the specifics of running Meteor applications. Our in-house container scheduler can effectively execute its job by simply knowing an app’s deployment preference and the location of its runnable image.

We’re also excited to explore the possibility of allowing our users to customize base images. Right now, if a customer needs extra OS-level packages or configuration, we have to decide whether the extra package makes sense for all of our users. Soon we will allow you to simplify your container environments by specifying system packages and language runtime specifics. Stay tuned for more updates!

Got a Meteor app? Sign up for Galaxy and get the best DevOps experience available for Meteor developers today!

About the Author

Changping Chen is a summer intern at Meteor Development Group. He has spent the past few months designing and building a new Galaxy image builder architecture, as well improving Galaxy’s security and performance. This fall, Changping will be studying Computer Science as senior at MIT.