El uso de subgráficos de múltiples instancias de Helm como parte de tu gráfico principal podría ser algo que, desde el principio, puede sonar extraño. Ya comentamos sobre los subgráficos y dependencias de los gráficos de helm en el blog porque el caso de uso habitual es así:
Tengo un gráfico que necesita otro componente, y lo «importo» como un subgráfico, lo que me da la posibilidad de desplegar el mismo componente y personalizar sus valores sin necesidad de crear otra copia del gráfico y, como puedes imaginar, simplificando mucho la gestión de los gráficos, un ejemplo puede ser así:
Entonces, creo que eso está totalmente claro, pero ¿de qué estamos hablando ahora? El caso de uso es tener el mismo subgráfico definido dos veces. Así que, imagina este escenario, estamos hablando de eso en lugar de esto:
# Chart.yaml
dependencies:
- name: nginx
version: "1.2.3"
repository: "https://example.com/charts"
- name: memcached
version: "3.2.1"
repository: "https://another.example.com/charts"
Estamos teniendo algo como esto
# Chart.yaml
dependencies:
- name: nginx
version: "1.2.3"
repository: "https://example.com/charts"
- name: memcached-copy1
version: "3.2.1"
repository: "https://another.example.com/charts"
- name: memcached-copy2
version: "3.2.1"
repository: "https://another.example.com/charts"
Así que tenemos la opción de definir más de una «instancia» del mismo subgráfico. Y supongo que, en este momento, puedes empezar a preguntarte: «¿Cuáles son los casos de uso donde podría necesitar esto?»
Porque eso es bastante comprensible, a menos que lo necesites nunca te darás cuenta de eso. Es lo mismo que me pasa a mí. Así que hablemos un poco sobre posibles casos de uso para esto.
Casos de Uso para Dependencia de Múltiples Instancias de Helm
Imagina que estás desplegando un gráfico de helm para un conjunto de microservicios que pertenecen al ámbito de la misma aplicación y cada uno de los microservicios tiene la misma base tecnológica, que puede ser TIBCO BusinessWorks Container Edition o pueden ser microservicios Golang. Así que todos ellos tienen la misma base por lo que pueden usar el mismo gráfico «bwce-microservice» o «golang-microservices» pero cada uno de ellos tiene su propia configuración, por ejemplo:
- Cada uno de ellos tendrá su propio nombre de imagen que diferirá de uno a otro.
- Cada uno de ellos tendrá su propia configuración que diferirá de uno a otro.
- Cada uno de ellos tendrá sus propios puntos de conexión que diferirán y probablemente incluso se conectarán a diferentes fuentes como bases de datos o sistemas externos.
Así que, este enfoque nos ayudaría a reutilizar el mismo gráfico de helm tecnológico, «bwce» e instanciarlo varias veces, para que podamos tener cada uno de ellos con su propia configuración sin la necesidad de crear algo «personalizado» y manteniendo los mismos beneficios en términos de mantenibilidad que el enfoque de dependencia de helm nos proporciona.
¿Cómo podemos implementar esto?
Ahora que tenemos claro el caso de uso que vamos a soportar, el siguiente paso es sobre cómo podemos hacer esto una realidad. Y, para ser honesto, esto es mucho más simple de lo que puedes pensar desde el principio, comencemos con la situación normal cuando tenemos un gráfico principal, llamémoslo un «programa», que ha incluido una plantilla «bwce» como una dependencia como puedes ver aquí:
name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon:
appVersion: 2.7.2
dependencies:
- name: bwce
version: ~1.0.0
repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"
Y ahora, vamos a movernos a un enfoque de múltiples instancias donde requeriremos dos microservicios diferentes, llamémoslos serviceA y serviceB, y ambos usarán el mismo gráfico de helm bwce.
Así que lo primero que modificaremos es el Chart.yaml de la siguiente manera:
name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon:
appVersion: 2.7.2
dependencies:
- name: bwce
alias: serviceA
version: ~0.2.0
repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"
- name: bwce
alias: serviceB
version: ~0.2.0
repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"
La parte importante aquí es cómo declaramos la dependencia. Como puedes ver en el nombre seguimos manteniendo el mismo «nombre» pero tienen un campo adicional llamado «alias» y este alias es lo que nos ayudará a identificar más tarde las propiedades para cada una de las instancias según lo requiramos. Con eso, ya tenemos nuestra definición de instancia de serviceA y serviceB y podemos comenzar a usarlo en el values.yml de la siguiente manera:
# Este es un archivo con formato YAML.
# Declara variables para ser pasadas a tus plantillas.
serviceA:
image:
imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceA:2.5.2
pullPolicy: Always
serviceB:
image:
imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceB:2.5.2
pullPolicy: Always
Conclusión
El principal beneficio de esto es que mejora las opciones de usar gráficos de helm para aplicaciones «complejas» que requieren diferentes instancias del mismo tipo de componentes y al mismo tiempo.
Eso no significa que necesites un gráfico de helm enorme para tu proyecto porque esto iría en contra de todas las mejores prácticas del enfoque de contenedorización y microservicios, pero al menos te dará la opción de definir diferentes niveles de abstracción como desees, manteniendo todos los beneficios desde una perspectiva de gestión.
