1.1　アプリケーションの管理

　Spinnakerでは仮想マシンのイメージ作成や仮想マシン・コンテナのデプロイ、スケーリングといったアプリケーション管理機能を、Bake、Deploy、Clusterといった抽象化した用語で表現します。同じような機能や概念でもIaaSによって名前が異なるため、抽象化することでマルチクラウドでも同じ用語でクラウドリソースを取り扱うことができます。

　アプリケーション管理機能によって、クラウドリソースの表示、変更などの操作を司ります。重要な概念として、Instance、Server Group、Cluster、Applicationがあります（図1.1）。

Instance

　仮想マシン（Virtual Machine; VM）を表します。AWSであればAmazon EC2、GCPであればGCE、KubernetesであればPodを指します。

Server Group

　Instanceをグループ化したものです。AWSであればAuto Scaling Group、GCPであれば Managed Instance Group、KubernetesであればReplicaSetを指します。

　Server Groupにはデプロイ可能なアーティファクト⁷（VMイメージ、Dockerイメージ、マニフェスト）、インスタンス数、オートスケーリングポリシーから構成されています。

Cluster

　Server Groupを論理的にグループ化したものです。Spinnaker上でグルーピングされたものにすぎないため、AWSやGCPには一致する概念がありません。

Application

　Clusterをグループ化したもので、パイプラインやインフラストラクチャから構成されています。Spinnakerの思想として、通常はマイクロサービス１つにつき、１つのApplicationとします。また、開発、ステージング、本番といった環境ごとにApplicationを分離せず、ひとつのApplicationにまとめます。これは多くの場合、環境ごとにデプロイするパイプラインがあり、ステージング環境へのデプロイがトリガーとなって本番環境へのデプロイパイプラインが実行されることを想定して、ひとつのApplicationに複数のパイプラインを含めます。

　Applicationを構成するインフラストラクチャーとしては、先ほど説明したCluster、Server Groupの他に、FirewallとLoad Balancerも含まれます（図1.2）。

Firewall

　TCPなどの通信プロトコルや、ポート、IPアドレスを指定することで、ネットワークトラフィックアクセスを制御します。AWSであればセキュリティグループ、GCPであればファイアウォールルールを指します。

Load Balancer

　Server Group内のインスタンス間のトラフィックを負荷分散します。また、必要に応じてヘルスチェック⁸を有効化し、インスタンスまたはサービスの状態をチェックします。

1.2　アプリケーションへのデプロイ

　Spinnakerは、デプロイやインフラストラクチャーに対する制御などのフローをPipelineという形で構築、管理します。Pipelineは実行するアクションを定義するStageと、パイプラインの開始を制御するTrigger、パイプラインの開始、成功、失敗時に通知するNotificationから構成されています。

Stage

　Stageはそれ自体が独立したアクションを記述しており、組み立てることでパイプラインを形成します。また、パイプラインにそって、ステージからステージへとパラメータを渡すこともできます。

　Stageは基盤となるインフラストラクチャーを構築するInfrastructure Stage、外部システムとの連携を行うExternal Systems Integrations、パイプラインの流れを制御するControlling Flowの3つに分類されます。

　Infrastructure Stageはリソース作成、変更、削除など基盤となるインフラストラクチャーを構築するステージです。

　主なステージは次のとおりです。

　・Bake（VMイメージ、Dockerイメージの生成）

　・Find Image From Tag（リソースに付与されたタグからイメージを特定し、後続ステージで利用する）

　・Deploy（Blue/Green Deployment、マニフェスト適用など）

　・Cluster のスケールアップ、ダウン、ロールバック、無効化

　・Server Group のクローン、有効、無効、リサイズ、破棄

　・Run Job（コンテナを実行）

　・Script（Jenkins上でジョブ実行）

　External Systems Integrationsは外部システムとの連携を担うステージです。継続的インテグレーション（Continuous Integration; CI）サービスをトリガーとして、パイプラインを実行することができます。

　Spinnakerと連携できるCIサービスは次のとおりです。

　・Jenkins

　・Travis CI

　・Wercker

　・Concourse CI

　Webhookからトリガーすることもできます。SpinnakerにHTTP POSTリクエストを送ることで、任意のパラメータをパイプラインに渡すこともできます。

　Controlling Flowはパイプラインの流れを制御するステージです。主なステージは次のとおりです。

　・Check Preconditions（条件分岐）

　・Manual Judgement（手動承認）

　・Wait（指定された秒数を待機）

　・Pipeline（別のパイプラインを実行）

Trigger

　トリガーはパイプラインの開始を制御します。

　時間ベースのトリガーとしては、

　・Manual（手動実行）

　・Cron（時間指定）

　があります。

　イベントベースのトリガーとしては主に次に挙げるものがあります。

　・Git（GitHub、GitLab）

　・CIサービス（Jenkins など）

　・Docker Registry（Docker Hub、Amazon ECR、Google Container Registry など）

　・Pipeline（別のパイプラインを実行）

　・Google Cloud Storage（GCS）⁹

　・Pub/Sub（Cloud Pub/Sub、Amazon SNS など）

　イベントベースのトリガーはアーティファクトをパイプラインに渡すことができます。たとえば、GCSはアーティファクトをGCSバケットに置くと、そのイベントを検知してGCSバケット名やファイル名がパイプラインに渡ります。GitHubはGit Pushなどリポジトリーの変更に基づいてリポジトリー名やブランチ名などがパイプラインに渡ります。

Notification

　パイプラインの開始、成功、失敗を通知することができます。また、各ステージでも通知が可能なので、デプロイステージになった場合にSlackで開発者にメンションして知らせることもできます。

　対応している通知先は次のとおりです。

　・Email

　・Slack

　・SMS（Twilio）

　・Pub/Sub

　Pub/Subを活用することで、上記以外の通知先にも対応できますし、Spinnakerから別システムへの連携もできます。