サイボウズエンジニアのブログ2019-07-19Kubernetesアプリケーションの開発、デバッグを高速化するツール、Telepresenceの紹介Kubernetesこんにちは、Necoプロジェクトのsatです。本記事ではKubernetes(以下K8sと記載)アプリケーション(以降アプリと記載)の開発を高速化するツール、Telepresenceを紹介します。最初に結論を書いておくと、Telepresenceは次のようなツールです。FoundationのSandBoxプロジェクトです。前節において"開発を高速化する"と書きましたが、まずはTelepresenceを使わないときの開発、デバッグはどのようになっているのかについて述べます。あるアプリがKubernetesクラスタにdeployされている状態を初期状態とすると、次のようになります。imageなどによってアプリが変更後のコンテナイメージを使うようにするアプリのPodを変更後のコンテナイメージを使って再起動するこのときコンテナイメージのpushからPodの再起動までにはそれなりの時間待たされるため、一回ソースを変更してからそれを動かすまでのサイクルが長くなりがちというのがK8sアプリ開発の大きな問題です。コンテナイメージのサイズが大きいほどこのサイクルは長くなります。この部分を高速化してくれるのがTelepresenceです。次節以降はTelepresenceがどういうものなのかを実際に使いながら紹介します。公式サイトの手順に従ってインストールします。18.04の場合は次のコマンドを使います。ローカルコンテナをK8sクラスタ内で動かすまずはTelepresenceの基本機能である、ローカルコンテナをK8sクラスタ内で動かす方法について書きます。K8sクラスタの作成kindを使ってK8sクラスタを作ります。ここではクラスタの作成にkindを使います。kindのインストール方法については以前紹介したkindについての記事を参照ください。サービスをdeploy以下のhello.yamlというマニフェストを使ってhellow-world-web-serverというアプリをクラスタ上で動かします。world!"という文字列を返すというアプリです。次のようにdeployした上でservice化します。104m$ここまでで、クラスタ内部からはこのアプリにhello-world-web-serverという名前、ないし10.109.22.168によってアクセスできます。その一方でこの設定ではクラスタの外からはアクセスできません。8000にアクセスしてみます。hello-world-web-server$クラスタの外からのアクセスなので失敗しました。これは想定通りの動きです。ローカルプロセスからクラスタにアクセスできない続いてTelepresenceを介して同じプロセスを動作させるとどうなるでしょうか。telepresence-1562306285-3227046-17962アクセスが成功しました。本節冒頭で述べたようにTelepresenceによってローカル環境にあるプロセス(および後述するコンテナ)がクラスタ内にいるかのように扱えることがわかりました。ローカルプロセスからクラスタにアクセスできるこのときTelepresenceは実行ログをtelepresence.logに出力します。同様にクラスタ内でshellを動かすこともできます。world!shellを含むプロセスだけではなく、クラスタ内でコンテナを動かすこともできます。deployment内のコンテナをローカル環境で動作するコンテナで差し替える初期状態はサンプル1の終了時点であるとします。通常は実行中のアプリのコンテナを差し替えるには前述のようにコンテナイメージをビルドした後に次のような手順が必要です。imageによってアプリが使うコンテナを変更するアプリのpodを再起動してコンテナをリロードこれに対してTelepresenceを使う場合はアプリが使うコンテナをローカルで動くものに差し替えられます。別のいいかたをすると上記の手順をすべて省略できます。ソースの準備hello-world-web-serverコンテナのソースをダウンロードしてhello-world-web-server:0.1に相当するバージョンをチェックアウトします。telepresence!"で差し替えます。コンテナイメージをビルド次のようにコンテナイメージをビルドします。アプリ内のコンテナをローカルのものと差し替える次のようなコマンドを発行します。worldサービスにアクセスすると差し替え後のコンテナを使っているのがわかります。deleted$下図において、通常は点線の矢印のようにアクセスするはずですが、Telepresenceによって実線の矢印のようにアクセスするようになります。変更したコンテナとDeployment内のコンテナを差し替えられる最後に環境を綺麗にしておきましょう。複数コンテナから成るdeployment内のコンテナの差し替えサンプル2の最後の状態で次に示すmulti-container.yamlというマニフェストを読み込みます。このDeploymentの中にはhello.yamlの場合に加えてsleepし続けるdummyというコンテナが存在します。8000Telepresenceはコンテナを特定するためにdeployemt名を指定する際に<deployment名>:<コンテナ名>という書き方ができます。...ここで別端末からhello-world-web-serverにアクセスすると変更後のコンテナが見えます。deleted最後に環境を綺麗にしておきます。multi-container.yamlおわりに弊社におけるTelepresenceを用例を一つ紹介しておきます。弊社には日本国内のインフラ基盤を刷新するNecoプロジェクトとは別に、US向けのインフラ基盤を刷新するYakumoというプロジェクトもあります。こちらでもTelepresenceがすでに活発に使われています。Yakumoで提供されるkintoneは国内のデータセンターで提供されていたkintoneと構成が異なるため、AWS移行と同時にkintoneのテストケースの修正も発生します。Jobとして実行しています。このテストのテストケース数は数千にも及ぶので、テストを修正する度にJobをデプロイしてると確認に時間がかかります。そこでYakumoチームではTelepresenceを使って特定のテストケースだけをローカル環境で実行することによって、待ち時間を大幅に削減できています。Necoプロジェクトにおいても開発が進むにしたがってk8sアプリのサイズが多く、かつ、それぞれのサイズ大きくなってきたことにより、今後ますますTelepresenceを使う場面が増えていく見込みです。最後になりますが、K8sアプリの開発において本記事で述べたような問題をかかえているみなさまは、ぜひTelepresenceを試していただきたいとおもいます。罠こんにちは、はじめまして。