今週初め、MicrosoftはBridge to Kubernetesをリリースした。Kubernetes環境から依存関係を参照して、マイクロサービスコードをローカルで記述、テスト、デバッグすることの可能な、Visual Studio用のエクステンションである。その目的は、DockerfileやKubernetesマニフェストといった外部アセットのニーズを低減することによる、マイクロサービス開発の簡略化にある。
Bridge to Kubernetes(以前はLocal Process with Kubernetesという名称であった)は、マイクロサービス開発の簡略化を目的として、Visual StudioおよびVS Code用のエクステンションとして提供される、反復型開発ツールである。Microsoftの公式資料によると、
Bridge to Kubernetesによって、Kubernetes上のアプリケーションやサービスとの接続を維持したまま、自身の開発用コンピュータで上でコードを実行し、デバッグすることが可能になります。[...] DockerやKubernetesコンフィギュレーションを作成しなくとも、完全なアプリケーションのコンテキスト内で、自身のサービスを迅速にテストし、開発することができます。
このツールは、ローカルマシンと接続先のKubernetesクラスタ間の通信をリダイレクトすることで動作し、ローカルコードとリモートサービスがあたかも同じKubernetesクラスタ上にあるように通信できるようにする。環境変数やマウントされたボリュームをローカルにレプリケートする手段も提供されるため、これらの依存関係を手作業で再作成する必要はない。
同社プログラムマネージャのNick Greenfield氏によれば、このツールは、既存のDev Spaces for Azure Kubernetes Services (AKS)の軽量版である。
Dev Spacesは、クラスタ内で直接実行されているコードの操作を支援することにより、運用環境と厳密に一致するローカル環境のレプリケーションを不要にするものです。このアプローチでは、環境の忠実性など、開発のある面については改善されますが、その反面、DockerやKubernetesなどの新しいコンセプトを学習するという前提条件や、事前にHelmを起動する必要などが新たに加わることにもなります。
これに対してBridge to Kubernetesでは、DockerやKubernetesのコンフィギュレーション作成の必要性を取り除くことで内部ループの複雑性が低減するため、開発者はコードのビジネスロジックのみに集中できるようになります。開発者自身の開発用コンピュータで直接作業しながら、クラスタ上で動作する他のサービスとインタラクションすることが可能になるのです。このアプローチには、作業環境への習熟性やローカル実行による速度向上と、クラスタの提供する依存関係や環境の共有を両立できるというアドバンテージがあります。Kubernetes内で実行することによる実行環境の忠実性やスケーラビリティもメリットです。
新しいツールのもうひとつのメリットは、開発環境の共有と作業の独立性の両立が可能になることだ。共有クラスタ内での独立した開発作業というのは、ローカルマシンとクラスタとの間のすべてのトラフィックが分離されているということであり、(複数の開発マシンと単一のKubernetesクラスタ間で確立する)複数のデバッグセッションによる相互影響を防止することができる。
今回のリリースは、Microsoftが近年取り組んでいる、マイクロサービス開発における開発者の生産性向上を目指す活動の最新のものになる。今年初めにMicrosoftがリリースしたProject Tyeは、複数のサービスのローカル実行や、.NETアプリケーションのKubernetesへのデプロイの自動化といった機能の提供によって、"マイクロサービスの開発を容易にする"ことを目指すツールである。ただし、Bridges to Kubernetesとは違い、Project Tyeは実験的プロジェクトという位置付けであり、.NET 5が公式リリースされた時点での再評価が予定されている。
Bridge to KubernetesはVS CodeおよびVisual Studio(バージョン16.7以降)のエクステンションとして提供される。Azure Dev Spacesを利用するクラスタでは使用できないので、その点にも注意が必要だ。既知の問題や追加予定の機能などの情報はこちらにある。