Desplegando applicaciones con Helm

Si ya estás familiarizado con Helm y los diferentes tipos de workloads/tipos de recursos de Kubernetes, podrías preguntarte cómo instalar aplicaciones directamente en Kubernetes. Sí, no tienes que reinventar la rueda para tu instalación de MySQL, o tu Postgres, o Nginx, Jenkins, lo que sea. Helm resuelve ese problema con Charts. Esta lista contiene los charts oficiales mantenidos por la comunidad, donde la carpeta ‘incubator’ puede referirse a charts que aún no cumplen con los requisitos técnicos pero probablemente utilizables, y la carpeta ‘stable’ es para charts graduados. Como puedes imaginar, esta no es la única fuente de charts. Puedes usar cualquier fuente para tus charts, incluso los archivos tgz, como veremos en este post. <br />

¿Cómo busco charts?:

$ helm search wordpress
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
stable/wordpress        3.3.0           4.9.8           Web publishing platform for building blogs and websites.

Nota que no soy fan de WordPress o PHP en sí, pero parece ser el ejemplo más común en todas partes. Como vemos aquí, dice stable/wordpress, así que sabemos que estamos usando el repositorio oficial en la carpeta ‘stable’. Pero, ¿y si no queremos ese chart, sino que alguien más proporciona uno con más características o algo que te guste más? Usemos el de Bitnami. Si revisamos su página, puedes seleccionar diferentes tipos de despliegues, pero para que funcione necesitamos añadir otro repositorio externo:

helm repo add bitnami https://charts.bitnami.com/bitnami

sí que si buscamos de nuevo, ahora veremos dos opciones (en el momento de escribir esto, la versión más reciente es en realidad la 5.0.2):

$ helm search wordpress
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
bitnami/wordpress       5.0.2           5.0.2           Web publishing platform for building blogs and websites.
stable/wordpress        3.3.0           4.9.8           Web publishing platform for building blogs and websites.

Revisemos la documentación del chart para crear nuestro archivo values.yaml. Nota que en este ejemplo el chart de WordPress estable también es mantenido por Bitnami, así que tienen la misma configuración :). Esto no siempre será el caso, pero nos simplifica las cosas.

Nuestro ejemplo de values.yaml se verá así:

wordpressBlogName: "Testing Helm Charts"
persistence:
  size: 1Gi
ingress:
  enabled: true

Solo cambiaremos el nombre del blog por defecto, el tamaño del volumen persistente y también habilitaremos ingress (nuestra aplicación debería estar disponible a través de wordpress.local dentro del clúster). Si estás usando Minikube, asegúrate de habilitar el addon de ingress.

$ minikube addons enable ingress
ingress was successfully enabled

Podemos entonces instalar stable/wordpress o bitnami/wordpress; continuaremos con el del repositorio de Bitnami.

$ helm install bitnami/wordpress \
--set image.repository=bitnami/wordpress \
--set image.tag=5.0.2 \
-f values.yaml

Como es una buena práctica usar versiones específicas, lo haremos aquí. Es mejor hacerlo de esta manera porque puedes moverte fácilmente entre versiones conocidas y también evitar estados desconocidos; esto puede suceder al malinterpretar lo que significa ‘latest’. Sigue el ejemplo.

Deberías ver algo como:

NAME:   plucking-condor
LAST DEPLOYED: Mon Dec 24 13:06:38 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Pod(related)
NAME                                        READY  STATUS             RESTARTS  AGE
plucking-condor-wordpress-84845db8b5-hkqhc  0/1    ContainerCreating  0         0s
plucking-condor-mariadb-0                   0/1    Pending            0         0s

==> v1/Secret

NAME                       AGE
plucking-condor-mariadb    0s
plucking-condor-wordpress  0s

==> v1/ConfigMap
plucking-condor-mariadb        0s
plucking-condor-mariadb-tests  0s

==> v1/PersistentVolumeClaim
plucking-condor-wordpress  0s

==> v1/Service
plucking-condor-mariadb    0s
plucking-condor-wordpress  0s

==> v1beta1/Deployment
plucking-condor-wordpress  0s

==> v1beta1/StatefulSet
plucking-condor-mariadb  0s

==> v1beta1/Ingress
wordpress.local-plucking-condor  0s


NOTES:
1. Get the WordPress URL:

  You should be able to access your new WordPress installation through
  http://wordpress.local/admin

2. Login with the following credentials to see your blog

  echo Username: user
  echo Password: $(kubectl get secret --namespace default plucking-condor-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

Dependiendo del proveedor del clúster o de la instalación en sí, podrías necesitar reemplazar persistence.storageClass para que coincida con lo que tiene tu clúster. Nota que en el archivo de valores se representa como JSON con notación de puntos, pero en tu values.yaml necesitas ceñirte al formato YAML e indentar storageClass bajo persistence como de costumbre. La API de Kubernetes analiza y usa JSON, pero YAML parece más amigable para los humanos.

En este punto deberíamos tener una instalación de WordPress funcionando y también movernos entre versiones. Pero ten en cuenta que la aplicación se encarga del esquema de la base de datos y de actualizarlo para que coincida con lo que necesita la nueva versión. Esto también puede ser problemático al revertir o al degradar. Así que si usas datos persistentes, SIEMPRE ten una copia de seguridad funcional, porque cuando las cosas van mal, querrás volver rápidamente a un estado conocido. También nota que dije “copia de seguridad funcional”: sí, prueba que la copia de seguridad funcione y que puedas restaurarla en otro lugar antes de hacer algo destructivo o que pueda tener repercusiones. Esto te brindará tranquilidad y mejores maneras de organizarte mientras actualizas, etc.

Ahora verifiquemos que todos los recursos están realmente funcionando y que podemos usar nuestra aplicación recién instalada.

$ kubectl get all
NAME                                             READY     STATUS        RESTARTS   AGE
pod/plucking-condor-mariadb-0                    1/1       Running       0          12m
pod/plucking-condor-wordpress-84845db8b5-hkqhc   1/1       Running       0          12m

NAME                                TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
service/kubernetes                  ClusterIP      10.96.0.1        <none>           443/TCP                      37h
service/plucking-condor-mariadb     ClusterIP      10.106.219.59    <none>           3306/TCP                     12m
service/plucking-condor-wordpress   LoadBalancer   10.100.239.163   10.100.239.163   80:31764/TCP,443:32308/TCP   12m

NAME                                        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/plucking-condor-wordpress   1         1         1            1           12m

NAME                                                   DESIRED   CURRENT   READY     AGE
replicaset.apps/plucking-condor-wordpress-84845db8b5   1         1         1         12m

NAME                                       DESIRED   CURRENT   AGE
statefulset.apps/plucking-condor-mariadb   1         1         12m

Puedes desplegarlo en un espacio de nombres personalizado (en este caso lo desplegué en el espacio de nombres por defecto); el único cambio para eso sería establecer el parámetro –namespace en la línea de helm install. <br />

Si usas Minikube, entonces ingress expondrá un nodeport que podemos encontrar usando minikube service list y luego, usando el navegador o curl, navegar por nuestro WordPress recién instalado.

 $ minikube service list
|-------------|---------------------------|--------------------------------|
|  NAMESPACE  |           NAME            |              URL               |
|-------------|---------------------------|--------------------------------|
| default     | kubernetes                | No node port                   |
| default     | plucking-condor-mariadb   | No node port                   |
| default     | plucking-condor-wordpress | http://192.168.99.100:31764    |
|             |                           | http://192.168.99.100:32308    |
| kube-system | default-http-backend      | http://192.168.99.100:30001    |
| kube-system | kube-dns                  | No node port                   |
| kube-system | kubernetes-dashboard      | No node port                   |
| kube-system | tiller-deploy             | No node port                   |
|-------------|---------------------------|--------------------------------|

En la nube o en instalaciones locales, esto será diferente y deberías tener una instalación disponible públicamente usando tu propio nombre de dominio (en este caso, HTTP está en: http://192.168.99.100:31764 y HTTPS en: http://192.168.99.100:32308, y http://192.168.99.100:30001 es el backend predeterminado para el controlador de ingress). Tus IPs pueden ser diferentes, pero los fundamentos son los mismos.

Ejemplo:

Notes

Mientras tengamos el volumen persistente, nuestros datos deberían preservarse. En este caso, el PV se usa para la base de datos, pero podríamos agregar otro volumen para preservar imágenes, etc.

Limpiando:

helm del --purge plucking-condor

Eso es todo por ahora; estaré agregando más contenido la próxima semana.

Don’t Repeat Yourself

DRY es un buen objetivo de diseño y parte del arte de una buena plantilla es saber cuándo añadir una nueva plantilla y cuándo actualizar o usar una existente. Aunque Helm y Go ayudan con eso, no hay una herramienta perfecta, así que exploraremos otras opciones en los siguientes posts. Exploraremos lo que la comunidad proporciona y lo que parece una herramienta adecuada para ti. ¡Happy Helming!

Proximos temas

• Empezando con Ksonnet y amigos.
• Empezando con Skaffold.
• Empezando con Gitkube.

Erratas

Si encuentras algún error o tienes alguna sugerencia, por favor envíame un mensaje para que pueda corregirlo.