You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduces a node wrapper that has special handling to ensure for --inspect-style arguments are only used when running application scripts.
Creates a new nodejs debug helper image that installs this node wrapper.
Towards fixing GoogleContainerTools/skaffold#2170. With this nodejs debug helper image in place, we can then change skaffold debug to 1) use the debug helper image, and 2) set PATH to cause this node-wrapper to be invoked.
NodeJS's node supports a set of --inspect arguments to activate debugging mode using the Chrome DevTools protocol. There are a few variants:
--inspect or --inspect=<port>: launches the app with devtools listening on the given port (or default 9229)
--inspect-brk or --inspect-brk=<port>: launches but immediately stops the app
Many NodeJS applications use NodeJS-based tools like npm and nodemon to launch the app rather than running node directly, and often use several layered together. For example, Skaffold's own nodejs example uses npm invoking nodemon, which then invokes node. Further complicating the issue is that the node images on Docker Hub use docker-entrypoint.sh as a helper script for launching apps. So this example might cause the following sequence:
docker-entrypoint.sh sh -c 'npm run production'
npm run production
node /path/to/npm run production
node src/index.js
This sequence makes it very difficult for skaffold debug to start launch the application for debugging as --inspects are usually intercepted by one of the launch tools.
This PR provides a node wrapper that adds special handling for --inspect-style arguments on the command-line and NODE_OPTIONS environment variable. When executing a node_modules script, any --inspect-like arguments are stripped and put in NODE_DEBUG. When executing an application script (i.e., does not live in node_modules), the NODE_DEBUG value is inlined.
For example, skaffold debug -p dev on nodejs example would do the following:
run docker-entrypoint.sh sh -c 'npm run production' with NODE_OPTIONS=--inspect=9229 but with PATH=/path/to/this/wrapper:$PATH
npm run production (with NODE_OPTIONS=--inspect=9229)
/path/to/this/wrapper/node /path/to/npm run production — npm is recognized as a non-application script and thus the --inspect=9229 is stripped from the NODE_OPTIONS and placed it in NODE_DEBUG
/path/to/actual/node /path/to/npm run production
/path/to/this/wrapper/node src/index.js — src/index.js is recognized as an application script and so NODE_DEBUG is inlined to the node command-line
/path/to/actual/node --inspect=9229 src/index.js
If you have npm/node on your system, you can check it out with something as simple as:
$ cd nodejs/
$ go build -o node .
$ cat package.json
{
"name": "backend",
"version": "1.0.0",
"scripts": {
"production": "node index.js",
"development": "nodemon index.js"
},
"devDependencies": {
"nodemon": "^1.18.4"
}
}
$ cat index.js
console.log("Hello, World!");
$ NODE_OPTIONS=--inspect npm install
Debugger listening on ws://127.0.0.1:9229/16fad1a5-3de7-4813-9512-31f94caa3090
For help, see: https://nodejs.org/en/docs/inspector
...
$ NODE_OPTIONS=--inspect npm run production
Debugger listening on ws://127.0.0.1:9229/4f066a67-b682-4997-b887-8ac77fda1f3b
For help, see: https://nodejs.org/en/docs/inspector
> backend@1.0.0 production /app
> node index.js
Starting inspector on 127.0.0.1:9229 failed: address already in use
...
I think it's hard to understand what you mean in the description. Can you include like a before and after transformation (or something in the description)?
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I was thinking of just treating it as a file name but maybe it's better to skip any processing and just immediately hand off to the unwrapped executable.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR:
--inspect
-style arguments are only used when running application scripts.nodejs
debug helper image that installs thisnode
wrapper.Towards fixing GoogleContainerTools/skaffold#2170. With this
nodejs
debug helper image in place, we can then changeskaffold debug
to 1) use the debug helper image, and 2) set PATH to cause this node-wrapper to be invoked.NodeJS's
node
supports a set of--inspect
arguments to activate debugging mode using the Chrome DevTools protocol. There are a few variants:--inspect
or--inspect=<port>
: launches the app with devtools listening on the given port (or default 9229)--inspect-brk
or--inspect-brk=<port>
: launches but immediately stops the appMany NodeJS applications use NodeJS-based tools like
npm
andnodemon
to launch the app rather than runningnode
directly, and often use several layered together. For example, Skaffold's ownnodejs
example uses npm invoking nodemon, which then invokes node. Further complicating the issue is that thenode
images on Docker Hub usedocker-entrypoint.sh
as a helper script for launching apps. So this example might cause the following sequence:docker-entrypoint.sh sh -c 'npm run production'
npm run production
node /path/to/npm run production
node src/index.js
This sequence makes it very difficult for
skaffold debug
to start launch the application for debugging as--inspect
s are usually intercepted by one of the launch tools.This PR provides a node wrapper that adds special handling for
--inspect
-style arguments on the command-line andNODE_OPTIONS
environment variable. When executing anode_modules
script, any--inspect
-like arguments are stripped and put inNODE_DEBUG
. When executing an application script (i.e., does not live innode_modules
), theNODE_DEBUG
value is inlined.For example,
skaffold debug -p dev
onnodejs
example would do the following:docker-entrypoint.sh sh -c 'npm run production'
withNODE_OPTIONS=--inspect=9229
but withPATH=/path/to/this/wrapper:$PATH
npm run production
(withNODE_OPTIONS=--inspect=9229
)/path/to/this/wrapper/node /path/to/npm run production
—npm
is recognized as a non-application script and thus the--inspect=9229
is stripped from theNODE_OPTIONS
and placed it inNODE_DEBUG
/path/to/actual/node /path/to/npm run production
/path/to/this/wrapper/node src/index.js
—src/index.js
is recognized as an application script and soNODE_DEBUG
is inlined to thenode
command-line/path/to/actual/node --inspect=9229 src/index.js
If you have npm/node on your system, you can check it out with something as simple as:
Whereas with the node-wrapper in place:
To see it in action, we use Skaffold's simple NodeJS project with
npm
and thenode
image: