Installing CloudBees Analytics to an existing CloudBees CI on traditional platforms environment

14 minute read

Installations of CloudBees CI on traditional platforms can take advantage of the analytics capabilities of CloudBees Software Delivery Automation.

Follow these steps in the order listed to complete the installation:

  1. Review the Pre-installation requirements

  2. Upgrade CloudBees CI on traditional platforms to version 2.263.4.2

  3. Install CloudBees Analytics prerequisites

  4. Install CloudBees Analytics

Pre-installation requirements

Before starting the installation process, do the following:

  • Contact CloudBees Support to obtain the executable files for the CloudBees CD/RO and CloudBees Analytics installers.

  • Review the CloudBees CI on traditional platforms + CloudBees Analytics architecture details to become familiar with CloudBees CI and CloudBees Software Delivery Automation concepts and terminology.

Upgrading CloudBees CI on traditional platforms

This guide describes the upgrade process for CloudBees CI on traditional platforms. CloudBees recommends that you always upgrade to the latest version of your CloudBees product, ensuring wider lifecycle support coverage, plus more security patches added via the CloudBees Security Advisory, resolved issues, and new features.

  • For client controllers that are connected to the operations center:

    • The operations center must be upgraded first, and then client controllers can be upgraded.

    • The client controller connected to the operations center does not have to be at the same version as the operations center. The operations center version must always be more recent or as old as the version of the client controllers that are connected to the operations center (operations center >= client controller version). CloudBees supports upgrading CloudBees CI to a version up to one year later than your current version.

      For more information, refer to Version skew between the operations center and controllers.

  • Java 11 is recommended for your CloudBees CI instance, the operations center, controllers, and all agents starting with version 2.332.1.4.

CloudBees strongly recommends that you upgrade your CloudBees CI on traditional platforms instances that are not already running Java 11 as soon as possible. The ability to run new versions of the product on Java 8 will be removed in an upcoming future release. Releases that occurred during the support window for Java 8 will continue to run on Java 8.

As a best practice, CloudBees recommends that you upgrade the operations center first. Then, you should upgrade any agents and controllers at the same time. If you use any customized pod templates in your environment, make sure they are also running Java 11.

Preparing for the upgrade

Before upgrading, CloudBees recommends that you complete the following steps to prepare for the upgrade.

  1. Review the best practices for upgrading.

  2. Generate a support bundle.

  3. Enable the CloudBees Assurance Program.

  4. Back up your instance.

  5. Create a test environment.

  6. Install the Health Advisor by CloudBees plugin to your controllers.

  7. Install the CloudBees Quiet Start plugin to your controllers.

Best practices when upgrading

When upgrading, CloudBees highly recommends the following best practices.

  • Change one thing at a time: Limit the changes you make to one area at a time. For example, do not plan to make infrastructure changes such as hardware upgrades, networking changes, or OS package upgrades when upgrading. This helps to identify and isolate the root cause of any issues you encounter.

  • Upgrade the instance where it is running: Upgrade your instance in the same location where it is currently running, even for production environments.

    CloudBees does not recommend that you keep two different production instances running at the same time. This may be done to avoid downtime while performing the upgrade. However, unless you really know what you are doing, it is very difficult to replicate the exact same environment. For example:

    • The inbound agent does not work correctly as the $JENKINS_URL because the location is different.

    • Credentials may fail if the secret is not the same for both instances.

    • The OS may not be configured in the same way. For example, ulimit.

    • The CloudBees CI configuration may not be correctly replicated.

  • Upgrade the CAS plugin at the same time as the instance: If you are using the CAS plugin and upgrading to version 2.277.1.2 or later, do not upgrade it using the Plugin Manager. It must be upgraded at the same time as the instance. Once the service is stopped, you must download the CAS plugin and manually replace $JENKINS_HOME/plugins/cas-plugin.jpi.

  • Stop using the Maven plugin: The Maven Integration plugin is not recommended because it is considered unreliable by the Jenkins Community. CloudBees recommends that you migrate jobs using the Maven Integration plugin to Pipeline Jobs using the Pipeline Maven Integration plugin. If you are able to migrate your jobs, please carefully read the Maven jobs and Java versions compatibility guide.

    End-of-life announcement

    CloudBees has determined that this plugin will be removed from the CloudBees Assurance Program (CAP) in late 2022. Notification will be provided prior to the removal of the plugin. Please contact CloudBees Support if you have any concerns or questions.

Generating a support bundle

Before upgrading, CloudBees recommends generating a support bundle. It can help you troubleshoot problems with the upgrade and determine which plugins were upgraded in the process.

Enabling the CloudBees Assurance Program

Before upgrading, CloudBees recommends that you enable the CloudBees Assurance Program (CAP) to ensure you are upgrading to plugin versions that are tested by CAP, to avoid plugin dependency issues and prevent incorrect versions from being installed.

To enable CAP and upgrade your plugins:

  1. Navigate to Manage Jenkins  Beekeeper Upgrade Assistant  CAP Configuration.

  2. Verify that Enroll this instance in the CloudBees Assurance Program is selected.

  3. Verify that Allow automatic upgrades of plugins on restart is selected.

  4. Select Save.

Backing up your instance

Before upgrading, CloudBees recommends taking regular backups of your $JENKINS_HOME directory for the operations center and all controllers. The backups should be stored at an offsite location such as cloud storage or, at a minimum, on separate hardware from CloudBees CI.

To back up your instance:

  1. Back up the operations center and all controllers. CloudBees recommends using the CloudBees Backup plugin to automate the backup process. For more information, refer to Configure backups using the CloudBees Backup plugin.

    • You can also perform a minimal backup by making a copy of your $JENKINS_HOME directory for the operations center and all controllers. If the $BUILD_DIRECTORY is not located in the default location within the $JENKINS_HOME directory, you must back it up as well. If something unexpected occurs, the rollback process is based on the backup of your instance. For more information, refer to Back up $JENKINS_HOME manually.

    • Controllers that have the CloudBees Backup plugin 3.38 or later installed support the Restore job type. The operations center does not have a restore option, so to restore the operations center when using CloudBees Software Delivery Automation, you can follow the steps for Restore backup files manually.

  2. Test the backup to verify it is valid. The backup is used to recover from a failure if you encounter a severe issue during the production upgrade.

    After an upgrade of the Jenkins core version or plugins, you cannot directly downgrade the war file and plugins. The only way to roll back is to restore the $JENKINS_HOME backup.

  3. Validate the integrity of the backup by extracting the backup to another filesystem and verifying the checksums using:

    find $JENKINS_HOME -type f | sort | xargs md5sum >~/checksum.log.backup
    ▼

    Run this for both the live and backup data, and compare the checksum.log.* between the two.

Creating a test environment

Before upgrading, CloudBees recommends creating a separate test environment that has a similar setup as your production environment with representative jobs. This is ideally a full test environment with the operations center and client controllers and requires a test license. If this is not feasible, using a test controller with representative jobs is sufficient.

If you are creating a test environment and require a license, please send the instance ID for your test instance to CloudBees Support, and CloudBees will send you a test instance license. While you are waiting for the permanent license, you can use the Request a trial license button in the CloudBees Software Delivery Automation UI, as long as your instance has internet access and can connect to the CloudBees License Registry.
Creating jobs on your test controller

Create jobs on your test controller that are representative of jobs on your production controller. This allows you to test the upgrade using the key plugins for your workflow and interactions with any external systems such as SCM tools, artifact repositories, bug trackers, and cloud automation. This test environment can also be useful after the upgrade to test the installation of new plugins.

It is a best practice to create jobs that are a subset of representative jobs on the test cluster. These dedicated jobs represent your production jobs, but without using real data. CloudBees recommends talking to your development groups to find jobs that cover the primary functionality, such as:

  • Testing your end-to-end complex Pipeline jobs.

  • Testing jobs that utilize critical plugins.

  • Running jobs that are part of integrations.

  • Running jobs that are for specific technologies.

    To clone a production controller to a test controller, follow the steps from Migration Guide: CloudBees CI, specifically the section titled, Case B - Migrate Entire Jenkins Configuration, Including Jobs.
Running the test jobs

Once you have created the jobs, you can run them on your test controller.

To run test jobs:

  1. Update the test configuration for some representative jobs, so they do not collide with your production jobs.

  2. Run the test jobs to ensure they work correctly in the upgraded test instance. You must recreate credentials on your test instance.

Upgrading your plugins in the test environment

CloudBees recommends upgrading the plugins in your test environment. After upgrading the plugins, you can run tests to ensure the upgraded plugins are functioning as expected.

Installing the Health Advisor by CloudBees plugin to controllers

Before upgrading your controllers, CloudBees recommends installing the Health Advisor by CloudBees plugin, if it is not already installed. The Health Advisor by CloudBees automatically identifies issues that could impact the performance, stability, and security of your controllers. It also identifies potential issues due to known issues on your controllers. You are notified via email when a new problem is found and the email includes links to the solutions for the identified issues. For instructions, refer to Health Advisor by CloudBees plugin.

Installing the CloudBees Quiet Start plugin to controllers

Before upgrading, CloudBees recommends installing the CloudBees Quiet Start plugin, if it is not already installed. The Quiet Start plugin ensures that builds do not start automatically when the instance first comes online after the upgrade.

Upgrading the operations center and controllers

Once you have upgraded your test environment and verified it is functioning as expected, you can perform the upgrade in your production environment.

If you are using the High Availability (HA) feature, the general process for upgrading the HA operations center or any HA controller is:

  1. Stop both HA nodes.

  2. Upgrade both HA nodes.

  3. Start one of the HA nodes and wait for it to come fully online.

  4. Upgrade the plugins according to CAP recommendations and restart.

  5. Start the other HA node.

To upgrade the operations center and controllers:

  1. Enable Quiet Restart to ensure that builds do not start automatically when the instance first comes online after the upgrade. Navigate to Manage Jenkins  Quiet Restart and select Stay in “quieting down” state when restarted.

  2. Verify all running builds are complete. Navigate to Manage Jenkins  Prepare for Shutdown and wait for any running builds to complete before you upgrade a controller.

  3. Take another backup of your instance.

  4. Upgrade the plugins and restart your controller immediately before you start the upgrade process.

  5. Visit the downloads page, select your desired distribution type, and complete the instructions:

    Java WAR file

    If your CloudBees CI instance is run with the command java -jar cloudbees-core-cm.war or java -jar cloudbees-core-oc.war, you can simply replace the jenkins.war file with the latest version.

    Ubuntu/Debian

    • Operations center: apt-get update && apt-get install cloudbees-core-oc

    • Controller: apt-get update && apt-get install cloudbees-core-cm

    Red Hat/CentOS

    The CloudBees CI on traditional platforms RPM installation package requires systemd. The majority of Linux distributions have adopted systemd, but if you attempt to use the RPM package to install CloudBees CI on traditional platforms on a Linux distribution that does not support systemd, the installation will appear to be successful, however the service will not be able to start.

    Beginning in CloudBees CI version 2.319.1.5, the epel-release package is required to upgrade CloudBees CI on traditional platforms using an RPM, however some CentOS distributions do not include it. For these CentOS distributions, run the following command before you begin the installation procedure: sudo yum install epel-release.

    • Operations center: yum upgrade cloudbees-core-oc

    • Controller: yum upgrade cloudbees-core-cm

    RPM/YUM with High Availability (HA): The RPM package contains a post-installation script to ensure ownership on several files including $JENKINS_HOME. If HA is configured, I/O errors can occur. For example, when upgrading one node while another node is still running. For more information, refer to JENKINS-23273.

    To address this issue, you can skip this script by adding the property JENKINS_INSTALL_SKIP_CHOWN="true" under /etc/sysconfig/jenkins.
    OpenSUSE/SUSE Linux

    The CloudBees CI on traditional platforms RPM installation package requires systemd. The majority of Linux distributions have adopted systemd, but if you attempt to use the RPM package to install CloudBees CI on traditional platforms on a Linux distribution that does not support systemd, the installation will appear to be successful, however the service will not be able to start.

    • Operations center: zypper install cloudbees-core-oc

    • Controller: zypper install cloudbees-core-cm

    Microsoft Windows

    To upgrade on Microsoft Windows servers, a new .zip file must be downloaded from the downloads page and installed.

    Servlet container

    Once a .war archive has been downloaded, follow the servlet container’s existing application deployment process.

    When using servlet containers, CloudBees CI sets the $JENKINS_HOME to the $APP_SERVER_USER/.jenkins/ folder. If the servlet container installation does not include write permissions to this folder for this user, which is sometimes done for security purposes, you must either grant appropriate permissions or override this setting by adding the -DJENKINS_HOME=$MY_JENKINSPATH argument in your servlet container startup. Refer to the servlet container’s documentation for how to add startup arguments.

    Tomcat

    Use environment variable CATALINA_OPTS to add:

    • -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true.

    • -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true which is needed for the Blue Ocean plugin.

    CloudBees recommends that you configure it in the script $CATALINA_BASE/bin/setenv.sh (Linux) or %CATALINA_BASE%\bin\setenv.bat (Microsoft Windows) that you will create to customize your application server.

    Custom container installations

    If you use a custom container, you can locate the cloudbees-core-oc.war or cloudbees-core-cm.war file in the deploy directory of your container. For example, /usr/local/jboss/server/default/deploy/cloudbees-core-cm.war is the location for a default JBoss installation.

  6. After your controllers are upgraded, you must manually upgrade the agent.jar file for any inbound agents that are not configured to upgrade the agent.jar file automatically. For more information, refer to Windows agent offline or unable to connect.

  7. Upgrade the plugins in your production environment again.

  8. Now that you are running the latest version of CloudBees CI and your plugins have been upgraded, CloudBees recommends you enable actionable build notifications in GitHub, Bitbucket, and Slack. This generally takes a few minutes and provides enhanced notifications for your developers with no Pipeline changes required. For more information, refer to Enabling actionable build notifications in GitHub and Bitbucket and Setting up actionable build notifications in Slack.

  9. Review articles in our Best Practices and apply changes accordingly.

Installing CloudBees Analytics prerequisites

The next step is to install the prerequisites for CloudBees Analytics, which include the CloudBees CD/RO server, a webserver, a local agent, and a MariaDB database.

The artifact repository is not installed. Also, when installing the CloudBees CD/RO server, the CloudBees CD/RO plugins are not installed.

Use the steps in this section to install the prerequisite CloudBees Software Delivery Automation components needed for CloudBees Analytics. Review Before You Install CloudBees Software Delivery Automation before performing this procedure.

  1. (Linux only) Enter the following command to make the installer file executable:

    chmod +x ./CloudBeesFlow-<version>
    ▼

  2. Do one of the following to start the installation:

    • For Linux with root or sudo privileges or for Windows installations, double-click the installer file.

    • For Linux non-root/non-sudo installations, on a command line enter:

      ./CloudBeesFlow-<version> --nonRoot
      ▼

      For this installation type, a warning about automatic server start-up with non-root/non-sudo installations appears. Click Yes to dismiss the warning.

      The installation wizard welcome screen displays.

  3. The following prompts appear:

    1. Input y for the following prompt:

      Invoked CloudBees Software Delivery Automation installer process.  Continue? [n/Y] y
      ▼

    2. Input SDA for the following prompt:

      Specify the type of setup you would like to perform: expressServer, expressAgent, SDA or advanced [expressServer]. SDA
      ▼

  4. Select one of the following:

    • Install CloudBees Analytics prerequisites with built-in database: This option installs the built-in database, MariaDB, for use by the CloudBees Software Delivery Automation server.

      For standalone installations of CloudBees Analytics, you must use this option and complete the installation with the built-in database. For this type of installation, clustered environments are not supported.

    • Install CloudBees Analytics prerequisites without built-in database: This option requires an enterprise license to integrate, and you must manually configure an external database after installation during CloudBees Software Delivery Automation server startup.

      For clustered CloudBees Software Delivery Automation environments, you must use this option to install an external database, which requires an enterprise license.

Select Next to continue. The Directories screen appears. . Review Install directory and Data directory default locations; select Browse to specify different directory locations. Click Next to continue. The Server service account screen appears.

  1. Select the appropriate step for your platform and complete the information for the server service account.

    • Windows:

      • User Name: Enter the name of the user who will run the CloudBees Software Delivery Automation server, web server, and repository server services.

      • Password: Enter the password of the user who will run the CloudBees Software Delivery Automation server, web server, and repository server services.

      • Domain: Enter the domain name information for the user. Leave this field blank if this is a local user.

      • Use the local system account: Select this check box if you want the CloudBees Software Delivery Automation server, repository server, and web server services to run as the local Windows system account.

      • Use the same account for the agent service: Select this check box if you want the agent on the CloudBees Software Delivery Automation server machine to run as the same account.

        For security reasons in production environments, CloudBees recommends using a separate account for the agent service because the server account has permission to read the key file located here:

    • Linux: installation-directory/conf/passkey

    • Windows: installation-directory\conf\passkey

      The key file is used to decrypt passwords stored in CloudBees Software Delivery Automation. Using a different account for the agent service ensures that a process running on the agent cannot gain access to the key file.

    • Linux:

      • User Name: Enter the name of the user who owns the CloudBees Software Delivery Automation server, repository server, and web server processes.

      • Group Name: Enter the name of the group who owns the CloudBees Software Delivery Automation server, repository server, and web server processes.

      • Use the same account for the agent service: Select this check box if you want the agent on the CloudBees Software Delivery Automation server machine to run as the same account.

      Click Next to continue. The Agent Service Account screen appears.

    If you selected the Use the same account for the agent service check box on the previous screen, you will not see this screen.

  2. Select the appropriate step for your platform and complete the information for the agent service account.

    • Windows:

      • User Name: Enter the name of the user who will run the CloudBees Software Delivery Automation agent service.

        The user that the agent runs as must have permission to write to the $INSTALL_DIRECTORY/log directory.

      • Password: Enter the password of the user who will run the CloudBees Software Delivery Automation agent service.

      • Domain: Enter the domain name information for the user. For example, electric-cloud.com. Leave this field blank if this is a local user.

      • Use the local system account: Select this check box if you want the CloudBees Software Delivery Automation agent service to run as the local Windows system account.

        The local system account does not have access to network shares.

    • Linux:

      • User Name: Use this field to enter the name of the user who owns the CloudBees Software Delivery Automation agent process.

        The user/group that the agent runs as must have permission to write to the $INSTALL_DIRECTORY/log directory. If you specify root, click Yes when the following confirmation appears:

      • Group Name: Use this field to enter the name of the group that owns the CloudBees Software Delivery Automation agent process.

    Click Next to continue. The Ready to Install screen appears.

  3. Review the default settings and your service account selections. Use the Back button to change your service account selections if necessary.

  4. Review Send user data information. When checked, anonymized, aggregated usage information is sent to CloudBees. Uncheck if you do not want to participate. Click Next to continue.

    The installer displays a status bar to show the progress of the installation, which can take fifteen minutes. When the install process is complete, the Install Wizard Complete screen appears.

    The CloudBees Software Delivery Automation server automatically starts when the installation is complete.

  5. Select the Launch a web browser to login to CloudBees Software Delivery Automation check box if you want CloudBees Software Delivery Automation to open the login screen after installation is complete.

  6. Click Finish to close the wizard.

  7. For non-root/non-sudo Linux installations, configure autostart for the CloudBees Software Delivery Automation services.

    For instructions, see Configuring autostart services for non-root/non-sudo Linux installations.

If you opted for installation without the built-in database, when the CloudBees Software Delivery Automation server starts, you are prompted on the sign-in page to configure an external database. For help configuring an external database, refer to Configure an external database.

Installing CloudBees Analytics

The next step is to install CloudBees Analytics on a separate server.

Start the installation by following the steps for using the CloudBees Analytics UI installer.

Add CloudBees Analytics to existing CloudBees CI on modern cloud platforms