ELK - Introducción a Logstah III

En el post anterior sobre Logstash, vimos que los dos filtros más utilizados para registros de tipo texto son dissect y grok. Usando syslog_generator, el cual os recuerdo que tenéis disponible aquí por si queréis usarlo, creamos entradas de tipo fijo para el syslog de una máquina donde habíamos instalado filebeat, las enviamos a Logstash y las procesamos con un filtro dissect para obtener los campos que nos interesaban.

En esta entrada usaremos grok sobre el mismo tipo de registros, enviados también desde un sistema con filebeat, para poder realizar la misma tarea.

Primero es importante recordar que grok es perfecto para procesar registros de tipo texto no estructurados, es decir, para aquellos casos en los que se generan registros con una estructura variable de línea a línea. Además, al basarse en expresiones regulares, es posible extender los patrones reconocidos creando patrones para poder usarlos en cualquier pipeline de Logstash que utilice grok.

La sintaxis básica para definir un filtro con grok se define del siguiente modo:

Sintaxis básica para un filtro grok.

Y esta definición, ¿que quiere decir exactamente? Como ya hemos visto, a diferencia de dissect, grok se basa en expresiones regulares ya existentes, identificadas con un nombre que se corresponde con el campo PATTERN, las cuales asignaremos al campo NAME que necesitemos cuando la coincidencia sea satisfactoria. Grok incluye un buen número de patrones ya listos para su uso, cuya lista puede consultarse aquí aunque pueden incluirse nuevos patrones, si es necesario, modificando la configuración de Logstash añadiendo un fichero con la definición de nuevos patrones.

Al definir filtros usando grok, este busca coincidencias desde el principio de cada línea de tecto hasta el final de la misma intentando mapear todo el evento, o hasta no encontrar una coincidencia. En función de los patrones, es posible que grok procese los datos varias veces, por lo que es más lento y requiere más recursos que filtros realizados con dissect.

Para nuestro ejemplo, vamos a seguir con líneas de registro que son perfectas para el uso de dissect, ya que no varían y presentan los mismos campos y delimitadores en todos los casos, pero así podremos comprobar que podemos usar indistintamente cualquiera de los dos tipos de filtro.

Las líneas a procesar presentan la siguiente estructura:

Líneas de registro a procesar y definición de campos.

Al igual que hicimos con el filtro dissect, vamos a empezar con un filtro simple y luego iremos complicándonos un poco más. 

Para empezar, vamos a hacer uso de una herramienta muy útil disponible en Kibana y que nos permite probar nuestros filtros grok, con lo que podemos analizar si el resultado obtenido es o no correcto antes de configurarlo en nuestro pipeline. Podemos acceder al Grok Debugger desde la sección Dev Tools de Kibana:

Grok Debugger disponible en Kibana.

Esta herramienta es de gran ayuda ya que, al tratarse de expresiones regulares, es fácil que tengamos que probar bastantes veces antes de dar con la configuración correcta del filtro. Por tanto, para empezar, vamos a probar a quedarnos solo con 4 campos de la línea message, en concreto con la fecha de syslog, el hostname, el nombre del programa que ha generado la línea y el mensaje generado por syslog_generator. Para esto, el filtro grok a aplicar sobre la línea message será:

Filtro grok inicial.

Como vemos en el filtro, puede que en algunos casos sea necesario definir los espacios que existan en el registro de texto, dados por el patrón SPACE. Teniendo esto en cuenta, el filtro está estableciendo lo siguiente:

• Almacenar en el campo logger_date el texto encontrado que haga match con el patrón SYSLOGTIMESTAMP.
• Almacenar en el campo logger_hostname la siguiente palabra encontrada.
• Almacenar en el campo logger_program los siguientes datos encontrados.
• Almacenar en el campo logger_message todo lo que queda hasta el final de la línea, lo cual especifcamos con el patrón GREEDYDATA.

Usando el grok debugger con este filtro, sobre una línea de ejemplo recibida en Logstash, podemos simular el resultado y comprobar que, al trabajar con expresiones regulares, los resultados que buscamos son un poco más complicados de obtener de lo que esperábamos:

Usando Grok Debugger con el filtro inicial.

Como vemos en la imagen anterior, el campo logger_program se queda vacio, es decir, que la definición %{DATA:logger_program} que hemos hecho para ese campo, no nos devuelve ningún contenido. Si vemos la definición del patrón DATA disponible, vemos que equivale a .*? lo cual establece que debe devolver la menor cantidad posible de caracteres (?) de cualquiera de los caracteres (.*) anteriores. Básicamente, al especificar que se devuelva la menor cantidad posible de caracteres con ?, no está devolviendo ningún valor en dicho campo.

La forma de corregirlo sería usar un filtro como el siguiente, en el cual fijásemos que haga match con cualquier palabra y todos aquellos caracteres que no sean un espacio:

Filtro grok modificado para incluir de forma correcta el cmapo logger_program.

Al probarlo en el depurador de grok de Kibana, vemos que ahora obtenemos los campos que queremos de forma correcta:

Comprobación de que el nuevo filtro es correcto.

La sintaxis empleada es la que podemos usar cuando la expresión regular que necesitamos, no se encuentra en los patrones disponibles incluidos con el plugin de filtro grok de Logstash. Podemos usarla directamente en la definición del filtro o, si queremos usarla de manera habitual, podemos extender la biblioteca de patterns incluyendo las nuestras y asignándoles un nombre para poder usarlas en múltiples pipelines.

Modificamos el fichero de configuración del filtro grok con esta definición de filtro y arrancamos Logstash. La salida que obtenemos en este caso es la siguiente:

Salida de Logstash con el filtro grok correcto.

Podemos ver como los cuatro campos que hemos definido están en la salida, además del resto generados por el plugin de entrada filebeat. Además, el campo message del registro ya no aparece al eliminarlo con la opción remove_field.

Ahora ya solo nos queda procesar el campo logger_message para obtener el resto de campos que necesitamos, para lo cual podríamos aplicar un filtro como el siguiente:

Filtro grok procesando todos los campos de message.

Cuando lo aplicamos, la salida de Logstash ya nos muestra los campos necesarios como podemos ver en la siguiente imagen:

Salida de Logstash con el filtro final grok.

En resumen, está claro que grok nos da mucha más potencia para procesar registros de tipo texto, pero con un coste de dificultad añadido debido al uso de expresiones regulares. En general, el uso de dissect o grok, dependerá de la estructura de los registros de texto que sea necesario procesar y, en algunos casos, será conveniente combinar ambos en el mismo pipeline.

En próximas entradas crearemos más de un pipeline, para ver como trabajan conjuntamente y enviaremos los datos a Elasticsearch para podeer realizar búsquedas sobre los datos recibidos.

Como referencia para el estudio de expresiones regulares, recomiendo usar la página https://regex101.com/ en la cual, además de poder probar expresiones regulares, nos explica cada una de las opciones y operadores que podemos usar para la construcción de expresiones regulares complejas.

ELK - Introducción a Logstah II

Como ya vimos en el post anterior sobre Logstash, este elemento de la pila ELK nos permite recibir datos, procesarlos mediante pipelines y luego enviar dichos datos a otros destinos. Resumiendo el post anterior, los pipelines presentan una estructura que, de forma muy simplificada, podemos ver del siguiente modo:

Definición básica de un pipeline.

Utilizando esta estructura para configurar un pipeline simple, vimos cómo recibir entradas de syslog de un sistema en el cual instalamos filebeat y enviamos dicha salida directamente a STDOUT, sin aplicar ningún filtro a los datos recibidos. Hoy veremos cómo podemos procesar esa información, aplicando filtros a los datos recibidos desde nuestro cliente, para obtener los campos que nos resulten útiles.

Recordando la configuracion que establecimos, al lanzar el generador de entradas de syslog para el tipo FIXED con el pipeline sin filtro, la salida que nos muestra logstash en stdout es como la siguiente:

Salida de Logstash sin filtro a STDOUT.

El objetivo es procesar el campo message, aplicando filtros para poder obtener los valores que realmente necesitamos y que luego podremos enviar a Elasticsearch.

Logstash dispone de múltiples plugins para realizar el filtrado de los datos recibidos, siendo dos de los más usados para registros de tipo texto dissect y grok. Para consultar la lista de plugins de filtro recomiendo visitar la página de Elastic y consultar la documentación disponible sobre Logstash.

Usar dissect o grok dependerá de como sea la estructura de los datos que debemos procesar, más concretamente de si la estructura de los datos está claramente definida. En general:

• Es recomendable usar dissect cuando los registros que recibe logstash siempre contienen los mismos campos separados por delimitadores. Este filtro es muy rápido y es el más sencillo de configurar.
• El filtro grok es ideal para los casos en los que los registros de texto recibidos varían, ya que usa patrones de expresiones regulares para hacer coincidir campos y delimitadores. Este filtro es más complejo de configurar y consume más recursos.

Es importante tener en cuenta que los pipelines de Logstash nos permiten aplicar múltiples filtros a la misma entrada, con lo que podremos pasar los registros recibidos por un filtro para posteriormente aplicarle otro diferente.

Teniendo en cuenta el campo message recibido en cada registro, esta claro que el filtro ideal en este caso es dissect ya que tenemos varios campos separados por delimitadores de longitud fija. Por tanto, podríamos hacer algo como lo siguiente:

Procesado básico de campo message.

El filtro dissect no permitirá mapear cada uno de esos campos y asignarles el nombre que más nos convenga, con lo que podríamos hacer un filtro básico como el siguiente:

Filtro inicial empleando dissect.

Si analizamos el filtro anterior vemos los siguientes puntos importantes:

• Un campo del filtro es la clave que hay entre los caracteres %{}, con lo que en este caso establecemos 6 campos. Cada uno de estos campos se corresponde con los 6 campos que hemos identificado sobre el mensaje recibido. Asignamos un nombre diferente a cada uno de ellos, según nuestras necesidades.
• El delimitador es cualquier carácter entre los caracteres } y %{, siendo en este caso espacios.
• Como el número de espacios después del campo timestamp_month es variable, añadimos el sufijo -> tras el nombre del campo.
• Además, al emplear la opción remove_field, dissect eliminrá el campo message siempre que se produzca una coincidencia del filtro, con lo que eliminaremos el campo que procesamos de la salida dada.

Al aplicar esta configuración al pipeline de Logstash, la salida que obtenemos ahora es la siguiente:

Salida de Logstash con filtro dissect básico.

Al aplicar el filtro dissect, aparecen los nuevos campos que hemos definido en el filtro, además de todos los campos que genera el plugin de entrada de filebeat con la información del cliente remoto y ha desaparecido el campo message que hemos procesado.

Ya hemos avanzado en el procesado de los registros de syslog que recibimos, pero suponiendo que la información que necesitamos es realmente la que está en el campo logger_message, podemos cambiar el filtro, asignar unos nombres más claros a los campos que nos interesan y trocear el campo logger message con el siguiente filtro:

Ampliamos el filtro dissect al campo logger_message.

Con lo que la nueva salida de logstash es la siguiente:

Salida de Logstash tras procesar el campo logger_message.

Como vemos en la salida anterior, ahora tenemos un conjunto de campos identificados con el prefijo logger_ así como los campos identificados con el prefijo timestamp_. Suponiendo que los campos con el prefijo logger_ de fecha y hora son los que necesitamos además de unificarlos todos en un solo campo y eliminando los campos con el prefijo timestamp_, el filtro final que hacemos con dissect sería el siguiente:

Eliminamos campos y unificamos los campos de fecha en uno solo.

Al aplicar el filtro anterior, la salida de Logstash es la siguiente:

Salida de Logstash eliminando campos timestamp_ y unificando campos de fecha.

Cómo podemos ver en la salida anterior, ya no aparece ningún campo timestamp_ y todos los campos de fecha, con el prefijo logger_, están unificados en el campo logger_timestamp. Para conseguir esto, solo debemos tener en cuenta los siguientes puntos sobre el filtro que hemos definido:

• Para eliminar totalmente un campo de la salida del filtro dissect, solo tenemos que prefijar el nombre del campo con el carácter ?. Como vemos en el filtro anterior, he incluido el carácter ? a todos los campos timestamp_ para eliminarlos.
• Si queremos concatenar campos, basta con repetir el nombre del campo añadiendo el carácter + delante del nombre. Así, en el filtro aplicado, podemos ver como todos los campos que incluyen información de fecha tienen el nombre logger_timestamp correspondiente al primer campo de fecha. El resto de campos que queremos concatenar, repiten el nombre del campo inicial incluyendo el caracter + delante del nombre, indicando así con que campo deben concatenarse.

En la próxima entrada sobre Logstash analizaremos como podemos realizar el mismo filtrado usando grok el cual, como veremos, es un poco más complejo y a la vez más potente.

ELK - Introducción a Logstash

Con este artículo voy a comenzar una nueva sección dedicada a estudiar la pila ELK. Vamos a empezar con una pequeña introducción a Logstash, lo que nos permitirá entender su función y cómo configurar un pipeline sencillo.

Bueno y ¿que es logstash? pues es el elemento de la pila ELK que permite procesar datos para luego enviarlos a Elasticsearch, para indexarlos y realizar tareas de análisis y búsqueda.

Logstash funciona mediante pipelines, siendo cada uno de ellos los que realizan, en su conjunto, todo el proceso. Un pipeline de logstash tendrá uno o más plugins de entrada, que recibirán los datos que luego se colocarán en una cola interna. Esta cola es por defecto pequeña y se almacena en memoria, pero puede configurarse para que se almacene en disco y ampliar su tamaño.
Los datos se leen de esta cola interna y se procesan a través de plugins de filtro, que se configuran en secuencia y estos datos procesados se envían a los plugins de salida correspondientes, que formatean y envían los datos a Elasticsearch o a otro destino como veremos. Todo esto podemos verlo, más o menos, del siguiente modo:

Estrucutura lógica de un pipeline.

Cada uno de los pasos que forman el pipeline nos permitirá especificar lo siguiente:

• Plugin de entrada, mediante los cuales especificartemos el origen de nuestros datos. Este plugin puede especificar como fuentes de origen ficheros, stdin, topics de Kafka, varias APIs públicas disponibles, syslog, los beats de Elastic, etc. En este artículo usaremos como plugin de entrada filebeat, para recibir datos de los ficheros de una máquina cliente.
• Filtros, los cuales nos permitirán procesar la información recibida y modificarla como más nos interese, creando los campos que necesitemos para su posterior procesado.
• Plugins de salida, que nos permitirán especificar donde enviará Logstash los datos procesados. Al igual que en el caso de los plugins de entrada, hay disponibles una gran cantidad de plugins de salida para enviar los datos a una base de datos MongoDB, a un topic de Kafka, a un socket TCP, a stdout, a un servidor Zabbix, etc. En este artículo enviaremos la salida a stdout, para poder comprobar como logstash procesa la información y la modifica de acuerdo a los filtros que configuremos.

Para generar información, y salvo que dispongas de una gran cantidad de máquinas generando logs que procesar, he creado un pequeño script en Python que genera entradas de syslog que enviaré a Logstash y utilizaré a lo largo del artículo. Si quieres usar este script, echarle un ojo, modificarlo o lo que sea, puedes descargarlo de GitHub.

Como es lógico debemos instalar Logstash, en la máquina que queremos usar como servidor y filebeat en la máquina cliente, auunque pueden estar instalados en la misma máquina. Para la instalación, recomiendo consultar la documentación de instalación proporcionada por Elastic, aunque disponen de sus propios repositorios con lo que es muy sencillo instalarlos.

Filebeat es un agente de Elastic para el envio del contenido de ficheros a los diferentes elementos de la pila ELK y que veremos más detenidamente en posteriores artículos. Por tanto, para empezar, configuramos el cliente, para lo cual es necesario modificar el fichero de configuración filebeat.yml del módulo filebeat. Este módulo dispone de un fichero de configuración cuya ruta por defecto, si instaláis el paquete oficial de Elastic, está en la ruta /etc/filebeat.

Ficheros de configuración de filebeat.

Lo que necesitamos especificar en el fichero de configuración es la ruta de los ficheros que van a enviarse y cual es el destino al que deben enviarse. En la configuración por defecto, filebeat dispone de un solo input, que se denomina log, y especifica que deben leerse los ficheros de la ruta /var/log, con lo que habilitamos dicho input, ya que vamos a enviar registros de syslog:

Configuración de input de filebeat.

La línea include_lines permite especificar que expresiones regulares deben contener las líneas de los ficheros de log para que se envíen al destino que luego especifiquemos. Esta es una manera de realizar un primer filtrado en origen, asegurándonos que solamente se enviarán aquellas líneas de nuestro interés. En el caso que nos ocupa, las lineas de syslog a enviar serán aquellas que contengan la cadena SYSLOG_GEN, como puede verse en la imagen anterior.

Por último solo es necesario habilitar la salida a la que filebeat enviará los datos, para lo cual debemos configurar la sección Logstash output del fichero indicando el nombre o dirección IP del host donde se encuentre instalado Logstash:

Configuración de output de filebeat.

Como se ve en la imagen anterior, podemos enviar la salida de filebeat directamente a un cluster de Elasticsearch pero es muy importante tener en cuenta que solo puede configurarse un output para filebeat. En nuestro caso lo enviamos al servidor donde se encuentra Logstash.

Una vez configurado filebeat en el cliente, pasamos a configurar Logstash definiendo un pipeline muy sencillo, en el cual solo vamos a tener un plugin de entrada, un filtro y un plugin de salida. 

En general los pipelines de Logstash se crean sobre uno o más ficheros de configuración, los cuales pueden estar en un directorio único que especificaremos en el fichero de configuración /etc/logstash/pipelines.yml, con lo que Logstash los concatenrá al arrancar, usando todos los pipelines simultáneamente.

Ficheros de configuración de Logstash.

Cómo el fichero pipelines.yml apunta a la ruta /etc/logstash/conf.d, crearemos los ficheros de configuración de los pipelines en dicho directorio

Ficheros de configuración de pipelines.

Teniendo en cuenta como es la estructura lógica que hemos visto de un pipeline, la estructura básica del fichero de configuración será:

Definición básica de un pipeline.

Para este caso, nuestro plugin de entrada será filebeat, comenzaremos sin especificar un filtro, lo cual es válido y el plugin de salida será stdout. En ese caso, el fichero de configuración del pipeline será como se muestra en la siguiente imagen:

Pipeline básico sin filtro.

Como vemos, el plugin de entrada especifica que para este pipeline Logstash recibirá información de filebeat en el puerto 5044, que no se va a aplicar ningún filtro y que el plugin de salida es stdout, usando un codec para mostrar la salida de un forma más entendible.

Con esta configuración podemos arrancar el servicio filebeat y el generador de syslog en el cliente y, para arrancar logstash usaremos un comando como:

 

Arranque de Logstash especificando la configuración de pipeline.

Desde el cliente, el generador de entradas de syslog está enviando registros a logstash, a través de filebeat, como los siguientes:

 

Salida de syslog_generator.

Con esta configuración, syslog_generator crea una línea de syslog fija con un identificador y una dirección IP ficticia, simulando así una línea de syslog básica.

 

Con esto ¿que nos muestra Logstash en stdout? pues una salida como la siguiente:

 

Salida de Logstash.

Si revisamos detenidamente la imagen anterior, vemos que Logstash nos muestra una serie de campos, formados por parejas clave-valor, muchos de los cuales genera a partir de la información que recibe de filebeat. Al usar beats como plugin de entrada, logstash aplica por defecto un codec específico mediante el cual nos muestra el hostname de origen, la versión de sistema operativo, timestamp, plataforma, etc.

 

Como también podemos ver, hay un campo específico que contiene el mensaje completo generado por syslog_generator y que se guarda en los ficheros de log del cliente a través de su syslog local. Como vemos en la salida, el campo es:

 

Campo message recibido en Logstash desde filebeat.

Debemos tener en cuenta que, al usar filebeat especificando como origen /var/log, este envía el contenido de los ficheros de dicha ruta a la salida configurada, en este caso Logstash. El campo message se corresponde con una línea de syslog, que contiene el registro de syslog generado por el script syslog_generator que estamos lanzando en el cliente.

 

Con esta configuración tan simple, hemos visto como podemos enviar entradas de ficheros de un cliente a Logstash mediante el uso de filebeat. Cómo la idea es procesar dichas entradas, aplicando filtros, en los próximos posts veremos como crear dichos filtros con dissect y con grok para poder extraer los datos que nos interesan de ese campo message.

 

Cluster ONTAP - Configuración de SVMs con subredes

Hoy vamos con una entrada sencilla de cluster ONTAP. Veamos como podemos usar la característica de subnets o subredes, para configurar de forma automática la red de nuestras SVMs.

Mediante el uso de subredes, la configuración de red de cualquier SVM se realizará de forma automática. Al aplicar una subred a una SVM configuraremos la dirección IP, la máscara de subred y el gateway de la LIF asociada a dicha SVM.

Esta característica está claramente orientada a los proveedores de servicio, donde cada cliente tendrá su propia red separada del resto.

Veamos como crear una subred y aplicarla a la configuración de nuestras SVMs.

Primero crearemos un IPspace y un dominio de broadcast, en el que incluiremos los puertos físicos que tendrán acceso a dicha red:

Creación del IPspace y dominio de broadcast para la subred.

Al listar los puertos de red de nuestro cluster, podremos comprobar que los puertos especificados están en el IPspace y dominio de broadcast recien creados:

Puertos ethernet del cluster, IPspace y dominio de broadcast.

Ahora podemos crear la subred, lo más importante es definir el pool de direcciones IP que se asignarán a las SVMs en el momento de crearlas:

Creación de la subred.

Nuestra subred desde OnCommand System Manager.

Ahora, en el momento de configurar la red de una nueva SVM, elegiremos Using a subnet y seleccionaremos la subred recien creada:

Creación de una SVM con una subred, asignamos el IPspace.

Creación de una SVM con una subred, configuración del data LIF.

Información de uso de la subred desde OnCommand System Manager.

Como vemos, la LIF de la nueva SVM tiene habilitado el DNS dinámico, pero dentro de la configuración de la SVM será necesario habilitarlo si disponemos de un servidor DNS que permita las, tan temidas por algunos, actualizaciones dinámicas:

Configuración del data LIF de la nueva SVM. La opción DDNS está activada.

Habilitamos el DNS dinámico en la configuración de la SVM.

Al permitir las actualizaciones automáticas en el DNS la IP se registrará perfectamente.

Por tanto, como vemosc los sistemas NetApp nos permiten configurar de forma rápida las LIFs de nuestras SVMs y además, de una forma muy simple, integrarlo con nuestro servicio DNS.

En próximas entradas veremos como podemos replicar datos usando SnapMirror para establecer una estrategia de recuperación de desastres.

Administración básica de Docker swarm - Parte II

Hoy continuamos con la administración de Docker swarm y en concreto, vamos a repasar como usar volúmenes con los servicios que desplegamos en nuestros clusters de dockerhosts.

Originalmente, como ya vimos en su momento, se usaba la opción -v o --volume, para montar volúmenes con nuestros contenedores standalone y, para el despliegue de servicios, se usaba la opción -m o --mount. Desde la versión 17.06 de Docker lo recomendado es usar --mount en ambos casos, aunque se sigue soportando el uso de --volume con contenedores standalone.

Recordando un poco lo que ya sabemos de Docker, hay dos tipos de montajes o volúmenes que podemos usar. Los dos tipos de montajes o volúmenes disponibles son:

• Volúmenes de datos (volume mounts). Estos son los volúmenes independientes de nuestros dockerhosts y que deben ser gestionados de manera separada. Lo lógico es que estos volúmenes los proporcionen sistemas de almacenamiento específicos y que, mediante un driver determinado, podamos interactuar con el proveedor del almacenamiento y administrar los volúmenes.
• Volúmenes de tipo bind. De forma muy simple estos son volúmenes que están en cada dockerhost del swarm, es decir son rutas dentro del sistema de archivos de nuestros dockerhosts.

Como ya he comentado, aunque se sigue soportando la opción -v o --volume, lo recomendado es usar siempre la opción -m o --mount, independientemente del tipo de volumen a usar. Al montar nuestros volúmenes con --mount podremos especificar diferentes opciones, como vimos en el post sobre Trident.

Para especificar los volúmenes de nuestros servicios o contenedores, la sintaxis de la opción --mount utiliza determinadas claves, mediante las cuales podemos especificar las siguientes opciones:

• Tipo de montaje, con la opción type. Esta opción nos permite especificar si el montaje será de tipo bind, volume o tmpfs. El tipo tmpfs nos permite crear un volumen en la memoria asignada al contenedor, lo cual está indicado para aquellos datos temporales que no queremos o no es necesario que tengan persistencia. 
• Origen del montaje, con la opción source. Para volúmenes con un nombre determinado, este campo contendrá el nombre del volumen. Si no especificamos un nombre se creará un volumen anónimo.
• Ruta o punto de montaje, con la opción destination. Con esta opción especificaremos el punto de montaje dentro del contenedor.
• Resto de opciones, especificadas como volume-opt, que nos permitirán especificar opciones adicionales de configuración.

Recordando el post sobre Trident, creamos un servicio montando un volumen y especificando un driver, del siguiente modo:

Especificamos un volumen en la creación de un servicio.

Vamos a revisarlo más detenidamente, definiendo un servicio simple que incluya volúmenes y modificando un servicio ya existente añadiendo o eliminando volúmenes.

Empezando por la parte más sencilla, con el subcomando volume de docker podemos controlar los volúmenes de nuestro cluster swarm, o de dockerhosts individuales. Las opciones disponibles del comando docker volume son las siguientes:

Opciones disponibles del comando docker volume.

Si usamos el comando docker volume sin ninguna opción, el driver utilizado será local, es decir las operaciones se realizarán sobre volúmenes locales del dockerhost sobre el que estemos operando. Por ejemplo, podemos crear un volumen en un solo dockerhost: 

Creación de un volumen local en un dockerhost.

Tambien podemos crear un volumen, con el mismo nombre, en cada uno de los dockerhost que forman parte del swarm:

Creación de un volumen local en los nodos de un swarm.

De la salida del comando docker volume ls vemos que, la primera columna indica que el driver utilizado es local. Esto indica que ese volumen solo existe en el dockerhost y por tanto, los datos que un servicio o contenedor genere y almacene en dicho volumen solo estarán disponibles en dicho dockerhost.

Los volúmenes creados con el driver local se crearán siempre en la ruta /var/lib/docker/volumes, lo cual podemos comprobar usando el comando docker volume inspect:

Obteniendo la información de un volumen.

Como es lógico, podemos cambiar esta ruta especificando la opción --data-root en el arranque del demonio dockerd.

Ahora que hemos creado un volumen común a todos los dockerhosts del swarm, podemos arrancar un servicio simple que use dicho volumen, especificándolo con --mount, mediante el comando siguiente:

Creación de un servicio con un volumen local.

De esta manera, al crear el servicio sin especificar un driver, docker usará el driver local y buscará un volumen con el nombre especificado en el dockerhost para montarlo en los contenedores. En caso de especificar un volumen que no exista, el volumen se creará con el nombre especificado o, si no especificamos un nombre, se creará un volumen anónimo:

Creación de un servicio con múltiples volúmenes.

Al listar los volúmenes disponibles en cada uno de los dockerhosts del swarm, vemos que se ha creado el volumen VOL_logs_swarm que no existía antes y dos volúmenes anónimos, uno se corresponde con el volumen para la ruta especificada /WWW_tmp y el otro volumen anónimo es para el volumen indicado en la definición de la imagen usada, que en este caso  se monta en /WWW.

Volúmenes creados para el servicio.

Por tanto, docker nos permitirá crear los volúmenes o los creará en caso de ser necesario, ya que como vemos se crea un volumen anónimo cada vez que lanzamos un contenedor a partir de una imagen que incluye volúmenes en su configuración.

Cuando queramos eliminar volúmenes que ya no se usen, podremos usar el comando docker volume prune, lo cual los eliminará. Como es lógico, al no especificar el driver, esto solo se aplicará a los volúmenes locales:

Eliminamos los volúmenes no usados. En este caso son volúmenes locales.

Ahora, usando plugins específicos para la creación de volúmenes para nuestros servicios, como por ejemplo el driver Trident para interactuar con sistemas NetApp, podemos crear un servicio que utilice volúmenes de datos comunes proporcionados por una SVM y volúmenes locales para datos temporales que no necesitamos que se mantengan:

Creación de un servicio con volúmenes desde una SVM.

En este ejemplo creamos un servicio que usa un volumen ya existente en la SVM (swarm_HTML), otro volumen que no existe y que el driver creará por nosotros (swarm_LOG) y un volumen local que tampoco existía con anterioridad (LOCAL_tmp) y que Docker creará en cada dockerhost:

El volumen VOL_swarm_LOG lo creará Trident al crear el servicio.

Lista de volúmenes existentes en nuestro swarm.

Por tanto podemos combinar volúmenes de diferentes poveedores en el mismo servicio con solo especificar el driver correcto para cada uno de ellos. Podemos comprobar los volúmenes en uso por el servicio usando el comando docker service inspect:

Lista de volúmenes en uso por el servicio.

En caso de ser necesario podemos actualizar la configuración del servicio y añadir o quitar volúmenes, mediante la opción --mount-rm del comando docker service update. Por ejemplo, si ncesitamos eliminar el volumen local, podemos hacer lo siguiente:

Eliminamos un volúmen de un servicio.

Con lo que ahora, al inspeccionar el servicio, vemos que solo está usando los volúmenes proporcionado por la SVM del sistema NetApp:

El servicio ahora usa solo dos volúmenes, dados por el driver Trident.

Para aplicar este update, como vemos en la salida siguiente, Docker ha parado cada contenedor del servicio y lo ha vuelto a arrancar con la nueva configuración:

Contenedores arrancados con la nueva configuración de volúmenes.

Por tanto y para terminar, hemos visto como Docker nos permite gestionar los volúmenes necesarios para nuestros contenedores o servicios y su integración con proveedores de almacenamiento como NetApp. Como siempre, para una información mucho más detallada, os recomiendo consultar la documentación oficial de Docker.