Режимы работы с Docker репозиториями#

SMDL имеет 2 режима работы с Docker репозиториями.

Поддержка одного релизного репозитория#

В этом режиме публикация Docker образа и дальнейшая работа с ним происходит внутри одного репозитория.

Для работы в этом режиме необходимо заполнить CIXml, не указывая параметр devRepo. Описание и пример файла смотрите в разделе «Описание CIXml» документа «Руководство по системному администрированию».

Пример:

<CIs>
  <ci>
    <number>10000017</number>
    <NexusGroupID>nexus_PROD.CI10000017_example</NexusGroupID>
    <dockerRegistryCI>ci10000017_example</dockerRegistryCI>
    <dockerRegistryProject>ci10000017_example</dockerRegistryProject>
    <nexusSegment>Example</nexusSegment>
    <artifactsId>
        <artifactId>Example1</artifactId>
    </artifactsId>
    <dockerRegistryRepo>
      <releaseRepo>releaseRepo</releaseRepo>
    </dockerRegistryRepo>
  </ci>
</CIs>

Поддержка 2 репозиториев: релизный и репозиторий для разработчиков#

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

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

Для работы в этом режиме необходимо заполнить CIXml, указав параметр devRepo. Описание и пример файла смотрите в разделе «Описание CIXml» документа «Руководство по системному администрированию».

Пример:

<CIs>
  <ci>
    <number>10000017</number>
    <NexusGroupID>nexus_PROD.CI10000017_example</NexusGroupID>
    <dockerRegistryCI>ci10000017_example</dockerRegistryCI>
    <dockerRegistryProject>ci10000017_example</dockerRegistryProject>
    <nexusSegment>Example</nexusSegment>
    <artifactsId>
        <artifactId>Example1</artifactId>
    </artifactsId>
    <dockerRegistryRepo>
      <releaseRepo>releaseRepo</releaseRepo>
      <devRepo>devRepo</devRepo>
    </dockerRegistryRepo>
  </ci>
</CIs>

Также для этого режима есть возможность задать несколько хостов для авторизации. Это необходимо если Docker репозитории, с которыми работают Jenkins Jobs, находятся на разных хостах. Для этого необходимо задать параметр buildDockerRegistryURLs в конфигурационном файле проекта и перечислить в нем все хосты.

Пример:

general:
  buildDockerRegistryURLs:
    - baseRepoHost.ru
    - devRepoHost.ru
    - releaseRepoHost.ru
  devDockerRegistryURL: devRepoHost.ru

Если хост репозитория для разработчиков отличается от хоста релизного репозитория, необходимо в конфигурационном файле проекта указать его в параметре devDockerRegistryURL либо задать параметр devDockerRegistryURL в CIXml. Описание и пример файла смотрите в разделе «Описание CIXml» документа «Руководство по системному администрированию».

Пример:

<CIs>
  <ci>
    <number>10000017</number>
    <NexusGroupID>nexus_PROD.CI10000017_example</NexusGroupID>
    <dockerRegistryCI>ci10000017_example</dockerRegistryCI>
    <dockerRegistryProject>ci10000017_example</dockerRegistryProject>
    <nexusSegment>Example</nexusSegment>
    <artifactsId>
        <artifactId>Example1</artifactId>
    </artifactsId>
    <dockerRegistryRepo>
      <releaseRepo>releaseRepo</releaseRepo>
      <devRepo>devRepo</devRepo>
      <devDockerRegistryURL>example-docker-host.ru/devRepo</devDockerRegistryURL>
    </dockerRegistryRepo>
  </ci>
</CIs>