Support installing Puma and Workhorse

What does this MR do?

Puma and Workhorse together build the application server component of GitLab, which as the name suggests serve the Rails application of GitLab.

Similar to GitLab Chart, Puma and Workhorse run together in a single Pod. The workload is managed by a Deployment and exposed through a Service and is made accessible via an Ingress resource.

This change enables controller to create the Deployment, Service, and Ingress resources for the application server.

Overview of changes

An overview of notable changes. The key changes are:

• api/v2alpha1
• assets/templates/application-server
• internal/controller/helpers

api/v2alpha1

• Top-level PodTemplate field is removed from GitLabSpec. This is the instance-level PodTemplate and was meant to be the fallback for all workloads which can be overwritten with component-level PodTemplates. Since this cannot be implemented yet (it requires supporting strategic merge patch) it is removed from the API. It will be added in future iterations if needed.
• Top-level TLS field is added to enable TLS on Ingress resources and pass TLS certificate Secrets.

As a result of these changes in the API, generated DeepCopy and CRD (in config/crd/bases) have changed.

assets/templates/application-server

Templates for Deployment, Service, and Ingress resources are added into separate files. These are rendered and deserialized by TemplateInventory.

cmd/main

Templates population and custom functions registration are added to manager init function.

internal/controller/tasks

• Old template functions are moved from internal/controller/helper to internal/controller/tasks. This was done to work around cyclic dependency. These function will be removed later and their usage will be replaced with the new template engine and TemplateInventory.
• A new general-purpose Digest task is added. It can calculate the SHA256 digest of a list of ConfigMaps and/or Secrets.

internal/controller/helpers

Application server installer is defined as a Task. It comprised of four others tasks:

1. Lookup Secrets
2. Calculate digest
3. Render templates and load inventory (Deployment, Service, Ingress)
4. Apply objects

The idea is to eventually get to a point that we can define compound tasks easier, in a declarative manner (as opposed to current procedural form).

pkg/framework/template

• toYAML and fromYAML template functions are added.

Test plan

1. Setup the development cluster with the development kit.
2. You need to port the Secrets before using them.
3. Create a GitLab custom resource from the following example.
4. Watch the application server Deployment, Service, and Ingress resources are deployed.

apiVersion: gitlab.com/v2alpha1
kind: GitLab
metadata:
  name: test
spec:
  version: 16.11.2
  externalUrl: <URL>

  tls:
    certificate:
      name: operator-v2-dev-kit-gitlab-tls

  postgresql:
    name: default
    provider:
      service:
        name: operator-v2-dev-kit-postgresql
    authentication:
      basic:
        name: example-1-postgresql-auth

  redis:
    name: default
    provider:
      service:
        name: operator-v2-dev-kit-redis-master
    authentication:
      basic:
        name: example-1-redis-auth

  repository:
    name: default
    provider:
      service:
        name: operator-v2-dev-kit-gitaly
    authentication:
      token:
        name: operator-v2-dev-kit-gitaly-secret
        key: token

  appServer:
    podTemplate:
      spec:
        containers: []
        securityContext:
          runAsUser: 1000
          runAsGroup: 1000
          fsGroup: 1000

  appConfig:
    objectStore:
      provider:
        aws:
          accessKeyId:
            name: operator-v2-dev-kit-minio-secret
            key: accesskey
          accessKeySecret:
            name: operator-v2-dev-kit-minio-secret
            key: secretkey
          region: 'local'
          endpoint: http://operator-v2-dev-kit-minio-svc.operator-v2-test.svc:9000

      destinations:
        artifacts:
          bucketName: test-artifacts
        externalDiffs:
          bucketName: test-external-diffs
        lfs:
          bucketName: test-lfs
        uploads:
          bucketName: test-uploads
        packages:
          bucketName: test-packages
        dependencyProxy:
          bucketName: test-dependency-proxy
        terraformStates:
          bucketName: test-terraform-states
        ciSecureFiles:
          bucketName: test-ci-secure-files

Alternatively, you can follow the validation procedure pf PoC: Rollout application server (!25 - closed).

Author's Checklist

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Ensure a release milestone is set.
• MR title and description are up to date, accurate, and descriptive.
• MR targeting the appropriate branch.
• MR has a green pipeline on GitLab.com.
• When ready for review, MR is labeled workflowready for review per the MR workflow.

Expected

• Test plan indicating conditions for success has been posted and passes.
• Documentation is created or updated.
• Tests are added.

Related issues

Closes #2 (closed)