初めてのSpinnaker 〜継続的デリバリー(CD)の実現〜(第二弾)

前回記事に引き続き、Spinnakerのパイプラインの定義、アプリケーションのデプロイまでを体験して行こうと思います。

この記事は アイソルート Advent Calendar 25日目の記事です。
こんにちは。
モバイルソリューショングループのimai.kです。

現在のSpinnakerインストール方法

現在、Spinnakerを使用するには二通りの方法があります。一つ目は前回記事で紹介したHalyardを使用した方法です。
Spinnakerの詳細な設定や更新をする行うにはHalyardが必要なため、商用環境ではHalyardを利用する方が良いでしょう。

もう一つの方法はKubernetesのパッケージマネージャであるHelmを利用した配置です。
今回はこのHelmを利用していきます。

実践！

GCPのチュートリアルを実践し、Cloud Source Repositories、Google Cloud Build、Spinnaker、GKEを組み合わせ、コードの変更をトリガーに、アプリケーションをGKEに展開する環境を構築することが今回のゴールです。
それでは早速チュートリアルを進めていきましょう。

操作は全て、Cloud Shell上で行っていきます。
まずはGKEのクラスター作成、サービスアカウントの作成と進めていき、次にHelmを使用してSpinnakerをデプロイしていきます。
Spinnakerの配置が完了したら、Cloud Shellの[ウェブでプレビュー] > [ポート 8080 でプレビュー] を選択し、Spinnakerのページを表示しましょう。
以下のようなページが表示されるはずです。

ビルドトリガーの設定

次に、Cloud Source Repositoriesにアプリケーションコードをアップし、Google Cloud Buildにビルドトリガーを設定します。
ビルドトリガーが設定された後、”v”で始まるGitタグがPushされるたび、Cloud BuildがDockerのコンテナイメージをビルドするようになります。

デプロイメント パイプラインの設定

パイプラインの設定は、Spinnakerのアプリケーションやパイプラインを制御するSpinというCLIツールを使用します。
Spinを使用することで、パイプラインをjsonとして定義することができます。
実際にビルドが始まると、以下のようにパイプラインの実行状況を確認できます。

プロダクション環境へのイメージの展開

Spinnakerの特徴の一つに、「パイプラインの実行時に承認フローを設けることができる」ということが挙げられます。
実際、このチュートリアルでは作成されたDockerイメージを本番環境にデプロイする際、以下のような承認UIが表示されるようになっています。
“Continue”をクリックするまで、パイプラインの次のステップが進まないので安心です。

デプロイされたアプリケーションの確認

実際にGKEにデプロイされたアプリケーションを確認しましょう。
Infrastructure > Load Balancersと選択し、”sample-frontend-production”の”Default”を選んでください。
アプリケーションのIPアドレスが表示されます。
IPアドレスを開くと以下のようなページが表示されるはずです。

まとめ

今回はGCPのチュートリアルを通して、Spinnakerを使用したアプリケーションのデプロイを体験しました。

Spinnakerには、今回のチュートリアルだけでは紹介しきれない機能を秘められています。
今後も本ブログを通してSpinnakerを紹介していこうと思います。