Nota. transl.: Con entusiastas de Kubernetes do proxecto coñecémonos nun evento recente , onde nos deixaron unha grata impresión. Este material deles, escrito sobre un tema técnico de actualidade e cun notable sentido do humor, é unha clara confirmación diso, polo que decidimos traducilo.
El fala do principal (do mesmo nome) empresa, cuxa idea é automatizar fluxos de traballo e simplificar o desenvolvemento de aplicacións en Kubernetes. Para iso, a utilidade permítelle implementar facilmente (literalmente cun só comando) novos cambios realizados no código no clúster de desenvolvemento, e tamén ofrece recursos/cachés compartidos para acelerar a creación e proba do código polo equipo. Hai dúas semanas o Xardín acolleu , no que se fixo posible utilizar non só un clúster de Kubernetes local, senón tamén un remoto: este é o evento ao que se dedica este artigo.
O que menos me gusta facer é traballar con Kubernetes no meu portátil. O "timonel" come o procesador e a batería, fai que os refrixeradores xiren sen parar e é difícil de manter.
Fotografía de stock en tema para un efecto adicional
Minikube, kind, k3s, Docker Desktop, microk8s, etc. - excelentes ferramentas creadas para que o uso de Kubernetes sexa o máis cómodo posible, e grazas a eles por iso. En serio. Pero non importa como o mire, unha cousa está clara: Kubernetes non é axeitado para funcionar no meu portátil. E o portátil en si non está deseñado para funcionar cun grupo de contedores espallados por capas de máquinas virtuais. O pobre está facendo todo o posible, pero está claro que non lle gusta esta actividade, amosando o seu descontento co ouveo dos refrixerantes e tentando queimarlle as coxas cando temerariamente o poño de xeonllos.
Digamos: portátil - portátil.
é unha ferramenta para desenvolvedores que ocupa o mesmo nicho que Skaffold e Draft. Simplifica e acelera o desenvolvemento e proba de aplicacións Kubernetes.
Desde o momento en que comezamos a traballar en Xardín, hai uns 18 meses, sabiamos que local O desenvolvemento de sistemas distribuídos é unha solución temporal, polo que Garden construíu unha flexibilidade significativa e unha base sólida.
Agora estamos preparados para admitir ambientes Kubernetes tanto locais como remotos. O traballo fíxose moito máis sinxelo: a montaxe, a implantación e as probas agora pódense realizar nun clúster remoto.
En breve:
Con Garden v0.10, podes esquecerte por completo dun clúster de Kubernetes local e seguir recibindo unha resposta rápida aos cambios de código. Todo isto é gratuíto e de código aberto.
Goza da mesma experiencia en ambientes locais e remotos
Chamou a súa atención?
E alégrome disto, porque temos moitas máis funcións interesantes! O uso xeral dos clústeres de desenvolvemento ten implicacións máis amplas, especialmente para os equipos de colaboración e os pipelines de CI.
E logo?
En primeiro lugar, compártense o colector intra-clúster, xa sexa un daemon Docker estándar ou Kaniko, así como o rexistro intra-cluster. para todo o cluster. O teu equipo pode compartir un clúster de desenvolvedores, con cachés de compilación e imaxes dispoñibles para todos os desenvolvedores. Dado que Xardín etiqueta as imaxes baseadas nos hashs de orixe, as etiquetas e as capas defínense de forma única e coherente.
Isto significa que unha vez que un desenvolvedor crea unha imaxe, esta faise dispoñible para todo o equipo. Día tras día, descargamos as mesmas imaxes base e facemos as mesmas compilacións nos nosos ordenadores. Curioso canto tráfico e electricidade se desperdicia?...
O mesmo pódese dicir das probas: os seus resultados están dispoñibles para todo o clúster e todos os membros do equipo. Se un dos desenvolvedores probou unha determinada versión do código, non é necesario volver executar a mesma proba.
Noutras palabras, non se trata só de non executar minikube. Este salto abre o camiño para o teu equipo moitas oportunidades de optimización: non hai máis compilacións e probas innecesarias.
Que pasa con CI?
A maioría de nós estamos afeitos ao feito de que CI e dev local son dous mundos separados que deben configurarse por separado (e non comparten caché). Agora podes combinalos e desfacerte do exceso:
Pode executar os mesmos comandos en CI e no proceso de desenvolvemento, así como utilizar un único ambiente, cachés e resultados das probas.
Esencialmente, o teu CI convértese nun bot de desenvolvedor que traballa no mesmo ambiente ca ti.
elementos do sistema; desenvolvemento e probas sen problemas
As configuracións de pipeline de CI pódense simplificar significativamente. Para iso, só tes que executar Garden desde CI para compilacións, probas e despregamentos. Dado que vostede e o CI están a usar o mesmo ambiente, é moito menos probable que atope problemas de CI.
Explorando incontables liñas de configuracións e scripts, despois empurrando, esperando, esperando e repeticións sen fin... Todo isto está no pasado. Só estás facendo desenvolvemento. Sen movementos innecesarios.
E para aclarar finalmente a situación: cando vostede ou outro membro do equipo construían ou probaron algo con Garden, ocorreu o mesmo con CI. Se non cambiou nada desde que se executou a proba, non necesitará realizar probas (ou incluso compilacións) para CI. Garden fai todo por si mesmo e despois pasa a outras tarefas como organizar o ambiente previo ao lanzamento, empurrar artefactos, etc.
Parece tentador. Como probalo?
Benvido a ! Instala Garden e xoga cos exemplos. Para quen xa utiliza Garden ou quere coñecelo mellor, ofrecémoslle . Únete a nós no canal , se tes preguntas, problemas ou só queres falar. Sempre estamos preparados para axudar e recibir comentarios dos usuarios.
PS do tradutor
En breve tamén publicaremos unha reseña de utilidades útiles para os desenvolvedores de aplicacións que operan en Kubernetes, que inclúe outros proxectos interesantes ademais de Garden... Mentres tanto, lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com