Avanzado

Funcionalidad completa del kit

Este Anexo abarcará toda la información sobre las posibles configuraciones y utilidades no cubiertas en la pestaña principal del documento.

All.yml explicado

En el kit se incluye un archivo, all.yml, en el cual se contienen muchas variables, algunas de ellas no incluidas en el fichero por defecto, y opciones editables para facilitar la gestión técnica del entorno. A continuación se detallan las funciones disponibles:

Versionado

Con el kit 25.a1 se incluye una selección automática del último artefacto disponible mediante el versionado basado en producto.

• version.anjana: permite la selección de versión basada en producto. En este caso, al seleccionar 25.1, se descargarán automáticamente los paquetes más recientes disponibles de 25.1 cuando se realice un update.

• version.rc: permite la descarga de versiones release canditate (prerelease) antes de su publicación oficial. ❌NO RECOMENDADO: pueden no ser estables, usar con responsabilidad.

version.core / version.plugins: estas dos claves permiten definir de forma individual, versiones para microservicios del core y plugins.

Las versiones especificadas de forma individual tienen preferencia sobre la versión de producto indicada. Un microservicio o plugin con versión fijada no será actualizado de forma automática más allá de la versión fijada.

• version.utilities.ansible: define la versión de kit que será descargada al ejecutar el tag ansible. Necesario para el proceso de actualización del kit.

• version.utilities.sampledata: engloba las dos claves para definir la versión y tipo de kit de datos de ejemplo que se descargará en caso de ser indicado tanto en el despliegue con datos de ejemplo, como la operación de reset e inserción de datos.

Cadenas de conexión

Se ha incluido configuración por defecto para facilitar su uso y reducir el número de modificaciones necesarias para que el entorno funcione.

• nexus.url: dominio del servidor de Anjana que provee los artefactos durante la instalación y otras operaciones. Configurado como valor por defecto, no es necesario añadir esta propiedad si no se quiere modificar su valor.

• nexus.user y nexus.pass: credenciales de conexión a nexus. Necesario solicitarlas en cs@anjanadata.com.

• nexus.external: repositorios provistos por Anjana para la descarga de artefactos, definidos por defecto.

Persistences.s3 permite la edición de las credenciales y personalizaciones necesarias para el despliegue de MinIO o la conexión a la tecnología S3 elegida.

• persistences.s3.type: permite alternar entre MinIO y AWS S3 como servicio de almacenamiento de buckets.

• persistences.s3.access_key y persistences.s3.secret_key: credenciales de acceso a la tecnología. Valores por defecto provistos, pueden ser alterados.

• persistences.s3.host: url de conexión a la tecnología S3. SOLO MinIO.

• persistences.s3.port: puerto especificado para la conexión a la tecnología S3. SOLO MinIO.

• persistences.s3.region: región cloud donde ubicar los buckets. SOLO AWS S3.

• persistences.s3.endpoint: permite que el tráfico entre Anjana y los bucket se limite a la VPC sin salida a internet utilizando un endpoint privado de tipo gateway. SOLO AWS S3.

• persistences.s3.buckets: buckets de operaciones de Anjana. Valores por defecto, no se incluyen las propiedades en el fichero provisto. ✅RECOMENDADO: dejar los valores por defecto.

persistences.s3.dump_bucket: permite mediante segregation true/false activar o desactivar la segregación del bucket dump como medio de volcado de datos. Esto permitirá a los buckets de Anjana situarse en MinIO mientras anjanabackups está en AWS S3, o viceversa.
El esto de propiedades se rellenarán como lo mencionado anteriormente.

Persistences.bbdd permite la edición de las credenciales y personalizaciones necesarias para el despliegue de PostgreSQL o la conexión con RDS.

• persistences.bbdd.host: url de conexión a la BBDD.

• persistences.bbdd.port: puerto especificado para la conexión a la BBDD.

• persistences.bbdd.database: nombre de la base de datos para la conexión.

• persistences.bbdd.user y persistences.bbdd.pass: credenciales de acceso a la BBDD. Valores

• persistences.bbdd.default_schema: esquemas de la BBDD de Anjana. Valores por defecto, no se incluyen las propiedades en el fichero provisto. ✅RECOMENDADO: dejar los valores por defecto.

Persistences.solr permite la edición de los parámetros de conexión y algunos ajustes para el motor de indexación. Actualmente no se incluye este apartado en el fichero all.yml provisto, todos los valores han sido establecidos por defecto.

• persistences.solr.host: url de conexión al indexador.

• persistences.solr.port: puerto especificado para la conexión con el indexador.

• persistences.solr.startup: permite alterar el comportamiento del motor de indexación durante el arranque de Minerva. ❌NO RECOMENDADO: alterar el valor por defecto, puede ocasionar resultados no deseados y pérdida de datos.

• persistences.solr.collections: colecciones por defecto de Anjana. ✅RECOMENDADO: dejar los valores de las colecciones provistas por defecto.

Configuración de instalación

Este apartado permite configurar y personalizar el despliegue de Anjana. Por defecto, ya se encuentra establecidos los parámetros recomendados.

• anjana.domain: permite establecer el dominio de acceso a la instancia de Anjana. ⚠️IMPORTANTE: este parámetro es requerido para que Anjana funcione correctamente en un entorno PRE/PROductivo. El certificado wildcard asociado a ese dominio debe encontrarse disponible en /opt/common/anjana-certs/ para que la instancia funcione.

• anjana.folder: carpeta raíz para el despliegue de todo Anjana. Establecido por defecto /opt.

• anjana.configURL: ruta al microservicio de configuración, ya establecido por defecto.
  ❌NO RECOMENDADO: definir esta propiedad a menos que sea necesario.

• anjana.configPath: directorio donde se almacenará la configuración, ya establecido por defecto.

• anjana.plugins_config.standalone: cuando está true, permite que los plugins funcionen en modo standalone, no necesitarán de horus para funcionar. El fichero de configuración será desplegado en el mismo nodo que el plugin.

• anjana.plugins_config.vault.type: corresponde al tipo de vault que se usa para alojar propiedades de la configuración de los plugins, siendo none lo correspondiente a false.
  ⚠️IMPORTANTE:para que la configuración mediante vault funcione, es requerido que la config para plugins sea standalone.

• anjana.plugins_config.vault.host: permite configurar el host o url de acceso al vault. SOLO Azure o GCP.

• anjana.plugins_config.vault.client_id: permite configurar el client_id de acceso al vault. SOLO Azure o GCP.

• anjana.plugins_config.vault.secret_id: permite configurar el secret_id de acceso al vault. SOLO Azure o GCP. Para GCP será la ruta al fichero de credenciales .json necesario.

• anjana.plugins_config.vault.tenant_id: id del proyecto o tenant al cual se quiere conectar. SOLO Azure o GCP.

• anjana.license: permite indicar la licencia de Anjana para habilitar el uso del producto. Necesario solicitarla en cs@anjanadata.com.

• anjana.security.unattended_upgrades: permite habilitar las actualizaciones automáticas de seguridad provistas por el sistema operativo. ✅RECOMENDADO: dejar esta opción habilitada.

• anjana.security.certificates.provider: permite elegir el origen del certificado para la instancia de Anjana. ✅RECOMENDADO: dejar el valor por defecto.

• anjana.security.certificates.truststorepath: permite elegir el truststore que se usará en Anjana. ✅RECOMENDADO: dejar el valor por defecto.

• anjana.security.certificates.truststorepass: permite indicar la contraseña usada para el truststore, por defecto “changeit” cuando se usa el del sistema.

• installation.mode: permite elegir el modo de despliegue para la instancia de Anjana. Se explica a continuación:

  • installation.mode: manager permite desplegar Anjana usando un nodo controlador. El nodo manager descargará todos los artefactos y luego los redirigirá a los nodos correspondientes. Este modo permite que solo el nodo manager tenga acceso a los repositorios.
    ✅RECOMENDADO: para entornos distribuidos o balanceados. Dejar este valor por defecto si no se necesita personalización adicional.

  • installation.mode: direct permite que las descargas y despliegues se realicen directamente en los nodos de destino (front, back, persistencias, etc…). En este modo todos los nodos del entorno requerirán conexión con los repositorios.
    🛈NOTA: óptimo para entornos singlenode.

  • installation.mode: local permite que el despliegue de Anjana se produzca sin necesidad de conexión contra el repositorio.
    ⚠️IMPORTANTE:tener en cuenta lo siguiente:

    • El despliegue se realizará desde el nodo de ansible (manager).

    • Es necesaria conectividad básica a la paquetería del sistema operativo.

    • Será necesario haber descargado todos los artefactos requeridos para el despliegue de Anjana previamente usando el tag download, y que se ubiquen en el directorio temporal de Anjana /tmp/anjana del nodo manager.

• installation.tmpdir: permite definir el directorio temporal de artefactos de Anjana.
  ⚠️IMPORTANTE:todo el contenido de esta carpeta será borrado durante el reinicio del sistema o al final de cada ejecución del kit.

• installation.eurekaPreferIpAddress: permite alterar la preferencia del registro de las aplicaciones en SpringBoot. ✅RECOMENDADO: dejar el valor por defecto.

• installation.failFast: permite que las aplicaciones fallen en caso de no alcanzar el microservicio de configuración. ✅RECOMENDADO: dejar el valor por defecto. En caso de un entorno balanceado será necesario establecerlo a false.

• installation.reportPath: permite definir el directorio y fichero de registro de ejecuciones del kit de ansible.

• installation.javaPATH: permite definir el directorio por defecto donde se ubica la instalación de JAVA. 🛈NOTA: será necesario editar el valor por defecto en caso de que se haya instalado JAVA en una ubicación personalizada.

• installation.type: permite definir el modo de instalación de Anjana. ✅RECOMENDADO: dejar el valor por defecto.

• installation.env: permite definir el tipo de entorno para ajustar los perfiles de RAM de acuerdo a la instancia desplegada. ✅RECOMENDADO: dejar el valor por defecto.

• installation.debug: cuando está a true permite obtener traza adicional de los logs de ejecución del kit así como acceder a los puertos de debug.
  ⚠️IMPORTANTE:cuando este valor está a true todos los puertos de debug son expuestos tras el despliegue de los descriptores de servicio. Así mismo, todas las contraseñas y cadenas de conexión se verán expuestas y registradas en los logs de ejecución del kit. Solo recomendado para tareas de mantenimiento o debug.

• installation.owner: permite configurar los detalles del usuario al cual se le otorgará la propiedad de la instalación de Anjana. ✅RECOMENDADO: dejar el valor por defecto.

Usuario de conexión entre nodos

Todas las propiedades definidas bajo ansibleuser permiten la configuración de un usuario de acceso a todos los nodos para la correcta comunicación entre instancias de un entorno distribuido o balanceado.

Para su despliegue se usa el tag ansible-user.

🛈NOTA: para el despliegue de este usuario es necesario indicar primero en el hosts.yml un usuario con permisos de administrador suficientes para la edición de ficheros y directorios como root.

Importación de roles y configuración

Este apartado permite la edición de los y configuración a importar durante el despliegue de Anjana o las ejecuciones del kit.

• import_role.persistences: permite configurar qué persistencias serán importadas durante la ejecución de ansible.
  🛈NOTA: será necesario ajustar esta sección de acuerdo a las persistencias que se estén utilizando. Ejemplo de uso: para un entorno utilizando AWS S3, debería configurarse MinIO a false.

• import_role.core: permite configurar qué roles del core y su configuración serán importados.
  ✅RECOMENDADO: dejar el valor por defecto.

• import_role.plugins: permite configurar qué roles de plugins y su configuración serán importados. Se ajustará según la necesidad.

• import_role.extras: permite definir qué software de terceros importar durante el despliegue y ejecución. Se ajustará según la necesidad.

• import_role.utilities: permite definir qué utilidades de Anjana incluidas en este kit serán importadas.
  ❌NO RECOMENDADO: modificar estos valores, podría causar inestabilidad en las funciones y uso del kit.

Exportación de log

• log.since: permite definir qué rango de log se exportará durante la ejecución del tag export-log y su posterior subida al bucket anjanalogs con el tag export-log-s3.

• log.pattern: permite alterar la forma en la que registran los logs. Útil para poder identificar strings más fácilmente en software de monitorización.

Plataforma de métricas de gobierno

extras.grafana.user y extras.grafana.pass: permiten establecer el usuario de acceso a la interfaz de Grafana alojada en el :3000. Por defecto, esta utilidad no se encuentra habilitada para su importación, pudiendo ser habilitada y posteriormente desplegada con el tag grafana.

Plataformado de instancias

Alias de ansible anjana

Para un manejo más sencillo del kit y toda su funcionalidad se configura por defecto un alias que transforma todo el comando de ansible en un sencillo anjana seguido de los parámetros adicionales que quiera ser añadidos.

Para restablecer o configurar el alias, será necesario lanzar estos comandos:

Para Ubuntu:

touch ~/.bash_aliases

echo "alias anjana='sudo ansible-playbook -i /opt/ansible/ansible-inventories/<inventario>/hosts.yml /opt/ansible/anjana.yml'" >> ~/.bash_aliases

Para RedHat:

touch /etc/profile.d/anjana.sh

echo "alias anjana='sudo ansible-playbook -i /opt/ansible/ansible-inventories/<inventario>/hosts.yml /opt/ansible/anjana.yml'" >> /etc/profile.d/anjana.sh

🛈NOTA: Hay que tener en cuenta que la ruta hacia el kit de ansible o el propio inventario variarán según el entorno, será necesario ajustar según la necesidad.

Plataformado adicional

Durante el despliegue de un entorno de Anjana se plataforma la instancia en la cual se está ejecutando ansible, para preparar todos los requisitos e instalar todas las dependencias necesarias.

Se abarca, en la sección Plataformado de entorno del Despliegue de Anjana, cómo plataformar las instancias adicionales para un entorno distribuido.

Para reacondicionar o plataformar nuevas instancias añadidas tras el despliegue de Anjana, por una posible migración del frontal o servidor de persistencias, sería necesario ajustar el fichero hosts.yml del inventario en uso para reflejar los últimos cambios en infraestructura.

Tras ello ya sería posible ejecutar el tag para el plataformado como visto anteriormente:

anjana -t platform

Gestión de aliases en /etc/hosts

Continuando con los cambios de 23.1, los aliases de Anjana del fichero /etc/hosts son gestionados por el kit de ansible de forma completamente autónoma como puede verse en la captura a continuación:

🛈NOTA: El dominio anjanadata.local es solo un ejemplo, siendo éste sustituido por el dominio contemplado en el certificado provisto para el despliegue de Anjana.

En caso de haberse añadido alguna instancia, como lo sucedido en el apartado anterior, o de haberse modificado la infraestructura para el entorno de Anjana tras el despliegue del producto, será necesario indicar las nuevas IPs de las máquinas en el fichero hosts.yml del inventario que se esté usando.

Una vez actualizado el fichero para reflejar los últimos cambios, se podrán actualizar los aliases de todas las máquinas de forma automática mediante el tag:

anjana -t aliases

⚠️IMPORTANTE: El estado desactualizado de estos aliases o su modificación manual puede dar lugar a un mal funcionamiento del producto y el kit.

Usuario de conexión personalizado

Es posible la creación de un usuario de acuerdo a lo comentado en la sección Usuario de conexión entre nodos, el cual permitirá la comunicación entre nodos(instancias) de un entorno Anjana, concretamente el nodo manager con el resto del entorno.

Para poder crear este usuario de forma asistida por el kit, es necesario modificar la sección del all.yml, e indicar el nombre que adoptará el usuario, así como su grupo y key.

Una vez relleno será necesario comprobar que en el hosts.yml del inventario se cuenta con un usuario administrador con suficientes permisos para la edición de ficheros y carpetas de otros usuarios. Un ejemplo de ello es root, pero se recomienda otro usuario.

Una vez confirmado, se procede al despliegue del nuevo usuario mediante el tag:

anjana -t ansible-user

Una vez completada la operación, la key del usuario generado estará disponible en el directorio /home/<ansible-user>/.ssh/<key>.pem.

Será necesario reemplazar el usuario en hosts.yml con el nuevo generado.

Integraciones cloud

El kit ofrece compatibilidad y funcionalidades con ciertos proveedores cloud, que se detallan a continuación.

Buckets en AWS S3

Para poder usar buckets alojados en AWS S3 con el kit, es necesario ajustar el fichero all.yml, para apuntar a los buckets disponibles en una región de AWS. Algunas propiedades no estarán disponibles por defecto y será necesario añadirlas:

También será necesario deshabilitar MinIO, para evitar que se despliegue sin necesidad:

Una vez ajustados ambos, ya se podrá proceder a desplegar Anjana con normalidad.

PostgreSQL en RDS

A diferencia de AWS S3, el kit soporta directamente RDS dada la naturaleza de la cadena de conexión, siendo solo necesario modificar el host, y el puerto de conexión en caso de ser necesario, junto a las credenciales, tal como se muestra:

Al igual que con AWS S3, será necesario deshabilitar el role de PostgreSQL para evitar su despliegue no intencionado:

Una vez ajustados ambos, ya se podrá proceder a desplegar Anjana con normalidad.

Gestión de datos

Descarga de artefactos

Mediante el tag download es posible la descarga de todos los artefactos necesarios para la ejecución del despliegue en un entorno sin conexión con el repositorio de Anjana.

⚠️IMPORTANTE: La descarga de artefactos solo funciona con el installation.mode: manager. Los artefactos serán depositados en /tmp/anjana en el nodo manager(nodo que ejecuta ansible).

Operaciones de datos

El kit provee una serie de utilidades para el manejo de los datos del entorno de forma segura.

⚠️IMPORTANTE: tener en cuenta lo siguiente:

• Todas las operaciones de datos paran y luego arrancan el entorno para evitar corrupciones.

• Todas las operaciones salvo la exportación/importación realizan un backup automático previo de los datos existentes.

• Ninguna operación de inserción o importación de datos reemplaza los datos existentes. Será necesario borrar previamente todos los datos para que la operación funcione.

Las operaciones disponibles son las siguientes:

• Exportación/importación de datos, mediante los tags ya mencionados en el apartado Migración de datos.

• Borrado de datos: permite el borrado de todos los los datos de las persistencias del entorno, tanto de forma individual como generalizada (no la configuración) a través de los siguientes tags:

anjana -t delete

anjana -t delete-s3

anjana -t delete-bbdd

anjana -t delete-solr

Inserción de datos: permite la inserción tanto de forma generalizada como individual, del kit de datos seleccionado en el fichero all.yml en este apartado:

Se encuentran disponibles los siguientes tags:

anjana -t insert

anjana -t insert-s3

anjana -t insert-bbdd

Reset/restablecimiento de datos: permite el borrado y posterior inserción del kit de datos seleccionado de la misma manera que los dos puntos anteriores. Los tags disponibles son los siguientes:

anjana -t reset

anjana -t reset-s3

anjana -t reset-bbdd

Gestión de dumps y periodicidad

El kit permite la gestión de backups en un bucket externo y su posterior restauración, así como establecer la periodicidad de los respaldos.

Para ello, se han definido las siguientes funcionalidades:

• Segregación en el fichero all.yml del bucket anjanabackups, actual bucket destinado a los respaldos de persistencias y configuración de Anjana.

  La segregación cuenta con las mismas configuraciones que el apartado normal dedicado a S3, siendo posible destinar unas credenciales distintas a este propósito, así como ubicar el bucket anjanabackups en una tecnología distinta.
  Ejemplo de uso:buckets de Anjana ubicados en server MinIO local, bucket anjanabackups ubicado en AWS S3.

  

  
  

  ✅RECOMENDADO: habilitar la segregación para asegurar que los backups se encuentran en una ubicación diferente a un posible punto de fallo.

• Backups de datos + configuración: usando como destino el bucket anjanabackups. Este proceso realizará un backup de todos los datos de las persistencias al igual que la configuración de los microservicios, y será comprimido y subido al bucket anjanabackups con timestamp.
  Es posible habilitar y definir una retención para esta operación en el fichero persistencesutilityhosts.yml del inventario en uso:

  

  
  

  Para lanzar el backup de este modo, se usa el tag:

anjana -t backup-dump



Restore de datos: usando como fuente de datos el bucket anjanabackups.
Durante el backup se respaldan todas las persistencias + configuración, pero para la restauración es posible definir desde el fichero persistencesutilityhosts.yml del inventario en uso, qué persistencias + configuración van a restaurarse, como se puede ver a continuación:

Este proceso analizará los respaldos disponibles en el bucket anjanabackups y dará un listado de los últimos disponibles para seleccionar de entre ellos cuál respaldar. En caso de no existir ningún respaldo se mostrará un mensaje y detendrá el proceso.

Para realizar la restauración se lanza el tag:

anjana -t restore-dump



Cron para respaldo: es posible desplegar un cron para las tareas de backup-dump, definiendo su frecuencia mediante unas propiedades configurables en el fichero persistencesutilityhosts.yml del inventario en uso:

Para desplegar el cron o actualizarlo, se lanza el tag:

anjana -t dump-cron

🛈NOTA: En caso de que se deshabilite, el cron será borrado en la siguiente ejecución del tag.

Gestión de la seguridad en Anjana

Gestión y renovación de certificado

⚠️IMPORTANTE:

• Desde 25.1 un certificado es requerido, tanto para el acceso como para la comunicación segura entre microservicios, y necesitan ser depositados en el directorio /opt/common/anjana-certs/ de todas las instancias que conformen el entorno de Anjana.

• El certificado NO será provisto por Anjana en la modalidad IaaS/PaaS, ya que se requiere la creación del certificado wildcard que contemplen el dominio y subdominios de acceso al entorno y será gestionado por el mantenedor de la infraestructura.

Para un despliegue nuevo, el certificado debe de estar ya presente en el directorio mencionado antes del inicio del despliegue, para que el producto y el kit funcionen correctamente. Explicado en el apartado Despliegue de Anjana.

En caso de renovación, para que el nuevo certificado sea correctamente comunicado entre todos los microservicios y las persistencias, será necesario ubicarlos nuevamente en el directorio mencionado, y lanzar el siguiente tag:

anjana -t certificates-deploy

Para asegurar el correcto funcionamiento de la aplicación tras la actualización del certificado, será necesario reiniciar con:

anjana -t restart

Actualizaciones de seguridad

Permite habilitar o deshabilitar las actualizaciones automáticas de paquetes de seguridad y backports en todos los nodos del entorno. El ajuste puede ser realizado en el all.yml en esta sección:

Por defecto está activadas pero pueden ser modificadas. Aplican a todos los sistemas soportados por el kit. En caso de realizarse alguna modificación, será necesario lanzar el siguiente tag para aplicar los cambios:

anjana -t platform



Seguridad en Apache2

Es posible administrar la configuración de seguridad de Apache2 y los frontales de Anjana, para ello, están disponibles los siguientes ajustes en el fichero anjanauihosts.yml del inventario en uso:

• anjana_ui.security.IP_redirect: permite redirigir todos los acceso del frontal mediante IP al dominio configurado.

• anjana_ui.security.apache_whitelist: permite habilitar y definir mediante la propiedad whitelist, una lista compuesta por Usuario e IP, la cual se usará como excepción en todas las medidas de seguridad comentadas anteriormente.

• anjana_ui.security.persistences_whitelist: permite habilitar mediante la propiedad enabled y definir mediante la propiedad whitelist, una lista compuesta por Usuario e IP como el punto anterior, la cual se usará como excepción en los proxies de persistencias (/minio, /solr).

🛈NOTA: Todas las medidas de seguridad a excepción de la whitelist de apache2 para frontales de Anjana (no persistencias) vienen habilitadas por defecto para mejorar la seguridad base del entorno.

Utilidades

Comprobadores de conexión

En el kit se incluyen dos comprobadores de conexión, los cuales se detallan a continuación:

Conexión a repositorios de artefactos: es posible verificar la conexión contra el servidor de artefactos de Anjana mediante el siguiente tag:

anjana -t check-repository

Conexión a las persistencias: el siguiente tag proporciona un check de la conexión contra las persistencias elegidas, ya sean Cloud u hospedadas en el propio entorno:

anjana -t check-connection



✅RECOMENDADO: usar ambos tags para troubleshooting o testar la conexión después de cambios de credenciales, entre otros escenarios.

Swap

Se ha incorporado en el kit un tag que permite añadir un fichero swap para extender la memoria disponible 4GB, no siendo disponible modificar mediante el kit dicho tamaño por el momento.

Para desplegar el fichero swap, será necesario lanzar el siguiente tag:

anjana -t swap



Formato del Log de Anjana

Es posible modificar el formato de log de los microservicios de Anjana y Apache2 al formato key:value para que sea más fácil de manejar por la plataforma de monitorización existente.

Para poder modificarlo es necesario ajustar en el all.yml, el pattern de log de la opción default a monitoring.

Una vez modificado, es necesario actualizar las configuraciones de todos los microservicios y Apache2, así como reiniciar el entorno de Anjana, usando los siguientes tags:

anjana -t update-config

anjana -t update-vhosts

anjana -t restart

Los Logs pasan de este formato:

A este:

Rotado de Log de Anjana

De forma adicional a lo comentado en el apartado anterior, es posible establecer un rotado de logs para evitar llenar el espacio en disco. Este rotado establece un máximo de ficheros de log a un total de 2, y cada fichero con un contenido máximo igual a 2GB.

🛈NOTA: Este rotado viene aplicado por defecto a partir del kit 25.a1, no siendo posible desactivarlo mediante el propio kit.

Para configurar el rotado en máquinas que no dispongan de él, será necesario lanzar el tag:

anjana -t log-rotate

Balanceador para MinIO

Se ha facilitado en el fichero anjanauihosts.yml del inventario en uso, un balanceador para entornos con varios nodos de MinIO. Viene habilitado por defecto, para usarlo, es necesario lo siguiente:

• anjana_ui.port.minioProxyPass: para editar el puerto en caso de ser necesario.
  🛈NOTA: habrá que tenerlo en cuenta para la configuración de los microservicios que usen el servicio de MinIO.

  

• anjana_ui.balancer.minio_nodes: para indicar los nodos de MinIO que se van a balancear. Por defecto ya viene el primero, el cual no hace falta modificar, ya que viene dado por la configuración en all.yml. El resto deberán ser ajustados según necesidad.

  

Extras

Métricas de Gobierno

Adicionalmente, se ha incluido en el kit el software Grafana, el cual permite desplegar paneles para la visualización de las métricas relacionadas con el gobierno de los datos en Anjana.

El software viene acompañado de un dashboard de ejemplo.

Para desplegar Grafana, será necesario habilitarlo en el all.yml, sección import_role:

Y posteriormente, lanzar el tag:

anjana -t grafana

En caso de querer modificar el dashboard por defecto o querer añadir más, será necesario acceder a los templates del inventario y crear los nuevos dashboards en la ruta /opt/ansible/ansible-inventories/<inventario>/templates/grafana/dashboards/.

🛈NOTA: la ruta puede no coincidir y dependerá de la ubicación del inventario.

Para actualizar los dashboards una vez depositados en la ruta correcta, se lanza el tag:

anjana -t update-dashboards

