SpinnakerのKubernetesプラグイン（以下「プロバイダー」）のバージョン2は次の特徴を備える。以前使われていたJavaライブラリではなく、Kubernetesネイティブのコマンドラインインタフェース（CLI）「kubectl」と統合された。カスタムリソースを定義できるため、Kubernetesと併せて使うことでサードパーティー製のインフラコンポーネントを管理しやすい。

　つまりKubernetesプロバイダー　バージョン2では、任意のコンテナイメージのKubernetesマニフェストを自動で生成する。そして、Spinnakerパイプラインの一環として、ステージング環境用、テスト環境用、運用環境用といった具合に、複数バージョンのマニフェストが生成される。IT運用管理者はKubernetesプロバイダー　バージョン2を使用して、セキュリティを目的としたKubernetesクラスタへのアクセス制限を実施できる。

　多国籍メディア企業のSchibsted Media GroupでDevOpsエンジニアスタッフを務めるガード・リーメスタ氏は次のように語る。同社はノルウェーに拠点を置き、Kubernetesプロバイダー　バージョン2を早くから導入している。「もはやKubernetesプロバイダーは恐ろしいものではなく、Kubernetesのコードと非常に近くなった。つまりSpinnakerによって、ローカル環境で使用しているものと同じバージョンのKubernetesをクラウドでも使用できるようになった」

継続的デプロイの実現を後押しするSpinnakerパイプライン

DevOpsチームの継続的デプロイを自動化するSpinnakerパイプラインの画面

　NetflixがSpinnakerのパイプラインツールを社内用に作成したのは2014年のことだ。Spinnakerがオープンソースコミュニティーにリリースされた2015年に、Googleも同プロジェクトに参加した。2017年6月のSpinnaker　バージョン1.0のリリース以降、パイプラインを使ったアプローチはクラウド化があまり進んでいない企業の注目を集めるようになった。

　「2013年からに7回にわたって継続的デプロイに挑戦してきたが、全て失敗した」とモバイルデバイスのセキュリティ会社Lookoutに所属するブランドン・リーチ氏は言う。同氏は同社の継続的デプロイ部門のシニアエンジニアリングマネジャーを務める。同社では4つのJenkinsパイプラインを導入して安定的に運用していたが、より優れたアプローチを探していた。そして2018年にSpinnakerを採用した。

　「Spinnakerではリリースの観点からインフラを調整できる。どのような方法でリリースするかを検討すれば、それに合わせたインフラが提供される。インフラ定義ソフトウェアの『Terraform』を使用したブルーグリーンデプロイメント（2つの環境を切り替えてバージョンアップを実施する手法）よりもはるかに円滑な方法だ」とリーチ氏は語る。

　オンライン印刷サービス会社のVistaprint USAでは、継続的インテグレーションツール「Bamboo」やJenkinsをベースにした継続的デプロイシステムを、Spinnakerのパイプラインに置き換えた。同社は小企業向けにマーケティング資料のカスタム印刷を提供している。Vistaprint USAではパイプラインの刷新を計画していた。プロビジョニング中のBambooビルドをスピンアップするのに2日以上掛かるようになり、テストが完了するまでリリース作業を中断しなければいけなくなったためだ。同社は社内で作成したデプロイ用コードと組み合わせてSpinnakerとJenkinsをテストおよび比較した。その結果、使いやすさの点でSpinnakerに軍配が上がった。

　「基本的なSpinnakerパイプラインは1日で稼働させられた。さらに1日半で実際にデプロイすることができた」と述べるアンドリュー・ドブソン氏は、Vistaprint USAでソフトウェアエンジニアを務める。

　Spinnakerパイプラインでは核心部分のインフラ構成タスクが抽象化されるため、ユーザーは具体的な処理を意識しなくてもよいが、Spinnakerのコードに手を加えることも可能だ。Lookoutのリーチ氏はSpinnakerのインフラプロバイダーを独自に作成した。Kubernetesではなく、Amazon Web Servicesのコンテナ管理サービス「Amazon Elastic Container Service」（Amazon ECS）でコンテナオーケストレーション環境を扱うためだ。一方でSchibsted Media Groupのリーメスタ氏は、Spinnakerパイプラインツールと同社独自のデプロイデーモンを連携させている。

Spinnakerパイプラインユーザーのウィッシュリスト

　Spinnakerパイプラインは、企業が継続的デプロイの初期段階を乗り切るのに役立つ。だがユーザーが洗練されていくにつれ、より多くの機能が期待されるようになる。例えば継続的インテグレーション段階前のSpinnakerパイプラインにおける成果物の自動評価、プロモート、ロールバックなどだ。ユーザーによると、Spinnakerパイプラインでステートフルアプリケーションのデプロイを実行するためのAPIが改善され、CLIの安定化や簡素化が遂行される可能性があるという。Netflix内でもまだα版の段階である宣言型のパイプラインツールが利用可能になることを切望するユーザーもいる。

　Vistaprint USAのドブソン氏は次のように述べる。「Spinnakerコミュニティーでは、方法を気にせずにデプロイできるようにするための取り組みが進められている。つまり新しい技術が用いられても、内部の仕組みを更新できるようにしている」

　Spinnakerパイプラインのロードマップには、成果物のプロモート機能、α版のCLIを使いやすくするための強化が含まれている。さらにユーザーの要望に基づいたステートフルなアプリケーション導入APIの更新、オープンソースとしての管理プロジェクトの運営委員会なども含まれている。

　「Netflixの全てのステートフルサービスは、アプリケーションのデリバリーに組み込めるようSpinnakerのAPIを使用している。当社で利用している分散データベース『Apache Cassandra』やメッセージサービス『Apache Kafka』でも、オーケストレーション済みのデプロイを実行したことがある。いずれはこうした機能の一部をSpinnakerに組み込むことになるだろう」とNetflixでデリバリーエンジニアリング部門のディレクターを務めるグローバー氏は語った。