NMaaS
The presented manual is based on the example of the NMaaS project which allows the network operations and engineering community to contribute and construct a portfolio of network management applications that can be easily shared and installed to manage these growing sets of infrastructure. More about NMaaS project can be found here.
1. Bamboo plan.
A dedicated Bamboo plan has been created to launch WS scans of NMaaS components at will.
The name of the plan is nmaas-ws under the gn4-3-wp6-t3-nmaas Bamboo project.
No automated triggers (e.g. either scheduled or push-based) were configured. The plan has to be run manually.
It is worth noting that the scanning process is run within dedicated Docker containers rather than on the Bamboo agents directly. This is a recommended approach.
1.1. Repositories.
The plan uses the same source code repositories as typical plans created for source code integration, Sonar updates or Docker image builds.
1.2. Variables.
On the plan configuration level, a set of variables are defined that can be later on referenced from various tasks executed during the overall WS scan setup and execution process.
In our case, those include apiKey, productToken, projectToken as well as productVersion and projectVersion (for each software component to be scanned within this Bamboo plan, e.g. projectTokenPlatform and projectVersionPlatform for the Platform component).
The first three are the identifiers of the GEANT organization and scanned product or project in the WS system. They are provided by the WS administrators and must be kept secret and plan variables is a good place to store them. The other two indicate the version of the scanned product and project.
Some variables can be later on easily managed for the given software project like the product and project versions that are most likely to be bumped from time to time.
1.3. Stages, jobs and tasks.
The NMaaS software is composed of 3 major software components the Platform, Portal and Janitor. Each of them is scanned separately in a dedicated Job under the Default Stage of the plan.
Each of those jobs follows the same scheme and is composed of 3 tasks.
The following description will base on the Platform scanning job. The other two are configured in a similar matter.
1.3.1. Checking out the source code repository.
The job starts with the execution of a plain Source Code Checkout task in which only the source code repository needs to be provided as a parameter.
1.3.2. Building Docker image.
Next, a Docker task is executed in order to build the Docker container image on which the scanning process will be launched.
The command parameter to be used is Build a Docker image.
A unique name of the image should be given as the Repository parameter together with a Docker registry to be used to store it (e.g. the GÉANT Artifactory).
The desired content of the Dockerfile should be also provided.
The content of the Dockerfile will be slightly different for each software component - in this case, execute permissions had to be granted to gradlew file as well.
In all cases, JRE and curl should be available in the container.
We are copying the software sources to a known directory on the container, in this case: /scan.
We are relying on that some scan configuration files were already added to the sources as the run_ws.sh script.
1.3.3. Running the scan inside the Docker container.
The final task is again a Docker task but this time with the command Run a Docker container.
In the container environment variables sections, a list of environment variables is being defined and assigned values from the previously created Plan variables.
The container is started with the execution of run_ws.sh script in /scan/ws directory.
2. Changes required in the software source code.
In the case of NMaaS, for each of the software components, ws directory was created in the root directory with two files.
The number of created directories depends on the number of components in a given project that needs to be scanned separately.
Typical content of the run_ws.sh script is provided below. Please note the main scanning script (jar) is run with a number of arguments that are obtained from environment variables that are being set based on the Bamboo plan variables mentioned earlier.
#!/bin/sh echo "Downloading Mend agent..." echo "Running Mend scan..." java -jar wss-unified-agent.jar -apiKey ${API_KEY} -projectVersion ${PROJECT_VERSION} -projectToken ${PROJECT_TOKEN} -productVersion ${PRODUCT_VERSION} -productToken ${PRODUCT_TOKEN} -c ws.config -d ../ |
|---|
The ws.config file contains the configuration of the scanning process specific to a particular software component. Below only a few first lines are included. Please note that the variables are left blank and the ones provided from the command line are being used.
############################################################### # Mend Unified-Agent configuration file ############################################################### # GENERAL SCAN MODE: Files and Package Managers ############################################################### # Organization vitals ###################### # TO BE PROVIDED AS COMMAND PARAMETER #apiKey= #userKey is required if Mend administrator has enabled "Enforce user level access" option #userKey= #requesterEmail=user@provider.com #projectName= # TO BE PROVIDED AS COMMAND PARAMETER #projectVersion= # TO BE PROVIDED AS COMMAND PARAMETER #projectToken= #projectTag= key:value #productName= # TO BE PROVIDED AS COMMAND PARAMETER #productVersion= # TO BE PROVIDED AS COMMAND PARAMETER #productToken= … |
|---|
3. Running the Bamboo plan.
With all the above in place, the user can simply run the plan when desired.
