Googleが”Skaffold” - Kubernetesでの継続的デプロイメントを促進するツールをリリース

Googleは、Kubernetesアプリケーションの継続的開発を容易にするコマンドラインツールのSkaffoldをリリースした。Skaffoldは今まさに、AzureのDraftやDatawireのForge、WeaveworkのFluxなどが乱立するKubernetes開発自動化ツールの領域に踏み込もうとしている。

Skaffoldはアプリケーションの構築、プッシュ、Kubernetesクラスタへのデプロイといったワークフローを自動化するツールだ。開発者は、アプリケーションのソースコードをローカルで繰り返し処理しながら、ローカルあるいはリモートのKubernetesクラスタ上で継続的に更新し、検証あるいはテストの準備を整えることが可能になる。コード開発中にSkaffoldをバックグラウンドプロセスとして実行することが可能で、単発的な作業だけでなく、CI/CDパイプラインのような自動化されたコンテキストで使用することもできる。これによって、アプリケーションをローカル開発から運用環境に移行しても、同じワークフローを活用することが可能になる。

Google Cloud Platform Blogによると、Kubernetesは、オペレータとシステム管理者のアジリティを向上し、信頼性の高いソフトウェアアプリケーションのデプロイメントを促進するAPIと方法論を提供する。Kubernetesは独自のデプロイメント方法を採用して、“他の手順と同等以上の堅牢性を実現するプログラム的手法を提供”する。このためオペレータは、組織における最重要課題 -- サービスの(リリース)速度と安定性の確保に集中することが可能になるのだ。

Kubernetesの世界に足を踏み入れる組織内の最後の人々は、もしかしたら開発者かも知れない。彼らはすでにRPMやDEB、あるいはDockerなど最新のLinuxコンテナを使って、アプリケーションのアーティファクトを作成している可能性があるからだ。Dockerを使用することで、アプリケーションの依存関係や設定をシンプルかつ再現可能な方法で定義できるようになるため、再現性のある実行環境が実現する。これにより、開発チーム全体の開発ランタイムの同期を維持できるようにはなるが、共通的なデプロイメントや検証の方法は定義されない。そのため開発者からは、ローカル環境や統合環境、QA環境の構築を、運用環境で使用しているKubernetes APIと手法を使って行いたいという希望が多い。

Kubernetesにデプロイされるアプリケーションの一般的なワークフローは、次のようなものになる。

1. Kubernetesクラスタを検索またはプロビジョニングする。
   • クラスタはGKEやAKS、(将来的には)AWS Fargateといったプラットフォームサービスを利用するか、あるいはkopsのようなオンプレミスツールを使って用意できる。
2. 各サービスのDockerイメージを構築し、クラスタ内で使用可能なレジストリにアップロードする。
   • これには通常、Docker Community Editionのイメージ構築ツール(最新バージョンにはKubernetes用のローカルインストールが含まれている)を使って行う。
3. リファレンス資料とサンプルを使用して、Kubernetesマニフェスト定義を作成する。
4. kubectl CLIまたはKubernetes Dashboardを使用して、アプリケーション定義をデプロイする。
5. 機能、バグフィックス、あるいは変更セットが完了するまで、2-4を繰り返す。
6. 変更内容をチェックインして、以下のようなCIプロセスで実行する。
   • ユニットテスト
   • 統合テスト
   • テスト環境またはステージング環境へのデプロイメント
   • 実行状況とオブザーバビリティ(可観測性)のチェック

Googleブログでは、ステップ2から5までについて、開発者がアプリケーションをアップデートするために、複数のインターフェースを通じて複数のツールを使用しなければならない点を指摘している。

これらステップの大部分は開発者とっては渾然一体となっているため、自動化や、あるいは最低限でも開発者のエクスペリエンスに合わせたツールセットでガイドすることが可能です。

Skaffoldは、’skaffold dev’または’skaffold run’のいずれかのモードで実行できる。‘dev’モードで実行されるオペレーションは次のものだ — Dockerイメージのソースコードと依存関係の変更を監視し、変更が検出された場合にはビルドとデプロイを実行する。配置済みのコンテナからのログをストリームする。継続的なビルド-デプロイループを実行し、エラー発生時のみ警告する。‘run’モードではパイプラインを1回実行し、パイプライン内でエラーが発生すると終了する。継続的インテグレーションや継続的デプロイのパイプラインや、“アプリケーションのイテレーション後の健全性チェック”に有効だ。

Skaffoldは“アルファ”版としてリリースされており、現時点では以下の設計検討と機能が含まれている。

• サーバ側コンポーネントが不要、従ってクラスタにオーバーヘッドが発生しない
• イメージタグ管理
• 複数のアプリケーションコンポーネントをサポート (アプリケーションスタックの変更部分のみをビルドおよびデプロイ)。

Skaffoldはプラグインアーキテクチャを採用しているため、開発者は“自分に最も適したツールをワークフローに選択”することができる。

Gareth Rushgrove氏やJoe Beda氏のようなこの分野の思想的指導者が指摘しているように、Kubernetes開発ワークフローの自動化という分野には数多くのツール -- DraftやForge、Flux、Gitkube、Heighliner、ksyncなど -- が現れて、それぞれが微妙に異なる機能を提供している。

Microsoft Azureチームは、開発者ワークフローの“内部ループ”を対象としたDraftをリリースしている。Draftパックベースで開発されたアプリケーションを’draft create’を実行してコンテナ化し、’draft up’でアプリケーションをKubernetesの開発用サンドボックスにデプロイする。その上でアプリケーションをローカルエディタで修正すれば、その変更がKubernetesに即時デプロイされる仕組みだ。Draftを通じて実行された変更に満足できたならば、それをバージョン管理にコミットおよびプッシュすれば、以降は継続的インテグレーション(CI)システムが面倒を見てくれる。DraftはKubernetes HelmとKubernetes Chartフォーマットをベースにしているので、Draft対応アプリケーションでCIパイプラインを簡単に構築することができる。

Datawireは、同社の開発者オートメーションワークフローツールの一部としてForgeを提供している。これにはリモートデバッグツールであるTelepresenceと、Ambassador API Gateway(Envoy Proxyをベースとする)も含まれている。Forgeでは、Dockerfileを使って各サービスの構築方法を、Kubernetesマニフェストを使って各サービスの実行方法を、’service.yaml’ファイルを使ってアプリケーション構築に必要な依存関係を、それぞれ開発者が定義する。‘forge deploy’の実行で、依存関係の変更検出やインクリメンタルビルドの実行など、Kubernetesの標準的なコンテナ構築およびデプロイ手順がすべて自動化される。カナリーリリース(バージョン管理ブランチで指定する)やCI/CDインテグレーションもサポートする。

WeaveworkのFluxツールは同社の“GitOps”思想を具現化したもので、Kubernetesクラスタの状態とバージョン管理(“真実の唯一の情報源(single source of truth)”)で指定されたものが一致することを自動的に保証する。Fluxの全体的な目的は、サービスのデプロイメントの自動化にある。一般的なユースケースは次のようなものになる — 開発者がサービスを修正し、GitHubスタイルのプルリクエストを作成する。運用中のクラスタに更新の必要が発生する。Fluxが変更を検出してクラスタに展開する。その後、Fluxがクラスタの状態を維持する(障害発生時など)。Fluxはさらに、これらの操作を手動で行うためのCLIとUI(Weave Cloud)も提供しており、CI/CDツールに統合されている。

Gitkubeは、Cloud Foundryの“cf push”モデルと同じように、“git push”を使ってDockerイメージの構築とKubernetes上へのデプロイを行うツールである。プロジェクトのWebには、GitKubeは“開発者がWIPブランチをテストのためにクラスタにプッシュできるという意味で、開発には理想的”であり、gitベースのオートメーションを実現する上でのリファレンス実装を目指している、とされている。その一例として、Gitkubeリポジトリをフォークして、Kubernetesクラスタ上で自動操作を実行するKubernetes Custom Resource Definition (CRD)とコントローラ、gitリモートフックを作成する方法が紹介されている。

HeighlinerはKubernetesのためのGitHub Flowを提供するツールである。GitHubで新たに作成されたプルリクエストは自動的にターゲットのKubernetesクラスタにデプロイされ、“実際の変化を容易にレビューすることが”可能になる。新たなGitHubリリースが作成されると、Heighlinerが自動的にその変更を運用環境にステージングする。ksyncは、クラスタ上で実行しているコンテナを、ローカルから透過的にアップデートすることで、Kubernetesでの開発のスピードアップを目的とする。この操作は、ローカルファイルシステムをクラスタ内のストレージと直接同期させることによって行われる(ローカルで実行されるバイナリとクラスタの各ノードでリモート動作するDaemonSetとして実装されている)。

Skaffoldに関する詳細な情報は、同プロジェクトのGitHubリポジトリにある。GKEのGetting Startedガイドや、READMEのインストラクションに従ったローカルインストールガイド(Minikubeを使用する)も公開されている。議論やフィードバックはメーリングリストに参加するか、あるいはGitHubのイシューをオープンして頂きたい。