Настройка AWS ECR для production: IAM, lifecycle, CI/CD

Почему настройка AWS ECR ломается на проде

Настройка AWS ECR обычно проходит гладко, пока реестр контейнерных образов трогает один инженер с одной машины. Как только к нему подключаются сборочные агенты, рабочие станции разработчиков и подрядчики, начинается расхождение: у одного образ залит вручную под тегом latest, у другого собран из незакоммиченного кода, а на проде в итоге крутится артефакт, который невозможно повторить. Формально реестр работает, фактически — никто не может сказать, из какого коммита собран текущий релиз.

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

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

Третья точка — переполнение хранилища образов. Без правил жизненного цикла каждый тег тянет за собой слои, объём реестра растёт линейно, и в какой-то момент сборка падает на отправке — релиз встаёт в самый неудобный момент. Разбираем, как это закрывается: где ставятся границы прав, как автоматизируется выкладка и что чистит реестр без потери возможности откатиться.

Что даёт управляемый реестр образов в ECR

Управляемый реестр — это не склад образов, а контур с политиками доступа и хранения. Роли IAM разделяют pull для сред исполнения и push для сборочного конвейера, поэтому агент сборки физически не может перезаписать тег, который уже разворачивался в production. Дополнительно включаем неизменяемость тегов: артефакт под данным тегом остаётся тем же, а попытка повторной публикации отклоняется на уровне Amazon ECR.

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

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

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

Варианты публикации образов: сравнение подходов

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

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

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

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

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

1. Аудит прав доступа и текущей схемы. Смотрим, какие репозитории и теги живут на самом деле, кто публикует образы и откуда берутся учётные данные. На выходе — карта избыточных привилегий, дублей и мест без ротации.

2. Проектирование схемы реестра. Разбиваем хранилище по окружениям и командам, фиксируем правила именования образов и тегов. Схема остаётся в описании инфраструктуры, а не в ручных настройках консоли.

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

4. Политики хранения образов. Автоудаление старых сборок с сохранением последних релизных тегов, сканирование на уязвимости, защита релизных тегов от перезаписи. Реестр перестаёт расти, откат на прошлую версию остаётся доступным.

5. Проверка на тестовом контуре. Прогоняем публикацию, выкат, откат и чтение образа из соседнего окружения. Убеждаемся, что права не шире нужного и что запись из чужого аккаунта отклоняется.

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

Комплект документации, политики и схемы реестра

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

• Роли IAM и политики доступа — права по принципу минимально необходимых: публикация из конвейера, чтение из сред исполнения и административные операции разведены по разным ролям, плюс явные границы между проектами.
• Схема именования образов — репозиторий на сервис, неизменяемый тег на релиз, отдельные теги для сред проверки; по имени сразу видно, что и откуда развёрнуто.
• Регламент очистки — lifecycle-правила с порогами: сколько последних образов держать на тег, когда удалять промежуточные сборки и с какой периодичностью пересматривать пороги.
• Конфигурация реестра как код — репозитории, проверки при загрузке и шифрование описаны файлами и применяются автоматически, без ручных правок в консоли.
• Инструкции для инженеров — как опубликовать образ, как откатиться на предыдущий релиз, что делать при отказе публикации и как запросить расширение прав.
• Схема связей с конвейером и средами — где собирается образ, куда публикуется, кто его читает и какие проверки проходят на каждом шаге.
• Порядок ревизии — кто и с какой периодичностью пересматривает политики, чтобы права не накапливались, а сроки хранения соответствовали требованиям.

Комплект передаём в ваш репозиторий с коротким разбором — дежурный инженер разберётся с реестром без обращения к нам.

Кейс: сократили время выкладки и убрали ручные шаги

Заказчик — продуктовая команда, которая собирала образы и публиковала их в реестр AWS ECR вручную: инженер тегировал сборку, заливал её и правил конфигурацию окружения перед каждым выпуском. При 12–14 публикациях в неделю это давало до 14 ручных действий в релизном цикле — и почти каждое второе отклонение в проде было связано с тем, что в окружение уходил не тот тег.

Что было до

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

Что изменили и что получилось

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

Публикация сократилась до 5–7 минут, ручных операций в релизе осталось две: подтверждение и проверка метрик. Объём реестра уменьшился втрое при полном сохранении истории релизов, а откат выполняется возвратом предыдущего тега за пару минут. Доля выпусков, откатываемых из-за неверного артефакта, ушла в ноль.

Чем отличается публикация по тегу от публикации по хешу

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

Хеш (дайджест) манифеста вычисляется из содержимого образа, поэтому переписать его незаметно нельзя: под одним идентификатором всегда лежат те же слои и та же конфигурация. Неизменяемость артефакта обеспечивает именно адресация по содержимому, а не обещание не переиспользовать тег.

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

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

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

Частые вопросы по доступам и жизненному циклу образов

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

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

Как выдать доступ внешним подрядчикам, не отдавая ключи от всего реестра?

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

Что произойдёт с уже работающей выкладкой?

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

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

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

Уточняем, прежде чем считать сроки:

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

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

Опишите задачу — вернёмся с оценкой и планом.