⁠#ECR-репозиторий имеет ограничение в 1000 образов максимум. Когда у вас активный процесс разработки, то этот кажущийся большим лимит очень даже быстро достигается и вы получаете много удовольствия от упражнений по изучению логов под названием "ну вчера же работало".

Даже если лимит не проблема, то бардак из тьмы билдов (обычно на каждую ветку) обеспечен плюс некоторые расходы, но они минимальны (хотя, конечно, зависит от размеров образов).

Светлая мысль "с этим что-то нужно делать" помноженная на гугление в попытках что-то найти и отсортировать в AWS консоли по работе с ECR докер-образами — очень скоро приведёт вас в уныние. Не расстраивайтесь, это не вы верблюд - там действительно не работает пэйджер (фильтры применяются лишь к одной странице). Пусть вас успокаивает факт, что они страдают точно также.

В общем смысл следующий - нужно настроить ECR LifecyclePolicy. Пишем правила, какие тэги сколько живут и добавляем каждому репозиторию, в результате порядок будет поддерживаться автоматически.

Если репозиторий один, то можно и потыкать ручками, однако если десятки? Тогда используем для этого секретную менюшку Edit JSON (на картинке внизу), откуда можно скопировать натыканное и размножить для других репозиториев.

Тяжело разбираться без примеров, потому вот реально используемый вариант #LifecyclePolicy:

{
 "rules": [
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 180,
       "tagStatus": "tagged",
       "tagPrefixList": [
         "develop"
       ]
     },
     "description": "clean 'develop*' after 180 days",
     "rulePriority": 10
   },
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 180,
       "tagStatus": "tagged",
       "tagPrefixList": [
         "feature"
       ]
     },
     "description": "clean 'feature*' after 180 days",
     "rulePriority": 20
   },
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 180,
       "tagStatus": "tagged",
       "tagPrefixList": [
         "hotfix"
       ]
     },
     "description": "clean 'hotfix*' after 180 days",
     "rulePriority": 30
   },
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 1,
       "tagStatus": "untagged"
     },
     "description": "clean Untagged after 1 day",
     "rulePriority": 40
   }
 ]
}

В дополнение к предыдущему посту по #ECR #LifecyclePolicy - в идеале такое должно быть автоматизировано с помощью #CloudFormation #templates.

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

https://github.com/applerom/cloudformation-examples/blob/master/ecs/ecr-repo.yml

Как видно в шаблоне - LifecyclePolicy прописывается в чистом виде (JSON). Там же для удобства добавлен шаринг для других аккаунтов, что всегда требуется в случае #multi_account_strategy (если не нужен - просто комментируем). Всё легко кастомизируется под свои значения и любимые скрипты.

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

#всё_под_контролем