Vermeiden Sie den Neuaufbau von node_modules in Elastic Beanstalk

Wir haben eine ziemlich einfache node.js-App, aber aufgrund des AWS Elastic Beanstalk-Bereitstellungsmechanismus dauert es etwa 5 Minuten, um eine neue Version (über git aws.push) auch nach einem Commit einer einzelnen Datei.

Das heißt, das Commit selbst (und das Hochladen) ist schnell (nur 1 Datei zum Pushen), aber dann holt Elastic Beanstalk das ganze Paket von S3, entpackt es und führt es aus npm install, wodurch node-gyp einige Module kompiliert. Nach der Installation/Baufertigstellung löscht Elastic Beanstalk /var/app/current und ersetzt sie durch die neue App-Version.

Unnötig zu erwähnen, dass ein ständiger Neuaufbau von node_modules nicht erforderlich ist, und ein Neuaufbau, der auf meinem alten Macbook Air 30 Sekunden dauert, dauert auf einer ec2.micro-Instanz> 5 Minuten, was keinen Spaß macht.

Ich sehe hier zwei Ansätze:

1. zwicken /opt/containerfiles/ebnode.py und spielen Sie mit dem Speicherort von node_modules, um zu vermeiden, dass es bei der Bereitstellung entfernt und neu erstellt wird.
2. Richten Sie ein Git-Repo auf der Elastic Beanstalk EC2-Instance ein und schreiben Sie die Bereitstellungsprozedur grundsätzlich selbst um, sodass /var/app/current Pushes und Runs empfängt npm install nur bei Bedarf (wodurch Elastic Beanstalk wie OpsWorks aussieht..)

Beiden Optionen mangelt es an Anmut und sie sind anfällig für Probleme, wenn Amazon seine Elastic Beanstalk-Hooks und -Architektur aktualisiert.

Vielleicht hat jemand eine bessere Idee, wie man den ständigen Neuaufbau von node_modules vermeiden kann, die bereits im App-Verzeichnis vorhanden sind? Danke schön.

Danke Kirill, es war wirklich hilfreich!

Ich teile nur meine Konfigurationsdatei für Leute, die nur die einfache Lösung für das suchen npm install. Diese Datei muss im abgelegt werden .ebextensions Ordner des Projekts, es ist leichter, da es nicht die letzte Version der Knoteninstallation enthält, und einsatzbereit.

Es überprüft auch dynamisch die installierte Knotenversion, sodass sie nicht in die Datei env.vars aufgenommen werden muss.

.ebextensions/00_deploy_npm.config

files:
  "/opt/elasticbeanstalk/env.vars" :
    mode: "000775"
    owner: root
    group: users
    content: |
      export NPM_CONFIG_LOGLEVEL=error
      export NODE_PATH=`ls -td /opt/elasticbeanstalk/node-install/node-* | head -1`/bin
  "/opt/elasticbeanstalk/hooks/appdeploy/pre/50npm.sh" :
    mode: "000775"
    owner: root
    group: users
    content: |
      #!/bin/bash
      . /opt/elasticbeanstalk/env.vars
      function error_exit
      {
        eventHelper.py --msg "$1" --severity ERROR
        exit $2
      }

      #install not-installed yet app node_modules
      if [ ! -d "/var/node_modules" ]; then
        mkdir /var/node_modules ;
      fi
      if [ -d /tmp/deployment/application ]; then
        ln -s /var/node_modules /tmp/deployment/application/
      fi

      OUT=$([ -d "/tmp/deployment/application" ] && cd /tmp/deployment/application && $NODE_PATH/npm install 2>&1) || error_exit "Failed to run npm install.  $OUT" $?
      echo $OUT
  "/opt/elasticbeanstalk/hooks/configdeploy/pre/50npm.sh" :
    mode: "000666"
    owner: root
    group: users
    content: |
       #no need to run npm install during configdeploy

25/01/13 HINWEIS: Skripte wurden aktualisiert, um ein npm -g-Versions-Upgrade auszuführen (nur einmal, beim ersten Rollout oder Neuaufbau der Instanz) und um NPM-Vorgänge während der EB-Konfigurationsänderung zu vermeiden (wenn App-Verzeichnis nicht vorhanden ist, um Fehler zu vermeiden und um Beschleunigung von Konfigurationsaktualisierungen).

Okay, Elastic Beanstalk verhält sich bei den neuesten node.js-Builds (einschließlich der vermutlich unterstützten v.0.10.10) zwielichtig, also habe ich mich entschieden, weiterzumachen und EB zu optimieren, um Folgendes zu tun:

1. um JEDE node.js-Version gemäß Ihrer env.config zu installieren (einschließlich der neuesten, die noch nicht von AWS EB unterstützt werden)
2. um zu vermeiden, dass vorhandene Knotenmodule neu erstellt werden, einschließlich des In-App-Verzeichnisses node_modules
3. um node.js global zu installieren (und auch jedes gewünschte Modul).

Grundsätzlich verwende ich env.config, um deploy&config-Hooks durch angepasste zu ersetzen (siehe unten). Außerdem fehlen in einem standardmäßigen EB-Container-Setup einige Umgebungsvariablen ($HOME zum Beispiel) und node-gyp schlägt manchmal während des Neuaufbaus fehl (ich brauchte 2 Stunden, um libxmljs zu googeln und neu zu installieren, um dies zu beheben).

Unten sind die Dateien, die zusammen mit Ihrem Build enthalten sein müssen. Sie können sie über env.config als Inline-Code oder über einfügen source: URL (wie in diesem Beispiel)

env.vars (gewünschte Node-Version & Arch sind hier und in env.config enthalten, siehe unten)

export HOME=/root
export NPM_CONFIG_LOGLEVEL=error
export NODE_VER=0.10.24
export ARCH=x86
export PATH="$PATH:/opt/elasticbeanstalk/node-install/node-v$NODE_VER-linux-$ARCH/bin/:/root/.npm"

40install_node.sh (Gewünschte node.js-Version abrufen und entpacken, globale Symlinks erstellen, globale npm-Version aktualisieren)

#!/bin/bash
#source env variables including node version
. /opt/elasticbeanstalk/env.vars

function error_exit
{
  eventHelper.py --msg "$1" --severity ERROR
  exit $2
}

#UNCOMMENT to update npm, otherwise will be updated on instance init or rebuild
#rm -f /opt/elasticbeanstalk/node-install/npm_updated

#download and extract desired node.js version
OUT=$( [ ! -d "/opt/elasticbeanstalk/node-install" ] && mkdir /opt/elasticbeanstalk/node-install ; cd /opt/elasticbeanstalk/node-install/ && wget -nc http://nodejs.org/dist/v$NODE_VER/node-v$NODE_VER-linux-$ARCH.tar.gz && tar --skip-old-files -xzpf node-v$NODE_VER-linux-$ARCH.tar.gz) || error_exit "Failed to UPDATE node version. $OUT" $?.
echo $OUT

#make sure node binaries can be found globally
if [ ! -L /usr/bin/node ]; then
  ln -s /opt/elasticbeanstalk/node-install/node-v$NODE_VER-linux-$ARCH/bin/node /usr/bin/node
fi

if [ ! -L /usr/bin/npm ]; then
ln -s /opt/elasticbeanstalk/node-install/node-v$NODE_VER-linux-$ARCH/bin/npm /usr/bin/npm
fi

if [ ! -f "/opt/elasticbeanstalk/node-install/npm_updated" ]; then
/opt/elasticbeanstalk/node-install/node-v$NODE_VER-linux-$ARCH/bin/ && /opt/elasticbeanstalk/node-install/node-v$NODE_VER-linux-$ARCH/bin/npm update npm -g
touch /opt/elasticbeanstalk/node-install/npm_updated
echo "YAY! Updated global NPM version to `npm -v`"
else
  echo "Skipping NPM -g version update. To update, please uncomment 40install_node.sh:12"
fi

50npm.sh (erstellt /var/node_modules, verknüpft es symbolisch mit dem App-Verzeichnis und führt npm install aus. Sie können jedes Modul von hier aus global installieren, sie landen in /root/.npm)

#!/bin/bash
. /opt/elasticbeanstalk/env.vars
function error_exit
{
  eventHelper.py --msg "$1" --severity ERROR
  exit $2
}

#install not-installed yet app node_modules
if [ ! -d "/var/node_modules" ]; then
  mkdir /var/node_modules ;
fi
if [ -d /tmp/deployment/application ]; then
  ln -s /var/node_modules /tmp/deployment/application/
fi

OUT=$([ -d "/tmp/deployment/application" ] && cd /tmp/deployment/application && /opt/elasticbeanstalk/node-install/node-v$NODE_VER-linux-$ARCH/bin/npm install 2>&1) || error_exit "Failed to run npm install.  $OUT" $?
echo $OUT

env.config (Notieren Sie auch hier die Knotenversion, und geben Sie sicherheitshalber auch die gewünschte Knotenversion in env config in der AWS-Konsole ein. Ich bin mir nicht sicher, welche dieser Einstellungen Vorrang haben wird.)

packages:
  yum:
    git: []
    gcc: []
    make: []
    openssl-devel: []

option_settings:
  - option_name: NODE_ENV
    value: production
  - option_name: RDS_HOSTNAME
    value: fill_me_in
  - option_name: RDS_PASSWORD
    value: fill_me_in
  - option_name: RDS_USERNAME
    value: fill_me_in
  - namespace: aws:elasticbeanstalk:container:nodejs
    option_name: NodeVersion
    value: 0.10.24

files:
  "/opt/elasticbeanstalk/env.vars" :
    mode: "000775"
    owner: root
    group: users
    source: https://dl.dropbox.com/....
  "/opt/elasticbeanstalk/hooks/configdeploy/pre/40install_node.sh" :
    mode: "000775"
    owner: root
    group: users
    source: https://raw.github.com/....
  "/opt/elasticbeanstalk/hooks/appdeploy/pre/50npm.sh" :
    mode: "000775"
    owner: root
    group: users
    source: https://raw.github.com/....
  "/opt/elasticbeanstalk/hooks/configdeploy/pre/50npm.sh" :
    mode: "000666"
    owner: root
    group: users
    content: |
       #no need to run npm install during configdeploy
  "/opt/elasticbeanstalk/hooks/appdeploy/pre/40install_node.sh" :
    mode: "000775"
    owner: root
    group: users
    source: https://raw.github.com/....

Da haben Sie es: Auf der Instanz t1.micro dauert die Bereitstellung jetzt 20–30 Sekunden statt 10–15 Minuten! Wenn Sie 10 Mal am Tag bereitstellen, sparen Sie mit dieser Optimierung 3 (drei) Wochen im Jahr. Hoffe, es hilft und besonderen Dank an die Mitarbeiter von AWS EB für mein verlorenes Wochenende 🙂

Es gibt ein npm-Paket, das das standardmäßige EB-Verhalten überschreibt npm install Befehl durch Abschneiden der folgenden Dateien:

• /opt/elasticbeanstalk/hooks/appdeploy/pre/50npm.sh
• /opt/elasticbeanstalk/hooks/configdeploy/pre/50npm.sh

https://www.npmjs.com/package/eb-disable-npm

Könnte besser sein, als nur das Skript von SO zu kopieren, da dieses Paket gepflegt wird und wahrscheinlich aktualisiert wird, wenn sich das EB-Verhalten ändert.

Ich habe dafür eine schnelle Lösung gefunden. Ich habe die Build-Skripte durchgesehen, die Amazon verwendet, und sie werden nur ausgeführt npm install wenn package.json vorhanden ist. Nach Ihrer ersten Bereitstellung können Sie es also ändern in _package.json und npm install läuft nicht mehr! Es ist nicht die beste Lösung, aber es ist eine schnelle Lösung, wenn Sie eine brauchen!

Ich hatte mehr als 10 Minuten Builds, als ich bereitstellen würde. Die Lösung war viel einfacher, als andere sich ausgedacht haben … Checken Sie einfach node_modules in git! Sehen http://www.futurealoof.com/posts/nodemodules-in-git.html für die begründung