
Комментарии 13
с подключением!
Модуль - это сценарий, который поставляется вместе с Angie.
И фактически не вполне корректно, и опечатка в слове Ansible. Исправить бы надо.


Статья беззастенчиво понадёргана из книжки Ansible: Up and Running, с заменой Nginx на Angie и топонимов на российские. Хоть бы источник указали.
Замечание в тему, Вы правы, данная книга была в числе источников материала для данной статьи. Поясню как это работает у меня. Есть куча мест, откуда я, да и все прочие беру информацию. Это и статьи в интернете, и книги, и чужие конфиги, и чужой код. Всё это в виде заметок попадает в общий конспект на определённую тему. Что-то я могу применить сразу у себя и указать свой пример, а что-то не могу и сохраняю пример из источника, где я его увидел, чтобы понимать про что сделал запись. А потом получилось, что конспект этот передал паре знакомых и им пригодилось, так что решил его причесать и выложить, авось кому-нибудь облегчит жизнь. Я бы и с радостью указал что, откуда и в каком количестве было взято, но не смогу найти уже да и, вероятно, статья сильно увеличится в объёме. Но претензию Вашу понимаю и принимаю, в конце концов без неё бы не заметил опечатку, так что спасибо!
Беда в том, что мало что это кривой перевод прям кусков из книги (ладно бы пересказ - я бы понял, да и "кривой" можно списать на мои придирки), но ведь и терминология хромает на обе ноги. Вам не зря написали "с подключением" - статья прям телепортирует на десять лет назад, когда статьи по Ansible были вновинку и их писали разве что реже чем сейчас про ИИ. Вы запутываете терминологически:
Основой Ansible являются сценарии. Сценарием или плейбуком называется файл, который описывает порядок управления конфигурациями.
Что ещё за сценарии? Основой Ansible является Play!
В общем, база по Ansible хорошо описана в документации, best practicies прекрасно описал @amarao: https://habr.com/ru/articles/508762/ - всем очень советую. Остальное всё - от Лукавого :)
Можно ходить от одной железки к другой и делать всё руками, но это медленно и непродуктивно, сгодится максимум для дома.
Ничего не имею против всяких ansible, но вот как показывает моя практика их применение сильно преувеличено. Как правило это хорошо годится когда вам надо управлять или создать постоянно и много однотипных хостов (управление рабочими станциями, хостинг). А вот в других случаях проще создать несколько шаблонов куда залито и настроено что надо всегда. Из шаблона создаем рабочий и допиливаем руками необходим образом. Писать же плейбуки под задачи это тоже время, отладка, отслеживание изменений и т.д. Опять же, если этим постоянно заниматься, а если нет, то забываешь какие там скобочки, отступы и прочее. А установка руками заставляет еще раз посмотреть как это собирается, что на что влияет и т.д., хорошая возможность пересмотреть какие-то моменты.
Писать же плейбуки под задачи это тоже время, отладка, отслеживание изменений и т.д.
Установка руками это тоже время, отладка, отслеживание изменений и т.д.
А установка руками заставляет еще раз посмотреть как это собирается, что на что влияет и т.д., хорошая возможность пересмотреть какие-то моменты.
На память вы весь процесс установки с кучей нюансов не запомните и обязательно напишете себе инструкцию. А инструкция по установке — это и есть плейбук. И вместо чтения ручной инструкции вы всегда можете прочитать плейбук и пересмотреть в нём какие-то моменты
Такой вариант тоже имеет право на жизнь и да, часто это кажется удобнее и проще. У ансибла, паппета и прочего похожего инструментария возможности сильно гибче. Во-первых, идемподентность. Если кто-то что-то навертел на хосте, то его можно вернуть к исходному виду, не затронув то, что работает как надо. Если же проходить руками или скриптом заново, то, скорее всего, будет снесено всё. Во-вторых, минимизация ошибок, если плейбук грамотно составлен, то может быть применён много где без глобальных изменений. Есть опыть настройки множества коммутаторов руками, и вот, глядя на все телодвижения с высоты сегодняшнего дня, жалею, что тогда ансибл не применял, но тогда бы и не вышло. Ну и в третьих, плейбуки можно и не писать, а взять готовые, в конце концов в yaml довольно просто разобраться, это не json. Да и в четвёртых добавлю шаблонизацию. Как пример, если ставить какой-нибудь пакет, или разворачивать контейнер, то в скольких местах придётся менять одну цифру или строчку с выходом новой версии? В ансибле же можно просто поменять значение переменной. Сейчас готовлю статью, там будет кейс, где ансибл я использовал довольно извращённо для разворачивания и настройки waf, получилось с виду сложно, но благодаря шаблонам это работало. Понятно, что для одного, двух или трёх сильно разных ПК такая автоматизация избыточна, но если уже есть даже небольшой офис, то рутинные задачи это сильно облегчит.
его можно вернуть к исходному виду
Плейбук не вернёт то, что не контролирует, так что от верчения хоста он не защищает
плейбуки можно и не писать, а взять готовые
Я не понял прикола готовых ролей и плейбуков, они настраивают систему так, как хочет их автор, а не так, как хочу я
в yaml довольно просто разобраться, это не json
Хорошая шутка https://ruuda.nl/2023/the-yaml-document-from-hell
У нас ребята для настройки коммутатора используют охidized. Он и сохраняет сам и раскатать конфиг на новый (замену) раз плюнуть. Т.е. это опять клонирование, а не написание.
Плэйбук ничего не вернет о чем в нем не сказано. Ну к примеру кто-то убил ваш apache2 запустив nginx на ваших портах. Как плэбук отслеживающий только apache2 отцепит nginx?
Никто настолько глобально анализирующий плэйбук не будет писать, или там можно еще место на диске проверять и т.д. Все это круто когда вы разворачиваете систему.
Насчет рутинных и не спорю изначально, большой парк машин однотипно обслужить это понятно.
Первоначальная система всегда идет руками. Потом пишется плейбук, сохраняются конфиги. Инструкцию я по любому напишу, а плейбук писать и отлаживать не буду скорее всего, чтобы сейчас повторить на втором я копию сделаю, а потом... ну когда это будет. "Но глядя на тебя я вспоминаю то, что даже не знал, что забыл"(c)БГ
У нас обычно используется подход "Infrastructure as a Cat" Black cat in the dark room...
Базированый Ansible