Configuración en Drupal 8. Parte 2: Config Split

Configuración en Drupal 8. Parte 2: Config Split

En esta segunda parte de la gestión de la configuración en Drupal 8, vamos a ver cómo podemos mantener diferentes configuraciones para cada entorno.

Si te has perdido la primera parte de este artículo, en ella vimos los principios básicos para gestionar la configuración de nuestros sitios con Drupal 8, y deberías darle un repaso antes de seguir con este.

Antes de empezar vamos a hacer un pequeño ejemplo y explicar cuales son los casos de uso.

El problema

En cualquier proyecto en el que tengamos varios entornos (integración, desarrollo, producción, etc.) es muy probable que queramos tener configuraciones distintas de nuestro sitio para cada uno de ellos, o varios, o uno solo. Por ejemplo:

  • Activar módulo Devel en el entorno de desarrollo. Este es el ejemplo típico.
  • Distinta configuración de URLs o IPs de servidores con los que tengamos integraciones. Por ejemplo, podemos tener un servidor LDAP para desarrollo y otro para producción.
  • Configuración específica para producción: caches, módulos de log, varnish, CDNs, etc.

Normalmente esto supone que tendremos un bloque de configuración gordo que será común a todos los entornos, pero también bloques específicos que sólo se aplicarán en algunos de ellos.

En principio, podríamos sobreescribir la configuración añadiendo líneas al archivo settings.php de los diferentes entornos que tengamos, así:

$config['system.logging']['error_level'] = 'verbose';

Para casos sencillos y concretos puede ser una solución válida, pero usar $config tiene varios inconvenientes:

  • No se puede añadir nueva configuración, solo modificar la ya existente.
  • No se puede hacer un unset, no se borrará la configuración.
  • No se pueden activar o desactivar módulos de esta forma.
  • El fichero settings sería complicado de mantener si empezamos a meter morralla.

Se va viendo ya donde está el problema, ¿verdad?

 

¿Que solución hay?

La gente de Nuvole ha estado desarrollando una serie de módulos que nos van a ayudar con este pequeño jaleo. Vamos a ver Config Filter, que va a ser la clave para solucionar el problema que acabamos de ver. La primera versión estable ha visto la luz hace bien poquito, y tuve la suerte de asistir a la conferencia que dió Fabian Bircher en Drupalcon Viena 2017, porque era exactamente lo que estaba buscando.

Usando Config Split vamos a poder agrupar y separar bloques de configuración, que podremos activar o desactivar en cada entorno, así como exportar o importar los ficheros desde directorios diferentes a nuestro sync. Este y otros módulos desarrollados también por Nuvole, necesitan el módulo Config Filter, como una dependencia en la que se basan.

 

Cómo funciona

Para cada bloque de configuración  (Split) que configuremos vamos a poder indicar un directorio donde se guardarán los archivo de configuración de los componentes de ese Split. Mientras el Split esté activo, la configuración de sus componentes se exportará e importará siempre desde ese directorio.

Hay dos modos de funcionamiento para la configuración:

  • Split completo: Inicialmente se llamaba Blacklist o lista negra. Los componentes indicados aquí se gestionarán exclusivamente desde el Split, por lo que sus archivos de configuración se eliminarán del directorio Sync principal. En este modo podremos incluir módulos completos o bien componentes concretos de esos módulos.
  • Split condicional: Llamado inicialmente Graylist, con este modo la configuración de sus componentes no se elimina del Sync global, pero mientras el Split este activo, se importará y exportará al Split. Esto nos permite tener configuraciones alternativas por entorno. En este modo solo se nos permite incluir componentes específicos.

Además, para cada Split podremos definir un peso, de forma que si varios Splits definen la misma configuración, el peso marcará cual tiene prioridad.

Config Split incorpora dos nuevos comandos de Drush para manejar la configuración, son config-split-import y config-split-export:

drush csim

drush csex

 

Instalación

Lo primero que necesitamos hacer es instalar y activar los módulos:

drush dl config_filter config_split
drush en config_filter config_split 

Una vez activados vamos a configurar el Split de la configuración. Vamos al panel de administración, en Inicio »  Administración » Configuración » Development » Sincronizar, donde podemos comenzar a crear grupos.

Listado de Splits

En la imagen se puede ver un Split configurado que hemos llamado Dev, y que está activo en este entorno. Vamos a hacer el ejemplo sencillo de usar este Split para activar el módulo Devel en el entorno de desarrollo. Veámos la configuración básica de este Split en la siguiente imagen.

Configuración básica del Split

Indicamos la ruta física donde se van a guardar los archivos de configuración de este split, relativa a la raíz de Drupal. Le damos un peso e indicamos si está activo o no.

A continuación, y para este ejemplo, seleccionamos el módulo Devel en el bloque de Complete Split, para sacar completamente la configuración de este módulo de la general, ya que solamente vamos a querer activarlo en desarrollo.

Configuración de opciones para el Split

Guardamos la configuración del Split, y para aplicarla tenemos que exportar, con Drush config-split-export:

drush csex

Cuando termine el comando, los archivos de configuración de Devel estarán en el directorio del split, y como los pusimos en el modo completo, serán eliminados del directorio Sync general. En mi caso, tengo algo así.

$ ll dev/

total 24
-rw-rw-r--  1 charles  staff  281  7 Oct 15:21 devel.settings.yml
-rw-rw-r--  1 charles  staff  279  7 Oct 15:21 devel.toolbar.settings.yml
-rw-rw-r--  1 charles  staff  283  7 Oct 15:21 system.menu.devel.yml

Ahora podemos ir a nuestro entorno de producción y desactivamos en nuestro entorno de producción este split, sobreescribiendo la configuración en el archivo settings.php del servidor:

// Desactivar configuracion de split de Dev
$config['config_split.config_split.dev']['status'] = FALSE;

Por supuesto que esto podemos hacerlo al revés, configurarlo como desactivado por defecto, y activarlo solamente en nuestro entorno de desarrollo, y en este caso puede que fuese la mejor opción, porque nos ahorraremos tocar nada de configuración en producción.

 

Flujo de trabajo

Esta es una lista básica de los pasos que vamos a necesitar para trabajar con esta configuración en varios entornos. Espero que ayude a clarificar el proceso.

En nuestro entorno local:

  1. Obtener la base de datos de producción y bajarla a nuestro entorno local.
  2. Borrar caches (drush cr).
  3. Actualizar nuestro repositorio de control de versiones. La forma de hacer esto dependerá mucho de nuestro proyecto, pero básicamente lo que queremos es hacer un git pull.
  4. Importar la configuración de Dev que hemos preparado. Al venir de producción ésta BD no tiene esa configuración (drush csim dev).
  5. Comprobar si hay algún cambio de configuración que se haya hecho en producción, y si es así exportarlo para no perderlo (drush csex).
  6. Guardar estos cambios en el control de versiones (git commit + git push).
  7. Trabajar en las modificaciones de configuación que queramos hacer sobre nuestro entorno local.
  8. Exportar nuestros cambios (drush csex).
  9. Subirlos al control de versiones (git commit + git push).

En el entorno de producción:

  1. Desplegar los cambios en los ficheros de configuración en el entorno de producción. Esto dependerá de la forma en que estemos trabajando. Puede ser tan sencillo como hacer un git pull, o desplegar con un Jenkins.
  2. Importar la configuración con los últimos cambios. Si nuestro Config Split de Dev está desactivado en el settings.php, esa configuración no se importará (drush csim).

 

Conclusiones

Config Split es justo la pieza que me faltaba para poder hacer una gestión medianamente decente de la configuración en Drupal 8 para proyectos grandes, sin usar Features.

Hasta ahora me esta funcionando sin problemas y en general me gusta como se configura y trabaja con el. Recomiendo sin duda darle una oportunidad porque los chicos de Nuvole han hecho un gran trabajo,

 

Referencias

  1. Creating a simple split configuration: Dev modules only in dev environments
  2. Advanced Configuration Management with Config Split et al. (Drupalcon Viena 2017)

  3. http://nuvole.org/blog/2017/aug/21/stable-release-config-split-and-conf…