[draft] Running containers with kubedock (crw-3367)

[deerskindoll]

What does this pull request change?

What issues does this pull request fix or reference?

Specify the version of the product this pull request applies to

Pull Request checklist

The author and the reviewers validate the content of this pull request with the following checklist, in addition to the automated tests.

• Any procedure:
  • [ ] Successfully tested.
• Any page or link rename:
  • [ ] The page contains a redirection for the previous URL.
  • Propagate the URL change in:
    • [ ] Dashboard default branding data
• [ ] Builds on Eclipse Che hosted by Red Hat.
• [ ] the Validate language on files added or modified step reports no vale warnings.

[github-actions[bot]]

⚡️ Deploying pull request preview...

[github-actions[bot]]

Click here to review and test in web IDE:

[deerskindoll]

feedback from Anton:

I would really appreciate if we could add some more context explaining why kubedock is useful. The docs says Use kubedock to run containers as Kubernetes pods.

And while that is technically true, you can also use devfile to run containers. Or k8s deployment. Kubedock is minimal container engine implementation which gives you podman(or docker)-like experience inside Dev Spaces Workspace. Developers are used to using podman/docker during their local development workflow, and kubedock brings that experience onto the OpenShift, inside Dev Spaces.. This is otherwise incredibly hard to achieve due to the inherent OpenShift security restrictions. Kubedock is specifically useful when dealing with ad-hoc, ephemeral and testing containers. Suitable use cases are (list is not exhaustive)

1. Executing applications tests which rely on Testcontainers framework - kubedock will dynamically spin up required test container image , on the fly, as an OpenShift pod, giving user seamless experience.

2. Quarkus Dev Services - which are internally relying on Testcontainers as well.

3. When you are in need to you to run a container stored in remote container registry, for local development purposes and for whatever reasons you don't want to pollute the devfile . It's very important to mention (even though this is obvious!) that even though it gives you podman-like experience which you are used to from your local development environment, the absolute hard requirement is that the particular image which is being used via kubedock must be compatible with OpenShift. I specifically have security requirements in mind - i.e. not every container image which can be executed in your local machine, can also be executed on OpenShift. So if you do podman run - it will fail with kubedock, and it will work locally. (edited)

Once the use cases/motivation is explained, it would really good if we can share an example devfile.yaml, but ideally with accompanied git repo as well. I know this is hard, because including public github link in official documentation is always risky, so not sure what is the general rule of thumb for tech writers.

Container Image Guidelines for OpenSHift are here https://docs.openshift.com/container-platform/4.15/openshift_images/create-images.html - For example, the kafka-native testcontainer wasn't compatible with openshift - it only worked in local environment. So user who used this testcontinaer locally, would be surprised if he tried to use it via kubedock in dev spaces. We had to reach out to upstream community and they had to refactor that image, so it would become OCP-compatible (luckily, the image owner was Red Hatter as well..). I am just sharing all my experience accumulated over the past weeks..