Comment déboguer l'application Nodejs s'exécutant dans le conteneur Docker via Google Cloud
J'ai trouvé que Google fournit des instructions sur comment exécuter Nodejs sur un environnement d'exécution personnalisé . Tout semble aller pour le mieux et je parviens à démarrer mon application Nodejs sur une machine locale exécutant gcloud preview app run ..
Comme je peux le constater, il probablement crée un conteneur Docker et exécute le programme Nodejs. Je dis "probablement"} _, car c’est ma première expérience avec Docker, mais j’ai plus de 2 ans d’expérience dans le développement de Nodejs.
Donc ma question est comment déboguer (avec les arrêts de points d'arrêt) mon programme Nodejs lorsqu'il est exécuté dans le conteneur Docker? À l'aide des outils de développement Chrome ou comment configurer la configuration de débogage Webstorm pour qu'elle s'arrête sur les points d'arrêt. Est-il possible de configurer Docker sur la façon dont il démarre le nœud ou même de démarrer Docker via gcloud dans Webstorm pour s'assurer que le débogage fonctionne? Toute aide ou clarification est appréciée.
Veuillez ne pas fournir de réponses sur la façon de déboguer l'application Nodejs en dehors du conteneur Docker - je sais très bien le faire.
Je suis désolé, mais je ne connais qu'une solution avec node-inspector, j'espère que cela pourra vous aider:
- Vous pouvez installer le paquet node-inspector dans votre conteneur: https://github.com/node-inspector/node-inspector
- Mappez le port 8080 de votre conteneur sur votre hôte (exécutez votre conteneur avec le paramètre -p 8080: 8080)
Exécutez ceci dans votre conteneur (avec docker exec ou docker-enter)
node-debug --web-Host 0.0.0.0 votreScript.js
Il existe un moyen plus simple, du moins à partir de Docker 0.11 ou quelque chose du genre.
Exécutez, sur votre ordinateur de développement uniquement, Docker avec --net = "Host". Cela permet à Docker de se lier directement à l'hôte local et de ne pas créer de carte réseau passerelle. Par conséquent, la machine Docker s'exécute comme tout autre processus de votre ordinateur et ouvre les ports dont elle a besoin sur l'interface locale.
De cette façon, vous pouvez vous connecter à votre port de débogage comme si le nœud ne fonctionnait pas dans Docker.
Plus de documentation ici: https://docs.docker.com/reference/run/
Avant Docker 0.11, vous disposez de deux méthodes de débogage, à part l’utilisation de node-inspector:
- Exécutez sshd dans votre ordinateur Docker et configurez un tunnel ssh, comme si vous deviez déboguer sur une machine distante.
- "Mess up" avec ip-tables pour "rétablir" le mappage Docker des ports locaux. Il y a quelque chose à ce sujet ici Exposer un port sur un conteneur Docker réel .
Par défaut, le débogueur de noeud n'écoute que les connexions du même hôte (127.0.0.1). Mais dans Docker, vous devez accepter les connexions de n’importe quel hôte (0.0.0.0):
# inside Docker
node --inspect=0.0.0.0:9229 myapp.js
Vous devez également exposer le port de débogage (9229). Ensuite, l'application doit être automatiquement détectée et répertoriée comme cible distante dans chrome://inspect/#devices sous Chrome (testé dans Chrome 67).
Exemple
Voici un exemple minimal. Il exécute une application JavaScript simple dans Docker et montre comment y attacher le débogueur Chrome:
$ cat example.js
setInterval(() => console.log('Hallo world'), 1000);
$ cat Dockerfile
FROM node
COPY example.js /
CMD node --inspect=0.0.0.0:9229 /example.js
Courir avec:
$ docker build . -t myapp && docker run -p 9229:9229 --rm -it myapp
Sending build context to Docker daemon 3.072kB
Step 1/3 : FROM node
---> aa3e171e4e95
Step 2/3 : COPY example.js /
---> Using cache
---> 3ef6c0311da2
Step 3/3 : CMD node --inspect=0.0.0.0:9229 /example.js
---> Using cache
---> e760739c2802
Successfully built e760739c2802
Successfully tagged debug-docker:latest
Debugger listening on ws://0.0.0.0:9229/4177f6cc-85e4-44c6-9ba3-5d8e28e1b124
For help see https://nodejs.org/en/docs/inspector
Hallo world
Hallo world
Hallo world
...
Ouvrez Chrome et accédez à chrome://inspect/#devices. Il devrait, peu après le démarrage de l’application, la détecter et la lister.
Dépannage
docker inspect est utile pour le débogage des problèmes de réseau Docker:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ae83d50e24c8 debug-docker "/bin/sh -c 'node --…" 2 minutes ago Up 2 minutes 0.0.0.0:9229->9229/tcp blissful_sammet
$ docker inspect ae83d50e24c8
...
"NetworkSettings": {
"Bridge": "",
"SandboxID": "682d3ac98b63d4077c5d66a516666b6615327cbea0de8b0a7a2d8caf5995b0ae",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {
"9229/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "9229"
}
]
},
...
Si vous voulez voir les requêtes envoyées entre Docker et Chrome, ngrep peut vous aider:
$ Sudo ngrep -d any port 9229
interface: any
filter: (ip or ip6) and ( port 9229 )
############################
T ::1:38366 -> ::1:9229 [AP]
GET /json/version HTTP/1.1..Host: [::1]:9229....
#####
T ::1:38368 -> ::1:9229 [AP]
GET /json HTTP/1.1..Host: [::1]:9229....
##############
T 172.17.0.1:56782 -> 172.17.0.2:9229 [AP]
GET /json HTTP/1.1..Host: [::1]:9229....
#
T 172.17.0.1:56782 -> 172.17.0.2:9229 [AP]
GET /json HTTP/1.1..Host: [::1]:9229....
###
T 172.17.0.1:56784 -> 172.17.0.2:9229 [AP]
GET /json/version HTTP/1.1..Host: [::1]:9229....
#
T 172.17.0.1:56784 -> 172.17.0.2:9229 [AP]
GET /json/version HTTP/1.1..Host: [::1]:9229....
###
T 172.17.0.2:9229 -> 172.17.0.1:56782 [AP]
HTTP/1.0 200 OK..Content-Type: application/json; charset=UTF-8..Cache-Contro
l: no-cache..Content-Length: 465....
#
T 172.17.0.2:9229 -> 172.17.0.1:56782 [AP]
HTTP/1.0 200 OK..Content-Type: application/json; charset=UTF-8..Cache-Contro
l: no-cache..Content-Length: 465....
###
T 172.17.0.2:9229 -> 172.17.0.1:56782 [AP]
[ {. "description": "node.js instance",. "devtoolsFrontendUrl": "chrome-de
vtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=[::
1]:9229/f29686f9-e92d-45f4-b7a2-f198ebfc7a8e",. "faviconUrl": "https://node
js.org/static/favicon.ico",. "id": "f29686f9-e92d-45f4-b7a2-f198ebfc7a8e",.
"title": "/example.js",. "type": "node",. "url": "file:///example.js",.
"webSocketDebuggerUrl": "ws://[::1]:9229/f29686f9-e92d-45f4-b7a2-f198ebfc7a
8e".} ]..
#
Si vous utilisez un réseau de pontage pour vos conteneurs et que vous ne souhaitez pas installer nœud-inspecteur dans le même conteneur que votre processus de nœud, j'ai trouvé cette solution pratique:
- Dans le conteneur node.js principal, mappez le port 5858 sur l'hôte.
- Exécuter le processus de noeud principal avec le débogage activé
- Utilisez un conteneur séparé pour exécuter node-inspector
- Utiliser la mise en réseau de l'hôte pour le conteneur d'inspecteur de nœud
Cela dit, le conteneur d’inspecteur de nœud se connectera à localhost: 5858 qui sera ensuite mappé sur le conteneur de nœud principal.
Si vous utilisez ceci sur une machine virtuelle, je recommanderais alors:
- Assurez-vous que le port 5900 n'est pas exposé publiquement (par exemple, par le pare-feu).
- Assurez-vous que le port de l'inspecteur de noeud (par exemple 8080) us est exposé publiquement pour pouvoir vous y connecter.
J'ai écrit quelques détails à ce sujet ici: https://keylocation.sg/our-tech/debugging-nodejs-in-docker-using-node-inspector
Autant que je sache, vous devez fournir le paramètre --debug-brk = to node au démarrage - cela permettra le débogage. Ensuite, accédez au port spécifié sur votre conteneur Docker. Vous devez probablement l'exposer ou le tunnel (en utilisant ssh).
Après cela, pointez le débogueur distant Webstorm sur le port spécifié et définissez-le.