Комментарии 9
Если считать, что админ программирует не на конфиге nginx'а, а на ямле чего-то выше уровнем (например, ансибла), то наследование директив и т.д. - скорее, зло. Поскольку конфиги генерируются автоматом, куда лучше, если каждый конфиг будет полностью автономный (быть может, кроме top-level конфига, который просто include всё остальное).
Писать шаблоны с наследованием директив от других шаблонов - то ещё развлечение. Куда проще, когда каждый конфиг полностью автономен, и если в нём что-то не так, это сразу видно глазами. Да, итоговые конфиги получаются в N раз больше по числу строк, но их экономть - это реально "на спичках".
Где-то я эту мысль уже слышал :) Игорь Сысоев на highload++:
не слушайте людей, которые говорят, что DRY — это всеобщая парадигма. Это хорошо, когда вам нравится продукт, или вы программируете продукт. Если же вам просто нужно облегчить свою администраторскую жизнь, то copy-paste — это для вас. Ваш друг — это редактор с хорошим find-replace;
Ну, find-and-replace - это не очень хороший метод для хранения source of truth. А вот внешний генератор (у которого свой DRY) - вполне, да. Компилировать бизнес-логику в конфиг nginx'а куда разумнее, чем хранить бизнес-логику в конфиге nginx'а.
Конечно, вся логика формирования конфига и должна осуществляться генератором, но отвергать полностью наследование я бы не стал. В моем текущем проекте сейчас 30k+ vhosts, все с одинаковой логикой и на одном движке и отличаются они только одной строкой root|alias|proxy_pass. Не вижу криминала в том, что большинство директив будут описаны на максимально допустимом верхнем уровне и унаследованы.
Хотя не буду лгать - сам реализовал это через include 3-х шаблонных файлов в каждый location, но после запуска проекта очень хочу сравнить стоимость решения с наследованием, include и полностью отдельными конфигами.
Забавно. Встретились простой админ и оператор ЭВМ.
Бубен с КДПВ у каждого есть?
Я свой бубен отложил во имя лучших практик. Я могу его использовать (и использую, в основном на своём собственном железе типа домашнего компьютера и ноутбука), но хорошие производственные практики важнее конкретного джиуджицу в консоли. Всё равно всего вы знать не будете, а вот как готовиться к неизвестному - это как раз и есть лучшие практики.
Мне казалось, после пары выстрелов в ногу должно приходить понимание "чем меньше используешь if, тем лучше для психики". И споры на эту тему начнут утихать. Когда открываешь для себя map, потребность в if сводится к минимуму.
Я уж думал мне кажется. Ан нет - это таки "особенности", как их политкорректно называет автор статьи. :)
После встречи каждой такой "особенности" хотелось найти того, кто ее придумал, и... и научить принципам хорошего кода.
Nginx. О чем не хотелось писать