Итак, у нас есть шаг, который генерирует docker изображение.
Следующий шаг использует изображение для запуска теста, но, ссылаясь на него с помощью тега LOCAL, чтобы избежать связи с нашим удаленным реестром (сохранить время и трафик c).
облако build.yaml:
steps:
- name: 'gcr.io/cloud-builders/docker'
entrypoint: bash
args: ['./build_image.sh','$PROJECT_ID','base-image']
- name: 'base-image:latest'. #This should ensure there's no need for an "actual" pull
args: ['-f', './verify_image.ps1']
build_image. sh
#!/bin/bash
project=$1
applicationName=$2
version=1.0.3
image="gcr.io/$project/$applicationName:$version"
local_image="$applicationName:latest"
docker build -t $image .
echo "Tag image to make it locally availiable so we dont have to do a new pull"
docker tag $image $local_image
docker push $image
# docker run $local_image #works
Это работает большую часть времени на GCB , Но время от времени шаг 2 завершается неудачно с:
Step #2: Already have image (with digest): base-image:latest
Finished Step #2
ERROR
ERROR: build step 2 "base-image:latest" failed: starting container: Error response from daemon: No such image: base-image@sha256:XXXX
Я могу воспроизвести это, если сначала запустим 10 перестроений одного и того же коммита, а затем 0-5 перестроений вызовут эту ошибку. Мы используем эту конструкцию в нескольких местах и делаем наш процесс сборки нестабильным.
GCB использует docker версию:
Docker версия 19.03.5, сборка 633a0ea838
Я искал объяснение этой ошибке, но безуспешно.
Вещи, которые я пробовал:
Я подтвердил, что оба тега существуют, и что дайджесты верны на шаге 1 и шаге 2 для базового изображения. Как вы можете видеть, шаг 2 подтверждает, что образ с дайджестом существует, но в следующей строке, где я ожидаю, что GCB выполнит «docker run base-image: latest», по некоторым причинам, иногда это не так.
Я попытался выполнить docker, используя локальный тег, на шаге 1, и он работает (образ запускается), но сразу после шага 2 происходит сбой с вышеприведенным сообщением, утверждая, что изображение существует, но его нет.
Протестировано с официальным изображением Google Builder docker и последним официальным docker изображением. Тот же результат.
Каждая сборка на GCB выполняется на своем собственном хосте vm, поэтому каждый шаг - это контейнер docker, работающий на том же vm. Я считаю, что демон docker размещен на виртуальной машине, а не в контейнерах. Вот почему можно использовать локальный тег и избежать тяги. Но каким-то образом состояние повреждается в локальном реестре / демоне или локальный тег не регистрируется. Состояние гонки?
На практике мы используем эту настройку, чтобы первый шаг решал, какую версию базового образа использовать на втором шаге (frameworks, et c), основываясь на содержимом * 1059 сборка репозитория, а затем на следующем шаге мы можем просто ссылаться на локальное изображение как base-image: latest. Это делает наш процесс сборки более упорядоченным и позволяет нам вносить «динамические» изменения, не мешая другим разработчикам специально. У нас есть много продуктов, использующих очень небольшое количество фреймворков аналогичным образом, так что это имеет смысл.
Если у кого-то есть какие-либо предложения, как решить / исправить / обойти эту проблему, пожалуйста, помогите:).
С уважением, Кристиан