Nota perev. : Conhecemos os entusiastas do Kubernetes do projeto Garden no recente evento KubeCon Europe 2019 , onde eles nos deixaram uma boa impressão. Este material, escrito sobre um tópico técnico relevante e com um notável senso de humor, é uma confirmação clara disso e, portanto, decidimos traduzi-lo.
Ele fala sobre o principal produto (de mesmo nome) da empresa, cuja idéia é automatizar fluxos de trabalho e simplificar o desenvolvimento de aplicativos no Kubernetes. Para fazer isso, o utilitário permite implantar facilmente (literalmente com um comando) novas alterações feitas no código no cluster dev, além de fornecer recursos / caches compartilhados para acelerar a montagem e o teste do código pela equipe. Há duas semanas, Garden hospedou o lançamento da 0.10.0 , na qual foi possível usar não apenas o cluster local do Kubernetes, mas também o remoto: este artigo é dedicado a este evento.Acima de tudo, gosto de trabalhar com o Kubernetes no meu laptop. O "piloto" absorve o processador e a bateria, faz os refrigeradores girarem sem parar e é difícil de manter.
Foto em um tema para aprimorar o efeito Minikube, tipo, k3s, Docker Desktop, microk8s, etc. - Ótimas ferramentas projetadas para tornar o Kubernetes o mais conveniente possível, e agradeço por isso. Sério. Mas de qualquer lado que você olhe, uma coisa é clara: o Kubernetes não está adaptado para rodar no meu laptop. E o laptop em si não foi projetado para funcionar com um cluster de contêineres espalhados por camadas de máquinas virtuais. O pobre está se esforçando ao máximo, mas ela claramente não gosta dessa ocupação, mostrando seu descontentamento com os uivos dos refrigeradores e se esforçando para queimar os quadris quando eu o coloquei de joelhos de forma imprudente.
Digamos: um laptop é um laptop.Garden é uma ferramenta de desenvolvedor no mesmo nicho que Skaffold e Draft. Simplifica e acelera o desenvolvimento e o teste de aplicativos Kubernetes.
Desde o início do trabalho no Garden, há cerca de 18 meses, sabíamos que o desenvolvimento
local de sistemas distribuídos era uma solução temporária, por isso estabelecemos considerável flexibilidade e uma base sólida no Garden.
Agora estamos prontos para oferecer suporte a ambientes locais e remotos do Kubernetes. O trabalho se tornou muito mais simples: agora a montagem, a implantação e o teste podem ser realizados em um cluster remoto.
Em resumo:
Com o Garden v0.10, você pode esquecer completamente o cluster local do Kubernetes e ainda obter uma resposta rápida às alterações no código. Tudo isso é gratuito e de código aberto.
Aproveite a mesma conveniência ao trabalhar com ambientes locais e remotosVocê chamou sua atenção?
E estou feliz com isso, pois ainda temos muitas fichas interessantes! O uso geral de clusters de desenvolvimento tem implicações mais amplas, especialmente para equipes colaborativas e pipelines de IC.
Como assim?Antes de tudo, o coletor intra-
cluster - seja o daemon Docker ou Kaniko padrão - quanto o registro intra-
cluster são comuns
a todo o cluster . Sua equipe pode usar o cluster dev juntos, com caches de montagem e imagens disponíveis para todos os desenvolvedores. Como o Garden identifica imagens com base em hashes de origem, as tags e as camadas são definidas de maneira inequívoca e consistente.
Isso significa que, assim que um desenvolvedor cria uma imagem, ele fica
disponível para toda a equipe . Dia após dia, fazemos o download das mesmas imagens básicas e fazemos as mesmas compilações nos computadores. Curioso quanto desperdício de tráfego e eletricidade? ..
O mesmo pode ser dito sobre os testes: seus resultados estão disponíveis para todo o cluster e todos os membros da equipe. Se um dos desenvolvedores testou uma determinada versão do código, não há necessidade de repetir o mesmo teste.
Em outras palavras, o ponto não é apenas que você não precisa executar o minikube. Esse salto abre a porta para sua equipe para
muitas oportunidades de otimização - não há mais compilações e execuções de teste extras!
E o CI?
A maioria de nós está acostumada ao fato de que o CI e o desenvolvedor local são dois mundos separados que precisam ser configurados separadamente (e eles não usam um cache comum). Agora eles podem ser combinados e se livrar do excesso:
Você pode executar os mesmos comandos no IC e no processo de desenvolvimento, além de usar um único ambiente, caches e resultados de teste.Essencialmente, seu IC se torna um desenvolvedor de bot que trabalha no mesmo ambiente que você.
Elementos do sistema; desenvolvimento e testes sem obstáculosVocê pode simplificar bastante as configurações de pipelines de IC. Para fazer isso, basta executar o Garden a partir do CI para compilações, testes e implantações. Como você e o IC usam o mesmo ambiente, a probabilidade de encontrar problemas com o IC é muito menor.
Cavar em inúmeras linhas de configurações e scripts, depois pressionar, esperar, esperar e repetições sem fim ... Tudo isso é passado.
Você está apenas desenvolvendo. Sem movimentos desnecessários.
E, finalmente, para esclarecer a situação:
quando você ou outro representante da equipe coletou ou testou algo usando o Garden, o mesmo aconteceu com a CI . Se você não alterou nada após a execução do teste, não será necessário realizar testes (ou mesmo montagens) para o IC. O Garden faz tudo sozinho e depois passa para outras tarefas, como organizar um ambiente de pré-lançamento, empurrar artefatos etc.
Parece tentador. Como tentar?
Bem-vindo ao
nosso repositório GitHub ! Instale o Garden e brinque com exemplos. Para aqueles que já usam o Garden ou desejam conhecê-los melhor, oferecemos o
Guia Remoto Kubernetes . Junte-se a nós no canal
#garden no Kubernetes Slack se você tiver dúvidas, preocupações ou apenas quiser conversar. Estamos sempre prontos para ajudar e receber os comentários do usuário.
PS do tradutor
Em breve, publicaremos também uma visão geral dos utilitários úteis para desenvolvedores de aplicativos que operam no Kubernetes, que, além do Garden, têm outros projetos interessantes ... Enquanto isso, leia também em nosso blog: