I've been searching around the web to see what's the best/simplest way to deploy a meteor app, and have found that Meteor Up has been the easiest way to do this.
However, I've been noticing that this works pretty awesome on small apps, now that one of our apps has grown larger than 250mb, Meteor Up has to build and deploy the whole 250mb app again and again for even the smallest change.
With other node applications we have on digital ocean, a simple git pull does the trick without having to re-upload the entire application.
Is there a way to maintain a meteor application with a github/bitbucket repository?
Thanks!
Well, I have found a solution for this.
Reference: PM2 + Meteor Environment Setup
Using meteor build and following the README that it generates, I was able to run the bundle without using meteor up.
This helps at deploying since it skips the process of uploading the entire bundle to the server, instead, just use git pull in the server to pull your code changes and use meteor build to create the build and run it with pm2.
Related
Quick background: I'm a java web developer. I deploy my apps in EARs. I'm not familiar with how the build process works for the new JS frameworks like ReactJS. I have been using WebPack as a build tool but only in dev. I'm trying to keep up with the growing tech because my company is slowly adapting to it.
Question 1
How does the build process work when deploying a React app to a prod app server (or any server at that)?
I'm guessing Node will have to be installed on the app server with WebPack as a globally installed package so when the app is ready to be built, WebPack will kick off its build script in the package.json file that will create your bundle.
Question 2
If the above ^^ is somewhat correct, how do you kick off the WebPack build script?
My company uses IBM's Rational Team Concert as version control. RTC uses Ant scripts as their build so I'm guessing since we have a Spring Boot API that uses Gradle, we can tell the Ant script in RTC to run the Gradle script so the Spring API will build. Right before the Gradle build ends, Gradle can kick off the WebPack build script that will create the bundle.js. And from there you should have a full functioning frontend service just like you would when developing it.
This whole process has a been a headache to wrap my mind around and would like to get some clarification because there's only so much I can research without pulling all of my hair out. I hope I'm somewhat close to the correct way this process works.
In new version webpack (>=4) added new options mode for set environment. For get more information read this tutorial
webpack conf for production
and about deploy (ci,cd), webpack required before build, after build you don't need any js tools (SSR other case). Just create archive (project_${branch_name}.zip) and upload some store like gitlab, awsS3, etc and download when deploy.
I'm recommend don't mixing ui with backend if it possible split project other repository.
Note that RTC has multiple build definition templates. ANT is just one of them. You can also use the Maven build template, the Command Line as well if using the Jazz build engine. If its connected to Hudson/Jenkins for its build functions, you can use those as well.
I am facing dilema whether I should bundle node js app from meteor or just run meteor --production.
I am mostly interested in performance impact. I have found some explanation on here, but it is not clearly stated that meteor runs in production mode.
Running just meteor --production will simplify my deployment process a lot.
I would like to know are there any reasons to stick to bundle?
I think when you run meteor --production, you are still running as if you are in development-mode, only using "production" settings and such. You are still getting an internal/local MongoDB, you are still burning CPU time monitoring files, etc.
If this is true, then the end result is that you will not scale at all. I doubt that running local MongoDB uses optlog, which is a HUGE performance boost for Meteor apps.
Your best bet would be to look at some automated build/deploy tools. I have personally used mup and mupx. The latest version of mup builds your app, sets up MongoDB (if you want) and nginx, builds them all as docker images, and deploys them. You can even setup SSL certs w/ nginx (although no Let's Encrypt support yet :(). Or, you could easily script the deployment yourself using any number of tools, including just raw scripts. I think in the long run you will be in much better shape than trying to run the app using the meteor command.
I'm running a NodeJS app on Openshift using Jenkins for building deployments (and I'm pretty new to both Node and cloud-based servers). My app depends on a package that has a binary component, so I can't just check it into git - it fails when it's executed on the server. I'm wondering what's the best way to deploy these sorts of dependencies. I see that there is an $OPENSHIFT_DEPENDENCIES_DIR (as well as $OPENSHIFT_BUILD_DEPENDENCIES_DIR), but I can't find any information about how (or if) these can be utilized for node modules. It would be great if I could keep all my dependencies on the server and out of my source tree.
Thanks!
Update: I forgot to mention that I need to apply a patch to the package in question, which is why I can't just rely on it being auto-installed via package.json. Plus, it seems awfully redundant/slow to rebuild all your dependencies on every deployment.
I'm also new to nodejs. I've been playing with nodeJs for about 6 months from now. As for my personal experience nodejitsu is the best cloud-hosting service for nodejs. As I said so due to the following reasons.
You can simply install jitsu command line in your terminal
Your app can be deployed with all the dependencies and databases using the package.json file
They support all the types of sockets either
A very good alternative for jitsu is heroku But sometimes heroku fails with Socket.IO and stuff.
I have a build process involving templating and file copying, which produces what I would like to deploy to Heroku.
But Heroku requires to push your source from a git repository.
What I currently see as my only option is to have a separate git repository, that only holds my build history.
My project is a NodeJS server application.
Is there a better approach?
Thanks.
I have create a grunt-init project template that simplifies the develop-build-deploy cycle of NodeJS server apps deployed on Heroku.
Here it is: https://github.com/nicroto/grunt-init-heroku
This will allow you to have a single repository for your server & client apps, AND do actual build work.
I am basically creating an ignored by git build dir, which I synch-up with your Heroku app. And of course scaffold the project with sample init, build and deploy scripts.
I hope this will be helpful to the community. :)
I would like to get this app:
https://github.com/lysol/typeto.me/
running on Heroku (or some similar service).
What steps would I need to follow? I'm having a great deal of trouble understanding what to put where.
I already know I need to do something like this:
Can I run coffeescript in Heroku?
for the coffeescript stuff.
So this is super easy to run on dotCloud.com
Here is a demo I just pushed.
Just clone this fork and push it to dotcloud.
create an account on dotcloud.com
install the cli tool
clone the repo git clone git://github.com/3on/typeto.me.git and cd typeto.me
edit the config file and put right value for "publicHost" typetome-[your dotcloud login].dotcloud.com
create an app dotcloud create typetome
push it to the cloud dotcloud push typetome
And that's it!
Heroku has a great article on deploying node.js apps at their devcenter. It is fairly simple, assuming you use NPM for packages, and git for version control.
You can try this site http://wedeploy.com/ with suport Node, Ruby, MongoDB, and others services. Have simple client to manage your apps.