Настройка AMI/Image Pipeline для золотых образов

Почему ручная сборка ломает золотой образ AMI

Ручная настройка серверов не воспроизводится: инженер заходит на узел, правит конфиги, доставляет пакеты, что-то доделывает «временно» — и сервер уезжает в прод как есть. Через несколько месяцев в одном окружении живут десятки уникальных серверов, у каждого своя история правок, и ни один нельзя поднять заново в том же виде.

Дрейф конфигурации накапливается незаметно: на одном узле изменён лимит соединений, на другом осталась старая ветка библиотеки, на третьем открыт порт «на время отладки». Тесты проходят на одном сервере и падают на другом — воспроизвести ошибку нечем, потому что эталонного состояния просто не существует, а документация описывает то, что задумывалось, а не то, что работает.

Восстановление после сбоя превращается в археологию: узел поднимают по памяти, из переписки и из обрывков старых скриптов, которые давно никто не поддерживал. По отраслевым данным Uptime Institute, большинство тяжёлых аварий начинается с человеческого изменения конфигурации, а не с отказа железа, — и простой в таком сценарии измеряется часами, потому что восстановление идёт методом проб. Резервные копии тут тоже не спасают: они возвращают данные, но не состояние операционной системы и окружения.

Золотой образ AMI закрывает этот класс отказов: сборка описана кодом, версионируется и проходит проверку на стенде до публикации. Новый сервер получает ровно то состояние, которое уже было протестировано, — и разбираем, как это устроено.

Что меняется после перехода на автоматизированную сборку

Раньше новый сервер собирали руками по инструкции: набор пакетов, версии библиотек, правки конфигов — всё зависело от того, кто и в какой день этим занимался. Золотой образ AMI, который собирается автоматически из версионированного описания, убирает эту вариативность: любая сборка даёт одно и то же состояние, а не «примерно такое же».

Время сборки и вывода в эксплуатацию

• Новый сервер поднимается из образа за минуты вместо часов ручной установки и настройки.
• Базовые обновления и правки безопасности приходят одной пересборкой, а не обходом всего парка машин.
• Тестовое и рабочее окружения собираются из одного описания — расхождение видно до выката, а не после.

Сборка идёт по шагам: Packer прогоняет скрипты первичной настройки, затем образ прогоняется через автотесты и только после этого публикуется в реестр с версией и описанием изменений.

Время восстановления и предсказуемость откатов

• Восстановление после отказа — это запуск известного образа, а не разбор «что же было настроено на упавшей машине».
• Откат — переключение на предыдущую версию образа по регламенту, а не импровизация под нагрузкой.
• Простой измеряется часами недоступности сервиса; когда сборка и восстановление предсказуемы, эти часы сокращаются в разы.

Главный эффект — устраняется целый класс отказов, причина которых расхождение окружений и ручные правки «по-быстрому прямо на сервере». Предсказуемость окружений перестаёт быть договорённостью в голове у инженера и становится свойством образа.

Способы сборки образа: какой режим выбрать под задачу

Выбор режима определяет не скорость первой сборки, а то, как образ будет жить дальше: насколько просто обновить окружение во всех копиях, откатиться на предыдущий выпуск и доказать, что узел соответствует регламенту. На практике выбирают между четырьмя подходами — от сборки из шаблона вендора до съёма слепка с уже работающей машины.

Сборка из шаблона и из базовой системы

Шаблон вендора ускоряет старт — ядро, драйверы и службы уже на месте, остаётся доустановить прикладное. Обратная сторона: внутрь приезжает то, что вашей роли не нужно, а версионирование образов привязывается к чужому циклу выпуска.

Сборка из базовой системы требует описать каждый шаг в коде: пакеты, пользователей, права, конфигурационные файлы. Дороже на входе, зато версия образа соответствует версии описания, а не дате снятия слепка — обновление окружения становится повторяемой операцией.

Донастройка уже работающего сервера

Слепок с живой машины закрывает задачу за час, и на этом его достоинства заканчиваются. Правки, сделанные руками, не попадают в описание, поэтому следующий инженер не воспроизведёт состояние, а готовый образ начнёт дрейфовать: расхождения копятся медленно и всплывают в самый неудобный момент. Такой режим оправдан только как разовый перенос с обязательной последующей нормализацией в код.

Мы выбираем режим по частоте изменений и требованиям к воспроизводимости, а не по удобству первой сборки.

Как мы внедряем конвейер сборки: этапы работ

Конвейер сборки золотого образа AMI начинается не с шаблонов, а с ревизии того, что уже работает в инфраструктуре. Пока роли серверов, их службы и зависимости не описаны, образ остаётся снимком одной машины, и тиражировать его нельзя.

1. Инвентаризация серверов: собираем роли, запущенные службы, открытые порты и внешние зависимости — фиксируем, что действительно нужно в образе.
2. Схема окружений: решаем, сколько образов требуется — базовый, прикладной, под конкретную роль — и где проходят границы между ними.
3. Шаблоны конфигурации: описываем сборку как код — пакеты, разметку дисков, сетевые параметры, часовой пояс, агент мониторинга, учётные записи.
4. Сборка: шаблон прогоняется в изолированной среде и запекается в образ, поэтому результат не зависит от состояния конкретной машины.
5. Проверка образа перед выкаткой — отдельный этап, о нём ниже.
6. Передача в эксплуатацию: регламент выпуска и отката версий, порядок снятия устаревших образов.

Проверка образа перед выкаткой

Образ поднимается в чистом окружении и проходит проверки: службы стартуют после перезагрузки, сетевые параметры и доступы совпадают с эталоном, лишние сервисы и учётные записи отключены. Отдельно сверяем состав пакетов — всё, что попало в образ, должно быть обосновано шаблоном.

Без этого этапа дефект размножается по всему парку: одна ошибка в образе даёт десятки одинаково нерабочих серверов. Поэтому критерий готовности формальный — образ годен, если эталонные проверки прошли без отклонений, а расхождения с шаблоном разбираются до выкатки.

Схемы, конфигурации и регламенты пересборки

Комплект по золотому образу AMI передаём так, чтобы сборку можно было повторить без её автора: инженер открывает репозиторий, читает регламент и получает идентичный образ. Ниже — что входит в передачу на руки.

• Описание окружений: какие контуры есть и чем отличаются их параметры сборки.
• Шаблоны сборки: декларативное описание образа с зафиксированными версиями пакетов.
• Реестр версий образов: версия, родительский образ, состав изменений, где развёрнут.
• Правила доступа и роли в сборочном контуре с журналом действий.
• Жизненный цикл образа: сколько версий храним, что уходит в архив, что удаляем.
• Регламент пересборки и обновления базовой системы с критериями приёмки.
• Порядок отката на предыдущую версию, если новая ведёт себя иначе.

Правила доступа и роли

Права разделены по зонам: инженер собирает образ, но не публикует его, а выпуск в общий реестр версий — за ответственным за релиз. Доступ выдаётся по ролям, каждое действие попадает в журнал, поэтому видно, чья сборка ушла в боевой контур.

Регламент пересборки и обновлений

Базовая система обновляется по расписанию, а не по факту сбоя: сначала сборка в тестовом контуре, затем проверки, только потом перенос метки версии на актуальную. У обновления есть окно, критерии приёмки и путь назад — оно перестаёт быть событием с неизвестным исходом.

Кейс: дрейф конфигурации сократился до нуля

Парк из ~120 виртуальных машин собирали вручную по инструкции: инженер поднимал сервер из базового образа провайдера, доставлял пакеты, правил конфигурации, подключал агента мониторинга. Инструкция жила в вики и расходилась с реальностью уже через неделю после каждого релиза — правки вносили в среду, но не в документ.

Что было до

На ежемесячной сверке 30–40% машин отличались от эталона хотя бы одним пакетом или строкой конфигурации, а расхождение копилось молча: заметить его можно было только в момент отказа. Вывод нового сервера занимал 3–4 часа, из них половина — ожидание, пока освободится инженер, знающий порядок действий. Каждый пятый инцидент в среде разбирался до причины вида «на этой машине другой набор библиотек» — то есть отказы, не связанные с кодом, приходилось искать в конфигурации.

Что стало после

Сборку образа перевели в декларативное описание: Packer прогоняет один и тот же сценарий установки, а готовый образ проверяется автотестами — сервис поднимается на тестовой машине, проверяются порты, права и записи в журнале. Образ становится единственным эталоном: любая правка вносится в описание, а не в живую машину, и попадает в среду только через новую сборку.

Дрейф конфигурации сократился до нуля — сверка идёт по контрольным суммам пакетов и файлов, расхождение видно сразу и блокирует выкат. Вывод нового сервера занимает 8–10 минут без участия инженера, включая проверки. Отказы из-за несовпадения окружений ушли как класс: среда стала воспроизводимой, а откат — это возврат к предыдущему образу, а не ручная починка.

Что делать, если серверы уже настроены вручную

Серверы, настроенные руками, переводят на эталон без остановки сервисов — если текущее состояние сначала фиксируется как воспроизводимое описание, а не переписывается по памяти администратора. Порядок: снять фактическую конфигурацию, собрать золотой образ AMI, сверить расхождения, перенести окружения по одному, держать рабочий откат до конца наблюдения.

Сверка расхождений — самый недооценённый этап. С узлов снимаются пакеты и версии, конфиги, юниты служб, права на каталоги, задачи по расписанию и слушающие порты; всё сводится в манифест, расхождения по машинам — в отдельный отчёт. Видно, где ручная правка несёт нагрузку и переходит в описание, а где остался след отладки — эталон не должен унаследовать мусор вместе с лишними классами отказов.

Эталон собирается из декларативного описания: пакеты, настройка, агенты мониторинга и логирования, требования безопасности. Сборка идёт через Packer — образ воспроизводим, версионируется и не меняется после запуска: правки вносятся в описание и пересборку, а не в живой сервер. Переносим окружениями, а не машинами — сначала непродуктивный контур, затем группа за балансировщиком, после подтверждения по метрикам остальные.

Откат заложен заранее: прежние узлы не удаляются, а выводятся из балансировки и остаются в резерве. Если группа на эталоне даёт рост ошибок или задержек, трафик возвращается на неё одной правкой маршрута — без пересборки и простоя. Устаревшие серверы гасим последними, после полного цикла обновления и закрытого окна наблюдения.

Частые технические сомнения перед стартом

До старта обычно остаются три вопроса: сколько занимает сборка с проверками, что делать при обновлении базовой системы и кто ведёт конвейер после передачи. Ниже — ответы с той детализацией, которая нужна для решения.

Что делать, когда выходит обновление базовой системы?

Образ собирается из описания, а не из ручных правок на живой машине. Обновился базовый слой — конвейер заново прогоняет сборку и проверки и публикует новый золотой образ, а предыдущий остаётся доступным для отката. Периодичность обновлений — по расписанию или по событию безопасности — фиксируем в регламенте: так окружения не расходятся между собой.

Кто отвечает за конвейер после передачи?

Передаём репозиторий с описанием образа, политики очистки реестра, документацию и обучение вашей команды. Дальше возможны два режима: инженеры заказчика сами правят описание и запускают сборку либо мы остаёмся на поддержке по согласованному регламенту — с окном реакции и плановым обновлением базовых слоёв.

Обсудим задачу и вернёмся с планом сборки

Чтобы оценка и план опирались на факты, а не на догадки, на входе нужен минимум вводных: состав окружений, частота изменений и требования к откату. Ниже — что присылаете вы; по этим данным мы выстраиваем порядок работ.

• Состав окружений. Сколько контуров, чем они отличаются — набор сервисов, сетевые правила, доступы — и где сейчас расходятся версии.
• Частота изменений. Что меняется в образах — системные пакеты, агенты мониторинга, параметры безопасности — и как быстро это нужно доставлять.
• Требования к откату. За какое время нужно вернуть предыдущий образ, кто принимает решение и сколько версий держать в хранении.
• Регламент выпуска. Кто и как инициирует сборку, какие проверки считаются обязательными перед публикацией.
• Ограничения и доступы. Требования аудита, политики безопасности, запреты на внешние источники пакетов, порядок выдачи прав.
• Целевые площадки. Где образы разворачиваются и какие проверки должны пройти до публикации.

В ответ вы получаете карту окружений, схему сборки, правила версионирования и хранения образов, а также порядок работ с этапами и контрольными точками. Опишите задачу в свободной форме — вернёмся с оценкой и планом сборки золотого образа.