Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

kubernetes: build with an initContainer or a Job

Offen
#269 2 Kommentare 3 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
kubernetes, terraform
Bereich
cloud, infrastructure

Rechercherichtung

Es werden keine Dateien oder Tests genannt. Beginne mit der Überprüfung des aktuellen Kubernetes-Deployments und der Terraform-Ressourcen und verfolge anschließend, wie envbuilder beim Start des Workspace Builds erstellt; als abgeschlossen gilt die Aufgabe, wenn ein Vorschlag ausgewählt und implementiert, die Übergabe der Image-Referenz validiert und das Streaming der Build-Logs behandelt wurde.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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?

Vorherrschende Sprache
Go
Sterne
300
Forks
64
Ø Merge
20 Min.
Gemergte PRs (30 T.)
1

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus coder/envbuilder

Alle Issues in coder/envbuilder

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.