ソフトウェアスタートアップのWeaveworksは創立5周年を、Weave Igniteと呼ばれるオープンソースプロジェクトのリリースで自ら祝福した。同プロジェクトは自身を、"コンテナUXを備えたGitOps管理の仮想マシン(VM)"と称している。この斬新なソフトウェアには、AWS Lambdaを支えるAWS オープンソースプロジェクトであるFirecrackerが使用されている。プロジェクトの詳細をさらに知るべく、InfoQは、同プロジェクトの開発チームに話を聞くことにした。
Weave Igniteに関するブログ記事では、同社CEOのAlexis Richardson氏が、その動作構造について説明している。
Igniteは、コンテナの開発者エクスペリエンスを取り入れることによって、Firecrackerを使いやすいものにします。VMとして実行するOCI準拠のイメージ(Dockerイメージ)を選択したならば、"docker run"ではなく、"ignite run"を実行してください。VM専用のツールを使用して.vdiや.vmdk、あるいは.qcow2イメージをビルドする必要はありません。お望みのベースイメージからdockerビルドを実行して、必要なコンテンツを追加すればよいのです。
ignite runを使用してOCIイメージを実行すると、デフォルトでは4.19 Linuxカーネルを使って、Firecrackerが約125ミリ秒(!)で新たなVMを起動してくれます。
Richardson氏はユースケースとして、テストや一時的なワークロードを目的とした多数のセキュアVMの高速起動、スタック全体の一括起動、軽量VM上でのレガシアプリの実行、などを挙げた。
Amazonは昨年11月、オープンソースの仮想化技術Firecrackerをリリースした。Weaveworksが今回Igniteで実現したことは、オープンソースのあるべき姿の理想的な表現である、とジャーナリストのMatt Asay氏は述べている。
技術自体は非常にクールだと思いますが、素晴らしい部分が他にもあります。それはAWSが作り上げなかった部分です。AWSはFirecrackerを開発し、オープンにすることで、@weaveworksのような他の開発者がそれを作り上げられるようにしたのです。これはオープンソースの真にあるべき姿です。
Weave Igniteが任意の場所で機能することを実証するため、Walmart Labsのエンジニアたちは、Google CloudでIgniteを機能させる方法をブログ記事で説明した。
Weave Igniteの詳細を知るためにInfoQは、Weaveworksにコンタクトを取り、CEOのAlexis Richardson氏と、作者であるLucas Kldström氏から話を聞くことができた。
InfoQ: Igniteが生成するのは、永続的な状態を保存したり、独自のコンテナをホストしたりできる"本物の"VMなのでしょうか？従来のハイパーバイザによって作成されたVMとは違っているように見えるのですが。
Weaveworks: はい、本物のVMを生成します。ただし、"従来の"VMとは少し違います。例えば、
Firecrackerは、最小限のKVM実装として設計されています。
`.iso`ファイルのような"ブート可能"なディスクや、ベンダ固有の`.vdi`、`.vmdk`ファイルを生成するPackerようなサポートツールを使用する代わりに、コンテナ業界の標準であるOCIイメージからルートファイルシステムを使用しています。
宣言的コンフィギュレーションとGitOps経由のオペレーションをサポートしています。
FAQ.mdも参照してください。
InfoQ: Firecrackerについて詳しく知らない人に、説明をお願いします。
Weaveworks: Firecrackerは、Linux用の最小限の仮想化実装です(KVMを使用しています)。
Firecrackerは、サーバーレスワークロードの新時代のために開発されました。従って設計面から、セキュリティと速度に最適化されています。要するに、指定されたLinuxカーネルとディスクからVMを起動し、監視するのがFirecrackerなのです。
https://firecracker-microvm.github.io/の説明よれば、FirecrackerはLinuxカーネルベースの仮想マシン(KVM)を使用して、microVMを生成し管理する仮想マシンモニタ(VMM)を実装しています。設計上は極めてシンプルで、不要なデバイスやゲスト機能を取り除くことで、microVM毎のメモリフットプリントと攻撃対象領域を削減しています。これにより、セキュリティが向上し、起動時間が短縮され、ハードウェアの使用率が向上します。
InfoQ: "コンテナの開発者エクスペリエンス"を採用したことによって、Igniteは、素のFirecrackerに対してどのように使いやすくなっているのでしょうか？
Weaveworks: Firecrackerに対するIgniteは、OCIコンテナランタイム実装であるrunCに対するDockerと同じ関係にあります。
runCと同じように、Firecrackerは、低レベルのコンポーネントを意図したものです。今日では、コンテナを実行する場合、runCを直接使用するのではなく、Dockerやcontainted、あるいはKubernetesなどの高レベルのツールを使用します。それと同じで、LinuxカーネルやKVMの開発者でない限り、Firecrackerを効率的かつ正しく使用する方法を理解するのは難しいでしょう。コンテナからDXを取得し、DockerやOCIイメージ仕様などのコンテナランタイムと統合することで、Igniteは、コンテナを実行するのと同じようなエクスペリエンスを、VMを実行するユーザに提供します。仮想ブロックデバイスや仮想イーサネットインターフェースを定義するよりも、はるかに簡単です。
InfoQ: Igniteをマシンで動作させるために、必要なコンポーネントは何ですか？
Weaveworks :基本となるのはDocker on Linuxです。こちらの手順を参照してください。
詳細としては、まず必要なのが、KVMの有効なLinuxを立ち上げることです。Firecrackerは設計上、Linuxの独自機能であるKVMを実装しているので、これは必須の要件です。次に、Docker(現在サポートされている唯一のランタイムですが、近々追加される予定です)など、Igniteが統合するコンテナランタイムをインストールします。その上で、Igniteバイナリをダウンロードしてください。それで終わりです！
InfoQ: GitOpsはインフラストラクチャ・アズ・コードの進化形なのでしょうか？GitOpsの概要について、少し教えてください。
Weaveworks: GitOpsは、Kubernetesクラスタの管理とアプリケーションのデリバリを自動化する手段です。GitOpsを概念的に理解している人、使用している人はたくさんいますが、その価値を完全に引き出せている人はほとんどいません。オペレーションに対して行うことのできる最も重要な改善、それこそがGitOpsなのです。
GitOpsでは、実行時状態を継続的に監視し、それを目的の状態(宣言型構成として保存)と比較することによって、実行中のシステム全体を管理します。監視された状態が望ましい状態を外れている場合には、Kubernetes、Flux、Flaggerといったオーケストレータを使用してシステムを正しい状態に収束させ、収束できない場合にはアラートを発行します。このような方法で、ポリシに従って、100％自動的に、クラスタやアプリ群を設定値から直接プロビジョニングおよび管理することが可能になるのです。さらにWeave Igniteを使用することで、Kubernetesと同じような、構成から管理される最初のVMテクノロジを手にすることもできます。
Weaveのプロダクトはクラスタの生成、スケールアップとスケールダウン、アップグレードとパッチの適用、さらにD/Rの管理にもGitOpsを使用しています。フリートを自動化し、多数のクラスタやテンプレートやコンフィギュレーションを管理することが可能です。第2に、デプロイメント用にスクリプトを、自動化された継続的アプリケーションデプロイメントに置き換えることができます。プログレッシブデリバリ — カナリアや機能フラグを使用したA/Bテスト — を実行したり、ポリシをコントロールしたりすることも可能です。このすべてをCIツール、イメージレジストリ、Gitリポジトリで行うのです。
そうですね、GitOpsはdevopsとIaCの進化版ですが、さらに重要な改善が行われています。何が変わったのか？GitOpsはおそらく、構成ベースの管理の元々のビジョンを最大限に活用しています。
インフラの"ボックス"とインストール済みソフトウェアをプロビジョニングするのではなく、アプリケーションやサービス、メッシュ、カナリア、さらにはボックスなど、実行中のソフトウェアスタック全体を管理します。
不変(immutable)コンテナと設定ファイルをデプロイします。CIや開発者が直接ランタイムに触れることはなく、不変性というファイアウォールを経由します。
システムのドリフトを継続的にチェックします。比較の可能な、完全な説明を用意しています。
実行中のシステムに対する変更はすべて、いかに些細なものであっても、構成の変更によって行われます。
対照的にkubectl、ssh、UI、CLI、あるいはOpenShiftなどの集約ファサードなど、他のインターフェースは使用しません。
Git + CIスクリプトではなく、Git+オーケストレーションを使用する必要があります。CDではCIスクリプトを使用しません。中断して不確実な状態に陥る可能性があるからです。Gitの更新には手動またはCIベースの変更手段を使用しますが、CIでデプロイメントのオーケストレーションを行うことはできません。Kubernetesあるいはそれに代わるオーケストレータのみがコンバージェンスと原子性を適用可能だからです。
この方法でもプログレッシブ配信と機能フラグを管理します — こちらのYAMLを参照してください。
環境全体には、プレイブックやダッシュボードなど、非プログラム的資産も含まれます。アプリを更新する場合には、監視やアラート、運用ドキュメントなどの更新も、すべて同じバージョン管理下で行う必要があります。
開発者に設定ファイルを記述させなたくないので、コードからYAMLを安全に生成し、フリートやパイプライン、ポリシーベースのopsアクション用のテンプレートを管理するために、Typescriptなど高次プログラミング言語を使用しています。CIベースのスクリプトモデルとは異なり、スケールアップも容易です。
InfoQ: Igniteの開発にあたって、Firecrackerプロジェクトにアップストリームの変更を提供する必要はありましたか？
Weaveworks : いいえ、問題なく動作しました :)
InfoQ: 自社のクラスタ管理プロダクトを使用するWeaveworksなど、考えられるユースケースをいくつか紹介していましたが最も興味があるのはどの開発者ユースケースですか？
Weaveworks: ひとつ選択するならば、テストですね。テストやCI、その他さまざまな開発用に、ゼロコストでk8sクラスタをスピンアップできれば素晴らしいと思いますが、そこまで行かなくても、Ignite上でセキュアなKubernetesクラスタを素早く起動できることによって、簡単になるユースケースはいくつかあります。紹介用のブログ記事を参照してください。"ignite run"を数回実行するだけで、好みのKubernetesインストーラ、例えばWeaveworks Kubernetes Platform用にWeaveworksが最初からオープンソースとして開発した、コミュニティ製ツールのデファクトであるkubeadmを使って、マシンにKubernetesｈがインストールされるのです。完了すればGitopsデータセンタ全体を、最新のクラウドネイティブツールを使用してどこでも実行することができます。