GitLabCIパイプラインでDockerイメージを構築する方法

Shell executorを使用している場合は、ランナーをホストするマシンにDockerがインストールされていることを確認してください。エグゼキュータは、dockerを使用して通常のシェルコマンドを実行することで機能します ランナーのホスト上のバイナリ。

イメージをビルドするプロジェクトのGitリポジトリに移動します。 .gitlab-ci.ymlを作成します リポジトリのルートにあるファイル。このファイルは、プロジェクトに変更をプッシュしたときに実行されるGitLabCIパイプラインを定義します。

次のコンテンツをファイルに追加します：

stages:
  - build

docker_build:
  stage: build
  script:
    - docker build -t example.com/example-image:latest .
    - docker push example.com/example-image:latest

この単純な構成は、パイプラインを利用したイメージビルドの基本を示すのに十分です。 GitLabはGitリポジトリをビルド環境に自動的に複製するため、docker buildを実行します プロジェクトのDockerfileを使用します リポジトリのコンテンツをビルドコンテキストとして利用できるようにします。

ビルドが完了したら、docker pushを実行できます レジストリへの画像。それ以外の場合は、ビルドを実行したローカルのDockerインストールでのみ使用できます。プライベートレジストリを使用している場合は、docker loginを実行します 最初に適切な認証の詳細を提供します：

script:
  - docker login -u $DOCKER_REGISTRY_USER -p $DOCKER_REGISTRY_PASSWORD

GitLabWebUIで[設定]>[CI/ CD]> [変数]に移動して、2つのクレデンシャル変数の値を定義します。青い[変数の追加]ボタンをクリックして、新しい変数を作成し、値を割り当てます。 GitLabは、これらの変数を、ジョブの実行に使用されるシェル環境で使用できるようにします。

DockerExecutorを使用したビルド

GitLab RunnerのDockerエグゼキューターは、通常、各ジョブに完全にクリーンな環境を提供するために使用されます。ジョブは分離されたコンテナで実行されるため、docker Runnerホストのバイナリにアクセスできなくなります。

Docker executorは、イメージをビルドするための2つの可能な戦略を提供します。Docker-in-Dockerを使用するか、ホストのDockerソケットをRunnerのビルド環境にバインドします。次に、公式のDockerコンテナイメージをジョブのイメージとして使用して、dockerを作成します。 CIスクリプトで使用可能なコマンド。

Docker-in-Docker

Docker-in-Docker（DinD）を使用してイメージを構築すると、ジョブごとに完全に分離された環境が得られます。ビルドを実行するDockerプロセスは、GitLabRunnerがCIジョブを実行するためにホスト上に作成するコンテナーの子になります。

DinDを使用するには、特権モードを有効にしてGitLabRunnerDockerエグゼキューターを登録する必要があります。 --docker-privilegedを追加します ランナーを登録するときにフラグを立てる：

sudo gitlab-runner register -n 
  --url https://example.com 
  --registration-token $GITLAB_REGISTRATION_TOKEN 
  --executor docker 
  --description "Docker Runner" 
  --docker-image "docker:20.10" 
  --docker-volumes "/certs/client" 
  --docker-privileged

CIパイプライン内に、docker:dindを追加します サービスとしての画像。これにより、Dockerはジョブのイメージにリンクされた個別のイメージとして利用できるようになります。 dockerを使用できるようになります docker:dindのDockerインスタンスを使用してイメージをビルドするコマンド コンテナ。

services:
  - docker:dind

docker_build:
  stage: build
  image: docker:latest
  script:
    - docker build -t example-image:latest .

DinDを使用すると、相互に影響を与えたり、ホストに影響を与えたりすることのない、完全に分離されたビルドが得られます。主な欠点は、より複雑なキャッシュ動作です。各ジョブは、以前に構築されたレイヤーにアクセスできない新しい環境を取得します。ビルドする前に以前のバージョンのイメージをプルしてから、--cache-fromを使用することで、これに部分的に対処できます。 プルされたイメージのレイヤーをキャッシュソースとして使用できるようにするためのビルドフラグ：

docker_build:
  stage: build
  image: docker:latest
  script:
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build --cache-from $CI_REGISTRY_IMAGE:latest -t $CI_REGISTRY_IMAGE:latest .

sudo gitlab-runner register -n 
  --url https://example.com 
  --registration-token $GITLAB_REGISTRATION_TOKEN 
  --executor docker 
  --description "Docker Runner" 
  --docker-image "docker:20.10" 
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock

script:
  - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  - docker build -t $CI_REGISTRY_IMAGE:latest .
  - docker push $CI_REGISTRY_IMAGE:latest

docker_build:
  stage: build
  image: $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX/docker:latest
  services:
    - name: $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX/docker:dind
      alias: docker

FROM ubuntu:latest

ARG GITLAB_DEPENDENCY_PROXY
FROM ${GITLAB_DEPENDENCY_PROXY}/ubuntu:latest

script:
  >
    - docker build 
        --build-arg GITLAB_DEPENDENCY_PROXY=${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX} 
        -t example-image:latest .