Photo by Mabel Amber
En las entradas anteriores he descrito los problemas -tanto conceptuales como técnicos- que he encontrado al intentar llevar Dokuwiki a un contenedor.
En este artículo explico los pasos a seguir para construir una imagen con Caddy server y PHP, de manera que puedas servir tus aplicaciones PHP usando contenedores.
En la entrada anterior Dokuwiki en un contendor dejaba constancia de los problemas que encontré creando una imagen para ejecutar Dokuwiki en un contenedor.
Al final de la entrada indicaba que la creación de la misma imagen, pero para ARM sería tan sencillo como cambiar la imagen base. Pues no.
Como he tenido que revisar a fondo los pasos que seguí -en particular para configurar la carpeta desde donde Caddy publica los ficheros-, he introducido algunos cambios que simplifiquen y mejoren el uso de la imagen.
Antes de convertir todas las Raspberry Pi de casa en hosts de Docker, usaba la Raspberry Pi B+ como wiki casero. En él documentaba todo lo que iba aprendiendo sobre las diferentes tecnologías de mi día a día.
Hoy he vuelto a instalar Dokuwiki, aunque esta vez usando un contenedor. En este artículo comento algunos de los puntos relevantes que han surgido durante el proceso.
Minio proporciona un servidor de almacenamiento distribuido compatible con el API de Amazon AWS S3.
En esta entrada comento las pruebas que he estado realizando usando Minio tanto el cliente como el servidor en contenedores Docker.
Como indicaba en la entrada la anterior entrada Almacenamiento en Kubernetes: problema abierto, el problema de proporcionar almacenamiento persistente para las aplicaciones desplegadas en Kubernetes sigue sin tener una solución general.
En este artículo comento una solución particular al problema del almacenamiento basada en el uso de un contenedor sidecar.
Hace unas semanas descubrí el sitio PWK, Play with Kubernetes. Su creador, Marcos Nils explica en Introducing PWK (Play with K8s) que tenía ganas de extender la plataforma PWD (Play with Docker) a Kubernetes.
El sitio PWK permite montar clústers de Kubernetes y lanzar servicios replicados de manera rápida y sencilla. Se trata de un entorno donde realizar pruebas y jugar durante cuatro horas con varias instancias de Docker sobre las que podemos usar kubeadm para instalar y configurar Kubernetes, creando un clúster en menos de un minuto.
Esta entrada es un registro de las diferentes acciones que realicé para conseguir que los pods asociados al StatefulSet del tutorial StatefulSet Basics se crearan correctamente.
Lo publico como lo que es, un log de todos los pasos que fui dando, en modo ensayo y error, hasta que conseguí que los pods se crearan con éxito. Mi intención al publicarlo no es tanto que sirva como referencia sino como archivo. Y si alguien se encuentra con un problema similar, que pueda consultar los pasos que he dado durante el troubleshooting.
Como indicaba en el artículo anterior, quiero publicar un tutorial paso a paso con el proceso correcto para provisionar los PersistentVolumes necesarios para el tutorial StatefulSet Basics del sitio de Kubernetes.
Leía el otro día que desde el principio la tendencia hacia los microservicios estaba pensada para las aplicaciones stateless, es decir, sin “memoria” del estado, donde cada interacción con la aplicación se considera independiente del resto. El ejemplo clásico de aplicación stateless es un servidor web. Así que no es de extrañar que la aplicación que siempre aparece en todo tutorial que se precie de Docker/Kubernetes es Nginx.
En el mundo real, sin embargo, la mayoría de aplicaciones requieren algún tipo de persistencia, incluso las webs más sencillas (así surgieron las cookies). Pero por el momento, Kubernetes y el almacenamiento son dos conceptos que no combinan demasiado bien, aunque funcionan perfectamente por separado.
Cuando se crea un pod se pueden reservar recursos de CPU y RAM para los contenedores que corren en el pod. Para reservar recursos, usa el campo resources: requests en el fichero de configuración. Para establecer límites, usa el campo resources: limits.
Los namespaces (espacios de nombres) en Kubernetes permiten establecer un nivel adicional de separación entre los contenedores que comparten los recursos de un clúster.
Esto es especialmente útil cuando diferentes grupos de DevOps usan el mismo clúster y existe el riesgo potencial de colisión de nombres de los pods, etc usados por los diferentes equipos.
