En Tanta hemos pensado en prestarle un poco más de atención a nuestra propia web, pero más allá de arreglar un par de bugs, hemos pensado que nuestra web podría ser un buen banco de pruebas para todas las cosas que estamos empezando a usar en nuestros desarrollos con el fin de mejorar la calidad del código que entregamos.

Nuestra web está construída hace ya algún tiempo y usa Drupal 6. Además, tenemos un blog que está construido usando WordPress. No tenemos en ella ningún dato que pueda ser considerado privado o que no podamos enseñar al mundo. Por eso, y aunque tenemos una cuenta privada en Bitbucket, hemos decidido llevarnos este proyecto a Github y hacerlo público. Github nos permite además trabajar con Travis, herramienta que nos gusta especialmente.

Así pues, nuestro código ahora puede verse en https://github.com/Tantacom/tantacom-web

Cualquiera puede hacer un fork y colaborar en nuestra web. ¡Estáis invitados!

Ramas en nuestro repositorio.

Como decíamos, nuestra web está hecha con drupal 6, en concreto la versión es drupal 6.38. Nuestra intención es pasarla a drupal 8, manteniendo estilo y funcionalidad. Pero eso puede llevarnos un tiempo, por lo que de momento vamos a mantener dos ramas. Una la hemos llamado 6.x. En ella iremos poniendo el código necesario para lo que se nos vaya ocurriendo mientras la web siga usando Drupal 6 como base.

En la rama drupal-8 iremos construyendo nuestra nueva web.

Docker en nuestro desarrollo.

Uno de los problemas a los que a veces nos enfrentamos es que si bien nosotros solemos actualizar nuestros entornos de desarrollo a las últimas versiones de software disponible (por ejemplo, ubuntu 16.04 viene con php 7 ya instalado) nuestros clientes, lógicamente, son más conservadores a la hora de actualizar dichas versiones. Así, que debemos intentar simular los entornos de nuestros clientes de forma que no nos vayamos a encontrar con problemas posteriores en subidas. Un caso típico es usar una notación corta para definir un array en PHP. Esto no es posible en php 5.3 y si no lo detectamos en desarrollo podemos tener un buen problema en producción.

Hemos usado Vagrant en el pasado, pero últimamente hemos oído cosas muy buenas sobre Docker y nos hemos decidido a probarlo con nuestra web. No es nuestro objetivo contaros qué es Docker y cuáles son sus ventajas.. Para eso hay gente que lo hace mucho mejor que nosotros, como Ana M. García en este artículo del blog de Javier Garzas.

Por resumir, sabiendo que en producción tenemos un Ubuntu trusty, lo que va a hacer cada uno de los desarrolladores es simular ese entorno de producción en sus máquinas, independientemente de la versión de linux que utilicen, el apache, php o mysql que tengan

Para empezar, hemos buscado una imagen que nos pudiese proporcionar una instalación de Drupal en un Ubuntu Trusty (14.04) y hemos dado con este proyecto, que no sólo nos ha servido para empezar sino que nos da aún más facilidades de las que esperábamos.

Por ejemplo, podemos crear una instalación limpia de Drupal 8 o hacer que esa instalación tenga como base una de las ramas de nuestro repositorio en Github, lo cual nos puede venir de perlas a la hora de hacer testing automático.

Hemos modificado un poco el DockerFile y el start.sh provistos por ese proyecto para adecuarlo a nuestras necesidades. Por ejemplo, hemos añadido una copia de la base de datos actual (drupal 6), otra ya en drupal 8 con el contenido que ya hemos migrado así como en la carpeta sites/default/files para que, en el caso de que tengamos que trabajar con la versión actual de la web, cualquiera pueda montarse un nuevo entorno con un simple comando.

Todo esto también lo tenemos disponible de forma pública en https://github.com/Tantacom/tanta-docker

Así, por ejemplo, para simular el estado de la web actual en producción hacemos:

docker run -t -p 8009:80 -p 3309:3306 -e "DRUPAL_VERSION=drupal-6" -e "DRUPAL_GIT_REPO=https://tantacom:**********@github.com/tantacom/tantacom-web" -e "DRUPAL_GIT_BRANCH=6.x" -e "CUSTOM_DB=/tantaweb.sql" -v /var/www/tanta6:/var/www/html --name tanta6 tanta-web

Con ese comando creamos un container en el que exponemos los puertos 80 (apache) y 3306 (mysql) asignándoles los puertos 8009 y 3309 en el host. Le decimos que nos coja el código de nuestro repositorio en la su rama “6.x”. Además, le pasamos un archivo sql que importaremos en la base de datos. Este puede ser una copia de producción u otro que nos sirva simplemente como testing.

Por último, con la opción -v montamos volúmenes de tal manera que podamos acceder a los archivos del desarrollo desde cualquiera de nuestros editores. En este caso, la web estará alojada en el directorio /var/www/html del container, pero se podrá acceder a ella desde la carpeta /var/www/tanta6

Para crear un contenedor que tenga el estado actual del desarrollo hacemos

docker run --rm -t -p 8008:80 -p 3308:3306 -e "CUSTOM_DB=/tantacom-8.sql" -e "DRUPAL_VERSION=drupal-8" -e "DRUPAL_GIT_REPO=https://tantacom:**********@github.com/tantacom/tantacom-web" -e "DRUPAL_GIT_BRANCH=drupal-8" -v /var/www/tanta8:/var/www/html -e "DRUPAL_ADMIN_PW=foo" --name tanta8 tanta-web

Funcionamos de forma similar, pero en este caso, como lo que queremos es montar un drupal 8 limpio, el script que se ejecutará al arrancar el container ejecutará un composer install con el fin de traernos las dependencias y un drush site-install que seteará la contraseña de administración a foo.

Además, los dos containers pueden comunicarse entre sí usando sus ips internas, lo cual nos viene muy bien para lanzar el proceso de actualización de de drupal 6 a drupal 8. 

Modificando el Dockerfile podríamos crear otra imagen con, por ejemplo, Php y así testar qué cosas deban ser cambiadas antes de pensar en un paso a PHP7 en el entorno de producción.

Hay opiniones sobre cómo montar containers para todos los gustos. Hay quien prefiere hacer contenedores que tengan todo el entorno LAMP (o LEMP), y hay quien prefiere dedicar un contenedor específico a cada componente (es decir, un contenedor para el php, otro para el mysql, otro para el Nginx….).

Un ejemplo de esta otra aproximación es este otro proyecto desarrollado por la gente de Kaliop y que ya estamos empezando a usar aquí para trabajar en nuestros proyectos con eZ Platform.

En próximos post os contaremos cómo configuramos Travis para que ejecute nuestros tests.

Mientras tanto, si tenéis experiencias similares nos encantaría conocerlas.