Guide - Setting up Continuous Integration for Meteor into ec2 using AWS CodeStar


#1

Hey all. I’ve spend some time to write about a new AWS Service called CodeStar. It allows us to set up continuous integration on AWS without having to manage a Jenkins server or external CI service. It uses AWS Developer tools under the hood.

I thought it would be a nice time to write about deployment and automating it for Meteor since its probably one of the least covered parts in the meteor guide.

Any feedback is appreciated. I did not yet go over it more then 100 times so there might be some flaws or silly mistakes.

https://cloudspider.io/meteor-ci-aws-codestar-setup-for-meteor/


#2

Thanks for the guide! I am definitely interested in implementing this into my current project.


#3

Nice. Let me know if it helped you :slight_smile:


#4

Very interesting read. Looking forward to the second chapter!


#5

This is looking really good! I’m definitely looking forward to reading more :slight_smile:


#6

Getting 404… must read it!
sounds like exactly what i need!


#7

@amitrahav:

The series is the first of many articles to come on my blog. However, the blog is also new. I’m setting up things, changing and tweaking the theme etc. But given the circumstance here is the complete serie for now:

There are going to be follow ups about setting up SSL and HTTPS using loadbalancers, creating test steps etc etc. Anyway, this is the basic flow for now and it will get you far enough to save huge amounts of time :slight_smile:

Feel free to occasionally return to my blog’s index to keep an eye out on follow ups and other articles. There’s no social media plugins yet so sharing is appreciated :slight_smile:


#8

hey thanx!
one issue i found is the env vars on EB can’t handle METEOR_SETTING. here is what I found about it - https://stackoverflow.com/questions/34761577/how-to-config-meteor-on-aws-ebs-using-meteor-settings-environment-variable

trying to figure it out…


#9

Thanks for mentioning. Maybe I should make a more explicit statement about it. The reason why METEOR_SETTINGS are an environment variable is to provide a convenient way to put app specific settings there without having to change the codebase. (at least that’s how I see it). However the METEOR_SETTINGS are json format, which I don’t find a ‘simple string’ is often escaped like with EBS. How I work around this is to put the a file on a file storage like S3, pull it to the server and use a command like below to start meteor with it:

echo Copying env file from S3
aws s3 cp s3://<bucket-name>/production.env /var/app/current

source production.env && node main.js

I must admit that this would be easier with jenkins or CircleCi, where you simply put the env vars in export statements on your build script.


#10

does your production.env file is a bash script with export env vars?


#11

Yes. Its just one of the ways to do it of course.


#12

another question -
how did you handled nginx configuration for web sockets?

i used .ebextensions with proxy.yml but the websokets returns 400.


#13

There’s a good topic on using nginx with Meteor on Stackoverflow. Just to be sure… AWS loadbalancers don’t play nicely with websockets. Using nginx directly is indeed a good alternative (and I think its EB’s default setting for node apps).

(sorry btw, I wasn’t ignoring you. Its just a bit busy here atm)