3.4 Git and OpenShift

General information

This page details how to synchronize version control from the University's GitLab with a project in OpenShift. Most of the instructions here can be applied to Github and similar services.

Different ways to get code to a project in OpenShift:

• Buildconfig. With this OpenShift can pull from a git repository, including the Dockerfile, build an Image and deploy the latest version of an application.
• Webhooks, with which a git-repository can command OpenShift to start a BuildConfig when new commits are made to certain repositories or branches.
• More sophisticated CI/CD-pipelines, such as Gitlab CI, ArgoCD, FluxCD, Openshift Pipelines, etc.

Creating a BuildConfig

This instruction assumes that you have a containerized application that works locally, and that both the source code and Dockerfile are in version control.

• If your repository is secret:
  • Create a SSH-key for your deployment
     DO NOT USE YOUR OWN KEYS HERE – THE PRIVATE PART OF THE KEY IS GIVEN AS PROJECT SECRET INSIDE THE CLUSTER! CREATE A NEW KEY FOR FOR THIS AND ONLY THIS
    
    
    

$ ssh-keygen -t rsa -b 4098 -q -N '' -C project-deploy -f project-deploy$ ls project-deploy* project-deploy project-deploy.pub

• 
  
  • Place the public key with read access in your repository as a deploy key:

    • GitLab: repository sidebar → "Settings" →  "Repository" → "Deploy keys" → "Expand" → descriptive name, copy and paste the contents of your key public key in the text field and choose "Add key" 

  • Web-console → Developer perspective → "+Add" → (make sure you are in the right project) → "From Dockerfile" → fill the form→ "Create" 
  • Under "Show advanced git options" you can find the option to give SSH-key as a secret ("Source Secret" → "Select Secret Name" → "Create New Secret" → "Auth type" → "SSH Key"). Use this if your repository is secret.
  • NOTE! When using an SSH-key, instead of your git-repo url use the git@<git-provider> address found under the "clone with ssh" button.

The chain above creates other things than just the BuildConfig, for example a Service and Deployment config DeploymentConfig objects. All of these can be edited later. It is recommended that you place the yaml files in version control immediately. These yaml files should be edited to make your application work correctly.

After this you can check build logs, either from the web-console or with the OC cli application. If you wish to restart the build (if for example you have a new commit in the source code), it can be done using theweb-console or from a terminal:

$ oc start-build <name> #name of the BuildConfig

Webhooks

In OpenShiftWebhooks are defined in OpenShift for each BuildConfig object. If you are adding your application to OpenShift using a Dockerfile, a checkmark should automatically be placed here (this may be under another menu)

The information for the Webhook can be found: Web-konsoli → Developer perspective -> Topology -> Choose your BuildConfig -> Your webhook should be at the bottom of the page (photo below) -> Copy URL with Secret. Also click the  application-name-generic-webhook-secret and you can find the secret at the bottom of this page.

If the BuildConfig does not have information of a webhook, you can create one with the OC-client:

You can also see the name for the Webhook used by a Buildconfig in the buildconfig.yaml:

In Gitlab

GitLab: repository sidebar → "Settings" → "Webhooks"

• URL - The "URL with secret" you copied above
• Secret token - The secret you copied above
• Choose the triggers you wish to have (with a push event branch, or the webhook could also be triggered in a Gitlab pipeline)
• Checkmark at the bottom "Enable SSL verification" and then "add webhook"

Below a photo for adding a Webhook in Gitlab

Webhooks can also be tested and triggered manually from the bottom of this page

Choose Test and the trigger you wish to test. The right  webhook can be identified by looking at darkened parts of the Webhook:

https://api.ocp-prod-0.k8s.it.helsinki.fi:6443/apis/build.openshift.io/v1/namespaces/project_name/buildconfigs/buildconfigin_name/webhooks/993a44d4125d6482/generic

• The first darkened part, test or prod, identifies the cluster.

Webhooks can also be used for other things, here is Gitlab's own documentation on the subject: Webhook events

CI/CD like Gitlab CI