I've node application and I use the following guide to debug it which works great
https://codeburst.io/an-easy-way-to-debug-node-js-apps-in-cloud-foundry-22f559d44516
Now I've a bit more complex scenario which one application is spawn other node application which I want to debug (the spawned application ) , in the cf top I see this app PID (of the spawned app) but my question if there is a way to debug it also ? both app running in the same container .
I was able to debug the master app but not the spawned app..., any idea how ?
I was able to ssh the main app, we are using cf 2.98 version
I don't think there's anything CloudFoundry-specific that needs to be done to make this work. The process described at the link you provided is showing how you can launch an application with the node --inspect flag, create an SSH tunnel to the port where node is listening and then attach to it remotely over the SSH tunnel.
If you're spawning subprocesses, I would suggest that you make sure those subprocesses, assuming they're also running Node, have the --inspect=<port> flag passed to them. In this case, you will need to set a port because the default port 9229 used by --inspect is already taken by your main process.
I don't know if your subprocesses are short or long-lived, but you may need to log the inspect port assigned to them somewhere so that you know which port to connect to so that you inspect a specific subprocess.
Hope that helps!
Related
I have a node.js Websocket server listening on port 443 running in a Docker Container(let's say ws_container) that is connected to both the host network and an internal network , let's say internal_net.
When the Websocket server running in ws_container establish a connection with a Websocket, I want to spawn a new container(let's say an Ubuntu 18.04 container) connected to internal_net from the ws_container.
I came across this question Is it possible to start a stopped container from another container , that states the best way to accomplish this is to mount the docker socket in the container(in my case ws_container).
Are there any better ways of solving the problem?
It depends where you want to spawn container. Containers run where docker daemon runs. To connect to the daemon you can use socket if the daemon is on same machine or you can use tcp connection to spawn container on any daemon that you have access to.
If you use some kind of orchestration like swarm or kubernetes then you can use some management tools to do that, like portainer, open shift or others.
However in most of the cases mapping socket is the easiest and sufficient option to do.
I am trying to setup the firewall for accessing node inspect using my local chrome browser.
Does anybody have a good short guide and which tcp protocol do I need to enable.
I have a firewall rule active where the compute instance enables tcp:80. It worked in the past of a http server. How do I know which port to use for node inspect and how to enable it.
If found it myself. I have to use an ssh tunnel. https://nodejs.org/en/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios
Enabling remote debugging scenarios
We recommend that you never have the debugger listen on a public IP address. If you need to allow remote debugging connections we
recommend the use of ssh tunnels instead. We provide the following
example for illustrative purposes only. Please understand the security
risk of allowing remote access to a privileged service before
proceeding.
Let's say you are running Node on remote machine, remote.example.com, that you want to be able to debug. On that
machine, you should start the node process with the inspector
listening only to localhost (the default).
$ node --inspect server.js
Now, on your local machine from where you want to initiate a debug client connection, you can setup an ssh tunnel:
$ ssh -L 9221:localhost:9229 user#remote.example.com
This starts a ssh tunnel session where a connection to port 9221 on your local machine will be forwarded to port 9229 on
remote.example.com. You can now attach a debugger such as Chrome
DevTools or Visual Studio Code to localhost:9221, which should be able
to debug as if the Node.js application was running locally.
I have a single EC2 instance on AWS, running HTTPS server with NodeJS.
I'm starting my NodeJS server from the /etc/rc.local, so it will start automatically on every boot.
I have 2 questions:
Is there a better way to start an https server listening on port 443 without using sudo path/to/node myScript.js? What risks do I have if I run this process as root?
Where do I see my logs? When running the script from the shell, I see the logs of the process, but now when it is runs from rc.local, how do I access the output of the server?
Thanks!
Starting the application using sudo definately is not a good practice. You should not run a publicaly accessible service with root credentials. If there is a flaw in your application and someone find this out there is the danger to access more services in the machine.
Your application should start in a non-priviledged port (e.g. 5000) and then having nginx or apache as a reverse proxy that will forward the traffic internally to your application that is running on port 5000. pm2 is suggesting something like that as well: http://pm2.keymetrics.io/docs/tutorials/pm2-nginx-production-setup. Searching online you will be able to find tutorials on how to configura nginx to run on https and how to forward all the traffic from http to https. Your application should not be aware of ssl certificates etc. Remember that the pm2 module should be installed locally within your project and you have to take advantage of the package.json. In there you can define a task that will boot your application on production using the local pm2 module. The advantage is that you don't have to install the pm2 module globally and you will not mess the things again with the permissions and super users.
I don't think that the log is saved somewhere until you will tell it to happen in the rc.local script. How do you spawn the process in there? Something like that should redirect the stdout to a file:
node path/to/node myScript.js 2> /var/log/my-app.rc.local.log # send stderr from rc.local to a log file`
Don't you use a logger in your application, though? I would suggest picking one (there are a lot available like bunyan, winston etc) and substitute all of your console.logs with the logger. Then you can define explicitly in your application where the logs will be saved, you can have different log levels and more features in general.
Not a direct answer, more a small return on experience here.
We have a heavy used nodejs app in production on AWS, on a non-Docker setup (for now ;) ).
We have a user dedicated to run the node app, I guess that if you start your node process with root, it has root access, and that's not a safe thing to do.
To run the app we use pm2, as a process manager, it allow to restart the node process when it fail (and it will), and scale the number of worker to match the number of core of your EC2 instance. You also have access to log of all the workers using ./path/to/node ./node_modules/.bin/pm2 logs, and can send it to whatever you want (from ELK to slack).
My2cents.
I am running a Nodejs server with an application which I want to debug.
In order to achieve this using node-inspector I run the app as follows:
node-debug server.js
Unfortunately I can not access the webserver via URL anymore. Visiting http://127.0.0.1:8080 results in
Cannot GET /
However if I start the application the usual way with
node server.js
everything is fine (except for the fact that I can not debug). But I can access http://127.0.0.1:8080.
The '/' request is also not logged so it seems that it never reaches the server.
Hence the problem I have is: I can access the remote debugger via http://127.0.0.1:8080/debug?ws=127.0.0.1:8080&port=5858 but I can not start debugging because I can not trigger any action on the webserver via URL.
Oh and the debugger is not paused or anything. I skipped the first break point.
I resolved the problem by choosing a different port than 8080. It seems like the debugger uses this port. I was not aware of that because this port was familiar to me as I used it for my application.
As Schnodderbalken already answered, the problem lies in the application and inspector both using the same port 8080. If you tell inspector to use a different web port, 8082 for instance, the problem is solved.
You can do this by adding a parameter like so:
node-inspector --web-port=8082
You can then access inspector via http://127.0.0.1:8082/?port=5858
I have 2 apps on server: "Websphere Commerce" and "myapp". While Myapp inits, it needs to receive some data from WC using SOAP, however, until both apps are started, the common http port 9060 isn't listening.
There's a flag:
Enterprise Applications > * > Startup behavior
Startup order
Launch application before server completes startup
It's cleared for both apps. I thought, WAS would first report:
TCP Channel TCP_2 is listening on host * (IPv6) port 9060.
Server server1 open for e-business
then start the apps, but it first starts them, then opens the port.
Then what does this flag do?
Check this page Startup behavior settings
Launch application before server completes startup
Specifies whether the application must initialize fully before the
server starts. The default setting of false indicates that server
startup will not complete until the application starts.
A setting of true informs the product that the application might start
on a background thread and thus server startup might continue without
waiting for the application to start. Thus, the application might
not be ready for use when the application server starts.
So it is other way around, server first ensures that applications are started and then opens port to allow traffic to them.