El artículo está dedicado al desarrollo de gráficos Helm para Kubernetes utilizando soluciones listas para usar de los repositorios de gráficos. Con este enfoque, el usuario aplica recetas de la comunidad o las suyas propias, asegurando la actualización oportuna de los componentes estándar de todos sus proyectos y la conveniencia de mantener soluciones en general.
Esta característica conveniente ahora está integrada en nuestra utilidad werf GitOps, que debería simplificar todo el proceso de operación de la infraestructura para aplicaciones ensambladas y desplegadas en Kubernetes.
Casco incorporado
Quizás el principal éxito de Helm, el "administrador de paquetes para Kubernetes", se asocie no tanto con su funcionalidad como con el
repositorio oficial de
gráficos y el soporte para repositorios en general. Las recetas y la configuración de los gráficos están acompañadas por una gran comunidad. Los especialistas respaldan las soluciones actualizadas que requieren los usuarios finales. Cada gráfico del repositorio oficial está estandarizado y bien documentado.
En casos triviales, el usuario ni siquiera necesita crear un gráfico para implementar la aplicación: solo encuentra una solución preparada, lee la documentación, prepara la configuración y utiliza el gráfico oficial.
Durante mucho tiempo, hemos estado utilizando Helm dentro de werf para implementar la infraestructura de la aplicación y ahora vamos más allá. A partir de la versión
v1.0.4-alpha.10 , los
comandos para trabajar con dependencias y repositorios de gráficos se han agregado a werf para abandonar completamente el cliente Helm.
Los principales comandos para esto:
werf helm repo
add Add a chart repository fetch Download a chart from a repository and (optionally) unpack it in local directory init Init default chart repositories configuration list List chart repositories remove Remove a chart repository search Search for a keyword in charts update Update information of available charts locally from chart repositories
werf helm dependency
build Rebuild the charts/ directory based on the requirements.lock file list List the dependencies update Update charts/ based on the contents of requirements.yaml
Además,
se ha agregado soporte para
referencia de gráfico al
werf helm deploy-chart .
Y así es como se ve toda esta magia en acción: más precisamente, aquí mostramos una comparación del despliegue del mismo gráfico en werf (izquierda) y en Helm (derecha):
Más práctica
Volviendo a la conveniencia de usar soluciones listas para implementar aplicaciones completas, un
ejemplo común con WordPress . La implementación de su tabla Helm en el clúster de Kubernetes usando werf podría verse así:
$ cat << EOF > values.yaml wordpressBlogName: flant wordpressUsername: admin wordpressPassword: password mariadb: mariadbRootPassword: password EOF $ werf helm deploy-chart --values values.yaml stable/wordpress my-web-app
→
Demostración en asciicinema .
Dado que los repositorios contienen
muchas soluciones , puede
crear sus propias aplicaciones a partir de ellos como cubos, donde los cubos serán los diversos gráficos Helm de los que depende todo el sistema. Lo más probable es que solo necesite configurar adecuadamente los componentes según sus necesidades.
Por ejemplo, una aplicación web requiere una cola, caché y almacenamiento de datos. ¿Cómo desplegamos estos componentes a través de werf?
Para comenzar, agilicemos la búsqueda de todo lo que necesita usando la CLI:
$ werf helm repo search queue NAME CHART VERSION APP VERSION DESCRIPTION stable/rabbitmq 6.4.1 3.7.17 Open source message broker software that implements the A... stable/rabbitmq-ha 1.31.0 3.7.15 Highly available RabbitMQ cluster, the open source messag...
Por analogía, encontraremos los componentes restantes para todos los repositorios de gráficos registrados (la lista de repositorios usados se puede ver ejecutando el
werf helm repo list ).
Después de encontrar todo, solo queda agregarlos al gráfico. Hay varias formas de hacer esto: agregue gráficos de componentes al directorio de gráficos o cree un archivo
werf helm dependency build|list|update y describa las dependencias, y luego interactúe con ellas usando
werf helm dependency build|list|update especiales de
werf helm dependency build|list|update .
Ilustración del segundo camino:
$ cat << EOF > .helm/requirements.yaml dependencies: - name: mysql version: 0.3.4 repository: "@stable" - name: redis version: 1.1.11 repository: "@stable" - name: rabbitmq version: 0.6.16 repository: "@stable" EOF $ werf helm dependency build $ werf deploy --env test
→
Demostración en asciicinema .
Durante el proceso de implementación, werf
creará todas las dependencias y las rastreará junto con el resto de los recursos; no se requieren acciones adicionales.
Como resultado, teniendo en cuenta la experiencia de la comunidad con experiencia, ahorrará significativamente tiempo en el desarrollo y mantenimiento de gráficos. Sin embargo, nadie lo restringe a usar gráficos públicos: puede desplegar sus gráficos con el mismo éxito, cuya configuración se prepara teniendo en cuenta los detalles necesarios.
Aquí se presenta la
documentación sobre los comandos de repositorio y dependencia en werf. También puede estar interesado en leer la documentación para obtener más detalles sobre
la implementación de werf y las
principales diferencias con respecto a Helm .
Conclusión
La ausencia de características críticas para nosotros en las soluciones de código abierto existentes nos obliga a crear las capacidades, enlaces e integración correspondientes. El proyecto werf fue creado y apoyado, en primer lugar, para resolver las tareas cotidianas de nuestros ingenieros de DevOps.
Como ejemplo, hemos estado trabajando durante mucho tiempo (¡segundo año!) Para que
nuestra propuesta de seguimiento de recursos en Helm sea aceptada como un modo alternativo en la base del código principal del proyecto (upstream). La comunidad aceptó y apoyó la idea, como Muchos necesitan esta oportunidad. Sin embargo, el progreso en esta dirección comenzó en
Helm 3 y solo ahora ...
Hasta ahora, la implementación de esta idea en Helm ha sido prácticamente bloqueada por los desarrolladores. Sin embargo, durante este tiempo hemos desarrollado las funciones correspondientes para el seguimiento de recursos en una biblioteca de código abierto separada,
kubedog , y ya la estamos utilizando en werf. Y a juzgar por la actividad en GitHub, la biblioteca encontró interés entre otros usuarios de Kubernetes / Helm, lo cual es muy agradable.
Puede apoyar nuestra idea (e implementación) colocando una estrella en el proyecto kubedog en GitHub y / o aprobado en el
número original de Helm. Gracias
PS
Lea también en nuestro blog: