Conceptos avanzados de imágenes Docker - Parte II

Hola, en la entrada anterior vimos como complicarnos un poco a la hora de construir imágenes. Hoy toca complicarnos un poco más y estudiar algunas de las opciones disponibles para la construcción de imágenes.

Hasta ahora hemos construido imágenes que nos permiten crear contenedores que ejecutarán una aplicación dererminada. La pregunta es ¿como le hemos indicado a docker qué debe ejecutar?¿cómo se ejecuta? y más importante todavía ¿que opciones tenemos?

Evidentemente la primera pregunta es la más sencilla. Si recordamos el dockerfile para nuestra imagen de un servidor ldap, teníamos lo siguiente:

Dockerfile de imagen ldap.

Como ya sabemos, mediante la instrucción ENTRYPOINT le estamos indicando a docker que programa o comando de nuestra imagen ejecutar al crear un contenedor basado en ella.

Ahora nos queda responder a las otras dos preguntas, las cuales están muy relacionadas entre si así que, como diría Groucho, respondamos primero a la segunda pregunta.

Ya sabemos que al crear una imagen es necesario que indiquemos en el dockerfile que la describe que se ejecutará dentro del contenedor. Para esto hay disponibles dos instrucciones que podemos usar en nuestros dockerfiles, estas instrucciones son CMD y ENTRYPOINT y en ambos casos el resultado al usar una u otra es muy similar, salvo por los siguientes puntos que debemos tener en cuenta:

• El objetivo al usar CMD es el de especificar parámetros por defecto para nuestros contenedores. En este caso, siempre es necesario especificar un ENTRYPOINT junto con la instrucción CMD, la cual no contendrá ningún ejecutable.
• Al usar ENTRYPOINT definiremos siempre un ejecutable que se lanzará al arrancar un contenedor. Esta definición siempre debe contener la ruta al ejecutable que queremos lanzar al crear nuestros contenedores. 

Es decir, aunque con ambas instrucciones podemos especificar el programa a ejecutar, lo ideal es siempre usar ENTRYPOINT para especificar el ejecutable y CMD para establecer los parámetros por defecto del mismo. Al especificarlo de esta manera, permitimos que cualquier parámetro que pasemos al comando docker run sustituya a los definidos en la instrucción CMD. Teniendo todo esto en cuenta, nuestro dockerfile para la imagen ldap quedaría del siguiente modo:

Nuevo dockerfile con parámetros por defecto.

Con esta nueva definición contruimos de nuevo nuestra imagen y ahora, al crear un contenedor, se ejecutará el servidor ldap indicado en ENTRYPOINT con los parámetros por defecto especificados en CMD. Si al crearlo pasamos otros parámetros al comando docker run, estos nuevos parámetros sustituirán a los que hemos especificado en el dockerfile. Veamoslo con un pequeño ejemplo:

Contenedor creado a partir de la imagen ldap.

Como podemos ver. nuestro conetendor está ejecutando el servidor ldap con los parámetros por defecto indicados en la instrucción CMD de nuestro nuevo dockerfile.

Si ahora creo otro contenedor y especifico otros parámetros el resultado será el siguiente:

Cambiando los parámetros en tiempo de creación del contenedor.

Es importante tener en cuenta que también podemos usar CMD para especificar el ejecutable, es decir, podemos usar ENTRYPOINT o CMD para especificar que ejecutar al crear un contenedor, incluso los dos a la vez si queremos y, como siempre, todo dependerá de nuestras necesidades y entorno.

Desde mi punto de vista, creo que lo mejor es usar la combinación de ENTRYPOINT, para el ejecutable y CMD, para los parámetros por defecto, cuando pueda ser necesario cambiar estos últimos al crear un contenedor. Cuando lo que buscamos es asegurarnos de que no se pueden alterar los parámetros por defecto, lo mejor será que nuestro dockerfile solo contenga una entrada ENTRYPOINT que especifique tanto el ejecutable como los parámetros necesarios. En este último caso cualquier parámetro que se añada en el momento de crear el contenedor se añadirá a los parámetros por defecto sin sustituirlos, con lo que nos aseguramos que el servicio arrancará con los parámetros deseados.

Otro punto importante que debemos tener en cuenta al utilizar ENTRYPOINT es el formato que utilizamos. Según la documentación, tenemos dos opciones al especificar la instrucción ENTRYPOINT:

• Formato shell, que es más o menos: ENTRYPOINT comando param1 param2 ...
• Formato exec, que es más o menos: ENTRYPOINY ["ejecutable", "param1", "param2", ... ]

Bueno y ¿cual es la diferencia y por qué es importante? La diferencia y por tanto su importancia, viene derivada de como se ejecuta el servicio en un caso y en el otro.

Hasta ahora siempre hemos usado el segundo formato en nuestros dockerfile, el denominado formato exec, en el cual especificamos el ejecutable y sus parámetros como un array JSON. Cuando hemos creado contenedores e inspeccionado los procesos corriendo en los mismos, hemos visto que nuestro ejecutable era siempre el PID número 1. Si usamos el formato shell, ¿que es lo que sucede? Como siempre veamoslo con un ejemplo muy sencillo:

Contenedor creado usando el formato shell de ENTRYPOINT.

Como podemos ver en la salida anterior, nuestro comando no es el PID 1 dentro del contenedor y esto es importante si queremos que nuestros servicios se paren ordenadamente. Cuando paramos un contenedor con el comando docker stop, en estos caso, el contenedor no parará de forma limpia ya que solo la shell usada para arrancar nuestro comando recibirá la señal, pero nuestro servicio no con lo que, en algunos casos, puede que tras un timeout docker deba enviar una señal SIGKILL al proceso, lo que puede provocar que el servicio no se pare adecuadamente. Teniendo esto en cuenta lo mejor será siempre usar la forma exec de ENTRYPOINT, como recomienda la documentación de Docker.

Hasta aquí un poco más de información sobre Docker y como trabajar con imágenes. En la siguiente entrada veremos como personalizar en el momento de crear un contenedor la configuración de nuestro servicio ldap.

Integración de NetWorker y Data Domain VE

Hola de nuevo, vamos con otra entrada sobre backup, en concreto como integrar un appliance virtual Data Domain con NetWorker 9.x.

Un sistema Data Domain nos permite realizar backups a disco con características muy superiores a las de un dispositivo AFTD de NetWorker, con el que se integra desde su versión 7.6, siendo sus principales características:

• Deduplicación de los datos. Los sistemas Data Domain deduplican los datos almacenados, lo que nos permitirá mantener más backups.
• Replicación entre los sistemas Data Domain desplegados.
• Protocolo DD Boost. El uso de este protocolo con NetWorker, acelera enormemente los backups y las recuperaciones.

Desde hace un tiempo está disponible una versión virtual de Data Domain, la cual se licencia por capacidad a partir de 500 GB. Esta appliance virtual que puede desplegarse en VMware e Hyper-V, incluye todas las licencias que nos interesan para nuestro servicio de backup, la licencia del protocolo DD Boost, la licencia de deduplicación y la de replicación. Por tanto, si queremos integrar sistemas Data Domain virtuales en nuestra infraestructura de backup, solo necesitaremos adquirir una licencia DiskBackup de NetWorker.

Tras la aburrida teoría, vamos a lo práctico. Primero desplegamos el appliance, para lo cual tenemos que seguir el asistente que se lanza al desplegar el fichero OVA del appliance virtual. Las opciones que debemos configurar en el despliegue son las tarjetas de red virtuales y el tipo de sistema DD que vamos a desplegar, siendo el mínimo el correspondiente a un sistema que soporta hasta 4 TB. Una vez desplegada nuestra appliance, en el primer arranque realizaremos la configuración inicial del sistema DD cuando iniciemos sesión en la consola por primera vez.

Lo primero es cambiar la contraseña del usuario sysadmin que nos permite administrar el sistema:

Primero cambiamos la password de sysadmin.

En los pasos siguientes configuramos la red del sistema donde, al menos uno de los interfaces, debe estar configurado por DHCP:

Especificamos la configuración de red.

En el siguiente paso el asistente de configuración nos preguntará si queremos introducir ya el código de licencia, así como la configuración del sistema la cual será más sencilla de realizar desde el interfaz gráfico de administración.

Al acceder a cualquier de las dos direcciones IP anteriores accederemos a la consola de administración Data Domain System Manager (DDSM) desde la cual podremos terminar de configurar el sistema y administrarlo:

Pantalla de validación para DDSM.

Al entrar por primera vez en DDSM y no haber introducido un código de licencia en la configuración inicial, lo primero que nos pedirá el sistema es introducir el fichero de licencia. La descarga del appliance incluye un fichero de licencia de evaluación, para que podamos hacer todas las pruebas que queramos durante 30 días. Basta con indicar donde esá el fichero de licencia para activar el DD virtual:

Introduciendo licencia de evaluación.

Tras este paso llegamos a la consola principal de adminsitración de DDSM que tiene la siguiente pinta:

Pantalla principal de DDSM.

El siguiente paso es añadir un disco al DD para que pueda usarlo como almacenamiento para nuestros backups. Como podemos añadir los discos en caliente, solo tenemos que añadir un nuevo disco virtual a la VM y configurarlo para su uso. Al añadir el nuevo disco veremos que este aparece en el apartado Devices dentro de la sección Hardware y también como almacenamiento utilizable, dentro del apartado Overview:

El disco disponible para ser añadido al sistema.

Para añadir el disco solo tenemos que pinchar sobre Configure y añadir el disco disponible al tier  activo como se puede ver en la siguiente imagen:

Añadimos el disco al tier activo para su uso.

El disco añadido y el uso de licencia asociado.

Al añadir el disco el sistema nos indicará que es necesario crear un sistema de archivos en el nuevo dispostivo para poder usarlo y el disco aparecerá en la consola como dispositivo que no está en uso. Para poder usar este nuevo disco necesitamos crear un sistema de archivos sobre él, para esto solo tendremos que seguir el asistente de creación de nuevo file system desde el apartado correspondiente dentro de la sección Data Management. Este asistente nos preguntará para que queremos utilizar el sistema, realizando unos tests de rendimiento específicos en cada caso. Como queremos integrarlo con NetWorker, seleccionamos la primera opción cuando llegamos al siguiente paso del asistente:

Seleccionamos la primera opción para usarlo como dispositivo de backup.

Una vez terminado el asistente de creación del file system este ya estará disponible para su uso con lo que ahora, para poder usarlo en nuestra infraestructura de backup, solo necesitamos conectarnos a la consola de nuestro servidor NetWorker y desde la sección devices, lanzar el asistente de creación de nuevo dispositivo. Al tratarse de un dispositivo DD el tipo de dispositivo que crearemos será un dispositivo Data Domain.

Lanzamos el asistente de creación de nuevo dispositivo.

Selecciona Data Domain como nuevo dispositivo.

Las opciones que debemos configurar para nuestro nuevo dispositivo son básicamente, la dirección IP del sistema y las credenciales del usuario con acceso para usar el protocolo DDboost:

Configuración de la IP y credenciales del dispositivo DD.

En el siguiente paso NetWorker se conectará con el Data Domain y podremos crear una carpeta específica en el file system y dar nombre a nuestro nuevo dispositivo. Esto nos permitirá tener cierta organización y crear diferentes dispositivos apuntando al mismo sistema DD.

Creación de carpeta y nombre de dispositivo.

Ya los siguientes pasos nos permiten crear un pool específico y asignarlo a este dispositivo, el nodo de almacenamiento que usará el dispositivo DD y la configuración de SNMP para que NetWorker pueda monitorizar los eventos SNMP que genere el sistema Data Domain. Con toda esta configuración realizada, nuestro nuevo dispositivo DD aparecerá en la lista de dispositivos del servidor NetWorker listo para ser usado para realizar backups.

El dispositivo DD ya está disponible para su uso.

Adicionalmente desde la DDSM, podemos ver la conexión activa desde el servidor NetWoker con el DD usando el protocolo DD Boost:

Conexión activa con el DD desde el servidor NetWorker.

Ya solo tendremos que cambiar nuestros workflows, o crear otros nuevos, para utilizar el nuevo pool que utiliza el dispositivo que acabamos de crear y empezar así, a hacer backups a disco.

Hasta aquí la configuración básica de un sistema Data Domain y como integrarlo con nuestro servidor NetWorker para poder hacer backusp a disco. En una próxima entrada veremos como configurar el DD para hacer backups directos de los clientes usando protocolos como NFS o CIFS.

Caraterísticas principales de NetWorker 9.2

Hola de nuevo, hoy toca una entrada sobre backup, en concreto sobre NetWorker y los cambios introducidos en las versiones 9.x.

Acabamos de terminar la migración de nuestro servicio de backup en versión 8.4.2, a la reciente versión 9.2.2 y he aprovechado para realizar cambios en la infraestructura. El cambio más importante ha sido la virtualización del servidor de backup, con lo que he separado el nodo de almacenamiento que controla la biblioteca de cintas del propio servidor.

El proceso de actualización ha implicado un cambio de plataforma, lo que Dell/EMC denomina una migración cruzada, ya que nuestro servidor de backup era un sistema Solaris 10 y el nuevo servidor es un servidor virtual Red Hat 7. Este tipo de migración solo está soportado si lo realiza personal de Dell/EMC así que, con su ayuda, hemos hecho la migración en aproximadamente 3 días.

Durante la instalación del servidor ya encontramos varios cambios, siendo los principales que es necesario instalar el servidor de autenticación y el servidor de licencias. Por tanto, si monitorizamos los procesos del servidor, ahora tendremos que incluir el servidor flex y los procesos asociados al servidor de autenticación en nuestro sistema de monitorización.

Otros de los cambios más importantes es la propia base de datos de NetWorker la cual, basada antes en WiSS, es ahora una base de datos SQLite, lo cual introduce muchas mejoras de rendimiento en el funcionamiento del servidor.

Pero los cambios de verdad los vemos al entrar en la NMC ya que ahora, la nueva consola presenta el siguiente aspecto:

Consola de adminsitración de NetWorker 9.2.

A primera vista es muy similar a la de las versiones 8.x y practicamente tenemos las mismas secciones, salvo por la sección Protection que es donde nos vamos a encontrar el cambio fundamental en como NetWorker nos permitirá proteger nuestra información.

En la sección Protection nos encontramos con la siguiente estructura:

Sección Protection de NMC.

Hay varios apartados que nos resultarán familiares de las versiones anteriores menos el apartado Policies, dentro del cual veremos que es donde se centra el cambio en como definimos nuestra estrategia de protección de datos.

Para ver las diferencias vamos a crear un cliente de backup usando el asistente de creación de nuevo cliente, que es el método recomendado de creación. Una vez terminado veremos nuestro nuevo cliente en la consola con una marca, la cual nos indica que el cliente no forma parte de ninguna política de protección.

Lista de clientes de backup disponibles.

A continuación creamos un grupo de clientes de backup en el que vamos a incluir nuestro nuevo cliente:

Creación de un nuevo grupo de backup.

Mientras que en versiones anteriores de NetWorker teníamos muchas opciones cuando configurábamos un grupo, ahora queda claro que un grupo de backup o protección es un conjunto de clientes organizado siguiendo el citerio que queramos fijar. En versiones anteriores recuerdo que olvidaba asignar el grupo al pool de cintas que quería usar para el backup de dicho grupo y, cuando se lanzaba el backup, el servidor siempre pedía una cinta del pool Default para poder realizar el backup. Ahora ya no hay una relación directa entre un grupo de backup y el pool de cintas a utilizar, con lo que veremos un poco más adelante como establecemos dicha relación.

Por tanto hasta ahora, en lo que respecta a la configuración de los clientes no encontramos muchas diferencias, pero en cuanto a los grupos de clientes no hemos configurado el pool a utilizar, si el grupo y el autostart están habilitados, el schedule, si queremos guardar los índices, etc...

El siguiente punto es la creación de una política, a partir de la cual podremos empezar a definir cómo queremos proteger nuestros datos. La creación de una política es tan sencillo como:

Creación de una nueva política.

Como podemos ver, lo único configurable es el nombre, comentario y tipo de notificación que se generará. Así que ¿como establezco la política de protección del grupo que acabo de crear? Creando un workflow que contendrá una o más acciones que queremos realizar sobre el grupo de protección.

Desde la política que acabamos de crear crearemos un workflow del siguiente modo:

Nuevo workflow de protección de clientes.

Ahora, dentro del workflow, definimos las acciones que queremos realizar y que se aplicarán solamente sobre el grupo LINUX_SERVERS que hemos definido antes.

Creación de una acción de backup - Tipo de backup y programación.

Creación de una acción de backup - Retención y pool.

Creación de una acción de backup - Opciones avanzadas y cambios en programación

Ahora que hemos definido la acción de backup sobre el grupo podemos resumir lo siguiente:

• Los clientes se organizan en grupos de protección. Estos grupos los crearemos según nuestros propios criterios, pero no disponen de más información que los clientes que los forman y el nombre del grupo.
• Las políticas de backup, también creadas según nuestros criterios y entorno, contendrán los workflows que aplicaremos a los grupos de protección anteriores. El workflow ya me permite configurar la hora de inicio, el intervalo y contiene las accioens que realizaremos sobre los grupos de protección.
• La acción o acciones que contenidas en un workflow me permitirán definir la programación, el storage node, el pool, la retención y cualquier opción adicional necesaria.

Una vez terminada la configuración, nuestro workflow se representará graficamente del siguiente modo:

Representación gráfica de un workflow de backup.

Con esta representacion gráfica queda claro que, sobre el grupo de protección LINUX_SERVERS vamos a realizar una acción de backup y que el pool a utilizar se llama BACKUP.

Todos estos cambios ya estarán reflejados en la sección Monitoring, desde la que podremos lanzar un backup de nuestro grupo con solo ejecutar el workflow correspondiente:

Ejecución de un workflow de backup.

Una vez terminado el backup, podremos consultar los logs y resultado del mismo desde esta sección:

Consultando el resultado de un backup.

Resultado y logs de un backup.

Así que hasta aquí, para todos los que administramos NetWorker, las diferencias fundamentales se basan en la relación entre todos los elementos que nos permiten diseñar nuestra estrategia de backup.

Después de tantos años trabajando con NetWorker, desde la version 7.x, creo que el cambio le hacía falta y que el resultado es un sistema mucho más moderno tanto desde el punto de vista funcional como operativo, sin contar todos los cambios realizados en el código y todas las funcionalidades añadidas.

Como todavía me falta mucho por leer, en breve intentaré hacer otra entrada con más información sobre esta nueva versión de NetWorker.

Conceptos avanzados de imágenes Docker - Parte I

Hola de nuevo, en el post anterior creamos nuestra primera imagen básica a partir de la cual queremos construir imágenes más complejas para nuestros servicios. En este post extenderemos nuestra imagen básica y exploraremos algunas de las opciones disponibles y relacionadas con la publicación de imágenes.

Para empezar recordemos que habíamos creado nuestra imagen básica y ahora, lo interesante es tenerla disponible para poder utilizarla en nuestra infraestructura. Para esto podemos crear nuestro propio registro interno de imágenes o usar una cuenta en Docker Hub, con lo que nuestra imagen estará disponible siempre desde cualquier punto con un acceso a internet.

Podéis crear una cuenta directamente en Docker Hub de forma gratuita con solo acceder aquí, con lo que tendréis disponible vuestro propio repositorio de imágenes. Una vez creada la cuenta, nuestro repositorio estará vacio y disponible como podemos ver en la siguiente imagen:

Nuestro repositorio en Docker Hub.

Una vez creada nuestra cuenta y desde la línea de comandos, podemos subir nuestra imagen a Docker Hub del siguiente modo:

Subiendo una imagen base a Docker Hub.

En resumen el proceso consiste en los siguientes pasos:

1. Iniciamos sesión de Docker Hub con nuestro dockerid. El comando docker login nos pedirá nuestro dockerid y la contraseña.
2. Una vez iniciada la sesión creamos una nueva etiqueta o tag usando el comando docker tag. Al hacerlo debemos especificar nuestro dockerid en el nombre de la nueva etiqueta.
3. Usamos el comando docker push el cual, usando el dockerid incluido en el tag de la imagen, la subirá a nuestro repositorio.

Una vez subida, nuestro respositorio en Docker Hub nos mostrará la nueva imagen ya disponible:

Nuestra imagen disponible en Docker Hub.

Si el repositorio es público, cualquiera podrá utilizar nuestra imagen para generar nuevos contenedores o crear nuevas imágenes a partir de ella.

Ahora que tenemos nuestra imagen base disponible, vamos a crear una nueva imagen a partir de esta. Supongamos que nuestro servicio necesita un servidor de directorio, como por ejemplo un servidor OpenLDAP, para proporcionar servicios de configuración o de validación de usuarios. En este caso, lo primero que debemos hacer, si ninguna de las imágenes públicas disponibles nos convencen o por motivos de seguridad queremos asegurarnos de que la imagen contiene exactamente lo que necesitamos, es instalar el servidor OpenLDAP con las opciones que necesitemos en nuestro contexto de construcción, por ejemplo:

Contexto de construcción para imagen LDAP.

Básicamente lo único que hacemos es compilar las fuentes de OpenLDAP con las opciones y módulos que necesitamos, e instalarlas en una ruta dentro de nuestro entorno para construir la imagen correspondiente. Una vez instalado, es necesario cambiar las rutas que aparecen en los ficheros de configuración del servidor OpenLDAP, ya que serán rutas absolutas al contexto de construcción que estemos usando, aunque ya veremos más adelante como personalizarlo en el momento de creación del contenedor.

Ya solo necesitamos crear el dockerfile y ejecutar el comando docker build. La parte importante ahora es que nuestro nuevo dockerfile indicará que debe construirse a partir de nuestra imagen base quedando del siguiente modo:

Dockerfile para imagen ldap.

Para poder probar nuestra imagen y comprobar que todo es correcto, vamos a seguir utilizando como entrypoint la bash incluida en la imagen base, por tanto lanzamos la construcción de la imagen con el comando siguiente:

Construcción de la imagen ldap.

A continuación creamos un contenedor interactivo y efímero con esta nueva imagen para explorar su contenido. Cuando un contenedor es efímero no es necesario darle un nombre ya que, cuando lo paremos se borrará automáticamente, lo que es perfecto para probar de forma rápida nuestras imágenes. Si queremos crear contenedores efímeros usaremos la opción --rm con el subcomando run, como podemos ver en la siguiente imagen:

Contenedor creado a partir la imagen ldap.

Como podemos ver, nuestra imagen contiene tanto nuestro directorio ldap así como los directorios de nuestra imagen base. Esto nos permite comprobar como la construcción de imágenes superpone las capas que forman cada una de ellas, viendo una sistema de archivos completo a partir de los que aporta cada una de las imágenes.

Ahora, si intentamos ejecutar el proceso slapd de nuestro servidor OpenLDAP, ¿funcionará o nos faltarán bibliotecas necesarias para su correcto funcionamiento?

Error en la ejecución del poceso slapd de la imagen ldap.

Es evidente que, en el proceso de compilación, se ha incluido una dependencia con una biblioteca del sistema operativo que no está incluida en nuestra imagen base. En este punto bien podemos cambiar nuestra imagen base, incluyendo la biblioteca que falta, o cambiar solo la nueva imagen. En este punto, en mi opinión, creo que siempre es mejor idea cambiar la nueva imagen ya que si por ejemplo, fuese necesario cambiar una biblioteca de nuestra imagen base y esta la hubiesemos utilizado para construir muchas imágenes poesteriores, implicaría cambiar todas las imágenes que dependen de la imagen base. De este modo solo es necesario cambiar la imagen afectada que, en este ejemplo, es nuestra imagen ldap. Así que, añadiendo unas cuentas cosas más a nuestra nueva imagen la dejaremos del siguiente modo:

Nuevo contexto de construcción para la imagen ldap.

De esta manera incluimos las bibliotecas que faltan en la imagen y además, para asegurarnos que estén disponibles, añadimos en el directorio etc de la imagen la configuración necesaria para el enlazador de bibliotecas dinámicas en tiempo de ejecución. En nuestro caso la configuración del ld es muy sencilla y basta con hacer lo siguiente:

Configuración para el ld de nuestra imagen.

Con esta configuración le estamos diciendo al ld que puede buscar bibliotecas en la ruta /ldap/lib, que es donde los contenedores construidos a partir de nuestra imagen base tendrán la instalación de OpenLDAP. Lo único que nos queda es generar el fichero de caché que ld consulta cuando es necesario buscar bibliotecas dinámicas, para esto usaremos el comando ldconfig indicándole que su directorio root es el de nuestro contexto de construcción de la imagen ldap:

Generación de la caché para ld en nuestro contexto de construcción.

Con todo esto hecho, si ahora construimos de nuevo la imgen ldap y comprobamos un contenedor generado a partir de la misma, tenemos lo siguiente:

Construcción de la imagen ldap corregida.

Nuevo contenedor generado a partir de imagen ldap corregida.

Ahora que no recibimos ningún error de dependencias, si arrancamos el servidor tenemos lo siguiente:

Servidor slapd de OpenLDAP corriendo en nuestro contenedos efímero de pruebas.

Como podemos comprobar, el contenedor permite la ejecución del servidor slapd de OpenLDAP con lo que solo nos queda modificar nuestro dockerfile para cambiar el ENTRYPOINT y añadir una opción fundamental, la publicación del puerto 389 al exterior. Por tanto ahora, el dockerfile de esta imagen queda del siguiente modo:

Dockerfile definitivo para nuestra nueva imagen ldap.

Construcción de la imagen ldap.

Con lo que, tras la modificación y construcción de la imagen ldap definitiva, podremos grenerar contenedores que ejecuten un servidor de directorio basado en OpenLDAP.

Sobre esta imagen caben muchas mejoras, como añadir soporte TLS para la encriptación de las comunicaciones y la personalización de las opciones de configuración del servidor de directorio en el momento de generar el contenedor mediante el uso de variables de entorno.

En las próximas entradas veremos como hacer estos cambios, la importancia y diferencias entre usar ENTRYPOINT o CMD en nuestros dockerfiles y como usar un proceso init dentro de nuestros contenedores.

Cluster ONTAP - Parte III

Hola de nuevo, tras ver un poco las diferencias hardware entre sistemas ONTAP 7-Mode y los sistemas cluster ONTAP, hoy voy a resumir las diferencias a nivel software que, como veréis son muchas.

Como ya comenté, un sistema cluster ONTAP está formado por parejas de controladoras. Esto nos lleva a una de las primeras diferencias que, desde mi punto de vista, es fundamental para entender como funciona cluster ONTAP. Mientras que en 7-Mode cada controladora de una pareja era independiente y podíamos administrarlas por separado, en cluster ONTAP tenemos un solo punto de administración para todo el cluster, tanto si está formado por dos nodos como por 10.
Este punto de administración nos permitirá gestionar todos los recursos del cluster de forma centralizada y servir el almacenamiento según nuestras necesidades. Aún podremos conectarnos a cada nodo del cluster si queremos, pero lo habitual es solo utilizar la administración única del cluster.

Este funcionamiento en cluster nos lleva a otra de las diferencias fundamentales entre 7-Mode y C-mode, las máquinas virtuales de almacenamiento.

Mientras que en 7-Mode cada controladora disponía de un servidor para cada protocolo ahora, cluster ONTAP nos permite crear instancias separadas de cada servicio o protocolo con los puertos de acceso necesarios. A cada una de estas instancias se las denomina storage virtual machine (SVM) y se caracterizarán por:

• La dirección IP o puertos de fibra necesarios para servir datos.
• Los protocolos de acceso usados.
• Los volúmenes a los que tengan acceso para servir datos.
• Sus propios usuarios y grupos.

Es decir, una SVM proporcionará ciertos servicios separados y totalmente aislados del resto de SVMs del cluster.

Más o menos y de manera muy simplificada, podemos verlo del siguiente modo:

SVMs en un sistema C-mode.

Por tanto, podremos crear SVMs cuyos volúmenes se encuentren en agregados de cualquier pareja del cluster, asignar los puertos, ya sean de red o fibra, de cualquier nodo físico del cluster y habilitar los protocolos necesarios en cada una de ellas para servicios NAS (NFS, CIFS) o de bloque (FCP, FCoE, iSCSI) así como crear los usuarios que sean necesarios en cada una de ellas.

Esta claro que con esta forma de trabajar, NetApp ha dado una orientación total a sus sistemas a proveedores de servicios, donde podremos tener tenants separados y cada cliente podrá administrar su SVM de manera totalmente independiente. Pero lo mejor de esto es que, aunque no seamos un proveedor de servicio, podremos hacer exactamente lo mismo y crear diferentes SVMs para cada uno de nuestros cliente internos y permitirles administrar totalmente su SVM y como siempre, da igual que nuestras controladoras sean la gama baja o la más alta, ya que cluster ONTAP correrá perfectamente en ellas.

Con esta entrada termino la parte de introducción a cluster ONTAP, la cual ha sido muy simple, con lo que recomiendo visitar la web de NetApp para profundizar mucho más en ella. A partir de ahora intentaré que las nuevas entradas sean un poco más prácticas.