Container builderでコンテナイメージをBuildしてSlackで結果を受け取る開発スタイルが捗る

Tweet

はい、ドーモ。自称Container builder普及委員会の吉海です。Container BuilderはGCPが提供しているクラウドなコンテナイメージのビルド環境です。フルマネージドサービスなので、導入コストも運用コストも低いのが嬉しいポイントです。

今回はそんなContainer builderを使った捗る開発スタイルをご紹介したいと思います。

本記事はこんな読者がターゲットです。

• ローカルでひたすらDocker buildとpushを繰り返す日々に疲れた方
• 開発効率を上げたい方

それでは、本題に入りたいと思います。今回紹介する開発スタイルは図にすると下記になります。

これは、開発者がgcloud container builds submitコマンドを開発マシンで叩くことで、クラウドのContainer builder上でDockerコンテナイメージのビルドとプッシュが自動で行われる仕組みです。ビルドとプッシュが終わると結果をslackに通知してくれるようになっています。

メリットとしてはbuildが行われるのがクラウドなので、開発マシンに負荷がかからないのと、buildとpushがワンコマンドで済む点があります。
デメリットとしては、ローカルのファイルをtarに圧縮して転送するための時間がかかるのとCloud builderの利用料金が発生することです。ただ、料金に関しては$0.003/ビルド分※1で、1日あたり120ビルド分は無料になるので、気にする必要はあまりなさそうです。

手順

• Slackへ通知
• Container builderのcloudbuild.yamlの作成

まず最初に、Google Cloud Functions使ってContainer biulderの結果をSlackに通知する仕組みを作ります。次にdocker buildに指定したい様々オプションをcloudbuild.yamlで定義していきます。
最後に使い方の説明としてgcloud container builds submitのコマンドをご紹介します。

Slackへ通知

Slackへ通知は、Container builderのステータスが変更されると、その内容がCloud Pub/Subのトピックにメッセージが公開され、それをトリガーにCloud functionsが実行される流れになります。
Cloud Pub/SubはGoogleが提供しているリアルタイム メッセージング サービスになります。本来はPub/Subを使う上でトピックというものを作る必要がありますが、Container builderのトピックは自動的に作成されるため、Cloud Pub/Subのセットアップに関してはCloud Pub/Subを有効にするのみで他に必要な手順はないはずです。
ちなみにトリガーとなるビルドのステータスは下記の通りです。

• STATUS_UNKNOWN
• QUEUED
• WORKING
• SUCCESS
• FAILURE
• INTERNAL_ERROR
• TIMEOUT
• CANCELLED

詳細は公式ドキュメントをご覧下さい。ビルドステータス

今回は、このステータスがSUCCESSかそうでないかで、Slackへの通知内容を変化させたいと思います。

Cloud Functionsのセットアップを含めた具体的な手順に関しては、GCPの公式ドキュメントで解説されているので、ここでは全ての手順は解説せずに、Cloud functionsにデプロイするコードの内容にフォーカスして説明していきます。

デプロイするコードは下記になります。

const IncomingWebhook = require('@slack/client').IncomingWebhook;
const SLACK_WEBHOOK_URL = "[YOUR_SLACK_WEBHOOK]"


const webhook = new IncomingWebhook(SLACK_WEBHOOK_URL);


// subscribe is the main function called by Cloud Functions.
module.exports.subscribe = (event, callback) => {
 const build = eventToBuild(event.data.data);


// Skip if the current status is not in the status list.
// Add additional statuses to list if you'd like:
// QUEUED, WORKING, SUCCESS, FAILURE,
// INTERNAL_ERROR, TIMEOUT, CANCELLED
  const status = ['SUCCESS', 'FAILURE', 'INTERNAL_ERROR', 'TIMEOUT'];
  if (status.indexOf(build.status) === -1) {
    return callback();
  }


// Send message to Slack.
  const message = createSlackMessage(build);
  webhook.send(message, (err, res) => {
    if (err) console.log('Error:', err);
    callback(err);
  });
};


// eventToBuild transforms pubsub event message to a build object.
const eventToBuild = (data) => {
  return JSON.parse(new Buffer(data, 'base64').toString());
}


// createSlackMessage creates a message from a build object.
const createSlackMessage = (build) => {
  let color = "";
  let text;
  if (build.status === "SUCCESS") {
    color = "good";
    text = "<@user> 終ったで";
  } else {
      color ="danger";
      text = "<@user> 何気ないsubmitがContainer Builderをきずつけた";
  }
  let message = {
    mrkdwn: true,
    username:`Container builder ${build.id}`,
    text: text,
    attachments: [
      {
        title: `Build Status: ${build.status}`,
        title_link: build.logUrl,
        color: color,
      }
    ]
  };
  return message
}

これはcreateSlackMessageの関数以外は公式ドキュメントにあるコードと同じ内容になります。このコードはビルドのステータスが’SUCCESS’, ‘FAILURE’, ‘INTERNAL_ERROR’, ‘TIMEOUT’の場合のみに通知するようになっています。なのでビルドの結果だけが通知される形です。
createSlackMessageに関しては下記の機能を実現したいので一部変更しています。

• 投稿されるメッセージを2行に圧縮(修正前は4行)。行数が少ないほうが視認性が高いので好きです。
• Successの時はメッセージの色を緑に、それ以外の場合は、特定のユーザー@userにリプライをするように

  createSlackMessageは、主にSlackのAPIを叩いてメッセージをポストしているだけです。もし投稿されるメッセージのフォーマットを変更したい場合は、Slack APIのchat.postMessageのドキュメントページをご覧下さい。ちなみに僕は、ユーザーにリプライを飛ばしたい場合は<>でユーザー名を囲う必要があることを知らず少しハマりました。@userだけだとリプライになりません。

cloudbuild.yamlの作成

cloudbuild.yamlはContainer Builderのビルドリクエストを定義するためのものです。ビルドリクエストには、Container BuilderがDockerコンテナイメージを作成するために必要な指示が盛り込まれています。今回はDocker buildのオプションを色々と設定したいために作成します。
buildのオプションを特に設定しないのであれば、cloudbuild.yamlを定義することなく、Container Builderのコマンドを使うことも出来ます。

今回、サンプルとして紹介するcloudbuild.yamlは下記になります。

timeout: 3600s
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ["build", "-t", "gcr.io/bobunemimimmi/eisaiharamasu:${_VERSION}", "--build-arg", "FROM_TAG=latest", "-f", "test.dockerfile", "."]
images:
    - 'gcr.io/bobunemimimmi/eisaiharamasu:${_VERSION}'

上から解説していきます。
まずtimeoutというオプションですが、これは名前の通りContainer builderのタイムアウトの設定です。設定している理由としては、Container Builderのデフォルトのタイムアウトの時間が10分と短くタイムアウトによるビルドの失敗が多発したので設定してあります。

次にstepsですが、ここにはCloud Builderで実行したいDockerイメージを指定します。今回行いたいのはbuildだけなので、Dockerコマンド実行用の’gcr.io/cloud-builders/docker’というイメージを指定して、argsにbuildコマンドとその引数を指定しています。ちなみに${_VERSION}というのは、独自に定義した変数で、この変数をgcloud container builds submitに指定することで変数の値を設定することが出来るようになります。今回は、gcloud container builds submit時に任意のバージョンを変数として渡し、そのバージョンと同じタグをイメージのタグに設定したいために使っています。

imagesではpushしたいイメージを指定します。今回は上のstepでビルドしたイメージをpushしたいので、buildの-tオプションで指定したイメージを指定しています。そのため、このcloudbuild.yamlを実行してデプロイされるイメージはgcr.io/bobunemimimmi/eisaiharamasu:${_VERSION}になります。

余談ですが、Container builderで使える様々な用途のDockerコンテナイメージがオフィシャルで公開されています。これらを使うことで簡単に、gcloudやkubectlなどのコマンドを実行することが出来るようになっています。何かContainer builderでやりたいことがあれば、まずはこちらのレポジトリを確認してみるのがオススメです。
cloud-builders

使い方

次に使い方として、コマンドについて解説しています。
下記のコマンドを一発叩くだけで、Dockerイメージのビルド及びプッシュ、完了後のSlack通知が行われます。

gcloud container builds submit --config=cloudbuild.yaml --substitutions _VERSION=v16 .

–configでcloudbuild.yamlを指定して、 –substitutionsで_VERSIONの変数にv16を設定しています。コマンド最後の.はDocker buildのコンテキストの指定で、これはコマンドを実行したディレクトリのファイル群が、buildのコンテキストとして、Container builderに送信されます。

まとめ

これで捗る開発スタイルの解説は終わりになります。一見すると地味なのですが、こういうちょい便利なのを使っていくと幸せになるのでおすすめです。Container Builderはコマンドを叩く以外にもGit レポジトリのPushをトリガーにすることも出来るので、皆さんで色々と試して見て下さい。

最後になりますが、弊社ではGCPが大好きで考えるだけで、ヨダレが出てしまう（出なくても可）エンジニアを大募集しています。ビビッと来た方はまずは、弊社のWantedlyのページを御覧ください。気に入って貰えたら「話を聞きに行きたい」のボタンを押して貰えると嬉しいです。

※1 Container Builderのマシンタイプがn1-standard-1の場合 料金