Как сократить время извлечения докера во время сборки CI?

Question

Я использую GitLab Runner в своем кластере Kubernetes для запуска заданий CI.Я хочу, чтобы задания по сборке работали быстрее.

Чтобы сделать их быстрее, я повторно использую образ Docker из предыдущей сборки (помеченный как latest).Время сборки уменьшилось, но теперь узким местом является команда pull, которая занимает примерно 60-70% времени.

Вот фрагмент кода .gitlab-ci.yml:

build:sheets:
  stage: build
  image: docker:stable
  services:
    - docker:dind
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" "$CI_REGISTRY" --password-stdin
  script:
    - docker pull $SHEETS_LATEST || true
    - docker build --cache-from $SHEETS_LATEST --tag $SHEETS_TAG --tag $SHEETS_LATEST .
    - docker push $SHEETS_TAG
    - docker push $SHEETS_LATEST

Я использую Gitlab Registry и, таким образом, команда pull требует большой связи между моим кластером и реестром.

Итак, у меня есть пара вопросов:

1. Стоит ли пытаться развернуть мой собственный реестр докеров в кластере, чтобы сэкономить пару минут на сборку?

2. Есть ли способ сохранить образгде-нибудь на кластере не тянуть из реестра каждый раз?

Answer 1

Существует несколько способов более быстрой сборки образов Docker в конвейере.

1. DOOD (Docker вне Docker)

Здесь вы должны смонтировать /var/lib/docker.sock хоста внутри вашего контейнера сборки.Это уязвимо.Но все еще слишком быстро.

DIND (Docker in Docker)

Здесь вы можете использовать dind image, который имеет как docker cli, так и daemon.Он не связывается с демоном докера хоста.Весь процесс сборки будет происходить в модуле.Не на 100% безопасно, но быстрее.

Kaniko, Makisu, Buildah

Это инструменты для создания образов нового поколения без демонов, которые не зависят от демона Docker.Более безопасный, чем DOOD и DIND, также быстрее и поддерживает кэширование.

Answer 2

Gitlab разделяет бегунов, не имеют вашего предыдущего изображения доступны (как вы заметили). Таким образом, ваши варианты либо тянуть его, как вы делаете, или идти со своими бегунами. В прошлый раз, когда я посмотрел, он не был доступен с бегуном kubernetes, который можно установить на странице интеграции с gitlab kubernetes, поэтому мне пришлось развернуть свои собственные бегуны.

Вот развертывание, которое создает 4 бегунов (todo: выяснить автомасштабирование) и регистрирует их как событие postStart. Вам нужно будет получить регистрационный токен со страницы настроек / cicd для вашего проекта или группы (https://gitlab.com/[user]/[project]/settings/ci_cd).). Вам также придется отключить общих участников на той же странице.

kind: Deployment
metadata:
  name: gitlabrunner
  labels:
    app: gitlabrunner
spec:
  replicas: 4
  selector:
    matchLabels:
      app: gitlabrunner
  template:
    metadata:
      labels:
        app: gitlabrunner
      name: gitlabrunner
    spec:
      containers:
      - name: gitlabrunner
        image: gitlab/gitlab-runner
        volumeMounts:
        - name: dockersock
          mountPath: "/var/run/docker.sock"
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "gitlab-runner register -n --url https://gitlab.com/ --registration-token [YOUR_REGISTRATION_TOKEN] --executor docker --description 'My Docker Runner' --docker-image 'docker:stable' --docker-volumes /var/run/docker.sock:/var/run/docker.sock"]
      volumes:
      - name: dockersock
        hostPath:
          path: /var/run/docker.sock

Answer 3

Вы можете запустить выделенный модуль с демоном Docker внутри с постоянным томом, смонтированным в / var / lib / docker. После этого вы выставляете этот модуль, используя сервис, названный, например, «Докер». После этого в ваших CI-заданиях вы определяете переменную среды "DOCKER_HOST = tcp: // docker".

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

Не забывайте следить за использованием дискового пространства на постоянном томе и периодически запускать «удаление системы Docker».