Установка AWS EC2 npm внезапно очень медленная

В моей среде ElasticBeanstalk всегда (в течение многих лет) требовалось ~ 5 минут для развертывания моего приложения Node.js и для изменения состояния экземпляра с «Ожидание» на «ОК» на вкладке EB Health.

С 14 мая развертывание приложения занимает примерно 15 минут без вмешательства в приложение, инфраструктуру, репозиторий приложений, среду EB или образ Linux EC2. То же самое произошло в рабочей среде и среде разработки, обе они являются отдельными средами EB, развертывающими одно и то же приложение.

Глядя на /var/log/eb-activity.log, я вижу, что эти 15 минут тратятся на шаг:

[Application deployment <APPID>/StartupStage0/AppDeployPreHook/50npm.sh] : Starting activity...

Сам скрипт работает только:

/opt/elasticbeanstalk/containerfiles/ebnode.py --action npm-install

Этот скрипт просто выполняет проверку файлов и составление пути, а затем запускается:

npm --production install

Для сравнения, я очистил все кешированные файлы и выполнил ту же команду локально, что заняло около 11 минут:

rm -rf node_modules
node cache clean -f
npm --production install

Я снова запустил команду с помощью --loglevel silly, и она показывает, что в package.json есть одна зависимость, которая вытягивается не из реестра npm, а напрямую из GitHub, указывая на метку:

npm sill pacote Retrying git command: ls-remote -h -t git://github.com/<org>/<repo>.git attempt # 2
npm sill pacote Retrying git command: ls-remote -h -t git://github.com/<org>/<repo>.git attempt # 3
npm verb prepareGitDep github:<org>/<repo>#<label>: installing devDeps and running prepare script.

Тайм-аут для каждой из этих git ls-remote команд составляет около 1 минуты, а затем кажется, что установка devDependencies запускает prepare скрипт еще на 5 минут. Я не уверен, что это также происходит на экземпляре EC2, но это единственный намек, который я нашел.

3 команды git ls-remote с истекшим временем ожидания и скрипт prepare составляют ~8 минут. Поэтому, если это что-то, что раньше не выполнялось, это может объяснить более длительное время развертывания. Но тогда почему развертывание вдруг стало отличаться от того, что было в течение многих лет?


Я наткнулся на этот GitHub Сообщение блога:

March 15, 2022

Changes made permanent. We’ll permanently stop accepting DSA keys. RSA keys uploaded after the cut-off point above will work only with SHA-2 signatures (but again, RSA keys uploaded before this date will continue to work with SHA-1). The deprecated MACs, ciphers, and unencrypted Git protocol will be permanently disabled.

Так GitHub перестал принимать запросы по протоколу git://. Возможно, это причина более длительного времени развертывания, и тайм-аут также происходит в EC2. Но это изменение уже было сделано постоянным 15 марта (ровно 2 месяца назад), так почему проблема появилась только сейчас.

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
0
98
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

У нас было такое же загадочное поведение в нашей кодовой базе, начиная с 13 мая. Я понятия не имею, почему зависимости GitHub до сих пор не столкнулись с этими проблемами, но, согласно сообщению в блоге, которым вы поделились, это кажется постоянным.

На эту тему был создан Проблема с GitHub, и сообщество предложило различные способы решения проблемы.

Одно такое предложение:

Solved by replacing github protocol with https at package-lock.json & package.json

Другой пользователь предложил:

... we found out that updating npm to version 7.16.0 (at least, that was our go to version for other reasons) solved the issue

Для нас мы выбрали последнее и начали использовать NPM версии 7 (в частности, 7.24.2). Это потребовало от нас обновить наш файл package-lock.json до версии 2, что принесло с собой целый ряд других проблем, но, похоже, это сработало для нас.

Спасибо за подтверждение, так как это, кажется, доступный в настоящее время ответ, я приму его. Мы перешли на git+https, и время сократилось с 14 до 8 минут, что по-прежнему составляет +100% по сравнению с исходным <5 минут до 13 мая.

Manuel 17.05.2022 20:38

Другие вопросы по теме