В моей компании сейчас есть один главный проект - большое монолитное приложение Rails. Развертывание простое, у нас есть пара интерфейсных серверов (настройка с помощью Puppet), которые Capistrano развертывает на /var/www/<hostname>/current. Затем он перезапускает Unicorn (без простоев развертывания!), И все довольны.
К сожалению, есть проблема. Монолитность приложения начинает нас кусать. Теперь на выполнение всех тестов уходит более 30 минут, и это сильно тормозит. Мы планируем разделить его на более мелкие части и принять архитектуру, более близкую к μService. Однако это заставило меня задуматься о нашей стратегии развертывания. В его нынешнем виде:
www-data пользовательchown данные пользователю приложения во время развертывания)Безопасность этого довольно низкая (все работает как один и тот же пользователь, каждый может получить доступ ко всему). Это также напоминает мне о том, как мы делали что-то в предыдущей компании - это был кошмар, поскольку все приложения застряли на Ruby 1.6, поскольку они использовали одну и ту же версию.
Я думаю, что мы можем улучшить это, установив rbenv чтобы позволить каждому приложению запускать свою собственную версию Ruby и иметь пользователей для каждого приложения для повышения безопасности. Но я действительно не видел примеров этого на практике. Например 37signals запускают все приложения от имени одного пользователя - Меня беспокоит, что есть веская причина, по которой приложения не должны запускаться от имени разных пользователей.
Чтобы обобщить:
Заранее спасибо!
Для нескольких экземпляров Ruby я бы определенно рекомендовал RVM (Ruby enVironemnt Manager). Я нашел его более надежным, чем rbenv для производственных сред.
Nginx может подключаться к привилегированным портам (<= 1024), только если он запущен как привилегированный пользователь. Таким образом, может потребоваться конфигурация обратного прокси, чтобы удовлетворить вашу потребность в запуске каждого экземпляра Unicorn как отдельного процесса разрешенным пользователем.
Если ваша оценка запуска каждого из них на отдельной виртуальной машине является окончательной, способ изолировать каждое приложение в GNU / Linux является SELinux. SELinux довольно сложен, но предоставляет средства, позволяющие безопасно разделять процессы и контекст.
У нас аналогичная конфигурация (хотя мы работаем с Tomcat и Grails вместо nginx и RoR). Мы настроили индивидуальные идентификаторы пользователей для каждого экземпляра Tomcat. Мы устанавливаем домашние каталоги для Java, Grails и любых других зависимых библиотек в .profile для пользователя в качестве переменных среды, поэтому каждый Tomcat может работать с любой установленной версией.
Пользователь с ИД пользователя нашей программы автоматического развертывания (Atlassian Bamboo) входит в группу, назначенную для каждого из каталогов Tomcat.