Comments 27
Извиняюсь если говорю глупость, но системных компонентов эта штука не подтягивает, было бы удобно реализовать еще и выполнение команд при деплоее.
Или для этого можно написать свои «plugins»?
Я написал в статье про установку зависимостей с помощью npm install. Если вы в package.json своего приложения пропишете инсталляционный скрипт, то npm выполнит его при установке. Пример можно найти в самом node-deploy-server. Он как раз использует эту технику, чтобы выполнить установку сервиса.
Хотелось бы еще поподробнее узнать — «зачем»? То есть, что именно особенного делает node-deploy-server? Не проще ли использовать Phusion Passenger, имеющий целую кучу полезных фич (и отработанных edge-case-ов)?
Основной мотив — простота установки для node.js разработчика.
Потому вопрос и возник — тот же Passenger ставится элементарно (через APT или Homebrew), и большая часть его фич скорее всего все равно понадобится в продакшене. Да, Passenger — Unix-only, но кто будет юзать node.js в продакшене на Windows.
UFO just landed and posted this here
> в продакшене на Windows.
А в чем проблема? С iisnode у нас всё прекрасно работает — отличная паралельная работа с IIS, который занимается статикой и даже другими WCF сервисами в приложении.
А в чем проблема? С iisnode у нас всё прекрасно работает — отличная паралельная работа с IIS, который занимается статикой и даже другими WCF сервисами в приложении.
Да не, технической проблемы и нет, и сам использовал iisnode (начинал с node.js еще во времена активной работы на .NET-стеке). Просто не вижу в нем особого смысла в продакшене (в том числе учитывая необходимость лицензирования), если не используется .NET. Если используется — вопросов и нет.
Изначальный же вопрос вообще про node-deploy-server был — зачем он нужен.
Изначальный же вопрос вообще про node-deploy-server был — зачем он нужен.
Не хотелось бы ввязываться в дебаты о нужности или ненужности того или иного инструмента. История сама ответит на Ваш вопрос. Но, хотел бы ещё раз подчеркнуть что моей целью было создание максимально простого в установке и обслуживании сервиса.
У меня есть несколько различных приложений, которые время от времени меняются и мне не хочется порождать возню с копированием файлов в то время, когда мне необходимо задеплоится и протестировать изменения, иногда на разные машины. Ещё у меня есть привычка деплоить сервисы из VS в пару щелчков мышки.
Ставить что-то серьёзное — это значит потратить время на изучение и настройку, проход по граблям, курение форумов, повторить это для каждого окружения (среда у меня достаточно гетерогенная). Я в принципе не против использования промышленных решений, там где возню с окружением оплачивает работодатель. Но в данном случае для меня это не приемлемо. Да ещё и VDS с 256M памяти не даёт разгуляться.
И да, конечно, я искал что-то подобное, но не нашёл. Рекомендуют либо готовые коммерческие сервисы или ручную возню с forever или более продвинутые системы (типа деплоя по git push), но на мой взгляд, причудливые.
Если Вы node.js разработчик и Вам нужно развернуть приложение на VDS, то скорее всего окружение Вы уже настроили. Значит node и npm стоят и готовы к работе. Остаётся выполнить одну команду для установки, которая знакома любому node.js разработчику; запустить сервис и забыть о нём. В теории, в идеально мире, Вы уже больше никогда на этот VDS не зайдёте, а будете деплоится одной командой из терминала. Очень удобно при горячем баг-фиксинге.
Надеюсь, что на прямой вопрос «зачем?» я ответил. А с полемикой о нужности… вон к дистрибутивам Linux… какого хна их столько?
А вообще, если в комментариях ещё что-нибудь предложат по требованиям, которые я изложил, в достаточном количестве, не поленюсь сделать обзор предложенных решений. Может и найдётся что-то… интересное.
У меня есть несколько различных приложений, которые время от времени меняются и мне не хочется порождать возню с копированием файлов в то время, когда мне необходимо задеплоится и протестировать изменения, иногда на разные машины. Ещё у меня есть привычка деплоить сервисы из VS в пару щелчков мышки.
Ставить что-то серьёзное — это значит потратить время на изучение и настройку, проход по граблям, курение форумов, повторить это для каждого окружения (среда у меня достаточно гетерогенная). Я в принципе не против использования промышленных решений, там где возню с окружением оплачивает работодатель. Но в данном случае для меня это не приемлемо. Да ещё и VDS с 256M памяти не даёт разгуляться.
И да, конечно, я искал что-то подобное, но не нашёл. Рекомендуют либо готовые коммерческие сервисы или ручную возню с forever или более продвинутые системы (типа деплоя по git push), но на мой взгляд, причудливые.
Если Вы node.js разработчик и Вам нужно развернуть приложение на VDS, то скорее всего окружение Вы уже настроили. Значит node и npm стоят и готовы к работе. Остаётся выполнить одну команду для установки, которая знакома любому node.js разработчику; запустить сервис и забыть о нём. В теории, в идеально мире, Вы уже больше никогда на этот VDS не зайдёте, а будете деплоится одной командой из терминала. Очень удобно при горячем баг-фиксинге.
Надеюсь, что на прямой вопрос «зачем?» я ответил. А с полемикой о нужности… вон к дистрибутивам Linux… какого хна их столько?
А вообще, если в комментариях ещё что-нибудь предложат по требованиям, которые я изложил, в достаточном количестве, не поленюсь сделать обзор предложенных решений. Может и найдётся что-то… интересное.
Ну что тут скажешь — я сразу и не понял, что собой представляет node-deploy-server (my bad) и поднял вопрос про «hosting environment» — а тут речь вообще просто про «deployment script/installation task».
Ну тут тогда добавлю, что просто не видел смысла чего-то городить — инсталляционные скрипты и grunt-таски как-то не считаю велосипедом и не вижу необходимости выносить в какую-то отдельную утилиту.
Но ваша мотивация понятна, благодарствую за подробный ответ.
P.S. Кстати, ничего замысловатого в развертывании с git push (а также git pull и git clone) вовсе нет.
Ну тут тогда добавлю, что просто не видел смысла чего-то городить — инсталляционные скрипты и grunt-таски как-то не считаю велосипедом и не вижу необходимости выносить в какую-то отдельную утилиту.
Но ваша мотивация понятна, благодарствую за подробный ответ.
P.S. Кстати, ничего замысловатого в развертывании с git push (а также git pull и git clone) вовсе нет.
А вы использовали passenger c node.js? Какие преимущества с обычным проксированием?
Собственно говоря, Пассажир и делает проксирование (используем в основном с nginx, иногда с Apache) в том числе, только снимает необходимость целого вала настроек, запуска скриптов, контролирует запуск процессов и прочее. А также имеет удобные тулзы для мониторинга. Он, конечно, не невесть что делает, но время экономит более чем существенно. Ну а в нашем случае, еще и интеграция с nginx играет роль — ресурсов жрет поменьше при формировании ответа и просто не стоит на пути, когда дело доходит до деплоя.
Спасибо за тулзу, надо будет опробовать на тестовом сервере.
В конфиге deploy-server можно добавить несколько приложений на сервер, а в клиентском конфиге не указывается название приложения, как управлять несколькими приложениями?
А есть возможность (или в планах) управлять настройками приложений на сервере с помощью «node-deploy-client»? (как всегда лень заходить на сервер и перезапускать сервис)
В конфиге deploy-server можно добавить несколько приложений на сервер, а в клиентском конфиге не указывается название приложения, как управлять несколькими приложениями?
А есть возможность (или в планах) управлять настройками приложений на сервере с помощью «node-deploy-client»? (как всегда лень заходить на сервер и перезапускать сервис)
Читайте параграф «Как это работает».
Конфигурационный файл (.deploy) один для каждого проекта и должен лежать рядом с package.json
Конфигурационный файл (.deploy) один для каждого проекта и должен лежать рядом с package.json
Насчёт менять настройки. С самого начала я включил в основу express.js фреймфорк, хотя для решения данной задачи он там слишком излишен. Так что есть мысли по поводу создания web-интерфейса для управления.
Есть dokku (https://github.com/progrium/dokku), можно поднять такой свой Heroku. Установка и деплой в два шага.
Плюсы в том, что он изолирует каждое node.js или любое другое приложение в контейнере с помощью Docker, сам деплой производится на git push (который эффективно шлет запакованные изменения исходного кода), умеет в плагины, есть выполнение команд в этом контейнере. Вообще Docker — сила, можно скастомизировать.
Плюсы в том, что он изолирует каждое node.js или любое другое приложение в контейнере с помощью Docker, сам деплой производится на git push (который эффективно шлет запакованные изменения исходного кода), умеет в плагины, есть выполнение команд в этом контейнере. Вообще Docker — сила, можно скастомизировать.
Сколько я не перепробовал инструментов для деплоя, что таких, что встроенных в среду разработки, что CI-систем — самым удобным на деле оказался велосипед, который мы написали для себя недавно. Показывать не буду — пока стыдно, может, как-нибудь потом :)
Сервер на express.js слушает хуки с гита, по срабатыванию — делает git clone, дальше — внимание, фокус — делается ритуальное харакири серверу, который тут же поднимается заново благодаря forever, после чего делается
require(REPO_DIR+'/'+repo_name+'/'+'gruntfile')(grunt);
grunt.tasks.run('CI-task-'+git.branch)
А дальше отрабатывают таски грюнта. Никакого мониторинга, конечно же, пока что нет, хотя и очень хочется, если честно. В идеале думал, если дойдут руки, сделать плагин для IDE, который выводил бы алерт с статусом, но это когда-нибудь потом.
Как бы смешно не выглядело — это реально очень удобно и просто в силу того, что грюнтом нынче умеет пользоваться почти любой идиот. А кто не умеет — того можно научить за пару часов. Ветки гита тоже понимают почти все.
Строго говоря, если кто-то хочет поучаствовать в создании нормального опенсорсного веб-ориентированного CI — я буду крайне рад сделать из велосипеда для себя действительно что-то хорошее.
Сервер на express.js слушает хуки с гита, по срабатыванию — делает git clone, дальше — внимание, фокус — делается ритуальное харакири серверу, который тут же поднимается заново благодаря forever, после чего делается
require(REPO_DIR+'/'+repo_name+'/'+'gruntfile')(grunt);
grunt.tasks.run('CI-task-'+git.branch)
А дальше отрабатывают таски грюнта. Никакого мониторинга, конечно же, пока что нет, хотя и очень хочется, если честно. В идеале думал, если дойдут руки, сделать плагин для IDE, который выводил бы алерт с статусом, но это когда-нибудь потом.
Как бы смешно не выглядело — это реально очень удобно и просто в силу того, что грюнтом нынче умеет пользоваться почти любой идиот. А кто не умеет — того можно научить за пару часов. Ветки гита тоже понимают почти все.
Строго говоря, если кто-то хочет поучаствовать в создании нормального опенсорсного веб-ориентированного CI — я буду крайне рад сделать из велосипеда для себя действительно что-то хорошее.
Ну для билд-системы, много круче писать билд-таски через Jake(Rake, Make, etc), имхо.
Плюсы Вашей в предустановленных тасках (installDependencies,...), но это никому не нужно, как показывает практика.
Ну и про username, password — это аутентификация для ssh? А если по ключу? А если серверов больше одного? В общем сыровато как-то…
Плюсы Вашей в предустановленных тасках (installDependencies,...), но это никому не нужно, как показывает практика.
Ну и про username, password — это аутентификация для ssh? А если по ключу? А если серверов больше одного? В общем сыровато как-то…
Инсталляция зависимостей с помощью npm — это для меня счастье, поскольку некоторые пакеты требуют компиляции, а среда гетерогенная. Основная машина под Windows (development), сервера под различными Linux.
Аутентификация производится HTTP-протоколом (Basic-авторизация), поскольку сервер — это HTTP-сервер, а клиент, собственно — http.request. Знаю, что не секьюрно, в ближайшее время предоставлю выбор между HTTP и HTTPS.
Аутентификация производится HTTP-протоколом (Basic-авторизация), поскольку сервер — это HTTP-сервер, а клиент, собственно — http.request. Знаю, что не секьюрно, в ближайшее время предоставлю выбор между HTTP и HTTPS.
Использую capistrano и для деплоя nodejs приложений. Он очень гибкий в конфигурации, так что легко можно создавать любые нужные таски (миграции, прекомпиляцию ассетов и прочие). Также из коробки работает multistage — возможность указывать разные конфиги для development, staging, production.
Таски для работы с forever получились довольно простыми
С
Единственный минус — по умолчанию конфиг лежит в
Таски для работы с forever получились довольно простыми
%w(start restart stop).each do |action|
task :"forever_#{action}" do
run "cd #{current_path} && NODE_ENV=#{stage} forever -al #{log_file} #{action} #{forever_cmd}"
end
end
С
npm install тоже проблем не возникло.Единственный минус — по умолчанию конфиг лежит в
config/deploy.rb, так что если нет у вас этой директории, придется добавить :)
Как понимаю, если на сервере PHP — работать не будет?
Sign up to leave a comment.
Развёртывание приложений node.js