89 lines
4.1 KiB
Markdown
89 lines
4.1 KiB
Markdown
# Decisiones de diseño del chart
|
|
|
|
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.
|
|
|
|
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"
|
|
```
|
|
|
|
## Flexibilidad con el dominio
|
|
|
|
En `ingress` se repite el `host` debido a que esto facilita que la api pueda estar en otro dominio. Por ejemplo:
|
|
|
|
```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
|
|
```
|
|
|
|
## 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.*`.
|
|
|
|
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 `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 `helm upgrade`
|
|
|
|
Si se quiere actualizar los autogenerados por helm los pasos son:
|
|
|
|
1) Borrar `exam-crt`
|
|
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!
|
|
|
|
## Stateful para postgres
|
|
|
|
Se eligió implementar un archivo `stateful.yaml` ya que necesitamos que postgres sea una aplicación con "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.
|
|
|
|
Notemos que de usar un deployment tendríamos muchos problemas con el `stop` de la aplicación ya que están compartiendo el mismo volumen de datos al mismo tiempo (pues hasta que no levante correctamente el nuevo pod el viejo seguirá activo y luego parará). Esto podría pasar que se corrompa la base de datos. Se arregla simplemente con un StatefulSet este problema.
|
|
|
|
Por otro lado, si estuvisemos usando un cluster el `RollingUpdate` nos salvaría de una imagen que no existe por ejemplo ya que empieza por los pods con cardinal más alto y si alguno falla no sigue actualizando.
|
|
|
|
## Tests de conexión
|
|
|
|
Se pueden correr con `helm test exam -n exam` |