1.5. 使用 Operator 在 OpenShift 上 3scale API Management 的部署配置选项

流程

1. 编写用于定义您要注入的自定义环境的 Lua 代码。例如，以下 env1.lua 文件显示了 3scale 操作器为所有服务加载的自定义日志策略。

   local cjson = require('cjson')
   local PolicyChain = require('apicast.policy_chain')
   local policy_chain = context.policy_chain
   
   local logging_policy_config = cjson.decode([[
   {
     "enable_access_logs": false,
     "custom_logging": "\"{{request}}\" to service {{service.id}} and {{service.name}}"
   }
   ]])
   
   policy_chain:insert( PolicyChain.load_policy('logging', 'builtin', logging_policy_config), 1)
   
   return {
     policy_chain = policy_chain,
     port = { metrics = 9421 },
   }

2. 从定义自定义环境的 Lua 文件创建 secret。例如：

   $ oc create secret generic custom-env-1 --from-file=./env1.lua

   secret 可以包含多个自定义虚拟环境。为定义自定义环境的每个文件指定 -from-file 选项。Operator 会加载每个自定义环境。

3. 定义一个 APIManager 自定义资源(CR)来引用您刚才创建的 secret。以下示例显示了相对于引用定义自定义环境的 secret 的内容。

   apiVersion: apps.3scale.net/v1alpha1
   kind: APIManager
   metadata:
     name: apimanager-apicast-custom-environment
   spec:
     wildcardDomain: <desired-domain>
     apicast:
       productionSpec:
         customEnvironments:
           - secretRef:
               name: custom-env-1
       stagingSpec:
         customEnvironments:
           - secretRef:
               name: custom-env-1

   APIManager CR 可以引用定义自定义虚拟环境的多个 secret。Operator 会加载每个自定义环境。

4. 创建添加自定义环境的 APIManager CR。例如：

   $ oc apply -f apimanager.yaml

流程

1. 从定义一个自定义策略的文件创建 secret。例如：

   $ oc create secret generic my-first-custom-policy-secret \
    --from-file=./apicast-policy.json \
    --from-file=./init.lua \
    --from-file=./my-first-custom-policy.lua

   如果您有多个自定义策略，请为每个自定义策略创建一个 secret。secret 只能包含一个自定义策略。

2. 使用 3scale 操作器监控机密更改。添加 apimanager.apps.3scale.net/watched-by=apimanager 标签以开始 3scale operator secret 更改监控：

   $ oc label secret my-first-custom-policy-secret apimanager.apps.3scale.net/watched-by=apimanager

   注意

   默认情况下，3scale 操作器不会跟踪对 secret 的更改。使用标签时，3scale Operator 会在您对 secret 进行更改时自动更新 APIcast 部署。这在使用 secret 的暂存和生产环境中发生。3scale 操作器不会以任何方式获取 secret 的所有权。

3. 定义一个 APIManager CR，它引用包含自定义策略的每个 secret。您可以为 APIcast staging 和 APIcast production 指定相同的 secret。以下示例显示有关引用包含自定义策略的 secret 的内容。

   apiVersion: apps.3scale.net/v1alpha1
   kind: APIManager
   metadata:
     name: apimanager-apicast-custom-policy
   spec:
     apicast:
       stagingSpec:
         customPolicies:
           - name: my-first-custom-policy
             version: "0.1"
             secretRef:
               name: my-first-custom-policy-secret
           - name: my-second-custom-policy
             version: "0.1"
             secretRef:
               name: my-second-custom-policy-secret
       productionSpec:
         customPolicies:
           - name: my-first-custom-policy
             version: "0.1"
             secretRef:
               name: my-first-custom-policy-secret
           - name: my-second-custom-policy
             version: "0.1"
             secretRef:
               name: my-second-custom-policy-secret

   APIManager CR 可以引用定义不同自定义策略的多个 secret。Operator 加载每个自定义策略。

4. 创建 APIManager CR，以引用包含自定义策略的 secret。例如：

   $ oc apply -f apimanager.yaml

流程

1. 在 stringData.config 中包含您的 OpenTracing 配置详情的 secret。这是包含您的 OpenTracing 配置详细信息的属性的唯一有效值。任何其他规格都阻止 APIcast 收到您的 OpenTracing 配置详细信息。以下示例显示了有效的 secret 定义：

   apiVersion: v1
   kind: Secret
   metadata:
     name: myjaeger
   stringData:
     config: |-
         {
         "service_name": "apicast",
         "disabled": false,
         "sampler": {
           "type": "const",
           "param": 1
         },
         "reporter": {
           "queueSize": 100,
           "bufferFlushInterval": 10,
           "logSpans": false,
           "localAgentHostPort": "jaeger-all-in-one-inmemory-agent:6831"
         },
         "headers": {
           "jaegerDebugHeader": "debug-id",
           "jaegerBaggageHeader": "baggage",
           "TraceContextHeaderName": "uber-trace-id",
           "traceBaggageHeaderPrefix": "testctx-"
         },
         "baggage_restrictions": {
             "denyBaggageOnInitializationFailure": false,
             "hostPort": "127.0.0.1:5778",
             "refreshInterval": 60
         }
         }
   type: Opaque

2. 创建 secret.例如，如果您将以前的 secret 定义保存到 myjaeger.yaml 文件中，您将运行以下命令：

   $ oc create -f myjaeger.yaml

3. 定义一个 APIManager 自定义资源(CR)来指定 openTracing 属性。在 CR 定义中，将 openTracing.tracingConfigSecretRef.name 属性设置为包含您的 OpenTracing 配置详情的 secret 的名称。以下示例显示了相对于配置 OpenTracing 的内容：

   apiVersion: apps.3scale.net/v1alpha1
   kind: APIManager
   metadata:
     name: apimanager1
   spec:
     apicast:
       stagingSpec:
         ...
         openTracing:
           enabled: true
           tracingLibrary: jaeger
           tracingConfigSecretRef:
             name: myjaeger
       productionSpec:
         ...
           openTracing:
             enabled: true
             tracingLibrary: jaeger
             tracingConfigSecretRef:
               name: myjaeger

4. 创建配置 OpenTracing 的 APIManager CR。例如，如果您在 apimanager1.yaml 文件中保存 APIManager CR，您将运行以下命令：

   $ oc apply -f apimanager1.yaml

流程

1. 从有效证书创建 secret，例如：

   $ oc create secret tls mycertsecret --cert=server.crt --key=server.key

   配置会公开 APIManager 自定义资源(CR)中的 secret 引用。您可以创建 secret，然后引用 APIManager CR 中的 secret 名称，如下所示：

   • Production: APIManager CR 在 .spec.apicast.productionSpec.httpsCertificateSecretRef 字段中公开证书。

   • Staging: APIManager CR 在 .spec.apicast.stagingSpec.httpsCertificateSecretRef 字段中公开证书。

     另外，您还可以配置以下内容：

   • httpsPort 表示哪个端口 APIcast 应开始侦听 HTTPS 连接。如果这与 HTTP 端口 APIcast 有冲突，则仅将此端口用于 HTTPS。

   • httpsVerifyDepth 定义客户端证书链的最大长度。

     注意

     提供有效的证书和来自 APIManager CR 的引用。如果配置可以访问 httpsPort，但不能访问 httpsCertificateSecretRef，APIcast 使用嵌入的自签名证书。不建议这样做。

2. 点 Operators > Installed Operators。
3. 从 Installed Operators 列表中，点 3scale Operator。
4. 点 API Manager 选项卡。
5. 点 Create APIManager。

6. 在编辑器中添加以下 YAML 定义。

   1. 如果 为生产环境 启用，请配置以下 YAML 定义：

      spec:
        apicast:
          productionSpec:
            httpsPort: 8443
            httpsVerifyDepth: 1
            httpsCertificateSecretRef:
              name: mycertsecret

   2. 如果为 staging 启用，请配置以下 YAML 定义：

      spec:
        apicast:
          stagingSpec:
            httpsPort: 8443
            httpsVerifyDepth: 1
            httpsCertificateSecretRef:
              name: mycertsecret

7. 点 Create。

流程

1. 如果您还没有登录，请登录到 OpenShift：

   oc login

2. 使用 oc patch 命令，指定 system-smtp 是 secret 名称的 secret 类型，后跟 -p 选项，并在 JSON 中为以下变量写入新值：

   Expand

   表 1.4. system-smtp

   字段	描述	默认值
   address	这是要使用的远程邮件服务器的地址（主机名或 IP）。如果此值设为一个不是 "" 的值，系统将使用邮件服务器来发送与 API 管理解决方案中发生的事件相关的邮件。	""
   port	这是要使用的远程邮件服务器的端口。	""
   domain	如果邮件服务器需要 HELO 域，使用域。	""
   身份验证	如果邮件服务器需要身份验证时使用。设置身份验证类型： plain 以明文发送，login 中 Base64 编码的形式发送密码，或 cram_md5 根据 HMAC-MD5 算法组合一个质询/响应机制。	""
   username	如果邮件服务器需要身份验证且身份验证类型需要，则使用 username。	""
   password	如果邮件服务器需要身份验证且身份验证类型需要它，则使用 password。	""
   openssl.verify.mode	使用 TLS 时，您可以设置 OpenSSL 如何检查证书。如果您需要验证自签名和/或通配符证书，这非常有用。您可以使用 OpenSSL 验证常量的名称：none 或 peer。	""
   from_address	no-reply 邮件的 from 地址值。	""

   Show more

   例子

   $ oc patch secret system-smtp -p '{"stringData":{"address":"<your_address>"}}'
   $ oc patch secret system-smtp -p '{"stringData":{"username":"<your_username>"}}'
   $ oc patch secret system-smtp -p '{"stringData":{"password":"<your_password>"}}'

3. 设置 secret 变量后，重新部署 system-app 和 system-sidekiq pod:

   $ oc rollout latest dc/system-app
   $ oc rollout latest dc/system-sidekiq

4. 检查推出部署的状态，以确保它已完成：

   $ oc rollout status dc/system-app
   $ oc rollout status dc/system-sidekiq

验证

1. 输入以下命令检查部署：

   $ oc get dc/apicast-staging -o yaml

   $ oc get dc/apicast-production -o yaml

2. 验证包含环境变量：

   # apicast-staging
   - name: APICAST_SERVICE_CACHE_SIZE
      value: '10'

   # apicast-production
   - name: APICAST_SERVICE_CACHE_SIZE
      value: '20'