Tenemos una aplicación node.js bastante simple, pero debido al mecanismo de implementación de AWS Elastic Beanstalk, demora unos 5 minutos implementar una nueva versión (a través degit aws.push) incluso después de un solo archivo de confirmación.

Es decir. la confirmación en sí misma (y la carga) es rápida (solo 1 archivo para insertar), pero luego Elastic Beanstalk recupera el paquete completo de S3, lo descomprime y ejecutanpm install, lo que hace que node-gyp compile algunos módulos. Tras la instalación / finalización del edificio, toallitas Elastic Beanstalk/var/app/current y lo reemplaza con la nueva versión de la aplicación.

No hace falta decir que no es necesaria la reconstrucción constante de node_modules, y la reconstrucción que toma 30 segundos en mi viejo Macbook Air, toma más de 5 minutos en una instancia de ec2.micro, no es divertido.

Veo dos enfoques aquí:

retocar/opt/containerfiles/ebnode.py y jugar con la ubicación de node_modules para evitar su eliminación y reconstrucción en el momento de la implementación.configure un repositorio git en la instancia de Elastic Beanstalk EC2 y básicamente reescribamos el procedimiento de implementación, por lo que / var / app / current recibe impulsos y se ejecutanpm install solo cuando es necesario (lo que hace que Elastic Beanstalk se parezca a OpsWorks ...)

Ambas opciones carecen de gracia y son propensas a problemas cuando Amazon actualiza sus enganches y arquitectura de Elastic Beanstalk.

Tal vez alguien tenga una mejor idea de cómo evitar la reconstrucción constante de los node_modules que ya están presentes en el directorio de la aplicación. Gracias.