Skip to Content

YAML files

Last modified by Tomas Terälä on 2025/03/21 14:23
Contents

Yaml files are configuration files that define BuildConfigs, Builds, Pods, Services, Routes etc. By editing a YAML you can change how your Pods/applications behave in OpenShift. When making changes to a BuildConfig, all objects inheriting from it create new versions that replace old versions when ready (this includes Pods). About Yamls in general

YAMLs also contain multiple rows of automaticaly generated lines, which is why this page will explain some of the most important parts. Some information can be found on the objects own page in an easier readable format while some require scrolling.

Finding YAMLs in the Web Console

Administrator View

Pod: Workloads → Pods → Choose a pod → Yaml

Build: Builds → Builds → Choose a build → Yaml

Service: Networking → Services → Choose a Service → Yaml

Route: Networking → Routes → Choose a Route → Yaml

Developer View

Pod: Topology → Choose a deployment → Choose from the “Pods” list → Yaml

Build: Topology → Choose a deployment → Choose from the “Builds” list → Yaml or Builds → Choose a BuildConfig → Builds → Choose a build → Yaml

Service: Topology → Choose a deployment → Choose from the “Services” list → Yaml

Route: Topology → Choose a deployment → Choose from the “Routes” list → Yaml

Buildconfig

Changing the Tracked Branch

This was also explained at: Adding an application to an OpenShift project

metadata:
 annotations:
   app.openshift.io/vcs-ref: main #metadata branch
   app.openshift.io/vcs-uri: 'https://version.helsinki.fi/project/Application' #metadata url
   openshift.io/generated-by: OpenShiftWebConsole

[.....]
spec:
 source:
   type: Git
   git:
     uri: 'https://version.helsinki.fi/projekti/Sovellus' #git url
     ref: main  #git branch/tag
   contextDir: /server #the path to the applications root folder
   sourceSecret:
     name: gitlab-production-token #references the Administrator->Workloads->Secrets file where the pull secret exists, if necessary

Environmental Variables

If the environmental variables are not secret, they can be defined directly in the BuildConfig.yaml.

spec:
 strategy:
   type: Docker
   dockerStrategy:
     env:
        - name: PORT #an example port
         value: '3001'
        - name: VARIABLE NAME #quotation marks unnecessary
         value: VARIABLE VALUE #quotation marks unncesessary
     dockerfilePath: Dockerfile #path from contextDir (defined above) to the Dockerfile,
                                #just Dockerfile is enough if the Dockerfile is in the root folder

For secret environmental variables instructions here.

Triggers

Defines what causes new Builds and the following Pod rebuild to be triggered

triggers:
    - type: Generic
     generic:
       secretReference:
         name: api-generic-webhook-secret #an automatically created webhook as a Secret in this example
    - type: ConfigChange

Log Amounts

Check: Openshift logs

Service

OpenShift will handle port network traffic between Pods as long as the Pods are correct, you do not need to worry about port forwardings. Usually this means that both the port and targetPort are the same number.

spec:
 ports:
    - name: 3001-tcp #Visible on the Services own page as 'Service port mapping name'
     protocol: TCP #Protocol, don't touch
     port: 3001 #Port that the Service listens to
     targetPort: 3001 #Port where the Service forwards the traffic to

Route

Changes to the Route are detailed here.