Debugging Node.js applications from inside Docker - javascript

When debugging a Node.js application, I expect the command node index.js --inspect=5858 to make my index.js file debuggable on the port 5858.
When I run the application outside of Docker, on my host computer, I'm able to debug the application in Chrome Dev Tools. I did the same inside of Docker and Chrome Dev Tools is unable to access the debugger on port 5858.
As you can see, port 5858 is exposed to the host computer for debugging:
version: '2'
services:
server:
build: .
command: node index.js --inspect=5858
volumes:
- .:/app
ports:
- "8000:8000"
- "5858:5858"
environment:
- NODE_ENV = "development"
I've specified localhost:5858 and 127.0.0.1:5858 network endpoints in Chrome Dev Tools, though still Dev Tools does not connect to it automatically as it suggests.
This seems to be an issue with my Docker setup though as you can see, I have exposed the port to the host computer. What could be the issue? Thanks.

The issue is that when you are running it inside the container it is listening only to localhost by default. So you have two options
Use host network
Add network_mode: host to your service and remove the port mappings. Not an ideal thing to do
Make sure nodejs listens to every IP
Change
command: node index.js --inspect=5858
to
command: node --inspect=0.0.0.0:5858 index.js

Related

Vue CLI run serve always running on localhost

I have a vue.js project created with Vue CLI and npm run serveit always run on localhost.
I want to access from my phone (another IP inside the same network), so I want the serve to run on 0.0.0.0. I tried adding the vue.config.js file and setting the host:
module.exports = {
publicPath: '/',
devServer: {
host: '0.0.0.0',
port: 8080
}
}
Changing the port works fine, but the host override is ignored. This is the output of serve:
App running at:
- Local: http://localhost:8080/
- Network: http://192.168.0.21:8080/
At first I thought it was being ignored, so I tried setting the host to 0.0.0.1 and the output is "correct", so the file is not ignored, only the 0.0.0.0 is being changed to localhost:
App running at:
- Local: http://0.0.0.1:8080/
- Network: http://0.0.0.1:8080/
I saw in some forums that devServer has a public option to set the URL, but if I try setting pubic: 'http://0.0.0.0:8080/' I get an error:
> npm run serve
Debugger attached.
> vue-model-viewer#0.1.0 serve <my project path>
> vue-cli-service serve
Debugger attached.
INFO Starting development server...
ERROR ValidationError: webpack Dev Server Invalid Options
options should NOT have additional properties
ValidationError: webpack Dev Server Invalid Options
options should NOT have additional properties
I need to run the server on 0.0.0.0 so I can test it on my phone.
Any help will be very appreciated.
You shouldn't need to run it on 0.0.0.0 from your local machine to test it on your phone. As long as the port on which it's running is open to external traffic and your phone is connected to your LAN via wifi, you can just put the IP address of your computer and the port # in as the URL.

Node.js WebStorm remote debugging not working (without SSH tunnel)

I'm trying to debug on a live server running a Node.js webserver (Express, TypeScript).
I run the node server with NODE_ENV=development node --inspect=9229 --inspect-brk build/start.js, and it says it's waiting and listening (Debugger listening on ws://127.0.0.1:9229/a61485f2-aef8-4719-901d-4d5ad9d1e6cd).
I set up an SSH tunnel (using this method: https://gist.github.com/pajtai/081e0371e7366c79c0b9), and I set up an "Attach to Node.js/Chrome" debug configuration, with Host: localhost and Port: 9229. Then when I hit the debug button, it connects through the SSH tunnel, and the node.js process runs just fine, stopping and debugging at all my breakpoints.
However, when I don't set up the SSH tunnel, start the node server the same way, and set up an "Attach to Node.js/Chrome" profile with the host as the URL or IP of the server, WebStorm can never connect. There is a little red bubble over the "5: Debug" icon at the bottom saying it can't connect, and sometimes it says "Closed Explicitly". I have opened up port 9229 in the firewall settings for the server (I've tried TCP and UDP).
What am I doing wrong? Please help, anyone!
I'm using Mac OS X 10.15.3 and WebStorm 2019.3.1.
Node binds to localhost by default and thus can't be accessed from outside unless you set up the port forwarding (via ssh tunneling, for example).
You can try changing the command to node --inspect-brk=0.0.0.0:9229 build/start.js - does it help?
Note that Node.js discourages using remote debugging in this way: https://nodejs.org/en/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios. Using SSH tunneling is recommended

Use service workers with Webpack dev-server inside Docker container

I'm trying to use service workers inside a web app using Webpack and Docker.
Everything I made for the moment is working well (service worker, webpack config, worker registration...)
Actually my app is running inside a Docker container, in this container I can start my webpack build to create all my JS files.
But now I would like to be able to use webpack dev-server and HMR with my service worker.
To do that I used https://github.com/oliviertassinari/serviceworker-webpack-plugin that correctly made a reference of my service worker inside the manifest.json
Then when I access through my web browser to my application, every built assets are found except my worker.
I run my dev-server using (I use webpack-encore), inside my docker container
encore dev-server --hot --host 0.0.0.0 --port 8080
To load my assets the browser request them on 0.0.0.0:8080 but my worker is registered from localhost:8000 so the request fail with 404 error because the worker is located 0.0.0.0:8080/sw.js instead localhost:8080/sw.js.
I would know if this was possible to fix this behavior and made my service worker working inside the webpack-dev-server on a docker container.
I know service workers are listening only their scope, in my case localhost:8000/* but the webpack-dev-server is 0.0.0.0:8080.
This is why I asking if this is possible to change this behavior to made it work, and if someone already had this problem.
Thanks
You need to expose port 8000 from your Docker container as well as port 8080. You must expose multiple ports from your Docker container for multiple web services on different ports.
docker run -p 8080:8080 -p 8000:8000
Official documentation

Meteor deployed on server, but browser says site can't be reached

So I've deployed my meteor app, and have it up and running on an instance.
I've used the following environment variables:
MONGO_URL='mongodb://localhost:27017/meteor'
ROOT_URL='http://<my static ip>'
PORT=3000
And I run the program using the following command:
node bundle/main.js
It prints my "Meteor is starting up" that is printed using the console.log command, and then doesn't error out, but when I navigate to http://< my static ip >:3000 in a browser, I get an ERR_CONNECTION_REFUSED result.
My open mongod terminal says it's connecting fine to the MongoDB database.
Does anyone have any ideas on how to start debugging this issue?
Thanks.
In server you don't need to run meteor application on port 3000. You can run it on port 80 if the port is not being used by any other program.
If you are using port 80 make sure port 80 is opened by the network security rules.
If you are using port 3000 or any other port you will have to make sure that port is opened by the network security rules as above. Additionally you will have to mention the IP in your url, like http://<your_ip>:<port>

Windows Virtual Machine getting connection refused to port 9090 webpack dev server

I have a Meteor + Webpack application I'm working on, but I can't get a Windows VM (Win10, IE11, from modern.ie running inside VirtualBox) to access the Webpack dev server assets on port 9090, while the Meteor assets on the same host but on port 3000 work fine for whatever reason. The app is running and being accessed at {host}:3000 but this one bundled JS file is on on the same host at port 9090 and the VM is unable to fetch it.

Categories