Как лучше всего поддерживать согласованность файлов httpd.conf и php.ini на нескольких веб-серверах за балансировщиком нагрузки?
Я мог периодически синхронизировать файлы или программировать собственный сценарий развертывания. Какие еще варианты мне не хватает?
В идеале вы должны настроить сервер управления конфигурацией с помощью Puppet или других подобных инструментов (например, cfengine).
Лучшая практика, которую я мог бы предложить в отношении конфигурации сервера в целом:
"Никогда не входите в систему, чтобы что-либо изменить на ней. Всегда вносите изменения на [сервер управления конфигурацией] и позволяйте изменению распространяться" (взято из http://www.infrastructures.org/papers/bootstrap/bootstrap.html)
С уважением, Алекс
За нашими веб-узлами стоит кластер NFS. Мы символически связываем расположение конфигурационных файлов по умолчанию для Apache и PHP с общими копиями в общей папке NFS. Затем очень простой сценарий оболочки выполняет некоторые базовые операции (перестраивает правила Apparmor и т. Д.), А затем выполняет итерацию по веб-узлам, запуская сначала apache2ctl configtest а потом apache2ctl graceful.
Другие идеи:
rsync или scp.svn можно использовать как для управления версиями, так и для распространения файлов конфигурации. Также можно использовать git или bzr и т. д.
отредактируйте файлы на «главном» сервере, svn зафиксируйте их, и либо задание cron, либо ssh может запустить затем «svn update» на «подчиненных» серверах.
Я обычно использую ssh и настраиваю доступ без пароля, чтобы разрешить `` главному '' серверу запускать определенный Makefile на подчиненных устройствах - Makefile запускает svn update, а правила зависимости на основе файловых меток решают, что еще нужно быть выполнено (например, сгенерировать хешированные файлы пользователя или группы db из текста, добавить или удалить IP-адреса из nic, перезапустить apache и т. д. - в любое время, когда вы можете определить, что последовательность действий зависит от изменения файла и / или другая последовательность действий - хороший кандидат на использование make для автоматизации процесса).
даже на «главном» сервере все управляется make. отредактируйте один или несколько файлов конфигурации, а затем запустите make. Makefile определяет, что нужно сделать (svn commit, генерировать фрагменты конфигурации из исходных файлов ввода, ssh make для других серверов и т. д.). использование make таким образом гарантирует, что каждый шаг будет выполнен в правильном порядке и ни один шаг не будет забыт. и делая svn неотъемлемой частью процесса, гарантирует, что каждое изменение фиксируется с отметкой времени и объяснением в журнале фиксации.
конечно, многие использовали бы марионетку или что-то в этом роде для этого. если бы я начал с нуля, я бы, наверное, тоже ... но я делал это так много лет, задолго до того, как марионетка появилась. подобные инструменты были и до марионетки, но марионетка - это первая из тех, что я видел, и похоже, что ее действительно стоит изменить ... но трудно оправдать изменение чего-то, что хорошо работает, для чего-то, что только выглядит как это, вероятно, будет работать лучше.
Есть несколько решений.
Большой вопрос: как в настоящее время синхронизируется ваш КОНТЕНТ (или динамические скрипты, которые обращаются к вашей базе данных для контента)? Если задуматься, файлы конфигурации - это просто еще один вид контента.
На данный момент у меня есть скрипт на каждом веб-сервере, который копирует конфигурацию из общего ресурса и обновляет информацию о конфигурации для обработки локального сервера (ip и т. Д.). Хотя это нормально работало для 3 серверов, на 10 серверах это раздражало (вход на сервер, запуск сценария, выход из системы, промывка, промывка, повтор). Я бы предложил решение (например, марионетку и друзья), которое отправит изменения на сервер, когда вы завершите свои изменения в локальном файле.