Развёртывание приложений node.js

[@Mikke]

Извиняюсь если говорю глупость, но системных компонентов эта штука не подтягивает, было бы удобно реализовать еще и выполнение команд при деплоее.

[@Mikke]

Или для этого можно написать свои «plugins»?

[@AndyGrom]

Я написал в статье про установку зависимостей с помощью npm install. Если вы в package.json своего приложения пропишете инсталляционный скрипт, то npm выполнит его при установке. Пример можно найти в самом node-deploy-server. Он как раз использует эту технику, чтобы выполнить установку сервиса.

[@VasilioRuzanni]

Хотелось бы еще поподробнее узнать — «зачем»? То есть, что именно особенного делает node-deploy-server? Не проще ли использовать Phusion Passenger, имеющий целую кучу полезных фич (и отработанных edge-case-ов)?

[@AndyGrom]

Основной мотив — простота установки для node.js разработчика.

[@VasilioRuzanni]

Потому вопрос и возник — тот же Passenger ставится элементарно (через APT или Homebrew), и большая часть его фич скорее всего все равно понадобится в продакшене. Да, Passenger — Unix-only, но кто будет юзать node.js в продакшене на Windows.

[@VasilioRuzanni]

Если честно — Azure не юзал для node.js (только для ASP.NET), но предполагаю там что-то похожее на iisnode (и Passenger), который тоже берет на себя всю грязную работу. Ну облачная тема особенная — там сами сервисы часто предлагают свои утилиты для удобства деплоймента.

[@tenbits]

> в продакшене на Windows.
А в чем проблема? С iisnode у нас всё прекрасно работает — отличная паралельная работа с IIS, который занимается статикой и даже другими WCF сервисами в приложении.

[@VasilioRuzanni]

Да не, технической проблемы и нет, и сам использовал iisnode (начинал с node.js еще во времена активной работы на .NET-стеке). Просто не вижу в нем особого смысла в продакшене (в том числе учитывая необходимость лицензирования), если не используется .NET. Если используется — вопросов и нет.

Изначальный же вопрос вообще про node-deploy-server был — зачем он нужен.

[@AndyGrom]

Не хотелось бы ввязываться в дебаты о нужности или ненужности того или иного инструмента. История сама ответит на Ваш вопрос. Но, хотел бы ещё раз подчеркнуть что моей целью было создание максимально простого в установке и обслуживании сервиса.

У меня есть несколько различных приложений, которые время от времени меняются и мне не хочется порождать возню с копированием файлов в то время, когда мне необходимо задеплоится и протестировать изменения, иногда на разные машины. Ещё у меня есть привычка деплоить сервисы из VS в пару щелчков мышки.

Ставить что-то серьёзное — это значит потратить время на изучение и настройку, проход по граблям, курение форумов, повторить это для каждого окружения (среда у меня достаточно гетерогенная). Я в принципе не против использования промышленных решений, там где возню с окружением оплачивает работодатель. Но в данном случае для меня это не приемлемо. Да ещё и VDS с 256M памяти не даёт разгуляться.

И да, конечно, я искал что-то подобное, но не нашёл. Рекомендуют либо готовые коммерческие сервисы или ручную возню с forever или более продвинутые системы (типа деплоя по git push), но на мой взгляд, причудливые.

Если Вы node.js разработчик и Вам нужно развернуть приложение на VDS, то скорее всего окружение Вы уже настроили. Значит node и npm стоят и готовы к работе. Остаётся выполнить одну команду для установки, которая знакома любому node.js разработчику; запустить сервис и забыть о нём. В теории, в идеально мире, Вы уже больше никогда на этот VDS не зайдёте, а будете деплоится одной командой из терминала. Очень удобно при горячем баг-фиксинге.

Надеюсь, что на прямой вопрос «зачем?» я ответил. А с полемикой о нужности… вон к дистрибутивам Linux… какого хна их столько?

А вообще, если в комментариях ещё что-нибудь предложат по требованиям, которые я изложил, в достаточном количестве, не поленюсь сделать обзор предложенных решений. Может и найдётся что-то… интересное.

[@VasilioRuzanni]

Ну что тут скажешь — я сразу и не понял, что собой представляет node-deploy-server (my bad) и поднял вопрос про «hosting environment» — а тут речь вообще просто про «deployment script/installation task».

Ну тут тогда добавлю, что просто не видел смысла чего-то городить — инсталляционные скрипты и grunt-таски как-то не считаю велосипедом и не вижу необходимости выносить в какую-то отдельную утилиту.

Но ваша мотивация понятна, благодарствую за подробный ответ.

P.S. Кстати, ничего замысловатого в развертывании с git push (а также git pull и git clone) вовсе нет.

[@btd]

А вы использовали passenger c node.js? Какие преимущества с обычным проксированием?

[@VasilioRuzanni]

Собственно говоря, Пассажир и делает проксирование (используем в основном с nginx, иногда с Apache) в том числе, только снимает необходимость целого вала настроек, запуска скриптов, контролирует запуск процессов и прочее. А также имеет удобные тулзы для мониторинга. Он, конечно, не невесть что делает, но время экономит более чем существенно. Ну а в нашем случае, еще и интеграция с nginx играет роль — ресурсов жрет поменьше при формировании ответа и просто не стоит на пути, когда дело доходит до деплоя.

[@Krio]

Спасибо за тулзу, надо будет опробовать на тестовом сервере.

В конфиге deploy-server можно добавить несколько приложений на сервер, а в клиентском конфиге не указывается название приложения, как управлять несколькими приложениями?

А есть возможность (или в планах) управлять настройками приложений на сервере с помощью «node-deploy-client»? (как всегда лень заходить на сервер и перезапускать сервис)

[@AndyGrom]

Читайте параграф «Как это работает».
Конфигурационный файл (.deploy) один для каждого проекта и должен лежать рядом с package.json

[@Krio]

ага «package.json и использует поле «name» в качестве имени приложения» — спасибо, завтыкал.

А что насчет управления серверным конфигом?

[@AndyGrom]

Насчёт менять настройки. С самого начала я включил в основу express.js фреймфорк, хотя для решения данной задачи он там слишком излишен. Так что есть мысли по поводу создания web-интерфейса для управления.

[@potomushto]

Есть dokku (https://github.com/progrium/dokku), можно поднять такой свой Heroku. Установка и деплой в два шага.
Плюсы в том, что он изолирует каждое node.js или любое другое приложение в контейнере с помощью Docker, сам деплой производится на git push (который эффективно шлет запакованные изменения исходного кода), умеет в плагины, есть выполнение команд в этом контейнере. Вообще Docker — сила, можно скастомизировать.

[@Jabher]

Сколько я не перепробовал инструментов для деплоя, что таких, что встроенных в среду разработки, что CI-систем — самым удобным на деле оказался велосипед, который мы написали для себя недавно. Показывать не буду — пока стыдно, может, как-нибудь потом :)
Сервер на express.js слушает хуки с гита, по срабатыванию — делает git clone, дальше — внимание, фокус — делается ритуальное харакири серверу, который тут же поднимается заново благодаря forever, после чего делается

require(REPO_DIR+'/'+repo_name+'/'+'gruntfile')(grunt);
grunt.tasks.run('CI-task-'+git.branch)

А дальше отрабатывают таски грюнта. Никакого мониторинга, конечно же, пока что нет, хотя и очень хочется, если честно. В идеале думал, если дойдут руки, сделать плагин для IDE, который выводил бы алерт с статусом, но это когда-нибудь потом.

Как бы смешно не выглядело — это реально очень удобно и просто в силу того, что грюнтом нынче умеет пользоваться почти любой идиот. А кто не умеет — того можно научить за пару часов. Ветки гита тоже понимают почти все.

Строго говоря, если кто-то хочет поучаствовать в создании нормального опенсорсного веб-ориентированного CI — я буду крайне рад сделать из велосипеда для себя действительно что-то хорошее.

[@AndyGrom]

Велосипед всегда удобнее, поскольку пишется под конкретные хотелки. С ними единственная проблема — сопровождение. Так что надо выкладывать на public и пусть борется за своё существование.

[@Jabher]

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

[@aeryaguzov]

Ну для билд-системы, много круче писать билд-таски через Jake(Rake, Make, etc), имхо.
Плюсы Вашей в предустановленных тасках (installDependencies,...), но это никому не нужно, как показывает практика.

Ну и про username, password — это аутентификация для ssh? А если по ключу? А если серверов больше одного? В общем сыровато как-то…

[@AndyGrom]

Инсталляция зависимостей с помощью npm — это для меня счастье, поскольку некоторые пакеты требуют компиляции, а среда гетерогенная. Основная машина под Windows (development), сервера под различными Linux.

Аутентификация производится HTTP-протоколом (Basic-авторизация), поскольку сервер — это HTTP-сервер, а клиент, собственно — http.request. Знаю, что не секьюрно, в ближайшее время предоставлю выбор между HTTP и HTTPS.

[@printercu]

Использую capistrano и для деплоя nodejs приложений. Он очень гибкий в конфигурации, так что легко можно создавать любые нужные таски (миграции, прекомпиляцию ассетов и прочие). Также из коробки работает multistage — возможность указывать разные конфиги для development, staging, production.

Таски для работы с 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, так что если нет у вас этой директории, придется добавить :)

[@tamtakoe]

Как понимаю, если на сервере PHP — работать не будет?

[@AndyGrom]

Заточено исключительно на node.js. К тому же нет большого смысла использовать этот инструмент для деплоя скриптов, которые не являются долгоживущими процессами (т.е. linux daemon`s или windows services).