Как пометить изображения ECR Docker как prod и non-prod

#docker #lifecycle #amazon-ecr

#docker #жизненный цикл #amazon-ecr

Вопрос:

У меня есть конвейер CI / CD с одним JenkinsBuild.настройка jk, которая автоматически запускается всякий раз, когда запрос на извлечение был объединен с главной веткой .

У меня есть куча команд, таких как ‘docker build’ и ‘docker push’ в JenkinsBuild, которые создают версию docker-изображений, например:

x.36, x.37, x.38, x.39, x.40, x.41 , x.42, x.43, x.44, x.45 (добавлен префикс «x.» для удаления изображений без тегов).

Теперь проблема возникает, когда мне приходится развертывать несколько из этих dockerImages в prod, а не все из них. Пример — x.36 , x.40 и x.45 — это изображения, развернутые в prod, а остальные все изображения используются для среды, отличной от prod, для тестирования кода.

Когда я применяю приведенную ниже политику жизненного цикла ECR, она сохраняет 5 лучших изображений, поэтому все те версии, которые не были развернуты в prod, также сохраняются, тогда как те, которые были развернуты совсем недавно, удаляются. Пример: 5 лучших изображений, т.е. x.41, x.42, x.43, x.44, x.45, хранятся в ECR, а самые последние изображения докеров, т.Е. x.36, x.40, удалены из-за приведенной ниже политики (x.45 не удаляется, поскольку онбыл одним из 5 лучших изображений).

 {
      "rulePriority": 1,
      "description": "Keep last 5 images",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["x."],
        "countType": "imageCountMoreThan",
        "countNumber": 5
      },
      "action": {
        "type": "expire"
      }
    }
  

Может ли кто-нибудь помочь мне, как политика ECR может удалять только не-prod dockerImages?

или

Как я могу переопределить dockerImages во время развертывания prod, как стр.36, стр.40, стр.45, используя JenkinsDeploy.jk?

Пожалуйста, предложите, если сможете. Спасибо, что прочитали мой пост.

Комментарии:

1. Каковы критерии продвижения изображений в prod? Или это ручной процесс?

2. 36….41 , 42 ,43 …,45 это номера сборки, которые в основном являются java jar . Таким образом, он продвигается в зависимости от того, прошла ли сборка без ошибок, имеет полное покрытие кода и т. Д. Это продвигается вручную, поскольку функция, которую необходимо развернуть, будет находиться в конкретной версии сборки.

Ответ №1:

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

Один из способов сделать это:

  • Переименуйте тег для каждого изображения ECR, которое должно быть повышено до prod, т.Е. Запустите этот скрипт bash вручную перед продвижением:

./rename_tag.sh <repo_name> "x.36" "p.36"

 REPO_NAME=$1
IMG_TAG=$2
NEW_TAGE=$3
MANIFEST=$(aws ecr batch-get-image --repository-name "$REPO_NAME" --image-ids imageTag="$IMG_TAG" --query 'images[].imageManifest' --output text)

aws ecr put-image --repository-name "$REPO_NAME" --image-tag "$NEW_TAG" --image-manifest "$MANIFEST"

aws ecr batch-delete-image --repository-name "$REPO_NAME" --image-ids imageTag="$IMG_TAG"
  

После переименования вы будете использовать стр.36 в качестве рабочего образа.

Не забудьте обновить свою политику жизненного цикла ECR, как:

 {
    "rules": [
        {
            "rulePriority": 1,
            "description": "Keep 10 production images",
            "selection": {
                "tagStatus": "tagged",
                "tagPrefixList": ["p"],
                "countType": "imageCountMoreThan",
                "countNumber": 10
            },
            "action": {
                "type": "expire"
            }
        },
        {
            "rulePriority": 2,
            "description": "Keep 5 nonprod images",
            "selection": {
                "tagStatus": "tagged",
                "countType": "imageCountMoreThan",
                "countNumber": 5
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
  

Вы можете увеличить числа для prod, если требуется, и вы можете запустить этот скрипт в JenkinsDeploy.jk (возможно, на основе успешной сборки), но поскольку вы сказали, что prod promotions выполняется вручную, имеет смысл вызывать его вручную.