Ускорить развертывание на Heroku [дубликат]

этот вопрос уже есть ответ здесь:

Heroku отлично. Но каждый раз, когда я развертываю, Heroku, похоже, любит перезагружать и перестраивать все пакеты. С socket.io и mailparser это занимает около 3 минут.

есть способ ускорить процесс развертывания? Есть ли способ сказать Heroku, что он может кэшировать эти элементы? Или я могу загрузить готовые node_modules?

6 ответов


похоже, что на сегодняшний день Heroku, наконец, кэширует !

- - - - - > удаление 6 совпадающих файлов .узоры slugignore.

-----> узел.приложение на JS обнаружено

- - - - - > запрошенный диапазон узлов: 0.10.x

- - - - - > разрешенная версия узла: 0.10.22

-----> загрузка и установка узла

-----> восстановление node_modules из кэша

-----> установка зависимостей

-----> обрезка неиспользуемых зависимостей

-----> кэширование каталога node_modules для будущих сборок

- - - - - > очистка артефактов node-gyp и npm

время сборки для меня сейчас как 3 секунды.


одна вещь, которую я сделал, чтобы ускорить процесс, это добавить .slugignore файл в основную папку и добавить все файлы и папки, которые я не хотел запускать приложение.

образец содержание .slugignore файл:
работа
макеты
*.psd
*.формат PDF


У меня был тот же вопрос (см. избегайте обновления npm после каждого развертывания на Heroku).

Heroku заставляет загружать / строить / и т. д. последовательность, потому что им нужно запустить приложение с "чистым листом": очистить предыдущие неотделенные файлы, когда они перемещают приложение на другой сервер, когда вы назначаете новые веб-dynos и т. д.

проблема явно связана с собственными пакетами и перекомпиляцией. Для всех пакетов JS-only я фиксирую их с помощью своего проекта и удаляю их из пакет.формат JSON. Он выигрывает несколько секунд, но не так много.

Я определенно должен иметь возможность предварительно компилировать и фиксировать собственные модули (я успешно запускаю wkhtml2pdf на Heroku, например, с двоичным кодом, скомпилированным для linux-amd64), если вы получаете доступ к Linux box (или VM) с той же конфигурацией - на сегодняшний день,Linux [...] 2.6.32-350-ec2 #57-Ubuntu SMP [...] x86_64 GNU/Linux.

хотя я бы не рекомендовал его в качестве окончательного решения, так как он, вероятно, сломается в один прекрасный день - мне не кажется, что heroku гарантирует платформа, на которой работает приложение.


я сталкиваюсь с той же проблемой.

некоторые обсуждения здесь о кэшировании node_modules папка:https://github.com/heroku/heroku-buildpack-nodejs/pull/37

другая идея:https://github.com/heroku/heroku-buildpack-nodejs/issues/25


я думаю о нескольких решениях прямо сейчас.

  1. Регистрация node_modules в отдельной ветке: основной узел.Яш разработчики рекомендуют проверять в node_modules папка в систему управления версиями (для приложений, а не для библиотек). Мне это не нравится. Способ обойти это, хотя может иметь отдельный production ветка с другой .gitignore файл, который не игнорирует node_modules. Когда вы хотите развернуть, просто перебазировать из своего хозяина и node_modules будет зарегистрирован. По крайней мере, это сохраняет вашу главную ветвь свободной от зависимостей.

  2. добавить preinstall скрипт package.json в скачать сжатую зависимость zip: вы также можете добавить предварительный крючок Git, чтобы связать свои зависимости и загрузить их в S3. Это, вероятно,будет слишком медленно.

  3. изменить heroku-buildpack-nodejs: интегрируйте выдающий запрос тяги с node_modules кэширование:

    heroku config:set BUILDPACK_URL=https://github.com/opdemand/buildpack-nodejs.git


кажется, что недавно был прогресс в в Heroku-buildpack-пакет-nodejs.

как только запрос на вытягивание объединен, вы можете добавить

heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs

на переменные среды heroku.

на данный момент, раздвоенный репозиторий Дэвида доллара доступен по адресу

https://github.com/ddollar/heroku-buildpack-nodejs

С этим как ваш BUILDPACK_URL он должен кэшировать модули npm. Я попробовал это с node.js 0.10.5 a, версия npm: 1.3.5 и npm_modules в .gitignore. Tt, кажется, работает нормально до сих пор!


проверьте эту ветвь нового узла Heroku.JS buildpack, теперь в бета-версии, которая поддерживает кэширование node_modules между сборками:

https://github.com/heroku/heroku-buildpack-nodejs/tree/diet

использовать:

heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs#diet -a my-node-app
git commit -am "fakeout" --allow-empty
git push heroku