Dockerイメージの使用

GitLab Runnerと連携したGitLab CI/CDは、Docker Engineを利用してあらゆるアプリケーションのテストやビルドを行えます。

Dockerはオープンソースのプロジェクトで、事前に定義されたイメージを使用してアプリケーションを独立した「コンテナ」に入れて単一のLinuxインスタンス内で実行できます。Docker Hubにはアプリケーションのテストやビルドに使用できるように、事前にビルドされた豊富なイメージが用意されデータベース化されています。

GitLab CI/CDと併用する場合、.gitlab-ci.ymlに設定したイメージを使用して、Dockerは各ジョブを個別に隔離されたコンテナで実行します。

これにより、ワークステーション上でも実行できるシンプルで再現性の高いビルド環境を、簡単に構築できます。また、後ほど説明するコマンドをすべて専用のCIサーバでテストするのではなく、シェルからテストできるという利点もあります。

Docker Runnerを登録する

GitLab RunnerをDockerで使用するには、新しいRunnerを登録してDocker executorを使用する必要があります。

以下に例を示します。まず、サービスを提供するための一時的なテンプレートを設定します。

cat > /tmp/test-config.template.toml << EOF
[[runners]]
[runners.docker]
[[runners.docker.services]]
name = "postgres:latest"
[[runners.docker.services]]
name = "mysql:latest"
EOF

そして、先ほど作成したテンプレートを使ってrunnerを登録します。

sudo gitlab-runner register \
  --url "https://gitlab.example.com/" \
  --registration-token "PROJECT_REGISTRATION_TOKEN" \
  --description "docker-ruby:2.6" \
  --executor "docker" \
  --template-config /tmp/test-config.template.toml \
  --docker-image ruby:2.6

登録されたrunnerはruby:2.6のDockerイメージを使用し、postgres:latestmysql:latestの両方もしくはどちらかのサービスをビルド時にアクセスします。

imageとは

imageというキーワードは、Docker executorがCIタスクを実行するために使用するDockerイメージの名前です。

デフォルトでは、executorはDocker Hubからのイメージのプルのみを行いますが、gitlab-runner/config.tomlDockerプルポリシーを設定することで、ローカルイメージの使用を許可できます。

イメージとDocker Hubの詳細については、Docker Fundamentalsのドキュメントをお読みください。

serviceとは

servicesキーワードは、ジョブ中に実行される別のDockerイメージを定義し、imageキーワードが定義したDockerイメージにリンクされます。

サービスイメージはどのようなアプリケーションでも実行できますが、最も一般的な使用例はmysqlなどのデータベースコンテナを実行することです。プロジェクトがビルドされるたびにmysqlをインストールするよりも、既存のイメージを使用して追加コンテナとして実行する方が簡単で高速です。

データベースサービスだけではなく、.gitlab-ci.ymlに必要なサービスを追加したり、config.tomlを手動で変更できます。Docker Hubやプライベートコンテナレジストリにあるイメージをサービスとして利用できます。

サービスは、CIコンテナ自体と同じDNSサーバー、検索ドメイン、および追加ホストを継承します。

関連文書のCIサービスの例では、広く利用されているサービスの例を参照できます。

サービスをジョブに連携するには

コンテナ連携の仕組みを理解するには、コンテナの連携を読んでください。

要約すると、アプリケーションにサービスとしてmysqlを追加した場合、そのイメージでジョブコンテナと連携したコンテナを作成します。

MySQLのサービスコンテナは、ホスト名mysqlでアクセスできます。そのため、データベースサービスにアクセスするためには、ソケットやlocalhostの代わりにmysqlというホストに接続しなければなりません。詳しくはサービスへのアクセスをご覧ください。

サービスのヘルスチェックの仕組み

サービスは、ネットワークからアクセス可能な追加機能を提供するように設計されています。それはMySQLやRedisのようなデータベースや、Docker上でDockerを使えるようにするdocker:stable-dindがあります。CI/CDジョブを進めるために必要なものであれば、ネットワークからアクセス可能なものであれば何でも構いません。

Runnerでジョブを成功させるためには。

  1. デフォルトでコンテナから公開されているポートをチェックします。
  2. これらのポートがアクセス可能になるのを待つ特別なコンテナを起動します。

チェックの第2段階が失敗した場合、サービスにオープンされているポートがないか、タイムアウト前にサービスが正しく起動されておらずポートが応答していないか、いずれかの理由で次のような警告が表示されます。*** WARNING: Service XYZ probably didn't start properly

ほとんどの場合はジョブに影響を与えますが、警告が出力されていてもジョブが成功する場合があります。例えば、警告が出力されていてもジョブが成功する場合があります。

  • 警告が出て少し経ってからサービスが開始され、最初から連携しているサービスを利用していないジョブが出てきました。その場合ジョブがサービスにアクセスする必要があったときには、すでに接続待ちの状態になっていた可能性があります。
  • サービスコンテナはネットワークサービスを提供していませんが、ジョブディレクトリに何か操作をしています(すべてのサービスは/buildsの下にジョブディレクトリをボリュームとしてマウントしています)。この場合、サービスはそのジョブを実行をしますが、ジョブはそれに接続しようとしていないので、失敗することはありません。

どのようなサービスがあるか

前述したように、この機能はネットワークアクセスサービスを提供するために設計されています。このようなサービスの最もシンプルな例としては、データベースがあります。

Note: サービス機能はservicesイメージのソフトウェアを、ジョブのコンテナに追加するようには設計されていません。

例えば、ジョブに以下のサービスが定義されている場合、phpnodegoコマンドはスクリプトで利用できず、ジョブは失敗します。

job:
  services:
    - php:7
    - node:latest
    - golang:1.10
  image: alpine:3.7
  script:
    - php -v
    - node -v
    - go version

phpnodegoをスクリプトで利用できるようにする必要がある場合は、どちらかを選択する必要があります。

  • 必要なツールをすべて含む既存のDockerイメージを選択します。
  • 必要なツールがすべて含まれている独自のDockerイメージを作成し、それをジョブに使用します。

サービスへのアクセス

例えば、アプリケーションのAPI統合をテストするためにWordpressのインスタンスが必要だとします。

その場合、あなたの.gitlab-ci.yml内で、例えばtutum/wordpressイメージを使用できます。

services:
  - tutum/wordpress:latest

サービスエイリアスを指定しなかった場合、ジョブ実行時にtutum/wordpressが起動し、ビルドコンテナから2つのホスト名でアクセスできるようになります。

  • tutum-wordpress
  • tutum__wordpress
Note: RFCによりアンダースコアを含むホスト名は有効でないため、サードパーティのアプリケーションで問題が発生する可能性があります。

サービスのホスト名のデフォルトのエイリアスは、これらのルールに従って、そのイメージ名から作成されます。

  • コロン(:)以降はすべて削除されます。
  • スラッシュ(/)はダブルアンダースコア(__)に置き換えられ、メインのエイリアスが作成されます。
  • スラッシュ(/)はダッシュ(-)に置き換えられ、セカンダリエイリアスが作成されます(GitLab Runner v1.1.0以降が必要です)。

デフォルトの動作を上書きするために、サービスのエイリアスを指定できます。

.gitlab-ci.ymlからimageservicesを定義する

すべてのジョブで使用するイメージと、ビルド時に使用するサービスのリストを定義するだけです。

default:
  image: ruby:2.6

  services:
    - postgres:11.7

  before_script:
    - bundle install

test:
  script:
    - bundle exec rake spec

イメージ名は、以下のいずれかの形式でなければなりません。

  • image: <image-name>(<image-name>latestタグを付けるのと同じです)
  • image: <image-name>:<tag>
  • image: <image-name>@<digest>

また、ジョブごとに異なるイメージやサービスも定義可能です。

default:
  before_script:
    - bundle install

test:2.6:
  image: ruby:2.6
  services:
    - postgres:11.7
  script:
    - bundle exec rake spec

test:2.7:
  image: ruby:2.7
  services:
    - postgres:12.2
  script:
    - bundle exec rake spec

または、imageservicesのための拡張設定オプションを渡すことができます。

default:
  image:
    name: ruby:2.6
    entrypoint: ["/bin/bash"]

  services:
    - name: my-postgres:11.7
      alias: db-postgres
      entrypoint: ["/usr/local/bin/db-postgres"]
      command: ["start"]

  before_script:
    - bundle install

test:
  script:
    - bundle exec rake spec

環境変数をサービスに渡す

また、カスタム環境variablesを渡して、Dockerimageservicesを直接.gitlab-ci.ymlファイルで設定可能です。詳細はカスタム環境変数を参照ください。

# The following variables will automatically be passed down to the Postgres container
# as well as the Ruby container and available within each.
variables:
  HTTPS_PROXY: "https://10.1.1.1:8090"
  HTTP_PROXY: "https://10.1.1.1:8090"
  POSTGRES_DB: "my_custom_db"
  POSTGRES_USER: "postgres"
  POSTGRES_PASSWORD: "example"
  PGDATA: "/var/lib/postgresql/data"
  POSTGRES_INITDB_ARGS: "--encoding=UTF8 --data-checksums"

services:
  - name: postgres:11.7
    alias: db
    entrypoint: ["docker-entrypoint.sh"]
    command: ["postgres"]

image:
  name: ruby:2.6
  entrypoint: ["/bin/bash"]

before_script:
  - bundle install

test:
  script:
    - bundle exec rake spec

拡張Docker設定オプション

GitLabとGitLab Runner 9.4で導入されました。

imageservicesのエントリを設定する際には、オプションとして文字列またはマップを使用できます。

  • 文字列をオプションとして使用する場合は、使用するイメージのフルネーム(Docker Hub以外のレジストリからイメージをダウンロードしたい場合はレジストリ部分も含めて)でなければなりません。
  • オプションとしてマップを使う場合は、少なくともnameオプションを含む必要があります。

例えば、以下の2つの定義は等しくなります。

  1. imageservicesのオプションとして文字列を使用します。

    image: "registry.example.com/my/image:latest"
       
    services:
      - postgresql:9.4
      - redis:latest
    
  2. imageservicesのオプションとしてマップを使用します。image:nameの使用が必須です。

    image:
      name: "registry.example.com/my/image:latest"
       
    services:
      - name: postgresql:9.4
      - name: redis:latest
    

imageに利用可能な設定

GitLabとGitLab Runner 9.4で導入されました。

設定 必須 GitLabバージョン 説明
name 他のオプションと併用する場合は必須 9.4 使用するイメージのフルネーム。必要に応じてレジストリ部分を含む必要があります。
entrypoint いいえ 9.4 コンテナのエントリポイントとして実行されるべきコマンドやスクリプトです。コンテナの作成時にDockerの--entrypointオプションに変換されます。構文はDockerfileENTRYPOINTディレクティブに似ていて、各シェルトークンは配列内の個別の文字列になります。

servicesで利用可能な設定

GitLabとGitLab Runner 9.4で導入されました。

設定 必須 GitLabバージョン 説明
name 他のオプションと併用する場合は必須 9.4 使用するイメージのフルネーム。必要に応じてレジストリ部分を含む必要があります。
entrypoint いいえ 9.4 コンテナのエントリポイントとして実行されるべきコマンドやスクリプトです。コンテナの作成時にDockerの--entrypointオプションに変換されます。構文はDockerfileENTRYPOINTディレクティブに似ていて、各シェルトークンは配列内の個別の文字列になります。
command いいえ 9.4 コンテナのコマンドとして使用されるべきコマンドまたはスクリプトです。イメージ名の後にDockerに渡される引数に変換されます。構文はDockerfileCMDディレクティブに似ていて、各シェルトークンは配列内の個別の文字列です。
alias いいえ 9.4 ジョブのコンテナからサービスにアクセスするために使用できる追加のエイリアスです。詳細については、サービスへのアクセスを参照してください。
Note: Kubernetes executorのエイリアスサポートは、GitLab Runner 12.8で導入され、Kubernetesのバージョン1.7以降のみ利用可能です。

同じイメージから複数のサービスを起動する

GitLabとGitLab Runnerの9.4で導入されました。詳細は拡張設定オプションを参照してください。

新しい拡張Docker設定オプションが導入される前には、以下の設定が正しく動作しませんでした。

services:
  - mysql:latest
  - mysql:latest

Runnerは、mysql:latestイメージを使用して2つのコンテナを起動しますが、そのうちの2つのコンテナは、デフォルトのホスト名命名規則に基づいてmysqlのエイリアスを使用してジョブのコンテナに追加されます。これは、サービスの1つにアクセスできない状態で終了します。

新しい拡張Docker設定オプションの導入後は、上記の例は以下のように動作が変更されます。

services:
  - name: mysql:latest
    alias: mysql-1
  - name: mysql:latest
    alias: mysql-2

Runnerはmysql:latestイメージを使用して2つのコンテナを起動しますが、それぞれのコンテナは.gitlab-ci.ymlファイルに設定されたエイリアスでアクセスできるようになります。

サービスのコマンド設定

GitLabとGitLab Runnerの9.4で導入されました。詳細は拡張設定オプションを参照してください。

ここでは、super/sql:latestイメージの中にSQLデータベースが入っていて、それをサービスとして利用したいとします。また、このイメージはコンテナを起動してもデータベースプロセスを起動しないので、ユーザは手動で/usr/bin/super-sql runコマンドを使ってデータベースを起動する必要があるとします。

新しい拡張Docker設定オプションの導入前には、super/sql:latestイメージをベースにデフォルトのコマンドを追加した独自イメージを作成して、ジョブの設定で使用する必要がありました。

# my-super-sql:latest image's Dockerfile

FROM super/sql:latest
CMD ["/usr/bin/super-sql", "run"]
# .gitlab-ci.yml

services:
  - my-super-sql:latest

新しく拡張されたDockerの設定オプションの導入後は、.gitlab-ci.ymlcommandを設定するだけで、次のように設定できるようになりました。

# .gitlab-ci.yml

services:
  - name: super/sql:latest
    command: ["/usr/bin/super-sql", "run"]

ご覧の通り、commandの構文はDockerfileのCMDと似ています。

イメージのエントリポイントをオーバーライドする

GitLabとGitLab Runnerの9.4で導入されました。詳細は拡張設定オプションを参照してください。

利用可能なエントリポイントのオーバーライド方法を示す前に、Runnerが起動してCIジョブで使用するコンテナにDockerイメージを使用する方法を簡単に説明します。

  1. Runnerは、定義されたエントリポイント(デフォルトはDockerfileに設定されたもので、.gitlab-ci.ymlによりオーバーライド可能です)を使ってDockerコンテナを起動します。
  2. Runnerは動作中のコンテナにアタッチされています。
  3. Runnerはスクリプト(before_scriptscriptafter_scriptの組み合わせ)を準備します。
  4. Runnerは、コンテナのシェルの標準入力にスクリプトを送り、その出力を受け取ります。

Dockerイメージのエントリポイントを上書きするには、.gitlab-ci.ymlに空のentrypointを定義することで、Runnerが無駄なシェルレイヤーを起動しないようにすることが推奨されます。しかし、これはすべてのDockerのバージョンに対応するわけではないので、Runnerがどのバージョンを使用しているかを確認する必要があります。具体的には以下のようになります。

  • Docker 17.06以降を使用している場合は、entrypointを空の値に設定できます。
  • Docker 17.03以前のバージョンを使用している場合は、entrypoint/bin/sh -c/bin/bash -c、もしくはイメージで利用可能な同等のシェルに設定できます。

image:entrypointの構文はDockerfileのentrypointと似ています。

ここではsuper/sql:experimentalイメージの中にSQLデータベースが入っていて、このデータベースのバイナリを使ってテストを実行したいので、ジョブのベースイメージとして使いたいとします。また、このイメージが/usr/bin/super-sql runをエントリポイントとして設定されているとします。つまり追加オプションなしでコンテナを起動するとデータベースのプロセスを実行しますが、Runnerはイメージがエントリポイントを持たないか、エントリポイントがシェルコマンドを起動する準備ができていることを期待しています。

拡張されたDocker設定オプションでは、super/sql:experimentalに基づいてイメージを作成し、ENTRYPOINTをシェルに設定してからCIジョブで新しいイメージを使うのではなく、.gitlab-ci.ymlで簡単にentrypointを定義できるようになりました。

Docker 17.06+用

image:
  name: super/sql:experimental
  entrypoint: [""]

Docker =< 17.03用

image:
  name: super/sql:experimental
  entrypoint: ["/bin/sh", "-c"]

イメージとサービスをconfig.tomlで定義する

[runners.docker]セクションを参照します。

[runners.docker]
  image = "ruby:latest"
  services = ["mysql:latest", "postgres:latest"]

このように定義されたイメージとサービスは、そのrunnerが実行するすべてのジョブに追加されます。

プライベートコンテナレジストリからイメージを定義する

GitLab Runnerプロセスで、プライベートコンテナのレジストリにアクセスできます。

どちらを使用するか定義するには、GitLab Runnerプロセスが次の順序で設定を読み込みます。

  • DOCKER_AUTH_CONFIG変数は、以下のどちらかで提供されています。
    • .gitlab-ci.ymlvariable
    • プロジェクトの設定>CI/CDページに保存されているプロジェクト変数。
  • DOCKER_AUTH_CONFIG。Runnerのconfig.tomlにある環境変数として用意されている変数です。
  • config.jsonファイルは、GitLab Runnerプロセスを実行しているユーザーの$HOME/.dockerディレクトリに置かれます。--userフラグを指定してGitLab Runnerの子プロセスを非特権ユーザーとして実行する場合は、GitLab Runnerプロセスのメインユーザーのホームディレクトリが使用されます。
Note: GitLab Runnerはこの設定のみconfig.tomlから読み込み、環境変数として提供されている場合は無視します。これは、GitLab Runnerがconfig.tomlの設定のみを使用し、実行時にすべての環境変数を補間しないためです。

要件と制限

  • この機能を利用するには、GitLab Runner 1.8以上が必要です。
  • GitLab Runnerのバージョン0.6以上、1.8未満では、プライベートレジストリの使用が一部サポートされていました。プライベートレジストリを使用したい場合は、Runnerをバージョン1.8以上にアップグレードすることをお勧めします。
  • GitLab Runner 13.1以降のKubernetes executorで利用可能。

静的に定義された認証情報の使用

プライベートレジストリにアクセスするには、2つの方法があります。どちらも環境変数DOCKER_AUTH_CONFIGに適切な認証情報を設定します。

  1. ジョブ単位: 1つのジョブがプライベートレジストリにアクセスするように設定するには、ジョブ変数としてDOCKER_AUTH_CONFIGを追加します。
  2. Runnerごと: すべてのジョブがプライベートレジストリにアクセスできるようにRunnerを設定するには、Runnerの設定の環境にDOCKER_AUTH_CONFIGを追加します。

それぞれの例は以下を参照してください。

DOCKER_AUTH_CONFIGデータの決定

例として、registry.example.com:5000/private/image:latestイメージを使用したい場合、プライベートコンテナのレジストリにログインする必要があります。

また、これらがログイン認証情報であると仮定してみましょう。

キー
registry registry.example.com:5000
username my_username
password my_password

DOCKER_AUTH_CONFIGの値を決めるには、2つの方法があります。

  • 最初の方法。ローカルマシンでdocker loginを実行します。

     docker login registry.example.com:5000 --username my_username --password my_password
    

    そして、~/.docker/config.jsonの内容をコピーします。

    コンピュータからレジストリにアクセスする必要がない場合は、docker logoutを行うことができます。

     docker logout registry.example.com:5000
    
  • 2つ目の方法。設定によっては、docker loginの結果を保存するためにDockerクライアントが利用可能なシステムキーストアを使用する可能性があります。その場合、~/.docker/config.jsonを読み込むことができないため、${username}:${password}をbase64エンコードした文字列を用意して、手動でDockerのJSON形式設定を作成する必要があります。ターミナルを開き、以下のコマンドを実行します。

     # Note the use of "-n" - it prevents encoding a newline in the password.
     echo -n "my_username:my_password" | base64
       
     # Example output to copy
     bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ=
    

    以下のようにDockerのJSON設定を作成します。

     {
         "auths": {
             "registry.example.com:5000": {
                 "auth": "(Base64 content from above)"
             }
         }
     }
    

ジョブの設定

registry.example.com:5000にアクセスできる単一のジョブを構成するには、以下の手順に従います。

  1. Docker設定ファイルの内容を格納する変数DOCKER_AUTH_CONFIGを作成します。

    {
        "auths": {
            "registry.example.com:5000": {
                "auth": "bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ="
            }
        }
    }
    
  2. registry.example.com:5000で定義したimageservices のプライベートイメージを.gitlab-ci.ymlファイルで使用できるようになりました。

    image: registry.example.com:5000/namespace/image:tag
    

    上の例では、GitLab Runnerはregistry.example.com:5000でイメージnamespace/image:tagを探します。

上記で説明したように、"auths"にさらに多くのレジストリを追加して、必要なだけ多くのレジストリの設定を追加できます。

Note: RunnerがDOCKER_AUTH_CONFIGと一致するためには、hostname:portの完全な組み合わせが必要です。例えば、.gitlab-ci.ymlregistry.example.com:5000/namespace/image:tagが指定されている場合、DOCKER_AUTH_CONFIGregistry.example.com:5000を指定しなければなりません。 registry.example.comのみを指定しても動作しません。

Runnerを設定する

同じレジストリにアクセスするパイプラインが多数ある場合は、Runnerレベルでレジストリにアクセスを設定した方が良いでしょう。これによりパイプラインの作成者は、適切なRunnerでジョブを実行するだけでプライベートレジストリにアクセスできるようになります。また、レジストリの変更や認証情報のローテーションが非常に簡単になります。

もちろん、これはそのRunner上のどのジョブでも、プロジェクト間であっても同じ権限でレジストリにアクセスできることを意味します。レジストリへのアクセスを制御する必要がある場合は、Runnerへのアクセスを制御する必要があることを確認してください。

RunnerにDOCKER_AUTH_CONFIGを追加するには。

  1. Runnerのconfig.tomlファイルを以下のように変更します。

    [[runners]]
      environment = ["DOCKER_AUTH_CONFIG={\"auths\":{\"registry.example.com:5000\":{\"auth\":\"bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ=\"}}}"]
    
  2. Runnerサービスを再起動します。

Note: DOCKER_AUTH_CONFIGデータに含まれる二重引用符はバックスラッシュでエスケープしなければなりません。これにより、それらがTOMLとして解釈されるのを防ぎます。
Note: environmentオプションはリストです。Runnerには既存のエントリがある場合があるため、リストを置き換えるのではなくリストに追加しなければなりません。

認証情報ストアの利用

GitLab Runner 9.5で認証情報ストアの使用をサポートするようになりました。

認証情報ストアを構成するには、以下の手順に従います。

  1. 認証情報ストアを使用するには、特定のキーチェーンや外部ストアと対話するための外部ヘルパープログラムが必要です。

  2. GitLab Runnerで認証情報ストアを使うには、2つの方法があります。

    • Docker設定ファイルの内容を格納するvariable DOCKER_AUTH_CONFIGを作成します。

         {
           "credsStore": "osxkeychain"
         }
      
    • セルフマネージドRunnerを実行している場合は、上記のJSONを${GITLAB_RUNNER_HOME}/.docker/config.jsonに追加します。GitLab Runnerはこの設定ファイルを読み込んで、特定のリポジトリに必要なヘルパーを使用します。

Note: credsStoreはすべてのレジストリにアクセスするために使用されます。 プライベートレジストリからのイメージとDockerHubからのパブリックイメージの両方を使いたい場合、DockerHubからの引き抜きは失敗します。

認証情報ヘルパーの使用

GitLab Runner 12.0で認証情報ヘルパーのサポートが追加されました。

例として、aws_account_id.dkr.ecr.region.amazonaws.com/private/image:latestイメージを使用したい場合を想定してみますが、このイメージはプライベートであり、プライベートコンテナのレジストリにログインする必要があります。

aws_account_id.dkr.ecr.region.amazonaws.comへのアクセスを設定するには、以下の手順に従います。

  1. GitLab Runnerの$PATHdocker-credential-ecr-loginがあることを確認します。

  2. 以下のAWSの認証情報を持つ場合、GitLab Runnerがこの認証情報でAWSへアクセスできることを確認してください。

  3. GitLab Runnerで認証情報ストアを使うには、2つの方法があります。

    • Docker設定ファイルの内容を格納する変数DOCKER_AUTH_CONFIGを作成します。

       {
         "credHelpers": {
           "aws_account_id.dkr.ecr.region.amazonaws.com": "ecr-login"
         }
       }
      

      これは、特定のレジストリで認証情報ヘルパーを使用するようにDockerを設定します。

      あるいは

       {
         "credsStore": "ecr-login"
       }
      

      これは、DockerがすべてのAmazon ECRレジストリで認証情報ヘルパーを使用するように設定します。

    • セルフマネージドRunnerを実行している場合は、上記のJSONを${GITLAB_RUNNER_HOME}/.docker/config.jsonに追加します。GitLab Runnerはこの設定ファイルを読み込んで、特定のリポジトリに必要なヘルパーを使用します。

  4. これで、.gitlab-ci.ymlファイルの中で定義されているimageサービス中のプライベートイメージaws_account_id.dkr.ecr.region.amazonaws.comを使用できるようになりました。

    image: aws_account_id.dkr.ecr.region.amazonaws.com/private/image:latest
    

    上の例では、GitLab Runnerはaws_account_id.dkr.ecr.region.amazonaws.comのimageprivate/image:latestを参照しています。

上記で説明したように"credHelpers"にさらに多くのレジストリを追加して、必要なだけ多くのレジストリの設定を追加できます。

サービスの設定

多くのサービスでは環境変数を受け付けており、環境に応じて簡単にデータベース名を変更したり、アカウント名を設定できます。

GitLab Runner 0.5.0以降では、作成されたサービスコンテナにYAMLで定義された変数をすべて渡します。

すべての可能な設定変数については、対応するDocker hubページで提供されている各イメージのドキュメントを確認してください。

Note: すべての変数はすべてのサービスコンテナに渡されます。それはどの変数がどこに行くべきかを区別するために設計されています。

PostgreSQLサービス例

PostgreSQLをサービスとして使用するための具体的なドキュメントを参照してください。

MySQLサービス例

MySQLをサービスとして使用するための具体的なドキュメントを参照してください。

Dockerインテグレーションの仕組み

以下、ジョブの実行中にDockerで実行されるステップを高レベルでまとめてみました。

  1. mysqlpostgresqlmongodbredisなど、任意のサービスコンテナを作成します。
  2. ビルドイメージのconfig.tomlDockerfileで定義されているすべてのボリュームを格納するキャッシュコンテナを作成します(上記の例ではruby:2.6)。
  3. ビルドコンテナを作成し、任意のサービスコンテナをビルドコンテナにリンクします。
  4. ビルドコンテナを起動し、コンテナにジョブスクリプトを送信します。
  5. ジョブスクリプトを実行します。
  6. コードは、/builds/group-name/project-name/にチェックアウトされます。
  7. .gitlab-ci.ymlで定義されている任意のステップを実行します。
  8. ビルドスクリプトの終了状況を確認します。
  9. ビルドコンテナと作成されたすべてのサービスコンテナを削除します。

ローカルでジョブをデバッグする方法

Note: 以下のコマンドをroot権限なしで実行します。通常のユーザーアカウントでDockerを実行できるはずです。

まず、build_scriptというファイルを作成することから始めます。

cat <<EOF > build_script
git clone https://gitlab.com/gitlab-org/gitlab-runner.git /builds/gitlab-org/gitlab-runner
cd /builds/gitlab-org/gitlab-runner
make
EOF

ここでは、Makefileを含むGitLab Runnerリポジトリを例にしています。makeを実行すると、Makefileで定義されたコマンドが実行されます。

次に、いくつかのサービスコンテナを作成します。

docker run -d --name service-mysql mysql:latest
docker run -d --name service-postgres postgres:latest

これにより、最新のMySQLとPostgreSQLのイメージを使用したservice-mysqlservice-postgresという2つのサービスコンテナが作成されます。これらは両方ともバックグラウンド(-d)で実行されます。

最後に、先ほど作成したbuild_scriptファイルを実行してビルドコンテナを作成します。

docker run --name build -i --link=service-mysql:mysql --link=service-postgres:postgres ruby:2.6 /bin/bash < build_script

上記のコマンドは、ruby:2.6イメージから生成されたbuildという名前のコンテナを作成します。build_scriptの内容はパイプ経由で標準入力からbashに渡され、bashはbuildコンテナ内でbuild_scriptの内容を実行します。

テストが終了しコンテナが不要になったら、コンテナを削除します。

docker rm -f -v build service-mysql service-postgres

buildコンテナ、2つのサービスコンテナ、およびコンテナ作成で作成されたすべてのボリューム(-v)を強制的に(-f)削除します。