Language:
Format:

迁移 3scale

Red Hat 3scale API Management 2.8

升级 3scale API 管理安装。

Red Hat Customer Content Services

法律通告

摘要

本指南提供将 3scale API 管理安装升级到最新版本的信息。

前言

本指南帮助您迁移和升级 Red Hat 3scale API 管理。

要将 3scale 安装从 2.7 升级到 2.8，有两个指南，具体取决于安装类型：

3scale 基于模板的升级指南
3scale 基于 operator 的升级指南

在开发者门户网站中置备 API 的升级后步骤

成功升级 3scale 后，若要在开发者门户中配置 OpenAPI 规格 3.0 (OAS 3.0)，请参阅以下内容：使用 OAS 3.0 配置开发人员门户。

要从基于模板的部署迁移到基于 Operator 的部署，请按照第 3 章 3scale API 管理迁移指南：从模板到基于 Operator 的部署 中列出的步骤操作。

第 1 章 3scale 基于模板的升级指南：从 2.7 升级到 2.8

本节介绍在基于模板的部署中将 Red Hat 3scale API Management 从 2.7 升级到 2.8。

重要

为了了解所需的条件和程序，请在应用列出的步骤前阅读整个升级指南。升级过程会破坏服务的调配，直到过程完成为止。因为这个过程需要涉及到系统中断，请确保计划有一个维护窗口进行。

1.1. 准备升级

本章论述了在升级 3scale 前需要满足的条件。它还列出了您需要满足执行升级所需先决条件的任务和工具。

1.1.1. 升级条件

在进行升级前，您必须考虑以下点：

3scale 支持在 OpenShift 3.11 上通过模板从 2.7 升级到 2.8。
确保 OpenShift CLI 工具已在部署了 3scale 的同一项目中配置。

1.1.2. 执行升级的先决条件

这部分论述了在基于模板的安装中将 3scale 从 2.7 升级到 2.8 所需的任务和工具。

准备步骤

对您用于 3scale 的数据库执行备份。备份过程特定于每种数据库类型和设置。

工具

您需要这些工具来执行升级：

3scale 2.7 使用 OpenShift 3.11 项目中的模板进行部署。
Bash shell：要运行升级过程中详述的命令，请执行以下操作。
base64：对 secret 信息进行编码和解码。
jq：用于 JSON 转换。

1.2. 在基于模板的安装中将 2.7 升级到 2.8

按照本节中的步骤，在基于模板的安装中将 3scale 2.7 升级到 2.8。

要开始升级，请转至部署了 3scale 的项目。

$ oc project <3scale-project>

然后，按照以下顺序执行这些步骤：

第 1.2.1 节 “创建 3scale 项目的备份”
第 1.2.2 节 “将 smtp ConfigMap 迁移到 system-smtp secret”
第 1.2.3 节 “更新 system-app DeploymentConfig 的 pre-hook pod 命令”
第 1.2.4 节 “修补 system-app DeploymentConfig 的 pre-hook pod 环境”
第 1.2.5 节 “修补 system-app DeploymentConfig 容器的环境”
第 1.2.6 节 “修补 system-sidekiq DeploymentConfig 容器的环境”
第 1.2.7 节 “迁移特定于 S3 的配置”
第 1.2.8 节 “更新 3scale 版本号”
第 1.2.9 节 “升级 3scale 镜像”
第 1.2.10 节 “删除 smtp ConfigMap”

1.2.1. 创建 3scale 项目的备份

前一步

无。

当前步骤

此步骤列出了创建 3scale 项目的备份所需的操作。

根据与 3scale 一起使用的数据库，使用以下值之一设置 ${SYSTEM_DB}：
- 如果数据库是 MySQL，则为 SYSTEM_DB=system-mysql。
- 如果数据库是 PostgreSQL，则为 SYSTEM_DB=system-postgresql。

使用现有 DeploymentConfig 创建备份文件：

$ THREESCALE_DC_NAMES="apicast-production apicast-staging backend-cron backend-listener backend-redis backend-worker system-app system-memcache ${SYSTEM_DB} system-redis system-sidekiq system-sphinx zync zync-database zync-que"

for component in ${THREESCALE_DC_NAMES}; do oc get --export -o yaml dc ${component} > ${component}_dc.yml ; done

备份通过 export all 命令导出的项目中所有现有 OpenShift 资源：
```
$ oc get -o yaml --export all > threescale-project-elements.yaml
```

使用没有使用 export all 命令导出的额外元素创建备份文件：

$ for object in rolebindings serviceaccounts secrets imagestreamtags cm rolebindingrestrictions limitranges resourcequotas pvc templates cronjobs statefulsets hpa deployments replicasets poddisruptionbudget endpoints
do
  oc get -o yaml --export $object > $object.yaml
done

验证所有生成的文件是否都为空，并且所有这些文件都具有预期内容。

后续步骤

第 1.2.2 节 “将 smtp ConfigMap 迁移到 system-smtp secret”

1.2.2. 将 `smtp` ConfigMap 迁移到 `system-smtp` secret

前一步

第 1.2.1 节 “创建 3scale 项目的备份”

当前步骤

此步骤的目标是将 system 的 SMTP 配置从 ConfigMap 迁移到 Secret。此迁移涉及与邮件相关的方面，因为 SMTP 配置包含一些敏感信息。为保护此信息，secret 比 ConfigMap 更安全。

收集 app 标签的当前值：

$ DEPLOYED_APP_LABEL=$(oc get dc backend-listener -o json | jq .spec.template.metadata.labels.app -r)

您可以运行以下命令来验证 DEPLOYED_APP_LABEL 是否不为空：
```
$ echo  ${DEPLOYED_APP_LABEL}
```

收集 smtp ConfigMap 的当前内容：
```
$ CFGMAP_DATA_CONTENTS=$(oc get configmap smtp -o json | jq -r .data)
```
- 您可以运行以下命令来验证 CFGMAP_DATA_CONTENTS 是否不为空：
```
$ echo  ${CFGMAP_DATA_CONTENTS}
```
- 您可以运行以下命令确认 CFGMAP_DATA_CONTENTS 的值：
```
$ oc get configmap smtp -o json | jq -r .data
```

使用 smtp ConfigMap 的内容创建 system-smtp secret：

$ cat <<EOF | oc create -f -
{
  "apiVersion": "v1",
  "kind": "Secret",
  "metadata": {
    "creationTimestamp": null,
    "labels": {
      "app": "${DEPLOYED_APP_LABEL}",
      "threescale_component": "system",
      "threescale_component_element": "smtp"
    },
    "name": "system-smtp"
  },
  "stringData": ${CFGMAP_DATA_CONTENTS}
}
EOF

通过执行以下方法确认 system-smtp secret 已创建：
```
$ oc get secret system-smtp -o yaml
```
验证 system-smtp secret 和 smtp ConfigMap 中所有数据键和相关值都相同。system-smtp secret 中的数据值采用 base64 编码，因此必须对其进行解码才能查看实际值。例如，如果 secret 数据中的一个键名为 mykey，您可以复制与该键关联的值，并使用以下命令查看实际值：
```
$ oc get secret system-smtp -o json | jq -r .data.mykey | base64 -d
```
如果键关联的值是空字符串，则上一个命令的结果将没有输出。

后续步骤

第 1.2.3 节 “更新 system-app DeploymentConfig 的 pre-hook pod 命令”

1.2.3. 更新 `system-app` DeploymentConfig 的 `pre-hook pod` 命令

前一步

第 1.2.2 节 “将 smtp ConfigMap 迁移到 system-smtp secret”

当前步骤

若要从 3scale 获取最新的功能，此步骤解释了如何更新 system-app DeploymentConfig 中的 pre-hook pod 命令。

在 system-app DeploymentConfig 中，将 pre-hook pod 命令更新至此发行版本所需的新 pod 命令：

oc patch dc/system-app -p '{"spec":{"strategy":{"rollingParams":{"pre":{"execNewPod":{"command":["bash","-c","bundle exec rake boot openshift:deploy"]}}}}}}'

验证 pre-hook pod 命令是否已更改为新值：

oc get dc system-app -o json | jq .spec.strategy.rollingParams.pre.execNewPod.command

以上命令的结果应该是：

[
  "bash",
  "-c",
  "bundle exec rake boot openshift:deploy"
]

后续步骤

第 1.2.4 节 “修补 system-app DeploymentConfig 的 pre-hook pod 环境”

1.2.4. 修补 `system-app` DeploymentConfig 的 `pre-hook pod` 环境

前一步

第 1.2.3 节 “更新 system-app DeploymentConfig 的 pre-hook pod 命令”

当前步骤

此步骤将环境变量添加到 pre-hook pod 环境中的 system-app DeploymentConfig。此添加可确保与 SMTP 相关的环境变量指向新创建的 system-smtp secret。此添加保证了与修改 pre-hook pod 命令相关的变量会被正确配置。

对 system-app DeploymentConfig 中的 pre-hook pod 环境变量进行补丁：

oc get dc system-app -o json | jq 'del(.spec.strategy.rollingParams.pre.execNewPod.env[] | select(.name == "SMTP_ADDRESS" // .name == "SMTP_USER_NAME" // .name == "SMTP_PASSWORD" // .name == "SMTP_DOMAIN" // .name == "SMTP_PORT" // .name == "SMTP_AUTHENTICATION" // .name == "SMTP_OPENSSL_VERIFY_MODE")) | .spec.strategy.rollingParams.pre.execNewPod.env += [{"name":"SMTP_ADDRESS","valueFrom":{"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}},{"name":"MASTER_ACCESS_TOKEN","valueFrom":{"secretKeyRef":{"key":"MASTER_ACCESS_TOKEN","name":"system-seed"}}}]' | oc apply -f -

根据这些操作点验证 pre-hook pod 环境是否已修补：

检查 MASTER_ACCESS_TOKEN 是否已设置为 system-app pre-hook pod 中的 secret 引用：

oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name == "MASTER_ACCESS_TOKEN")) | length'

预期输出：1

您可以确认 MASTER_ACCESS_TOKEN 已正确设置指向 system-seed secret：

oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name == "MASTER_ACCESS_TOKEN"))'

预期输出：

[
  {
    "name": "MASTER_ACCESS_TOKEN",
    "valueFrom": {
          "secretKeyRef": {
                "key": "MASTER_ACCESS_TOKEN",
                "name": "system-seed"
          }
    }
  }
]

检查 system-app pre-hook pod 中所有 SMTP_* env vars 是否已设置为 secret 引用：
```
oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name | contains("SMTP")))'
```
- 以下输出列表中的每个环境变量都应该是 system-smtp secret 密钥的引用：
  - SMTP_ADDRESS
  - SMTP_USER_NAME
  - SMTP_PASSWORD
  - SMTP_DOMAIN
  - SMTP_PORT
  - SMTP_AUTHENTICATION
  - SMTP_OPENSSL_VERIFY_MODE

后续步骤

第 1.2.5 节 “修补 system-app DeploymentConfig 容器的环境”

1.2.5. 修补 `system-app` DeploymentConfig 容器的环境

前一步

第 1.2.4 节 “修补 system-app DeploymentConfig 的 pre-hook pod 环境”

当前步骤

此流程在 system-app 容器环境中添加和修改环境变量。它确保与 SMTP 相关的环境变量指向新创建的 system-smtp secret。

修补 system-app DeploymentConfig 中的容器环境变量：

oc patch dc/system-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-master","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]},{"name":"system-provider","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]},{"name":"system-developer","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]}]}}}}'

验证所有 SMTP_* env vars 是否已设置为此处列出的 system-app 容器的 secret 引用：

system-developer

oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-developer"))[].env | map(select(.name | contains("SMTP")))'

system-provider

oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-provider"))[].env | map(select(.name | contains("SMTP")))'

system-master
```
oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-master"))[].env | map(select(.name | contains("SMTP")))'
```
在这些容器中，以下输出列表中的环境变量应该是 system-smtp secret 密钥的引用：
- SMTP_ADDRESS
- SMTP_USER_NAME
- SMTP_PASSWORD
- SMTP_DOMAIN
- SMTP_PORT
- SMTP_AUTHENTICATION
- SMTP_OPENSSL_VERIFY_MODE

后续步骤

第 1.2.6 节 “修补 system-sidekiq DeploymentConfig 容器的环境”

1.2.6. 修补 `system-sidekiq` DeploymentConfig 容器的环境

前一步

第 1.2.5 节 “修补 system-app DeploymentConfig 容器的环境”

当前步骤

此流程在 system-sidekiq pod 环境中添加和修改环境变量。此处列出的步骤可确保与 SMTP 相关的环境变量指向新创建的 system-smtp secret。

修补 system-sidekiq DeploymentConfig 的环境变量：

oc patch dc/system-sidekiq -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-sidekiq","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]}]}}}}'

确认所有 SMTP_* 环境变量都已设置为 secret 引用：
```
oc get dc system-sidekiq -o json | jq '.spec.template.spec.containers | map(select(.name == "system-sidekiq"))[].env | map(select(.name | contains("SMTP")))'
```
以下输出列表中的每个环境变量都应该是 system-smtp secret 密钥的引用：
- SMTP_ADDRESS
- SMTP_USER_NAME
- SMTP_PASSWORD
- SMTP_DOMAIN
- SMTP_PORT
- SMTP_AUTHENTICATION
- SMTP_OPENSSL_VERIFY_MODE

后续步骤

如果您使用 amp-s3 模板，使用 Amazon Simple Storage Service (Amazon S3)部署 3scale 2.7，第 1.2.2 节 “将 smtp ConfigMap 迁移到 system-smtp secret”。
如果您还没有在 3scale 2.7 中安装 amp-s3 模板，第 1.2.8 节 “更新 3scale 版本号”

1.2.7. 迁移特定于 S3 的配置

注意

如果您在 3scale 2.7 中安装了 amp-s3 模板，请按照此步骤的说明操作。否则，请在下一步中继续升级：第 1.2.8 节 “更新 3scale 版本号”

前一步

第 1.2.6 节 “修补 system-sidekiq DeploymentConfig 容器的环境”

当前步骤

此步骤列出了将特定于 S3 的配置从 system-environment ConfigMap 迁移到 aws-auth secret 的任务。

将值添加到现有 aws-auth secret 中：

oc patch secret aws-auth --patch "{\"stringData\": $(oc get configmap system-environment -o json | jq '.data | {"AWS_BUCKET": .AWS_BUCKET, "AWS_REGION": .AWS_REGION } ')}"

确认密钥及其值已添加到 aws-auth secret 中。这些值是 base64 编码：
```
oc get secret aws-auth -o yaml
```

修补 system-app DeploymentConfig 中的 pre-hook pod 环境变量：

oc get dc system-app -o json | jq 'del(.spec.strategy.rollingParams.pre.execNewPod.env[] | select(.name == "AWS_BUCKET" // .name == "AWS_REGION")) | .spec.strategy.rollingParams.pre.execNewPod.env += [{"name":"AWS_BUCKET","valueFrom":{"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]' | oc apply -f -

检查所有 AWS_* 环境变量是否已设置为 system-app pre-hook pod 中的 secret 引用：

oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name | contains("AWS")))'

以下输出列表中的每个环境变量都应该是对 aws-auth secret 密钥的引用：
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- AWS_BUCKET
- AWS_REGION
- AWS_PROTOCOL
- AWS_HOSTNAME
- AWS_PATH_STYLE

修补 system-app DeploymentConfig 中的容器环境变量：

oc patch dc/system-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-master","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]},{"name":"system-provider","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]},{"name":"system-developer","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]}]}}}}'

验证所有 AWS_* 环境变量是否已设置为 system-app 的三个容器中的 secret 引用。

system-developer:

oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-developer"))[].env | map(select(.name | contains("AWS")))'

system-master ：

oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-master"))[].env | map(select(.name | contains("AWS")))'

system-provider
```
oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-provider"))[].env | map(select(.name | contains("AWS")))'
```
对于所有三个容器，以下输出列表中的每个环境变量都应该是 aws-auth secret 密钥的引用：
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- AWS_BUCKET
- AWS_REGION
- AWS_PROTOCOL
- AWS_HOSTNAME
- AWS_PATH_STYLE

修补 system-sidekiq DeploymentConfig 中的容器环境变量：

oc patch dc/system-sidekiq -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-sidekiq","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]}]}}}}'

验证所有 AWS_* 环境变量是否已设置为 secret 引用：
```
oc get dc system-sidekiq -o json | jq '.spec.template.spec.containers | map(select(.name == "system-sidekiq"))[].env | map(select(.name | contains("AWS")))'
```
以下输出列表中的每个环境变量都应该是对 aws-auth secret 密钥的引用：
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- AWS_BUCKET
- AWS_REGION
- AWS_PROTOCOL
- AWS_HOSTNAME
- AWS_PATH_STYLE

删除未使用的 system-environment ConfigMap 键：

oc patch configmap system-environment --patch '{"data": {"AWS_BUCKET": null, "AWS_REGION": null}}'

后续步骤

第 1.2.8 节 “更新 3scale 版本号”

1.2.8. 更新 3scale 版本号

前一步

如果您在 3scale 2.7 中安装了 amp-s3 模板，第 1.2.2 节 “将 smtp ConfigMap 迁移到 system-smtp secret”。
如果您还没有在 3scale 2.7 中安装 amp-s3 模板，第 1.2.6 节 “修补 system-sidekiq DeploymentConfig 容器的环境”

当前步骤

此步骤在 system-environment ConfigMap 中将 3scale 发行版本号从 2.7 更新至 2.8。AMP_RELEASE 是某些 DeploymentConfig 容器环境中引用的 ConfigMap 条目。

要修补 AMP_RELEASE，请运行以下命令：

oc patch cm system-environment --patch '{"data": {"AMP_RELEASE": "2.8"}}'

验证 system-environment ConfigMap 中的 AMP_RELEASE 键是否具有 2.8 值：
```
oc get cm system-environment -o json | jq .data.AMP_RELEASE
```

后续步骤

第 1.2.9 节 “升级 3scale 镜像”

1.2.9. 升级 3scale 镜像

前一步

第 1.2.8 节 “更新 3scale 版本号”

当前步骤

此步骤更新升级过程所需的 3scale 镜像。

对 amp-system 镜像流进行补丁：

要修补 amp-system 镜像流，您需要考虑用于 3scale 部署的数据库。

如果 3scale 使用 Oracle 数据库部署，请执行以下步骤以使用 Oracle 数据库构建系统镜像：1、2、4、8 和 9。

如果数据库与 Oracle DB 不同，请使用以下命令：

oc patch imagestream/amp-system --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP system 2.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/system-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-system --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP system (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

这会触发 system-app、system-sphinx 和 system-sidekiq DeploymentConfig 的重新部署。等待它们重新部署、对应的新容器集就绪，并且旧容器集终止。

对 amp-apicast 镜像流进行补丁：

oc patch imagestream/amp-apicast --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP APIcast 2.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-apicast --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP APIcast (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

这会触发 apicast-production 和 apicast-staging DeploymentConfig 的重新部署。等待它们重新部署、对应的新容器集就绪，并且旧容器集终止。

对 amp-backend 镜像流进行补丁：

oc patch imagestream/amp-backend --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Backend 2.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/backend-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-backend --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Backend (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

这会触发 backend-listener、backend-worker 和 backend-cron DeploymentConfig 的重新部署。等待它们重新部署、对应的新容器集就绪，并且旧容器集终止。

对 amp-zync 镜像流进行补丁：

oc patch imagestream/amp-zync --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Zync 2.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/zync-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-zync --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Zync (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

这会触发 zync 和 zync-que DeploymentConfig 的重新部署。等待它们重新部署、对应的新容器集就绪，并且旧容器集终止。

对 system-memcached ImageStream 进行补丁：

oc patch imagestream/system-memcached --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.8 Memcached"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/memcached-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/system-memcached --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System Memcached (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

这会触发 system-memcache DeploymentConfig 的重新部署。等待它重新部署、对应的新容器集就绪，并且旧容器集终止。

对 zync-database-postgresql 镜像流进行补丁：

oc patch imagestream/zync-database-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Zync 2.8 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/zync-database-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Zync PostgreSQL (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

此 patch 命令更新 zync-database-postgresql 镜像流，使其包含 2.8 标签。您可以通过执行以下内容来验证 2.8 标签是否已创建：
```
oc get is/zync-database-postgresql
```
然后，检查 tags 列是否显示 2.8 标签。
如果镜像有新的更新，此补丁还可能触发 zync-database DeploymentConfig 的重新部署。如果发生这种情况，请等待新容器集重新部署并就绪，并且旧容器集终止。

如果 3scale 2.7 安装中存在一个或多个 DeploymentConfig，请点适用 DeploymentConfig 的链接来获取如何继续的更多信息：

验证 DeploymentConfig 的所有镜像 URL 包含新的镜像 registry URL，并在各个 URL 地址末尾添加一个哈希：

$ THREESCALE_DC_NAMES="apicast-production apicast-staging backend-cron backend-listener backend-redis backend-worker system-app system-memcache system-mysql system-redis system-sidekiq system-sphinx zync zync-database zync-que"

for component in ${THREESCALE_DC_NAMES}; do echo -n "${component} image: " && oc get dc $component -o json | jq .spec.template.spec.containers[0].image ; done

后续步骤

第 1.2.10 节 “删除 smtp ConfigMap”

1.2.9.1. 现有 DeploymentConfig 的额外步骤

1.2.9.1.1. `backend-redis` DeploymentConfig

如果当前 3scale 安装中存在 backend-redis DeploymentConfig，请修补 backend-redis 镜像流：

oc patch imagestream/backend-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Backend 2.8 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/backend-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Backend Redis (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

此补丁更新了 backend-redis 镜像流，使其包含 2.8 标签。使用以下命令，如果 tags 列显示了 2.8，您可以确认标签已创建：

oc get is/backend-redis

如果镜像上有新的更新，此补丁还可能触发 backend-redis DeploymentConfig 的重新部署。如果发生这种情况，请等待新容器集重新部署并就绪，并且旧容器集终止。

继续升级 3scale 镜像。

1.2.9.1.2. `system-redis` DeploymentConfig

如果当前 3scale 安装中存在 system-redis DeploymentConfig，请修补 system-redis 镜像流：

oc patch imagestream/system-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.8 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/system-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System Redis (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

此补丁更新了 system-redis 镜像流，使其包含 2.8 标签。使用以下命令，如果 tags 列显示了 2.8，您可以确认标签已创建：

oc get is/system-redis

如果镜像有新的更新，此补丁还可能触发 system-redis DeploymentConfig 的重新部署。如果发生这种情况，请等待新容器集重新部署并就绪，并且旧容器集终止。

继续升级 3scale 镜像。

1.2.9.1.3. `system-mysql` DeploymentConfig

如果当前 3scale 安装中存在 system-mysql DeploymentConfig，请修补 system-mysql 镜像流：

oc patch imagestream/system-mysql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.8 MySQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/mysql-57-rhel7:5.7"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/system-mysql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System MySQL (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

此补丁更新了 system-mysql 镜像流，使其包含 2.8 标签。使用以下命令，如果 tags 列显示了 2.8，您可以确认标签已创建：

oc get is/system-mysql

如果镜像上有新的更新，此补丁还可能触发 system-mysql DeploymentConfig 的重新部署。如果发生这种情况，请等待新容器集重新部署并就绪，并且旧容器集终止。

继续升级 3scale 镜像。

1.2.9.1.4. `system-postgresql` DeploymentConfig

如果当前 3scale 安装中存在 system-postgresql DeploymentConfig，请修补 system-postgresql 镜像流：

oc patch imagestream/system-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.8 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7
"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/system-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System PostgreSQL (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

此补丁更新了 system-postgresql 镜像流，使其包含 2.8 标签。使用以下命令，如果 tags 列显示了 2.8，您可以确认标签已创建：

oc get is/system-postgresql

如果镜像有新的更新，此补丁还可能触发 system-postgresql DeploymentConfig 的重新部署。如果发生这种情况，请等待新容器集重新部署并就绪，并且旧容器集终止。

继续升级 3scale 镜像。

1.2.10. 删除 `smtp` ConfigMap

前一步

第 1.2.9 节 “升级 3scale 镜像”

当前步骤

此步骤会删除 smtp ConfigMap，因为此 ConfigMap 已迁移到 system-smtp secret。

要删除 smtp ConfigMap，请运行以下命令：

$ oc delete cm smtp

如果命令未返回错误，则代表它可以正常工作。

后续步骤

无。执行所有列出的步骤后，基于模板的部署中的 3scale 从 2.7 升级到 2.8 现已完成。

第 2 章 3scale 基于 operator 的升级指南：从 2.7 升级到 2.8

本节包含在基于 operator 的部署中将 Red Hat 3scale API Management 从版本 2.7 升级到 2.8 的信息。

重要

先决条件

3scale 2.7 之前通过 3scale operator 部署。
具有管理员访问权限的 OpenShift 容器平台(OCP)4.x 集群。

2.1. 将 3scale 2.7 升级到 2.8

要在基于 operator 的部署中将 3scale 从 2.7 升级到 2.8，请使用以下步骤。

流程

使用具有管理员特权的帐户登录 OCP 控制台。
选择部署了 3scale-operator 的项目。
点 Operators > Installed Operators。
选择 3scale operator Subscription > Channel。
选择 threescale-2.8 并保存更改，以编辑订阅的频道。
- 这将开始升级过程。
- 等待升级过程完成 APIManager。
查询项目的 pod 状态：
```
oc get pods
```
- 等待所有新版本都正在运行并就绪且无错误。
- 它们可能会在升级过程中出现临时错误。
  注意
  时间可能大约为 5 到 10 分钟。务必持续检查容器集的状态，直到它们都正在运行、就绪且无错误。
通过登录 3scale 管理门户并检查是否按预期工作，确认升级过程是否成功。
运行以下命令，检查 APIManager 对象的状态并获取 YAML 内容：
```
oc get apimanager <myapimanager> -o yaml
```
1. 带有值的新注解应如下所示：
```
apps.3scale.net/apimanager-threescale-version: "2.8"
apps.3scale.net/threescale-operator-version: "0.5.0"
```
  执行了所有列出的步骤后，在基于 operator 的部署中，3scale 从 2.7 升级到 2.8。

第 3 章 3scale API 管理迁移指南：从模板到基于 Operator 的部署

本节介绍使用 Red Hat OpenShift 3.11 将 Red Hat 3scale API 管理从基于模板的部署迁移到使用 Red Hat OpenShift 4.x 基于 Operator 的部署。

警告

为了了解所需的条件和程序，请在应用列出的步骤前阅读整个迁移指南。迁移过程会破坏服务的调配，直到过程完成为止。因为这个过程需要涉及到系统中断，请确保计划有一个维护窗口进行。

3.1. 准备迁移

在将 3scale 安装从模板迁移到基于 Operator 的部署之前，请通过咨询以下指南确认您的部署受支持：

3.2. 将 3scale 模板迁移到基于 operator 的部署

先决条件

在这两个环境中部署的 Red Hat 3scale API Management 2.8。
每个 OpenShift 集群的域，另一个用于 3scale 的 WILDCARD_DOMAIN。示例：
- Red Hat OpenShift 3.11 (OCP3): ocp3.example.com
- Red Hat OpenShift 4.x (OCP4): ocp4.example.com
- 3scale: 3scale.example.com

流程

迁移前的基本设置是将 3scale 指向 OCP3 域： 3scale.example.com → ocp3.example.com

要将 3scale 从使用 Red Hat OpenShift 3.11 的基于模板的部署迁移到使用 Red Hat OpenShift 4.1 的基于 operator 的部署，按照以下步骤进行：

从基于模板的部署创建一个 3scale 备份。
使用 operator 部署 3scale。
在基于 Operator 的部署中恢复备份。
将 3scale WILDCARD_DOMAIN（在本例中为 3scale.example.com ）指向 ocp4.example.com。

执行所有列出的步骤后，3scale 从模板迁移至基于 Operator 的部署现已完成。

法律通告

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Select Your Language

迁移 3scale

升级 3scale API 管理安装。

前言

第 1 章 3scale 基于模板的升级指南：从 2.7 升级到 2.8

1.1. 准备升级

1.1.1. 升级条件

1.1.2. 执行升级的先决条件

1.2. 在基于模板的安装中将 2.7 升级到 2.8

1.2.1. 创建 3scale 项目的备份

1.2.2. 将 `smtp` ConfigMap 迁移到 `system-smtp` secret

1.2.3. 更新 `system-app` DeploymentConfig 的 `pre-hook pod` 命令

1.2.4. 修补 `system-app` DeploymentConfig 的 `pre-hook pod` 环境

1.2.5. 修补 `system-app` DeploymentConfig 容器的环境

1.2.6. 修补 `system-sidekiq` DeploymentConfig 容器的环境

1.2.7. 迁移特定于 S3 的配置

1.2.8. 更新 3scale 版本号

1.2.9. 升级 3scale 镜像

1.2.9.1. 现有 DeploymentConfig 的额外步骤

1.2.9.1.1. `backend-redis` DeploymentConfig

1.2.9.1.2. `system-redis` DeploymentConfig

1.2.9.1.3. `system-mysql` DeploymentConfig

1.2.9.1.4. `system-postgresql` DeploymentConfig

1.2.10. 删除 `smtp` ConfigMap

第 2 章 3scale 基于 operator 的升级指南：从 2.7 升级到 2.8

2.1. 将 3scale 2.7 升级到 2.8

第 3 章 3scale API 管理迁移指南：从模板到基于 Operator 的部署

3.1. 准备迁移

3.2. 将 3scale 模板迁移到基于 operator 的部署

法律通告

Quick Links

Help

Site Info

Related Sites

About

Red Hat legal and privacy links

Red Hat legal and privacy links

Language and Page Formatting Options

迁移 3scale

升级 3scale API 管理安装。

前言

第 1 章 3scale 基于模板的升级指南：从 2.7 升级到 2.8

1.1. 准备升级

1.1.1. 升级条件

1.1.2. 执行升级的先决条件

1.2. 在基于模板的安装中将 2.7 升级到 2.8

1.2.1. 创建 3scale 项目的备份

1.2.2. 将 smtp ConfigMap 迁移到 system-smtp secret

1.2.3. 更新 system-app DeploymentConfig 的 pre-hook pod 命令

1.2.4. 修补 system-app DeploymentConfig 的 pre-hook pod 环境

1.2.5. 修补 system-app DeploymentConfig 容器的环境

1.2.6. 修补 system-sidekiq DeploymentConfig 容器的环境

1.2.7. 迁移特定于 S3 的配置

1.2.8. 更新 3scale 版本号

1.2.9. 升级 3scale 镜像

1.2.9.1. 现有 DeploymentConfig 的额外步骤

1.2.9.1.1. backend-redis DeploymentConfig

1.2.9.1.2. system-redis DeploymentConfig

1.2.9.1.3. system-mysql DeploymentConfig

1.2.9.1.4. system-postgresql DeploymentConfig

1.2.10. 删除 smtp ConfigMap

第 2 章 3scale 基于 operator 的升级指南：从 2.7 升级到 2.8

2.1. 将 3scale 2.7 升级到 2.8

第 3 章 3scale API 管理迁移指南：从模板到基于 Operator 的部署

3.1. 准备迁移

3.2. 将 3scale 模板迁移到基于 operator 的部署

法律通告

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links

1.2.2. 将 `smtp` ConfigMap 迁移到 `system-smtp` secret

1.2.3. 更新 `system-app` DeploymentConfig 的 `pre-hook pod` 命令

1.2.4. 修补 `system-app` DeploymentConfig 的 `pre-hook pod` 环境

1.2.5. 修补 `system-app` DeploymentConfig 容器的环境

1.2.6. 修补 `system-sidekiq` DeploymentConfig 容器的环境

1.2.9.1.1. `backend-redis` DeploymentConfig

1.2.9.1.2. `system-redis` DeploymentConfig

1.2.9.1.3. `system-mysql` DeploymentConfig

1.2.9.1.4. `system-postgresql` DeploymentConfig

1.2.10. 删除 `smtp` ConfigMap