Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

迁移 3scale

Red Hat 3scale API Management 2.6

升级 3scale API 管理安装。

Red Hat Customer Content Services

摘要

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

前言
复制链接

本指南将帮助您升级 3scale API 管理。

本节包含在基于模板部署中将 Red Hat 3scale API Management 从 2.5 升级到 2.6 的信息。

警告

此过程会导致服务中断，并临时停止 Zync 处理作业，直到升级完成为止。确保有一个维护窗口。

第 1 章 开始前
复制链接

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

支持的配置

  • 在 OpenShift 3.11 中，3scale 仅支持使用模板从 2.5 升级到 2.6。

以前的 3scale 版本

  • 假设 3scale 2.5 是使用 amp.yml 标准场景模板部署的，请下载新的 3scale 2.6 amp.yml 模板，然后进行部署以创建新的 OpenShift 元素。

  • 对于早期版本的 2.4 的多版本升级，请确认是否存在 system-environment ConfigMap: 

    $ oc get configmap system-environment
    Copy to Clipboard Toggle word wrap
    • 如果您收到 NotFound 错误消息，请参阅 Creating ConfigMaps 下的 2.4 Upgrade Guide。

工具

  • 对数据库进行备份。备份过程特定于每种数据库类型和设置。
  • 确保 OpenShift CLI 工具已在部署了 3scale 的同一项目中配置。
  • 在 bash shell 中运行以下命令。

  • 对于这个升级，请执行下列步骤下载并获取补丁文件：

    1. 点 templates-migration-2.5-to-2.6。
    2. 下载并解压缩文件。

您将在文档中看到一些与您下载的压缩文件内容相关的文件引用。例如，$(cat db-imagestream-patches/backend-redis-json.patch)。

第 2 章 将 3scale 2.5 升级到 2.6
复制链接

先决条件

  • 在项目中部署的 Red Hat 3scale API Management 2.5。

  • 工具先决条件：

    • base64
    • jq

步骤

要将 3scale API 管理 2.5 升级到 2.6，请转至 3scale 部署的项目。 

$ oc project <3scale-project>
Copy to Clipboard Toggle word wrap

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

  1. 创建 3scale 项目的备份
  2. 配置对经过身份验证的 registry 的支持
  3. 创建 OpenShift 资源
  4. 为 Redis Enterprise 和 Redis Sentinel 配置系统 DeploymentConfig
  5. 修复 Redis Sentinel 环境变量
  6. 修复 Zync 环境变量
  7. 将 DeploymentConfig 数据库迁移到 ImageStreams
  8. 升级 3scale 镜像
  9. 从 WildcardRouter 迁移到 Zync 路由管理

2.1. 为 3scale 项目创建备份目录
复制链接

使用以下步骤为 3scale 项目创建备份目录。请注意，{BACKUP_DIR} 是 3scale 备份机器上的位置。

步骤

  1. 创建备份目录： 

    mkdir ${BACKUP_DIR}
    Copy to Clipboard Toggle word wrap

  2. 为您的备份创建目录和子目录： 

    mkdir ${BACKUP_DIR}/system-database ${BACKUP_DIR}/zync-database ${BACKUP_DIR}/system-redis ${BACKUP_DIR}/backend-redis ${BACKUP_DIR}/system-app ${BACKUP_DIR}/openshift

mkdir ${BACKUP_DIR}/openshift/configmaps/ ${BACKUP_DIR}/openshift/deploymentConfigs ${BACKUP_DIR}/openshift/imageStreams ${BACKUP_DIR}/openshift/other/ ${BACKUP_DIR}/openshift/routes/ ${BACKUP_DIR}/openshift/secrets/ ${BACKUP_DIR}/openshift/services/
    Copy to Clipboard Toggle word wrap

2.1.1. 备份 system-database (MySQL)
复制链接

转储 system-mysql 数据库，并将转储存储在 ${BACKUP_DIR}/system-database/system-mysql-backup.gz 中： 

oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'export MYSQL_PWD=${MYSQL_ROOT_PASSWORD}; mysqldump --single-transaction -hsystem-mysql -uroot system' | gzip > ${BACKUP_DIR}/system-database/system-mysql-backup.gz
Copy to Clipboard Toggle word wrap

2.1.2. backup zync-database
复制链接

转储 zync-database PostrgreSQL 数据库，并将转储存储在 ${BACKUP_DIR}/zync-database/zync-database-backup.gz 中： 

oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r) bash -c 'pg_dumpall -c --if-exists' | gzip > ${BACKUP_DIR}/zync-database/zync-database-backup.gz
Copy to Clipboard Toggle word wrap

2.1.3. 备份 system-redis
复制链接

在 ${BACKUP_DIR}/ system-redis /system-redis-dump.rdb中提取 system-redis 转储 

oc cp $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb ${BACKUP_DIR}/system-redis/system-redis-dump.rdb
Copy to Clipboard Toggle word wrap

2.1.4. 备份 backend-redis
复制链接

在 ${BACKUP_DIR}/ backend-redis /backend-redis-dump.rdb中提取 backend-redis 转储 

oc cp $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb ${BACKUP_DIR}/backend-redis/backend-redis-dump.rdb
Copy to Clipboard Toggle word wrap

2.1.5. 备份 system-app 持久性数据
复制链接

在 ${BACKUP_DIR}/ system-app / 中复制 system-app 持久性数据： 

oc rsync $(oc get pods -l 'deploymentConfig=system-app' -o json | jq '.items[0].metadata.name' -r):/opt/system/public/system ${BACKUP_DIR}/system-app/
Copy to Clipboard Toggle word wrap

2.1.6. 备份 DeploymentConfig
复制链接

for object in `oc get dc | awk '{print $1}' | grep -v NAME`; do oc get -o yaml --export dc ${object} > ${BACKUP_DIR}/openshift/deploymentConfigs/${object}_dc.yaml; done
Copy to Clipboard Toggle word wrap

2.1.7. Backup ImageStreams
复制链接

for object in `oc get is | awk '{print $1}' | grep -v NAME`; do oc get -o yaml --export is ${object} > ${BACKUP_DIR}/openshift/imageStreams/${object}_is.yaml; done
Copy to Clipboard Toggle word wrap

2.1.8. 备份 secret
复制链接

备份令牌和 secret 默认构建器和部署程序以外的所有内容： 

for object in `oc get secret | awk '{print $1}' | grep -v NAME | grep -v default | grep -v builder | grep -v deployer`; do oc get -o yaml --export secret ${object} > ${BACKUP_DIR}/openshift/secrets/${object}_secret.yaml; done
Copy to Clipboard Toggle word wrap

2.1.9. 备份服务
复制链接

for object in `oc get svc | awk '{print $1}' | grep -v NAME`; do oc get -o yaml --export svc ${object} > ${BACKUP_DIR}/openshift/services/${object}_svc.yaml; done
Copy to Clipboard Toggle word wrap

2.1.10. 备份路由
复制链接

for object in `oc get routes | awk '{print $1}' | grep -v NAME`; do oc get -o yaml --export route ${object} > ${BACKUP_DIR}/openshift/routes/${object}_route.yaml; done
Copy to Clipboard Toggle word wrap

2.1.11. 备份 ConfigMap
复制链接

for object in `oc get cm | awk '{print $1}' | grep -v NAME`; do oc get -o yaml --export cm ${object} > ${BACKUP_DIR}/openshift/configmaps/${object}_cm.yaml; done
Copy to Clipboard Toggle word wrap

2.1.12. 备份其他资源
复制链接

进行第二个备份，以处理没有备份对象的其他自定义资源 

oc get -o yaml --export all > ${BACKUP_DIR}/openshift/other/threescale-project-elements.yaml

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 > ${BACKUP_DIR}/openshift/other/$object.yaml; done
Copy to Clipboard Toggle word wrap

2.2. 配置对经过身份验证的 registry 的支持
复制链接

作为 3scale 2.6 发行版本的一部分，容器镜像已从 registry.access.redhat.com 迁移到 registry.redhat.io 中的经过身份验证的 registry。按照以下步骤准备现有的 3scale 基础架构，以支持新的经过身份验证的 registry：

  1. 在新的 Red Hat 身份验证 registry 中创建凭证，位于 registry.redhat.io 中。

    • 创建名为 Registry Service Account 的 Registry Token。此 registry 令牌应该在 3scale 平台中用于进行 registry.redhat.io 进行身份验证。
    • 有关如何创建凭证的详情，请参阅 Red Hat Container Registry Authentication。

  2. 当一个 Registry Service Account 可用时，在部署 3scale 基础架构的 OpenShift 项目中创建一个新 secret：

    1. 进入到 Red Hat Service Accounts 面板来获取 OpenShift secret 定义。
    2. 选择用于 3scale 基础架构的 Registry Service Account。
    3. 选择 OpenShift Secret 选项卡，再点下载 secret 链接。

  3. 从 Red Hat Service Accounts 面板下载 OpenShift secret 后，修改 YAML 文件的 metadata 部分中的 name 字段，将现有名称替换为 threescale-registry-auth 名称。

    secret 类似于以下内容： 

    apiVersion: v1
kind: Secret
metadata:
  name: threescale-registry-auth
data:
  .dockerconfigjson: a-base64-encoded-string-containing-auth-credentials
type: kubernetes.io/dockerconfigjson
    Copy to Clipboard Toggle word wrap

  4. 保存更改，并在当前部署的 3scale 2.5 的 OpenShift 项目中创建 secret： 

    $ oc create -f the-secret-name.yml
    Copy to Clipboard Toggle word wrap

  5. 创建 secret 后，您可以检查其是否存在。以下命令返回一个包含内容的 secret： 

    $ oc get secret threescale-registry-auth
    Copy to Clipboard Toggle word wrap

  6. 创建使用 3scale -registry-auth secret 的 amp 服务帐户。要做到这一点，使用以下内容创建文件 amp-sa.yml ： 

    apiVersion: v1
kind: ServiceAccount
imagePullSecrets:
- name: threescale-registry-auth
metadata:
  name: amp
    Copy to Clipboard Toggle word wrap

  7. 部署 amp 服务帐户： 

    $ oc create -f amp-sa.yml
    Copy to Clipboard Toggle word wrap

  8. 确保已正确创建了 amp 服务帐户。以下命令会返回创建的服务帐户，其内容为 3scale -registry-auth，作为 imagePullSecrets 部分中的一个元素之一： 

    $ oc get sa amp -o yaml
    Copy to Clipboard Toggle word wrap

  9. 在应用到现有 3scale 项目的默认服务帐户后，验证权限是否复制到新的 amp 服务帐户。

    • 如果在服务账户身份验证模式下配置了服务发现，请按照 在没有 OAuth 服务器的情况下配置 中的说明，为 system:serviceaccount:<3scale-project>:default 用户授予 cluster-role view 权限，相同的权限现在需要应用到 system:serviceaccount:<3scale-project>:amp: 

      $ oc adm policy add-cluster-role-to-user view system:serviceaccount:<3scale-project>:amp
      Copy to Clipboard Toggle word wrap

  10. 更新所有现有 DeploymentConfig 以使用新的 amp 服务帐户： 

    $ THREESCALE_DC_NAMES="apicast-production apicast-staging apicast-wildcard-router backend-cron backend-listener backend-redis backend-worker system-app system-memcache system-mysql system-redis system-sidekiq system-sphinx zync zync-database"
for component in ${THREESCALE_DC_NAMES}; do oc patch dc $component --patch '{"spec":{"template": {"spec": {"serviceAccountName": "amp"}}}}' ; done
    Copy to Clipboard Toggle word wrap

    命令的输出包含这些行： 

    deploymentconfig.apps.openshift.io/apicast-production patched
deploymentconfig.apps.openshift.io/apicast-staging patched
deploymentconfig.apps.openshift.io/apicast-wildcard-router patched
deploymentconfig.apps.openshift.io/backend-cron patched
deploymentconfig.apps.openshift.io/backend-listener patched
deploymentconfig.apps.openshift.io/backend-redis patched
deploymentconfig.apps.openshift.io/backend-worker patched
deploymentconfig.apps.openshift.io/system-app patched
deploymentconfig.apps.openshift.io/system-memcache patched
deploymentconfig.apps.openshift.io/system-mysql patched
deploymentconfig.apps.openshift.io/system-redis patched
deploymentconfig.apps.openshift.io/system-sidekiq patched
deploymentconfig.apps.openshift.io/system-sphinx patched
deploymentconfig.apps.openshift.io/zync patched
deploymentconfig.apps.openshift.io/zync-database patched
    Copy to Clipboard Toggle word wrap

    上一命令还会重新部署所有 3scale 现有 DeploymentConfig，从而触发它们的重启。

  11. 当 DeploymentConfig 被重启时，您可能会观察其状态中的更改。等待所有 DeploymentConfig 都为 Ready。

    • 您可以通过输入以下命令来检查 DeploymentConfig 的状态，并验证每个 DeploymentConfig 的状态是否为 Desired 和 Current 列的值相同，并不是零： 

      $ oc get dc
      Copy to Clipboard Toggle word wrap

  12. 另外，验证所有 pod 都处于 Running 状态，并且所有 pod 都是 Ready。 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

  13. 使用以下命令检查所有 DeploymentConfig 是否设置了 amp 服务帐户： 

    $ for component in ${THREESCALE_DC_NAMES}; do oc get dc $component -o yaml | grep -i serviceAccountName; done
    Copy to Clipboard Toggle word wrap

  14. 由于上一命令，可以看到在以前设置 THREESCALE_DC_NAMES 环境变量中定义的元素数多次重复执行以下行： 

    serviceAccountName: amp
    Copy to Clipboard Toggle word wrap
  15. 此时，DeploymentConfigurations 已准备好使用红帽经过身份验证的 registry 镜像。

2.3. 创建 OpenShift 资源
复制链接

本节提供了创建这些新元素所需的步骤。作为 3scale 2.6 发行版本的一部分，添加了以下 OpenShift 元素：

  • 数据库的新 ImageStreams：

    • backend-redis
    • system-redis
    • system-memcached
    • system-mysql
    • zync-database-postgresql

  • 新的 zync-que 组件，包含以下 OpenShift 对象：

    • zync-que DeploymentConfig
    • zync-que-sa ServiceAccount
    • zync-que 角色
    • zync-que-rolebinding RoleBinding

要创建新 OpenShift 元素，请按照以下步骤执行：

  1. 创建以下环境变量，其中包含部署 3scale 2.5 时的 WildcardDomain 设置： 

    $ THREESCALE_WILDCARD_DOMAIN=$(oc get configmap system-environment  -o json | jq .data.THREESCALE_SUPERDOMAIN -r)
    Copy to Clipboard Toggle word wrap

  2. 验证 THREESCALE_WILDCARD_DOMAIN 环境变量不为空，并且它的值与部署 3scale 2.5 时设置的 Wildcard 域相同。 

    $ echo ${THREESCALE_WILDCARD_DOMAIN}
    Copy to Clipboard Toggle word wrap

  3. 创建包含 ImageStreams 中设置的 ImportPolicy ImageStream 值的以下环境变量： 

    $ IMPORT_POLICY_VAL=$(oc get imagestream amp-system -o json | jq -r ".spec.tags[0].importPolicy.insecure")
if [ "$IMPORT_POLICY_VAL" == "null" ]; then
  IMPORT_POLICY_VAL="false"
fi
    Copy to Clipboard Toggle word wrap

  4. 验证 IMPORT_POLICY_VAL 环境变量是否为 true 或 false ： 

    $ echo ${IMPORT_POLICY_VAL}
    Copy to Clipboard Toggle word wrap

  5. 创建以下环境变量，它将在 3scale pod 中包含 app Kubernetes 标签的当前值。例如，从 backend-listener pod 中获取它： 

    $ DEPLOYED_APP_LABEL=$(oc get dc backend-listener -o json | jq .spec.template.metadata.labels.app -r)
    Copy to Clipboard Toggle word wrap

  6. 验证 DEPLOYED_APP_LABEL 环境变量不为空或为 null： 

    $ echo ${DEPLOYED_APP_LABEL}
    Copy to Clipboard Toggle word wrap

  7. 使用 3scale 2.6 amp.yml 标准场景模板为 2.6 版本部署新的 OpenShift 对象： 

    $ oc new-app -f amp.yml --param WILDCARD_DOMAIN=${THREESCALE_WILDCARD_DOMAIN} --param IMAGESTREAM_TAG_IMPORT_INSECURE=${IMPORT_POLICY_VAL} --param APP_LABEL=${DEPLOYED_APP_LABEL}
    Copy to Clipboard Toggle word wrap

    您会看到几个错误。这些是正常的，因为 3scale 2.5 中已存在一些元素。不是错误的唯一可见行为： 

    imagestream.image.openshift.io "zync-database-postgresql" created
imagestream.image.openshift.io "backend-redis" created
imagestream.image.openshift.io "system-redis" created
imagestream.image.openshift.io "system-memcached" created
imagestream.image.openshift.io "system-mysql" created
role.rbac.authorization.k8s.io "zync-que-role" created
serviceaccount "zync-que-sa" created
rolebinding.rbac.authorization.k8s.io "zync-que-rolebinding" created
deploymentconfig.apps.openshift.io "zync-que" created
    Copy to Clipboard Toggle word wrap

  8. 验证所有之前描述的新 ImageStreams 是否存在，以及所有新的 zync-que 相关元素： 

    $ oc get is system-redis
$ oc get is system-mysql
$ oc get is system-memcached
$ oc get is zync-database-postgresql
$ oc get is backend-redis
$ oc get role zync-que-role
$ oc get sa zync-que-sa
$ oc get rolebinding zync-que-rolebinding
$ oc get dc zync-que
    Copy to Clipboard Toggle word wrap

    上述所有命令都会返回显示它们已经创建的输出。另外，如果输入： 

    $ oc get pods | grep -i zync-que
    Copy to Clipboard Toggle word wrap

    您将看到其状态为 Error，或者指出崩溃的其它错误。这是预期的结果，因为 Zync 镜像还没有更新。这是在 第 2.8 节 “升级 3scale 镜像” 部分的点 4 中完成。

本节将帮助您配置现有 system DeploymentConfig 以使用您创建的 secret 字段。这些 secret 字段用作 system-redis 中的环境变量。

  1. 在 system-redis secret 中为系统连接添加与 Redis Enterprise 兼容性相关的字段： 

    $ oc patch secret/system-redis --patch '{"stringData": {"MESSAGE_BUS_SENTINEL_HOSTS": "", "MESSAGE_BUS_SENTINEL_ROLE": "", "SENTINEL_HOSTS": "", "SENTINEL_ROLE": "", "MESSAGE_BUS_NAMESPACE": "", "MESSAGE_BUS_URL": "", "NAMESPACE": ""}}'
    Copy to Clipboard Toggle word wrap

  2. 将新环境变量添加到 system-app 容器中： 

    $ oc patch dc/system-app -p "$(cat redis-patches/system-app-podcontainers.patch)"
    Copy to Clipboard Toggle word wrap

    此命令触发 system-app DeploymentConfig 重启。等待 DeploymentConfig pod 重启并再次处于 Ready 状态。

  3. 使用以下命令列出 DeploymentConfig 的所有环境变量： 

    $ oc set env dc a-deployment-config-name --list
    Copy to Clipboard Toggle word wrap
    • 运行这个命令，以在此步骤的项中的每个 patch 命令前和之后检索环境变量列表。

    • 以下是无法使用命令列出环境变量并需要特定命令的特殊情况：

      • pre-hook pod: 

        $ oc get dc system-app -o json | jq .spec.strategy.rollingParams.pre.execNewPod.env
        Copy to Clipboard Toggle word wrap

      • system-sidekiq initContainer 

        $ oc get dc system-sidekiq -o json | jq .spec.template.spec.initContainers[0].env
        Copy to Clipboard Toggle word wrap

  4. 将新环境变量添加到 system-app pre-hook pod 中： 

    $ oc patch dc/system-app -p "$(cat redis-patches/system-app-prehookpod-json.patch)" --type json
    Copy to Clipboard Toggle word wrap

    运行前面的命令后，现有环境变量会保持不变。另外，新的变量被添加到 system-app 的 pre-hook pod 中，以及 system-app 的所有容器（system-master、system-developer、system-provider），并将 system-secret secret 用作源：

    • REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_URL
    • MESSAGE_BUS_REDIS_SENTINEL_HOSTS
    • MESSAGE_BUS_REDIS_SENTINEL_ROLE
    • REDIS_SENTINEL_HOSTS
    • REDIS_SENTINEL_ROLE
    • BACKEND_REDIS_SENTINEL_HOSTS
    • BACKEND_REDIS_SENTINEL_ROLE

  5. 在 system-sidekiq 中添加新环境变量： 

    $ oc patch dc/system-sidekiq -p "$(cat redis-patches/system-sidekiq.patch)"
    Copy to Clipboard Toggle word wrap

    此命令将触发 system-sidekiq DeploymentConfig 重启。等待 DeploymentConfig 容器集重新引导并再次处于 ready 状态。

    运行上一命令后，将以下环境变量添加到 system-sidekiq pod 的 system-sidekiq InitContainer 中：

    • REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_URL
    • MESSAGE_BUS_REDIS_SENTINEL_HOSTS
    • MESSAGE_BUS_REDIS_SENTINEL_ROLE
    • REDIS_SENTINEL_HOSTS

    • REDIS_SENTINEL_ROLE

      另外，在 system-sidekiq pod 中还添加了以下环境变量：

    • REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_URL
    • MESSAGE_BUS_REDIS_SENTINEL_HOSTS
    • MESSAGE_BUS_REDIS_SENTINEL_ROLE
    • REDIS_SENTINEL_HOSTS
    • REDIS_SENTINEL_ROLE
    • BACKEND_REDIS_SENTINEL_HOSTS
    • BACKEND_REDIS_SENTINEL_ROLE

  6. 在 system-sphinx 中添加新环境变量： 

    $ oc patch dc/system-sphinx -p "$(cat redis-patches/system-sphinx.patch)"
    Copy to Clipboard Toggle word wrap

    此命令触发 system-sphinx DeploymentConfig 重启。等待 DeploymentConfig 容器集重新引导并再次处于 ready 状态。

    运行上一命令后，会将以下环境变量保持在 system-sphinx pod 中。

    • REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_NAMESPACE
    • MESSAGE_BUS_REDIS_URL
    • MESSAGE_BUS_REDIS_SENTINEL_HOSTS
    • MESSAGE_BUS_REDIS_SENTINEL_ROLE
    • REDIS_SENTINEL_HOSTS
    • REDIS_SENTINEL_ROLE
    • REDIS_URL

2.5. 修复 Redis Sentinel 环境变量
复制链接

此步骤涉及在 3scale 2.5 中修复一个问题，它会阻止 Redis Sentinel 连接配置在 backend-worker 和 backend-cron pod 中工作。

  1. 运行以下命令，以查看 DeploymentConfig InitContainer 的所有现有环境变量： 

    $ oc get dc a-deployment-config-name -o json | jq .spec.template.spec.initContainers[0].env
    Copy to Clipboard Toggle word wrap

    使用此命令在此流程中执行的每个补丁命令前和之后检索环境变量列表，以验证一切是否按预期工作。

  2. 在 backend-worker 中应用 Redis Sentinel 连接修复： 

    $ oc patch dc/backend-worker -p "$(cat redis-patches/backend-worker.patch)"
    Copy to Clipboard Toggle word wrap

    运行此命令后，会在 backend-worker DeploymentConfig 的 backend-worker InitContainer 中添加以下环境变量：

    • CONFIG_REDIS_PROXY
    • CONFIG_REDIS_SENTINEL_HOSTS
    • CONFIG_REDIS_SENTINEL_ROLE
    • CONFIG_QUEUES_SENTINEL_HOSTS
    • CONFIG_QUEUES_SENTINEL_ROLE
    • RACK_ENV

  3. 在 backend-cron 中应用 Redis Sentinel 连接修复： 

    $ oc patch dc/backend-cron -p "$(cat redis-patches/backend-cron.patch)"
    Copy to Clipboard Toggle word wrap

    运行此命令后，会在 backend-cron DeploymentConfig 的 backend-cron InitContainer 中添加以下环境变量：

    • CONFIG_REDIS_PROXY
    • CONFIG_REDIS_SENTINEL_HOSTS
    • CONFIG_REDIS_SENTINEL_ROLE
    • CONFIG_QUEUES_SENTINEL_HOSTS
    • CONFIG_QUEUES_SENTINEL_ROLE
    • RACK_ENV

2.6. 修复 Zync 环境变量
复制链接

  • 运行以下命令以更新 zync 环境： 

    oc patch dc zync -p '{"spec": {"template": {"spec": {"containers": [{"name": "zync", "env": [{"name": "POD_NAME", "valueFrom": {"fieldRef": {"apiVersion": "v1", "fieldPath": "metadata.name"}}}, {"name": "POD_NAMESPACE", "valueFrom": {"fieldRef": {"apiVersion": "v1", "fieldPath": "metadata.namespace"}}}]}]}}}}'
    Copy to Clipboard Toggle word wrap

2.7. 将 DeploymentConfig 数据库迁移到 ImageStreams
复制链接

在 2.6 中，部署包含数据库的 3scale DeploymentConfig 已从 ImageStreams 获取容器镜像，而不是直接引用镜像 URL。

  1. 迁移 backend-redis DeploymentConfig 以使用 backend-redis ImageStream： 

    $ oc patch dc/backend-redis -p "$(cat db-imagestream-patches/backend-redis-json.patch)" --type json
    Copy to Clipboard Toggle word wrap
    • 这会触发 backend-redis DeploymentConfig 重新部署，DeploymentConfig 现在有一个 ImageChange 触发器引用 backend-redis ImageStream。

    • backend-worker、backend-cron 或 backend-listener 可能会临时失败，直到重新部署 backend-redis pod。

      等待 DeploymentConfig 容器集重新引导并再次处于 ready 状态。

  2. 迁移 system-redis DeploymentConfig 以使用 system-redis ImageStream: 

    $ oc patch dc/system-redis -p "$(cat db-imagestream-patches/system-redis-json.patch)" --type json
    Copy to Clipboard Toggle word wrap
    • 这会触发 system-redis DeploymentConfig 的重新部署，DeploymentConfig 现在有一个 ImageChange 触发器引用 backend-redis ImageStream。
    • 等待 DeploymentConfig 容器集重新引导并再次处于 ready 状态。

  3. 迁移 system-memcache DeploymentConfig 以使用 system-memcached ImageStream： 

    $ oc patch dc/system-memcache -p "$(cat db-imagestream-patches/system-memcached-json.patch)" --type json
    Copy to Clipboard Toggle word wrap
    • 这会触发 system-memcache DeploymentConfig 重新部署，DeploymentConfig 现在有一个 ImageChange 触发器引用 system-memcached ImageStream。
    • 等待 DeploymentConfig 容器集重新引导并再次处于 ready 状态。

  4. 将 system-mysql DeploymentConfig 迁移到 system-mysql ImageStream: 

    $ oc patch dc/system-mysql -p "$(cat db-imagestream-patches/system-mysql-json.patch)" --type json
    Copy to Clipboard Toggle word wrap
    • 这会触发 system-mysql DeploymentConfig 重新部署，DeploymentConfig 现在有一个 ImageChange 触发器引用 system-mysql ImageStream。
    • 等待 DeploymentConfig 容器集重新引导并再次处于 ready 状态。

  5. 迁移 zync-database DeploymentConfig 以使用 zync-database-postgresql ImageStream: 

    $ oc patch dc/zync-database -p "$(cat db-imagestream-patches/zync-database-postgresql.patch)"
    Copy to Clipboard Toggle word wrap
    • 这会触发 zync-database DeploymentConfig 的重新部署，DeploymentConfig 现在有一个 ImageChange 触发器引用 zync-database-postgresql ImageStream。
    • zync DeploymentConfig pod 可能会临时失败，直到 zync-database 再次可用为止，这可能需要一些时间，直到再次就绪的状态为止。验证几分钟后所有 'zync' DeploymentConfig pod 是否处于 Ready 状态。
    • 继续操作前，请等待 DeploymentConfig pod 重启并再次处于 ready 状态。

  6. 删除不再使用的 postgresql ImageStream： 

    $ oc delete ImageStream postgresql
    Copy to Clipboard Toggle word wrap

  7. 要确认成功，请验证：

    • 所有与数据库相关的 DeploymentConfig 现在都使用 ImageStream。您可以验证是否创建了指向相应数据库 ImageStream 的 ImageChange 触发器。
    • ImageChange 触发器有一个名为 lastTriggeredImage 的字段，其中包含指向 registry.redhat.io 的 URL。

2.8. 升级 3scale 镜像
复制链接

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

    $ oc patch imagestream/amp-system --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP system 2.6"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp26/system"}, "name": "2.6", "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.6"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
    Copy to Clipboard Toggle word wrap

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

    注意

    如果使用 Oracle 数据库，您必须在执行上述说明后重新构建系统镜像，方法是使用 Oracle 数据库的 3scale 系统镜像

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

    $ oc patch imagestream/amp-apicast --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP APIcast 2.6"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp26/apicast-gateway"}, "name": "2.6", "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.6"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
    Copy to Clipboard Toggle word wrap

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

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

    $ oc patch imagestream/amp-backend --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Backend 2.6"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp26/backend"}, "name": "2.6", "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.6"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
    Copy to Clipboard Toggle word wrap

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

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

    $ oc patch imagestream/amp-zync --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Zync 2.6"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp26/zync"}, "name": "2.6", "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.6"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
    Copy to Clipboard Toggle word wrap
    • 这会触发 zync 和 zync-que DeploymentConfig 的重新部署。等待它们重新部署、对应的新容器集就绪，并且旧容器集终止。
    • 另外，您会看到 zync-que （在上一节中创建时，处于 Error 状态）正在运行，其 pod 处于 Ready 状态。

  5. 更新可见的发行版本： 

    $ oc set env dc/system-app AMP_RELEASE=2.6
    Copy to Clipboard Toggle word wrap

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

  6. 最后，您可以验证 DeploymentConfig 的所有镜像 URL 是否包含新的镜像 registry URL（在每个 url 的末尾添加的哈希值）： 

    $ THREESCALE_DC_NAMES="apicast-production apicast-staging apicast-wildcard-router backend-cron backend-listener backend-redis backend-worker system-app system-memcache system-mysql system-redis system-sidekiq system-sphinx zync zync-database"
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
    Copy to Clipboard Toggle word wrap

2.9. 从 WildcardRouter 迁移到 Zync 路由管理
复制链接

在 3scale 2.6 中，WildcardRouter 组件和通配符 OpenShift 路由已被删除，现在作为由 Zync 子系统管理的单个 OpenShift 路由创建。此流程详细介绍了将路由管理从 WildcardRouter 迁移到 Zync。

此时，所有 3scale 镜像都已升级到 3scale 2.6。创建和删除与 3scale 服务和租户对应的 OpenShift 路由由 Zync 子系统自动管理。此外，通过添加新的 OpenShift 元素（在上一节中完成）提供了需要这样做的所有新 Zync 基础架构。

要将 OpenShift 路由管理从 WildcardRouter 迁移到 Zync，必须执行与 OpenShift 路由和通配符路由相关的旧 3scale 租户和服务，然后必须执行 Zync 的现有服务和租户强制重新评估。这使得 Zync 将创建与当前具有等效的路由。

修改公共基本 URL 时，会在 system-app 中触发事件，并通过存储在 system-redis 中的作业队列通知 system-sidekiq。然后，作业会在后台处理，并发送到 zync，它会检查数据是否已或没有存在于 zync-db 中。如果检测到更改，它将通过在 zync-que 中处理的作业创建新路由。

重要

在执行任何操作前，如果您手动将 SSL 证书安装到某些路由中，则必须复制分配给路由的证书，并注意每个路由被分配到的证书。您需要将它们安装到由 Zync 创建的新等效路由中，以便保留证书功能。

注意
  • 默认情况下，通过 hosted 选项迁移您的服务。
  • 公共基本 URL 将自动填充，路由由 Zync 创建。
  • 只有在使用选项 self_managed 配置外部 APIcast 网关时才需要步骤 1。
  • 如果您选择了 3scale_managed 选项，则路由由 Zync 自动管理。

步骤

  1. 假设 Zync 不管理外部网关的路由，您可以按照其中一个建议的替代选择来修改由 Zync 管理的每个服务的部署选项：

    • 在 3scale 中：

      1. 进入 Integration 页面，点 edit integration settings。
      2. 选择正确的部署选项，并在有时保存您的更改。

    • 使用 API：

      1. 使用带有访问令牌 (ACCESS_TOKEN) 和租户端点 (TENANT_URL) 的服务标识符 (ID) 更新服务。 

        $ curl -XPUT "${TENANT_URL}/admin/api/services/${ID}.json" -d deployment_option=self_managed -d access_token="${ACCESS_TOKEN}"
        Copy to Clipboard Toggle word wrap

        另外，如果您使用 APIcast 托管，可以使用下面的命令： 

        $ curl -XPUT "${TENANT_URL}/admin/api/services/${ID}.json" -d deployment_option=hosted -d access_token="${ACCESS_TOKEN}"
        Copy to Clipboard Toggle word wrap

      2. 对于每个租户的每个服务，通过 3scale 或 API 修改 deployment_option 字段：

        • 这些是您可以将 deployment_option 设置为 self_managed 的情况：

          • APIcast 链接到 OpenShift 中的自定义路由。
          • APIcast 在 OpenShift 之外托管。
          • APICAST_PATH_ROUTING 设置为 true。
        • 在其他情况下，将 deployment_option 设置为托管的。

  2. 在可能的现有路由中，3scale 在 2.5 中自动创建一些默认路由。首先删除它们： 

    $ oc delete route system-master
$ oc delete route system-provider-admin
$ oc delete route system-developer
$ oc delete route api-apicast-production
$ oc delete route api-apicast-staging
    Copy to Clipboard Toggle word wrap

    • 如果使用 WILDCARD_POLICY=Subdomain 部署 3scale 2.5，则必须使用以下命令删除通配符路由： 

      $ oc delete route apicast-wildcard-router
      Copy to Clipboard Toggle word wrap
    • 否则，如果您在没有 WILDCARD_POLICY=Subdomain 的情况下部署 3scale 2.5，您必须删除为 3scale 租户和服务手动创建的路由，以避免重复 Zync 将创建的路由。

此时，所有与服务和租户相关的路由都必须已被删除。现在，您将由 Zync 创建对等路由：

  1. 使用 Zync 强制重新同步所有 3scale 服务和租户 OpenShift 路由： 

    $ SYSTEM_SIDEKIQ_POD=$(oc get pods | grep sidekiq | awk '{print $1}')
    Copy to Clipboard Toggle word wrap

  2. 检查 SYSTEM_SIDEKIQ_POD 环境变量结果是否不为空： 

    $ echo ${SYSTEM_SIDEKIQ_POD}
    Copy to Clipboard Toggle word wrap

  3. 最后，执行重新同步： 

    $ oc exec -it ${SYSTEM_SIDEKIQ_POD} -- bash -c 'bundle exec rake zync:resync:domains'
    Copy to Clipboard Toggle word wrap

    您将看到这种样式的输出，其中包含有关通知到系统的信息： 

    No valid API key has been set, notifications will not be sent
ActiveMerchant MODE set to 'production'
[Core] Using http://backend-listener:3000/internal/ as URL
OpenIdAuthentication.store is nil. Using in-memory store.
[EventBroker] notifying subscribers of Domains::ProviderDomainsChangedEvent 59a554f6-7b3f-4246-9c36-24da988ca800
[EventBroker] notifying subscribers of ZyncEvent caa8e941-b734-4192-acb0-0b12cbaab9ca
Enqueued ZyncWorker#d92db46bdba7a299f3e88f14 with args: ["caa8e941-b734-4192-acb0-0b12cbaab9ca", {:type=>"Provider", :id=>1, :parent_event_id=>"59a554f6-7b3f-4246-9c36-24da988ca800", :parent_event_type=>"Domains::ProviderDomainsChangedEvent", :tenant_id=>1}]
[EventBroker] notifying subscribers of Domains::ProviderDomainsChangedEvent 9010a199-2af1-4023-9b8d-297bd618096f
…
    Copy to Clipboard Toggle word wrap

    在强制 Zync 重新评估后，为所有现有租户和服务创建新路由。根据服务和租户的数量，路由创建可能需要几分钟时间。

    在进程结束时，您将看到创建：

    • 一个主管理门户路由。

      每个 3scale 租户都会创建两个路由：

    • 租户的管理门户路由。

    • 租户的开发人员门户路由。

      每个 3scale 服务都创建两个路由：

    • 与服务对应的 APIcast 暂存路由。
    • APIcast 生产路由与服务对应。

  4. 验证是否为所有现有服务和租户创建了上述所有预期的路由。您可以通过运行以下命令查看所有路由： 

    $ oc get routes
    Copy to Clipboard Toggle word wrap

    如上一命令的输出中显示的 host/port 字段必须是路由的 URL。

    • 如果您部署了 3scale 2.5，将 WILDCARD_POLICY 设置为 Subdomain，则所有新路由都必须具有与旧 OpenShift 通配符Domain 相同的基本 WildcardDomain。
    • 否则，如果您在没有 WILDCARD_POLICY=Subdomain 的情况下部署 3scale 2.5，新路由必须具有与您删除的旧路由相同的主机，包括在 2.5 发行版中 3scale 自动创建的那些。
  5. 最后，如果您为旧通配符路由使用自定义 SSL 证书，或者旧的手动创建的路由，请将它们安装到 Zync 创建的新路由中。您可以通过 OpenShift Web 面板编辑路由，并将证书/添加到其中。

  6. 验证在迁移仍然可使用新路由解析前存在的服务和租户。要做到这一点执行以下操作：

    1. 解析与迁移前已存在的 3scale 服务关联的现有 APIcast 生产 URL 的路由。
    2. 解析与迁移前已存在的 3scale 服务关联的现有 APIcast staging URL 的路由。
    3. 解析在迁移前已存在的租户的路由。

  7. 验证新的 Zync 功能是否正常工作时，请确认在创建新租户和服务时是否生成了新的路由。要做到这一点执行以下操作：

    1. 从 'master' 面板创建一个新租户，并验证与它关联的新路由后出现在 OpenShift 中。
    2. 在其中一个现有租户中创建一个新服务，并验证与它关联的新路由出现在 OpenShift 中后。

  8. 删除 apicast-wildcard-router 服务： 

    $ oc delete service apicast-wildcard-router
    Copy to Clipboard Toggle word wrap

  9. 删除已弃用的 WildcardRouter 子系统： 

    $ oc delete ImageStream amp-wildcard-router
$ oc delete DeploymentConfig apicast-wildcard-router
    Copy to Clipboard Toggle word wrap

    执行完所有列出的步骤后，3scale 从 2.5 升级到 2.6 现已完成。

法律通告
复制链接

Copyright © 2023 Red Hat, Inc.
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.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat