Product information

• RedHat OpenShift
• IBM App Connect operator v6.1.1
• Gitlab

Context

In the examples below, I’m utilizing IBM’s offered operator to deploy an integration server on OpenShift. I can build an integration server using this operator and a variety of OpenShift resources. This sample uses the following resource types:

• IntegrationServer.yaml
• Configuration.yaml
• Secret.yaml

Solution

Please keep in mind that the solution demonstrated in this blog post is not a fully automated pipeline from development to deployed resources. I’m only interested in integrating a connection between OpenShift and Gitlab to provide the necessary bar files.

Extra setup info: Gitlab is running on OpenShift. In this case Gitlab is running on the ocp1 instance and my integration sollutions are running on the ocp2 instance. A route is sufficient to enable a connection to Gitlab.

Design

Gitlab – Create a token

Tip : use a service account/Technical user

• Edit your profile

• Go to ‘Access Tokens’
• Create a token, do provide the scope ‘api’
• Save your token.

OpenShift – Create required resources

Prerequisite: Login to Openshift using your CLI

Root CA

If your GitLab is running on an internal network and is secured with certificates, you must create an OpenShift secret containing the root CA. Make a yaml file called’my-gitlab-ca.yaml’ that includes the following information:

Upload your secret in OpenShift

oc apply -f my-gitlab-ca.yaml

Security configuration

Now I’ll generate a json with my credentials and Gitlab authentication type. The json does not need to be saved to a file. I’ll simply encode the JSON in base64 and store it in a yaml configuration file.

Next, I’ll make a yaml file called ‘gitlab-barauth.yaml’ that has the following information.

Upload your configuration:

oc apply -f gitlab-barauth.yam

Gitlab – Create HTTP GET call to fetch the bar file.

To include the bar files in your deployment, you can’t simply copy the download link from Gitlab into your IntegrationServer.yaml file. Fortunately, Gitlab provides an API for managing resources in Gitlab projects. The syntax of such an API request is as follows:

https://<hostname>/api/v4/project/<project-id>/repository/files/<resource-name>/raw?ref=<branch-name>&private-token=<token>

The project ID is available here:

OpenShift – Update your integration server

Following that, I’ll create a yaml file called my-is.yaml’ with the following information.

oc apply -f my-is.yaml

Follow-up

Check the OpenShift logs to check if the deployment was successful. Otherwise, the logs will display an error message. If you encounter an error:

• Check that your account has enough rights to work with the Gitlab project.
• You used the proper token.
• Your secret certificate is valid.
• Your request’s route is correct.

The simplest approach to ensure that it is operating as planned is to open the WebUI and ensure that all bar files have been successfully deployed.

Conclusion

By using this approach, I can make sure that my containers are always running the most recent version of the integrations I’ve committed to the given branch. It will automatically download the most recent version of my integrations even if the pod dies or I give OpenShift an upgraded version of the IntegrationServer.yaml. A more automated solution is something I do suggest for a non-development environment. But for my development purposes, I’m pleased with how this works.