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.

Imagen base

Lo que originalmente debía ser tan sencillo como un cambio de imagen base, no ha funcionado a la primera.

La imagen base que pensaba utilizar era xaviaznar/rpi-alpine-base. Esta imagen está basada en hypriot/rpi-alpine-scratch, pero resulta que esta imagen no se actualiza desde hace más de un año:

Así que los paquetes de PHP 7 no estaban todavía incluidos en los repositorios y la construcción de la imagen ha fallado.

Afortunadamente existen una imagenes semi-oficiales para ARM de la mano de arm32v6 (para Raspberry Pi “1”) y arm32v7 (para las Raspberry 2 y 3).

Así que para la RPi 1, he usado como base arm32v6/alpine.

La dependencia de imágenes base de terceros es uno de los problemas que hay que tener en cuenta en el diseño de los contenedores. Esto es especialmente sensible para equipos ARM para los cuales todavía no hay siempre una imagen oficial del desarrollador del producto y se depende de imágenes creadas por voluntarios.

Rutas (de nuevo)

En la entrada anterior los ficheros del wiki se encontraba en la carpeta ~/dokuwiki, por lo que montaba el volumen en comando docker run el volumen mediante -v /home/operador/dokuwiki:/var/www. En el fichero Caddyfile sin embargo, la raíz de las carpetas publicadas por Caddy root /var/www/wiki.

Es decir, en el sistema de ficheros locales tenía ~/dokuwiki/wiki/{ficheros php}, pero debido a la similitud de los nombres, pensaba que tenía ~/dokuwiki/{ficheros php}, por lo que he estado un buen rato intentando averiguar el porqué de los errores 404 que mostraba el navegador, los logs, etc.

Para evitar este tipo de errores en el futuro, la raíz de las carpetas públicas en Caddy será siempre /var/www. Los ficheros locales siempre estarán en una carpeta llamada www, que será la que se monte sobre ésta carpeta del contenedor.

Otro punto que hay que tener en cuenta es que el contenido de la carpeta del contenedor sobre la que se monta la carpeta del host no se fusiona con el contenido de ésta: sólo son visibles los ficheros de la carpeta del host montada en el contenedor.

En mi caso, por ejemplo, al construir la imagen se copian los ficheros index.htm y phpinfo.php en /var/www. Pero cuando se monta la carpeta ~/wiki en /var/wwww, sólo aparecen los ficheros presentes en ~/wiki. Los ficheros index.php y phpinfo.php sólo son visibles si no se monta un volumen en el contenedor.

File not found al acceder a http://$IPHOST:puerto/

Al acceder a la URL del servidor web sin indicar el nombre del fichero, por defecto se busca un fichero llamado index.html. En mi caso, como el fichero se llamaba index.htm (sin la “l” final), se mostraba un error File Not Found.

He renombrado el fichero de index.htm a index.html después de consultar la documentación de Caddy para que no suceda. En el fichero index.html he incluido un enlace al fichero phpinfo.php para verificar la configuración de PHP en el contenedor.

Volúmenes compartidos entre el host y el contenedor

Para simplificar la organización de las carpetas montadas en los contenedores, he creado una carpeta llamada /shared, en la raíz del árbol de carpetas. Dentro de esta carpeta habrá una carpeta para cada contenedor que tenga un volumen local montado.

Para el caso anterior, si el contenedor tiene por nombre wiki, cada uno de los volúmenes montados será una subcarpeta de ésta.

Un ejemplo:

/shared/
├── wiki/
│   ├── www/
│   └── logs/
├── otro_contenedor/
│   ├── foo/
│   └── bar/

Este cambio hace que tenga que modificar todos los lanzadores -como el runWiki.sh-, aunque es un problema menor; una vez que el contenedor se ha lanzado, se puede gestionar el arranque y la parada mediante docker start/stop $NOMBRE_CONTENEDOR.

Siguientes pasos

Una vez he resuelto todos los problemas que han ido apareciendo en esta fase de desarrollo, el siguiente paso es documentar todos los pasos -correctos- que hay que dar para obtener tanto la imagen con Caddy y PHP como para usarla en un contenedor sirviendo una aplicación web en PHP.

Actualización: Ya está lista la guía paso a paso: Cómo crear una imagen con Caddy y PHP