Update README.md
This commit is contained in:
parent
ecca63c187
commit
af59f6d678
102
helm/README.md
102
helm/README.md
|
|
@ -1,70 +1,12 @@
|
|||
# Decisiones de diseño del chart Helm
|
||||
# Decisiones de diseño del chart
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
|
||||
|
||||
------------------------------------------------------------------------------------------
|
||||
Este README explica algunas de las decisiones de diseño tomadas durante el desarrollo del chart `helm`.
|
||||
|
||||
## Uso de namespace
|
||||
|
||||
Se utiliza el namespace `exam` para poder aislar los recursos (con todos los beneficios que eso trae) y no usar el namespace `default`.
|
||||
|
||||
## Uso de default values
|
||||
|
||||
Todas las variables que se repiten y que, en un principio, no tendría sentido cambiarlas para este chart se marcaron con default.
|
||||
|
||||
|
|
@ -84,9 +26,9 @@ services:
|
|||
type: "NodePort"
|
||||
```
|
||||
|
||||
----------
|
||||
## Flexibilidad con el dominio
|
||||
|
||||
En `ingress` se repite el `host` debido a facilita que la api pueda estar en otro dominio, si así se desea:
|
||||
En `ingress` se repite el `host` debido a que esto facilita que la api pueda estar en otro dominio. Por ejemplo:
|
||||
|
||||
```yaml
|
||||
ingress:
|
||||
|
|
@ -112,37 +54,33 @@ ingress:
|
|||
- api.kube.slc.ar
|
||||
```
|
||||
|
||||
## Certicados para el ingress
|
||||
|
||||
|
||||
----
|
||||
|
||||
|
||||
Se puede pasar certificados autogenerados en ingress.ssl.* PERO se debe notar las restricciones de helm de seguridad: solo se pueden usar archivos relativos al path del chart. Por lo tanto, si se desea usar un archivo de "afuera" se puede hacer un symbolic link. Por ejemplo: cd helm && ln -sf /usr/local/etc/ssl/certs/ca.crt ca.crt && ln -sf /usr/local/etc/ssl/private/ca.key ca.key. Y luego se puede pasar esos archivos al ingress.ssl.*.
|
||||
Se puede pasar certificados autogenerados en `ingress.ssl.*` PERO se debe notar las restricciones de `helm` de seguridad: solo se pueden usar archivos relativos al path del chart. Por lo tanto, si se desea usar un archivo de "afuera" se puede hacer un symbolic link. Por ejemplo: `cd helm && ln -sf /usr/local/etc/ssl/certs/ca.crt ca.crt && ln -sf /usr/local/etc/ssl/private/ca.key ca.key`. Y luego se puede pasar esos archivos al `ingress.ssl.*`.
|
||||
|
||||
Note que para que se usen estos secrets:
|
||||
1) si ya existía el secret-crt se debe borrar y hacer un helm upgrade
|
||||
2) si no existía con un install basta (o mismo un upgrade si ya estaba andando)
|
||||
1) si ya existía el `secret-crt` se debe borrar y hacer un `helm upgrade`
|
||||
2) si no existía con un `helm install` basta (o mismo un `helm upgrade` si ya estaba andando)
|
||||
|
||||
Por lo tanto, supongamos que se quieren actualizar los certificados por unos autogenerados por usted (y para actualizarlos una vez expirados los autogenerados por usted). Los pasos son los siguientes:
|
||||
|
||||
1) Borrar `exam-crt`
|
||||
2) Actualizar certificados
|
||||
3) Ponerlos en el values.yaml de haberse modificado el path o si antes se usaba uno autogenerado por helm
|
||||
4) Hacer upgrade
|
||||
3) Ponerlos en el `values.yaml` de haberse modificado el path o si antes se usaba uno autogenerado por helm
|
||||
4) Hacer `helm upgrade`
|
||||
|
||||
Si se quiere actualizar los autogenerados por helm los pasos son:
|
||||
|
||||
1) Borrar `exam-crt`
|
||||
2) Hacer upgrade
|
||||
2) Hacer `helm upgrade`
|
||||
|
||||
Note que si se hace un upgrade solo NO se regenerará el exam-crt. Esto es esperado ya que sino cada vez que modificamos algo se estará autogenerando un nuevo certificado!!
|
||||
Note que si se hace un upgrade solo NO se regenerará el `exam-crt`. Esto es esperado ya que sino cada vez que modificamos algo se estará autogenerando un nuevo certificado!
|
||||
|
||||
|
||||
---
|
||||
## Stateful para postgres
|
||||
|
||||
Se eligió usar stateful debido ya que necesitamos que sea una aplicación "Stable, persistent storage" (ver (documentación)[https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#using-statefulsets]). Además, en un futuro, si quisieramos tener READ replicas se podría hacer muy fácilmente agregando containers y la lógica necesaria. Para ese caso se debe usar si o si un stateful set para mantener al master siempre identificado. Lo dejé como algo más bien future-proof.
|
||||
|
||||
# Race condition:
|
||||
# https://www.postgresql.org/message-id/CA+TgmoZAdYVtwBfp1FL2sMZbiHCWT4UPrzRLNnX1Nb30Ku3-gg@mail.gmail.com
|
||||
# with app.app_context():
|
||||
# db.create_all()
|
||||
# return app
|
||||
## Tests de conexión
|
||||
|
||||
Se pueden correr con `helm test exam -n exam`
|
||||
|
|
@ -10,10 +10,10 @@ spec:
|
|||
containers:
|
||||
- name: wget-client
|
||||
image: busybox
|
||||
command: ['wget']
|
||||
command: ['wget', '--no-check-certificate']
|
||||
args: ['http://{{ include "exam.host" . }}']
|
||||
- name: wget-api
|
||||
image: busybox
|
||||
command: ['wget']
|
||||
command: ['wget', '--no-check-certificate']
|
||||
args: ['http://{{ include "exam.host" $ }}/api/ping']
|
||||
restartPolicy: Never
|
||||
|
|
|
|||
Loading…
Reference in New Issue