容器：开发/服务网格

服务网格

本页面解释了以下服务网格组件的构建和打包过程

• envoy-proxy
• istio-proxy - 我们现在可以暂时放弃它，直到我们想打包完整的 Istio！cilium-proxy 曾经需要 istio-proxy 来构建，但现在不再需要了
• cilium-proxy

包结构

envoy-proxy 是 devel:kubic 项目中的一个包，包含以下源和规范：

• envoy-proxy
• istio-proxy - 我们现在可以放弃它了
• cilium-proxy

istio-proxy 和 cilium-proxy 包是 envoy-proxy 包的链接。这样做是为了将这三个项目一起构建，因为它们相互依赖源代码。

问题

这些项目的打包存在一些问题，使其非同寻常。

Bazel

Bazel 是一个构建系统，旨在构建捆绑库的软件。通常，大多数使用 Bazel 的 C 和 C++ 项目都从 Github 或任何其他托管基于 git 仓库的 tarball 的公共提供商下载所有库。

这种方法与 openSUSE 打包相矛盾，openSUSE 打包使用共享库和 *-devel 包来构建 C 和 C++ 软件。

为了使 Bazel 与我们的方法更兼容，有一个名为 bazel-workspaces 的项目，其中包含 Bazel 的“虚拟”工作区，这些工作区指示动态链接库而不是捆绑。这是通过自定义 BUILD 文件实现的，例如：

cc_library( name = "gperftools", hdrs = glob(["thirdparty_build/include/gperftools/**/*.h"]), copts = [], linkopts = ["-ltcmalloc", "-lprofiler"], visibility = ["//visibility:public"], linkstatic = False, ) 

它告诉 Bazel：

• 在 /usr/include/gperftools 中查找头文件，递归地在所有可能的子目录中
• 链接 libtcmalloc.so 和 libprofiler.so

bazel-workspaces 提供了一个 RPM 包，用于将这些文件安装在 /usr/share/bazel-workspaces 中。

假设您想使用 Bazel 构建一个项目，该项目依赖于名为 com_github_gperftools_gperftools（一个常用名称）的 gperftools。要使用 gperftools-devel 包中的共享库，请使用 --override_repository 选项，例如：

bazel build \ --override_repository="com_github_gperftools_gperftools=/usr/share/bazel-workspaces" \ //... 

使用 OpenSSL 而不是 BoringSSL

上游 Envoy 使用 BoringSSL 作为认证功能的库。BoringSSL 是 Google 的 OpenSSL 分支。其 README 中提到：

尽管 BoringSSL 是一个开源项目，但它不打算像 OpenSSL 那样用于一般用途。我们不建议第三方依赖它。这样做可能会令人沮丧，因为不保证 API 或 ABI 的稳定性。

这就是我们不想打包 BoringSSL 的原因，我们将修补所有源代码以改用 OpenSSL。

我们通过 Maistra - OpenShift 服务网格 的以下项目来实现这一目标：

• bssl_wrapper – 一个将 BoringSSL 调用转换为 OpenSSL 调用的库
• OpenSSL-cbs – 一个为 OpenSSL 提供 Crypto ByteString (CBS) 功能的库——BoringSSL 的一个功能
• jwt-verify-lib-openssl、 envoy-openssl、 istio-proxy-openssl – 一组补丁和模块，它们使 jwt_verify_lib、Envoy 和 Istio 使用 OpenSSL 构建，并使用上述两个项目

在本地环境中使用 OpenSSL 构建

最好将上面提到的所有仓库都克隆到一个目录中（假设是 ~/repos）

git clone git@github.com:google/jwt_verify_lib.git git clone git@github.com:Maistra/jwt-verify-lib-openssl.git git clone git@github.com:envoyproxy/envoy.git git clone git@github.com:kubic-project/envoy-openssl.git git clone git@github.com:istio/proxy.git istio-proxy git clone git@github.com:Maistra/istio-proxy-openssl.git git clone git@github.com:cilium/proxy.git cilium-proxy 

克隆所有仓库后，目录树如下所示：

- repos/ |- jwt_verify_lib/ |- jwt-verify-lib-openssl/ |- envoy/ |- envoy-openssl/ |- istio-proxy/ |- istio-proxy-openssl/ |- cilium-proxy/ [...] 

然后每个 *-openssl 仓库都有一个 openssl.sh 文件。该脚本的语法是：

./openssl.sh [path-to-repository-to-patch] SSL 

因此，对于每个仓库，您需要执行：

cd jwt-verify-lib-openssl ./openssl.sh ../jwt_verify_lib SSL 

cd envoy-openssl ./openssl.sh ../envoy SSL 

cd istio-proxy-openssl ./openssl.sh ../istio-proxy SSL 

然后您可以构建每个仓库

cd jwt_verify_lib bazel build //... 

cd envoy bazel build \ --override_repository="com_github_google_jwt_verify=$HOME/repos/jwt_verify_lib" \ --copt="-DENVOY_SSL_VERSION=\"OpenSSL_1_1_1\"" \ //source/exe:envoy-static 

cd istio-proxy bazel build \ --override_repository="com_github_google_jwt_verify=$HOME/repos/jwt_verify_lib" \ --override_repository="envoy=$HOME/repos/envoy" \ --copt="-DENVOY_SSL_VERSION=\"OpenSSL_1_1_1\"" \ //... 

最后一个可能仍然无法构建，但这目前不是一个阻塞问题。