Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

kubernetes: build with an initContainer or a Job

Abierto
#269 2 comentarios 3 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
kubernetes, terraform
Área
cloud, infrastructure

Línea de trabajo

No se nombran archivos ni pruebas. Empieza revisando el deployment actual de Kubernetes y los recursos de Terraform; después, sigue cómo envbuilder realiza las compilaciones durante el inicio del workspace. El trabajo estará terminado cuando se haya elegido e implementado una propuesta, se haya validado la transferencia de la referencia de imagen y se haya abordado el streaming de los logs de compilación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

Lenguaje dominante
Go
Estrellas
300
Forks
64
Merge medio
20 min
PR fusionados (30 d)
1

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de coder/envbuilder

Todos los issues de coder/envbuilder

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.