Современное развертывание Rails-приложений с помощью git
Я собираюсь собрать воедино информацию о текущих рекомендациях по развертыванию приложения Rails на сервере, который я запускаю (а не, скажем, в Heroku). Приложение разработано несколькими людьми, и все они имеют разрешение на его развертывание. Приложение будет работать на сервере, который может иметь более одного приложения.
- Используйте Apache или Nginx с Passenger
- Я использую Ubuntu, но это не должно иметь большого значения.
- Capistrano, кажется, лучший способ перейти на сервер.
Теперь некоторые сомнения у меня есть:
- Использовать RVM или нет? Пассажир может использовать только одну версию Ruby, так что это бесполезно, не так ли?
- Как бы вы структурировали права доступа и ключи ssh? Я думаю, что вы определенно не хотите, чтобы пользователь был "самим собой" (скажем, dnw на сервере), а имел учетную запись роли. Целесообразно ли для этого использовать www-данные Ubuntu или лучше создать другого пользователя? Один для каждого приложения? Какого рода конфигурация (оболочка в /etc/passwd, например, группы и т. Д.) Должна позволять этим пользователям сделать систему максимально безопасной, если кто-то обнаружит уязвимость в веб-приложении? Какой рецепт капистрано вы бы использовали для этого?
- Теперь мы добавляем в смесь git: git должен иметь возможность извлекать пароль без пароля с git-сервера, поэтому будет происходить некоторый обмен ключами. Как должна выглядеть удаленная настройка git, чтобы все было красиво и безопасно?
- Что-нибудь еще, что я не покрываю?
2 ответа
- Nginx/ Unicorn (Passenger доставляет больше хлопот, чем стоит, особенно когда вы имеете дело с несколькими версиями Ruby). Единороги управляются daemontools / allah, потому что бог шуршит моими уловками.
- rbenv, а не RVM (rbenv предназначен для того, чтобы делать что-то одно и делать это хорошо, а не для подхода RVM "делай болезненную половинку всего")
- Пользователь на приложение, с ключами SSH для каждого разработчика, который имеет полномочия для управления каждым отдельным приложением.
- Вы можете запустить само приложение как отдельный пользователь и использовать списки ACL, чтобы разрешить доступ только к тем частям файловой системы, в которых нуждается приложение; этот пользователь приложения не должен разрешать вход в систему. Лично я считаю, что это излишне, но это возможно, если вы хотите немного увеличить разделение.
- Capistrano - это еще один инструмент "мучительной половины работы всего"; Я рекомендую Giddyup, хотя это может быть потому, что я написал это.
Я написал книгу о более или менее точно такой же настройке, которая бесплатна для людей из моего списка рассылки.
Он включает в себя настройку сервера с nginx, Unicorn, MySQL и rbenv с нуля и развертывание (и обновление) примера приложения Rails, чтобы помочь вам понять, как этот процесс работает под капотом.
Если вы думаете, что это что-то для вас, вы можете получить это здесь.
Обновление: Прошло довольно много времени с тех пор, как я написал этот комментарий. С тех пор я выпустил Efficient Rails DevOps, профессиональную книгу по этой теме, которая охватывает не только большинство из вышеперечисленных вопросов, но и то, как делать вещи контролируемым, воспроизводимым способом (используя Ansible в качестве инструмента управления конфигурацией и развертывания).