Comments 15
Не думал, что ещё кто-то IP гвоздями к хостам прибивает.
Почему-то всегда считал, что ансиблоподобные утилиты удобны когда у нас сегодня 15 инстансов, а завтра 150. И все это надо туда-сюда сворачивать-разворачивать. В этом случае если только playbook динамически генерировать с нужным ip… А уж как жить в таком случае со всякими кубернетесами, вообще не очень хорошо представляю.
Тут есть тонкий момент. Скажите, что вы можете из инфраструктуры дропнуть и поднять быстро? Сервер приложений, например. LB. Может быть, мониторинг.
А как насчёт СУБД, в которой компания хранит историю списаний по карточкам? Вы уверены, что такой сервер можно динамически создать и удалить? (Data have gravity).
Вы правы, что если инстансы создаются динамически, то руками вписывать IP'шники странно. Однако, очень удобно вписывать их роботами. (См раздел про плюсы и минусы динамических инвентори).
Мой поинт был, что указание транспорту на IP (вместо любых имён) — это правильно. Любой уровень inderect тут, это добавление в цепочку чего-то, что может либо не то закешировать, либо не то отдать, либо сломаться.
А как насчёт СУБД, в которой компания хранит историю списаний по карточкам?
Ну, например, AWS RDS не имеет статического ip от природы.
Вообще, дата — это набор где-то сложенных файлов, а БД лишь способ доступа к ним, который можно поднять в контейнере за N секунд (хотя сам я такую практику и не приветствую).
Вы правы, что если инстансы создаются динамически, то руками вписывать IP'шники странно
Скажу честно, с ансиблом почти не работал, но всегда думал, что это его основное предназначение — автоматизировать динамическую систему.
Если инфраструктура не изменяется, то как бы "топорно" это не выглядело, но установить и настроить раз в год сервер вручную может быть быстрее чем оттестировать плейбуки (которые через год все равно наполовину сломаются, потому что выйдет новая ОС/библиотеки, зависимости и т.п.)
Мой поинт был, что указание транспорту на IP (вместо любых имён) — это правильно
По-прежнему не согласен. Если в инфраструктуре нет отлаженного внутреннего DNS, которому вы можете доверять больше чем плейбукам, то вначале надо решать эту проблему.
БОльшим злом являются только захардкоденые IP.
Когда офис переезжал и глобальный IP поменялся, пришлось половину java бекенда пересобирать, потому что ограничение доступа по IP было прямо в коде.
Но если глобальный ip и его доменное имя не всегда удобно контролировать, то уж в локальной сети рабочий DNS стоять обязан.
А чтобы уровни inderect не создавать, в идеале, между пользователем и сервером должна быть только клавиатура.
PS конечно, если все автоматизировано и все ip обновляются динамически — это совсем другой разговор, хотя такая система и добавляет indirect'a еще больше чем прописывание доменных имен вручную.
Я давно стал придерживаться мысли, что хосты должны быть именованны системно, а вот группы должны динамически создаваться из их имён. Так же, вести инвентори хостов вручную, это крайне опасная ситуация (человеческий фактор). Все хосты должны быть заведены в инвентарной системе, туда например попадает автоматически из днс всё и то что добавляется руками или иными скриптами. В нашем случае это foreman, так же мы кешируем на 5 минут динамически созданный инвентори, что уменьшает нагрузку на сервис. Foreman к тому же предоставляет сервис кеширования фактов, что опять же ускоряет работу ансибл.
Это зависит от того, есть ли у вас централизация "заведения хостов". Вот, например, если у вас в инвентори есть 4 хоста, то сколько там виртуалок? И зачем нам специальная система для регистрации виртуалок? А ведь во многих архитектурах виртуалки могут жить дольше, чем гипервизоры (миграция).
Если уж доводить до некоего абсурда, то у Ансибла есть транспорт в контейнеры. Вы поды куба тоже будете в инвентори вносить?
Т.е. необходимость учёта платных ресурсов понятна, а дальше — уже вопрос.
as you wish. Если вы никогда не отлаживали проект, построенный на fqdn'ах, то вам повезло.
У всех так? Или только у меня?
Спасибо, поправил. Ссылка была на коммент в первой части.
Спасибо за цикл статей!
Вы упомянули возможность "использовать в hosts переменные, если переменные хотя бы одного хоста были инициализированы". Не то, что бы я хотел использовать это на практике (тем более, Вы прямо от этого предостерегаете), но, для общего развития, ознакомиться с возможностью хотел бы.
Подскажите, Вы имели в виду constructed inventory или что-то иное?
я, в проекте, где инвентори формируется роботами, я эту инвентори не использую как инвентори, а сохраняю в файл, который объявлен артефактом для джобы.
Дадите пример кода?
PS. Да, я понимаю, что статья 2020 года. Но вдруг автор ответит :)
Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 2