Puppet: управление (много) Apache VirtualHosts


9

Я изучаю свой путь через управление конфигурацией в целом и использую puppet для его реализации в частности. Я уже провел некоторые общие исследования ( также по SF ), и сейчас я рассматриваю Apache VirtualHosts.

Мы размещаем множество веб-сайтов LAMP (в настоящее время их насчитывается несколько сотен) на двух системах: на Apache2 / mod_php и на MySQL - в основном противоположность другому вопросу, уже существующему на SF, где он управляет множеством серверов с несколькими vhosts каждый (если на самом деле не один, я не знаю). Я еще не собрал рабочий конфиг в puppet, но это не должно быть проблемой, есть много примеров и рецептов.

В дополнение к очевидным файлам конфигурации Apache (здесь нет проблем, я полагаю) каждому vhost потребуется создать несколько каталогов и проверить разрешения (например, корневой каталог для каждого vhost, содержащий documentroot, выделенный каталог tmp, выделенный файлы сеанса php dir, возможно сертификаты SSL и т. д.) на веб-сервере и пользователь + одна или несколько баз данных на сервере MySQL.

Добавление нового vhost потребовало бы создания puppet, а удаление одного потребовало бы, чтобы puppet запустил какой-либо сценарий, который будет создавать резервные копии пользовательских данных, а затем удалять текущие данные с двух серверов, но также каждый запускаемый агент puppet будет проверять существование каталоги, базы данных, разрешения и т. д.

Запрашиваю ли я проблемы при переходе к сотням виртуальных хостов со всеми этими проверками, запускаемыми при каждом запуске кукол, особенно в файловой системе (на веб-сервере), и особенно когда в будущем системы будут загружены больше? (допустим, мы нацелены на диапазон 1000–2000 веб-сайтов в качестве разумного максимума для каждого сервера).

Есть ли опыт сделать это там в сети? Я гуглил, но ничего не нашел, в том числе из-за низкого соотношения сигнал / шум при поиске «puppet» и «apache» ...

Ответы:


4

Я подозреваю, что управление многими виртуальными хостами Apache не будет проблемой, но я не могу сказать точно. Приемлемая производительность определяется потребностями вашего бизнеса. Только вы можете решить, достаточно ли это быстро. Вот достойная тема о снижении нагрузки на процессор: https://groups.google.com/forum/?fromgroups#!topic/puppet-users/sxtMvCnKnys[1-25]

Подводя итог темы:

  • Увеличьте задержку между запусками кукольного агента
  • не планируйте кукольный и используйте только кукольный удар или mcollective для запуска
  • Запланируйте изменения Apache, чтобы они происходили только в определенное время.
  • использовать две разные среды (техническое обслуживание и производство) для управления вещами. Сохраняйте производство легким и используйте обслуживание для внесения изменений.

Вот пример управления виртуальным хостом Apache с веб-сайта PuppetLabs: http://docs.puppetlabs.com/learning/definedtypes.html#an-example-apache-vhosts

Настройка и удаление конфигурации не должно быть проблемой. Самой большой проблемой было бы удаление файлов данных для веб-приложений / сайтов. Для этого я бы порекомендовал общее хранилище, например NFS / AFS. Если вы не используете общее хранилище, убедитесь, что сгенерированные пользователем данные остались нетронутыми, скопированы или перенесены на новый сервер.

Я подозреваю, что вы находитесь в ситуации массового хостинга, например, в компании, предоставляющей услуги веб-хостинга, поэтому я рекомендую не указывать имена отдельных сайтов в вашем манифесте. Для этого я рекомендую использовать Hiera < http://puppetlabs.com/blog/first-look-install-and-using-hiera/ . Hiera позволяет использовать отдельный способ хранения списка виртуальных хостов для сопоставлений реальных серверов. Вы можете использовать плоские файлы или базу данных с Hiera. К сожалению, я не знаю Hiera достаточно, чтобы показать вам, как настроить многоуровневую структуру данных Hiera, которая вам может понадобиться, но я могу, по крайней мере, указать вам общее направление Hiera.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.