0:00
Hello. In this lesson,
we're going to talk about upgrading Apigee components.
In the previous lesson, you saw how to bootstrap
the hosts in your Apigee planet to prepare for an upgrade.
The bootstrapping process reconfigures access to
your Apigee software repository by
pointing it to the new version to which you are upgrading.
This lesson provides an overview of the next step,
the component upgrade process.
The installation and upgrade processes are similar in some ways.
For instance, both use scripts included in
the apigee-setup utility and use the same response file.
An important difference between the two processes is
that while the installation process operates on profiles,
the upgrade process operates on components.
Remember that a profile such as DS, or data source,
or RMP for routers and message processors,
can bundled together multiple components.
Since components from more than one profile can be stacked together on a single host,
the upgrade process enforces ordering by targeting specific components in some cases.
Here is a list of the available components you can upgrade.
Note that each of the open source components have a dedicated component name.
These components are normally upgraded first and the ordering is important.
There is also an Edge component which
includes any Apigee Edge component other than the UI.
The UI component targets just the UI.
Finally, the DP component is for the developer portal.
The upgrade program will care for upgrading RPMs to the newer software release,
updating service configurations and updating or migrating
data if necessary, and restarting services.
In some cases, the only action will be to upgrade the RPMs and restart services.
For components such as Cassandra or PostgreSQL,
a data update or migration may occasionally be necessary, and this will be done for you.
The response file used for upgrading is identical to the one used for installation.
You should keep the response file in a secure place that you can reuse
it for the initial installation as well as for future upgrades.
On occasion, a new variable may be added to the response file.
The release notes for each release will clearly identify
any changes to the response file so that you can update it if needed.
The ordering of component upgrades can vary from release to release.
If underlying database components such as Cassandra or
PostgreSQL are upgraded to a new upstream release,
the ordering may change slightly,
so be sure to check the release notes and documented upgrade procedure for details.
The typical ordering is to upgrade Cassandra and ZooKeeper first,
Qpid second, PostgreSQL third, and OpenLDAP fourth.
With the open source components upgraded,
the Edge profile can be applied in order on Qpid servers,
Postgre servers, management servers,
routers, and finally, message processors.
This ordering will be the same in multi-region installations as well.
Each component should be upgraded in order
across all regions before moving onto the next component.
Here, you see that all Cassandre and ZooKeeper components
in both regions are upgraded first,
followed by all Qpid components in both regions, and so on.
Following the upgrade, you should run Apigee all
status to ensure that all services are running.
You will also need to re-enable the Cassandra node to
repair maintenance job if you temporarily disabled it for the upgrade.
Finally, you will want to perform post
upgrade validation and testing as described in the upgrade validation lesson.
For more information on this topic,
refer to our documentation.
If you have any questions,
please post them to our community. Thanks for watching.
Google Cloud Training
