Tyler can you post your settings.json and a sanitized version of your mup.json?
I’ve been running meteor 1.3 on AWS in production, using let’s encrypt certs without issue.
A colleague of mine has also built a Jenkins / ansible / kubernetes toolchain for more complex deployments.
Also - What version of node are you using for mupx?
Thanks for your help. Here is the sanitized mup.json
{
// Server authentication info
"servers": [
{
“host”: “host”,
“username”: “ubuntu”,
//“password”: “password”,
// or pem file (ssh based authentication)
// WARNING: Keys protected by a passphrase are not supported
"pem": “~/.ssh/aws.pem”,
// Also, for non-standard ssh port use this
//“sshOptions”: { “port” : 49154 },
// server specific environment variables
"env": {}
}
],
“ssl”: {
“certificate”: “~/MeteorProjects/certs/sslcert.crt”, // this is a bundle of certificates
"key": “~/MeteorProjects/certs/server.key”, // this is the private key of the certificate
"port": 443 // 443 is the default value and it’s the standard HTTPS port
},
// Install MongoDB on the server. Does not destroy the local MongoDB on future setups
"setupMongo": true,
// Application name (no spaces).
“appName”: “estimator”,
// Location of app (local directory). This can reference ‘~’ as the users home directory.
// i.e., “app”: “~/Meteor/my-app”,
// This is the same as the line below.
“app”: “~/MeteorProjects/estimator”,
// Configure environment
// ROOT_URL must be set to your correct domain (https or http)
“env”: {
“PORT”: 80,
“ROOT_URL”: “https://host”
},
// Meteor Up checks if the app comes online just after the deployment.
// Before mup checks that, it will wait for the number of seconds configured below.
“deployCheckWaitTime”: 60,
// show a progress bar while uploading.
// Make it false when you deploy using a CI box.
“enableUploadProgressBar”: true
}
I finally got everything working including PhantomJS in a repeatable fashion. The scariest part is that the recent Meteor core update fixed it. I have no idea why. Once the new version came out and I updated to it, everything started working.
Not sure what JSON parser mup uses but standard JSON syntax doesn’t support comments. It’s probably just a syntax error with the config file because of all those comments. Make sense given the SyntaxError you posted above. You can use a JSON linter like http://jsonlint.com/ to check if the file is valid.
@whitesidest - so are you all set now with deployment to AWS?
Did you manage to get SSL working?
2 Likes
We run Meteor on AWS EC2 using mupx, with machines built and deployed to via Ansible.
We don’t use https and I don’t understand how phantomjs complicates things for you.
I have 2 instances (mupx processes) running on each of two t2.medium boxes.
nginx load balances the 4 meteor apps using ip_hash
Let me know if you need any info.
Yes. Somehow the recent Meteor update fixed it all. Mupx works flawlessly now with no config changes, SSL also works. I also got PhantomJS working, though that one did take some manual tinkering.
2 Likes
Why isn’t this simply as simple as meteor --production but actually production mode, not insecure fake production mode? Why do we need complicated steps to run in production mode? Why can’t the deployment/production experience be as simple as the dev experience?
MDG, what’s the reason it is so difficult to run in prod mode?
What are you struggling with? Deployment is about as simple as deploying any node application and even easier if you use galaxy.
I’m saying it should just be easy to do on any machine, f.e. I might want to simply publish on my local machine with static IP just because, and it would be great if it were just simple meteor --production. That’d give freedom being so easy.
If I want to do it myself, I gotta
meteor build /path/to/build --architecture os.linux.x86_64
then extract the tar.gz. and run the node app? I gotta think about architecture? etc?
That’s so convoluted.
meteor --production can just work on any architecture. MDG could easily do that, rather than provide a flag for which they say not to use. That makes little sense.
On top of that, the fake “–production” mode doesn’t even work. I get ReferenceError: ue is not defined, etc, for minified variable names.
This just doesn’t make sense how deploying is so involved, when dev mode isn’t, and the fake prod mode doesn’t work. The picture isn’t right here.
In my Webpack-based apps, etc, production mode is just as easy to run (because why make it more difficult?).
Okay, I untarred the tarball. Then node bundle/main.js and nothing works.
❯ node bundle/main.js ✹ ✭
module.js:487
throw err;
^
Error: Cannot find module 'fibers'
at Function.Module._resolveFilename (module.js:485:15)
at Function.Module._load (module.js:437:25)
at Module.require (module.js:513:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/Users/jpea/src/trusktr+trusktr.io/build/bundle/programs/server/boot.js:1:75)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
Alright, now what?
It really doesn’t have to be this hard. I don’t get why it is this hard. Not that I’m not capable, it’s just a nuisance.
The README says to do
$ (cd programs/server && npm install)
$ export MONGO_URL='mongodb://user:password@host:port/databasename'
$ export ROOT_URL='http://example.com'
$ export MAIL_URL='smtp://user:password@mailhost:port/'
$ node main.js
Dafuq?
Sorry, I’m just annoyed how difficult this is. It should be easy, and incrementably optimizable. F.e. it should just be meteor --production (if it worked in the first place) then I could customize those env vars, later, when the time is right and it makes sense).
I’ve not had any issues deploying to any platform. I think the architecture flag is in case you’re using a Windows box (Meteor has a different build for Windows afaik, I could be wrong though as it might be standardised now).
Have you looked into using meteor-pm2? I’ve found that the easiest way to deploy. I use the ‘deploy yourself’ method about 2/3 of the way down that page. Once you generate your bundle with pm2-meteor, all you have to do is run npm install in the programs/server directory and run your app (with pm2 is easiest, especially if you want it to automatically attempt to restart when it crashes etc).
Feel free to PM me if you want some help. Though I’m now in a meeting for 3 hours so might not be responsive for a little bit!
@korus90 Thanks, I appreciate the suggestion and your effort to help! It says
$ pm2-meteor generateBundlethen transfer it to your machine, unzip it and run
$ pm2 start pm2-env.json
That’s still quite a lot. It could rather be
git clone https://github.com/username/mateor-app
cd meteor-app
meteor --production
and done. That’s literally how simple it could be!
I don’t doubt that at all but once you have a way of deploying it’s not all that hard 
I’ve deployed a few meteor apps now and I can spin one up in a few mins now I have a way of doing it.
1 Like
Yeah, I’m going to script it, to automate it onto my server, then it’ll be done. The rest is all just wishful thinking. It’s open source, so I suppose if I had time to make meteor --production actually be production mode, I would.
The nice thing about meteor --production is that MongoDB just works, I don’t have to go learn how to set it up and how to run it. In Arch Linux, f.e., it’s easy to install a global Mongo, but that’s not ideal. My server might have multiple apps that need Mongo (it’s just a personal server). I don’t want multiple apps accessing a single global Mongo. This means I gotta figure out how to configure and run individual instances. That’s a whole lot of work that’s already encapsulated inside the meteor command, so not being able to take advantage of that is not a win.
Plus, I’m expecting minification might break just like it currently does with meteor --production; minified var names not being defined for some reason, so basically, I’m just gonna run meteor for now, because I don’t have the time to debug Meteor’s minification and to set all that other manual stuff up.
On top of that, Galaxy doesn’t run Mongo for you either. It still requires a MONGO_URL. I could just go pay for a hosted MONGO_URL and be done with it, but I don’t want to pay.
So for now, I’ll just use meteor it is because it’s just easy. The app will take a little while longer to load, but I can inject a nice CSS loading spinner or similar.
In all honestly, making the deploy process difficult just seems like a business move, so devops and hosted services can take advantage of it. Meteor “recommends” galaxy, along with other products it “recommends” for Mongo, etc. It makes business sense. It doesn’t make as much developer sense, because why should I have to re-invent what the meteor command already does? Because, business! (I’m only guessing. If I’m wrong, then MDG is simply lucking out).