Skip to content

Application

Application CRD instances are managed by the Application Operator

Application instances are designed to tackle edge use-cases, where off-the-shelves operators such as:

  • sparkline operator
  • stormline operator
  • flinkline operator

...are not enough to answer your pipeline needs.

A common example is that you want to be able to use our Plan operator on a pod that uses the image my-custom-image:latest, encapsulating your program.

Application Operator lifecycle

Note

Only the core loop is described below and this is not the complete lifecycle of an application instance

An application instance can go through five different phases, similarly to Pod Phases: Pending, Running, Succeeded, Failed and Unknown.

  • When an instance of an Application CRD is submitted to kubernetes ApiServer
  • application instance status should be empty
  • Application Operator will catch the submitted event and update the application instance status to Pending
  • During Pending phase, needed kubernetes sub-resources (pods and configmaps) will be created by the Application Operator
  • OwnerReferences are also set to all created sub-resources to the application instance
  • When all sub-resources are created successfully, the application instance status will be updated to Running
  • While in Running phase, the Application Operator will aggregate all sub-resources owned by application instance and update the application instance status based on the aggregated result

Mutating/Validating webhooks

Using webhooks with Application instances

Any Application CRD instances defining the .metadata.annotations.platform.gitlab.thalesdigital.io/platform: <PLATFORM_CRD_INSTANCE_NAME> will have its fields updated and validated based on the <PLATFORM_CRD_INSTANCE_NAME> resource.

apiVersion: punchline.gitlab.thalesdigital.io/v1
kind: Application
metadata:
  name: application-sample
  annotations:
    platform.gitlab.thalesdigital.io/platform: "<PLATFORM_CRD_INSTANCE_NAME>"
...

The usage of this field is mandatory in the scenario that sensitive objects must be used. I.E. secrets.

Configuration

Native kubernetes fields

Fields such as:

  • .apiVersion
  • .kind
  • .metadata

...are common fields, part of kubernetes terminology.

apiVersion: punchline.gitlab.thalesdigital.io/v1
kind: Application
metadata:
  name: application-sample
...

.metadata field is propagated to all the application instance sub-resources.

Customizing an instance based on .spec field

The .spec field is where you will be able to express your needs.

spec:
  # define the entrypoint you want to use
  command:
  - "/bin/sh"
  - "-c"
  # define the arguments you want to pass to your entrypoint
  args:
  - "myapplication.sh"
  # defaults to true if not set
  # state which context should be used to execute the application instance
  # Pod in case oneshot: true
  # Deployment in case oneshot: false / or oneshot is not set
  oneshot: false
  # define an image name
  image: busybox:latest
  # In general, this field is taken care by our webhooks
  # Define a SA in case additional rbac or imagePullSecrets are needed during runtime
  serviceAccount: admin-user
  # can be any initcontainer image as long as it follows our operator defined interface
  # we do provide one in our private repository
  # ghcr.io/punchplatform
  initContainerImage: ghcr.io/punchplatform/resourcectl:7.0.1
  imagePullPolicy: IfNotPresent
  # setting this to true will result in the submitted instance to be garbage upon Succeeded Phase
  # to be used only when oneshot: true
  garbageCollect: false
  # In general, this field is taken care by our webhooks
  # This field enables you to mount secret resources belonging in the same namespace as the application instance
  # so as your program can consume them for various purpose: e.g. fetching data from an elasticsearch cluster.
  secretRefs:
  - name: "resourcectl-tls"
    MountPath: "/var/run/kubernetes/platform/secrets/resourcectl/resourcectl-tls"
  # define a list of dependencies this application depends on
  dependencies:
  - punch-parsers:org.thales.punch:punch-websense-parsers:1.0.0
  - punch-parsers:org.thales.punch:common-punchlets:4.0.2
  - file:org.thales.punch:geoip-resources:1.0.1
  # define additional files you want to be mounted on the container filesystem during runtime
  # key: file_name
  # value: file_content
  configs:
    # this will create a file 'myCustomConfMountedOnPod'
    # with content: <value of the key>
    myCustomConfMountedOnPod: |
      # this content will be mounted on
      # the pod container local filesystem at
      # /data/myCustomConfMountedOnPod
      test: hello world

Example(s)

Standard / helloworld on stdout

---
apiVersion: punchline.gitlab.thalesdigital.io/v1
kind: Application
metadata:
  name: application-sample
spec:
  oneshot: true
  command:
  - "/bin/sh"
  - "-c"
  args:
  - "echo hello world"
  image: busybox
  serviceAccount: admin-user
  imagePullPolicy: IfNotPresent
  garbageCollect: false
  configs:
    myCustomConfMountedOnPod: |
      # this content will be mounted on
      # the pod container local filesystem at
      # /data/myCustomConfMountedOnPod
      test: hello world