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 fromGitLabSpec
. This is the instance-levelPodTemplate
and was meant to be the fallback for all workloads which can be overwritten with component-levelPodTemplate
s. 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
tointernal/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 andTemplateInventory
. - 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:
- Lookup Secrets
- Calculate digest
- Render templates and load inventory (Deployment, Service, Ingress)
- 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
andfromYAML
template functions are added.
Test plan
- Setup the development cluster with the development kit.
- You need to port the Secrets before using them.
- Create a GitLab custom resource from the following example.
- 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)