#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 выполняется вручную, имеет смысл вызывать его вручную.