gitlab ci как не перестраивать изображения - PullRequest
1 голос
/ 20 марта 2019

Я использую gitlab ci для хранения и развертывания образов докера, но у меня возникла большая проблема.Gitlab ci перестраивает все изображения при каждом коммите ...

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

Таким образом, сборка очень бесполезна, потому что push ничего не делает: изображение уже находится в репозитории gitlab ..

Как не перестраивать изображения, когда они уже находятся в вашем gi lab репозитории?

Ниже gitlab-ci.yml

build:
   tags:
       - docker_ci_build
   services:
       - docker:dind
   script:
       - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
       - >
           docker build 
           -t $CI_PROJECT/common:6.0.1 common

Ниже файла docker:

FROM ubuntu:bionic
RUN apt-get update && \
     DEBIAN_FRONTEND=noninteractive \
     apt-get install -y packages && \
     apt-get clean && \
     rm -rf /var/lib/apt/lists/*
COPY file.conf /etc/common/

С наилучшими пожеланиями

1 Ответ

0 голосов
/ 21 марта 2019

Кэширование кажется более сложным, чем я думал, и в документации докера для различных опций извлечения не упоминаются какие-либо нюансы.

Если образ докера может существовать, а может и не существовать, вы можете настроить команду docker pull так, чтобы она передавала сборку даже в случае сбоя извлечения:

- docker image pull $LATEST || true

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

Опция --pull для сборки докера выглядела как то, что вы хотели, и документация докера гласит

- тянуть Всегда пытаться тянуть более новую версию изображения

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

- docker image pull $LATEST_IMAGE || true
- docker build --pull -t $TAGGED_IMAGE --cache-from $LATEST_IMAGE .
- docker tag $TAGGED_IMAGE $LATEST_IMAGE
- docker push $LATEST_IMAGE
- docker push $TAGGED_IMAGE

Это может быть более полезно, если ваш образ сборки многоступенчатый сборка, и может реально использовать кеш. При желании вы можете настроить скрипт gitlab-ci, чтобы избежать сборки, если изображение существует.

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

Я определяю переменные в секции variables в начале файла Последний определяется тегом :latest, который в основном является самой последней сборкой из любой ветви CI для проекта. $TAGGED_IMAGE определяется с помощью :$CI_COMMIT_SHORT_SHA, который помечает образ докера с помощью git SHA, что упрощает отслеживание развертываний kubernetes в среде разработки.

...