Migrating Meteor Apps from Modulus to Galaxy with Continuous Deployment from Codeship
Galaxy is the new hosting offering from Meteor Development Group. The business editions have been publicly available for a little while, but they are too expensive for small/hobby projects. The Galaxy Developer Edition is oriented to smaller projects, but it is still in limited, invite-only access. I was lucky enough to get my invite the other day. You can request your own invitation if you would like to try it out for yourself.
I’ve been running We Work Meteor on Modulus for the past 2 years. Generally, I’ve been happy with Modulus during that time, but there have been some issues in the past 2 months. Modulus support has been very responsive and helpful, but I’ve been itching to try out Galaxy since I first heard about it oh so long ago.
I have We Work Meteor running on Modulus and Compose. The code is hosted on Github and I use Codeship for automatic builds and deployment.
My Modulus/Compose/Codeship setup is based on this guide.
Deployment to Modulus from Codeship is rather easy, however Galaxy is so new that it is not specifically supported. However, Codeship is very flexible so we’ll just have to use some custom commands to deploy to Galaxy.
Restructuring Environment Variables
In Modulus we have a control panel for environment variable, but Galaxy wants your environment variables delivered as part of the settings file specified at deployment time.
Create a new json file with the contents of the ‘METEOR_SETTINGS’ environment variable, then copy over all the other environment variables into the “galaxy.meteor.com”:“env” key.
I’ve saved this file as ‘prod_settings.json’ in my repo and added an entry to ‘.gitignore’ to make sure this file never makes it to Github. Later, we’ll load these settings into CodeShip for automatic deployments.
Manually Deploy to Galaxy
I want to deploy manually from my laptop to make sure Galaxy works properly before I alter DNS and Codeship configurations.
$ DEPLOY_HOSTNAME=galaxy.meteor.com meteor deploy www.weworkmeteor.com --settings prod_settings.jsonDeploying to www.weworkmeteor.com.Now serving at http://www.weworkmeteor.com
The app now shows up in Galaxy dashboard.
Since We Work Meteor is an active site, I’ll edit my local /etc/hosts file to test to check things out before I fully make the switchover.
Grab an IP address for the galaxy load balancer.
$ dig +short galaxy-ingress.meteor.com52.20.102.11654.86.202.17052.20.156.16452.2.179.142
Note: Be sure to run this command for yourself and not just copy one of the addresses listed here as the IP addresses can change.
I then edit my ‘/etc/hosts’ file to point the domain to one of these IP addresses by adding this line and saving.
52.20.102.116 www.weworkmeteor.comNext I check ‘www.weworkmeteor.com’ in a browser to verify that it works just the same as Modulus.
Note: I did get some odd behavior here. If I used the same browser session that had visited the Modulus hosted site, the page would reload automatically after the initial load, sometimes just 1 reload and sometimes a reload loop. Clean browser sessions were fine. As was the app after changing DNS settings.
The site appeared to function just as it did on Modulus, possibly a little faster. Let’s go ahead and make the transition!
Changing DNS Records
I use Namecheap as my registrar. My domain was already set up to forward the naked domain “weworkmeteor.com” to the www subdomain “www.weworkmeteor.com” as recommended by the Galaxy documentation.
I changed my DNS record for “www” from an A record pointing to the Modulus AWS load balancer
to a CNAME record pointing to the Galaxy load balancer
After waiting a little bit, the transition seems to have gone just fine with clients being served by Galaxy. Checking the dashboard the next morning, everything seems to still be going well.
Continuous Deployment to Galaxy from CodeShip
Galaxy deployment from Codeship isn’t quite as nice as deploying to Modulus, but it is quite doable with some custom commands.
Start by deleting your Modulus deployment, under “Project Settings” and “Deployment”.
Click ‘Edit’ to edit the deployment pipeline
Click ‘Delete’ to remove the Modulus pipeline.
We now need to create a login session token file to allow Codeship to deploy to Galaxy without having to supply your username and password.
Create a Meteor session token in a json file by running this command locally
METEOR_SESSION_FILE=deployment_token.json meteor loginThis will create session token with Meteor’s authentication system and store it in a json file `deployment_token.json`. If needed, the token can be revoked from your Meteor user account settings. The token stored in the file looks like
{ “sessions”: { “www.meteor.com": { “session”: “SESSION_STRING”, “type”: “meteor-account”, “username”: “YOUR_USERNAME”, “userId”: “USER_ID”, “token”: "TOKEN_STRING“, “tokenId”: "TOKEN_ID” } }}
The contents of this file and some other settings need to go into the Codeship environment variables for the deployment script to utilize them, so we’ll set those next.
Click on ‘Environment’ on the left navigation to add your environment variables.
Enter the contents of the ‘deployment_token.json’ file, the domain of the app, and the contents of the ‘prod_settings.json’ file.
Now that the environment variables are set, we can create the deployment commands.
Click ‘Custom Script’ to create a new pipeline for Galaxy.
Enter the following commands that will deploy your app to Galaxy.
The first two commands write the two json strings in environment variables to files. The last command uses the login token to deploy the app to Galaxy with the settings.
To test the build, change a file in your app and push to Github. You should see it kick off right away.
The build/deployment actually seems a little faster than when deploying to Modulus.
At this point, the app is fully migrated over to Galaxy and has the automated build/deployments directly from Github.
What’s Next?
I’ll be evaluating Galaxy over the next several weeks. I plan to leave my configuration in place on Modulus for the time being. Just in case something goes wrong, I’ve got the ability to switch the DNS back and start the app which will have me up and running very quickly on Modulus if needed.
Update — 3 months on Galaxy
Galaxy has been just as good or better than my experience with Modulus. I had reason to file a few support tickets and the Galaxy customer service was exceptional. I’ve got nothing but good things to say about running my app on Galaxy.
Features of Galaxy Developer Edition in Comparison to Modulus
- Galaxy does not currently have autoscaling. This means that you can not set rules to allow your app to use more resources during traffic spikes. It’s very easy, one click, to manually scale up or down, but it is a manual process.
- Galaxy doesn’t currently have alerts. Modulus sends alerts for crashes, changes, etc. I’ll have to rely on Kadira and Pingdom to monitor the app.
- Galaxy doesn’t currently offer a free MongoDB like Modulus does. I always use Compose, so this doesn’t effect me, but it may be important to others.
- Galaxy currently only offers the last 5 minutes of server metrics in the dashboard (cpu, memory, clients), while Modulus will show you the last 24 hours. Kadira can help here, especially with a paid plan.
I was able to have a quick chat with the Galaxy Product Manager from MDG and he assured me that all my concerns are already on their radar.
- Autoscaling is on the roadmap. Not sure if it will be automatic or defined rule based, but it is coming.
- Alerts are on the roadmap.
- Integrated MongoDB is being looked into. Could even be a partner vendor based setup rather than MDG offering their own MongoDB.
- Dashboard server metrics will likely be increased but advanced analysis will only be available for team/business editions.
The developer edition’s shortcomings are the markings of a new, early access product. The good folks at Meteor will surely improve all editions of Galaxy over time to fully meet the needs of the community.
