The state of Meteor deployment is very unfriendly. Is it wrong of me to think that?

Deployment for Meteor is a Black Art. The transmogrification to a node app is FAR from perfect or even sane today.

It’s not “Soup” yet is an understaement.

I wanted to use Passenger from Phusion and I still plan to do so, but only if they give me a startup company discount and still … most of my issues have nothing to do with Passenger …

Running an application under Meteor is NOT like running it under node directly … it just isn’t … That’s why I think Galaxy hosting will actually be quite popular.

If you look at Galaxy hosting from Meteor and the price point ( $495/mo paid ANNUALLY) it seems that they are out of touch with what other people are charging for hosting.

What the hell are they smoking ?

But … when you meet the difficulties head-on, as I have done, and I have the bruises to prove it, you begin to see that they are not so crazy.

I’m contemplating starting a company with real money … and peoples lives and families … on the line and I’ve read about horror story after horror story of reasonably intelligent engineers having the rug pulled out from under them on relatively innocuous updates … x.x.2 or x.1 updates … Then BLAM !!!

Meteor deployment in general, sucks … at this time in it’s development.

5 Likes

is this a technical gripe or a financial gripe?

Because technically, I’ve never have a problem deploying - both deploying my own scripts to deploy from meteor build and using @arunoda’s mup

5 Likes

Financial ? 6K a year for hosting is ridiculous, but I predict that Galaxy will be very successful and that tells you something.

Technical … I’ve recently had a frightening experience with Phusion Passenger … and have determined that it was never Passenger. It was the fact that a Meteor app is far removed from the node app that it can be converted into … and that conversion sucks today.

I liken the world of JavaScript/Node/Meteor to Java/JVM … and the two worlds are far, far apart when it comes to maturity.

That’s my point. Do you agree ?

I thought it was quite good actually. You can signup for a Modulus account in 5 mins and then just modulus deploy and you’re up an running with a load balancer that supports sticky sessions, elastic horizontal scaling, rolling upgrades, and few more bits.

Heroku is almost there but they’re very focused on the Ruby stack and it’s not quite as polished.

If you need more control over your boxes and have time for dev-ops, then Digital-Ocean and MUP provide a very easy way to deploy yourself. If MUP is too restrictive de-meteorizer helps you roll your own deploy scripts.


If you look at Galaxy hosting from Meteor and the price point ( $495/mo paid ANNUALLY) it seems that they are out of touch with what other people are charging for hosting.

What the hell are they smoking ?

To be honest it’s much lower than Heroku’s direct alternative. MDG will eventually release a Heroku basic type of tier sometime next year.


> I wanted to use Passenger from Phusion and I still plan to do so,

From what i’ve heard it’s not quite as nice and has some issues… checkout the latest crater podcast where they discuss hosting (I could never get it to work 2 years ago).

2 Likes

I’m contemplating starting a company with real money … and peoples lives and families … on the line and I’ve read about horror story after horror story of reasonably intelligent engineers having the rug pulled out from under them on relatively innocuous updates … x.x.2 or x.1 updates … Then BLAM !!!

I think this has more to do with a large part of the Meteor community not having tests setup and not testing in a staging environment before deploying to production.

So many people are obsessed with doing the least amount of work in Meteor and I think it trickles down to the packages that get developed and even down to deployment practices.

The Meteor community def. isn’t as strong in testing as the Ruby/Rails community is now (IMHO).

11 Likes

Meteor will be rolling out smaller (individual) plans for Galaxy. Until then go with Modulus if you need something resembling turnkey deployment at a reasonable price tag.

2 Likes

You haven’t told us what quirks you’ve had with Meteor and Passenger, so that would be helpful to know if you’re looking for help.

Aside from that, I don’t understand what’s wrong. There are so many simple ways to deploy a Meteor application, and Passenger is a third-party manager which MDG cannot help you with. Here’s a “one-liner” you can run on your server to deploy Meteor if you use Git:

git clone git@github.com:user/repo.git app && \
cd $_ && \
meteor build /usr/share/nginx/html/ && \
rm -rf ../app && \
cd /usr/share/nginx/html && \
tar -xzf app.tar.gz && \
(cd bundle/programs/server && npm install) && \
mv bundle appName && \
rm app.tar.gz && \
node appName/main.js

You could replace node appName/main.js with PM2 using pm2 start appName/main.js which starts the application in the background and enables multithreading for it.

Now if you are going to be building larger applications, you will need a more sophisticated deployment method. I suggest going with CI (Continious Integration). That’s a whole other story but I’ve setup a fully working CI deployment method for Meteor that easily scales to other machines with a single addition to the CI .yml file - if you’re interested I could write a post about it.

In the end, you definitely don’t need to use Passenger to handle your application if you just know how to configure your Nginx server block (virtual host). MUP and Phusion Passenger is essentially just tools to help Developers deploy, while large production deployments should either be handled by a System Administrator or a DevOps engineer.

My setup is kind of too advanced to be put into this post, but I essentially have a few servers all running CoreOS and all applications are contained within Docker. I have a private Git remote in a Docker container running Gogs (Go Git Service) and a CI platform in a Docker container running Drone CI. Drone runs all stages in Docker so this works hand-in-hand with CoreOS. I also run a private Docker Registry so I can easily build and publish my applications ready to be ran.

To trigger my deploy I simply push a new tag to my Git remote repository with something like git tag -a v1.0.0 -m "version 1.0.0" && git push origin v1.0.0. Drone will then start testing my application in a Docker container, followed by building the application using meteor build, followed by publishing the built Docker image to my private Docker Registry. Lastly it deploys it with docker pull and starts/restarts the container depending on if it’s already running or not. This allows for zero-downtime deployment and hot-code push to work flawlessly.

This is already too much for this post but if you really want a detailed rundown on how I’ve got a really scalable, performant setup like this just tell me and I’ll create a post for it.

12 Likes

hello Sven,

please do write the post about your setup :smile:

cheers,

zoltán

Hi @svenskunganka

We have used mup successfully also, but I would like to read a more detailed post about your deployment process.

+1

Cheers
Brad

1 Like

For sure check out MupX also instead of Mup since it contains lots of great improvements.

1 Like

yes @svenskunganka deep blog pls

I’ve been running mission-critical production apps on Meteor since version 0.6. ‘Real’ lives are supported. (We have eight employees now,) I knew going in that it was all going to be changing radically. We faced lots of problems along the way. If I could go back and start over I’d choose Meteor again.

What’s so hard about deployment? We use Galaxy now, but there are lower cost solution like Heroku and Modulus. Hardly took me 5 minutes to deploy to Modulus. Heroku took a little longer, but not much longer.

2 Likes

Hm … our experiences are different … no pain at all for now. We are using different types of VPS or Hardware server as production servers. All are running Ubuntu Core / Server 14.04 LTS and the node from meteor dev_bundle.

We just install iptables (always the same script), nginx as front-end proxy and mongo from OS or on ARM boards also from meteor dev_bundle.

We have installed meteor on the live servers as well and doing all through a hook-script on git.

Our deployment is running by pushing the changes to the “live” branch. The hook makes the pull and runs the build on our live server. With that we are sure, that we got the consistence environment on that machine (libc, +++).

We just have defined an “update-bash” script in addition, that gets started by the hook after build process to make updates or whatever outside from the meteor app.

I want that blog post :smile: !

Woah there seems to be a lot of attraction for CI with Meteor here. That’s awesome! I’ll create a new thread outside this thread with my setup and notify you guys when it’s done. It’s gonna be really long though as I want you to understand every bit of the workflow in detail, as that’s crucial if you ever want to customize it - so brace for that! :grin:

4 Likes

a frightening experience with Phusion Passenger

This is your second mention of a passenger problem, yet you don’t provide any clue to what it is. Perhaps if you elaborated on that?

I’ve been using passenger for a long time now on multiple servers with varying sizes and I love its simplicity, the density it provides and its scaling abilities. Never ever had a problem that was actually a passenger problem. They are also very responsive to their github issues and the documentation is also great.

And you also mention you seek a startup discount from passenger. Man, it is free. If you are eyeing the enterprise version, it is $29, again, basically free.

Here it is, I’m super tired and really have to get some sleep. I missed some parts and will fill in tomorrow, but it should keep you occupied for a while: Continious Integration with Meteor

1 Like

Wow. That one liner looks cool.

I worked on the Passenger problem in other threads. The problem wasn’t with passenger ultimately. It was a Meteor app ( very simple ) that that runs great under “meteor” but doesn’t run at all after “build” or “demeteorizer” … because of incompatibilities and version control.

It wasn’t Passenger. It was the state of my meteor education.

I’m not a dev-ops person … I understood individual elements of what you said, but not the totality. If something went wrong with your system and I was the only one left to fix it … I wouldn’t call that a “production” system with 'production" level safe guards.