Docs menu
MENU

Jenkins Auto-Configuration via Add-On

01 With an aim to help you to get the best usage experience and achieve the maximum possible automation of the DevOps approach at the platform, below we’ll reveal how the process of Jenkins CI server configuration can be greatly simplified.

To accomplish this, we’ll leverage a new solution, implemented by combining two progressive technologies: the pluggable add-ons and Cloud Scripting operations - the next generation mechanism for application and server management within the Cloud. In particular, such an integration allows to automatically create the complete list of job templates, which just need to be slightly tuned (with operations like setting a URL to the repository with the required project instead of the default one) to complete the Jenkins server adjustment.

02

The true efficiency of such an implementation is fully revealed in case of handling multiple projects, as instead of the countless step-by-step manual configurations, required for each of the Jenkins servers to be properly set, you’ll need to create a single add-on just once.

Subsequently, it can be easily applied to the required environment in a few clicks with just several user-dependent parameters needed to be adjusted, saving an increasing amount time on each following installation.

Configuring Jenkins using Cloud Scripting

To designate the greatest part of the Jenkins server’s setting up to be performed automatically, the appropriate configurations should be written in a form of code lines firstly. Subsequently, they will be executed at your application server with Jenkins running. This could be done through preparing a special JSON manifest file, which, being integrated to the platform, will represent a pluggable add-on, that can be easily run by any user directly through the dashboard.

Note: Before proceeding further, please ensure you have the appropriate pre-configurations already accomplished at your PaaS installation (i.e., dedicated user groups and installed Jenkins CI server).

So, in order to obtain a proper Jenkins configuration template for the multiple projects delivery via DevOps pipeline, you’ll require to perform the following steps:

Creating Add-On

Let’s start with composing the basis for our add-on in order to get the ability to apply it to the required environment further:

1. Log into your admin panel as an administrator user and navigate to the Marketplace section using the main menu to the left.

03

Once inside, expand the Add list at the top pane and select the Add-on option.

2. Within the opened editor, paste the general code template of the following structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
    "jpsType": "update",
    "jpsVersion": "0.3",
    "application": {
   	 "name": "package_name",
   	 "logo": "logo_url",
   	 "type": "java",
   	 "onInstall": {
   		 "executeShellCommands": {
   			 "nodeType": "tomcat7",
   			 "commands": [
   					 custom_code
   			 ]
   		 }
   	 }
    }
}

The highlighted parameters should be substituted with the appropriate data - here you need to define the general information about your package and specify the operations it is intended to perform:

  • package_name - add-on name it will be titled with at users' dashboard (e.g., Jenkins Configurations)
  • logo_url - link to the image that will be used as a package icon (you can use our default one through copying and specifying this URL)
  • custom_code - list of comma-separated shell commands, that will be run on add-on’s appliance

Whilst the first two settings are obvious, the last one needs to be considered in details, thus the next section of the guide is devoted to delving into the specifics of the required operations' scripting.

Composing Script

In our example, the Jenkins integration tool is installed over Tomcat 7, so all the commands used would be based on its specifications. We intend to automate the process through scripting the following operations:

  • uploading the scripts, required for setting Jenkins jobs
  • configuring Jenkins itself
  • creating and linking jobs to automatically lead an application through the lifecycle

Further, we’ll examine each of these points in more detail and prepare the core of our manifest according to this flow.

Tip: Below we provide you with the example code, which needs to be modified according to the specifics of your application. In order to ensure this was done correctly and all of the actions were scripted properly, we recommend a preliminary test of your code.

This could be done through adding a separate environment with the same topology your add-on is being created for (i.e., Tomcat 7 with Jenkins app deployed in our case) and running the adjusted below described commands directly inside your compute node’s container using SSH. If you need any assistance with this, please refer to the complete guidance on the DevOps Add-on for Jenkins Troubleshooting, which additionally includes descriptions of the expected results for each of the presented operations.

So, let’s reveal how the above suggested processes can be easily accomplished, with the help of the appropriate Cloud Scripting options. Subsequently, all of them need to be inserted instead of the custom_code parameter in the manifest example, in the same order they are described below.

1. In the first piece of code, we create a dedicated projects' folder and fill it with the files, required for the further Jenkins jobs setting:

1
2
3
4
5
6
7

"mkdir /opt/tomcat/demo",
"cd /opt/tomcat/demo",
"echo ENV_NAME= > /opt/tomcat/demo/variables",
"curl -fsSL file_url -o install.sh",
"curl -fsSL file_url -o transfer.sh",
"curl -fsSL file_url -o migrate.sh",
"curl -fsSL file_url -o runtest.sh",

where:

  • /opt/tomcat/demo - the full path to the folder, where all of your management scripts and the related data will be stored (we’ll use demo, but you could create and use any other desired directory - just don’t forget to specify the correct path everywhere throughout your code)
  • the variables file, created at the 3d string, is intended to be used for further storing of the automatically generated name for your environments
  • curl -fsSL file_url -o file_name - this command initiates scripts uploading inside the container (for the detailed information on the needed scripts preparation, please get acquainted with the corresponding guidance)

2. The second part of code will remove all the existing (i.e., installed automatically during the initial tool deployment) Jenkins plugins in order to prevent incompatibility issues or mismatch of their versions with the upcoming configurations:

1

"rm -rf /opt/tomcat/temp/.jenkins/plugins",

3. After that, you need to move to the main .jenkins directory and add the necessary plugins and configuration files to the Jenkins integrator instead of the deleted ones, by uploading and extracting the appropriate plugins.zip archive.

1
2
3

"cd /opt/tomcat/temp/.jenkins/",
"curl -fsSL file_url -o plugins.zip",
"unzip -o plugins.zip >/dev/null 2>&1",
Tip: We recommend to use the package we’ve prepared for this example, which already contains all the necessary modules. However, you can complement it with other plugins if necessary or just pack your own zip archive - in this case, note that there are several obligatory tools it should comprise (namely: SCM API Plugin, GIT plugin, GIT client plugin, Environment File Plugin) and all of them should be put in the plugins folder inside the archive.

4. The next section of the code uploads and extracts another required package (jobs.zip), that will set Jenkins jobs according to the data inside.

1
2

"curl -fsSL file_url -o jobs.zip",
"unzip -o jobs.zip >/dev/null 2>&1",

The archive structure should be the following:

  • one general jobs folder, which may include multiple directories, named after the appropriate comprised jobs
  • each of such directories should contain the config.xml file (with all the required configs specified inside) and the builds folder with an empty legacyIds file

We’ve already prepared such an archive, which contains settings for creation of the jobs, devoted to each step of the proposed application lifecycle flow:

Create Environment > Build and Deploy > Dev Tests > Migrate to QA > QA Tests > Migrate to Production

Note: In case you are using your custom path to the scripts folder, you need to edit the Build and Deploy job in our example package, as it contains the defined location of the file inside that directory:

1

<filePath>/opt/tomcat/demo/variables</filePath>

Everything else may remain as is; however, you can also edit it or add your own jobs if needed.

5. Finally, define the restart of the server in order to apply all of the executed configs.

1

"sudo /etc/init.d/tomcat restart >/dev/null 2>&1"

Being combined together, all these code parts will automatically perform almost all the required Jenkins configurations.

Thus, now you can place them within the appropriate commands manifest section as it was suggested above - you’ll get something similar to the following:

04

Click Save to finish and append your add-on to the list of the already available installations.

Enabling Add-On

To make our module accessible via the dashboard, find and select it within the list, click on the Publish button above and confirm this action at the shown pop-up.

05

Everything is prepared now, so let’s just see how quick and simple the implementation of our DevOps approach becomes now.

What’s next?