Page History
...
Before updating users should identify the version in use by JS7 Components and the indicated compatibility, see JS7 - Compatibility Indicator.
Applicability
- For most upgrades the The JOC Cockpit and the Controller are required to use the same minor release, for example 2.2.
- Existing Agents can continue to be operated with newer Controller releases within the same minor release , for example 2.2.only:
- An older Agent maintenance version release 2.2.1 will work with a Controller maintenance release 2.2.2.
- A newer Agent minor version release cannot be used with an older Controller minor versionrelease: for example, an Agent 2.2 will not work with a Controller 2.1.
- An older Agent minor version release cannot be used with newer Controller minor versionsrelease: for example, an Agent 2.1 will not work with a Controller 2.2.
...
Consider that the above procedure does not apply if you build your own images, see JS7 - Build Docker Images. Consider to map the steps explained with Upgrade Procedure for Headless Installation On Premises.
Anchor | ||||
---|---|---|---|---|
|
...
Installation On Premises
JOC Cockpit
- Consider instructions from JS7 - JOC Cockpit Installation On Premises.
- Take a backup of the JOC Cockpit's installation directory.
- Automated Upgrade
- Stop the JOC Cockpit daemon (Linux) or service (Windows) of any JOC Cockpit instances using the same database.
- Take a backup of the JS7 - Database schema. During upgrade changes to the database schema might be applied that prevent to rollback to the previous JOC Cockpit release.
- Run the JOC Cockpit Installation Script for Upgrade
- Manual Upgrade
- Extract the installer archive .tar.gz/.zip file. This will create a sub-directory that includes the maintenance release number, for example
joc.2.2.2
.- Users basically can re-use an existing
joc_install.xml
installer response file from a previous installation, however, users should check for changes, for example new or changed installer options that are available from thejoc_install.xml
file after extraction of the installer archive. If in doubt copy settings from a previousjoc_install.xml
file to the new version of this file. - Consider to copy additional resources to the directory of the extracted installer archive, for example to
joc.2.2.2
- any JDBC Drivers that you downloaded individually for installation with a previous JOC Cockpit release,
- the Hibernate configuration file that holds the database connection and that has been used for a previous installation,
- the JS7 license key *.pem file if JS7 is operated with a Commercial License.
- Users basically can re-use an existing
- Stop the JOC Cockpit daemon (Linux) or service (Windows) of any JOC Cockpit instances using the same database.
- Take a backup of the JS7 - Database schema. During upgrade changes to the database schema might be applied that prevent to rollback to the previous JOC Cockpit release.
- Run the JOC Cockpit installer
- Invoke the installer script in the same way as for installation of a previous release, for example
./setup.sh|.cmd joc_install.xml
./setup.sh|.cmd -u joc_install.xml
- Invoke the installer script in the same way as for installation of a previous release, for example
- Start the JOC Cockpit daemon (Linux) or service (Windows)
- Extract the installer archive .tar.gz/.zip file. This will create a sub-directory that includes the maintenance release number, for example
...
- Consider instructions from JS7 - Controller Installation On Premises.
- Take a backup of the Controller instance's installation directory.
- Suspend all orders.
- Stop the Controller:
- Standalone Controller
- Stop the Controller instance's daemon (Linux) or service (Windows).
- Controller Cluster
- Take a note which Controller instance is the active node before stopping Controller instances.
- Stop both Controller instances' daemon (Linux) or service (Windows).
- Stop the Cluster Watch Agent daemon (Linux) or service (Windows) if an Agent is used as a Cluster Watch.
- Standalone Controller
- Automated Upgrade
- Run the Controller Installation Script for Upgrade
- For a Controller Cluster consider to first stop both Controller instances and then to
- run the Controller Installation Script
- for the active and then for the standby Controller instance.
- update the Cluster Watch Agent as explained below and start the Cluster Watch Agent if an Agent is used as a Cluster Watch. This step is not performed if JOC Cockpit is used as a Cluster Watch.
- Manual Upgrade
- Extract the installer archive .tar.gz/.zip file from a neutral directory not related to the current Controller installation. This will create a sub-directory that includes the maintenance release number, for example
controller.2.2.2
.Stop the Controller.Standalone Controller - Stop the Controller instance.
- Controller Cluster
- Take a note which Controller instance is the active node when stopping Controller instances.
- Stop both Controller instances.
- Stop the Cluster Watch Agent.
- Extract the installer archive .tar.gz/.zip file from a neutral directory not related to the current Controller installation. This will create a sub-directory that includes the maintenance release number, for example
- From the existing Controller installation directory move or remove the
lib
directory. - Copy the
lib
andbin
sub-directories from the extracted installer archive to the Controller instance's installation directory. This will replace the previouslib
sub-directory and will overwrite the existingbin
sub-directory from the new release. The Controller's instance start script that can contain individual settings, is not included with the installation archive and therefore will not be overwritten, see JS7 - Controller - Command Line Operation. - For a Controller Cluster
- consider to perform this step for both Controller instances.
- update the Cluster Watch Agent as explained below and start the Cluster Watch Agent. This step is not performed if JOC Cockpit is used as a Cluster Watch.
Agent
- Consider instructions from JS7 - Agent Installation On Premises.
- Take a backup of the Agent's installation directory.
- Suspend all orders related to the Agent in question.
- Stop the Agent
- Standalone Agent
- Stop the Agent instance's daemon (Linux) or service (Windows). This can be performed using the Agent's installation scripts.
- Cluster Agent
- Take a note which Director Agent instance is the active node before stopping Agent instances.
- Stop the Primary and Secondary Director Agent instance's daemon (Linux) or service (Windows).
- Standalone Agent
- Automated Upgrade
- Run the Controller Agent Installation Script for Upgrade
- For an Agent Cluster run the Agent Installation Script for the active and then for the standby Director Agent instance.
- Manual Upgrade
- Extract the installer archive .tar.gz/.zip file from a neutral directory not related to the current Agent installation. This will create a sub-directory that includes the maintenance release number, for example
agent.2.2.2
.Stop the Agent. - From the existing Agent installation directory move or remove the
lib
directory. - Copy the
lib
andbin
sub-directories from the extracted installer archive to the Agent's installation directory. This will replace the previouslib
sub-directory and will overwrite the existingbin
sub-directory from the new release. The Agent's instance start script that can contain individual settings is not included with the installer archive and therefore will not be overwritten, see JS7 - Controller - Agent Command Line Operation. - For an Agent Cluster consider performing this step for all Agent instances in the cluster.
- Extract the installer archive .tar.gz/.zip file from a neutral directory not related to the current Agent installation. This will create a sub-directory that includes the maintenance release number, for example
- Start the Agent.
- Resume orders for the related Agent.
...
Overview
Content Tools