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


    Деплоймент приложения всегда является критической точкой цикла разработки… и никогда не бывает лёгким. Если Вы пользуетесь услугами хостинговых провайдеров, то вероятнее всего Вам уже предоставили достаточный всяческих удобств сервис. В данной статье я расскажу про развёртывание приложений без создания сложной хостинговой инфраструктуры…

    Для начала определимся с технологией. Использовать будем, естественно, только то, что предоставила нам платформа разработки — node.js. На сервере будет работать некий web-сервис, который будет принимать запросы и заниматься всей «грязной» работой. На клиенте — command-line tool. Ну как без него?

    Итак, сервис устанавливается следующим образом:
    npm install -g node-deploy-server --unsafe-perm
    


    Клиент, не сложнее…
    npm install -g node-deploy-client
    


    Софт стоит, теперь пора рассказать как его конфигурировать, чтобы подружить вместе сервис с клиентом.

    Настройка сервера.

    Файл конфигурации носит имя nodehosting.json и находится в папке /etc для Linux систем и в корне модуля для Windows.
    Полный текст конфигурационного файла
    {
        "port" : 15478,
        "username" : "admin",
        "password" : "admin",
        "applications" : {
            "application1" : {
                "path" : "../applications",
                "foreverConfig" : {
                    "cwd" : "../applications/application1"
                },
                "startProcess" : true
            }
        }
    }
    


    • port — TCP порт на котором будет работать сервис
    • username и password — тут пояснять нечего...
    • объект applications. Именами свойств этого объекта являются имена приложений, за развёртывание которых отвечает сервис.

    Настройка приложения:
    • path — общая корневая папка приложений. Не беспокойтесь её создавать. Всё сделают за Вас.
    • foreverConfig — Приложения запускаются с помощью forever-monitor, поэтому более чем официальный источник мне рассказать нечего.
    • startProcess — автоматический запуск процесса после развёртывания

    Отдельно хочу сказать про установку зависимостей. Она выполняется с помощью команды npm install в корневой папке приложения. Для примера это ../applications/application1. Таким образом, если необходимо при развёртывании выполнить дополнительные действия их достаточно прописать в поле scripts.install в package.json

    Настройка клиента.

    В корневую папку приложения (рядом с package.json) необходимо положить файл с именем .deploy и следующего содержания:
    {
    	"dev" : {
    		"url" : "http://admin:admin@localhost:15478"
    	},
    	"staging" : {
    		"url" : "http://admin:admin@192.168.1.3:15478"
    	}
    }
    

    В отличии от сервера здесь не густо — самый минимум, чтобы связаться с сервером. В файле можно указать несколько конфигураций. Т.е. можно определить несколько различных серверов для развёртывания, например: dev, staging, production. Выбор конкретного сервера производится клиентской утилитой. Собственно именем конфигурации в тестовом примере является dev и staging. Более подробный пример можно посмотреть на github

    Запуск сервера.

    Запускаем сервер на Linux
    service nodehosting start
    

    Не забудьте выполнить команду chkconfig nodehosting on если хотите чтобы сервис запускался при запуске ОС.

    Запускаем сервер на Windows
    sc start nodehosting.exe
    


    Запуск клиента

    Для деплоя приложения необходимо перейти в его корневую папку и в командной строке выполнить
    deploy dev
    

    Вывод команды выглядит примерно так:


    Как это работает?

    Клиентская часть открывает файл package.json и использует поле «name» в качестве имени приложения (ничуть не странно). Далее упаковывает корневую папку исключая из архива папку node_modules. Получившийся архив отправляет POST`ом по http протоколу по адресу указанному в .deploy файле. Ну а на сервере происходят процессы уже описанные выше.

    Благодарности.

    Проект молодой. Так что конструктивная критика и предложения ожидаются. Исходники хостятся на github

    Если чё вдруг.

    Протестировано на парочке RedHat-based дистрибутивов, Debian 7.2 (wheezy) и Windows 7.

    PS

    C января 2014 года доступен web-интерфейс. Таким образом настройка приложений стала намного проще.

    А так же…
    • Перед развёртыванием приложения не обязательно создавать через интерфейс новое приложение, и вообще что-либо настраивать. Достаточно с клиента выполнить запрос и приложение задеплоится с параметрами по умолчанию.
    • Переключение сервера в режим SSL.
    • Проверена работа на следующих ОС: CentOS 6, Fedora 18, Debian 7.2 (wheezy), Windows 7, Windows 8
    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 27
    • 0
      Извиняюсь если говорю глупость, но системных компонентов эта штука не подтягивает, было бы удобно реализовать еще и выполнение команд при деплоее.
      • 0
        Или для этого можно написать свои «plugins»?
        • 0
          Я написал в статье про установку зависимостей с помощью npm install. Если вы в package.json своего приложения пропишете инсталляционный скрипт, то npm выполнит его при установке. Пример можно найти в самом node-deploy-server. Он как раз использует эту технику, чтобы выполнить установку сервиса.
      • 0
        Хотелось бы еще поподробнее узнать — «зачем»? То есть, что именно особенного делает node-deploy-server? Не проще ли использовать Phusion Passenger, имеющий целую кучу полезных фич (и отработанных edge-case-ов)?
        • 0
          Основной мотив — простота установки для node.js разработчика.
          • +1
            Потому вопрос и возник — тот же Passenger ставится элементарно (через APT или Homebrew), и большая часть его фич скорее всего все равно понадобится в продакшене. Да, Passenger — Unix-only, но кто будет юзать node.js в продакшене на Windows.
            • 0
              >>>кто будет юзать node.js в продакшене на Windows.
              а разве Azure Web Sites для node.js не на винде?
              • 0
                Если честно — Azure не юзал для node.js (только для ASP.NET), но предполагаю там что-то похожее на iisnode (и Passenger), который тоже берет на себя всю грязную работу. Ну облачная тема особенная — там сами сервисы часто предлагают свои утилиты для удобства деплоймента.
              • 0
                > в продакшене на Windows.
                А в чем проблема? С iisnode у нас всё прекрасно работает — отличная паралельная работа с IIS, который занимается статикой и даже другими WCF сервисами в приложении.
                • 0
                  Да не, технической проблемы и нет, и сам использовал iisnode (начинал с node.js еще во времена активной работы на .NET-стеке). Просто не вижу в нем особого смысла в продакшене (в том числе учитывая необходимость лицензирования), если не используется .NET. Если используется — вопросов и нет.

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

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

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

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

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

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

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

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

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

                      P.S. Кстати, ничего замысловатого в развертывании с git push (а также git pull и git clone) вовсе нет.
            • 0
              А вы использовали passenger c node.js? Какие преимущества с обычным проксированием?
              • 0
                Собственно говоря, Пассажир и делает проксирование (используем в основном с nginx, иногда с Apache) в том числе, только снимает необходимость целого вала настроек, запуска скриптов, контролирует запуск процессов и прочее. А также имеет удобные тулзы для мониторинга. Он, конечно, не невесть что делает, но время экономит более чем существенно. Ну а в нашем случае, еще и интеграция с nginx играет роль — ресурсов жрет поменьше при формировании ответа и просто не стоит на пути, когда дело доходит до деплоя.
            • 0
              Спасибо за тулзу, надо будет опробовать на тестовом сервере.

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

              А есть возможность (или в планах) управлять настройками приложений на сервере с помощью «node-deploy-client»? (как всегда лень заходить на сервер и перезапускать сервис)
              • 0
                Читайте параграф «Как это работает».
                Конфигурационный файл (.deploy) один для каждого проекта и должен лежать рядом с package.json
                • 0
                  ага «package.json и использует поле «name» в качестве имени приложения» — спасибо, завтыкал.

                  А что насчет управления серверным конфигом?
                • 0
                  Насчёт менять настройки. С самого начала я включил в основу express.js фреймфорк, хотя для решения данной задачи он там слишком излишен. Так что есть мысли по поводу создания web-интерфейса для управления.
                • 0
                  Есть dokku (https://github.com/progrium/dokku), можно поднять такой свой Heroku. Установка и деплой в два шага.
                  Плюсы в том, что он изолирует каждое node.js или любое другое приложение в контейнере с помощью Docker, сам деплой производится на git push (который эффективно шлет запакованные изменения исходного кода), умеет в плагины, есть выполнение команд в этом контейнере. Вообще Docker — сила, можно скастомизировать.
                  • 0
                    Сколько я не перепробовал инструментов для деплоя, что таких, что встроенных в среду разработки, что CI-систем — самым удобным на деле оказался велосипед, который мы написали для себя недавно. Показывать не буду — пока стыдно, может, как-нибудь потом :)
                    Сервер на express.js слушает хуки с гита, по срабатыванию — делает git clone, дальше — внимание, фокус — делается ритуальное харакири серверу, который тут же поднимается заново благодаря forever, после чего делается

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

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

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

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

                      Ну и про username, password — это аутентификация для ssh? А если по ключу? А если серверов больше одного? В общем сыровато как-то…
                      • 0
                        Инсталляция зависимостей с помощью npm — это для меня счастье, поскольку некоторые пакеты требуют компиляции, а среда гетерогенная. Основная машина под Windows (development), сервера под различными Linux.

                        Аутентификация производится HTTP-протоколом (Basic-авторизация), поскольку сервер — это HTTP-сервер, а клиент, собственно — http.request. Знаю, что не секьюрно, в ближайшее время предоставлю выбор между HTTP и HTTPS.
                      • 0
                        Использую 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, так что если нет у вас этой директории, придется добавить :)
                        • 0
                          Как понимаю, если на сервере PHP — работать не будет?
                          • 0
                            Заточено исключительно на node.js. К тому же нет большого смысла использовать этот инструмент для деплоя скриптов, которые не являются долгоживущими процессами (т.е. linux daemon`s или windows services).

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.