カスタム ビルドステップの作成

ビルド構成を作成する場合、Cloud Build 提供のサポートされているオープンソース ビルドステップを使用したり、独自のカスタム ビルドステップを定義したりできます。

カスタム ビルドステップとは、Cloud Build ワーカー VM が pull し、ソース ボリュームで /workspace にマウントして実行するコンテナ イメージです。カスタム ビルドステップでは、コンテナ内の任意のスクリプトまたはバイナリを実行できるので、コンテナができることは何でもできます。

カスタム ビルドステップは、次の場合に便利です。

  • 外部のロケーションからのソースコードまたはパッケージのダウンロード
  • 外部ツールチェーンの使用
  • 必要なライブラリのキャッシュ
  • ソースの事前ビルド(ビルドをコンテナ イメージにパッケージ化する部分のみを受け持つ Cloud Build を使用)

カスタム ビルドステップは、ソースが /workspace の下にマウントされた状態で実行され、/workspace のいずれかの作業ディレクトリで実行されます。特定のビルドステップによって /workspace に残ったファイルは、ステップが同時に実行されるかどうかにかかわらず、他のビルドステップで使用できます。

カスタム ビルドステップでは、Google Container Registry リポジトリ(gcr.io/$PROJECT-NAME/ でホストされています)との間で push または pull できます。このリポジトリには、Builder サービス アカウントでアクセスできます。docker コマンドライン ツールの認証情報では、Docker Hub に認証済みのアクセスを提供するには不十分です。

このガイドでは、シェル スクリプトを実行するビルドステップを例にして、カスタム ビルドステップの作成方法について説明します。ビルドソースのいずれかのロケーションからシェル スクリプトを実行するカスタム ビルドステップとして「シェル スクリプト エグゼキュータ」を作成できます。

カスタム ビルドステップの作成

カスタム ビルドステップを作成するには、Builder サービス アカウントでアクセスできる Container Registry などのイメージ レジストリにビルドステップ イメージをビルドして push する、ビルド構成ファイルを作成します。または、別のツールを使用してカスタム ビルドステップ イメージをビルドし、イメージ レジストリに格納することもできます。この操作が完了したら、今後のビルドでカスタム ビルドステップを呼び出すことができます。

entrypoint フィールドについて

イメージの Dockerfile には、ENTRYPOINT フィールドや CMD フィールドがある場合があります。ENTRYPOINT は、コンテナを実行可能ファイルとして実行する場合にカスタム ビルドステップで使用するエントリ ポイントを指定します。CMD は実行する際のデフォルト設定を提供し、ENTRYPOINT を省略した場合は実行可能ファイルを含める必要があります。

ビルド構成で、オプションの entrypoint フィールドはビルドステップが呼び出されたときの実行方法を定義します。たとえば、ビルドステップの実行時に呼び出されるメインコマンドを指定できます。docker ビルドステップのエントリ ポイントは "/usr/bin/docker" です。ビルドステップを後のビルドで使用する場合、Dockerfile ENTRYPOINT を、そのビルドに entrypoint を指定することによってオーバーライドできます。

ビルドステップのビルド リクエスト ファイルで entrypoint フィールドを指定せず、かつビルドステップのイメージに Dockerfile で指定された ENTRYPOINT がなかった場合は、args の最初のアイテムがエントリ ポイントとして使用され、args の残りのアイテムは引数として使用されます。

例: ソースからのシェル スクリプトの実行

カスタム ビルドステップがソースからシェル スクリプトを実行できるようにするためには、スクリプトを実行できるツールがステップのコンテナ イメージに含まれている必要があります。ubuntudebianalpinebusybox コンテナ イメージなどの標準ベースのイメージはすべてスクリプトを実行できます。ただし、ubuntudebian イメージには bash がプリインストールされていますが、alpinebusybox イメージにはインストールされていません(したがって bash スクリプトを実行できません)。

イメージに、スクリプトを実行するのに必要なすべてのツール(シェルを含む)が含まれている場合は、そのイメージをビルドステップとして直接使用できます。

この例では ubuntu イメージを使用してスクリプトを実行します。このイメージには bash があらかじめパッケージに含まれており、多くの開発ツールをサポートしているためです。ビルド自体は、alpine に基づいてイメージを作成します。これらのイメージは、はるかに小さく、実行時の環境に必要なものだけを含んでいます。

カスタム ビルドステップの構成ファイル ./cloudbuild.yaml の例を次に示します。

steps:
- name: 'ubuntu'
  args: ['bash', './myscript.bash']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/custom-script-test', '.']
images: ['gcr.io/$PROJECT_ID/custom-script-test']

このステップでは、./myscript.bash という次のスクリプトが実行されます。

echo "Hello, world!" > file.txt

Dockerfile の例を次に示します。

FROM alpine
COPY file.txt /file.txt
ENTRYPOINT ["cat", "/file.txt"]

このカスタム ビルドステップを使用するビルドを送信するには、シェルまたはターミナル ウィンドウで次のコマンドを実行します。

$ gcloud builds submit --config cloudbuild.yaml .
...
$ gcloud docker -- pull gcr.io/<your-project-id>/custom-script-test
...
$ docker run gcr.io/<your-project-id>/custom-script-test
Hello, world!

カスタム ビルドステップが実行するスクリプトには、この例で使用される alpine ベースのイメージに提供されるリソースよりも多くのリソースが必要になる可能性があります。この場合、Docker ファイルの COPY ディレクティブを使用してワークスペースからコンテナ イメージにリソースを取り込むことによって、必要なリソースを持つイメージをあらかじめ用意できます。

たとえば、curl を使用するスクリプトを実行して、ビルドされたイメージに含めるファイルを pull するとします。ubuntu イメージは curl コマンドライン ツールであらかじめパッケージ化されていないので、ubuntu ベースイメージの上に curl を重ねて新しいイメージを作成します。

カスタム ubuntu-curl ビルドステップを使用するビルド向けの ./cloudbuild.yaml 構成ファイルの例を次に示します。

steps:
- name: 'gcr.io/$PROJECT_ID/ubuntu-curl'
  args: ['bash', './curl.bash']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/custom-script-test2', '.']
images: ['gcr.io/$PROJECT_ID/custom-script-test2']

curl ツールをインストールする Dockerfile.ubuntu-curl:

FROM ubuntu
RUN apt-get -q update && apt-get install -qqy curl

./curl.bash スクリプトは次のようになります。

#!/bin/bash
curl http://example.com > example.html

Dockerfile の例:

FROM alpine
COPY example.html /example.html
ENTRYPOINT ["cat", "/example.html"]

ubuntu-curl のカスタム ビルドステップを実行してイメージをビルドするには、シェルまたはターミナル ウィンドウで次のコマンドを実行します。

# First, build and push the `ubuntu-curl` custom build step.
$ docker build -f Dockerfile.ubuntu-curl -t gcr.io/your-project/ubuntu-curl .
...
$ gcloud docker -- push gcr.io/your-project/ubuntu-curl
...

Dockerfile.ubuntu-curl を使用してビルドしたイメージを Docker レジストリに push すると、そのイメージをビルドステップとして直接使用できます。

# Then, use the custom `ubuntu-curl` build step in a new build.
$ gcloud builds submit --config cloudbuild.yaml .
...
$ gcloud docker -- pull gcr.io/your-project/custom-script-test2
...
$ docker run gcr.io/your-project/custom-script-test2
`<`contents of example.com source`>`

スクリプト実行プログラム イメージをビルドするための予備ステップを追加することで、1 つのビルドで同じことを実現できます。そのイメージをビルドしたら、それをビルドの次のステップとして使用できます。これには、curl.bash をクリーンなままに保ち、Cloud Build サービスで作業の大半を実行するという利点があります。

予備のステップが追加された ./cloudbuild.yaml 構成ファイルの例を次に示します。

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-f', 'Dockerfile.ubuntu-curl', '-t', 'script-runner', '.']
- name: 'script-runner'
  args: ['bash', './curl.bash']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/custom-script-test2', '.']
images: ['gcr.io/$PROJECT_ID/custom-script-test2']

cloudbuild.yamlimages フィールドに script-runner を含めない限り、Cloud Build サービスはそれを push しません(この例では失敗します)。ただし、ビルドのコンテキストでは、script-runner イメージはイメージ キャッシュに存在し、ビルドステップとして使用できます。

次のステップ

フィードバックを送信...