Сейчас я использую Mercurial для синхронизации похожих конфигураций Apache между серверами производства и разработки. Очередь патчей поверх этого добавляет изменения и дополнительные вещи, необходимые для сервера разработки.
Схема работает, но могла бы быть и лучше. Я всегда получаю конфликты слияния, когда повторно применяю очередь исправлений после извлечения изменений из конфигураций развертывания. У меня такое чувство, что я всегда вношу идентичные изменения в отдельные файлы конфигураций http:// и https://.
Как мне вычленить одинаковые биты из моих конфигураций Apache :80 и :443 и более аккуратно добавить «дополнительные биты» в конфигурацию разработки?
решение1
Возможно, вы захотите рассмотреть возможность использованияВключатьособенность системы конфигурации Apache. Затем отделите элементы вашей конфигурации, которые являются специфичными для отдельной машины, в_local.confэто должно сделать слияние более простым
решение2
Apache имеет возможность выборочно включать определенные конфигурации. Это позволяет использовать один и тот же файл конфигурации для разработки и производства. Запустите apache с -DDEVELOPMENT или -DPROD, и вы сможете использовать теги для конфигурации, которая специфична для сервера dev. Таким образом, вы не получите никаких конфликтов слияния (конечно, если вы не измените оба файла конфигурации dev/prod перед слиянием)
решение3
Это может быть старомодным, но мои конфигурации Apache для стадии и производства были идентичны, за исключением того, что некоторые параметры в каждой из них были разными (например, IP-адрес). Я использовал обертку perl вокруг стартового скрипта, чтобы методично «заполнить пробелы». Фактические «шаблоны» базовой конфигурации были действительно идентичны.
Это гарантировало, что сценический Apache был функционально идентичен производственному Apache.
Предоставление этой конфигурации производства разработчикам позволило им проводить тестирование настолько близко к производству, насколько им было нужно (а они хотели этого, потому что они не могли попасть в производство, если их вещи не «работали» на этапе разработки). Время от времени мы предоставляли помощь (например, для правил mod_rewrite), а остальное оставляли разработчику.
Разница между этой конкретной установкой и другими местами, где я работал, заключается в следующем:
Сотрудников отдела разработки поощряли заниматься областями, не связанными напрямую с программами, над которыми они работали... то есть: они могли работать над внутренними приложениями (поэтому им не нужно было много знать об Apache), но при этом они настраивали свои собственные серверы Apache (фактически создавали свои собственные рабочие столы, но, по моему скромному мнению, это уже перебор).
На самом деле, операции во многом управляли инфраструктурой, а не просто ее эксплуатировали.