I'm developing a Meteor app on cloud9 (c9.io) which is stuck on Meteor v0.5.9.
I'd like to try my app with 0.6.5.1 as I'm having a few unexplained issues.
Q: Is it possible to do a
meteor deploy myapp.meteor.com
and specify the version of Meteor.
I'm assuming not, as I guess everything's packaged up and deployed together, including Meteor itself?
Specify what version of Meteor to use locally suggest you can specify meteor versions, so may be I should set that just before deployment?
Thanks in advance.
Yes. In fact, it's the same argument as in the other question:
meteor deploy --release <tag of meteor> myapp.meteor.com
The tags are the same as in https://github.com/meteor/meteor/releases but without the release/ prefix.
However, in your case, the current version is 0.6.5.1 so if you just did a meteor update on your machine, that would be the default release for any deploy or bundling. Beware that it will be hard to go back to a previous version because of the various changes it will make.
Related
I have an app I'm writing using Meteor, Angular2 (using the angular-meteor package), Typescript, and MongoDB. I'm trying to put it up on Heroku and running into difficulties. I'm using this meteor buildpack. I'm not sure whether the problems are with Meteor, Heroku, or Angular2, though I suspect it's something Heroku isn't configuring correctly for Angular2. The site is at http://alfred-zahner.herokuapp.com/ and the error I'm getting is:
EXCEPTION: No provider for t! (e -> t)
I've checked the Heroku logs and there is no sign of trouble there. Part of my problem is that I can't see what t and e are, as someone (Heroku?) is uglifying the JavaScript. I'm not really sure how to proceed in debugging this.
One way to solve this problem would be to figure out and fix the error, but I'd be happy if there's a better build pack, or even a better (must be free!) hosting environment that I could be using.
Edit
It's not Heroku's problem. The same thing happens when deploying to Meteor's built in deployment testing (meteor deploy site.meteor.com). If I deploy using meteor deploy --debug site.meteor.com, however, it works, so Angular2 has some problem with the extra processing that happens when Meteor prepares an app for production.
On the angular2-meteor Github I found out that this is an issue with Angular 2 in particular, when using UglifyJS. For now, it seems the only solution is to use meteor deploy --debug. I'm planning to just use that on meteor's built in hosting until Angular 2 plays nicely.
When creating a Meteor app., Mongo is installed by default and runs automatically when I run my app. In the past, with other non-Meteor apps, I have always tried to place my app code files and database on separate servers to ensure that I can scale them independently. It feels as though this default Mongo install is a convenient way simply for Meteor to use a database out-of-the box, just to get you going. Thinking ahead, I want my app to scale, so should I start thinking about using a Mongo instance on separate server and, if so, what process do I go through to detach this default Mongo instance from my Meteor app?
The instance of mongodb that comes with meteor is only for use when developing your app. In a production environment, you should either install your own mongo instance or use a service.
I strongly recommend using compose.io in production. We've had a really good experience with them and the most basic deployment comes with access to the oplog which is critical for scaling your app.
Either way, in production you will provide two URLs to your app via environment variables:
MONGO_URL
MONGO_OPLOG_URL (this is optional but strongly recommended)
If you go with compose, here is the guide for integrating with meteor.
I'm checking out my options on deploying meteor apps.
I already saw the problems of deploying meteor apps built on my mac, to remote Ubuntu server and other versioning issues, i believe more to come.
meteor-up looks like a good solution, but can it be used alongside with demeteorizer
to handle dependency management?
Would that have any advantage over packaging with demeteorizing, and deploying with some othe/custom script?
You don't have to use demeteorizer, if you're using mup. You can configure npm binary dependencies in the config.
Personally I use mup in production, for over 10 different apps, and it even handles multi-node deploys nicely.
I recommend using something like chef to setup your environments, and then mup for meteor/node/mongo/phantom.
For various reasons we have decided to try to sidestep the slug-compilation and build our own slug locally to deploy through the API (as described here: https://devcenter.heroku.com/articles/platform-api-deploying-slugs).
The slug is built mostly like the java/scala buildpack using that buildpack jvm and is then combined with our play framework application dist file. Looking at the app dir of a normal/git-deployed app it looks aboutish the same.
Now, after deploying the slug through the api we get the expected dynos listed in the config page but the app crashes right away without giving any further information. Trying to attach a bash shell through heroku run bash it just times out.
Is there any way to get more information about why the app crashed out of heroku?
Ok, after some help from heroku support we figured out the following:
The slug tar files must be created so that the paths start with './' regular relative paths doesn't cut it. When we had that figured out we didn't really have any more big problems and now we have got a working alternative build and deploy to heroku pipeline that allows us to build or app locally and then deploy that.
I have a specific problem but the solutions are hopefully probably generic for similar problems.
I have a Play! framework 2.0 project, using Scala.
I am trying to deploy a new version to Heroku.
However for this project the deployment fails as the slug size is too big (101MB).
Now this app is very simple, so it is most likely a configuration problem. The current deployed version is/was using Play! 2.0-RC3 and the one I am trying to deploy is using version 2.0. That may be an issue?
I have tried to use a .slugignore file, ignoring .ivy2, project/boot etc, but to no avail.
Any other suggestions for how to reduce the slug size? When Using Play 2.x and Scala?
Here is the git push output (excluding the Selenium dependencies is probably a start)
Just follow the instructions on the bottom of this page. You simply fork https://github.com/heroku/heroku-buildpack-scala and change the bin/compile script towards its end as described in the Finetunig section.
EDIT: as of the time of this post the code was in the buildpack repository but not yet live, as per #JamesWard comments. I assume it will be released soon :)
I see that your application was started a few months ago. Try to remove the Heroku application and create it again from scratch.
Heroku's buildpack already contains the changes listed by Fynn to reduce slug size (tested yesterday), but if your aplication is old it may be that the changes were not added. Of course, you could modify your buildpack, but it may be simpler to just recreate the app.