Add helper image for generating static deploy yamls for the operator.

[amisevsk]

What does this PR do?

While trying to figure out a solution for eclipse-che/che#18842 since we removed static deployment yamls from the repo, I realized there's no easy way of generating the files directly and figured we would eventually need a way of generating static files that can be deployed directly to a cluster without relying on make for environment substitution and kustomize for applying overlays. (note: the envsubst step is currently required before kustomize, as the CRDs have fields whose descriptions contain env vars)

I wrote a dockerfile that generates a tarball containing all yaml files required for deploying the operator, with the only requirement that the configmap is updated to have the correct routingSuffix on Kubernetes.

This commit also hard-codes the webhooks-enabled property to true, as webhooks have been required for quite some time.

What issues does this PR fix or reference?

Potentially helpful for eclipse-che/che#18842

Is it tested? How?

Building the image:

docker build -t <template-image> -f yaml-builder.Dockerfile .

Extracting yamls:

docker create --name builder <template-image>
docker cp builder:/devworkspace_operator_templates.tar.gz ./devworkspace_operator_templates.tar.gz
docker rm builder
tar -xzf devworkspace_operator_templates.tar.gz

The file structure of the tarball is

deploy
├── kubernetes
│   ├── objects
│   │   ├── <object-name>.<object-kind.yaml
│   │   └── (...)
│   └── combined.yaml
└── openshift
    ├── objects
    │   ├── <object-name>.<object-kind.yaml
    │   └── (...)
    └── combined.yaml

where combined.yaml is a fat yaml of all the objects (~16k lines) and deploy/platform/objects contains each of the records in combined.yaml named after the object they represent.

I've pushed quay.io/amisevsk/devworkspace-yaml:latest for testing

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amisevsk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [amisevsk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[amisevsk]

cc: @tolusha

[tolusha]

Are templates changed often?
If not, can this script be generated on your side (release process or when it is needed) and templates committed into the repo?

[sleshchenko]

That seems to duplicate stuff we have in Makefile, which means we have more to maintain and test.

According to discussion with @tolusha, it would simplify things for chectl if it can just grab static files from devworkspace-operator repo (even if then it will modify some pieces, like namespace, possible operator image, ...).
After go vendoring we're not afraid of redundant ~16k lines )

So, it make me thinking what if:

1. We have a script that generates static deploy files, according to the current env vars.
2. We generate static deploy files with default values and keep them in the repo, PR checks that they are up to date.
3. Makefile invokes the script from 1, but result is stored in another not commited place.

@amisevsk WDYT?

[amisevsk]

Makes sense; my main concern is the levels of indirection (pkg/api -> CRDs -> deployable yamls) but that can be addressed with PR checks I suppose. I'll close this one and port the changes over to a new one that includes the full yamls.

[amisevsk]

Closing in favor of Serhii's suggestion.