升级 OpenResty Edge

1. 升级 Log Server

1.1 查看并记录升级前的版本信息

# centos/redhat/fedora
rpm -q openresty-edge-log-server
# or
rpm -q openresty-edge-log-server-prod

# debian/ubuntu
dpkg -l | grep openresty-edge-log-server
# or
dpkg -l | grep openresty-edge-log-server-prod

1.2 安装时序库

如果您使用的不是 openresty-PostgreSQL,请自行安装时序库插件;如果您之前已经安装过,则可以跳过此步骤。

curl -O https://openresty.com/client/oredge/install-edge-postgresql-timscaledb.sh
sudo /bin/bash install-edge-postgresql-timscaledb.sh

1.3 升级数据库

# 如缺少此文件,请联系我们进行确认
# 请替换 VERSION 为实际的版本号
/bin/bash update-log-server-db-VERSION.sh

1.4 下载升级脚本

curl -O https://openresty.com/client/oredge/upgrade-edge-log-server.sh

如果得到一条类似下面的信息:

curl: command not found

可能是系统里面没有安装 curl 或者是系统的 shell 程序没有包含 curl 的搜索路径。

你可以使用绝对路径来重试:

/usr/bin/curl -O https://openresty.com/client/oredge/upgrade-edge-log-server.sh

你的系统的路径可能不同,请联系你的网站管理员或使用 which bash 等命令来检查路径以纠正这种情况。

1.5 执行升级脚本

sudo /bin/bash upgrade-edge-log-server.sh

2. 升级 Node

我们建议先对 1~2 个 Node:

  • 迁移走流量
  • 升级
  • 验证

没问题后,再不迁移流量升级剩下的 Node 。另外,升级过程中请关注错误日志。

2.1 备份 Node 数据库

如果你当前的 OpenResty Edge Admin 版本小于 1.3.0,则跳过此步骤。

  • 登录 OpenResty Edge Admin 控制台
  • 【网关集群】-【备份与还原】-【开始备份】

2.2 查看并记录升级前的软件版本

# centos/redhat/fedora
rpm -q openresty-edge-node
# or
rpm -q openresty-edge-node-prod

# debian/ubuntu
dpkg -l | grep openresty-edge-node
# or
dpkg -l | grep openresty-edge-node-prod

2.3 迁移流量(可选)

为避免影响业务,Node 节点升级前,把该节点上的流量转移到其他未升级节点上。 此步骤为可选,但是强烈建议对最初升级的少数 Node 执行此步骤。 如果使用的 OpenResty Edge 的 DNS 控制流量,请按以下步骤把即将升级的 Node 节点下线。

进入 OpenResty Edge 控制台:

  • 进入【网关集群】页面
  • 对节点所在集群进行【编辑】
  • 修改节点【状态】为【关闭 DNS,关闭集群缓存】
  • 保存

等待节点不再有流量或只有少量流量。可通过查看访问日志确定:

tail -f /usr/local/oredge-node/logs/access.log

2.4 下载并执行升级脚本

curl -O https://openresty.com/client/oredge/upgrade-edge-node.sh

sudo /bin/bash upgrade-edge-node.sh

3. 升级 Admin 数据库

3.1 备份 Admin 数据库

执行备份命令前,请先检查磁盘空间是否足够。

# 请替换 127.0.0.1 成实际的 IP,替换 5432 成实际的端口。
/usr/local/openresty-postgresql12/bin/pg_dump or_edge_admin                       \
    -h 127.0.0.1 -p 5432 -U postgres                                              \
    | gzip > db_edge_admin_$(date '+%Y-%m-%d').sql.gz

3.2 升级 Admin 数据库

# 如缺少此文件,请联系我们进行确认
# 请替换 VERSION 为实际的版本号
/bin/bash update-admin-db-VERSION.sh

4. 升级 Admin-web

此步骤与 5. 灰度升级 Admin 二选一。 如果配置过两份 Admin-web 服务,并且希望可以灰度升级 Admin-web 服务,请按 5. 灰度升级 Admin 中的步骤进行。

4.1 查看并记录升级前的软件版本

# centos/redhat/fedora
rpm -q openresty-edge-admin
# or
rpm -q openresty-edge-admin-prod

# debian/ubuntu
dpkg -l | grep openresty-edge-admin
# or
dpkg -l | grep openresty-edge-admin-prod

4.2 升级

# 下载升级脚本
curl -O https://openresty.com/client/oredge/upgrade-edge-admin.sh

# 执行升级脚本:
sudo /bin/bash upgrade-edge-admin.sh

4.3 重新编译

需要重新编译应用,请按照以下顺序进行:

  1. 先重新编译几个流量较少的不包含泛域名的 HTTP 应用
  2. 重新编译几个大流量的不包含泛域名的 HTTP 应用
  3. 全量编译所有包含泛域名的应用
  4. 全量编译所有应用
  5. 编译全局规则
# 在 admin 机器上
cd /usr/local/oredge-admin/
# 重新编译升级兼容配置
sudo /bin/bash utils/recompile-apps.sh upgrade-config
# 重新编译指定应用 ( APP-ID 替换为应用 ID)
sudo /bin/bash utils/recompile-apps.sh http APP-ID
# 重新编译所有应用
sudo /bin/bash utils/recompile-apps.sh wildcard-http
sudo /bin/bash utils/recompile-apps.sh http
sudo /bin/bash utils/recompile-apps.sh http_proxy
sudo /bin/bash utils/recompile-apps.sh socks5_proxy
# 重新编译全局规则
sudo /bin/bash utils/recompile-apps.sh global
# 重新编译waf规则
sudo /bin/bash utils/recompile-apps.sh waf
# 重新编译dns
sudo /bin/bash utils/recompile-apps.sh dns
# 重新编译全局动作
sudo /bin/bash utils/recompile-apps.sh global-action
# 重新编译网关节点(可能会触发 node 节点重载)
sudo /bin/bash utils/recompile-apps.sh gateway

如果业务指标都表现正常,升级完成!

如果 HTTP/HTTPS 应用数量很多,可能这一步的编译时间会比较长:

sudo /bin/bash utils/recompile-apps.sh http

此时,我们推荐用另外一个工具,来并发编译,如下命令将启动 4 个进程来编译:

sudo /bin/bash utils/parallel-recompile.sh

如果不够快,也可以指定更大的并发,但是不能超过 8,比如:

sudo /bin/bash utils/parallel-recompile.sh 8

5. 灰度升级 Admin

此步骤与 4. 升级 Admin 二选一。

灰度升级 Admin-web 有两个前提条件:

  1. 安装配置过 两份 Admin-web 服务
  2. 升级前 Admin-web 的版本不低于 1.3.0-1 。

架构图如下:

灰度升级 Admin-web 架构图

相比于双主 Admin-web 状态,核心区别在于:

  1. Admin-B 为新版本,可以把新版本的特性,发布到灰度的 node 节点上,从而灰度验证 Admin-web 。
  2. Admin-A 为老版本,依旧提供老版本的服务,待新版本灰度验证通过,再升级灰度到双主状态。

具体步骤如下:

  • 针对两个 Admin-web 做角色划分,例如上图的 Admin-A 和 Admin-B 。

    Admin-A 在灰度期间先不会升级,所以确保 Web,REST API 调用,SDK 调用,都指向了 Admin-A 。 Admin-B 接下来将会拒绝提供 Web 服务,但是还是可以正常与 edge-node 通讯,所以 node 侧还是可以保持双主。

  • 将 Admin-B 配置为灰度角色,并升级到新版本

    修改 config.ini,将 role 字段修改为 staging,修改后 config.ini 中 clone_admin 段的配置示例如下:

    # 配置文件:/usr/local/oredge-admin/conf/config.ini
    [clone_admin]
    host = "IP-of-Admin-A"
    role = "staging"
    

    升级方式与上面的一样:

    # 下载升级脚本
    curl -O https://openresty.com/client/oredge/upgrade-edge-admin.sh
    
    # 执行升级脚本:
    sudo /bin/bash upgrade-edge-admin.sh
    
  • 将另外一个 Admin A 的角色配置为 main

    修改 config.ini,将 role 字段修改为 main,修改后 config.ini 中 clone_admin 段的配置示例如下:

    # 配置文件:/usr/local/oredge-admin/conf/config.ini
    [clone_admin]
    host = "IP-of-Admin-B"
    role = "main"
    

    重启 Admin-A:

    sudo systemctl reload oredge-admin
    
  • Admin B 上,重新编译应用和全局配置

    重新步骤参见 4.3 重新编译

    完成后,观察一段时间,如果有问题执行回滚操作一

  • 将 Admin B 的角色恢复为双主

    修改 config.ini,将 role 字段修改为 normal,修改后 config.ini 中 clone_admin 段的配置示例如下:

    # 配置文件:/usr/local/oredge-admin/conf/config.ini
    [clone_admin]
    host = "IP-of-Admin-A"
    role = "normal"
    

    重启 Admin-B:

    sudo systemctl reload oredge-admin
    
  • 将 Admin A 的角色恢复为双主,升级到新版本,并重新编译应用和全局配置

    修改 config.ini,将 role 字段修改为 normal,修改后 config.ini 中 clone_admin 段的配置示例如下:

    # 配置文件:/usr/local/oredge-admin/conf/config.ini
    [clone_admin]
    host = "IP-of-Admin-B"
    role = "normal"
    

    升级方式与上面的一样:

    # 下载升级脚本
    curl -O https://openresty.com/client/oredge/upgrade-edge-admin.sh
    
    # 执行升级脚本:
    sudo /bin/bash upgrade-edge-admin.sh
    

    步骤参见 4.3 重新编译

    如果业务指标都表现正常,升级完成!又可以把 Admin-A 和 Admin-B 当做双主使用了。

    如果有问题执行 回滚操作二

5.1 Admin-web 回滚一

  • 将 Admin-A 恢复为双主角色,重启服务,并重新编译应用和全局配置

    修改 config.ini,将 role 字段修改为 normal,修改后 config.ini 中 clone_admin 段的配置示例如下:

    # 配置文件:/usr/local/oredge-admin/conf/config.ini
    [clone_admin]
    host = "IP-of-Admin-B"
    role = "normal"
    

    重启 Admin-A:

    sudo systemctl reload oredge-admin
    

    重新编译步骤参见 4.3 重新编译。 注意:此时可以优先重新编译导致出错的那一步,可以尽快的恢复服务。

  • 将 Admin B 角色恢复为双主,并回滚版本

    修改 config.ini,将 role 字段修改为 normal,修改后 config.ini 中 clone_admin 段的配置示例如下:

    # 配置文件:/usr/local/oredge-admin/conf/config.ini
    [clone_admin]
    host = "IP-of-Admin-B"
    role = "normal"
    

    降级方式与上面的一样:

    curl -O https://openresty.com/client/oredge/downgrade-edge-admin.sh
    sudo /bin/bash downgrade-edge-admin.sh OLD_PACKAGE_VERSION
    
    # 如:sudo /bin/bash downgrade-edge-admin.sh 1.1.0-0
    

    降级完成!

5.2 Admin-web 回滚二

  • 回滚 Admin A 并重新编译到全网

    此时 Admin A 已经是双主模式,只需要降级 Admin A 的版本 降级方式与上面的一样:

    curl -O https://openresty.com/client/oredge/downgrade-edge-admin.sh
    sudo /bin/bash downgrade-edge-admin.sh OLD_PACKAGE_VERSION
    
    # 如:sudo /bin/bash downgrade-edge-admin.sh 1.1.0-0
    

    重新编译步骤参见 4.3 重新编译。 注意:此时可以优先重新编译导致出错的那一步,可以尽快的恢复服务。

  • 回滚 Admin B 版本

    降级方式与上面的一样:

    curl -O https://openresty.com/client/oredge/downgrade-edge-admin.sh
    sudo /bin/bash downgrade-edge-admin.sh OLD_PACKAGE_VERSION
    
    # 如:sudo /bin/bash downgrade-edge-admin.sh 1.1.0-0
    

    降级完成!

6. 升级完成后

在执行完前面的步骤并验证完成后,可以执行此步骤来清理不再需要的数据库字段或者对数据库字段增加约束。

  • Admin DB
bash /tmp/after-upgrade-admin-db-VERSION.sh

# 如: bash /tmp/after-upgrade-admin-db-202.sh

有问题我们随时沟通 :)