How does this compare to deploying the app on Opsworks?
I haven’t gotten SSL working yet but it seems pretty promising. Updating the app takes less time with ECS compared to with OPSWorks and you can allocate as much memory and CPU as you want per container which is also really nice. The Cloud formation configuration needed by ECS will make sure your app restarts upon crashing and with autoscaling, micro services and cluster I think I see a pretty bright future for scaling meteor apps specifically.
I have not deployed production quality apps to it yet so it still needs to be tested.
@khamoud - A few things
will this work with private images hosted on docker hub?
I’m trying to get this up and running right now, and i noticed we lose websockets, thoughts on that?
It will work with privately hosted images on docker hub. There is more documentation on that here.
How did you lose websockets? I do know that cluster doesn’t work with ECS right now for some reason. @jkatzen is dealing with that now. There will probably be an update to this tutorial or a completely new tutorial with everything from the old Opsworks tutorial but with ECS instead.
@khamoud - Awesome! And yeah, when I inspect element, it says that it couldn’t connect to web sockets in the console. Also for some reason I can’t get port 80 to open on the instances even though the security group states so.
Do you have an estimated date of the release of the tutorial? I’m debating on whether I should fix the opsworks deployment or go with ECS.
@arjunrajjain I’m going to try to write something up this weekend and post latest Monday. I think I have cluster working with SSL and websockets. Honestly, our own OpsWorks deployment has seen better days and even deploying for ourselves is not 100%. ECS has definitely been more of a pleasure to use so far and the deployments are MUCH faster.
Expect something soon. In the meantime, Kris’s tutorial will help you get setup and running - the update/new post will probably just take the old OpsWorks tutorial and have it in ECS flavor.
@khamoud nice work on the tutorial 
Just a heads up:
The Dockerfile you’ve provided will result in significantly larger images than required (hundreds of MB larger).
Also, your tutorial doesn’t make it clear that app bundling should happen on the correct machine architecture to support npm modules with native extensions.
Using either meteord or meteor-tupperware (a project of mine) is a much better idea. Both solutions are optimised and perform bundling for you on the correct architecture.
Try the following as an alternative:
- Follow the two steps in the meteor-tupperware Quickstart. Thereafter it’s just a
docker buildto update. - Push your image.
- Follow the Step 4 in @khamoud’s tutorial to get the image running on ECS.
Chris
Thanks for the feedback @chriswessels!
The goal of this tutorial was not to make a production ready deployment. It was simply to show that there is no magic within the deployment of meteor. I feel like a lot of people are confused as to how to deploy meteor themselves without the help of third party packages/dockerfiles/deployment scripts. All I really wanted to do was take away some of the mystery behind things like meteord and meteor-tupperware
meteord is a great Dockerifle and it’s what we use in production. I have not used/tried meteor-tupperware although it does look pretty cool!
@khamoud @chriswessels I’m looking to ‘containerize’ my ‘production-ready’ Meteor application with an AWS EC2 Ubuntu instance as the target sever.
(3) questions:
- Do you guys recommend following these steps to get started?
-
I have a special case, where I install executable I use to generate PDFs on the EC2 instance, the install is pdftk. Also, while generating the PDF, I use a directory outside of my Meteor application and store PDF templates there. I also write temporary files to the file system outside of the Meteor application. Is this possible with a Docker container? Could I build a container with a directory structure store PDF templates in a folder structure outside of my Meteor application? It would be ideal to keep this directory and file structure in place and just update the Meteor application within the Docker container; that way I don’t have to build this each time I do a new deployment. Or would it be better to have these folders and files outside of the docker container (keeping in mind this is a dependency)?
-
What about MongoDB, is that installed within the container or should that be ouside on the server or in another container?
I’ll answer those to the best of my ability.
-
You would be better off following @chriswessels docker build for a production app because it does some very nice things that you don’t have to think about.
-
You can mount volumes onto your docker container. That way you can have access to the file system outside of the container. There is also probably a pdftk docker image that you could use to install it onto your instance.
-
If it is a production quality deployment it should be on separate servers.
1 Like
Thanks @khamoud. I’ll add my piece too @aadams.
Following the steps outlined above will give you a deployment. In terms of its production-readiness, there are a few additional points to consider:
SSL Termination
a) Your app should be running behind SSL.
b) You shouldn’t be terminating SSL with Meteor. This is because the encryption performance of Node.js is pretty bad. Ideally you should be terminating SSL at a load balancer like NginX or HAProxy (or even AWS ELB with websockets) and then proxy the plain HTTP traffic behind a firewall to your Meteor.js app instance(s).
MongoDB Deployment
As @khamoud mentioned, your MongoDB deployment should be external to your Meteor.js apps. You could run it on a separate EC2 instance (in container or on the host), or you could choose to use a third-party solution like Compose.
Additional runtime dependencies (pdftk)
Additional runtime dependencies would need to be bundled into your Docker image. You’ll need to edit your app Dockerfile to ensure these are installed. Any directory structure you can place into your app folder and then copy in.
It might look something like this:
FROM chriswessels/meteor-tupperware
RUN apt-get install -y pdftk
COPY ./dir_structure /target_in_container
If you don’t need any of the generated files persisted, then you don’t need to mount a volume into the container.
2 Likes
We just got cluster, papertrail, ssl, and websockets working. Tutorial should be coming soon.
3 Likes
brilliant! congrats man!
1 Like
Thank you for the tutorials! They have been very helpful. I also would like to know if you have made any progress on your ‘production-ready’ tutorials? Specifically, I am interested in SSL enablement.
Also, what do you think of MUP? Have you tried that instead of a more ‘manual’ process and, if so, how does it compare with what you have been experimenting with (pros/cons)?
Thanks again!
Peter
We’ll have it up soon. We’ll let you know when it’s done.
Thanks! I’m glad you’ve liked them. SSL is tricky at first but after you get your crt and key files it’s actually not that bad. MUP is great and super useful for getting a production ready deployment up and running.
We like our current deployment setup because it has allowed for us to customize a lot of different things such as CPU and Memory allocation for our docker images based on how many resources each image needs (I’m sure we’ll see support for this in Mupx when it becomes stable). For me personally, I really enjoy knowing how everything is working under the hood so I tend to lean more towards manual deployments.
Pros and cons of manual deployments vs cli’s
Manual deployment:
pros:
customization - you have control over all of the environment variables, resources, instances, etc.
cons:
difficult - since meteor is still really new people are still learning how to get production ready deployments out so using a custom deployment is pretty hard
stability - if you looked at our AWS, OpsWorks, Docker tutorial you might have noticed that it doesn’t work anymore. Things like this can happen if you are running chef recipes or deploy scripts that are no longer compatible with meteor for whatever reason. My old EBS tutorial also doesn’t work with the newest release of meteor.
Using deploy scripts (MUP, admiral, demeteorizer)
pros:
consistent - unless a big change has happened in some core api these deploy scripts will almost always work
easy - there is a tutorial and extensive docs for these which allows for quick production ready deployments.
fast - no need to google problems that occur because there is almost always an answer in the docs or in a github issue
customizable - Things like mup are actually very customizable and can work for almost any deployment
cons:
understanding - it’s tough to know what’s actually going on under the hood if you never actually look at the source code. This isn’t always a bad thing. Good software abstracts away things that don’t need to be understood by every developer. Things like mup are great because they abstract a layer of difficulty away.
1 Like