kubernetes: build with an initContainer or a Job

未指定文件或测试。首先检查当前的 Kubernetes deployment 和 Terraform 资源，然后跟踪 envbuilder 在 workspace 启动期间如何执行构建；完成标准是选择并实现一个提案、验证镜像引用的交接，并处理构建日志流式传输。

Context

Currently, envbuilder runs at the start up of a workspace, exposing elements of the buildtime to the runtime and vice-versa:

• Build secrets (e.g. dockerconfig)
• Environment variables (#91)
• Mounts (#187)
• Privileges (#181)
• Container layers are downloaded in each container rather than on the nodes
• ... (feel free to grow the list)

Proposal 1: initContainer

1. Envbuilder would build the image as an initContainer and push it to a container registry
2. The main container would pull and run the image (todo: validate that the pod can be created without the image existing yet)

This would require to generate/know the image reference ahead of time.

Proposal 2: Kubernetes Job

Entire decoupling of buildtime and runtime:

1. Envbuilder runs as Kubernetes Job to build and push the container image
2. It writes a ConfigMap with the reference of the built image
3. Terraform waits for completion of the Job
4. Terraform reads the ConfigMap with kubernetes_config_map datasource (explicitly depending on the Job creation)
5. The image reference from the ConfigMap is then used to create a Deployment
6. A short ttl_seconds_after_finished would allow clean up of the Job for it to be recreated on the next terraform apply

The ConfigMap could be used to share of information between envbuilder and Terraform (#121), like the volumes defined in the devcontainer.json (#220)

Detail to consider: I believe the Coder server starts streaming the logs from the deployment after the terraform apply has finished, it would need to be able to do it for the Job while the apply is running to expose the build logs to the user.

Is it something that has been thought of/done but not documented yet?