kubernetes: build with an initContainer or a Job

Aperta
#269 2 commenti 3 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
kubernetes, terraform
Ambito
cloud, infrastructure

Direzione di ricerca

Non vengono indicati file o test. Inizia esaminando il deployment Kubernetes corrente e le risorse Terraform, quindi traccia il modo in cui envbuilder esegue le build durante l’avvio del workspace; il lavoro sarà completo quando sarà stata scelta e implementata una proposta, sarà stato validato il passaggio del riferimento all’immagine e sarà stata affrontata la trasmissione dei log di build.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
Go
Stelle
300
Fork
64
Merge medio
20m
PR unite (30g)
1

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coder/envbuilder

Tutte le issue di coder/envbuilder

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.