C2NET Service Builder

Table of contents

• Introduction
• A short description
• Configuration
• Other scritps

Introduction

The C2NET Service Builder script is a tool that creates a C2NET service bundle(s) by means of a configuration file.
It makes it easier to create a service bundle with different versions and from different sources, such as local folders where own developments are located.

A short description

The service-builder.sh script takes one mandatory parameter, which points to the configuration file:

Usage: service-builder.sh config-file 
    config-file      File containing service parameters and other of general use.

Configuration

The file config-file file loads all the configurable parameters to execute the service-builder.sh script. The file has three sections:

1. Component Configuration
2. Service Configuration
3. Other Configuration Options

Component Configuration Parameters

In this section the component configuration parameters are defined. You can configure the script to obtain the component codes from different sources as follows:

1. -source=ftp:
   It will download the file from FTP server. The parameter -ftp-bundle is mandatory to define the file name.
   The FTP configuration is defined in the FTP_PARAMETERS section.

2. -source=git:
   Clone the project containing a component from the GIT default server. The parameter -git-branch or -git-tag. are mandatory.
   The path inside the GIT is defined in -git-path parameter inside DEFAULT COMPONENT CONFIGURATION PARAMETERS option. The FTP configuration is defined in the FTP_PARAMETERS section.

3. -source=file:
   Use a bundle file from the local file system. A parameter -file-path is mandatory, which must be the path to the component file.

4. -source=folder:
   Use a folder from the local file system. A parameter -folder-path is mandatory, which defines the path to the component folder. In this case, there must exists a script component-builder-script.sh, which will be launched to create the bundle.
   This option should be opted when combining own developments with already built bundles.

5. -skip:
   Use this option if you want to skip including the component in the service.
   

This message will be also shown if parameter validation fails:

Usage: COMPONENT= -source=[git|folder|ftp|file] [-git-tag=] [-git-branch=] [-ftp-bundle=] [-folder-path=] [-file-path=]"
  -source=        Method to get the component from. Must be one of following:
      ftp             Get bundle from FTP. Requires '-ftp-bundle'
      git             Get bundle from GIT. Requires '-git-path'  and '-git-branch|-git-tag'
      file            Get bundle from a local file. Requires '-file-path'
      folder          Get component source code from local folder. Requires '-folder-path'
  -ftp-bundle     Bundle file name
  -git-tag        Tag in the GIT repository
  -git-branch     Branch in the GIT repository
  -git-path       Path in the GIT repository
  -folder-path    Path to the component folder
  -file-path      Path to the component bundle file
  -skip           Skips the component in the service.

Examples

This instruction will obtain a bundle from the FTP Server (configured in config-file) bundle file JOBS-0_0_9-ITI.zip with default master branch:

JOBS="-source=ftp -ftp-bundle=JOBS-0_0_9-ITI.zip"

If you are developing, it is interesting that you specify your work folder, in this case the script will execute the COMPONENT_BUILDER_SCRIPT which usually is component-builder-script.sh:

JOBS="-source=folder -folder-path=/home/user/projects/c2net/development/opensourceprojects.eu.git/c2net-cpl-paas4man-jex-jobs-code"

The service and deployment manifests are also handled with same principle, as a git project in OPS:

C2NET_SERVICE="-source=git -git-path=git/p/c2net/service -git-branch=integration"

Or if you make modifications to the manifests, you can specify a folder location:

C2NET_SERVICE="-source=folder -folder-path=/home/user/projects/c2net/development/c2net-service"

Example of not using a component with -skip option. REMEMBER: you'll need to modify the service/deployment manifests to not to include this component, or validation will fail.

  JOBS=" -skip "

For a full example of all components take a look into the config-file example included in this project, where the latest versions are used.

Service Configuration Parameters

You can configure to obtain the manifests from the git or from a folder in your local file system.
For simplicity, options -source=file and -source=bundle are not available for building the service, but it should be straightforward to unzip these manifests and use the option -source=folder instead

The service must have a specific folder structure:

        ├── deployment
        │   └── Manifest.json
        └── service
            └── Manifest.json

In this section, the Service Configuration Parameters are:

1. C2NET_SERVICE:
   The service is obtained in the same way as if it were a component,
   with the exception of executing any script if -source=folder is chosen.

2. COMPONENT_BUILDER_SCRIPT:
   Defines the name of the script to be executed when building the components, which is component-builder-script.sh by default.

3. RESOURCES:
   This boolean variable defines if the resources domain and volumes zip files are to be created.

4. ONE_BUNDLE:
   To generate a single bundle.

Input/Output Configuration Parameters

Other parameters which can be modified are:

1. ADMISSION_URL:
   Admission url to register/deploy the services.

2. OPS_PARAMETERS
   C2NET GIT default parameters, you can modify to adjust to your configuration.

3. FTP_PARAMETERS
   C2NET FTP Default server parameters.

4. LOCAL_FOLDERS
   These parameters enable you to change folders.

Other Utility Scripts

Along with the service-builder.sh, additional utility scripts have been created:

1. scripts/util/show-component-versions.sh
   Show component versions from the bundles which are in /bundles folder. To do it, unzips the bundles and extracts from the Manifest.json the name of the component

2. scripts/admission/register-bundles.sh
   Register the .zip bundles which are in /bundles folder AND those in the list of components in /bundles/manifests/service-VERSION.zip. To do the filtering, it will unzip the bundle to extract the name of the component, as well as the list of components form the service manifest.

3. scripts/admission/register-service.sh
   Register the service which service-builder.sh has created in /bundles/manifests/service-VERSION.zip

4. scripts/admission/deploy-service.sh
   Deploy the service which service-builder.sh has created in /bundles/manifests/deployment-VERSION.zip

5. scripts/admission/register-bundle.sh
   Register a single bundle from /bundles

6. scripts/admission/send-bundle2host.sh
   Register/deploys a bundle into the ADMISSION_URL.
   

7. scripts/build-register-deploy.sh

This script perform all needed tasks:

• Build the Service

  ./service-builder.sh config-file
  

• Register Component Bundles, previously downloaded/built:

  ./admission/register-bundles.sh
  

• Register UCP Domain:

  ./admission/register-bundles.sh

• Register PubSub Domain

  ./admission/vhosts/deploy-dataservice.sh

• Register Persistent Volume

  ./admission/volumes/register-acs-volume.sh

• Register Service Manifest

  ./admission/register-service.sh

• Deploy Service

  ./admission/deploy-service.sh