Go言語で実装するプラグイン機構
ソフトウェアに拡張性を持たせる時にプラグイン機構を持たせる事は一般的ですが、それを実現する方法は結構バラバラなのかなと思います。例えば、
- C言語等の.so/.dllを読み込む方法
- Nodejsのような言語での単なるimport
- TCPやUnixソケットを利用してRPC通信を行う方法
などが有るのかなと思います。1番目・2番目は、関数の呼び出し速度等のオーバーヘッドが少なく高速ですが、言語等の制約が大きくなる・メモリを共有することによるセキュリティリスクが発生します。そこで、提供するインターフェースを制約出来る場合は、3番目の手法が多く使われるようです。
Go言語で開発されている、hashicorp/terraform cloudfoundry/cli は共に3番目のRPC通信でプラグイン機構を実装しています。その中でもterraformで使用されているプラグイン機構は、言語への依存が低いという特徴があり、興味深いので調べてみました。
hashicorp/go-pluginを試す
https://github.com/hashicorp/go-plugin
HashiCorpが開発しているライブラリで、Packer, Terraform, Nomad, Vault等の内部で利用されています。RPCにgRPCを使用していて、ホスト側のライブラリはGo言語ですが、クライアント(プラグイン側)の言語依存がほぼ無いのが特徴です。Go+Go/Go+Nodejs/Go+Python等の構成が非常に簡単に実現できます。また、実装も非常に軽いです。
試しにGoのホストと、Scalaのプラグインという構成で雑に試してみました。
サンプルリポジトリ: https://github.com/kamijin-fanta/go-plugin-example
このような簡単なサービスを実装してみました。サービスの定義・実装は素のgRPCとして実装するので、言語に合ったツールを使用します。Scalaでのサーバ実装には、protocの代わりに ScalaPB のコード生成を使用しました。traitが自動的に生成されるので、それぞれのメソッド(ここではSayHello)を実装するだけです。
// サービス定義
syntax = "proto3";
package com.example.protos;
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}// サーバ実装
class GreeterImpl extends GreeterGrpc.Greeter {
override def sayHello(req: HelloRequest) = {
val reply = HelloReply(message = "Hello " + req.name)
Future.successful(reply)
}
}var Handshake = plugin.HandshakeConfig{
ProtocolVersion: 1,
}
var PluginMap = map[string]plugin.Plugin{
"greeter": &GreeterGRPCPlugin{},
}
client := plugin.NewClient(&plugin.ClientConfig{
HandshakeConfig: Handshake,
Plugins: PluginMap,
Cmd: exec.Command(os.Getenv("PLUGIN")),
AllowedProtocols: []plugin.Protocol{plugin.ProtocolGRPC},
})
rpcClient, _ := client.Client()
raw, _ := rpcClient.Dispense("greeter")
service := raw.(Greeter)
result, _ := service.Hello("fukuyama") // Hello fukuyama多くのコードを省略しているので、詳細はリポジトリよりコードを探してください。
通信フロー
hashicorp/go-pluginでは、TCPのgRPCを用いて通信を行いますが、ホストはポート番号等をどうやって知っているのでしょうか？簡単に図にしてみました。
- ホスト側はプラグインをForkExecする
- プラグインはネゴシエーションのための文字列を標準出力でホストに伝える (APIバージョン/接続プロトコル/Listenアドレスが含まれる)
- ホスト側のAPIバージョンと一致していれば、指定されたアドレスへgRPC接続を行う
- サービスのヘルスチェックを行う
- プラグインの通信を行う
- 通信が終了する際にホストはプラグインのプロセスを終了する
Negotiation
ネゴシエーションの為にプラグインからホストに送られる文字列は、1|1|tcp|127.0.0.1:1234|grpcの様な形式です。
CORE-PROTOCOL-VERSION | APP-PROTOCOL-VERSION | NETWORK-TYPE | NETWORK-ADDR | PROTOCOLCORE-PROTOCOL-VERSIONgo-plugin自体のAPIバージョンで、現在は1APP-PROTOCOL-VERSIONユーザが用意するAPIのバージョンNETWORK-TYPEunixかtcpが指定可能NETWORK-ADDR接続先のアドレスPROTOCOLgrpcかnetrpcが指定可能
Health Check
ヘルスチェックは、gRPCを通じて行われます。プラグイン側はHealthサービスを実装している必要があります。とりあえず面倒なら常に status: ServingStatus.SERVING を返しておけば良いです。
message HealthCheckRequest {
string service = 1;
}
message HealthCheckResponse {
enum ServingStatus {
UNKNOWN = 0;
SERVING = 1;
NOT_SERVING = 2;
}
ServingStatus status = 1;
}
service Health {
rpc Check(HealthCheckRequest) returns (HealthCheckResponse);
}health.proto: https://github.com/grpc/grpc/blob/master/src/proto/grpc/health/v1/health.proto
雑記
これを調べるきっかけは、Grafanaを調べている時に見つけたBackendPluginsでした。Grafanaのプラグインの種類は他に、Palnel Plugin, Datasource Pluginの2種類有るのですが、いずれもJSで記述するフロントエンドのプラグインです。認証等のコードを差し込めるように用意されたのがBackend Pluginsです。
Developing Backend Plugins: https://grafana.com/docs/plugins/developing/backend-plugins-guide/
このプラグインに採用されている仕組みが hashicorp/go-plugin でした。現在はDataSourceとRendererの2つのAPIしか用意されていないようですが、今後増えてくると拡張性が非常に増すのではないかと思います。
公式が用意している grafana/grafana-image-renderer プラグインは、TypeScriptで全て書かれています。言語に依存されない利点を活用しています。Nodejs上でgRPCサーバを用意し、今回のガイドと同じ様な実装を行ってサービスをプラグインとして提供しています。まだサードパーティのプラグインを受け入れるという感じでは無いのが悲しいですが、時間の問題だと思います。
↑水と油のリポジトリ
