Ляльковий: управління (безліч) Apache VirtualHosts


9

Я вивчаю свій шлях через керування конфігурацією взагалі і використовую лялькові для його реалізації зокрема. Я вже провів деякі загальні дослідження ( також щодо SF ) і зараз я розглядаю Apache VirtualHosts.

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

На додаток до очевидних файлів конфігурації apache (тут, мабуть, немає жодної проблеми), кожному vhost потрібно було б створити деякі каталоги та перевірити права доступу (наприклад, root-dir для кожного vhost, що містить documentroot, виділений tmp dir, виділений php-файли сеансу dir, можливо, SSL-сертифікати тощо) на веб-сервері, а користувач + одна або кілька баз даних на сервері MySQL.

Додавання нового vhost вимагатиме створення маріонетки для їх створення, для видалення потрібна маріонетка запустити якийсь сценарій, який буде створювати резервні копії даних користувачів, а потім видалити живі дані з двох серверів, але також кожен запуск маріонеткового агента перевірятиме існування каталоги, db, дозволи тощо

Я запитую проблеми, коли збираються сотні сотень virtualhost з усіма тими чеками, які виконуються при кожному запуску ляльки, особливо файловій системі (на веб-сервері), і особливо, коли в майбутньому системи будуть завантажуватися більше? (скажімо, ми орієнтуємося на діапазон веб-сайтів 1000 ~ 2000 як розумний максимум на сервері).

Чи є досвід роботи з цим в мережі? Я гуглив, але нічого не знайшов, ще й тому, що при пошуку "маріонетки" та "апачі" низьке співвідношення сигнал / шум ...

Відповіді:


4

Я підозрюю, що керування багатьма віртуальними хостами apache не буде проблемою, але я не можу сказати точно. Прийнятна ефективність визначається потребами вашого бізнесу. Тільки ви можете вирішити, чи досить швидко вона. Ось гідна нитка щодо зменшення завантаження процесора: https://groups.google.com/forum/?fromgroups#!topic/puppet-users/sxtMvCnKnys evidence1-25]

Щоб узагальнити нитку:

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

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

Налаштування та видалення конфігурації не повинно бути проблемою. Найбільшою проблемою було б видалення файлів даних для веб-додатків / сайтів. Для цього я рекомендую спільне сховище, наприклад, NFS / AFS. Якщо ви не використовуєте спільне сховище, переконайтеся, що створені користувачем дані залишаються недоторканими, створюються резервними копіями або переносяться на новий сервер.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.