Comments 9
А я что-то и забыл, что в нем есть експорт в bluepill и тп. А можно как-то сделать експорт, указав кол-во запускаемых процессов?
Отлично! Спасибо. Мне всегда нравился foreman, но всегда пугало, что оно не может следить за жизнью процессов, как bluepill, теперь все станет еще проще и красивее :)
P.S., что-то пошло не так, но этот комментарий был ответом на habrahabr.ru/post/176947/#comment_6147833
P.S., что-то пошло не так, но этот комментарий был ответом на habrahabr.ru/post/176947/#comment_6147833
А в чем отличие от, к примеру, того же Supervisor? Насколько понимаю — и то, и другое — демонайзеры.
Или я не правильно осознаю суть Foreman?
Или я не правильно осознаю суть Foreman?
foreman создавался для хостинга heroku(там нет возможности задать настройки для supervisor). Для удобства чтобы просто в репозитории был Procfile с необходимыми командами для запуска и .env файл с переменными окружения. Я вот с foreman познакомился давно, после того как попробовал heroku и как-то с тех пор мне оч понравилось и пользуюсь. Для работы с .env файлами пользуюсь autoenv который при входе в папку помимо того что считывает переменные окружения еще и может активировать например виртуальное окружение питона.
Хотелось бы еще добавить к комментарию выше, что Foreman в первую очередь — инструмент разработчика, а не администратора. Более того, он поддерживает экспорт в том числе и в supervisord.
Существует подход, постепенно завоевывающий популярность у разработчиков, заключающийся в том, чтобы хранить конфигурацию приложения в переменных окружения.
Не могли бы вы дать больше информации об этом?
Говоря о конфигурации веб-приложения, мы, как правило, имеем в виду все, что может отличаться для нескольких экземпляров одного и того же приложения, запущенного в разных окружениях. Скажем, параметры доступа к БД, очередям сообщений, внешним сервисам (API-ключи, логины-пароли) — это все конфигурация, тогда как список роутов или описание подключаемых компонентов в IoC-контейнере ею не являются — это уже внутренний конфиг, фактически, часть кода. Отсюда сразу следует рекомендация строго разделять конфигурацию и код — конфиг может меняться в разных окружениях, тогда как код для всех един.
Поэтому, как правило, разработчики используют конфигурационные файлы. Некоторые все еще продолжают их класть в репозиторий, а остальные этого уже не делают и заполняют конфиги для каждого деплоя. Еще одна часто распространенная практика — написать пару-тройку готовых конфигов для основных окружений и положить их в репозиторий — в качестве примера можно привести известное заклинание «development, test, production». Понятно, однако, что такой способ не очень-то масштабируется.
Соответственно, также используется и тот подход, о котором мы говорим — хранить конфигурацию в переменных окружения. Вот его достоинства:
Как можно понять, это все неплохо вписывается в приложения, которым нужен высокий уровень гибкости и масштабируемости, а также подходит для новомодных облачных моделей типа PaaS и IaaS — одними переменными окружения мы можем рулить чем и кем угодно, вне зависимости от платформы — можно хоть на чистом C код писать. Именно поэтому такие сервисы, как, например, Heroku, используют переменные окружения для конфигурирования.
Поэтому, как правило, разработчики используют конфигурационные файлы. Некоторые все еще продолжают их класть в репозиторий, а остальные этого уже не делают и заполняют конфиги для каждого деплоя. Еще одна часто распространенная практика — написать пару-тройку готовых конфигов для основных окружений и положить их в репозиторий — в качестве примера можно привести известное заклинание «development, test, production». Понятно, однако, что такой способ не очень-то масштабируется.
Соответственно, также используется и тот подход, о котором мы говорим — хранить конфигурацию в переменных окружения. Вот его достоинства:
- Переменные окружения легко менять, к тому же для разработчиков есть такие штуки как Foreman и autoenv.
- Не получится случайно закоммитить конфиг от околобоевого окружения в репозиторий, в отличие от файлов-конфигов.
- Это, фактически, единственный способ описать конфигурацию, который не зависит от ОС, используемой платформы или языка.
Как можно понять, это все неплохо вписывается в приложения, которым нужен высокий уровень гибкости и масштабируемости, а также подходит для новомодных облачных моделей типа PaaS и IaaS — одними переменными окружения мы можем рулить чем и кем угодно, вне зависимости от платформы — можно хоть на чистом C код писать. Именно поэтому такие сервисы, как, например, Heroku, используют переменные окружения для конфигурирования.
Sign up to leave a comment.
Foreman — менеджер процессов для ваших веб-приложений