I started using naught for node.js deployment (https://github.com/andrewrk/naught).
I have a folder in Ubuntu Server containing my node.js(express) app.
I deployed it using "naught start app.js" from this folder.
Now I would like to redeploy/update my code with zero downtime.
What should I do?
Suppose I have my code on a git server, do I "git pull origin master" in the same folder and then "naught deploy" to deploy the new code? Or maybe I need to pull the new code to a new folder and deploy the new code in another way?
Pulling the latest changed from Git and calling 'naught deploy' should do the trick. You don't need to clone your code a different directory.
Notice that the 'deploy' command expects an .ipc file, and by default looks for it in the same directory from which you called deploy. If, when starting naught you specified a different location for the .ipc file, then you should call deploy with that location.
So for example, if you did:
naught start app.js --ipc-file /var/run/naught.ipc
Then when deploying use:
naught deploy /var/run/naught.ipc
At BigPanda we use naught in production this way, and it works perfectly.
Related
When I run a development server on localhost:3000 using npm run start, the server works as expected. I am using react-scripts, I have not ejected the react app.
What I am trying to do, is set up the dev server behind a reverse proxy. So localhost:5572/author/name/ will point to the development server running on localhost:3000.
The setup is working fine, the index.html gets loaded. But as the dev server is running at "/", the page tries to load scripts as "<script src="/static/js/bundle.js"></script>". So, it expects the URL to be localhost:5572/static/js/bundle.js. But the reverse proxy is serving the same file at localhost:5572/author/name/static/js/bundle.js
Inside the package.json, I have specified
{
...
"homepage": "./",
...
}
so my production builds have a relative path, but the dev builds don't.
Is there a way to have relative paths rather than absolute? Or is there a different solution I can use.
Thank You.
Create file named .env.development in the root folder of your project. Add to the file the next string:
PUBLIC_URL=/author/name
This settings will affect only on dev mode. More details about how to define environment variables you can find here. And here is some information about using of public folder.
I changed the filename of one of my routes from authroutes to authRoutes. When I commit the changes and deploy to heroku, the build fails because it is still looking for authroutes.
2017-09-16T15:57:57.744695+00:00 app[web.1]: Error: Cannot find module './routes/authRoutes.js'
The only reference to the file is in my index.js file via:
require('./routes/authRoutes.js')(app);
I make the change in the index.js file when committing. I've tried clearing my build cache with the heroku-repo plugin as well as making changes to the file itself. If I switch the file name back as well as the reference in index.js, everything works without a hitch. I've tried manually changing the file with heroku bash but it just switches back after the build process is completed to the all lowercase version.
Thanks!
The buildpack may be doing something with the hash comparison against the repo that requires a change bigger or more significant than a single byte changing Case.
If that is so, why dont you try a drop/add of an entire file across 2 successive git push actions?
rm your router file from project
git push heroku master ( node start may fail but so what )
add back your "new" router file with the change that the repo hash failed to recognize
git push heroku master with the new version of the router
that should fool the buildpack hasher for node projects enough to FORCE thru your change.
I have a local development machine and a test server.
Now I have an APP_ID that's being used in Javascript. I've been looking into ways that they kan differ on my local machine and on the test server.
Using Gulp
With gulp it's possible to add a flag on the command line:
gulp build --env=production
That way I can get the correct APP_ID from a file.
The only issue is with this approach I need to run my build on the server, at this moment I run gulp locally and upload the changes to my server
Is it okay to build on the server? Are there other ways to use environment variables in Javascript?
My suggestion is to not build on the server but build locally and then deploy to the server using one of the many deploy solution (es. deployer.org for php). Normally javascript NPM packages put build output even in GIT repository ready for use in other projects or for deploy.
For more info on how to use env variable in node (gulp run over node) see this page
For example in linux you can set env variable with export
app.js :
console.log(console.log(process.env.foo))
Then try
> export foo=app1
> node app.js
Res:
app1
Then try
> export foo=app2
> node app.js
Res:
app2
This is valid only if you run your code server side on node (ex on gulp).
If you are developing a client side library and you want to create different builds that targets different enviroments you have to instruct gulp to do so. In this case this is a guide that can help you
I want to set up a second node.js server to run an express.js application which is an exact and independent copy of my current html (client-side) and js (server-side) files.
The reason is that I want to deploy my current code in a production environment that can be used by the team that will not be shut down, while I work on my current code in a development environment.
My worry is that I have added my current node.js server to my path and I am not sure if upon installation of the second node.js server my command to start the second server will interfere with the node.js server I have saved in my path variable.
Here are a couple of things to know before I ask my questions:
I am working on a machine with a Linux distribution.
I am using Express.js routing
I am using the instructions to install another instance of node.js and express.js at:
www.vultr.com/docs/installing-node-js-and-express
My questions are as follows:
Is this as simple as installing node and express as per the instructions in the link above into a new directory and running from the new path without storing it in my path variable?
Is there a better and more effective way to create a production and a development environment so that my team can use the app I have built without interfering with my current instance of node while ensuring 100% up time for the app deployed in production?
Once the 2nd server is instantiated, how do I make the call from my terminal so that it does not turn on/off the original node server I have running from my path variable?
Considering that the link above is a how to on how to install node and express from scratch and in Ubuntu (I am on CentOS - Gnome), is there a better "how to" that I should use to complete the second node and express install?
When creating the new Port for the second node/express server to listen on can I just pick any number with 4 digits or is there a particular set of numbers that would be more effective to use? I am already using Port:3000 for my first instance in my development environment.
Thank you for your guidance.
Developing and serving from the same PC is not preferable, however, if you must, this is what you can do.
First, there is no need to install a second copy of node on to your machine - you can run multiple processes of node on the same machine without any problem.
What I suggest you do is this:
If you haven't already, commit your project into a git repository
Create separate branches for development and production, as shown here: http://nvie.com/posts/a-successful-git-branching-model/#the-main-branches
Every time you are ready to publish a new piece of code, push it to the master branch
Move all configuration parameters to a config file, and create s separate one for dev/production, you can do this easily with the config package: https://www.npmjs.com/package/config
Clone your repo to a separate folder which would always remain on the master (production) branch
Run you server from that folder - your team could then connect to it
All development would be done in the original folder. Once you are ready, push to master, and pull on the production folder.
Regarding the port numbers, you can use anything that is above 1024 and below 65535
I know how to get the current directory from a Meteor package, but how do I get the path of a specific file in the project?
node's __dirname and __filename don't work in Meteor.
It is complicated.
meteor run copies your project files to a tree of directories inside <project-dir>/.meteor/local/build, reorganizes them in non-obvious ways (e.g.. the private subdirectory in the original tree becomes the assets subdirectory) and mixes it in with various npm modules to create a bundle that can be executed as a nodejs project. Indeed, to avoid duplications, there is a .gitignore file automatically set up in the .meteor directory that tells git, if you use it for version control, not to copy the .meteor/local directory.
The original project directory gets watched in case you change a file. The change then gets copied into the current project build directory and the project rebuilt.
If you deploy to a remote system, the build gets copied to a server and then run.
process is usually a defined global server-side object, and works according to the node.js API, because the meteor server code is ultimately running in node.js.
So you can run console.log(process.cwd()); in your server-side to obtain the current working directory for the server process, usually something like:
~/<meteor project directory>/.meteor/local/build/programs/server
This suggests that when meteor run is done locally, original project files are in ../../../../../, but don't use that as it may change in the future.
Instead, for the directory containing the original project files, you could use:
baseDir = process.cwd().replace(/\/\.meteor.*$/, '');
This will get the working directory, and truncate everything beginning with /.meteor
This won't work for a server deploy, though, because the original project tree is not needed on the server, only the build. Files that aren't intended to be client or server code could possibly be stuck in the private subdir, which as I mentioned becomes the assets subdir in the build. Ways to currently find files in the build is either manual inspection .meteor/local in a local run, or use of a JS library that calls or imitates gnu find.
Since you mentioned packages, I note that in the build, server-side package code finally ends up in:
~/<project-dir>/.meteor/local/build/programs/server/packages
and client side in:
~/<project-dir>/.meteor/local/build/programs/web.browser/packages