Kubernetesクラスターの遠隔操作による開発を支援するTelepresence

連載 :

イベント・セミナー2021

2021年5月26日(水)

ローカルの開発環境と本番環境の橋渡しをするTelepresenceを紹介する。

この記事では、CNCFのサンドボックスプロジェクトからTelepresenceを紹介する。Telepresenceは2018年5月22日にサンドボックスプロジェクトとして採用されたオープンソースの開発用ツールである。Telepresenceという名前が示すようにKubernetesクラスターに対して開発用PCから遠隔操作することで「自分のPCでは動いていたのに本番環境ではエラーになる」というデベロッパーのジレンマを解消するためのツールである。

ちなみに「Telepresence」という名称はシスコのビデオ会議システム「TelePresence」とかぶってしまうため、単純に検索を行うとシスコ製品の情報もヒットしてしまう。Telepresenceの情報を求めている場合は、「Telepresence CNCF」で検索すれば、CNCFが公開した動画など必要なものがヒットするだろう。

今回は2020年に開催されたKubeCon/CloudNativeCon Chinaでのセッションから、Telepresenceの概要を紹介する動画から解説する。

動画：Intro: Telepresence: Fast Local-to-Remote Development for Kubernetes - Daniel Bryant, Datawire

CNCFがサンドボックスプロジェクトとして採用したことを紹介するブログ記事には、開発のための体制として100％ローカルから100％リモートで行う際の利点／欠点を解説したチャートがあり、それぞれの特徴を理解することができる。

CNCFのブログから引用。開発環境の違いを解説

ただ多くのビジネスがモノリシックなシステムからマイクロサービスに移行していく現在の状況では、システム内で利用されている多くのサービスを100％ローカルの開発用PCに配備して開発を行うのはすでに困難だろう。多くの企業がローカルとリモート／クラウドの間のどこかで折り合いを付けているという状況であると想定される。

CNCFのブログ：CNCF to host Telepresence in the Sandbox

OSやツールやライブラリーの違いを吸収して、アプリケーションをどこでも稼働させられるようになったのは、コンテナテクノロジーの大きな貢献と言える。しかしそれでもローカルのPCとオンプレミスやパブリッククラウドとの違いは大きく、多くのデベロッパーが「ローカルの開発用PCでは動くのにクラウドに置いたら動かない」というトラブルに遭遇しているのではないだろうか。そして、それを解消するためのツールがTelepresenceである。

セッションのタイトル。「Local-to-Remote Development」に意味がある

このセッションはAmbassador LabsのエンジニアDaniel Bryant氏によるものだ。Bryant氏の所属として記載されているDatawireは、現在Ambassador Labsとしてブランディングを行っている。DatawireはEnvoyをベースにしたオープンソースのAPI GatewayであるAmbassadorの開発を行っており、2020年4月29日にインキュベーションプロジェクトとして採用されるための申請を行っている。時系列的にはTelepresenceが先にサンドボックスプロジェクトとして採用され、2020年にAmbassadorがインキュベーションプロジェクトとして申請されたということになる。

どちらもKubernetesのネットワーク関連のソフトウェアであり、Ambassador Labsの強みがでた形になっている。Ambassador LabsはMIT卒、ハーバードビジネススクール卒でRed HatのエンジニアであったRichard Li氏が創業したボストンのベンチャーだ。

セッションを行うBryant氏。Ambassador LabsのDev Rel Directorである

このセッションの冒頭にまとめとして、マイクロサービス＆Kubernetesの開発が難しいこと、TelepresenceがProxyとして利用できることなどが紹介された。最初に結論を述べてからそれを実証していくというのは、バーチャルセッションの視聴者の注意力、集中力を維持していくためには効果的だ。

このセッションのまとめ

「tl;dr」は「Too Long, Didn't Read」の略で「文章が長過ぎて、読んでいません」から転じて「要約」と意味で用いられることがあるネットスラング。

最初に紹介したのはこのまとめにも使われている「インナーループ」「アウターループ」という概念だ。具体的に言えば、インナーループはデベロッパーが開発用PCで行う作業、アウターループはそれを開発環境やステージングなどに配備して行う検証ということになる。

インナーループとアウターループの解説

自分が使うPCでコードを書き、ビルドしてテストそれが上手くいけば本番に近い環境で統合テストを行い、最終的に実装するというやり方が現在の開発スタイルとしては一般的だ。Kubernetesの環境下で開発用PCと本番環境を同じに揃えることは論理的には可能だが、実際には無理があるというのがBryant氏の指摘するポイントだ。

Kubernetesでの開発を開発用と本番環境で揃えるのは無理がある

またKubernetesのエコシステムにはDraftやSkaffold、Gardenなどのツールが用意されているが、それでも開発用PCと本番環境を同じにすることは難しい。またビルドしたバイナリーをDocker Hubなどのレジストリーにプッシュすることを考えれば、多くのオーバーヘッドがあることは自明だ。