I'm using the nodejs library:
import net from 'net'
When creating a server via:
net.createServer
Then I can make the server listen using the next procedure:
server.listen({host: 'localhost', port: 8000, exclusive: true}, () => etc..)
My question is why do I need to specify a host for the server? I mean, I should not always be serving on the server/ip where the service is placed? When I deploy a service in spring or nginx I don't have to specify the actual host since it's assumed what host should use. Isn't it right?
To answer your question, you do not need to specify a host when deploying your server. It is an optional dependency for people who may be using a VPN and have 2 different IP addresses.
The following code is all you need to deploy your web server.
server.listen(port, function() {
// Do something
});
Related
I have a NodeJS micro-service hosted on Google Cloud Run.
The service houses both an express server for user facing routes and a gRPC server for communicating with other internal micro-services.
Below is my code so far:
....
//For the express server I am using an hard coded port because of port conflict with grpc server port
const app = express();
const hardCodedPort=3000; //I can't use process.env.PORT here because grpc server below needs it
app.listen(hardCodedPort);
......
//For grpc I am NOT using an hardcoded port, I am listening to the port provided by Cloud Run as shown below
gRPCServer.bindAsync(`0.0.0.0:${process.env.PORT}`, grpc.ServerCredentials.createInsecure(), () => {
gRPCServer.start();
});
Now, owing to the fact that Cloud Run can spin very many instances of the above service will I hit a port conflict for my express server since it is always listening on an hard coded port?
The Cloud Run Frontend (GFE) only supports two ports: 80 and 443. If a client connects to port 80, the client will be redirected to port 443. In other words, your Cloud Run service can only support one internal port number, which defaults to 8080 (configurable). Your application can only listen for connections on one port.
I have been researching this for day and I haven't been able to find the way to do this.
I am building a react app, running express at the backend, that needs to access some data in a remote database that lives inside a VPN. At the moment the app lives on my localhost so its enough for me to connect my machine using openvpn client and everything works a beauty. The problem will rise when the app will be live and I will need it to have access to the vpn by (I'm guessing) having a vpn client running on the site/domain.
Has anyone done this before?
I have tried to install the node-openvpn package that seems could do the job but unfortunately I can't manage to make it work as the connection doesn't seem to be configured properly.
This is the function I call to connect to the vpn that systematically fails at the line
--> openvpnmanager.authorize(auth);
const openvpnmanager = require('node-openvpn');
...
const connectToVpn = () => {
var opts = {
host: 'wopr.remotedbserver.com',
port: 1337, //port openvpn management console
timeout: 1500, //timeout for connection - optional,
logpath: '/log.txt'
};
var auth = {
user: 'userName',
pass: 'passWord',
};
var openvpn = openvpnmanager.connect(opts);
openvpn.on('connected', function() {
console.log('connecting..');
openvpnmanager.authorize(auth); <-- Error: Unhandled "error" event. (Cannot connect)
});
openvpn.on('console-output', function(output) {
console.log(output)
});
openvpn.on('state-change', function(state) { //emits console output of openvpn state as a array
console.log(output)
});
};
Am I misusing this function? Is there a better way?
Any help will be extremely appreciated.
Thank You!
The problem will rise when the app will be live and I will need it to
have access to the vpn by (I'm guessing) having a OpenVPN client running
on the site/domain.
Thats correct, you will need an openvpn client instance on the server where you will run the backend.
The above library (node-openvpn) is simply a library to interact with the local OpenVPN client instance. It cannot create a connection on its own. It depends on the OpenVPN binary (which should be running).
The solution you need is simply run the OpenVPN client on your server (apt-get openvpn). And let the daemon run. Check out the references below.
node-openvpn issues that points out that a running instance of the client is needed
OpenVPN CLI tutorial
I'm trying to deploy a node.js app on aws EC2 Beanstalk. My problem is, I can't figure out how to move from my localhost testing environment to aws standard. Right now, my app works on port 8081 by using the following code.
var server = app.listen(8081, function () {
var host = server.address().address
var port = server.address().port
})
How would I change this server variable to work on an actual domain?
Assuming your intent is to provide a public-facing web application, your code will work as is, albeit with a few caveats:
Currently your server will listen on port 8081. Once deployed to AWS users would have to browse to www.somedomain.com:8081 to reach your application. (Assuming the host instance allows traffic on that port. See below).
If your intent is to have users reach your application at www.somedomain.com - without specifying a port - you'll want the server to listen on port 80 instead.
var server = app.listen(80, function () { ... }
In either case you'll need to ensure that the security group rules for the EC2 host instance allow incoming TCP traffic on the listening port. Likewise, if your EC2 host instance is behind a load balancer you'll need to allow incoming traffic on the appropriate ports there as well.
For something a little fancier, you can try deploying your application to Elastic Beanstalk using Docker and exposing port 8081 in the dockerfile. This way users would still reach it at www.somedomain.com (via http port 80) and you could continue to develop and test locally using port 8081.
One final note: you didn't provide much information about what your application is or how you intend to use it, so I'm making quite a few assumptions based only on the information provided.
This code works great for me with node on Elastic Beanstalk, and allows me to seamlessly switch between localhost and remote development without changing any code:
var port = process.env.PORT || 8081;
var server = app.listen(port, function () {
//server is started!!!
})
I have set up up a node.js 0.10 gear in OpenShift which I deployed a simple server which is based off peerjs-server. All I want this server to do is act as a signalling server to communicate the connection info between peers connected to my application and from then on they communicate peer-to-peer using WebRTC. Everything works when pointing to the demo "PeerJS Cloud" signalling server but when trying to use my own server set up I keep getting returned 503 status codes.
Here is the server creation code I use:
var host = process.env.OPENSHIFT_NODEJS_IP;
var port = process.env.OPENSHIFT_NODEJS_PORT || 8080;
var server = new PeerServer({ port: port, host: host});
NB: I have added host to peerjs-server so I can use OpenShift's IP, not sure if this was necessary but it wasn't working without this either.
The server peerjs-server uses is restify. Here is the server create and listen code:
this._app = restify.createServer(this._options.ssl);
/* A lot of set up code that I have not changed from peerjs-server */
this._app.listen(this._options.port, this._options.host);
Where this._options.port and this._options.host are the ones defined in the previous code segment and I am not using SSL so nothing is being passed in there.
When deploying this code to OpenShift I get no errors but when accessing the site on port 80 or 8000 (the open external ports) I get 503's. I also checked rhc tail and this is what I get:
Screenshot (Can't post images because I have no reputation..). Not sure exactly what that means if anything.
Any help is much appreciated, and if more info is needed I can add more, was not sure what was important information or not.
UPDATE: It's a scaled application using 1-3 small gears.
from https://github.com/peers/peerjs-server/blob/master/lib/server.js:
// Listen on user-specified port and IP address.
if (this._options.ip) {
this._app.listen(this._options.port, this._options.ip);
} else {
this._app.listen(this._options.port);
}
So, use 'ip' and not 'host'. Worked for me.
So say I have a node.js application that hosts both a HTTP and HTTPS server as described in the question: How to force SSL / https in Express.js
In my code I have the following:
// General configuration settings for production usage
app.configure(function () {
app.set('port', process.env.PORT || 3000);
app.set('sslport', process.env.SSLPORT || 4000);
...
}
http.createServer(app).listen(app.get('port'), function () {
winston.info('Express server listening on port ' + app.get('port'));
});
var options = {
key: fs.readFileSync('key.pem'),
cert: fs.readFileSync('cert.pem')
};
https.createServer(options, app).listen(app.get('sslport'), function () {
winston.info('Express server listening on port ' + app.get('sslport'));
});
Which works perfectly fine for a local running node server.
However, I want to publish my site to a cloud hosted provider like Azure Web Sites, Heroku, Nodejitsu, etc.
All of the cloud hosts seem to set a process.env.PORT value, but only the one. When my HTTPS server is created this usually results in the app crashing, as the PORT is already in use / access denied / etc.
So how do I create / host a site with a secure login page with only one port to work with!?
If you use Heroku you get SSL without needing to specify a port in nodejs. All you need to do is listen on the heroku PORT environment variable for http requests. Once uploaded to heroku you can address your heroku app using either https (on 443) or http (on port 80). Heroku routes either to your server.
Similarly if using elastic load balancing with EC2 you can make use of SSL termination at the load balancer, and again route to your node server listening on port 80 using using http. http://aws.amazon.com/elasticloadbalancing
In both cases you can use either self-signed or proper SSL certificates depending upon your need.