What is best approach to have live code changes deployed to PROD.
So that
i don't have to restart my servers.
And don't want to push the entire bundle.tgz file
What are the options ??
We have a Meteor app in production - We upload the new bundle and prepare it (updating the native fibers) and restart - you have to restart the node thread.
You might say that you kick all clients, but Meteor is build to handle poor connections and will reconnect - it uses delay algorithm to help flatten out reconnects.
If the client is ready for migration the new code is then pushed.
Our app is running Meteor inside cordova and we use appcache making sure that clients can allways open our app even if offline.
NOTE: MDG is working on Galaxy - a cool and easy way of managing your own Meteor servers - so deployment would be a single line in a terminal. (eta aprox. first part of 2014)
Easy deployment to your own server (DigitalOcean, Amazon EC2, etc) can be done using meteoric.
Meteoric can setup your server and deploy latest commit to production.
I use it and it works great.
Related
I want to set autoscaling for my meteor app.
Ideally I would like to keep build image ready on s3(or some other storage, image would be typically generated from last build) and using aws-lambda(so that no dedicated build server is needed) to deploy using this image on new instance. I would like all this to be finished within 2 minutes.
So is it possible to mup for these tasks
build image and save it to aws s3, without deployment.
run mup deploy programatically using image from aws s3.
No need of mup setup, because I will launch instance with ami which has already been setup.
mup is also setting up ssl for me using letsencrypt.
I am also open to other tools/scripts to achieve this.
You won't get much response from this question, because mup makes deployment life quite simple, and most people who use it don't know much about what it does.
You should have a look at the code of meteor-up to see what it does, and see where you can extend it for your own purposes. You could also look at yamup, as that is another approach to the same problem.
I need Meteor App in production, without worrying about scaling in the future. App will have 500 user online in any one time - as maximum. I read in the oficial guide that the best practice for many reasons is deploy to Galaxy.
But there are also many articles about deploy to Digital Ocean and Heroku.
So what variant is the best?
Use digitalocean.
Set up nameservers, set up node on your droplet and have Mupx do the deploying. It's very easy and DO is cheap.
DO has easy to follow tutorials to do the initial setup and you will thank me later + your wallet will be happy.
I have used Galaxy in a production level app for one of our clients and it works fantastic. If you want a deployment where you don't have to worry about scaling at all, then Galaxy is for you.
With time, as your users increase and you find yourself needing more resources, you can assign better containers and CPU power with just the click of one button. It also provides complete logs and some performance metrics to help you in a completely meteor-specific manner.
The deployment process itself is as simple as having a settings json file, and running a one line command like:
DEPLOY_HOSTNAME=galaxy.meteor.com meteor deploy appname.meteorapp.com --settings settings.json
As we all know, we can run a meteor app by just typing meteor in a terminal.
By default it will start a server and use port 3000.
So why do I need to deploy it using MUP etc.
I can configure it to use port 80 or use nginx to route to port 80 for the app. So the port is not the point.
Edit:
Assume meteor is running on a VPS or cloud server with public IP address, not a personal computer.
MUP does a few extra things you can do yourself:
it 'bundles' the code into a single file, using meteor build bundle
the javascript is one file, and css another; it's minified, and obfuscated so it's smaller and faster to load, and less easy to decipher on the client.
some packages are also meant to be removed when running in production. For example meteorToys, the utility toolset to look up collections and much more, is not bundled into the production bundle, as per the instructions in its package. This insures you don't deploy code with security vulnerabilities (Meteor toys basically opens up client side delete / updates etc... if you're not careful)
So, in short, it installs a minimal version of your site, making sure that what's meant for development only doesn't get push to a production environment.
EDIT: On other reason to do this, is that you don't need all the Meteor build tools on your production server; that can add up to a lot of stuff, especially if you keep caches going for a while...
I believe it also takes care of hooking up to a remote MongoDB Instance (at least it used to be the case on the free meteor site) which is more scalable and fault tolerant than running on the same instance as the web server, as well as provision storage etc... if needed.
basically, to deploy a Meteor app yourself manually, you need to:
on your dev box:
meteor build bundle your app to a tar file (using the architecture flag corresponding to the OS you will use)
on the server:
install node v0.10 (or whatever is the current version of node required by Meteor)
you might have to install Fiber#1.0.5 (but I believe this is now part of meteor install already)
untar the bundle, get into bundle/programs/server/ and run npm install
run the server with node main.js in the bundle folder.
The purpose of deploying an application is that you are situating your project on hardware outside of your local machine. For example if you deploy an application on Heroku app you create a repository on heroku's systems and that code based is used to serve your application off of their servers.
If you just start an application on your personal system, you will suffer a lack of network and resource availability as well as under use of computer time at non-peak hours as your system will need to remain attentive for additional users without having alternative tasks. Hosting providers provide resources as needed, and their diverse client base allows their systems to work around the clock on a global scale.
I have an app running on my own digitalocean VM that I'm trying to play around with to figure out how to run a meteor production server. I deployed it with meteor build, but now I'm a bit unsure about how to push updates. If I build a new tarball on my own machine, I will loose file references that my users have made to files in bundle/uploads, because the remote filesystem isn't incorporated into my local project. I can imagine some hacky ways to work around this, but besides hosting the files on s3 or another 3rd party server, is there any way to "hot code push" into the deployed app without needing to move files around on my server?
Am I crazy for wondering what the meteor equivalent of git push/pull is in production, or just ignorant?
You can use dokku (https://github.com/progrium/dokku). DigitalOcean allows you to create an instance pre-installed with dokku too.
Once you've set up your ssh keys, set the environment variables, ROOT_URL, PORT and MONGO_URL you can add that server as a git remote and simply git push to it.
Dokku will automatically build up the Meteor app and have it running, and keep it up to date whenever you git push.
I find Dokku is very convenient. There's also flynn and deis which are able to do the same in multi tenant environment with way more options.
Just one thing to keep in mind with this is to push the guys who own the repo to keep the Node version in the buildpack up to date. Meteor is a bit overzealous when it comes to using the latest version of Node and refusing older versions.
Meteor does lack a bit in this department. I can't remember where I may have heard this, but I believe they intend on adding this very popular Meteor deployment package to their library. Short of switching to a more compatible host, I'm not aware of any better solutions.
For production why should I "bundle" the meteor application and not just copy
the sources on the server use the "meteor" command?
Basically what is the difference between:
"meteor bundle app.tar.gz", then installing the right version of fibers and nodejs
and extracting the archive and starting with "node main.js" the app,
and copying the project sources on the server and just writing "meteor" to start
the app?
This won't be an exhaustive list, but here are some things that the meteor command does:
creates a local database
watches on every dependent file in your app or in your packages
sends every file separately and unminified to the client (this is super inefficient unless you are developing locally)
In contrast, bundling an app:
does not create a local database
does not spend CPU watching your files for changes
creates two minified files (js and css) which is perfect for putting on a CDN or hosting from a reverse proxy. These are also efficient for clients to download and are highly cacheable.
In general, deploying shouldn't be a huge pain if you use a good set of scripts.
When using a bundle:
It will not spawn meteor-mongo(Mongodb inside meteor)
No hot reloads
Meteor will not watch your files.
You can leave/quit the server without killing your app.
You can manage node processes smoothly by using pm2 or other similar npm packages.
You can decide where to put your mongoDB and decide what port to use.
You can connect to your mongodb remotely by not having to run your meteor app.
While using a copy or running meteor command in the project directory:
You can't leave/quit the server while keeping the project running without using any screen multiplexers (e.g. tmux)
You can only use meteor's assigned mongodb which is spawned in localhost:3001 -- if meteor is using port 3000.
You are letting meteor to watch over file changes which uses CPU.
When your app dies, your db dies. :)