Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

Google Cloud Container Builderでアプリケーションのデプロイと継続的インテグレーションを実現

KubernetesによるスケーラブルなWebアプリ環境の構築 第4回

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/01/17 14:00

 本連載では、オープンソースのオーケストレーションシステムである「Kubernetes」を用いて、スケーラブルで運用しやすいWebアプリケーションを構築する方法を紹介します。前回はServiceのselectorを使ったBlue-Green Deployment相当の機能を実現する方法と、アプリケーションのバージョンごとにURLを自動で割り当てる機能を実現するため、必要な手順を解説しました。本記事では効率的なアプリケーション開発に欠かせない、継続的インテグレーションをするための仕組みについて、その構築方法などを紹介します。

目次

はじめに

 継続的インテグレーションを行うための手段として、JenkinsやCircleCなどのさまざまなツールやサービスが存在します。今回は「Google Cloud Container Builder」を使った方法を解説します。

Google Cloud Container Builderとは

 Google Cloud Container Builderは、Googleが提供しているDockerコンテナイメージを作成できるビルド環境です。Google Cloud Container Builderに「Google Cloud Source Repositories」「GitHub」「BitBucket」などのレポジトリを指定し、Dockerコンテナイメージのビルドといった処理を実行させることができます。

 なお、Google Cloud Platformを利用しているのであれば特別な設定は不要ですぐに利用できるため、構築や運用のコストが低いメリットがあります。例えばJenkinsを使う場合、ユーザー自身が構築や運用を行う必要があり構築コストや運用コストがかかります。しかし、Google Cloud Container BuilderはGoogle Cloud Platformのコンソールから機能を有効にするだけで利用することができます。また、メンテナンスもGoogle Cloud Platformが行ってくれるので運用のコストはほとんどかかりません。

 Google Cloud Container Builderの欠点としては、ビルドのトリガーが「Gitの特定のブランチにPushされた時」「Gitに特定のタグを追加した時」の2種類しかないことが挙げられます。そのため、これ以外のケースをトリガーにしたい場合には適しません。ほかにも、ビルドの途中でマニュアルジャッチメントといった、ユーザーによるビルド継続の判断処理を間に入れることができない、などがあります。

Google Cloud Container Builderの使い方

 Google Cloud Container Builderには大きく分けて2つ使い方があります。

 1つ目は「DockerコンテナイメージのビルドからDockerレジストリに対してのプッシュまで行う使い方」です。レポジトリにあるDockerfileの指定とDockerコンテナイメージ名を指定するだけで使用可能となっています。

 2つ目は「ビルドステップをユーザーが独自にJSONおよびYAMLで定義することで、自由なビルドを行うことができる使い方」です。ビルドステップとはビルドの処理を記述したもので、 主にDockerコンテナイメージの指定とそのコンテナで実行したい内容を記述します。また、ビルドステップを組み合わせて記述することで、さまざまな処理を行うことできます。ビルドステップで指定するDockerコンテナイメージにはGoogle Cloud Container Builderが提供しているイメージだけでなく、自由なDockerコンテナイメージを指定することができます。

 まとめると、Dockerコンテナイメージのビルドとプッシュを行いたいだけであれば、簡単な設定で使える前者の使い方がおすすめです。それ以外の使い方をしたい場合は後者を選ぶことになります。

 今回は、後者の使い方であるビルドステップをYAMLで定義する方法を使います。ビルドステップでkubectlを実行するためのDockerイメージを使うことで、Dockerコンテナイメージのビルドとプッシュだけでなく、Kubernetesへのデプロイを行います。このビルドステップは下図のような開発フローを想定しています。

想定する開発フロー
想定する開発フロー

 この想定フローはアプリケーションの開発者がKubernetesの使い方を知らなくても、Gitレポジトリにタグを付けてプッシュするだけでアプリケーションがデプロイできる開発フローです。アプリケーション開発者がデプロイするコストを下げることで、開発の効率化を目指します。ただし、動作確認と本番環境の切り替えは開発者が手動で行う想定です。

 Google Cloud Container Builderの処理フローの詳細は下図の通りです。

Google Cloud Container Builderの処理フロー図
Google Cloud Container Builderの処理フロー図

 Google Cloud Container Builderで担当するステップは2つあります。「Dockerコンテナイメージのビルド&プッシュ」と「Kubernetesへのデプロイ」です。

 この処理フローを実現するにあたり、以下の手順が必要になります。

  • アプリケーションのレポジトリへのセットアップ
  • Google Cloud Container Builderのトリガー設定
  • 動作確認

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • WINGSプロジェクト 吉海 将太(ヨシカイ ショウタ)

     株式会社カブクのサーバーサイドエンジニアです。APIの開発(Python,GO,AppEngine)とKubernetesによるインフラ環境の構築を担当しています。好きな獣はチベットスナギツネです。 Twitter: @yoshikai_ Faceb...

  • 山田 祥寛(ヤマダ ヨシヒロ)

    静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「入門シリーズ(サーバサイドAjax/XMLD...

バックナンバー

連載:KubernetesによるスケーラブルなWebアプリ環境の構築
All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5