Skip to end of metadata
Go to start of metadata


0 Visión general

WBS Airback®  provee una solución unificada para la consolidación de almacenamiento y archivado de datos, así como la gestión de la seguridad de los mismos, permitiendo establecer diferentes niveles de acceso a estos en virtud de sus requerimientos de disponibilidad.


WBS Airback®  supone una nueva generación en los sistemas de gestión y protección del almacenamiento, incluyendo funcionalidades capaces de gestionar almacenamiento heterogéneo para su uso como almacenamiento primario o como repositorio de backup, así como funcionalidades para la gestión del ciclo de vida del backup. Dichas funciones son gestionadas de una manera muy sencilla debido a que abstraen parte de la complejidad técnica y conceptual de los mencionados servicios.

WBS Airback® está basado en una plataforma de tipo appliance que integra todos los componentes lógicos necesarios en una única plataforma. No requiere la adquisición ni instalación de sistemas operativos ni aplicaciones de terceros para funcionar. Puede adquirirse como un appliance físico incluyendo la plataforma hardware adecuada a cada necesidad, o como un appliance virtual incluyendo los ficheros estándar necesarios para desplegar una máquina virtual en las principales plataformas de virtualización.

A través de una sencilla interfaz web accesible desde cualquier navegador, se puede realizar toda la administración y configuración del sistema y de sus funcionalidades principales.

Desde dicha interfaz se realiza la actualización de versiones, actualizaciones, parches, etc. con tan sólo dos o tres clicks.

El esquema general de la solución es el siguiente:

WBSAirback

Figura 0: Visión general WBSAirback

En el presente documento se presenta el módulo de protección de entornos basados en contenedores de imágenes a través de la tecnología Docker mediante el plugin Docker de WBS Airback®.

1 Introducción a Docker

Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos. 

1.1 Comparativa entre virtualizaciones1

Figura 1. Máquinas virtuales(vieja forma) vs Contenedores(nueva forma)1

La vieja forma de desplegar aplicaciones era instalarlas en un servidor usando el administrador de paquetes del sistema operativo. La desventaja era que los ejecutables, la configuración, las librerías y el ciclo de vida de todos estos componentes se entretejían unos a otros. Podíamos construir imágenes de máquina virtual inmutables para tener rollouts y rollbacks predecibles, pero las máquinas virtuales son pesadas y poco portables.

La nueva forma es desplegar contenedores basados en virtualización a nivel del sistema operativo, en vez del hardware. Estos contenedores están aislados entre ellos y con el servidor anfitrión: tienen sus propios sistemas de archivos, no ven los procesos de los demás y el uso de recursos puede ser limitado. Son más fáciles de construir que una máquina virtual, y porque no están acoplados a la infraestructura y sistema de archivos del anfitrión, pueden llevarse entre nubes y distribuciones de sistema operativo.

Ya que los contenedores son pequeños y rápidos, una aplicación puede ser empaquetada en una imagen de contenedor. Esta relación uno a uno entre aplicación e imagen nos abre un abanico de beneficios para usar contenedores. Con contenedores, podemos crear imágenes inmutables al momento de la compilación en vez del despliegue ya que las aplicaciones no necesitan componerse junto al resto del stack ni atarse al entorno de infraestructura de producción. Generar una imagen de contenedor al momento de la compilación permite tener un entorno consistente que va desde desarrollo hasta producción. De igual forma, los contenedores son más transparentes que las máquinas virtuales y eso hace que el monitoreo y la administración sean más fáciles. Esto se aprecia más cuando los ciclos de vida de los contenedores son administrados por la infraestructura en vez de un proceso supervisor escondido en el contenedor. Por último, ya que solo hay una aplicación por contenedor, administrar el despliegue de la aplicación se reduce a administrar el contenedor.

En resumen, los beneficios de usar contenedores incluyen:

  • Ágil creación y despliegue de aplicaciones: Mayor facilidad y eficiencia al crear imágenes de contenedor en vez de máquinas virtuales
  • Desarrollo, integración y despliegue continuos: Permite que la imagen de contenedor se construya y despliegue de forma frecuente y confiable, facilitando los rollbacks pues la imagen es inmutable
  • Separación de tareas entre Dev y Ops: Puedes crear imágenes de contenedor al momento de compilar y no al desplegar, desacoplando la aplicación de la infraestructura
  • Observabilidad No solamente se presenta la información y métricas del sistema operativo, sino la salud de la aplicación y otras señales
  • Consistencia entre los entornos de desarrollo, pruebas y producción: La aplicación funciona igual en un laptop y en la nube
  • Portabilidad entre nubes y distribuciones: Funciona en Ubuntu, RHEL, CoreOS, tu datacenter físico, Google Kubernetes Engine y todo lo demás
  • Administración centrada en la aplicación: Eleva el nivel de abstracción del sistema operativo y el hardware virtualizado a la aplicación que funciona en un sistema con recursos lógicos
  • Microservicios distribuidos, elásticos, liberados y débilmente acoplados: Las aplicaciones se separan en piezas pequeñas e independientes que pueden ser desplegadas y administradas de forma dinámica, y no como una aplicación monolítica que opera en una sola máquina de gran capacidad
  • Aislamiento de recursos: Hace el rendimiento de la aplicación más predecible
  • Utilización de recursos: Permite mayor eficiencia y densidad

1.2 Componentes principales

El motor de Docker es una aplicación cliente-servidor con los siguientes principales componentes:

  • Demonio Docker - Como su nombre indica, es un proceso demonio que siempre está ejecutándose (comando dockerd). Encargado de crear y gestionar los "Objetos Docker" tales como imágenes, contenedores, redes y volúmenes.
  • API REST - Interfaz específica para que los programas puedan utilizar para comunicarse con el Demonio Docker.
  • Interfaz de línea de comando (Comando docker) permite un control e interacción con el Demonio Docker a través de la línea de comandos empleando el API REST.

Docker structure

Figura 2. Flujo de componentes de Dockerd

1.3 Elementos Docker

Docker Architecture Diagram

Figura 3. Diagrama de la arquitectura de Docker

1.3.1 Imágenes

Una imagen es una plantilla sólo lectura con las intrucciones necesarias para la creación de un contenedor. A veces, una imagen puede estar basada en otra imagen con alguna personalización añadida.

1.3.2 Contenedores

Un contenedor es una instancia de una imagen. El usuario puede crear, iniciar, parar o eliminar un contenedor empleando las interfaces REST o CLI de Docker. Un contenedor se puede conectar a una o más redes, adjuntarle almacenamiento, o incluso crear una nueva imagen basada en su actual estado. Por defecto, un contenedor está aislado de otros contenedores y del hosts. Cuando un contenedor es eliminado, todos los cambios de su estado que no estén guardados en un almacenamiento persistente desaparece.

1.3.3 Almacenamiento en Docker

Por defecto todos los archivos creados dentro de un contenedor son almacenados en la capa de escritura de los contenedores. Esto significa que:

  • Los datos no persisten cuando el contenedor se elimina, y puede ser difícil extraer los datos del contenedor si otro proceso los necesita.
  • La capa de escritura de un contenedor está estrechamente acoplada al host donde se ejecuta el contenedor. No se puede mover los datos fácilmente a otro lugar.
  • La capa de escritura de un contenedor requiere un controlador de almacenamiento para administrar el sistema de archivos. El controlador de almacenamiento proporcina un sistema de archivos de unión, utilizando el kernel de Linux. Esta abstracción adicional reduce el rendimiento en comparación con el uso de volúmenes, que escriben directamente en el sistema de archivos del host.

Docker tiene dos opciones a los contenedores para almacenear archivos in la máquina del host, incluso después de parar los contenedores: volumes bind mounts. En Linux, se permite utilizar un tmpfs mount. En Windows, se denomina pipe. La Figura X muestra la diferencia entre cada uno de estos almacenamientos.

types of mounts and where they live on the Docker host

Figura 4. Tipos de montajes y sus respectiva persistencia


Sin embargo, independientemente del tipo de volumen que se utilice, los datos tienen el mismo aspecto desde el contenedor, ya que estarán expuestos como un directorio o un archivo individual en el sistema de ficheros del contenedor.

  • Volumes: Los volúmenes son almacenados en una parte del sistema de archivos del host, el cual está gestionado por Docker ('/var/lib/docker/volumes/' en Linux).
    • Ningún proceso que no sea Docker debería modificar nada de este directorio.
    • Se crean mediante el comando `docker volume create [name]` o Docker lo puede crear durante la creación de un contenedor o servicio.
    • Al crear un volumen se le puede asignar un nombre o delegar esa responsabilidad a Docker para que lo nombre de una forma única. 
    • Pueden ser utilizados por varios contenedores al mismo tiempo.
    • Cuando ningún contenedor lo está utilizando el volumen no será destruido automáticamente, se deberá de hacer manualmente mediante el comando `docker volume prune`.
    • Soportan el uso de volume driverslos cuales permiten almacenar los datos en hosts remotos o proveedores en la nube, entre otras posibilidades.
  • Bind mounts:  Los bind mounts pueden ser almacenados en cualquier directorio del host.
    • Cualquier proceso (sea de Docker o no) puede modificarlo en cualquier momento.
    • El host debe de tener la ruta de enlace especificada.
    • Son muy efectivos, pero se basan en el sistema de archivos que el host tenga.
    • Al ser un montaje de enlace, los procesos del contenedor del Docker pueden crear, modificar o eliminar archivos o directorios importantes del sistema, si no se gestiona de forma adecuada. Esta implicación de seguridad puede tener impacto en los procesos que no son de Docker en el sistema host.
    • No se pueden utilizar los comandos Docker CLI para administrarlo directamente.
    • @Docker recomienda la utilización de Volumes.
  • Tmpfs: El sistema de archivos temporal de Docker únicamente almacena los datos en memoria.
    • Nunca los llega a escribir en el host.
    • Los datos pueden ser utilizados durante el tiempo de vida del contenedor.
    • Recomendación para almacenar datos no persistentes o información sensible.

1.3.4 Registro

Docker permite almacenar Docker imágenes en repositorios, tanto públicos como privados. El repositorio público por defecto de Docker es Docker Hub.

1.3.5 Docker ID

El Docker ID es el identificador único (basado en SHA256) que se utiliza para identificar los contenedores o las imágenes de Docker. El ID puede ser referenciado utilizando un trozo de la cadena hexadecimal SHA256 o entera. La variante completa consiste en 64 caracteres y la corta consiste en los primeros 12 caracteres de la cadena.


1.4 Beneficios

A continuación,  se listan los principales beneficios del uso de esta tecnología de virtualización frente a las convencionales máquinas virtuales:

Beneficios
  1. Ahorro de costes - La naturaleza de Docker es que se necesitan menos recursos para ejecutar la misma aplicación. Debido a los requisitos de infraestructura reducidos que tiene Docker, las organizaciones pueden ahorrar en todo, desde los costos del servidor hasta los empleados necesarios para mantenerlos. Docker permite que los equipos de ingeniería sean más pequeños y más efectivos.
  2. Estandarización y productividad - Los contenedores Docker garantizan la coherencia en múltiples ciclos de desarrollo y liberación, estandarizando su entorno. Docker proporciona entornos repetibles de desarrollo, construcción, prueba y producción. La estandarización de la infraestructura de servicio en todo el proceso permite que cada miembro del equipo trabaje en un entorno de paridad de producción. Al hacer esto, los ingenieros están más equipados para analizar y corregir errores de manera eficiente dentro de la aplicación. Esto reduce la cantidad de tiempo desperdiciado en defectos y aumenta la cantidad de tiempo disponible para el desarrollo de características.
  3. Eficiencia de CI -  Docker te permite construir una imagen de contenedor y usar esa misma imagen en cada paso del proceso de implementación.
  4. Compatibildad y mantenibilidad - La paridad, en términos de Docker, significa que tus imágenes se ejecutan igual sin importar en qué servidor o en qué computadora portátil se ejecutan. Para los desarrolladores, esto significa menos tiempo dedicado a configurar entornos, depurar problemas específicos del entorno y una base de código más portátil y fácil de configurar.
    La paridad también significa que tu infraestructura de producción será más confiable y más fácil de mantener.
  5. Simplicidad y configuraciones más rápidas y flexibles - Los usuarios pueden tomar su propia configuración, ponerla en el código y desplegarla sin ningún problema. Como Docker se puede utilizar en una amplia variedad de entornos, los requisitos de la infraestructura ya no están vinculados con el entorno de la aplicación.
  6. Despliegue rápido - Crea un contenedor para cada proceso y no arranca un sistema operativo.
  7. Despliegue contínuo y pruebas - Si necesita realizar una actualización durante el ciclo de lanzamiento de un producto, puede realizar fácilmente los cambios necesarios en los contenedores Docker, probarlos e implementar los mismos cambios en sus contenedores existentes.
  8. Plataformas multi-nube -  Gracias a su portabilidad, los proveedores de computación en nube, incluidos Amazon Web Services (AWS) y Google Compute Platform (GCP), han adoptado la disponibilidad de Docker y han agregado soporte individual.
  9. Aislamiento - Docker se asegura de que cada contenedor tenga sus propios recursos que están aislados de otros contenedores. 
  10. Seguridad - Docker garantiza que las aplicaciones que se ejecutan en contenedores estén completamente segregadas y aisladas entre sí, lo que le otorga un control total sobre el flujo y la administración del tráfico.


2 Descripción general

El plugin Docker está diseñado para ser utilizado en infraestructuras locales de Docker, y es capaz de realizar copias de seguridad y, cuando sea necesario, restaurar los contenedores que representan los servicios de infraestructura o almacenes de datos que son persistentes. Los contenedores no persistentes que se crean a partir de plantillas existentes, que se inician, detienen y destruyen cuando son necesarios sin contener datos persistentes, a menudo se administran mejor de una manera diferente. 

En otras palabras, aquellos contenedores que son especiales, que requieren de una preparación manual y que representan datos o servicios comunes, compartidos y persistentes son los que se deben repaldar y restaurar con este plugin. Mientras que los contenedores no modificados, creados y destruidos automáticamente están fuera del alcance de los casos de uso de este plugin, es decir, que están soportados por el plugin pero no se recomienda emplear este plugin para este tipo de contenedores.


3 Backup del contenido de los volúmenes

Antes de continuar en esta sección se recomienda entender la Sección 1.3.3. A pesar de la capacidad que tiene el plugin de respaldar los volúmenes de Docker, hay que tener en cuenta que éste no lo hace implícitamente, es decir, si un contenedor emplea cualquier tipo de volumen de Docker no se respaldará el volumen. Es por ello que dependiendo del tipo de volumen se debe actuar de forma distinta para su respaldo.

3.1 Docker Volume

Este tipo de volúmenes puede ser respaldado y restaurado por el plugin explícitamente. Sin embargo, si no se desea hacer una copia completa del volumen, siempre se puede acceder a la ruta por defecto de este tipo de volúmenes: '/var/lib/docker/volumes/' y a través de un respaldo del propio cliente mantener los archivos a salvo a nivel de archivo.

3.2 Bind Volume

Este tipo de volúmenes no puede ser respaldado por el plugin y deberá de ser respaldados directamente por el cliente.

3.3 Tmpfs Volume

Se recuerda que este tipo de volúmenes se guarda en memoria, y por lo tanto no se puede acceder a él y por lo tanto no se puede realizar un copia de seguridad de su contenido.

3.4 Restauración de los volúmenes respaldados

El plugin de Docker no tiene la capacidad de restaurar un contenedor y montar los volúmenes asociados en el momento de la copia de seguridad. Es por ello que  en este punto se escenifica el problema y se ofrece la solución:

Escenificación del linkado en la restauración de un contenedor
[whitebear@dockerHost bindVolume]$ sudo docker container ls --all
CONTAINER ID        IMAGE                                      COMMAND             CREATED              STATUS                          PORTS               NAMES
ff90e0649713        v_container/6188b7ee5750/1441:restore      "/bin/bash"         About a minute ago   Exited (0) About a minute ago                       v_container_1441
6188b7ee5750        ubuntu                                     "/bin/bash"         3 hours ago          Exited (0) 3 hours ago                              v_container
b06fd8b8cafd        bind_container/90955835a441/1434:restore   "/bin/bash"         4 hours ago          Exited (0) 4 hours ago                              upbeat_herschel
4867c9f356f9        bind_container/90955835a441/1434:restore   "/bin/bash"         5 hours ago          Exited (0) 5 hours ago                              bind_container_1434
7b5267fb23a0        hello-world                                "/hello"            29 hours ago         Exited (0) 29 hours ago                             pedantic_elion
[whitebear@dockerHost bindVolume]$ sudo docker inspect -f '{{ .Mounts }}' 6188b7ee5750 ff90e0649713 
[{volume vDocker /var/lib/docker/volumes/vDocker/_data /data local z true }]
[]

Como se puede observar en el anterior bloque, cuando se realiza el backup el contenedor llamado "v_container", tenía el volumen vDocker enlazado al directorio "/data". Sin embargo, cuando se realiza la restauración del contenedor "v_container_1441" se puede observar que no tenía ningún volumen enlazado (Aunque internamente si que tiene el directorio "/data").

Sin embargo, hay una solución para esto, ya que la restauración del contenedor se hace en modo imagen, lo único que se deberá de realizar es la ejecución del contenedor basándonos en la imagen respaldada y enlanzando cualquier tipo de volumen. Aquí un ejemplo:

Ejemplo de enlazado de volúmenes
# Listamos todas las imágenes
[whitebear@dockerHost bindVolume]$ sudo docker image ls
REPOSITORY                         TAG                 IMAGE ID            CREATED             SIZE
v_container/6188b7ee5750/1441      restore             04e53aa894ab        3 hours ago         64.2MB
bind_container/90955835a441/1434   restore             5c1676d7dc8d        5 hours ago         64.2MB
ubuntu                             latest              2ca708c1c9cc        3 weeks ago         64.2MB
baculatar                          19Aug19             1ddc32af48e8        7 weeks ago         1.71MB
hello-world                        latest              fce289e99eb9        9 months ago        1.84kB

# Ejecutamos el contenedor con la base de la imagen restaurada con el volumen.
[whitebear@dockerHost bindVolume]$ sudo docker run --name v_container_v --mount source=vDocker,target=/dataRestore v_container/6188b7ee5750/1441:restore 
[whitebear@dockerHost bindVolume]$ sudo docker container ls --all
CONTAINER ID        IMAGE                                      COMMAND             CREATED             STATUS                      PORTS               NAMES
d433913fb290        v_container/6188b7ee5750/1441:restore      "/bin/bash"         9 seconds ago       Exited (0) 8 seconds ago                        v_container_v
ff90e0649713        v_container/6188b7ee5750/1441:restore      "/bin/bash"         19 minutes ago      Exited (0) 19 minutes ago                       v_container_1441
6188b7ee5750        ubuntu                                     "/bin/bash"         3 hours ago         Exited (0) 3 hours ago                          v_container
b06fd8b8cafd        bind_container/90955835a441/1434:restore   "/bin/bash"         5 hours ago         Exited (0) 4 hours ago                          upbeat_herschel
4867c9f356f9        bind_container/90955835a441/1434:restore   "/bin/bash"         5 hours ago         Exited (0) 5 hours ago                          bind_container_1434
7b5267fb23a0        hello-world                                "/hello"            29 hours ago        Exited (0) 29 hours ago                         pedantic_elion

# Aquí inspeccionamos y comprobamos que efectivamente el volumen está enlazado con la imagen restaurada, aunque en el path /dataRestore para diferenciarlo del original.
[whitebear@dockerHost bindVolume]$ sudo docker inspect -f '{{ .Mounts }}' 6188b7ee5750 ff90e0649713 d433913fb290
[{volume vDocker /var/lib/docker/volumes/vDocker/_data /data local z true }]
[]
[{volume vDocker /var/lib/docker/volumes/vDocker/_data /dataRestore local z true }]


4 Funcionalidades

El plugin Docker implementa las siguientes funcionalidades:

  • Respaldo basado en imagen de cualquier contenedor Docker.
  • Respaldo del sistema de imágenes de Docker.
  • Respaldo de volúmenes Docker.
  • Utilización de expresiones regulares para la selección de los elementos a respaldar.
  • Restauración de una imagen de Docker.
  • Restauración de un contenedor Docker como una nueva imagen Docker.
  • Capacidad de crear y ejecutar un contenedor Docker restaurado.
  • Capacidad de restaurar imágenes o contenedores a un directorio alternativo.
  • Capacidad de listar imágenes y contenedores existentes en el entorno Docker del cliente.

5 Plataformas soportadas

Se encuentran soportadas las siguientes plataformas basadas en linux: Debian Linux, Linux Ubuntu, Red Hat Enterprise Linux, Suse Enterprise Linux Edition, Open Suse.

Si necesita soporte para alguna otra plataforma adicional, por favor, póngase en contacto con soporte@wbsgo.com para consultar su compatibilidad.

6 Limitaciones

Actualmente, el plugin presenta las siguientes limitaciones:

  • Sólo lista imágenes, contenedores y volúmenes.
  • Restauración granular no soportada.
  • Sólo Full backups están disponibles.
  • Restauración con un nombre o id específico.
  • No permite mayúsculas en el nombre de las imágenes y contenedores.

7 Configuración del Cliente

Para realizar las copias de seguridad de los componentes de Docker con este plugin, no es necesario que instalar nada en cada uno de los contenedores. Simplemente es necesario desplegar agente y plugin en el cliente donde resida el demonio de Docker

7.1 Instalación y despliegue

Es necesario que el directorio Plugins esté definido correctamente en la configuración del FileDaemon:


bacula-fd.conf

FileDaemon {
    ...    

    Plugin Directory = /opt/bacula/plugins

    ...

}

A modo de ejemplo, se presenta el proceso de instalación de cliente y plugin en un entorno Debian Stretch de 64 bits. Para ello, se han realizado las descargas e instalaciones de los archivos ‘.deb’ del repositorio de Bacula, y ejecutado el siguiente comando:

Instalación manual cliente y plugin Docker
# Cliente
dpkg -i /tmp/bacula-enterprise-client_12.0.0_amd64.deb
# Plugin Docker
dpkg -i /tmp/bacula-enterprise-docker-plugin_12.0.0_amd64.deb

Tras la instalación (también si es necesario ajustar la configuración de bacula-fd.conf), es necesario reiniciar el servicio Bacula-fd en la máquina.

7.2 Comprobación de la instalación

Una vez instalado el plugin, para comprobar la correcta instalación del plugin se accederá mediante bconsole:

Comprobación instalación plugin
*status client=ClienteDocker
Connecting to Client ClienteDocker at 172.19.33.210:9102

ClienteDocker Version: 12.0.0 (23 May 2019)  x86_64-pc-linux-gnu-bacula-enterprise debian 9.6
Daemon started 18-Jun-19 12:26. Jobs: run=4 running=0.
 Ulimits: nofile=1024 memlock=65536 status=ok
 Heap: heap=135,168 smbytes=4,968,561 max_bytes=5,148,337 bufs=207 max_bufs=247
 Sizes: boffset_t=8 size_t=8 debug=300 trace=1 mode=0,2010 bwlimit=0kB/s
 Plugin: docker-fd.so(0.2.0) bpipe-fd.so(2) 

Running Jobs:
Director connected using TLS at: 18-Jun-19 13:31
No Jobs running.
====

7.3 Permisos

Si el cliente se va a ejecutar con un usuario que no sea root, se deberá tener en cuenta los permisos necesarios para acceder al demonio de Docker. Para poder realizar las peticiones a Docker el usuario encargado deberá de pertenecer al grupo docker. Una ligera prueba para comprobar si los permisos son los correctos sería una salida parecida a:

Salida del plugin con permisos correctos
*.ls client=ClienteDocker plugin=docker: path=image
Connecting to Client ClienteDocker at 172.19.33.210:9102
brw-r-----   1 root     root              125829120 2019-06-18 11:45:19  python:2.7-slim -> ca96bab3e2aa
brw-r-----   1 root     root                   1884 2019-06-18 11:45:19  hello-world:latest -> fce289e99eb9
2000 OK estimate files=3 bytes=263,194,460

Sin embargo, si no se tuviesen los permisos necesarios obtendríamos lo siguiente:

Salida con los permisos incorrectos
*.ls client=ClienteDocker plugin=docker: path=image
Connecting to Client ClienteDocker at 172.19.33.210:9102
dkcommctx: Error closing backend. Err=Child exited with code 1
brw-r-----   1 root     root                      0 2019-06-18 11:43:45  docker: listing=image:�$P� -> 
2000 OK estimate files=1 bytes=0


8 Configuración de WBSAirback ®

Cuidado con el nombre de los contenedores o imágenes

El plugin no permite el respaldo de contenedores o imágenes con alguna mayúscula en su nombre, deben de ser todo minúsculas.


8.1 Activación del plugin

Este plugin requiere de la activación del código de servicio asociado a Docker:

Figura 5. Servicio de suscripción de Docker

Una vez activado el servicio, podremos crear y gestionar los patrones de ficheros específicos del plugin Docker a través de la opción correspondiente de la sección de patrones de ficheros en el menú principal :

Figura 6. Secciones activas de los patrones de ficheros

8.2 Configuración cliente

La configuración del cliente puede llevarse a cabo de dos formas:

  • Cliente genérico: Este plugin es compatible con los clientes genéricos de WBSAirback ®. Esto implica que se podría emplear un cliente ya creado para este plugin, siempre y cuando éste disponga de un despliegue de Docker activo y se realice la instalación del plugin en dicho cliente, tal y como se describe en el punto 6.
  • Cliente específico: Este tipo de clientes son los específicos de Docker. Su diferencia reside en la posibilidad de realizar las copias y restauraciones de seguridad sin tener instalado un cliente de Bacula en el host de Docker.*

NOTA: Para que el demonio de Docker permita el acceso remoto se deberá de realizar el comando: "sudo dockerd -H tcp://ipHost". Donde el puerto por defecto es el 2375.

8.2.1 Cliente específico

Para la creación de este tipo de clientes se deberá de seleccionar el valor "Docker" en el desplegable de sistema operativo, donde deberemos de rellenar la dirección y el puerto donde el demonio de Docker realizará la escucha.

Figura 7. Creación de un cliente específico de Docker con sus parámetros

8.3 Patrón de ficheros Docker

Al entrar en la sección de los patrones de ficheros de Docker se mostrará la gestión de los diferentes patrones de ficheros Docker creados en el sistema. En esta pantalla se podrán realizar las operaciones de crear, editar, copiar y borrar.

Figura 8. Listado de los patrones de ficheros


En el formulario de creación de patrones de ficheros Docker se dispondrán de los siguientes parámetros:

Figura 9. Formulario de creación de un patrón de fichero de Docker

8.3.1 Parámetros

  • Cliente: Selección de cliente para incluir los parámetros de configuración de red. Una vez seleccionado el cliente, comprobará si está instalado el plugin de Docker, si es afirmativo los elementos para respaldar se actualizarán, sino se manifestará un error.
  • Opciones generales: Parámetros generales de Bacula.
  • Opciones del plugin: Paramétros específicos del plugin:
    • Incluir imagen1 : Campo que determinará las imágenes que se incluirán en el backup.
    • Excluir imagen1: Campo que determinará las imágenes que se excluirán del backup.
    • Incluir contenedor1: Campo que determinará los contenedores que se incluirán en el backup.
    • Excluir contenedor1Campo que determinará los contenedores que se excluirán en el backup.
    • Volumen1Campo que determinará los volúmenes que se incluirán en el backup.
    • Todos los volúmenes: Determinación de copiar todos los volúmenes que dispongan los contenedores.
  • Opciones avanzadas: Parámetros avanzados de conectividad.
    • Docker host: Dirección y puerto del host de Docker, para permitir la realización de copias y restauraciones de seguridad de forma remota sin el empleo de tener un cliente Bacula en el host de Docker. Si seleccionamos un cliente específico de Docker(Explicado en el anterior apartado) este campo se autorellenará y no será posible su edición. 
    • Timeout: Tiempo de espera máximo de comunicación con el host de Docker.
    • Modo: En el respaldo de contenedores esta opción permitirá hacer un respaldo más seguro y completo, a cambio de prescindir de algunas operaciones I/O.
  • Listado de elementos disponibles: Estructura basada en el árbol de directorios. Al clickar en cada elemento realizará una petición al cliente Docker para consultar el elemento de la lista.

NOTA 1: Este campo permite utilizar varias expresiones regulares separadas por una ','. Este campo está sincronizado con los  listado de elementos disponibles.


En este plugin, al permitir el uso de expresiones regulares para la inclusión o exclusión de elementos (imágenes, contenedores y volúmenes(Sólo inclusión)) se establece que el resultado será por el orden de la aplicación de las expresiones de inclusión y por consiguiente, las expresiónes de exclusión. Dicho de otra forma, las expresiones excluyentes tienen prioridad sobre las incluyentes

8.3.2 Funcionalidades extra

En la pantalla de creación y edición de los patrones de ficheros de Docker contiene unos comportamientos específicos:

  • Autocompletado del campo cliente - Es un campo de texto que ayuda al usuario a elegir el cliente autocompletando la entrada de dicho usuario.

Figura 10. Autocompletado del parámetro cliente

  • Comprobación de la compatibilidad con el cliente - Una vez seleccionado el cliente, automáticamente comprobará que el cliente es compatible. En caso afirmativo, el árbol realizará la petición de listado y en caso negativo, mostará un error en el campo cliente.

  

Figura 11. Comprobación de la compatibilidad del cliente


  • Navegación interna del árbol - Con el click izquierdo se permite navegar con el listado accediendo como si fuese una estructura de directorios. En el caso particular de este plugin sólo se permite navegar a través de los directorios '/image' , '/container' y '/volume'.


  • Eliminación de la caché del listado - Permite eliminar la caché almacenada en WBSAirback ®, realizar la petición directamente al cliente y representar esta última en el árbol. Por defecto, se empleará la caché almacenada en WBSAirback ®, pero el usuario puede modificar este comportamiento realizando un click sobre el icono de recargar y luego clickando sobre cualquier elemento que quiera realizar la petición directa y actualice la caché de WBSAirback ®.


Figura 12. Cambio en la eliminación de la caché          

  • Sincronización entre campos - Permite la visualización  del resultado de los diferentes campos del patrón en el árbol. Es decir, aplica las diferentes expresiones de cada unos de los campos, con sus respectivas consecuencias, al árbol. 

Figura 13. Sincronización entre los inputs y el árbol

  • Exclusión individual - A través del click derecho del ratón sobre un elemento que no sea ni '/image' ni '/container', aparecerá un menú que podremos excluir directamente ese elemento. Posicionándose en el campo correspondiente.

Figura 14. Exclusión interactiva de un elemento Docker


9 Backup

En el cliente genérico de Docker, podemos configurar un job con todos sus parámetros habituales y seleccionar un patrón de ficheros de tipo Docker:

Figura 15. Creación de un job

Una vez configurado, podremos ver la evolución del job mediante las secciones de administración de trabajos habituales de WBSAirback ®:

Figura 16. Listado de las ejecuciones de un job

A continuación podemos ver un ejemplo de log de un backup:

Figura 17. Log de una ejecución de un job

10 Recuperación

Para la recuperación de contenedores e imágenes se puede realizar de dos formas, o de una forma local que se obtendría el archivo .tar que almacena el elemento respaldado, o empleando la restauración del plugin, que es interactiva y directa en la restauración.

10.1 Recuperación de archivos

Para la recuperación del archivo que conforma el elemento respaldado (.tar) se podrá realizar a través de los ficheros almacenados del cliente

10.2 Recuperación por job

La recuperación por job se accede seleccionando un job desde cualquier listado de jobs realizados y completado correctamente, y accediendo a la sección de "Fichero" como se muestra en la Figura 18:

Figura 18. Acceso a la recuperación de archivos de un backup Job

En la siguiente pantalla, mostrada en la Figura 19, seleccionamos restauración de imágenes y contenedores

Figura 19. Acceso a la recuperación por archivo o completa

Figura 20. Pantalla de restauración completa

En la Figura 20 se muestra la pantalla de restauración de un job individual. Esta pantalla será explicada mediante las zonas marcadas del color:

  • Rojo: Los elementos respaldados en el job se mostrará en forma de árbol y se podrá seleccionar tantos elementos como se quieran restaurar.
  • Verde: Selección del cliente destino. Se permite restaurar un job de un cliente a otro cliente, siempre y cuando cumpla con el requisito de tener instalado el plugin de Docker.
  • Azul: Las opciones del plugin específicas de la restauración.
  • Naranja: El botón que antes de iniciar la restauración realizará una confirmación con los parámetros que se emplearán para la restauración. Y después de confirmar lanzará la restauración.

10.3 Recuperación por fecha o versión

En esta pantalla se accede a través de los "Ficheros respaldados" del cliente en lugar del job específico. Es parecida a la pantalla mostrada en la Figura 20, pero con la diferencia de que en el apartado rojo aparecerá un listado de todos los elementos que actualmente tiene el cliente y cuando se seleccionen los elementos que se quiera restaurar, se podrá realizar en base a(Figura 21 apartado verde) las versiones que se hayan respaldado en los distintos jobs, o por la fecha indicada por el usuario (Apartado rojo de la Figura 21).


Figura 21. Pantalla de restauración por fecha

11 Renombrado manual

Debido a las limitaciones del plugin no se permite un renombrado completo de la imagen o contenedor restaurado desde la interfaz WBSAirback ®. Sin embargo, es posible hacerlo de forma manual mediante los siguientes comandos en el cliente:

Renombramiento de imágenes Docker
docker tag <old_name> <new_name>
docker rmi <old_name>



12 Contacto

Consultas o dudas relativas al presente documento, pueden dirigirlas a:

Jorge Gea

e: jorge.gea@wbsgo.com

Francisco García

e: francisco.garcia@wbsgo.com



WBSAirback

19

WhiteBearSolutions, WBSgo y WBSAirback y sus correspondientes logos son marcas registradas propiedad de WhiteBearSolutions, S.L.

WhiteBearSolutions realiza los mayores esfuerzos para asegurar que la información facilitada en el presente documento es precisa y exacta.

No obstante, no se responsabiliza de cualquier error o inexactitud de la misma recogido en el documento.

Las especificaciones e informaciones recogidas en el presente documento pueden ser modificadas sin previo aviso.

WhiteBearSolutions (WBSgo)

Calle Severo Ochoa 3, Planta 1 Of. 7 – 28232, Las Rozas (Madrid)
t. 902 90 69 69 f. 902 90 69 70 

13 Referencias

[1] ¿Porqué utilizar contenedores? - Página oficial de Kubernetes

14 Versiones

Historial de versiones del presente documento:


1.4Francisco GarcíaCompletada la sección del respaldo de volúmenes. 

1.3Francisco GarcíaAñadido cliente específico de Docker, actualización de imágenes y sus leyendas.

1.2Jorge GeaCorrecciones menores

 

1.1Francisco GarciaCorrecciones de la revisión

 

1.0Jorge GeaRevisión

 

1.0Francisco GarciaPrimera versión documento completo. Backup, restore, capturas...

  

0.1Francisco GarciaPrimera versión documento: Estructura y primeras secciones

  

  • No labels