Galaxy build just dies for some reason


#1

I have been having problems deploying to galaxy. The build just dies for some reason. With log level set to debug I’m not seeing any indicators as to what the problem may be. The log shows a bunch of imports and translation stuff then… "Application exited with signal killed"
Seems like a memory problem? Any ideas on how i might begin to figure out what’s happening here? She builds just fine locally.


#2

Galaxy forces you to use their proprietary closed source Docker build and that’s possibly a problem for Reaction (although I’ve not confirmed that). We have our own base image because Reaction has specific build steps (like our plugin loader) that need to happen. I’m not 100% positive that’s your problem without signing up and testing it though.

If that is the problem, the only solution that I can think of to allow any base image is refactoring the Reaction build process to allow the use of any Docker base that supports generic Meteor apps. That’s not really in our plans at the moment, but I’d be happy to discuss a community contribution if that’s something you’re interested in working on. Feel free to discuss here in the forum if you’d like more info.

But yeah, you may also be right that it’s a memory issue. I have no idea what the defaults are for a single Galaxy container, but I suspect it’s not a lot. Perhaps try increasing the RAM. I’d definitely recommend 1.5-2gb RAM at the very least.

Also, if your app works when you build/run with our official base image, then I’d say you may want to contact Galaxy support to see if they might be able to help you debug further.


#3

Thanks for the response!

yeah, that’s interesting. I’ve decided to ditch the Galaxy and just build my own… I keep running into problems when i try and use different hosting providers - a bunch of different problems… most likely user error however.

On an unrelated subject, Atlas mongo hosting has a bug involving the dynamically generated domain name which prevents connections when you try to build reaction with it. It may be worth noting in the docs (or somewhere else?) so that someone doesn’t spend the hours I spent yesterday bashing their head into their keyboard wondering why reaction was erroring out… Is this something worth noting on the reaction side? (i suggest because your docs recommend using Atlas) …

cheers!


#4

What exactly was the issue with Atlas? Just curious because building Reaction doesn’t require a database and you mentioned that it “prevents connections when you try to build Reaction with it”. (I assume you mean run Reaction in development with it)

Regardless, if it’s a common enough problem I’d be happy to make sure it gets into the docs so we can save other people any headaches.

Thanks!


#5

The issue with atlas is that it creates domain names based on your shards such that “myproject-shard-00.atlasdomain.com” and apparently there’s a bug when trying to connect with galaxy because of a mismatch between mygalaxydomain.meteorapp.com and your replica set domains on atlas. Apparently they need to be the same domain… It’s not a reaction related issue so it might not “fit” in the docs anyway. I’m also having problems finding the exact thread / issue on github that explains this at the moment… I’ll see if i can’t track it down for ya though.

cheers


#6

Also what i meant by “prevents connections when you try to build reaction with it” i meant when I push to galaxy with my MONGO_URL set to atlas…

Also,

You say, "building reaction doesn’t require a database"
I do realize that reaction uses its own mongo instance but i was under the impression that this wasn’t “the way” for production. Is it ok to use the prebuilt mongo that dist with reaction in production? I’ve been trying to figure out a good workflow on this front and i realize that connecting my development reaction to the production database could present problems because of the different app id’s?.. what is the proper workflow here? Would i create products in my dev env and then export them or am i on the right track just using a single database for both dev and production? Maybe point me to a more appropriate thread? Thanks again mate!


#7

Yeah, I think we’re talking about the same thing, but using different terminology. I meant that the database is not used/required to build a Meteor app. By build, I mean the process of turning your development code into a production build of the app (the process that happens by running meteor build). The MONGO_URL that you provide to Galaxy isn’t being used until after the build is complete and the app container is started.

And no, definitely do not use the development database in production. Not only is that not a production-ready database setup, it would also mean you’re running a development version of the app (which is even worse). While you can use the same external database for dev and production, it’s probably not a great idea unless you aren’t worried about breaking things. It’ll absolutely work fine and it’s a great way to test code changes with the same production data your deployed app uses, but it’s a little dangerous when you’re altering code that can possibly mess up your production data. I think the better/safer workflow is probably going to be to use mongodump and mongorestore to transfer data back and forth between databases as needed and just use your local development database when working locally.