Foreman — менеджер процессов для ваших веб-приложений

[pechorin]

А я что-то и забыл, что в нем есть експорт в bluepill и тп. А можно как-то сделать експорт, указав кол-во запускаемых процессов?

[Invizory]

Да, конечно можно, например:

$ foreman export upstart /etc/init -c habr=4 -c web=2

[pechorin]

Отлично! Спасибо. Мне всегда нравился foreman, но всегда пугало, что оно не может следить за жизнью процессов, как bluepill, теперь все станет еще проще и красивее :)

P.S., что-то пошло не так, но этот комментарий был ответом на habrahabr.ru/post/176947/#comment_6147833

[MechanisM]

Так как у меня проекты на питоне, пользуюсь альтернативой написанной на python — honcho.
есть еще на shell — shoreman, и norman на nodejs.

[DOLARiON]

А в чем отличие от, к примеру, того же Supervisor? Насколько понимаю — и то, и другое — демонайзеры.
Или я не правильно осознаю суть Foreman?

[MechanisM]

foreman создавался для хостинга heroku(там нет возможности задать настройки для supervisor). Для удобства чтобы просто в репозитории был Procfile с необходимыми командами для запуска и .env файл с переменными окружения. Я вот с foreman познакомился давно, после того как попробовал heroku и как-то с тех пор мне оч понравилось и пользуюсь. Для работы с .env файлами пользуюсь autoenv который при входе в папку помимо того что считывает переменные окружения еще и может активировать например виртуальное окружение питона.

[Invizory]

Хотелось бы еще добавить к комментарию выше, что Foreman в первую очередь — инструмент разработчика, а не администратора. Более того, он поддерживает экспорт в том числе и в supervisord.

[copist]

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

Не могли бы вы дать больше информации об этом?

[Invizory]

Говоря о конфигурации веб-приложения, мы, как правило, имеем в виду все, что может отличаться для нескольких экземпляров одного и того же приложения, запущенного в разных окружениях. Скажем, параметры доступа к БД, очередям сообщений, внешним сервисам (API-ключи, логины-пароли) — это все конфигурация, тогда как список роутов или описание подключаемых компонентов в IoC-контейнере ею не являются — это уже внутренний конфиг, фактически, часть кода. Отсюда сразу следует рекомендация строго разделять конфигурацию и код — конфиг может меняться в разных окружениях, тогда как код для всех един.

Поэтому, как правило, разработчики используют конфигурационные файлы. Некоторые все еще продолжают их класть в репозиторий, а остальные этого уже не делают и заполняют конфиги для каждого деплоя. Еще одна часто распространенная практика — написать пару-тройку готовых конфигов для основных окружений и положить их в репозиторий — в качестве примера можно привести известное заклинание «development, test, production». Понятно, однако, что такой способ не очень-то масштабируется.

Соответственно, также используется и тот подход, о котором мы говорим — хранить конфигурацию в переменных окружения. Вот его достоинства:

• Переменные окружения легко менять, к тому же для разработчиков есть такие штуки как Foreman и autoenv.
• Не получится случайно закоммитить конфиг от околобоевого окружения в репозиторий, в отличие от файлов-конфигов.
• Это, фактически, единственный способ описать конфигурацию, который не зависит от ОС, используемой платформы или языка.

Как можно понять, это все неплохо вписывается в приложения, которым нужен высокий уровень гибкости и масштабируемости, а также подходит для новомодных облачных моделей типа PaaS и IaaS — одними переменными окружения мы можем рулить чем и кем угодно, вне зависимости от платформы — можно хоть на чистом C код писать. Именно поэтому такие сервисы, как, например, Heroku, используют переменные окружения для конфигурирования.