Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

kubernetes: build with an initContainer or a Job

Ouverte
#269 2 commentaires 3 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
kubernetes, terraform
Domaine
cloud, infrastructure

Piste de recherche

Aucun fichier ni test n’est nommé. Commencez par examiner le déploiement Kubernetes actuel et les ressources Terraform, puis suivez la manière dont envbuilder effectue les builds au démarrage du workspace ; le travail sera terminé lorsqu’une proposition aura été choisie et implémentée, que le transfert de la référence d’image aura été validé et que le streaming des logs de build aura été pris en charge.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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?

Langage dominant
Go
Étoiles
300
Forks
64
Merge moyen
20 min
PR mergées (30 j)
1

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de coder/envbuilder

Toutes les issues de coder/envbuilder

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.