Observação. trad.: Com entusiastas do Kubernetes do projeto nos conhecemos em um evento recente , onde nos causaram uma impressão agradável. Este material deles, escrito sobre um tema técnico atual e com notável senso de humor, é uma clara confirmação disso, por isso decidimos traduzi-lo.
Ele fala sobre o principal (de mesmo nome) empresa, cuja ideia é automatizar fluxos de trabalho e simplificar o desenvolvimento de aplicações em Kubernetes. Para fazer isso, o utilitário permite que você implante facilmente (literalmente com um comando) novas alterações feitas no código no cluster de desenvolvimento e também fornece recursos/caches compartilhados para acelerar a construção e o teste do código pela equipe. Há duas semanas o Garden acolheu , no qual foi possível utilizar não apenas um cluster Kubernetes local, mas também remoto: é a esse evento que este artigo se dedica.
Minha coisa que menos gosto de fazer é trabalhar com Kubernetes no meu laptop. O “timoneiro” consome processador e bateria, faz com que os coolers girem sem parar e é difícil de manter.
Banco de fotos no tema para efeito adicional
Minikube, tipo, k3s, Docker Desktop, microk8s, etc. - excelentes ferramentas criadas para tornar o uso do Kubernetes o mais conveniente possível, e obrigado a eles por isso. Seriamente. Mas não importa como você olhe, uma coisa é certa: o Kubernetes não é adequado para rodar em 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 coitado está se esforçando ao máximo, mas claramente não gosta dessa atividade, demonstrando sua insatisfação com o uivo dos coolers e tentando queimar suas coxas quando eu imprudentemente o coloco de joelhos.
Digamos: laptop - laptop.
é uma ferramenta para desenvolvedores que ocupa o mesmo nicho do Skaffold e Draft. Simplifica e acelera o desenvolvimento e teste de aplicações Kubernetes.
Desde o momento em que começamos a trabalhar no Garden, há cerca de 18 meses, sabíamos que local O desenvolvimento de sistemas distribuídos é uma solução temporária, por isso o Garden construiu uma flexibilidade significativa e uma base sólida.
Agora estamos prontos para oferecer suporte a ambientes Kubernetes locais e remotos. O trabalho ficou muito mais fácil: a montagem, a implantação e os testes agora podem ser realizados em um cluster remoto.
Em resumo:
Com o Garden v0.10, você pode esquecer completamente um cluster Kubernetes local e ainda obter uma resposta rápida às alterações de código. Tudo isso é gratuito e de código aberto.
Aproveite a mesma experiência em ambientes locais e remotos
Chamou sua atenção?
E estou feliz com isso, porque temos muitos outros recursos interessantes! O uso geral de clusters de desenvolvimento tem implicações mais amplas, especialmente para equipes colaborativas e pipelines de CI.
Como assim?
Primeiro de tudo, o coletor intra-cluster - seja um daemon Docker padrão ou Kaniko - bem como o registro intra-cluster são compartilhados para todo o cluster. Sua equipe pode compartilhar um cluster de desenvolvimento, com caches de build e imagens disponíveis para todos os desenvolvedores. Como o Garden marca imagens com base em hashes de origem, tags e camadas são definidas de forma única e consistente.
Isto significa que uma vez que um desenvolvedor cria uma imagem, ela se torna disponível para toda a equipe. Dia após dia, baixamos as mesmas imagens base e fazemos as mesmas compilações em nossos computadores. Curioso para saber quanto tráfego e eletricidade são desperdiçados?
O mesmo pode ser dito sobre os testes: seus resultados estão disponíveis para todo o cluster e para todos os membros da equipe. Se um dos desenvolvedores testou uma determinada versão do código, não há necessidade de executar novamente o mesmo teste.
Em outras palavras, não se trata apenas de não rodar o minikube. Este salto abre caminho para que sua equipe muitos oportunidades de otimização - chega de compilações e testes desnecessários!
E quanto ao CI?
A maioria de nós está acostumada com o fato de que CI e desenvolvimento local são dois mundos separados que precisam ser configurados separadamente (e não compartilham um cache). Agora você pode combiná-los e se livrar do excesso:
Você pode executar os mesmos comandos no CI e no processo de desenvolvimento, bem como use um único ambiente, caches e resultados de teste.
Essencialmente, seu CI se torna um bot desenvolvedor trabalhando no mesmo ambiente que você.
Elementos do sistema; desenvolvimento e testes contínuos
As configurações do pipeline de CI podem ser significativamente simplificadas. Para fazer isso, basta executar o Garden do CI para compilações, testes e implantações. Como você e o CI estão usando o mesmo ambiente, é muito menos provável que você encontre problemas de CI.
Vasculhando inúmeras linhas de configurações e scripts, depois empurrando, esperando, esperando e repetições intermináveis... Tudo isso está no passado. Você está apenas fazendo desenvolvimento. Sem movimentos desnecessários.
E para finalmente esclarecer a situação: quando você ou outro membro da equipe construiu ou testou algo com Garden, a mesma coisa aconteceu com CI. Se você não mudou nada desde a execução do teste, não será necessário executar testes (ou mesmo compilações) para CI. Garden faz tudo sozinho e depois passa para outras tarefas, como organizar o ambiente de pré-lançamento, enviar artefatos, etc.
Soa tentador. Como tentar?
Bem-vindo ao ! Instale o Garden e brinque com os exemplos. Para quem já utiliza o Garden ou deseja conhecê-lo melhor, oferecemos . Junte-se a nós no canal , se você tiver dúvidas, problemas ou apenas quiser bater um papo. Estamos sempre prontos para ajudar e receber comentários dos usuários.
PS do tradutor
Em breve também publicaremos uma revisão de utilitários úteis para desenvolvedores de aplicativos que operam em Kubernetes, que inclui outros projetos interessantes além de Jardim... Enquanto isso, leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com