Actualmente me estoy mudando de ECS a EKS y estoy confundido sobre la división entre Helm y Terraform.
Actualmente tenemos un repositorio Terraform/Packer dedicado para nuestro clúster EKS.
Entonces tenemos un repositorio para nuestra aplicación. La aplicación requiere una instancia de AWS RDS y SQS/SNS.
Tengo entendido que Helm no es compatible con SQS u otra configuración de servicio, en cuyo caso me pregunto por qué me molestaría con Helm cuando es bastante fácil implementar todas las colas/db/aplicación requeridas en EKS utilizando únicamente Terraform. Parece que al presentar Helm todo lo que termino haciendo es crear una división innecesaria en la configuración de la aplicación para la configuración de la aplicación K8/NonK8.
Siento que me estoy perdiendo el punto de Helm, pero estoy luchando por ver qué es. ¡Ayúdame a ver lo que me estoy perdiendo!
Helm es para instalar aplicaciones en su EKS. SQS y RDS no son aplicaciones que se ejecutan en su clúster de contenedores, son infraestructura. Para aquellos, puede usar Terraform, CloudFormation o CDK.
Puede encontrar más ejemplos sobre cómo usar las diferentes herramientas aquí: https://www.eksworkshop.com/
Puedes hacer lo que hace Helm usando otras herramientas como Terraform. Depende de qué antecedentes vengas en mi opinión.
Helm fue una de las herramientas iniciales que la gente de DevOps tenía disponible para abordar el "infierno de YAML", ya que Kubernetes, Cloud-Native, Microservices realmente estaban despegando en el uso de producción. Es fácil de aprender para una persona orientada a operaciones acostumbrada a piratear cosas en shell, línea de comandos o usar plantillas de texto Jinja en scripts de Python.
Debido a esto, hay mucha inercia detrás de los gráficos de Helm y muchos productos nativos de la nube eligen publicar gráficos de Helm como una forma "rápida" de poner en marcha su producto en un clúster de Kubernetes.
Personalmente, evito usar gráficos de Helm y (si estos gráficos no son demasiado locos) elijo traducirlos a Terraform para que encaje correctamente dentro del paradigma GitOps/IaC y gane consistencia tanto en el aprovisionamiento como en el despliegue de la infraestructura. También sospecho que los gráficos de Helm son más difíciles de mantener desde la perspectiva del desarrollo del equipo a largo plazo.
Si IaC no es su preferencia, entonces una solución "más limpia" entonces Helm sería kustomize , especialmente porque es compatible con Google y en realidad está integrado en el binario kubectl en este punto. Esta también es una utilidad para crear plantillas/manifiestos de Kubernetes, pero no introduce ni se basa en un estado externo como lo hace Helm.
Helm y Terraform tienen dos propósitos diferentes. Por lo general, utiliza ambos para el aprovisionamiento nativo en la nube centrado en CI/CD. Helm le permite aprovisionar fácilmente servicios que están destinados a ejecutarse dentro de un clúster de Kubernetes. Con Terraform, puede aprovisionar el propio clúster de Kubernetes o cualquier otro componente de PaaS (como bases de datos o intermediarios de mensajes) destinado a ejecutarse fuera del clúster de Kubernetes. Para obtener más detalles, consulte este blog sobre el renacimiento de DevOps .