J'ai une application de nœud pré-construite qui ne doit pas tenter d'accéder au réseau si npm install est exécuté avant le démarrage - l'intention est que tout soit déjà présent dans le répertoire node_modules. Il est déployé dans un environnement de fonderie cloud.

Il ne s'agit pas d'un problème de proxy - il ne doit y avoir aucune tentative d'accès à l'URL du registre lors de la mise en place de l'application Cloud Foundry. Je cherche des idées pourquoi il essaie de faire cela.

Lorsque cette application est déployée sur Cloud Foundry, même si elle détecte la présence du répertoire node_modules lors du transfert, elle essaie toujours de récupérer les modules de dépendance de base (comme @node/types) déjà présents dans node_modules, et bien sûr, il expire en essayant d'atteindre un registre qui n'est pas autorisé dans ces environnements. Il existe des centaines d'autres dépendances qu'il n'essaie pas de récupérer, mais pour une raison quelconque, il pense qu'il a besoin de certains modules. Par exemple:

   2021-03-17T16:29:57.71-0700 [STG/0] OUT        Installing any new modules (package.json + package-lock.json)
   2021-03-17T16:32:31.78-0700 [STG/0] OUT npm ERR! code ECONNREFUSED
   2021-03-17T16:32:31.78-0700 [STG/0] OUT npm ERR! errno ECONNREFUSED
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! FetchError: request to https://<registry-fqdn>/@types%2flong failed, reason: connect ECONNREFUSED 10.x.x.x:443
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.<anonymous> (/tmp/contents784086672/deps/0/node/lib/node_modules/npm/node_modules/node-fetch-npm/src/index.js:68:14)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.emit (events.js:315:20)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.socketErrorListener (_http_client.js:469:9)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.emit (events.js:315:20)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorNT (internal/streams/destroy.js:106:8)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorCloseNT (internal/streams/destroy.js:74:3)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at processTicksAndRejections (internal/process/task_queues.js:80:21)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!  FetchError: request to https://<registry-fqdn>/@types%2flong failed, reason: connect ECONNREFUSED 10.x.x.x:443
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.<anonymous> (/tmp/contents784086672/deps/0/node/lib/node_modules/npm/node_modules/node-fetch-npm/src/index.js:68:14)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.emit (events.js:315:20)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.socketErrorListener (_http_client.js:469:9)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.emit (events.js:315:20)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorNT (internal/streams/destroy.js:106:8)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorCloseNT (internal/streams/destroy.js:74:3)
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at processTicksAndRejections (internal/process/task_queues.js:80:21) {
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   type: 'system',
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   errno: 'ECONNREFUSED',
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   code: 'ECONNREFUSED',
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   parent: 'app'
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! }
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! If you are behind a proxy, please make sure that the
   2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! 'proxy' config is set properly.  See: 'npm help config'
   2021-03-17T16:39:12.54-0700 [STG/0] OUT npm ERR! A complete log of this run can be found in:
   2021-03-17T16:39:12.54-0700 [STG/0] OUT npm ERR!     /home/vcap/.npm/_logs/2021-03-17T23_32_31_800Z-debug.log
   2021-03-17T16:39:12.56-0700 [STG/0] OUT        **ERROR** Unable to build dependencies: exit status 1
   2021-03-17T16:39:13.07-0700 [STG/0] ERR Failed to compile droplet: Failed to run all supply scripts: exit status 14
   2021-03-17T16:39:13.09-0700 [STG/0] OUT Exit status 223
   2021-03-17T16:39:13.28-0700 [STG/0] OUT Cell 5cee670a-6f6c-4510-a274-5584f197038c stopping instance 59dda306-be2f-4d08-830c-77c08ffab3f5
   2021-03-17T16:39:13.28-0700 [STG/0] OUT Cell 5cee670a-6f6c-4510-a274-5584f197038c destroying container for instance 59dda306-be2f-4d08-830c-77c08ffab3f5
   2021-03-17T16:39:13.76-0700 [API/1] ERR Failed to stage build: staging failed

Des idées?

Modifier 1 Autres faits :

  1. l'application est poussée en tant qu'archive zip
  2. le système de fichiers zip inclut le répertoire node_modules résultant d'une commande npm install exécutée lors de la "build" pour construire le zip
  3. le système de fichiers zip comprend package-lock.json (depuis la source)
  4. il n'y a aucun fichier .cfignore dans l'archive zip
  5. le zip 'build' se déroulait sur une machine Windows et n'avait pas ce problème auparavant lorsqu'il était ensuite poussé vers cf
  6. le zip 'build' a récemment migré vers un coureur gitlab ci à partir d'un cluster k8s, qui peut utiliser une image dérivée de centos
  7. la version du pack de construction est 1.7.32
  8. la version du nœud (14.14.0) sur la machine de build correspond à la version utilisée par le buildpack, mais pas la version npm (7.6.1) (buildpack utilise 6.14.8)
  9. changer l'image de construction où le zip est assemblé à Ubuntu Bionic Beaver (18.04.4 LTS) ne fait aucune différence
0
Hoobajoob 18 mars 2021 à 02:58

2 réponses

Meilleure réponse

Ce problème s'est avéré être causé par des versions de npm incompatibles sur la machine sur laquelle le fichier package-lock.json est généré, la machine sur laquelle le répertoire node_modules est rempli pour être inclus dans la distribution zip (npm v7.x), et ce que le pack de construction de la fonderie cloud utilise (npm v6.x).

Changer les machines de développement et de construction pour utiliser npm v6.x pour générer à la fois le fichier package-lock.json et remplir le répertoire node_modules a abouti à une application nodejs vendue avec succès.

0
Hoobajoob 18 mars 2021 à 21:49

Je ne suis pas sûr à 100% que cela résoudra le problème, mais voici ce que j'ai vu fréquemment des gens essayer de vendre des dépendances Node.js :

Tout d'abord, consultez les instructions de la documentation : https://docs.cloudfoundry.org /buildpacks/node/index.html#vendoring

  1. Exécutez npm install (vous l'avez fait)
  2. Assurez-vous d'avoir un fichier package-lock.json (vous l'avez probablement). Cela verrouille les versions à utiliser et devrait garantir que ce qui est dans node_modules/ correspond à ce qui sera installé. Si vous ne l'avez pas, vous verrez la sortie Warning: package-lock.json not found. du buildpack.
  3. Assurez-vous de pousser vers le haut package.json, package-lock.json et le répertoire complet node_modules/, ainsi que tout le code de votre application.

Ceux-ci ne sont pas documentés, mais quelques conseils tirés de ce que j'ai observé en travaillant avec d'autres à ce sujet :

  1. Assurez-vous de ne pas avoir de fichier .cfignore, car cela pourrait accidentellement empêcher node_modules/ d'être poussé. Vous pouvez généralement savoir si node_modules/ n'est pas poussé, car le nombre de fichiers et la taille de ce qui est poussé seront beaucoup, beaucoup plus importants avec cela. Vous verrez également le message It is recommended to vendor the application's Node.js dependencies si le répertoire node_modules/ n'existe pas.

  2. Lorsque vous exécutez npm install localement, vous devez l'exécuter dans une machine virtuelle ou un conteneur Ubuntu Bionic. En effet, NPM installe souvent des modules qui nécessitent du code natif. Il gérera automatiquement cela, mais le contenu de node_modules/ est spécifique au système d'exploitation et à l'architecture sur lesquels vous exécutez npm install. Ainsi, si vous exécutez npm install sur un système d'exploitation non Ubuntu Bionic (par exemple Windows ou MacOS), il compilera le code natif pour votre machine locale. Lorsque vous appuyez dessus, cela ne correspondra pas et NPM essaiera de réinstaller le package, ce qui peut déclencher l'accès à Internet.

  3. Assurez-vous que vous utilisez la dernière version du pack de construction Node.js et de Node.js dans la mesure du possible. Il est toujours utile d'avoir le dernier code avec des corrections de bogues.

  4. NODE_ENV=production sera défini par le buildpack, ce qui peut parfois entraîner une différence de comportement. Il ignore également l'installation des dépendances de développement. Ce n'est probablement pas le problème ici, mais cela mérite d'être mentionné car cela fait trébucher certaines personnes.

2
Daniel Mikusa 18 mars 2021 à 12:56