Управление конфигурацией
Пространства имён
Действия на странице
Конфигурация — это знание о том, какова работающая (актуальная) система, выделенная из множества ее возможных вариантов. Конфигурация находится под контролем, если конфигурация определения системы соответствует конфигурации воплощения системы. Если какие-то части этих конфигураций не соответствуют друг другу, то говорят о конфигурационных коллизиях.
Управление конфигурацией (configuration management) — техническая дисциплина системной инженерии, обеспечивающая поддержание надлежащей (задуманной, одобренной) конфигурации системы во время всего её жизненного цикла. Если говорить попроще, то управление конфигурацией — это практика, обеспечивающая на протяжении всего жизненного цикла совместимость версий (отсутствие коллизий!) и полноту частей системы (отсутствие коллизий!).
Управление конфигурацией — практика системноинженерного менеджмента — она занимается поддержанием целостности системы на протяжении всего ЖЦ. В рамках этой практики выпускаются различные виды спецификаций закупаемого/изготавливаемого оборудования/изделий — BOM (bill of materials, список комплектующих).
Отнесение управления конфигурацией к системной инженерии означает, что конфигурация обязательно относится ко всей системе.
Управляющий конфигурацией — системный инженер, наряду с инженером по требованиям, системным архитектором, интегратором.
Содержание
Основные понятия
Управление конфигурацией включает в себя следующие понятия:
Практики
Управление конфигурацией, в том числе и управление изменениями невозможно рассматривать отдельно от управления данными (управления информацией, интеграции данных жизненного цикла и т.д.). Сюда попадают следующие практики:
Дисциплина управления конфигурацией имеет следующие основные основные практики:
Основные принципы
Управление конфигурацией очень просто, когда есть один административный центр, который вводит
При распределенной разработке (collaborative engineering, concurrent engineering) каждая из участвующих в проекте организаций имеет собственные предпочтения по управлению конфигурацией (кодировки, учётные регламенты, версионирование). Собрать из этого распределенного конфигурационного месива базис обычно представляет собой непростую задачу.
Так, любая PLM-система поддерживает управление конфигурацией. Но если в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ), а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.
Коллизии, возникающие из проблем управления конфигурацией — самые распространенные. Отсутствие управления конфигурацией как раз и характеризуется словами «у них там бардак». Поэтому разворачивание технологии управления конфигурацией — центральная забота при создании СУЖЦ.
Управление конфигурацией требует:
Инструментарий
Для управления конфигурацией определения системы сейчас используют информационные системы:
Управление конфигурацией
Как управление конфигурацией помогает техническим командам создавать надежные и стабильные системы
В 1950-х годах Министерство обороны США разработало техническую управленческую дисциплину для отслеживания изменений при разработке сложных систем. У этой системы и ее итераций были сугубо технические названия, но в 2001 году Министерство опубликовало сводное руководство, в котором закрепило понятие системы технического управления. Сегодня это называется «управление конфигурацией». В настоящее время управление конфигурацией используется не только в министерстве обороны, но и при разработке программного обеспечения, управлении ИТ-услугами, в гражданском строительстве, промышленном машиностроении и многих других отраслях.
Что такое управление конфигурацией?
Управление конфигурацией — это процесс проектирования систем, позволяющий обеспечить единообразие атрибутов продукта на протяжении всего жизненного цикла. В технологическом мире управление конфигурацией представляет собой процесс управления ИТ, который используют для отслеживания отдельных элементов конфигурации ИТ-системы. ИТ-системы состоят из ИТ-ресурсов различной степени детализации. ИТ-ресурсом может быть часть программного обеспечения, сервер или кластер серверов. Далее основное внимание уделяется управлению конфигурацией, поскольку оно применяется непосредственно к программным ИТ-ресурсам, а также процессам CI/CD программных ресурсов.
Управление конфигурацией программного обеспечения — это процесс системного проектирования, предназначенный для отслеживания изменений в конфигурационных метаданных программных систем. При разработке программного обеспечения управление конфигурацией обычно используется совместно с системами контроля версий и инфраструктурой CI/CD. В этой статье описывается современное применение управления конфигурацией в гибких программных средах CI/CD.
Важность управления конфигурацией
Управление конфигурацией помогает техническим командам создавать стабильные и надежные системы с помощью инструментов, которые автоматически управляют обновлениями конфигурационных данных и отслеживают их. Сложные программные системы состоят из компонентов, различающихся по размеру и сложности. В качестве конкретного примера приведем архитектуру микрослужб. Каждая служба в такой архитектуре использует конфигурационные метаданные для собственной регистрации и инициализации. Вот несколько примеров конфигурационных метаданных программного обеспечения.
Эти конфигурационные значения могут легко отойти на второй план, что приведет к беспорядку и разрозненности в конфигурации. Представьте себе множество стикеров с паролями и URL-адресами, разлетающихся по всему офису. Управление конфигурацией решает эту проблему благодаря централизованному «достоверному источнику информации» для конфигурации.
Git — это потрясающая платформа для управления конфигурационными данными. Перенос конфигурационных данных в репозиторий Git позволяет контролировать версии и использовать репозиторий в качестве достоверного источника информации. Контроль версий также решает другую проблему конфигурации, а именно — непредвиденные изменения, приводящие к сбою. Управление непредвиденными изменениями с помощью проверок кода и контроля версий помогает свести время простоя к минимуму.
Конфигурационные значения часто добавляются, удаляются или изменяются. Без контроля версий это может создавать проблемы. Участник команды может скорректировать значение распределения аппаратных ресурсов, чтобы оптимизировать работу программного обеспечения на своем ноутбуке. Но при дальнейшем развертывании программного обеспечения в рабочей среде эта новая конфигурация может оказаться недостаточно эффективной либо привести к сбою.
Контроль версий и управление конфигурацией решают эту проблему, обеспечивая прозрачность конфигурационных изменений. При внесении изменений в конфигурационные данные система контроля версий отслеживает их: участники команды видят изменения в журнале.
Контроль версий конфигурации позволяет выполнять откат (отмену) конфигурации и тем самым избегать непредвиденных сбоев. С помощью контроля версий конфигурации можно быстро вернуться к последнему известному стабильному состоянию.
Как управление конфигурацией вписывается в принципы DevOps, CI/CD и Agile
С самого начала конфигурационные данные тяжело поддаются обработке и легко могут выпасть из поля зрения. Они не являются настоящим кодом и поэтому не сразу попадают в систему контроля версий. Их также нельзя отнести к настоящим данным, поэтому они не хранятся в первичной базе данных. Традиционное и маломасштабное системное администрирование обычно выполняется с помощью набора скриптов и специальных процессов. Конфигурационные данные нередко остаются без внимания, но они крайне важны для работы системы.
Рост количества облачных инфраструктур привел к разработке и внедрению новых моделей управления инфраструктурой. Развертывание сложных облачных системных архитектур и управление ими выполняется с помощью файлов с конфигурационными данными. Новые облачные платформы позволяют командам указывать необходимые аппаратные ресурсы и сетевые подключения с помощью человеко- и машиночитаемых файлов данных, таких как YAML. Затем эти файлы данных считываются, а инфраструктура становится доступна в облаке. Такая модель называется «инфраструктура как код», или «IaC-обработка».
Управление конфигурацией DevOps
В первые годы разработки интернет-приложений администрирование аппаратных ресурсов и систем выполнялось в основном вручную. Системные администраторы обрабатывали конфигурационные данные, после чего на их основе вручную подготавливали аппаратные ресурсы и управляли ими.
Управление конфигурацией — это основной элемент жизненного цикла DevOps. Конфигурация DevOps возникла в результате развития и автоматизации роли системного администратора: она позволяет автоматизировать управление инфраструктурой и ее развертывание.
Конфигурация DevOps также предполагает сдвиг ответственности за системное администрирование в сторону разработчиков ПО. Сегодня предприятия используют ее для того, чтобы специалисты по программному обеспечению могли запрашивать и подготавливать необходимые ресурсы по требованию. Это позволяет устранить потенциальное узкое место в организационной зависимости для команды разработчиков ПО, которые ожидают, пока отдельная команда системного администрирования не выделит необходимые ресурсы.
Управление конфигурацией CI/CD
В управлении конфигурацией CI/CD используются рабочие процессы проверки кода на основе запросов pull, которые автоматизируют развертывание изменений кода в действующей системе программного обеспечения. Эти процессы можно применять и к изменениям конфигурации. Принцип CI/CD можно настроить таким образом, чтобы подтвержденные запросы на изменение конфигурации сразу развертывались в работающей системе. В качестве примера такого процесса можно привести рабочий процесс GitOps.
Управление конфигурацией Agile
Управление конфигурацией позволяет командам, следующим принципам Agile, четко оценивать работу по конфигурированию и расставлять в ней приоритеты. В качестве примеров работы по конфигурированию можно назвать следующие рутинные операции и задания.
После создания платформы управления конфигурацией команды получают представление о работе, которую необходимо проделать для выполнения настройки. Работу по управлению конфигурацией можно определить в виде зависимостей для других работ и выполнять ее в рамках agile-спринтов.
Инструменты для управления конфигурацией
Git — ведущая система контроля версий, отслеживающая изменения в коде. При добавлении кода и данных для управления конфигурацией в репозиторий Git команды получают целостное представление о версиях всего проекта и могут управлять ими. Git — это базовый инструмент управления конфигурацией более высокого уровня. Приведенные далее инструменты управления конфигурацией предназначены для сохранения данных в репозиторий Git и отслеживания версий Git.
Docker
Контейнеризация Docker — это улучшенная форма управления конфигурацией (как, например, и блокировка конфигурации). В основе Docker лежат конфигурационные файлы Dockerfiles, которые содержат список команд и оцениваются при восстановлении ожидаемого снимка состояния операционной системы. Эти файлы представляют собой снимки предварительно настроенного приложения; на их основе создаются контейнеры. Для отслеживания версий Dockerfiles помещают в репозиторий Git, а для развертывания этих файлов в инфраструктуре необходимо дополнительное управление конфигурацией.
Terraform
Terraform — платформа для управления конфигурацией с открытым исходным кодом, созданная компанией HashiCorp. На платформе Terraform подготовка кластеров, облачной инфраструктуры или служб и управление ими выполняется с помощью IaC-обработки. Terraform поддерживает Amazon Web Services (AWS), Microsoft Azure и другие облачные платформы. Каждая облачная платформа имеет собственный способ представления и интерфейс для стандартных компонентов инфраструктуры, таких как серверы, базы данных и очереди. На Terraform создан уровень абстракции инструментов конфигурации для облачных платформ, благодаря чему команды могут писать файлы, которые являются воспроизводимыми определениями их инфраструктуры.
Ansible, SaltStack, Chef и Puppet
Ansible, SaltStack и Chef — это платформы автоматизации ИТ. Они автоматизируют многие стандартные процессы системного администрирования. Каждая платформа использует ряд конфигурационных файлов данных (обычно YAML или XML), которые оцениваются исполняемым файлом.
В конфигурационных файлах данных указана последовательность действий, которые необходимо выполнить для настройки системы. Впоследствии эти действия выполняются исполняемым файлом. Язык исполняемого файла в разных системах различается: Ansible и SaltStack основаны на Python, а Chef — на Ruby. Этот рабочий процесс аналогичен запуску специальных скриптов оболочки, но предлагает более структурированный и усовершенствованный интерфейс через экосистемы соответствующих платформ. Эти инструменты обеспечивают автоматизацию, необходимую для достижения CI/CD.
Как внедрить управление конфигурацией
Обнаружение
Для внедрения управления конфигурацией первым действием необходимо собрать информацию. Конфигурационные данные должны быть агрегированы и скомпилированы из различных прикладных сред, среды разработки, раздела проиндексированных файлов и рабочей среды для всех используемых компонентов и служб. Любые секретные данные, такие как пароли и ключи, должны быть идентифицированы, надежно зашифрованы и сохранены. На этом этапе конфигурационные данные необходимо упорядочить в файлах данных, которые станут централизованным достоверным источником информации.
После агрегирования и упорядочения конфигурационных данных можно определить базу. Базовая конфигурация — это известное состояние конфигурации, при котором зависимое программное обеспечение будет работать без ошибок. Для создания базы обычно проводится анализ конфигурации функционирующей рабочей среды с последующим коммитом этих настроек конфигурации.
Контроль версий
В проекте разработки рекомендуется использовать систему контроля версий. Если ее нет, установите Git, инициализируйте репозиторий для проекта и добавьте в этот репозиторий конфигурационные файлы данных. Предупреждение: перед добавлением конфигурационных данных в репозиторий убедитесь, что все секретные данные, такие как пароли или ключи, зашифрованы с помощью внешнего ключа. Секретные данные, случайно помещенные в репозиторий, представляют собой большую угрозу. Их следует вычистить из истории репозитория, в противном случае ими могут воспользоваться.
Аудит
Упорядоченные конфигурационные данные, добавленные в репозиторий, позволяют вести совместную работу и делают конфигурацию системы прозрачной. Популярный рабочий процесс с запросом pull, который команды разработчиков используют для проверки и редактирования кода, можно применять и к конфигурационным файлам данных. Это помогает создать систему отчетности и аудита. Любые изменения, вносимые в конфигурацию, должны быть проверены и приняты командой. Это повышает ответственность и обеспечивает прозрачность изменений конфигурации.
Заключение
Управление конфигурацией является обязательным инструментом для управления сложными программными системами. Его отсутствие может привести к серьезным проблемам с надежностью, уровнем доступности и масштабированием системы. Многие современные средства разработки программного обеспечения имеют встроенные возможности управления конфигурацией. Решение Bitbucket предлагает мощную систему управления конфигурацией, построенную на основе рабочих процессов с запросами pull в системе Git и конвейеров CI/CD.
Подпишитесь и получайте больше статей
Thanks for signing up!
Составление карт потоков создания ценности (VSM)
Составление карт потоков создания ценности — это метод анализа, помогающий оптимизировать конвейер непрерывной поставки. Узнайте, как и для чего используется этот метод.
DevSecOps: Обеспечение безопасности в конвейерах CD
Термином DevSecOps обозначается цикл разработки программного обеспечения с непрерывной поставкой, в котором особое внимание уделяется безопасности. DevSecOps опирается на рекомендации DevOps.
Принудительное введение в системы управления конфигурациями
Abstract: как заставить себя изучить любую из существующих систем конфигураций и перестать редактировать файлы на сервере руками.
Пост посвящён душевной боли, которую нужно преодолеть. Ещё в посте будет чуть-чуть технического, но большей частью пост посвящён борьбе с самим собой, отложенному вознаграждению и тому, насколько моторная память котролирует вас.
Введение для отшельников, которые не слышали что такое configuration management systems
Уже многие годы (по айтишным меркам — три поколения как) существуют программы, которые позволяют автоматизировать процесс конфигурации серверов. Все эти программы сложные, они вторгаются в святую святых администраторов и заставляют их делать «всё не так, как раньше». Их изучение и интернализация (признание, что «так надо и так правильно») — абсолютный must have в карьере любого системного администратора.
Главная боль любой системы управления конфигурациями
Главная боль состоит в том, что система управления конфигурациями ломает привычную автоматику пальцев. Раньше вы могли поднять веб-сервер за 2 минуты почти не глядя на экран. Теперь вам предлагают потратить на абсолютно те же самые действия минут 15-20 (если вы хорошо знаете систему управления конфигурациями) или даже несколько дней (. ), если вы её изучаете.
Это преступление против личной эффективности. Уменьшить её в десять (0xA) раз — и это они называют прогрессом?
Вне зависимости от всех остальных аргументов, эта мысль будет преследовать вас всё время. Даже спустя годы. Вы не просто нажимаете больше кнопок для того, чтобы сделать то же самое, но и вынуждены делать это медленнее, вы вынуждены ждать компьютер (никогда раньше вам не надо было ждать десятки секунд пока редактор «отредактирует» файл и перезапустит веб-сервер). Хуже, в момент, когда вы пишите примитивную конструкцию в конфиге, вы будете вынуждены бороться с лишними пробелами в DSL’е (специальном птичьем языке программирования, который надо выучить); думать о всякой невероятно сложной посторонней фигне; делать специальные услуги роботам. Отладка будет хуже и отвратительнее — вместо нормального сообщения об ошибке из-за опечатки в конфиге вы будете получать невнятную oversharing простыню вывода на два экрана, чтение которой занимает больше времени, чем «пойти и сделать вручную».
Ещё хуже: часто эти простыни будут касаться не ваших действий, а совершенно несвязных изменений в других местах проекта. И вы будете вынуждены с ними разбираться. Иногда это будут даже баги системы управления конфигурациями и вы будете чинить/обходить баги вместо того, чтобы заниматься своей прямой работой.
Ну как, я «продал» вам эту технологию? Готовы отбиваться всеми силами от попыток внедрить её на рабочем месте?
Перед тем, как мы продолжим говорить про системы управления конфигурациями, я хочу показать на очень иллюстративный пример из психологии зефирный эксперимент. Для тех, кому лениво читать Википедию, пересказ: детям дают зефирку, и говорят, что если они её не съедят за 15 минут, то им дадут вторую (и обе можно будет съесть). Чем старше ребёнок, тем больше вероятность, что он продержится 15 минут. Малыши не могут себя сдержать и съедают зефирку сразу, хотя потом становится обидно. Этот эксперимент проверяет механизм «отложенного удовольствия».
Именно это и предлагают системы управления конфигурациями. Вы тратите пол-часа на операцию, которую вы можете руками сделать за 3 минуты, а потом эту операцию можно выполнять снова и снова (когда нужно) без затраты трёх минут. И главное, без вовлечения головы. Чаще всего эту процедуру делегируют CI-серверу (jenkins, buildbot, etc), и тогда это открывает дверь для первого шажка к волшебной двери по имени CI/CD.
Staging
А этот шажок называется ‘staging’. Копия вашего продакшена, которая ничем не занимается. На которой вы можете посмотреть ответ на вопрос «что будет, если я поменяю версию сервера?» и другие смешные эксперименты, не сломав ваш продакшен.
Безусловно, staging можно сделать и без систем управления конфигурациями. Но кто будет следить за тем, что staging похож на продакшен? Более того, кто будет следить, что после вашего смешного эксперимента стейджинг всё ещё похож на продакшен? Если вы делаете смешной эксперимент на результате предыдущего смешного эксперимента, то возможно, результат будет отличаться от того, что получится потом на продакшене.
Этот вопрос «кто будет следить?» на самом деле с подковыркой. Если у вас не гигантский раздутый штат в котором у вас может быть пара человек, которые следят за staging’ом, то ответ на него «никто». Никто не следит. Что же делать?
Ответ: «до основанья мы разрушим,» и пересоздадим с нуля. Если в этом процессе от человека требуется больше минуты времени, то, разумеется, никто этого делать не будет. Слишком уныло снова и снова делать то же самое ради исправления «смешного эксперимента».
Обычная мысль «Да чего его переподнимать, я сейчас всё назад верну руками, так быстрее». На выходе — смешной эксперимент и результат его исправления, вместо «копии продакшена».
А вот если есть робот, который «пойдёт и всё сделает сам», вот тогда да, никакой проблемы. Пошёл и сделал.
Размножение staging’ов
Если переподнять стейджинг так просто, то почему бы его не поднять в ещё одном экземпляре? Он может быть попроще, в нём не будет какой-то из важных сложных тяжёлых компонент, но нужный кусок, над которым вы работаете прямо сейчас — почему бы и нет?
А ещё он может быть на localhost’е, в виртуалке или контейнере. Что даёт вам практически нулевую латенси при работе (приятно), поддержку оффлайнового режима (полезно). Это потребует чуть-чуть работы с системой управления конфигурациями, но куда меньше, чем может показаться. А дальше — тык-тык и у вас свежий кусок копии продакшена (или даже чего-то специфичного для вашего фичебранча из гита).
Рефакторинг
После того, как у вас есть написанный процесс превращения нескольких серверов в продакшен и вы можете повторять его снова и снова (малыми усилиями), вы вольны начинать менять кусочки этого процесса (на более удобный/правильный/модный процесс) и смотреть что получилось.
Это требует второй части системы управления конфигурациями — валидации серверов. Об этом мы поговорим чуть позже, но пока сфокусируйтесь на простой идее: вы можете попробовать поменять что-то в процессе конфигурации сервера и посмотреть что получится. За бесплатно. (От себя: когда я не уверен, я иногда запускаю 2-3 версии в параллель на разных стейджингах чтобы выбрать лучший).
code review
Рефакторинг и хранение инструкций для системы управления конфигурациями в гите делает возможным проводить code review (если у вас больше одного человека в команде). code review это круто! Во-первых он дисциплинирует не оставлять кривизны. Во-вторых вы учитесь у друг друга как делать лучше. В третьих это увеличивает взаимное знание о проекте и происходящих в нём изменениях. Развивая линию ci/cd, с некоторыми усилиями можно даже видеть результаты прогона предлагаемых изменений на временной инсталляции — и робот может завернуть pull request просто потому, что он «всё ломает» — no human involved.
Тесты
Если у нас есть набор инструкций для системы управления конфигурацией, то мы можем проверить результат. Для этого есть масса интересных решений: testinfra, goss, inspec, serverspec, etc. Фактически, эти тесты позволяют проверить результат применения вашей конфигурации. Например, «на 80ом порту слушают», «в мониторинге появилось 180 чеков», «пользователь Х может залогиниться на сервер» и т.д. Когда у вас появляются такие тесты, то вы можете уже сколько угодно играться с процессом — если тесты проходят, то вы всё сделали правильно. Благодаря этому, вы можете пробовать новое (дерзкое) и не бояться неожиданного (например, «ой, я же не подумал, что включение SSL сломает весь мониторинг»).
Job security
Системы управления конфигурациями напрямую угрожают рабочим местам низкоквалифицированных системных администраторов. Если раньше нам нужно было 20 администраторов, каждый из которых мог управлять 20 серверами, то теперь команда из трёх (чуть-чуть более квалифицированных администраторов) прекрасно может справляться с 400 серверами. На самом деле один тоже может справляться, но 2-3 дают большую компетенцию команде, меньший бас-фактор (концентрацию знаний у единственного человека) и улучшают атмосферу в коллективе благодаря взаимной ответственности за качество работы. И с job security всё просто. Либо вы в списке этих трёх администраторов, либо нет.
На самом деле я чуть-чуть лукавлю и реальность обычно выглядит так: вместо 60 серверов у трёх администраторов у них на руках оказывается 400 (1000? 2000?) серверов, и варианта «нанять ещё 17 администраторов» просто не стоит по бюджетным причинам. Но это особенности растущего рынка и дефицита квалифицированных кадров, а общий аргумент всё равно остаётся: системы управления конфигурациями повышают эффективность труда, и на рынке оказываются более востребованы люди с более высокой эффективностью труда.
Ещё одна программа, которая требует внимания
При всей позитивности необходимости вышесказанного, любая система управления конфигурациями — всего лишь программа. Это означает, что будут баги. В том числе обидные требующие делать неудобно и некрасиво лишь бы обойти баг. Это означает, что очевидные архитектурные фичи не будут реализованы просто потому, что у программистов иное видение направления движения проекта. Это означает, что вместо части документации будет «Документация» (которая находится в каталоге src ). Как любая другая программа, она будет требовать внимания к своему внутреннему миру, уделения себе времени, компетенции (и ещё времени на обучение).
И ещё раз о смене парадигмы
Всё это (включая баги и глубокий внутренний мир) — потребует адаптации мышления под модель, которая диктуется системой управления конфигурации. Управление конфигурациями — крайне инвазивная сущность, которая хочет быть главной во всём, и многие рабочие процессы придётся подстраивать под требования этой программы. Будет множество граничных моментов, когда станет хуже (раньше можно было сделать лучше и проще), будет множество раз, когда будет ощущение выполнения нелепого ритуала вместо нормальной работы.
Но вместе с этим будет и ещё одно ощущение — что стало меньше кнопкодавства и стало больше думания. Вместо «пойти и поменять» будет момент размышления «а правильно ли менять так?», «А почему его вообще надо менять?», будет больше рассуждений об архитектуре (почему на сервере А мы меняем одно значение а на сервере Б другое? Можем ли мы найти что-то общее между этими изменениями и описать это общее как новую сущность?)
Онтология, или 2nd hard problem
Онтологические проблемы будут в полный рост. Размышления над «общим для разных изменений» будут постоянно приводить к появлению новых вещей, а новые вещи требуют имён. Придумывать же имена, как известно, это вторая сложная проблема в IT (первая — инвалидация кеша), и она сложна потому, что придуманное название определяет свойства и ожидания от объекта. И вам придётся каждый раз мучительно придумывать имена. Каждая ошибка — кусок кривизны в архитектуре. Если раньше изменения были «потому что надо поменять», то теперь изменения будут, потому что «так нужно для реализации свойств сепульки». Я старался избегать анекдотических примеров (из жизни), но всё-таки приведу. У меня в одном проекте ушло три недели на то, чтобы придумать имя «системная конфигурация» (для описания той части изменений, которые затрагивают настройки серверов и требуют использования ansible, как противоположность «программной конфигурации», для описания той части, которая не требует вмешательства ансибла). Идея оказалась разумной и помогла разделить невозможно переплетённый комок зависимостей «надо поменять на сервере А но только после того, как пользователь поменяет в интерфейсе Б, но если пользователь поменяет В, то нам А трогать не надо, а если пользователь поменяет Е, то поменяется В и Б, так что нам надо как-то одновременно поменять и конфигурацию сервера, и ту часть, которая ансиблом не конфигурируется». Уф… Давно забытый ужас. Который надо было прочувствовать, продумать и найти имя для отдельной сущности внутри него.
Переезд с фронтира в бэк-офис
Жизнь админа становится всё меньше похожа на жизнь админа. Профессия разделяется на тех, кто пишет конфигурацию и тех, кто её сопровождает (т.е. остаётся на фронтире, наедине с сервером). Таких иногда называют SRE, и в зависимости от критичности проекта в каждый момент времени, это может быть как очень крутая и важная профессия, так и «апгрейженный саппорт».
С чего начать?
Если я вас чуть-чуть мотивировал, но вы не знаете, с чего начать, то начните с поиска системы управления конфигурациями, которая вам по душе. Это Ansible, cfengine, Chef, Juju, Puppet, SaltStack, Quattor, etc. Вероятнее всего, список не полон. Ни одно из этих решений не является хорошим (на мой взгляд), но это лучшее, из того, что у нас есть. Выбор такой системы частично нужно основывать на известных языках программирования (это моё IMHO), ощущении от синтаксиса и жизнеспособности проекта.
После выбора ПО, не стоит бросаться с головой. Читать умные книги по такой системе надо, играться тоже можно до любого уровня сложности, но внедрять стоит очень ограниченно, не теряя контроля над ситуацией. Это означает, что начинать надо с простой автоматизации длительных действий (перепишите свой любимый скрипт деплоя на языке системы управления конфигурацией), попробуйте в него записать хотя бы часть того, что делаете руками.
postscriptum
Одним из интереснейших лайфхаков с системами управления конфигурациями, я считаю лабораторное применение. Когда исследуется новое ПО, то конфигурация этого ПО силами системы управления конфигурациями позволяет «попробовать снова» (если не ясно, делает ли ПО сайд-эффекты по серверу).
Заодно, описание для робота «что делать» отлично подходит на роль эскизного проекта внедрения. Одно время я отлаживал corosync, который не хотел работать в сети с лимитом на unknown unicast/multicast. В ходе отладки мне пришлось несколько десятков раз переподнимать кластер. Когда это делалось ansible’ом, «несколько десятков раз» не стали подвигом, а пришли к чему-то уровня «перезапустить лабораторию».
Ежедневное применение систем управления конфигурациями требует перестройки самых базовых инстинктов работы с серверами, но взамен очень неприятной learning curve даёт на руки не только инструмент для повышения эффективности труда, но и смену модели поведения и мышления на более эффективную. Это очень тяжёлый шаг, но шаг, который нужно обязательно сделать.
