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

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

У меня есть куча команд, таких как «сборка докеров» и «подталкивание докеров» в JenkinsBuild, которые создают версии образов докеров, например:

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

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

Когда я применяю приведенную ниже политику жизненного цикла ECR, она сохраняет 5 лучших образов, поэтому все те версии, которые не были развернуты в рабочей среде, также сохраняются, а те, которые были развернуты последними, удаляются. Пример: первые 5 образов, т. е. x.41, x.42, x.43, x.44, x.45, хранятся в ECR, а последние prod dockerImages, т. е. 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 может удалять только нерабочие dockerImages?

or

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

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


docker amazon-ecr lifecycle
person Aastha Jain    schedule 08.10.2020    source источник
comment
Каковы критерии продвижения изображений в прод? Или это ручной процесс?   -  person amsh    schedule 08.10.2020
comment
36....41 , 42 ,43 ...,45 - это номера сборки, которые в основном представляют собой java jar . Таким образом, он продвигается в зависимости от того, прошла ли сборка без ошибок, имеет ли полное покрытие кода и т. д. Он продвигается вручную, поскольку функция, которую необходимо развернуть, будет в конкретной версии сборки.   -  person Aastha Jain    schedule 09.10.2020

Ответы (1)


arrow_upward
0
arrow_downward

Так как нет шаблона производства изображений 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 выполняется вручную, имеет смысл вызывать его вручную.

person amsh    schedule 08.10.2020