YAML files

Last modified by Xwiki VePa on 2024/02/07 07:37

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: 3.3 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. For secret environmental variables: Instructions

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

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: 3.7 How to publish my application to the internet?

Contact information

The recommended contact for questions is:

https://helsinkifi.slack.com #kontit

All changes related to resources for the project/namespace should be emailed to:

grp-openshift-owner@helsinki.fi (platform administration and development)tike-ohjelmistotuotanto@helsinki.fi (program development)