Estimated Reading time: 9 minutes | Last modified: 2022-07-08, 3:07:37 pm

Upgrade OpenResty Edge

1. Upgrade Log Server DB

  • Download Installer
curl -O https://openresty.com/client/oredge/openresty-edge-installer.sh
  • Run installer
sudo /bin/bash openresty-edge-installer.sh
  • Enter the action you want to perform Upgrade
What would you like to do?
[1] Install
[2] Upgrade
[3] Downgrade
[4] Uninstall
2
What you choose is: Upgrade.
  • Enter the version you want to upgrade (The latest version information can be obtained from Changelog)
which version would you like to upgrade? (like 22.6.1)
22.6.1
  • Enter the component you want to install Log Server DB
Which component would you like to upgrade?
[1] Log Server DB
[2] Log Server
[3] Node
[4] Admin DB
[5] Admin
[6] Rebuild
[7] Clean db after upgrade
1
What you choose is: Log Server DB.
  • If successful, the following prompt will be displayed at the end
Great! update log-server database successfully.

2. Upgrade Log Server

  • The procedure is the same, with the component Log Server selected for the upgrade
Which component would you like to upgrade?
[1] Log Server DB
[2] Log Server
[3] Node
[4] Admin DB
[5] Admin
[6] Rebuild
[7] Clean db after upgrade
2
What you choose is: Log Server.
  • If successful, the following prompt will be displayed at the end
Great! Upgrade openresty-edge-log-server successfully.

3. Upgrade Node

3.1 Backup Node Database

If your current OpenResty Edge Admin version is less than 1.3.0, skip this step.

  • Log in to the OpenResty Edge Admin console
  • [Gateway Clusters] - [Backup and Restore] - [Start Backup]

3.2 Migrate traffic(optional)

To avoid disrupting operations, before a Node is upgraded, migrate the traffic on that Node to another Node that is not upgraded. This step is optional, but is highly recommended for the few Nodes that are initially upgraded.

  • migrate away traffic
  • Upgrade
  • Verify

After it is OK, upgrade the remaining Node without migrating traffic. Also, please pay attention to the error logs during the upgrade process.

If you are using the OpenResty Edge’s DNS to control traffic, follow these steps to migrate traffic.

Access the OpenResty Edge console:

  • Enter the [Gateway Clusters].
  • [Edit] The cluster where the node is located.
  • Modify the node’s [status] to [Disable DNS, disable caching cluster].
  • [Save]

Wait for the node no longer to have traffic or only a small amount of traffic. You could confirm by checking the access log:

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

3.3 Upgrade

  • The procedure is the same, with the component Node selected for the upgrade
Which component would you like to upgrade?
[1] Log Server DB
[2] Log Server
[3] Node
[4] Admin DB
[5] Admin
[6] Rebuild
[7] Clean db after upgrade
3
What you choose is: Node.
  • If successful, the following prompt will be displayed at the end
Great! Upgrade openresty-edge-node successfully.

4. Upgrade Admin DB

  • The procedure is the same, with the component Admin DB selected for the upgrade
Which component would you like to upgrade?
[1] Log Server DB
[2] Log Server
[3] Node
[4] Admin DB
[5] Admin
[6] Rebuild
[7] Clean db after upgrade
4
What you choose is: Admin DB.
  • Backup Admin database

Before executing the backup command, please check if there is enough disk space.

Do you want to backup db? [Y/N]:  y
  • If successful, the following prompt will be displayed at the end
Great! update admin database successfully.

5. Upgrade Admin-web

Choose either this step or 7. staging upgrade Admin-web.

If you have configured double admin-web and want to staging upgrade the Admin-web service, you can jump to 7 staging upgrade Admin-web.

  • The procedure is the same, with the component Admin selected for the upgrade
Which component would you like to upgrade?
[1] Log Server DB
[2] Log Server
[3] Node
[4] Admin DB
[5] Admin
[6] Rebuild
[7] Clean db after upgrade
5
What you choose is: Admin.
  • If successful, the following prompt will be displayed at the end
Great! Upgrade openresty-edge-admin successfully.

6. Recompile

  • The procedure is the same, with the component Rebuild selected for the upgrade
Which component would you like to upgrade?
[1] Log Server DB
[2] Log Server
[3] Node
[4] Admin DB
[5] Admin
[6] Rebuild
[7] Clean db after upgrade
6
What you choose is: Rebuild.
  • Recompile a few applications that do not contain wildcard domains with less traffic first. Recompile several high-traffic applications that do not contain wildcard domains later.
Do you want to rebuild one application for test? [Y/N]:  y
Please input the application id: 1
rebuild application 1
  • Continue to follow the prompts to compile
Do you want to rebuild upgrade config? [Y/N]:  y
rebuild upgrade config
recompile upgrade configurations successfully

Do you want to rebuild all wildcard apps? [Y/N]:  y
rebuild all wildcard apps

Do you want to rebuild all apps? [Y/N]:  y
Do you want to compile concurrently? [Y/N]:  n
rebuild all apps

Do you want to rebuild all http_proxy apps? [Y/N]:  y
rebuild all http_proxy apps

Do you want to rebuild all socks5_apps? [Y/N]:  y
rebuild all sock5_proxy apps

Do you want to rebuild global? [Y/N]:  y
rebuild global
recompile global successfully

Do you want to rebuild waf? [Y/N]:  y
rebuild waf
recompiled all of the WAF rule sets successfully.

Do you want to rebuild dns? [Y/N]:  y
rebuild dns
recompile dns successfully.

Do you want to rebuild global-action? [Y/N]:  y
rebuild global-action
recompile global action successfully

Do you want to rebuild gateway? [Y/N]:  y
rebuild gateway
recompiled gateway successfully

rebuild done!

If the whole system behaves normally, the upgrade is complete!

This step may take longer to compile when there are many HTTP/HTTPS applications.

Do you want to rebuild all apps? [Y/N]:  y

We can choose concurrent compilation, which will start 4 processes to compile.

Do you want to compile concurrently? [Y/N]:  y

If that is not fast enough, you can modify the installer to specify a larger concurrency, but not larger than 8, e.g.

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

7. staging upgrade Admin-web

Choose either this step or 5. Upgrade Admin-web.

There are two prerequisites for staging upgrade of Admin-web.

  1. You have installed and configured double admin-web.
  2. Current version of Admin-web (before upgrade) is not lower than 1.3.0-1.

The architecture diagram is as follows.

Staging upgrade Admin-web architecture diagram

The key differences compared to the dual master Admin-web:

  1. Admin-B is a new version, which allows release to staging nodes with the new features, thus staging the Admin-web.
  2. Admin-A is the old version, which still provides the services of the old version. And upgrades to the dual-master state after the new version has been confirmed work well.

The specific steps are as follows.

  • Divide roles between the two Admin-webs, for example, Admin-A and Admin-B in the above diagram.

    Admin-A will not be upgraded during the staging period, so please ensure that the web, REST API calls, and SDK calls are using Admin-A. Admin-B will refuse to provide web services but will still be able to communicate with edge-node normally so that the node side will remain dual master.

  • Configure Admin-B as the staging role and upgrade to the new version

    Modify config.ini to change the role field to staging. The example configuration for the clone_admin segment in config.ini is as follows.

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

    Upgrade method reference 5. Upgrade Admin.

  • Configure the other Admin A role as main

    Modify config.ini to change the role field to main. An example of the configuration of the clone_admin segment of config.ini is as follows.

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

    Restart Admin-A.

    sudo systemctl reload oredge-admin

  • On Admin B, recompile the application and global configuration

    See 6 recompile for the steps.

    After completion, observe for a while, and if there are problems, go to Rollback I.

  • Restore the Admin B role to dual master

    Modify config.ini to change the role field to normal. An example configuration for the clone_admin segment in config.ini is as follows.

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

    Restart Admin-B.

    sudo systemctl reload oredge-admin

  • Restore Admin A’s role to the dual master, upgrade to the new version, and recompile the application and global configuration

    Modify config.ini to change the role field to normal. An example configuration for the ``clone_admin`’ segment in config.ini is as follows.

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

    Upgrade method reference 5. Upgrade Admin.

    See 6. recompile for steps.

    If all business indicators behave properly, the upgrade is complete! You can now use Admin-A and Admin-B as dual masters again.

    If there are problems goto Rollback II

7.1 Admin-web Rollback I

  • Restore Admin-A to a dual master role, restart the service, and recompile the application and global configuration

    Modify config.ini to change the role field to normal. An example configuration for the clone_admin segment in config.ini is as follows.

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

    Restart Admin-A.

    sudo systemctl reload oredge-admin

    See 6 recompile for recompiling steps. Note: At this point, you can prioritize the recompile step that caused the error and restore the service as quickly as possible.

  • Restore the Admin B role to dual master and roll back the version

    Modify config.ini to change the role field to normal. An example configuration for the clone_admin segment in config.ini is as follows.

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

    Downgrade method.

    curl -O https://openresty.com/client/oredge/downgrade-openresty-edge.sh
sudo /bin/bash downgrade-openresty-edge.sh OLD_PACKAGE_VERSION [OLD_PLUS_VERSION]

# e.g.:
#  sudo /bin/bash downgrade-openresty-edge.sh 1.1.0-0
#  sudo /bin/bash downgrade-openresty-edge.sh 1.1.0-0 1.19.9.1.3-1

    Downgrade complete!

7.2 Admin-web Rollback II

  • Rollback Admin A and recompile

    At this point, Admin A is already in dual-master mode, and you only need to downgrade the version of Admin A Downgrade in the same way as above.

    curl -O https://openresty.com/client/oredge/downgrade-openresty-edge.sh
sudo /bin/bash downgrade-openresty-edge.sh OLD_PACKAGE_VERSION [OLD_PLUS_VERSION]

# e.g.:
#  sudo /bin/bash downgrade-openresty-edge.sh 1.1.0-0
#  sudo /bin/bash downgrade-openresty-edge.sh 1.1.0-0 1.19.9.1.3-1

    See 4.3 recompile for recompiling steps. Note: At this point, you can prioritize recompiling the step that caused the error and restore the service as soon as possible.

  • Rolling back Admin B

    Downgrade in the same way as above.

    curl -O https://openresty.com/client/oredge/downgrade-openresty-edge.sh
sudo /bin/bash downgrade-openresty-edge.sh OLD_PACKAGE_VERSION [OLD_PLUS_VERSION]

# e.g.:
#  sudo /bin/bash downgrade-openresty-edge.sh 1.1.0-0
#  sudo /bin/bash downgrade-openresty-edge.sh 1.1.0-0 1.19.9.1.3-1

    Downgrade complete!

8. After Upgrade

After the previous steps have been performed and validated, this step can be performed to clean up database fields that are no longer needed or to add constraints to database fields.

  • The procedure is the same, with the component Clean db after upgrade selected for the upgrade
Which component would you like to upgrade?
[1] Log Server DB
[2] Log Server
[3] Node
[4] Admin DB
[5] Admin
[6] Rebuild
[7] Clean db after upgrade
7
What you choose is: Clean db after upgrade.
  • If successful, the following prompt will be displayed at the end
Great! upgrade admin database successfully.

If you have any questions, please get in touch with us.