First I tried MUP a few versions ago, then I was convinced to go to MUPX, then I learned that after I was already using MUPX was some experimental build deployment solution and it wasn’t the real direction. What? Experimental, no thank you. So now, I’ve been having the most difficult time to get deployments to work on my app, with my v0.11.3 of mup and 1.3 (and i’ve waited patiently for the beta to become a release)? Then I learned there’s yet another experimental build system called, Meteor Build.
Wow? When does it stop? What is a developer to do? I’m pretty confused, unable to build and beside myself. I’d rather pay MDG for support and expect a more quality product then the confusion I’ve run into. I mean, look at the 492 open issues with little support from the creator of MUP, most of the comments are +1? it’s a little unfortunate the meteor build process is in such a state, and I hope it improves. I know a lot of this is based on the whole npm disaster out there.
Please advise? Honestly this is not a great selling point for the framework. A solid build tool, for all Meteor’s promises about how easy everything is, is quite a pipe dream.
I feel like I have to step up for Mup a bit here. I’ve been using this package from @arunoda for over a year and really couldn’t be happier. Of those 492 issues, how many are troubleshooting and how many are legit issues with PRs?
There is a learning curve, but I can mup deploy, meteor build, and sign my .apk and have a web and Android app running off one server in a few minutes.
MUP has no ties to MDG and there’s galaxy as well, so no real reason to complain about it hurting the framework.
Your issues are with MUP, which can be solved, but if you don’t know how, the actual issue is with your inexperience while still wanting to do the sysops part yourself (don’t take this as an offense, it’s not meant to be).
In other words: you’re choosing to take the hard way by not wanting to use galaxy and are then complaining it should be easier.
I’ve been exclusively using mup and mupx for deployments and even though 1.3 introduced a few tricky problems with binary npm libraries, there are ways to get it to work.
Personally I would advise only to use mupx or the kadirahq mup version. (the kadirahq version allows for custom docker images, which is huge imo, I’m still using mupx with a custom start.sh at the moment)
If you don’t like the state of MUP, besides galaxy you can always do the deployments completely manual, but I doubt you’re going to like that route more. Another option is to hold off on using 1.3 until everything has caught up. It’s not uncommon for a major release to cause some issues in the beginning of course.
OK, it should be easier, and these tools should work better, sure it’s not MDG’s fault, it’s not their product. MUPX uses docker and containers are handled a different way with AWS. The problem is that none of my node modules are being installed on my server with node when i do a deployment. It’s unfortunate. I don’t have time to write a build script or do manual builds, or find out why none of the packages are failing to install on the server. I need something that works out of the box.
Unfortunately, I am officially giving up on Meteor and going with something like koa, I started a new project and was convinced to go down the 1.3 path. But I was planning on just using restivus and making a simple API framework. I really liked the the way you were going - so it’s unfortunate. It was fun do to one project in production already and I was excited.
I’m sure some of you will be happy i won’t be here complaining any more.
That’s why you’d need to create a custom docker image. You base it on meteord, install the binaries needed, publish that image and deploy with it. You only need to do that once and from that point on you just do normal mup deploys. This will only work with the kadirahq mup version.
With mupx you’d need to adjust the start.sh script to use that image instead of the standard meteord, only a single line change after every deploy. Still easy from my point of view.
Either way, use whatever feels best for you. If you feel uncomfortable with meteor right now, it’s a good idea to look around.
i didn’t use either galaxy or mup… galaxy is too easy that i learn nothing… it doesn’t suit with my learning purpose… i skipped mup because i saw the source it install a lot of things that i didn’t understand what are these and why i should use these…
so i deployed manually on aws… it pretty easy…
install nginx on web server; node and npm on app server; mongodb on db server,
nginx config… you can find a lot the config on google,
local build,
upload the bundle to app server,
extract the bundle,
install npm dependencies on app server,
export environment variables on app server,
node main.js
since my purpose is for learning hence this is enough… for production i’d rather go with galaxy… my point is meteor deployment is easy even if you deploy manually…!!
i found similar experienced… it’s because npm-bcrypt that was installed in my local machine (mac) was different with npm-bcrypt that was installed in my app server (rhel)…
I think this all the time with galaxy and meteor. My concern is that the future looks like things will be (a) highly specialized and (b) abstracted away.
As an example of specialization, your dev shop may not higher a DevOps person full-time if they can just pay MDG/Galaxy $500/month to have all the devops support they need. MDG/Galaxy won’t be the only company offering a similar outsource-able service… and no CEO is going to take a 150k employee over a 20k service unless there is some extreme circumstance (e.g. the company you work for is twitter or facebook)… this model will become widespread sooner than later.
As an example of extracting things away, there’s galaxy. Heroku is going this way. Compose is trying to do this for mongo. Everything is going this way… highly abstracted and super easy to use.
I think the future will value people who are good at gluing it all together, rather than people who can build it from scratch. The only people who would say otherwise are the ones concerned for their jobs. They’ll spend hours thinking up all sorts of black swan examples of why this can’t be.
Still, all the useless learning will probably still pay dividends for at least another 2-3 years… is my guess. After that it’ll only be useful if you want to work at the 2% of the tech industry that is building the abstractions, but not helpful if you want to work at the other 98% of the industry who is building on the abstractions.
OK, after being nearly offended after I’ve been offensive, i took another stab at building my app…
thanks to @karina for sharing some advice. I am making an sh script to handle my custom deployments. It’s weird that kadira would have ever chose to build the app on a different architecture – hence the whole docker image system I guess.
I’m happy to share what I’ve done. I’ll probably use some private node module for my own custom dependencies. Maybe MDG could better document a build process aside from Galaxy.
Yeahh crypting in mac is different with crypting in linux so you should build in linux architecture… You can find the detail of this issue in npm-bcrypt repo…
Here’s what I did, I pushed up to my master repo with git, then i pulled down from my master repo in my project folder on my server
cd ~/app_name
meteor build --verbose "/opt/app_name/app"
cd /opt/app_name/app
tar -vxf app_name.tar.gz
cd bundle
npm install layer-api fibers underscore source-map-support semver jws
pwd
source ../../config/env.sh
node main.js
my env.sh was actually the same file that mup created, all mup does is create a env.sh file from the mup.json env block in mup.json
What I’d rather do is just do an npm install, but why aren’t these dependencies like source-map-support, underscore and semver installed from a meteor build.
Still figuring out the best way to handle these dependencies, ideally, i’d like all my npm dependencies to be handled with one npm install.
Yeah, it’s a but confusing. I would think Kadira would want to clear it up sooner rather than later.
There was MUP that appears to continue to work fine. But then there’s MupX which use dot be the experimental version but maybe now is the one you’re supposed to use? But then there’s the new Kadira version which you’d think woul dbe the one to use but is suggested not to.
Realistically, my guess is Galaxy is a non-starter for many due to sensible cost or control concerns.
It has definitely gotten confusing with all the Mup splintering. I don’t think it is MDG’s fault in any way, but the longer the various versions of Mup we now have stay a confusing mess, the worse it gets.
Mup worked pretty well, could take some tinkering to get configured right, documentation was good but not great.
Then MupX started being developed and pretty soon, even though it wasn’t the stable release yet, if you had a problem with Mup, especially if Mup had a problem with a new meteor release, the response to most issues was “use MupX”. Since MupX wasn’t officially stable, the documentation wasn’t great, there wasn’t a lot of warning about just how different it was and how throwing your app into a docker container could cause a lot of problems if it wasn’t built with that in mind.
Now we have two MupX’s. Apparently Kadira is the one in active development, the other isn’t. But kadira refers to the other as the stable version. But most issues that pop up on that version, the response is to use the Kadira version.
For me, that’s been the biggest hassle or source of confusion. Marking one version as stable while the others are being developed, but not supporting any issues and just telling everyone with a problem to use a different version. If “stable” doesn’t work, use “dev”, if “dev” doesn’t work, use “stable”. You can pretty easily end up being run in circles. And with unclear documentation on the differences between them and adjustments that need to be made to the config, you can easily end up having to dig through many issues trying to find an instance with a solution where someone encountered a problem similar to your own.
For our biggest production app, we eventually ended up just doing meteor bundle and deploying to Passenger with a bash script to install the correct bcrypt modules. It’s quick and easy, but with “bundle” deprecated, will probably have to revisit all the deployment options at some point and try to find another quick, easy, solution that actually works.
