Using ConfigMaps to access the configuration files

The BMC Helix Innovation Suite container installs BMC Helix Innovation Suite and Service Management applications in your on-premises environment by using the Jenkins pipeline. The Jenkins pipeline runs various deployment pipelines and configures the BMC Helix Innovation Suite and applications. If you want to update the configuration files anytime after you successfully deploy the container, you can use ConfigMaps.

In the BMC Helix Innovation Suite containerized environment, you cannot access the configuration files directly. As a system administrator, you can use a ConfigMap to access and make changes to a configuration file in the system. The configuration files are stored in the configmapfiles folder in the helm directory on your server. You can update the logging files by using configmaps, for example logback_server.xml files and log4j files. You can update the configurations for all the pods running in your namespace by updating a single ConfigMap file.

Before you begin

Perform the following steps to checkout and clone the Helm Repository to your server:

1. Navigate to the directory where you want to clone the Helm Repository. For example, cd/tmp.

2. Clone the directory to a folder named containerization-certified.git by using the following command:

   git clone git@<jenkinsServer>:/<GITREPO_PATH>HELM_REPO/containerization-certified.git/

   A containerization-certified folder is created in the directory.

3. Navigate to the clone directory:

   cd containerization-certified

4. Run the following command to view the files:
   

   git checkout tags/<TARGET_VERSION>

   where <TARGET_VERSION> is the version from the HELIX_ONPREM_DEPLOYMENT pipeline.

   You can see the kubernetes folder in the containerization-certified folder.

Example: To update logback_server.xml file by using a ConfigMap

As an example, perform the following steps to update a parameter in the logback_server.xml file: 

1. In the containerization-certified folder, navigate to kubernetes/helm/staging/configmapfiles folder.
   The following folders are present in the configmapfiles folder:
   
   • ars/opt/extconfig
   • certs/opt/extconfig
   • midtier/opt/extconfig
   • smartit/opt/extconfig
   • smartreporting/opt/extconfig
     
     
2. In the ars folder, navigate to the opt/extconfig/logback_server.xml file. 
   
   
3. In the logback_server.xml file, edit the required parameter and save the file.
   
   
   

4. Edit the respective deploy.sh file for the component for which you have updated the parameter.
   In this example, navigate to kubernetes/helm/platform folder and open the deploy.sh file.
   
   

5. From the deploy.sh file, copy the following command with the namespace and staging path values:

   kubectl create configmap --namespace $NAMESPACE platform-extconfig --from-file=$STAGINGPATH/configmapfiles/ars/opt/extconfig --dry-run -o yaml | kubectl apply -f -

   Parameter name	Value
   $NAMESPACE	Namespace containing the pods.
   $STAGINGPATH	Path to the helm charts where the configmapfiles are stored. For example, kubernetes/helm/staging

6. After you update the values of $NAMESPACE and $STAGINGPATH parameters, run the command. 
   For example: 
   

   kubectl create configmap --namespace ABC platform-extconfig --from-file=kubernetes/helm/staging/configmapfiles/ars/opt/extconfig --dry-run -o yaml | kubectl apply -f -

7. Upload the changes to your server by performing the following steps:

   1. Navigate to the checkout directory from the Step 1 of the Before you begin section:

      cd /<Checkout DIR>/containerization-certified

   2. Run the following commands to push the changes to the server:

      ##Adding Changes for checkin
      git add -A
      git commit -am "Modifying Helm"
      
      ##Locally removing tag
      git tag -d <TARGET VERSION>
      
      
      ##Locally adding the tag
      git tag <TARGET VERSION>
      
      
      ##Deleting tag form GIT server
      git push origin :<TARGET VERSION>
      
      
      ##Pushing the tag in GIT server
      git push origin <TARGET VERSION>

      The configuration values get updated in the container.