envoyのsidecarでgRPCを受ける with docker-compose

スマブラのオンラインにあんま入ってなかったら、めっちゃ世界は強くなってて萎えてます。

envoyを触っているので、そのメモです。

envoyとは

いわゆるproxyです。簡単に言うとリクエストを受けて、いろいろ処理をしてからバックエンドに流すやつですね。

gPRCをリクエストで受けて、そのリクエストをLBのように分散することができます。

似た役割ではnginxなどがあてはまり、他にもいくつか似たようなツールが紹介されています。

envoyに関しては、kubernetes文脈ではdata planeとして語られることが多いですが、ただのproxyなのでkubernetesでなくてももちろん使えます。

対応しているリクエストの種類も多く、Mongo、Dynamo、Redisの負荷分散などもできます。

その他にも機能がかなり豊富なので、調べてみると面白いかもしれません。

あとは、envoyはシングルプロセス、マルチスレッドで動くためnginxのようなマルチプロセスよりもcontainerに向いていると思っています。

envoyという選択は、AWSのAppMeshでも使われるので、今後メインのsidecar proxyとして使われることが予想されるでしょう。

やりたいことは以下です。

図で表すと以下のような形になります。

f:id:yuutookun:20190203182310j:plain

以下のページでサンプルがあるのですが、sidecar形式ではなくbackendのアプリケーションと同じcontainerにenvoyを乗せていました。

なので、sidecar形式にするようforkして作りました。以下のレポジトリの examples/grpc-bridge 以下です。

本家とほぼ同じです。GOPATHがちゃんと設定されていれば、以下手順で動くはず。 docker-composeが複数あるので、 build.sh にまとめています。

$ pwd
envoy/examples/grpc-bridge
$ script/bootstrap
$ script/build
$ script/build.sh

基本的にenvoyの設定は以下です。

static_resource
 - listener: 受け側の設定
 - cluster: 流し先の設定

listenersのfiltersの中でどのclusterに流すかという設定をします。例えば、python containerからsidecar containerへは routes にて、prefixやclusterの設定をすることでどこに流すかを決めます。

clusterの設定では、typeでIPの解決をどうするかを決めます。

- static: 単一のホストのみ
- strict DNS: DNSで解決されたIPのみ
- logical DNS: DNSで返される一つのIPを利用。ホスト全IPは取らず、初回接続のみIP解決

詳しくはこちら service_discovery

docker-composel環境で動かすというのを説明を交えながら、解説してみました。