スマブラのオンラインにあんま入ってなかったら、めっちゃ世界は強くなってて萎えてます。
envoyを触っているので、そのメモです。
envoyとは
いわゆるproxyです。簡単に言うとリクエストを受けて、いろいろ処理をしてからバックエンドに流すやつですね。
gPRCをリクエストで受けて、そのリクエストをLBのように分散することができます。
似た役割ではnginxなどがあてはまり、他にもいくつか似たようなツールが紹介されています。
envoyに関しては、kubernetes文脈ではdata planeとして語られることが多いですが、ただのproxyなのでkubernetesでなくてももちろん使えます。
対応しているリクエストの種類も多く、Mongo、Dynamo、Redisの負荷分散などもできます。
その他にも機能がかなり豊富なので、調べてみると面白いかもしれません。
あとは、envoyはシングルプロセス、マルチスレッドで動くためnginxのようなマルチプロセスよりもcontainerに向いていると思っています。
envoyという選択は、AWSのAppMeshでも使われるので、今後メインのsidecar proxyとして使われることが予想されるでしょう。
やりたいこと
やりたいことは以下です。
- envoyをsidecar *1 に乗せて、goのアプリケーションを動かしたい。
- front serverとbackend serverの通信はgRPC
図で表すと以下のような形になります。
実際の設定
以下のページでサンプルがあるのですが、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の設定
基本的に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環境で動かすというのを説明を交えながら、解説してみました。
*1:sidecarに関しては、ここが詳しい https://docs.microsoft.com/ja-jp/azure/architecture/patterns/sidecar
