Copia de seguridad y restauración completa de GeoNode¶

El comando de administración para realizar copias de seguridad y restaurar GeoNode, permite extraer consistentemente los modelos de datos de GeoNode y GeoServer en un metaformato serializable que luego es interpretado por el procedimiento de restauración para reconstruir exactamente toda la estructura.

En particular, la herramienta ayuda a los desarrolladores y administradores a extraer y serializar correctamente los siguientes recursos:

GeoNode (Modelo base de recursos):
1. Capas (tanto raster como vectoriales)
2. Mapas
3. Documentos
4. Personas con Credenciales
5. Permisos
6. Estilos asociados
7. Datos estáticos y plantillas
GeoServer (Catálogo):
1. Configuración y límites de los servicios OWS
2. Modelo de seguridad junto con la configuración de filtros de autenticación, usuarios y credenciales
3. Espacios de trabajo
4. Almacenes (tanto DataStores como CoverageStores)
5. Capas
6. Estilos

La herramienta expone dos comandos de administración de GeoNode, “copia de seguridad” y “restaurar”.

Los comandos permiten:

Realizar una copia de seguridad completa de los datos y dispositivos de GeoNode en un archivo zip
Realizar una copia de seguridad completa de la configuración de GeoServer (conjuntos de datos físicos: tablas, shapefiles, geotiffs)
Restaurar completamente los accesorios y el catálogo de GeoNode y GeoServer desde el archivo zip

El uso de estos comandos es bastante fácil y directo.

El primer paso es asegurarse de que todo esté configurado correctamente y se respeten los requisitos para poder realizar con éxito una copia de seguridad y restauración de GeoNode.

Advertencia

Vale la pena señalar que esta funcionalidad requiere la última versión de GeoServer Extension (2.9.x o superior) para GeoNode para funcionar correctamente.

Nota

La documentación completa de GeoServer también está disponible aquí GeoServer Docs

Requisitos y configuración¶

Antes de ejecutar una copia de seguridad/restauración de GeoNode, es necesario asegurarse de que todo esté configurado y preparado correctamente.

Ajustes¶

Según las necesidades del administrador, se debe crear el archivo settings.ini antes de ejecutar una copia de seguridad o restauración.

Los archivos predeterminados se pueden encontrar en geonode/br/management/commands/settings_sample.ini y geonode/br/management/commands/settings_docker_sample.ini para los entornos clásico y Docker, respectivamente. El contenido es similar en ambos (un ejemplo de settings_sample.ini):

[database]
pgdump = pg_dump
pgrestore = pg_restore

[geoserver]
datadir = geoserver/data
dumpvectordata = yes
dumprasterdata = yes

[fixtures]
# NOTE: Order is important
apps  = contenttypes,auth,people,groups,account,guardian,admin,actstream,announcements,avatar,base,dialogos,documents,geoserver,invitations,pinax_notifications,layers,maps,oauth2_provider,services,sites,socialaccount,taggit,tastypie,upload,user_messages
dumps = contenttypes,auth,people,groups,account,guardian,admin,actstream,announcements,avatar,base,dialogos,documents,geoserver,invitations,pinax_notifications,layers,maps,oauth2_provider,services,sites,socialaccount,taggit,tastypie,upload,user_messages

El archivo settings.ini se puede crear en cualquier directorio accesible por GeoNode, y su ruta se puede pasar a los procedimientos de respaldo/restauración usando el argumento -c (–config).

Hay algunas secciones diferentes del archivo de configuración que deben revisarse cuidadosamente antes de ejecutar un comando de copia de seguridad/restauración.

Configuración: Sección [base de datos]¶

[database]
pgdump = pg_dump
pgrestore = pg_restore

Esta sección es bastante sencilla. Contiene sólo dos propiedades:

pgdump; la ruta del comando local pg_dump.
pgrestore; la ruta del comando local pg_restore.

Advertencia

Esas propiedades se ignoran en caso de que GeoNode no esté configurado para usar una base de datos como backend (consulte las secciones settings.py y local_settings.py)

Nota

Las configuraciones de conexión de la base de datos (tanto para GeoNode como para GeoServer) se tomarán de los archivos de configuración settings.py y local_settings.py. Asegúrese de que estén correctamente configuradas (también en la instancia de GeoNode de destino) y que el servidor de base de datos sea accesible mientras se ejecuta un comando de copia de seguridad/restauración.

Configuración: Sección [geoserver]¶

[geoserver]
datadir = /opt/gs_data_dir
datadir_exclude_file_path =
dumpvectordata = yes
dumprasterdata = yes
data_dt_filter =
data_layername_filter =
data_layername_exclude_filter =

Esta sección permite habilitar / deshabilitar una copia de seguridad / restauración completa de datos de GeoServer.

datadir: la ruta completa del directorio de datos de GeoServer, de manera predeterminada /opt/gs_data_dir. La ruta debe ser accesible y completamente escribible por los usuarios de geonode y/o httpd server al ejecutar un comando de copia de seguridad/restauración.
datadir_exclude_file_path: lista separada por comas de rutas a excluir de geoserver_catalog.zip; esta lista será enviada y administrada directamente por la API REST de GeoServer Backup.
dumpvectordata: un indicador booleano que habilita o deshabilita la creación de un volcado de datos vectoriales desde GeoServer (shapefiles o tablas de bases de datos). Si es false (o no) los datos vectoriales no se almacenarán ni se volverán a almacenar.
dumprasterdata: un indicador booleano que habilita o deshabilita la creación de un volcado de datos raster desde GeoServer (geotiffs). Si es false (o no) los datos raster no se almacenarán ni se volverán a almacenar.
data_dt_filter: {cmp_operator} {ISO8601} e.g. > 2019-04-05T24:00 que significa «incluir en el archivo de respaldo solo los archivos que se hayan modificado después de 2019-04-05T24:00
data_layername_filter: lista separada por comas de nombres de capas, opcionalmente con sintaxis global, p. ej.: tuscany_*,italy; Solo los datos originales RASTER y los volcados de tablas VECTORIAL que coincidan con esos filtros se incluirán en el archivo ZIP de respaldo
data_layername_exclude_filter: lista separada por comas de nombres de capas, opcionalmente con sintaxis global, p. ej.: tuscany_*,italy; Los datos originales RASTER y los volcados de la tabla VECTORIAL que coincidan con esos filtros se excluirán del archivo ZIP de respaldo

Advertencia

Para habilitar estas opciones se requiere que el directorio de datos de GeoServer sea accesible y totalmente escribible para los usuarios de geonode y/o servidor httpd al ejecutar un comando de respaldo/restauración.

Ajustes: Sección [partidos]¶

[fixtures]
#NOTE: Order is important
apps   = people,account,avatar.avatar,base.backup,base.license,base.topiccategory,base.region,base.resourcebase,base.contactrole,base.link,base.restrictioncodetype,base.spatialrepresentationtype,guardian.userobjectpermission,guardian.groupobjectpermission,layers.uploadsession,layers.style,layers.layer,layers.attribute,layers.layerfile,maps.map,maps.maplayer,maps.mapsnapshot,documents.document,taggit

dumps  = people,accounts,avatars,backups,licenses,topiccategories,regions,resourcebases,contactroles,links,restrictioncodetypes,spatialrepresentationtypes,useropermissions,groupopermissions,uploadsessions,styles,layers,attributes,layerfiles,maps,maplayers,mapsnapshots,documents,tags

Esta sección es la más compleja. Normalmente no es necesario modificarla. Solo un usuario experto que conozca Python y la estructura del modelo GeoNode debería modificar esta sección.

Qué significan sus propiedades:

apps; una lista ordenada de aplicaciones Django de GeoNode. El procedimiento de copia de seguridad/restauración volcará/restaurará los datos en un formato portátil.
dumps; esta es la lista de archivos asociados a las aplicaciones de Django. El orden debe ser el mismo que en la propiedad apps anterior. Cada nombre representa el nombre de archivo donde volcar o leer los accesorios de la aplicación individual.

Ejecutando desde la CLI¶

Las siguientes secciones muestran instrucciones sobre cómo realizar copias de seguridad/restauraciones desde la línea de comandos utilizando los comandos de administración de Django.

Para obtener una guía básica de usuario para el comando de administración desde la línea de comandos, simplemente ejecute

python manage.py backup --help

python manage.py restore --help

--help proporcionará la lista de opciones de línea de comando disponibles con una breve descripción.

Por defecto, ambos procedimientos activan el modo Read Only, deshabilitando cualquier petición de modificación de contenido, que vuelve al estado anterior (antes de la ejecución) al finalizar, independientemente del resultado del comando (éxito o fracaso). Para deshabilitar la activación de este modo, se puede pasar al comando el argumento --skip-read-only.

Vale la pena notar que ambos comandos permiten la siguiente opción

python manage.py backup --force / -f

python manage.py restore --force / -f

Esto habilita un modo no interactivo, lo que significa que no se le pedirá al usuario una confirmación explícita.

Respaldo¶

Para realizar una copia de seguridad simplemente ejecute el comando:

python manage.py backup --backup-dir=<target_bk_folder_path> --config=</path/to/settings.ini>

En caso de éxito, el comando de administración generará automáticamente un archivo comprimido .zip en la carpeta de destino. En el directorio de destino se creará un archivo .md5 con el mismo nombre que la copia de seguridad. Contiene el hash MD5 del archivo de copia de seguridad, que se puede utilizar para comprobar la integridad del archivo comprimido antes de la restauración.

Vale la pena mencionar que br (aplicación Backup & Restore GeoNode) no se volcará, incluso si se especifica en settings.ini, ya que su contenido está estrictamente relacionado con la instancia específica de GeoNode.

Actualmente, GeoNode no admite la extracción automática del archivo de copia de seguridad. Si es necesario, se debe transferir manualmente al entorno de la instancia de destino.

Restaurar¶

El comando restore tiene una serie de argumentos que modifican su ejecución:

# -c / --config: ruta al archivo de configuración settings.ini. Si se proporciona el archivo de copia de seguridad con sus configuraciones, el comando de restauración utilizará estas últimas y esta opción ya no será obligatoria

--skip-geoserver: no se realizará la restauración de la copia de seguridad de GeoServer
--skip-geoserver-info: {Predeterminado: True} Omite la información global de GeoServer, como la URL base del proxy y otra información de metadatos globales de GeoServer
--skip-geoserver-security: {Predeterminado: True} Omite todas las configuraciones de seguridad de GeoServer
--backup-file: (exclusivo junto con --backup-files-dir) ruta al archivo de respaldo .zip
--backup-files-dir: (exclusivo junto con --backup-file) directorio que contiene archivos de copia de seguridad. El directorio puede contener varios archivos, pero solo se permiten archivos de copia de seguridad con una extensión .zip. En caso de que haya varios archivos en el directorio, se restaurará el más nuevo, creado después de la hora de creación de la última copia de seguridad ya restaurada. Esta opción se implementó pensando en las restauraciones automáticas.
--recovery-file: Archivo de respaldo que contiene datos de GeoNode para restaurar en caso de falla.
-l / --with-logs: el archivo de copia de seguridad se comparará con los registros de restauración (historial). En caso de que esta copia de seguridad ya se haya restaurado (comparación basada en MD5), se genera un error RuntimeError que impide la ejecución de la restauración.
-n / --notify: el resultado del procedimiento de restauración se enviará mediante una notificación por correo electrónico a los superusuarios de la instancia (nota: la notificación se enviará a los superusuarios de la instancia antes de la restauración).
--skip-read-only: el procedimiento de restauración se llevará a cabo sin configurar el modo Solo lectura durante la ejecución.
--soft-reset: el procedimiento de restauración conservará la tabla y los recursos de geoserver durante la restauración. De manera predeterminada, el procedimiento eliminará las tablas y los recursos

Para realizar una restauración de copia de seguridad predeterminada, simplemente ejecuta el comando:

python manage.py restore --backup-file=<target_restore_file_path> --config=</path/to/settings.ini>

Para que se ejecute la restauración, se requiere el argumento --backup-file o --backup-files-dir definido.

Advertencia

La restauración sobrescribirá todas las instancias de destino de GeoNode (y por defecto GeoServer), incluidos los usuarios, el catálogo y la base de datos, así que tenga mucho cuidado.

Inspección de la interfaz gráfica de usuario de administración de GeoNode¶

El historial de copias de seguridad restauradas se puede verificar en el panel de administración.

Inicia sesión en el panel de administración y selecciona la tabla «Copias de seguridad restauradas» de la aplicación «COPIA DE SEGURIDAD/RESTAURACIÓN».

Se mostrará una lista con el historial de todas las copias de seguridad restauradas. Puedes seleccionar una copia de seguridad determinada para ver sus datos.

La vista detallada de la copia de seguridad restaurada muestra el nombre del archivo de copia de seguridad, su hash MD5, su fecha de creación o modificación (en la carpeta de destino) y la fecha de la restauración. Ten en cuenta que el historial de copias de seguridad restauradas no se puede modificar.

B/R en el entorno Docker¶

Al ejecutar B/R en el entorno Docker, la creación de la copia de seguridad y la restauración desde la misma se deben realizar en el directorio /backup_restore. Es un volumen compartido entre las imágenes de Geoserver y Geonode, creado solo para este propósito. Si se apunta a otra ubicación, fallará, ya que una de las imágenes no tendrá acceso a los archivos.

Advertencia

Al ejecutar B/R en el entorno Docker, recuerda crear el archivo settings.ini basándose en settings_docker_sample.ini para apuntar a un directorio de datos de Geoserver adecuado. En otro caso, la falta de coincidencia de configuración puede provocar errores inesperados.

Advertencia

El único otro volumen compartido entre imágenes es /geoserver_data/data, pero la creación de copias de seguridad no debería realizarse allí, ya que en ese caso se pueden crear copias de seguridad recursivas de Geoserver.

Trabajo de B/R Jenkins en el entorno Docker¶

Al instalar GeoNode a través del Docker geonode-project (ver Instalación básica de GeoNode), también se implementa automáticamente una instancia de Jenkins CI/CD y está disponible a través de http://<geonode_host>/jenkins.

Configurar Jenkins en el primer inicio¶

La primera vez que intentes acceder a Jenkins, deberás desbloquearlo y generar un nuevo nombre de usuario y contraseña de administrador.

Para hacer esto, debes imprimir el contenido del archivo generado automáticamente /var/jenkins_home/secrets/initialAdminPassword

En primer lugar, busca el ID del contenedor de Jenkins, generalmente jenkins4{{project_name}} donde {{project_name}} es el nombre de tu instancia geonode-project (por ejemplo, my_geonode)

$ docker ps

  CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                                                                                NAMES
  e9fc97a75d1a        geonode/nginx:geoserver      "/docker-entrypoint.…"   2 hours ago         Up 2 hours          0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp                                             nginx4my_geonode
  c5496400b1b9        my_geonode_django            "/bin/sh -c 'service…"   2 hours ago         Up 2 hours                                                                                               django4my_geonode
  bc899f81fa28        my_geonode_celery            "/bin/sh -c 'service…"   2 hours ago         Up 2 hours                                                                                               celery4my_geonode
  3b213400d630        geonode/geoserver:2.17.1     "/usr/local/tomcat/t…"   2 hours ago         Up 2 hours          8080/tcp                                                                             geoserver4my_geonode
  d2f59d70a0d3        geonode/postgis:11           "docker-entrypoint.s…"   2 hours ago         Up 2 hours          5432/tcp                                                                             db4my_geonode
  3f9ce0be7f88        rabbitmq                     "docker-entrypoint.s…"   2 hours ago         Up 2 hours          4369/tcp, 5671-5672/tcp, 25672/tcp                                                   rabbitmq4my_geonode
  02fdbce9ae73        geonode/letsencrypt:latest   "./docker-entrypoint…"   2 hours ago         Up 14 seconds                                                                                            my_geonode_letsencrypt_1
  c745520fd551        jenkins/jenkins:lts          "/sbin/tini -- /usr/…"   2 hours ago         Up 2 hours          0.0.0.0:9080->9080/tcp, 8080/tcp, 0.0.0.0:50000->50000/tcp, 0.0.0.0:9443->8443/tcp   jenkins4my_geonode

Ahora simplemente haz un cat del archivo anterior dentro del contenedor de Jenkins

$ docker container exec -u 0 -it jenkins4my_geonode sh -c 'cat /var/jenkins_home/secrets/initialAdminPassword'

  b91e9d*****************373834

Copia el código hash que acabas de obtener de la impresión anterior y cópialo y pégalo en la ventana del navegador

En el siguiente paso, simplemente instala los complementos predeterminados. Puedes instalar más complementos más adelante desde la página de administración.

Espera hasta que Jenkins haya terminado de configurar los complementos

Proporciona las credenciales de administrador según lo solicitado

Confirma la URL de la instancia de Jenkins, esto se puede cambiar desde la configuración más adelante en caso de que necesites actualizar la dirección del servidor

Bien hecho, Jenkins ya está listo

El siguiente paso es configurar un trabajo de Jenkins capaz de interactuar con el contenedor Docker de Django y ejecutar una copia de seguridad completa

Configurar un trabajo de Jenkins para ejecutar una copia de seguridad completa en el contenedor de Django¶

Antes de crear el nuevo trabajo de Jenkins, necesitamos instalar y configurar un nuevo complemento, Publicar sobre SSH

Para hacer eso, una vez que hayas iniciado sesión como admin, ve a la página de administración de Jenkins > pestaña Administrar complementos

Haz clic en la pestaña Disponibles y busca los complementos SSH disponibles

Selecciona y marque la opción Publicar mediante SSH

Instalar los complementos y reiniciar Jenkins

El siguiente paso es configurar la «Conexión del servidor SSH» para el complemento Publicar sobre SSH.

Mover a Configuración de Jenkins

Desplázate hacia abajo hasta encontrar la sección del complemento Publish over SSH

Dependiendo de cómo se haya configurado su servicio HOST SSH, es posible que necesites diversa información para configurar la conexión.

A continuación se muestra un ejemplo que utiliza un host global (master.demo.geonode.org) que acepta conexiones SSH a través de claves RSA

Nota

Antes de guardar la configuración, asegúrate siempre de que la conexión sea correcta utilizando el botón Probar configuración

También es posible ejecutar y configurar Jenkins para que se ejecute localmente, como una instancia en localhost. En ese caso, deberás cambiar algunas cosas para permitir que Jenkins acceda a tu red local.

En primer lugar, asegúrate que el servidor OpenSSH esté instalado y funcionando correctamente en su PC. Por último, verifica las reglas del firewall.
```
$ sudo apt install openssh-server
```

# Prueba tu conexión localmente

$ ssh -p 22 user@localhost
user@localhost's password:

Necesitarás realizar algunos cambios en tu archivo docker-compose.yml para habilitar la configuración de la ``red del host`.

Nota

Habilitar network_mode: "host" en el contenedor Jenkins

$ vim docker-compose.yml

...
jenkins:
   image: jenkins/jenkins:lts
   # image: istresearch/jenkins:latest
   container_name: jenkins4${COMPOSE_PROJECT_NAME}
   user: jenkins
   ports:
      - '${JENKINS_HTTP_PORT}:${JENKINS_HTTP_PORT}'
      - '${JENKINS_HTTPS_PORT}:${JENKINS_HTTPS_PORT}'
      - '50000:50000'
   network_mode: "host"
   volumes:
      - jenkins_data:/var/jenkins_home
      - backup-restore:/backup_restore
      # - /var/run/docker.sock:/var/run/docker.sock
   environment:
      - 'JENKINS_OPTS=--httpPort=${JENKINS_HTTP_PORT} --httpsPort=${JENKINS_HTTPS_PORT} --prefix=/jenkins'
...

# Recreate the Jenkins container
$ docker-compose stop jenkins
$ docker-compose rm jenkins
$ docker-compose up -d jenkins

Advertencia

A partir de ahora, tu instancia local de Jenkins será accesible desde http://localhost:9080/jenkins

Agrega el servidor localhost a la configuración del complemento Publicar sobre SSH

Modo http://localhost:9080/jenkins/configure y completa la información requerida

Nota

Antes de guardar la configuración, asegúrate siempre de que la conexión sea correcta utilizando el botón Probar configuración

Ahora estamos listos para crear el trabajo de Jenkins que ejecutará una copia de seguridad y restauración completa de nuestra instancia acoplada de GeoNode.

Ve a la página de inicio de Jenkins y haz clic en el botón Crear un trabajo
Proporciona un nombre al trabajo y selecciona Proyecto Freestyle
Habilita la estrategia Rotación de registros si es necesario
Configura los Parámetros del trabajo que utilizará el script más adelante.

Agrega tres Parámetros de cadena

como se muestra a continuación
1. BKP_FOLDER_NAME
2. SOURCE_URL
  
  Advertencia
  
  Proporciona la URL correcta de tu instancia de GeoNode
3. TARGET_URL
  
  Advertencia
  
  Proporciona la URL correcta de tu instancia de GeoNode
Habilita las opciones Eliminar espacio de trabajo antes de que comience la compilación y Agregar marcas de tiempo a la salida de la consola Entorno de compilación

Finalmente, vamos a crear el paso de compilación SSH Build Step

Selecciona el Servidor SSH correcto y proporcione el Comando de ejecución a continuación

Advertencia

Reemplaza {{project_name}} con su nombre de instancia de geonode-project (por ejemplo, my_geonode)

# Replace {{project_name}} with your geonode-project instance name (e.g. my_geonode)
# docker exec -u 0 -it django4{{project_name}} sh -c 'SOURCE_URL=$SOURCE_URL TARGET_URL=$TARGET_URL ./{{project_name}}/br/backup.sh $BKP_FOLDER_NAME'
# e.g.:
docker exec -u 0 -it django4my_geonode sh -c 'SOURCE_URL=$SOURCE_URL TARGET_URL=$TARGET_URL ./my_geonode/br/backup.sh $BKP_FOLDER_NAME'

Haz clic en Avanzado y cambia los parámetros como se muestra a continuación

¡Guarda! Estás listo para ejecutar el trabajo…

Vincula la carpeta backup_restore a una carpeta local en el HOST¶

En caso de que necesites guardar los archivos de respaldo fuera del contenedor Docker, existe la posibilidad de vincular directamente la carpeta backup_restore a una carpeta local en el HOST.

En ese caso, no necesitarás copiar y pegar los archivos cada vez desde los contenedores, estarán disponibles directamente en el sistema de archivos del host.

Advertencia

Deberías estar siempre atento al espacio en disco. Los archivos de respaldo pueden ser enormes.

Nota

También podrías considerar filtrar los archivos a través de los filtros de respaldo en el settings.ini para reducir el tamaño de los archivos de respaldo, incluyendo solo los nuevos.

Modifica docker-compose.override.yml de la siguiente manera para vincular las carpetas de respaldo externas.

Nota

/data/backup_restore es una carpeta ubicada físicamente en el sistema de archivos del host.

$ vim docker-compose.override.yml

version: '2.2'
services:

django:
   build: .
   # Loading the app is defined here to allow for
   # autoreload on changes it is mounted on top of the
   # old copy that docker added when creating the image
   volumes:
      - '.:/usr/src/my_geonode'
      - '/data/backup_restore:/backup_restore'  # Link to local volume in the HOST

celery:
  volumes:
    - '/data/backup_restore:/backup_restore'  # Link to local volume in the HOST

geoserver:
  volumes:
    - '/data/backup_restore:/backup_restore'  # Link to local volume in the HOST

jenkins:
  volumes:
    - '/data/backup_restore:/backup_restore'  # Link to local volume in the HOST

# Restart the containers
$ docker-compose up -d