Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

kubernetes: build with an initContainer or a Job

Aberta
  • Algo errado?
#269 2 comentários 3 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
kubernetes, terraform
Domínio
cloud, infrastructure

Direção de pesquisa

Nenhum arquivo ou teste é indicado. Comece revisando o deployment atual do Kubernetes e os recursos do Terraform; em seguida, rastreie como o envbuilder realiza os builds durante a inicialização do workspace. O trabalho estará concluído quando uma proposta tiver sido escolhida e implementada, a transferência da referência da imagem tiver sido validada e o streaming dos logs de build tiver sido tratado.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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?

Linguagem predominante
Go
Estrelas
301
Forks
64
Nenhum PR com merge em 30d

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de coder/envbuilder

Todas as issues de coder/envbuilder

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.