初めての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を紹介していこうと思います。