Введение в развертывание производственных приложений Erlang/OTP
Я хотел бы разработать и развернуть приложение Erlang/OTP в производство на VPS.
Я довольно хорошо знаком с разработкой кода Erlang на локальной машине, и мой вопрос касается развертывания.
в принципе, я хотел бы знать, какие шаги я должен предпринять, чтобы переместить код Erlang с локального компьютера на рабочий сервер и запустить его, т. е. быть доступным для пользователей.
Примечание: я прочитал некоторую документацию о Эрланг и командная строка, Эрланг код модуль, Эрланг выпускает, но я все еще не уверен, как выполнить требуемую задачу.
однако, я думаю, что развертывание программного обеспечения на основе Erlang на сервере немного сложнее, чем делать sudo tasksel на лампы.
Я планирую иметь приложение Erlang / OTP, которое имеет Mochiweb, CouchDB (couchbeam) и boss_db as зависимости.
Итак, мой новичок вопросы о развертывании всего этого на рабочем сервере следующие:
- я планирую использовать Ubuntu Server 12.04; есть ли лучший выбор для дистрибутива Linux для использования для Erlang / OTP в производстве?
- как должен быть организован весь код? Должен ли я поместить свое приложение в /home/myapp/ dir, а затем поместить все зависимости в /home/myapp/deps? Или я должен поместить все зависимости в / usr/местный/lib/erlang / lib? (возвращается код:get_path()). Должен ли я как-то регулярно обновлять зависимости или должен их замораживать?
- как запустить все приложение после запуска сервера? Должен быть какой-то скрипт или что-нибудь еще?
- я знаю, что Erlang позволяет обновлять горячий код, но как я должен это организовать? На рельсах я мог бы Обновить код с помощью git, есть ли что-нибудь подобное в мире Эрланга?
2 ответов
существует два типа зависимостей: внутренняя и внешняя. Если вы хотите сделать это правильно(tm), это займет немного времени, чтобы добраться до работы:
внешние зависимости:
принимая последнее первым, an внешний зависимость - это еще одна вещь, которая должна запускаться до запуска вашего приложения. Например, база данных PostgreSQL или кластер Riak. Для тех, кто, как правило, просто использовать обычные вещи в Ubuntu для его запуска должным образом. У меня было хороший опыт использования monit для этих задач:
Внутренних Зависимостей:
на внутренние зависимости, вам нужно организовать свою программу в приложения внутри виртуальной машины Erlang. Они имеют зависимости друг от друга, как и внешние зависимости. Например, вашему основному приложению может потребоваться запуск регистратора перед его запуском. Затем вы создаете релиз. А релиз копирует двоичные файлы Erlang и необходимые библиотеки/лучи/приложения в каталог выпуска, формируя автономную систему Erlang. Он содержит boot-script который говорит, Как запустить приложения в правильном порядке и сохранить их запущенными. Таким образом, вы можете tar-ball этот выпуск, скопировать его на сервер, а затем запустить его. Есть некоторые основы покрыты здесь:
http://learnyousomeerlang.com/release-is-the-word
но также прочитайте главы перед ним о приложениях. Вы также можете получить rebar вызов reltool для построения релиза. Это то, что я обычно делаю.
горячее обновление:
обработка горячих обновлений в производстве может быть выполнена несколькими способами. Вы можете переместить луч на машину, а затем развернуть его, взять оболочку, а затем вызвать l(Module) загрузить его в работающая система. Это работает для небольших исправлений. Для больших систематических обновлений вы can сделайте выпуск-обновление, которое обновит работающую систему на лету без остановки службы. Но если ваша система в основном ничем не делится, это обычно не стоит того. Вместо этого вы можете иметь несколько машин и обновлять их последовательно.
например, вы можете обновить машину, а затем использовать систему HAProxy для отправки 2% всех запросов в новую систему. Затем систематически поверните вверх вес нагрузки запроса.
в то время как @I GIVE CRAP ANSWERS дал довольно подробное резюме, я чувствую себя вынужденным бросить в использование синхронизация, что помогает автоматизировать горячую перекомпиляцию и перезагрузку модулей.
простой способ-указать синхронизацию как зависимость арматуры, а затем, когда вы готовитесь к развертыванию обновления, вы можете запустить sync:go() на узле Erlang. Это запускает механизм синхронизации, который следит за изменениями файловой системы. Затем вы можете использовать git для нажатия на ваш сервер. Синхронизации обратите внимание на изменение файлов, их перекомпиляцию и автоматическую загрузку новых лучей.
затем, вы можете запустить sync:stop() сразу же сказать системе, чтобы перестать следить за изменениями файловой системы (обычно не рекомендуется синхронизировать работу на живом сервере, просто чтобы предотвратить случайную перекомпиляцию, если по какой-либо причине исходный файл изменяется и это непреднамеренно.