编译容器中的 gRPC 服务定义.proto 文件

为了确保编译 gRPC 服务定义 .proto 文件时的一致性和可重现性，容器化 protoc 步骤是一个有效的方法。它可以通过使用 Dockerfile 创建一个容器，其中安装了 protobuf 编译器和 gRPC 的 Go 插件。在容器内运行 protoc 命令可以确保在不同的开发环境中产生相同的输出。

假设我们有一个带有 grpc 服务定义的 services.proto，例如：

service foo {
  rpc bar (barrequest) returns (barreply) {}
}

message barrequest {
  string test = 1;
}

message barreply {
  string test = 1;
}

我们可以通过运行类似的东西将其本地编译为 go

$ protoc --go_out=. --go_opt=paths=source_relative \
    --go-grpc_out=. --go-grpc_opt=paths=source_relative \
    services.proto

我担心的是，运行最后一步可能会产生不一致的输出，具体取决于安装的 protobuf 编译器版本和 grpc 的 go 插件。例如，从事同一项目的两个开发人员本地安装的版本可能略有不同。

对我来说，通过容器化 protoc 步骤来解决这个问题似乎是合理的。例如，使用这样的 dockerfile...

from golang:1.18
workdir /src
run apt-get update && apt-get install -y protobuf-compiler
run go install google.golang.org/protobuf/cmd/[email protected]
run go install google.golang.org/grpc/cmd/[email protected]
cmd protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative services.proto

...我们可以在容器内运行 protoc 步骤：

docker run --rm  -v $(pwd):/src $(docker build -q .)

将前面的命令包装在 shell 脚本中后，开发人员可以在本地计算机上运行它，从而提供确定性的、可重现的输出。它还可以在 ci/cd 管道中运行。

我的问题是，这是一种合理的方法和/还是有更简单的方法来实现相同的结果？

注意，我很惊讶地发现官方 grpc/go 镜像没有预装 protoc。我这里是不是偏僻了？

正确答案

这绝对是一个好方法。我也一样。不仅要在整个团队中保持一致，还要确保我们可以在不同的操作系统中产生相同的输出。

不过，有一种更简单的方法可以做到这一点。 看看这个仓库：https://github.com/jaegertracing/docker-protobuf

该映像位于 docker hub 中，但您可以根据需要创建自己的映像。

我使用这个命令来生成go：

docker run --rm -u $(id -u)  \
    -v${PWD}/protos/:/source  \
    -v${PWD}/v1:/output  \
    -w/source jaegertracing/protobuf:0.3.1  \
      --proto_path=/source \
      --go_out=paths=source_relative,plugins=grpc:/output \
      -I/usr/include/google/protobuf  \
      /source/* 

好了，本文到此结束，带大家了解了《编译容器中的 gRPC 服务定义.proto 文件》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！