# Decisiones de diseño del chart Helm ## Introducción Este readme explica algunas de las decisiones de diseño tomadas durante el desarrollo del chart Helm. El objetivo es proporcionar información sobre las razones detrás de ciertas configuraciones en el archivo `values.yaml`. ## Valores predeterminados para eliminar redundancias ### Configuración del servicio En el archivo `service.yaml`, se han establecido valores predeterminados para ciertos parámetros, como `type` y `targetPort`. Por ejemplo, el `type` se establece en "ClusterIP" de forma predeterminada, y `targetPort` se establece en `$port`. **Beneficios:** 1. **Eliminación de redundancias:** Los valores predeterminados reducen la redundancia en el archivo `values.yaml`. Los usuarios pueden centrarse en personalizar valores específicos de su implementación. 2. **Flexibilidad:** Los usuarios tienen la libertad de modificar estos valores predeterminados en el archivo `values.yaml` sin necesidad de especificarlos explícitamente para cada servicio. Por ejemplo, cambiar el `type` a "NodePort" para el servicio `api` es tan simple como actualizar `values.yaml`. ```yaml services: - api: name: "api" tier: "backend" port: 5000 type: "NodePort" ``` ## Configuración de Ingress para flexibilidad de dominio En el archivo `ingress.yaml`, el campo `host` se repite para cada ruta. Esta elección de diseño permite la flexibilidad de alojar la API en un dominio diferente si así se desea. ```yaml ingress: ssl: true annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true" hosts: - host: kube.slc.ar paths: - path: / name: "client" port: 8080 pathType: "Prefix" - host: api.kube.slc.ar paths: - path: / name: "api" port: 5000 pathType: "Prefix" tls: - secretName: exam-crt hosts: - kube.slc.ar - api.kube.slc.ar ``` **Beneficio:** - **Flexibilidad de dominio:** La repetición del campo `host` en cada ruta proporciona la flexibilidad de alojar la API en un dominio diferente (`api.kube.slc.ar` en este ejemplo). Los usuarios pueden personalizar fácilmente la sección `hosts` en el archivo `values.yaml` según sus requisitos de dominio específicos. Estas elecciones de diseño buscan simplificar la gestión de la configuración, reducir la redundancia y proporcionar a los usuarios la flexibilidad de adaptar el chart Helm a sus necesidades de implementación. ------------------------------------------------------------------------------------------ Todas las variables que se repiten y que, en un principio, no tendría sentido cambiarlas para este chart se marcaron con default. Por ejemplo, busque los default de service.yaml. Verá que `type` es por defecto "ClusterIP" y que `targetPort` es por defecto `$port`. Esto tiene dos beneficios: 1) Elimina redundancia en values.yaml 2) Da libertad para que en un futuro se pueda simplemente modificarlo en `values.yaml`. Por ejemplo, supongamos que queremos cambiar el `type` a "NodePort" en el servicio de `api`, basta con hacer el siguiente cambio: ```yaml services: - api: name: "api" tier: "backend" port: 5000 type: "NodePort" ``` ---------- En `ingress` se repite el `host` debido a facilita que la api pueda estar en otro dominio, si así se desea: ```yaml ingress: ssl: true annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true" hosts: - host: kube.slc.ar paths: - path: / name: "client" port: 8080 pathType: "Prefix" - host: api.kube.slc.ar - path: / name: "api" port: 5000 pathType: "Prefix" tls: - secretName: exam-crt hosts: - kube.slc.ar - api.kube.slc.ar ```