Business Automation

 View Only

Deploying IBM Cloud Pak for Business Automation (CP4BA) Using ArgoCD

By Poojitha Pantani posted Tue November 26, 2024 07:05 PM

  

Co-Authors: Vincent Le, Scott Nguyen, Shubham Gurao.

Abstract

This blog focuses on implementing a production-ready deployment of IBM Cloud Pak for Business Automation (CP4BA) on the OpenShift Container Platform using ArgoCD. By leveraging ArgoCD, a powerful GitOps tool, we streamline the deployment process, ensuring efficiency and automation in continuous delivery. We will explore the key components of ArgoCD, how it works, and provide step-by-step instructions to integrate it into your CP4BA deployment. From generating Kubernetes manifests to creating ArgoCD applications and monitoring deployments, this guide equips you with the knowledge needed to effectively manage your CP4BA environment. The GitOps approach ensures that your deployment remains consistent with the desired state defined in your Git repository, enhancing both reliability and scalability.

Introduction

IBM Cloud Pak for Business Automation helps automate business operations through an integrated platform of automation capabilities. The platform relies on OpenShift Container Platform, which makes it easier to configure, deploy, and manage containerized applications. Designed to support projects of all sizes (small and large), improve employee productivity, and deliver better end-to-end customer journeys while reducing the burden of governing your content and processes. By leveraging automation, it enables you to scale more effectively and accelerate work, driving better results faster.

What is ArgoCD ?

ArgoCD is a declarative continuous delivery tool for Kubernetes and OpenShift, based on the GitOps methodology. It ensures your application's deployment remains consistent with the desired state defined in your Git repository. Unlike traditional continuous delivery tools, ArgoCD can directly pull updated code from Git repositories and deploy it to Kubernetes resources.

How ArgoCD Works

ArgoCD embraces the GitOps model, using Git repositories as the definitive source for defining the desired state of applications. In this blog, we will focus on using plain YAML files, which provide a straightforward and clear method for managing deployments. This approach enables teams to easily version-control their configurations and collaborate efficiently.

ArgoCD automates the deployment of these desired application states across specified environments. It continuously monitors updates to branches, tags, or can be configured to deploy a specific version of manifests from a Git commit. By focusing on YAML files, this article aims to showcase a simple yet effective strategy for managing Kubernetes applications within a GitOps framework.

Setting Up GitOps with ArgoCD for IBM Cloud Pak for Business Automation

Integrating ArgoCD into your CP4BA deployment is essential for effectively managing Kubernetes resources. ArgoCD continuously monitors your Git configuration repository for changes and automatically applies the relevant Kubernetes resources to your cluster. This ensures that your CP4BA environment—encompassing pods, routes, and other components—stays up to date.

To deploy CP4BA using ArgoCD, follow these steps:

Prerequisites:

Step 1: Install ArgoCD:

  1. Install Red Hat OpenShift GitOps from the Operator Hub.

  2. Select Red Hat OpenShift GitOps from the installed operators list and click on the ArgoCD and check whether the status of the instance is available.

  3. Go to Networking → Routes → <instance_name>-server in the project where the ArgoCD instance is installed.

  4. Log in to the ArgoCD user interface.

Step 2: Connect Git Repository to ArgoCD

  1. Access ArgoCD UI: Log in to the ArgoCD user interface.

    • username: admin

    • password: <instance-name>-cluster  secret

  1. Add Your Git Repository: Next, connect your customized Git repository to the ArgoCD instance running in your cluster. In the ArgoCD UI, navigate to Settings → Repositories → + CONNECT REPO.

  2. Add your GitHub repository with the necessary credentials. Once connected, ArgoCD will use the repository contents to create the corresponding resources in the cluster, keeping it in sync with any changes.

Step 3: Adding cluster to AgroCD

In CLI, run the commands to add your cluster .

  1. Login to ArgoCD using CLI

argocd login <Host>

Here, <Host> is the ArgoCD server endpoint. For OpenShift, you can get the host from the route of the <instance-name>-server.

username: admin

password: <instance-name>-cluster secret

  1. Use oc to login to the target cluster oc login

  2. Find the context name to the target cluster

context=$(kubectl config current-context)
  1. Add the cluster to ArgoCD

argocd cluster add $context --name=<cluster name> #cluster name can be arbitrary string 

It is recommended that you set cluster name to something meaningful and readable. Note that ArgoCD will not validate cluster connection until you deploy an app onto it.

  1. Once the cluster is added, you can verify it using

argocd cluster list

The <SERVER> from the output should be used for creating the applications.

  1. To generate a Base64-encoded string for the IBM-entitlement registry:

  • Run the following command, replacing <Insert the credential for IBM entitlement registry> with your IBM entitlement registry.

echo -n '{
  "auths": {
      "cp.icr.io": {
          "username": "cp",
          "password": "<Insert the credential for IBM Entitlement registry >",
          "email": "",
          "auth": ""
      }
  }
}' | base64

Step 4: Creating ArgoCD Applications:

1. Git clone the public CP4BA git repository:
2. Clone the your private git repository:
  • To clone the repository, run the following command:

git clone <repo URL>

Explore the high level of the public git repository folder structure:
Note: The directory structure in the screenshot contains a subset of files for a specific capability (pattern). The manifest files that you generated could contain more or a different subset of files depending on the capability or capabilities that you are deploying.

Review the yaml files in parentapplication and childapplication folder, and modify them accordingly. See below for more detail

  1. ParentApplication:

    • Apply the parentapplication.yaml located in the parentapplication/ directory. This file acts as the central controller and creates all the applications listed in the childapplication/ directory. When the parent application is applied, ArgoCD automatically triggers the deployment of all listed applications.

  • Key parameters in parentapplication.yaml:

    • repoURL: Update this field <repoURL> with your git repo URL where all the manifest files are stored.

    • path: Update this <path> where the child application yaml files are located in the repository.

    • server: Indicates the OpenShift API server where the resources will be deployed. Update this field <SERVER> with your desired OpenShift API server URL. You can get the server info by looking at the output of the “argocd cluster list”

    • targetRevision: Change the <targetRevision> to the branch name associated to your Git repository that contains all the manifests.

  1. ChildApplication:

    • The childapplication.yaml file creates all applications pointing to their corresponding directories and YAML manifest files. Each child application has parameters like repoURL, path, and server to specify where the resources will be deployed.

  • Key parameters in childapplications:

    • repoURL: Update this feild <repoURL> with your git repo URL where all the manifest files are stored.

    • path: Update this <path> where the child application yaml files are located in the repository.

    • server: Indicates the OpenShift API server where the resources will be deployed. Update this field <SERVER> with your desired OpenShift API server URL. You can get the server info by looking at the output of the “argocd cluster list”

    • targetRevision: Change the <targetRevision> to the branch name associated to your Git repository that contains all the manifests.

After making the necessary updates to the parentapplication.yaml and childapplication.yaml files, commit and push the changes to your Git repository.

Step 5: Generate Manifest Files

To deploy CP4BA with ArgoCD clone the branch corresponding to the specific version you wish to use from the following repository: https://github.com/icp4a/cert-kubernetes/. This blog focuses on deploying version 24.0.0-IF002 to your target CP4BA namespace (e.g., cp4ba-project) with a specific capability. Use the cp4a-clusteradmin-setup.sh, cp4a-prerequisites.sh, and cp4a-deployment.sh scripts to generate the required YAML manifests. Customize provided manifests, commit them to your Git repository, and configure ArgoCD to automate deployment and manage updates in your target CP4BA namespace

1. Creating operator-related resources:

Typically the cp4a-clusteradmin-setup.sh script is used to create the necessary Kubernetes resources such as the namespace, IBM Entitlement Key secret, catalog sources, configMaps, operator groups, and install operators. However, running this script is not necessary in this guide. Instead, you can leverage the manifest YAML files directly from the Git repository (https://github.com/icp4a/CP4BA-with-ArgoCD) which you have already copied to your private git repository in step 4.2 above.

These manifest files have already been created to emulate the execution of the cp4a-clusteradmin-setup.sh script and can be applied directly to your OpenShift cluster through ArgoCD.

  • Namespace: Located at cp4ba-manifests/namespace/namespace.yaml. Replace “cp4ba-project” with the namespace where you intend to deploy CP4BA(In this deployment we used “cp4ba-project”).

  • Catalog Sources: Available at cp4ba-manifests/catalogsource/catalog_source.yaml. Replace the “cp4ba-project” namespace placeholder with your target CP4BA namespace for a private catalog.

  • Secrets: The IBM Entitlement Key secret can be found at cp4ba-manifests/secrets/ibm-entilement-key.yaml. Replace the “password” placeholder under .dockerconfigjson with the output generated in step 3.6.

  • ConfigMaps: We provided here cp4ba-manifests/operatorgroup/ibm-cp4ba-common-configmap.yaml. Replace the namespace “cp4ba-project” in the namespace that you created and prepared for the operator.

  • Operator Groups: Found at cp4ba-manifests/operatorgroup/operator_group.yaml. Update the namespace and targetNamespace to the CP4BA project namespace for the ibm-cp4a-operator-catalog-group OperatorGroup

  • Subscriptions: The directory for creating subscriptions is located at cp4ba-manifests/subscriptions/ibm-cp4a-operator-subscription.yaml. Update the sourceNamespace to point to your CP4BA project namespace.

Important: Ensure that the namespace specified in all manifest files matches the namespace you are deploying to. This is crucial for the successful deployment of your CP4BA environment.

Push the configMaps, secrets, and catalog sources, subscription, operatorgroup YAML files into your own Git repository, organized with a clear directory structure. This setup enables ArgoCD to deploy the resources effectively.

2. Navigate to the parent directory:
  • Change to the directory where the parentapplication.yaml file is located:

cd parentapplication/
3. Deploying the Parent Application:
  • Apply the parentapplication.yaml by running the following command

oc apply -f parentapplication.yaml 

  • ArgoCD will automatically create and deploy all the applications listed in the child applications. This means you don’t have to apply each child YAML file manually. The parent application handles the entire process for you, ensuring that all components are deployed in the correct order. Before following step 4, verify if the CP4BA operator and other operators are installed successfully in your OCP cluster. Once the operators are successfully installed follow step 4.

4. Run cp4a-prerequisites.sh

The cp4a-prerequisites.sh script is located here : https://github.com/icp4a/cert-kubernetes/tree/24.0.0-IF002/scripts

The cp4a-prerequisites.sh script has three modes and running this script is necessary in order to generate SQL statement files (scripts) and YAML template files for the secrets based on the selected capabilities.

  • Property Mode: The script in property mode generates the property files (DB/LDAP property files) with default values for database names, users, and schemas. Modify the generated DB/LDAP/user property files to match your infrastructure by adding your specific values for the database server name, database names, schemas, and LDAP details. These property files will be generated based on the capabilities selected while running cp4a-prerequisites.sh script.

  • Generate Mode: In generate mode, the script takes the modified property files and generates the necessary database SQL statement files and YAML templates for secrets based on capabilities . The SQL statement files are used to create the required databases for CP4BA capabilities installation, while the YAML templates define the secrets, ensuring secure access to these databases during the deployment process.

  • Validate Mode: The validate mode checks whether the generated databases and the secrets are correct and ready to use in a CP4BA deployment.

You need to complete all three modes base on this documentation (https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/24.0.0?topic=pycc-recommended-preparing-databases-secrets-your-chosen-capabilities-by-running-script)

After completing the validate mode, copy the generated YAML secrets files from ${PREREQUISITES_FOLDER}/secret_template to the cp4ba-manifests/secrets/ folder.

5. Run cp4a-deployment.sh

Executing this script is essential for preparing the final Custom Resource (CR) needed for deployment. It creates the Custom Resource that defines the configuration for your CP4BA instance. After running the script, copy the generated-cr located in {CUR_DIR}/generated-cr/project/$TARGET_PROJECT_NAME to the cp4ba-manifests/deploycr/ directory. This organization allows for seamless deployment through ArgoCD, facilitating version control and consistent management of your deployment configuration. By placing the final CR manifest in the specified directory, you ensure that all changes are tracked and can be efficiently deployed across environments.

For more detailed information on the execution of the cp4a-deployment.sh script, please refer to the official documentation: https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/24.0.0?topic=cpd-option-1a-recommended-generating-custom-resource-deployment-script

Ensure that the generated secrets YAML files and the final Custom Resource (CR) are pushed to your GitHub repository, where ArgoCD can access them for deployment. After pushing the secrets YAML files and the final Custom Resource (CR) go to the ArgoCD UI, navigate to SYNC APPS → select SECRETS,CP4BACR applications → SYNC.

Step 6: Monitoring CP4BA Deployment with ArgoCD:

  • Once the applications are created, monitor the deployment progress via the ArgoCD dashboard. This dashboard shows real-time synchronization status of each child application. As deployment progresses, ArgoCD ensures all resources—such as namespaces, secrets, operators, and custom resources—are deployed according to the manifests in your GitHub repository.

Step 7: Validation of CP4BA

To validate the readiness of your CP4BA deployment, use the post-installation script (cp4a-post-install.sh) found in the cert-kubernetes repository https://github.com/icp4a/cert-kubernetes/ . The script helps you to assess the readiness of your CP4BA deployment, and to retrieve and validate connection information to all its services.

The cert-kubernetes/scripts/cp4a-post-install.sh script has four modes for a production deployment type:

  • precheck

    • The precheck mode gets some basic information about the cluster, the console, and the client.

  • status

    • The status mode gets the status of all the components from the custom resource (Ready | Not Ready | Not Installed).

  • console

    • The console mode gets the console connection information from the URLs and credentials.

  • probe

    • The probe mode checks the readiness and health of the deployment endpoints.

The script can be run with the following options:

./cp4a-post-install.sh --help
   --precheck         This mode gives information about the cluster and the client.
   --status           This mode gives the status of the services of the deployment. 
   --console          This mode gives the service URLs of the consoles in the deployment. 
   --probe            This mode checks the readiness of the deployment endpoints. 

When you run the script in the status, console, or probe mode, the commands display information about the Cloud Pak for Business Automation version and interim fix number of the installed deployment. The output also includes the list of CP4BA capabilities that are installed.

Step 8: Uninstalling the CP4BA deployment

Delete the parent application first then delete the child applications. You can uninstall Cloud Pak resources and components from your platform deployment from the command line or from the OpenShift Container Platform (OCP) console. You can choose to also remove the data associated with the capability. For the detailed information please refer our official documentation: https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/24.0.0?topic=icmppd-uninstalling-capabilities

Conclusion

In this blog, we walked through deploying IBM CP4BA using ArgoCD. This GitOps-based approach ensures that your CP4BA environment is always in sync with your desired state as defined in your Git repository. With ArgoCD’s powerful features like automated synchronization and self-healing, managing complex applications like CP4BA becomes more efficient and scalable.


#Featured-area-2-home
0 comments
36 views

Permalink