Cluster ONTAP - Usando RAID TEC

Hola de nuevo, en este post voy a repasar una funcionalidad disponible en ONTAP desde la versión 9.0 y que, en función de la criticidad de nuestros datos o del tamaño de los discos que estemos usando, puede ser interesante tener en cuenta. Me estoy refiriendo al RAID Triple Erasure Coding o RAID-TEC para abreviar.

Primero vamos al rollo teórico y resumamos un poco que es RAID-TEC y como funciona, aunque para ello será buena idea que revisemos primero como funcionan los modos RAID4 y RAID-DP que hemos estado utilizando hasta ahora.

Como ya sabemos, a grandes rasgos, RAID4 soporta el fallo de un disco de un raid group y RAID-DP el fallo de dos discos de un raid group. Siempre que nuestro sistem tenga suficientes discos spare, ONTAP será capaz de sustituir el disco fallido y reconstruir la información del mismo a partir de la información de paridad correspondiente. En general y solo desde mi punto de vista, no es recomendable construir agregados usando RAID4, salvo que los datos que contenga no sean datos de producción y dispongamos de suficientes discos spare.

Pero, ¿como funcionan realmente RAID4 y RAID-DP? Como habremos comprobado muchas veces, cuando consultamos la distribución de discos de un agregado, vemos algo como lo siguiente:

Distribución de discos de un agregado.

En la imagen anterior tenemos la salida del comando aggr show que nos muestra los raid groups que forman un agregado y, como podemos ver, hay dos discos marcados como discos de paridad ya que el raid group en cuestión es de tipo RAID-DP. Cada disco de paridad almacena un tipo de paridad diferente, más concretamente, el tipo de paridad por disco es el siguiente:

• Disco de paridad o de paridad de banda. Este disco almacenaría el cálculo de paridad de banda, mediante el uso de una operación XOR, de cada una de las escrituras distribuidas en cada uno de los discos de datos del raid group. Esto podemos verlo de manera muy simple como:

Cálculo de paridad de fila.

• Disco de paridad diagonal. Este disco almacenaría el cálculo de paridad diagonal de cada una de las bandas diagonales distribuidas en cada uno de los discos de datos del raid group. De nuevo, de manera muy simplificada, podemos verlo del siguiente modo:  

Cálculo de paridad diagonal.

Teniendo esto en cuenta, podemos ver un raid group completo, con sus discos de paridad y de paridad diagonal, del siguiente modo:

Paridad de banda y diagonal de un raid group.

Llegados a este punto, está claro que en el caso de usar RAID-TEC, tendremos un nuevo disco que contendrá un nuevo cálculo de paridad y ¿que nos queda para poder hacer ese cálculo? Pues en este caso la solución de NetApp es añadir un cálculo de paridad anti-diagonal que se almacenará en nuestro tercer disco de paridad. Esta paridad anti-diagonal podemos verla de forma muy simplificada del siguiente modo:

Paridad anti-diagonal.

Como vemos, para el cálculo de la paridad anti-diagonal solo se utilizan los discos de datos y el disco de paridad de banda.

Para el cálculo de paridad es muy importante tener en cuenta como trabaja ONTAP y su relación con la NVRAM. En una entrada posterior revisaremos todo esto un poco más en detalle.

Como es lógico, RAID-TEC está pensado para aquellos agregados en los que usemos discos de gran capacidad, pensando en evitar que el fallo de un disco, mientras se está realizando la reconstrucción de un raid group, provoque la pérdida irreversible de datos. La recomendación de NetApp es usarlo para agregados con discos de capacidades superiores a los 4 TB.

Para cada tipo de RAID, el número mínimo de discos es el siguiente:

• RAID4, son necesarios al menos 3 discos, dos discos de datos y uno de paridad de banda para agregados con un solo raid group. Si se trata del agregado root, el raido group puede ser de dos discos únicamente.
• RAID-DP, el mínimo número de discos necesarios para un agregado con un solo raid group es 5, tres discos de datos, uno de paridad de banda y otro de paridad diagonal. Sin embargo, si se trata del agregado root, el raid group puede estar formado por 3 discos solamente.
• RAID-TEC, para este caso el mínimo número de discos es 7, 4 discos de datos y 3 para cada uno de los tipos de paridad.

Una forma sencilla de comprobar el número de discos requeridos para cada tipo de raid, es lanzar el comando de creación de un agregado con un solo disco ya que, la salida del comando nos indicará el mínimo número de discos requeridos:

Discos requeridos por tipo de RAID.

Vamos a ver como crear un nuevo agregado de tipo RAID-TEC con dos raid groups, para esto solo necesitamos ejecutar un comando como el siguiente:

  

Creación de un agregado con protección RAID-TEC.

Como podemos ver en la salida del comando, vamos a crear un agregado que estará formado por 14 discos en total, con dos raid groups de 7 discos cada uno (opción maxraidsize) con protección RAID-TEC en cada raid group. Esto se refleja en la distribución de cada raid group con los discos de paridad parity, dparity y tparity, siendo el resto discos de datos.

Una de las ventajas de ONTAP es la capacidad que nos proporciona de cambiar el tipo de RAID utilizado en un agregado con solo usar un comando. Veamos un ejemplo en el cual, creamos un agregado con una protección RAID4 y lo cambiamos a RAID-DP y finalmente a RAID-TEC:

Creación de un agregado de tipo RAID4.

Conversión del agregado a tipo RAID-DP.

Conversión del agregado a tipo RAID-TEC.

Como podemos ver, el sistema ha ido añadiendo discos de paridad al agregado en cada uno de los casos y reconstruyendo su contenido según lo hemos convertido. Para hacer esto es necesario que tengamos en cuenta los siguientes puntos:

• Es necesario que dispongamos de suficientes discos de spare en el sistema. En este ejemplo cada raid group ya tiene el mínimo número de discos requerido para cada tipo de raid, con lo que solo es necesario añadir un disco de paridad a cada raid group en cada paso. 
• En caso de que el número de discos en los raid groups ya existentes sea inferior al número de discos requeridos, será necesario incremental el número de discos requeridos en cada raid group hasta el número necesario antes de poder hacer la conversión de tipo de RAID.
• El sistema reconstruye el disco de paridad correspondiente a partir de los datos existentes en el agregado. Si tenemos que convertir un agregado con una gran cantidad de datos, es muy probable que el proceso de reconstrucción sea bastante largo.

Hasta aquí un repaso de RAID-TEC y como usarlo en nuestros sistemas ONTAP. En breve una entrada sobre como proteger nuestros agregados localmente usando SyncMirror.

Usando plugins en Docker - NetApp Trident

Hoy vamos a estudiar cómo podemos extender las funcionalidades de Docker mediante el uso de plugins.

Docker y por tanto Docker Swarm, al igual que orquestadores como Kubernetes o Rancher, permite el uso de plugins o módulos adicionales que nos permitirán la integración de nuestra infraestructura de contenedores con otros servicios o añadirán funcionalidades adicionales. Estos plugins, disponibles en Docker Hub, nos permiten integrar nuestros dockerhosts con sistemas de almacenamiento, añadir funcionalidades de logging o extender las capacidades de red.

Para estudiar el funcionamiento del sistema de plugins de Docker, voy a centrarme en el plugin Trident desarrollado por NetApp, que nos permite administrar y montar volúenes alojados y servidos por sistemas NetApp en nuestros dockerhosts.

Plugin Trident de NetApp disponible en Docker Hub.

En la página del plugin en Docker Hub tenemos disponible la descripción del plugin así como las instrucciones de instalación del mismo, pero es recomendable seguir las instrucciones de configuración oficiales dadas en el siguiente enlace.

En resumen, para usar este plugin debemos realizar los siguientes pasos:

1. Debemos crear el fichero de configuración en todos los dockerhosts que vayamos a integrar con nuestros sistemas NetApp.
2. Crearemos una o más SVMs que proporcionarán los servicios de bloque o fichero necesarios. Es muy importante que dichas SVMs tengan asignado uno o más agregados para la creación de volúmenes.
3. Creamos un rol y un usuario específico para el uso del plugin en cada una de las SVMs que vayan a proporcionar servicio a nuestros dockerhosts.
4. Por último instalamos el plugin en todos nuestros dockerhosts.

Empecemos por el fichero de configuración, como indica la documentación este fichero debe estar en la ruta /etc/netappdvp y es un fichero JSON cuyo nombre por defecto será config.json. Una configuración simple del fichero, para un entorno NAS, podría ser:

Fichero de configuración de Trident.

En esta configuración estoy especificando:

• Los parámetros managementLIF y dataLIF contienen el nombre DNS o dirección IP de las LIF de gestión y datos de la SVM para esta instanacia de configuración.
• El parámetro svm indica el nombre de la SVM que estamos usando, siendo username y password las credenciales del usuario que usaremos para interactuar con dicha SVM.
• La sección default establece una serie de valores por defecto para la creación de nuestros volúmenes desde los dockerhosts. En este ejemplo establecemos la política de snapshots así como la política de exportación de volúmenes, el tamaño de los volúmenes creados, el tipo de seguridad y la reserva de espacio para snapshots.

En caso de cambiar la configuración de Trident, será necesario reiniciar el plugin con los comandos docker plugin disable y docker plugin enable.

 

Creamos una SVM con el mismo nombre que el que indicamos en el fichero de configuración, así como el rol con los permisos adecuados que luego asignaremos al usuario que tabién vamos a crear. Los permisos necesarios para el rol son los siguientes:

Creación del rol necesario para el plugin.

Creamos el usuario y le asignamos el rol que acabamos de crear, es importante que establezcamos como tipo de aplicación a usar por el usuario ontapi:

Creación del usuario y asignación del rol.

Ahora ya podemos instalar el plugin en todos nuestros dockerhosts, siendo la salida de la instalación como la siguiente:

Instalación del plugin Trident en los dockerhosts.

El plugin ya instalado y disponible.

Una vez instalado el plugin, al estar habilitado, el demonio docker se encargará de arrancarlo cada vez que iniciemos el sistema. Podemos comprobarlo viendo los procesos de cada uno de nuestros dockerhosts:

Procesos del plugin Trident.

En caso de ser necesario, podemos parar el plugin usando el comando docker plugin del siguiente modo:

Parando el plugin Trident en un dockerhost.

Como ya he comentado la SVM debe tener agregados asignados a ella para permitir la creación de volúmenes desde el plugin. En caso de no ser así recibiríamos un error como el siguiente:

Error cuando la SVM no tiene agregados asignados.

Desde OnCommand System Manager podemos asignar de forma muy rápida y simple los agregados a la SVM con solo editarla desde el apartado SVMs:

Asignamos un agregado a nuestra SVM para el usuao de Trident.

Lo primero que podemos hacer es crear los volúmenes que vayamos a necesitar usando el comando docker volume. Como es lógico esto solo lo haremos desde uno de nuestros dockerhosts, así que como ejemplo creamos varios volúmenes desde diferentes dockerhosts:

Creamos varios volúmenes usando el plugin Trident.

Comprobamos que los nuevos volúmenes existen en el agregado.

Es muy importante que nos demos cuenta que al delegar un agregado a la SVM como hemos hecho, el usuario que utilicemos tiene control total sobre los volúmenes que existan en dicho agregado. Por tanto, si el agregado está compartido con más clientes, es posible borrar el resto de volúmenes con los comandos de gestión de volúmenes de Docker a través de Trident, siempre y cuando todos los volúmenes de dicho agregado contengan el mismo prefijo que hemos establecido en la configuación del plugin. Por ejemplo, si listamos los volúmenes disponibles vemos que aparece uno que no hemos creado con Trident:

Listado de volúmenes disponibles.

Para evitar problemas, si es necesario que diferentes cliente compartan el mismo agregado, lo mejor es que los volúmenes controlados por Trident utilicen un prefijo distinto al del resto de volúmenes del agregado.

 

Una vez creados los volúmenes, podemos pasar a usarlos montándolos cuando despleguemos un contenedor o un servicio en nuestro swarm:

Creación de un servicio replicado con un volumen.

El comando anterior utiliza la sintaxis mount para el montaje de volúmenes, esta sintaxis está disponible desde la versión 17.06 de Docker para contenedores standalone y no solo para swarm. En próximas entradas explicaré más detalladamente como utilizarla y sus diversas opciones, por ahora quedémonos en que vamos a montar un volumen controlado por el plugin Trident.

 

Al ejecutar el comando anterior, swarm orquesta el montaje del volúmen especificado en los hosts en los que se despliegue un contenedor que lo necesite, con lo que, de forma automática montará por NFS el volumen swarm_HTML que hemos creado anteriormente y que está sirviendo nuestra SVM. Esto lo podemos comprobar del siguiente modo:

Escalamos el servicio a 3 réplicas.

Ahora el contenedor solo está corriendo en tres de los dockerhosts que forman el swarm, con lo que el volumen necesario solo está montado en dichos hosts como podemos ver:

Docker Swarm ha montado el volumen en los hoosts necesarios.

Si ahora escalamos de nuevo el servicio, comprobaremos que se montará el volumen en el nodo swarm-nodo2 para poder levantar correctamente el contenedor con el volumen requerido:

Docker Swarm monta el volumen en el nodo restante.

Como es lógico, al borrar el servicio, el volumen se desmontará de todos los nodos si ningún otro servicio lo está utilizando.

Por tanto, y en resumen, hemos visto como Docker Swarm es capaz de orquestar perfectamente el montaje de volúmenes externos, en este caso controlados por el plugin Trident de NetApp y como este plugin nos permite integrar nuestra infraestructura de contenedores basada en Docker con los sistemas de almacenamiento NetApp. Además hemos podido comprobar como expandir las funcionalidades de Docker mediante el uso de plugins.

Como es lógico este plugin también está disponible para Kubernetes, el cual espero poder estudiar dentro de un tiempo y repasar su funcionamiento.

En próximas entradas, repasaré las opciones disponibles para la gestión y uso de volúmenes en servicios implementados en Docker Swarm con la opción mount.

Como añadir discos en ONTAP simulator

Si como yo estás preparándote la certificación de cluster ONTAP, estarás más que acostumbrado a usar el simulador de NetApp para poder realizar pruebas. En ese caso puede suceder que necesites añadir más discos para realizar pruebas con diferentes funcionalidades, para lo cual hoy vamos a ver como podemos añadir discos de forma sencilla a cada controladora.

Es importante, antes de continuar, tener en cuenta ciertos puntos sobre el simulador de ONTAP:

• Al tratarse de máquinas virtuales, no hay una conexión física entre las controladoras ni entre las controladoras y los discos de su partner, con lo que no se pueden realizar pruebas de storage failover.
• No podemos comprobar el estado de conexión de las bandejas mi configurar ACP.
• Cada nodo puede tener un máximo de 4 bandejas simuladas, con 14 discos por bandeja para un total de 56 discos por nodo virtual.

Para poder incrementar el número de discos en un nodo virtual, solo tenemos que seguir estos pasos:

1. Es necesario desbloquear la cuenta de usuario diag. Este usuario es necesario para poder acceder a la systemshell. La systemshell es la shell del nodo, ya sea físico o virtual, en la cual estamos accediendo al FreeBSD sobre el que corre ONTAP y, por tanto, al sistema operativo que corre en nuestras controladoras.
2. Pasamos al usuario diag y nos conectamos a la systemshell de cada nodo.
3. Hay un script en cada nodo llamado vsim_makedisks que nos permitirá añadir los discos que necesitemos, de ciertos tipos ya predefinidos, a dicho nodo. Si lo ejecutamos con la opción -h nos mostrará una lista de los tipos de discos disponibles.
4. Cambiamos al directorio /sim/dev y lanzamos el script usando sudo indicando el número de discos (-n), el tipo de los mismos (-t) y el puerto o controladora virutal donde vamos a "conectar" estos nuevos discos.
5. Por último es necesario rebotar el nodo para que los nuevos discos aparazcan como unassigned y podamos asignarlos al nodo.

El proceso descrito en los pasos anteriores, podemos verlo en las siguientes imágenes:

Desbloqueamos el usuario diag.

Entramos en la systemshell de cada nodo.

Salida de ayuda del script vsim_makedisks.

Ficheros para cada disco en /sim/dev/,disks en cada nodo.

Añadimos 14 discos del tipo 31 al adapatador 0.

Asignamos los nuevos discos al nodo.

El proceso anterior podemos hacer en ambos nodos o solamente en uno y, una vez terminado ya tendremos nuestros nuevos discos listos para realizar todas las pruebas que necesitemos.

Administración de Docker swarm con Rancher

Hoy continuamos explorando Docker swarm pero, para variar un poco, vamos a instalar Rancher para crear y administrar un swarm de dockerhosts así como para explorar las funcionalidades que puede aportar a nuestros despliegues de Docker swarm.

¿Que es Rancher? es una plataforma de gestión de contenedores que nos permite su despliegue y control en cualquier entorno, desde nuestros propios servidores, ya sean físicos o virtuales o en entornos cloud. Además proporciona una gran cantidad de funcionalidades adicionales que pueden ser desplegadas desde diferentes catálogos, lo que permite añadir nuevas herramientas a nuestros despliegues de forma rápida y sencilla.

De forma muy resumida, la unidad de trabajo básica de Rancher es el entorno, cada uno de los cuales puede utilizar un tipo de orquestación y que contendrá los hosts asociados a dicho entorno. Como siempre, para una información más detallada y mucho mejor que esta, os recomiendo visitar la página oficial de Rancher.

Después de un poco de rollo teórico vamos a instalar Rancher, para lo cual he seguido las instrucciones de instalación dadas en esta página para un entorno multinodo, en el cual he desplegado cuatro máquinas virtuales, siendo una de ellas el servidor de base de datos y las otras tres los nodos donde he instalado Docker.

Para comenzar la instalación, solo necesitamos lanzar el siguiente comando en al menos uno de los hosts:

Instalación del nodo servidor de Rancher.

Como es lógico este comando descargará la imagen de correspondiente de Docker Hub y creará un contenedor para nuestro servidor Rancher, el cual conectará con el servidor de base de datos indicado en los parámetros del comando docker run. Tras ejecutar el comando anterior podemos comprobar que hay un contenedor en nuestro host que se corresponde con el servidor Rancher:

Host con el contenedor del servidor Rancher.

A continuación ya podremos acceder a la consola de administración de Rancher, con lo que solo necesitamos lanzar un navegador y acceder al puerto 8080 del host donde hemos lanzado el contenedor del servidor Rancher. Al acceder por primera vez a la consola nos encontraremos con una imagen como la siguiente:

Conosla de administración de Rancher.

En este punto, lo primero es configurar el control de acceso a la consola y configurar el método de autenticación que vayamos a utilizar. En nuestro ejemplo, usaremos autenticación local por sencillez. Para configurar el control de acceso solo tenemos que acceder a la sección Access Control dentro del menú ADMIN y crear la cuenta de usuario con derechos de administración que vayamos a utilizar:

Configuración del control de acceso a la consola de Rancher.

A continuación debemos crear un nuevo entorno usando la plantilla disponible para Docker swarm. Para crearlo solo es necesario pinchar sobre el botón Add Environment desde la sección Manage Environments del menú Default, que nos indica cual es el entorno que estamos gestionando:

Ventana para la gestión de entornos en Rancher.

Creación de un entorno Docker Swarm

Tras crearlo, ahora veremos nuestros dos entornos disponibles en la ventana de gestión de entornos y que el entorno por defecto es el entorno llamado Default:

Entornos disponibles tras la creación del entorno para Swarm.

Ambos entornos se encuentran en estado Unhealthy ya que no hemos añadido hosts a ninguno de ellos. Por tanto, el siguiente paso consiste en añadir hosts a la infraestructura de nuestro nuevo entorno, para ello solo tenemos que cambiar al entorno Swarm test lab y acceder a la sección Hosts del menú INFRASTRUCTURE para añadir nuestros dockerhosts. El proceso, muy resumido, podemos verlo en las siguientes imágenes:

Definición de la infraestructura para establecer nuestro Swarm. Rancher indica que debemos añadir hosts.

Añadimos un dockerhost a la infraestructura de nuestro entorno Docker Swarm.

En la pantalla para añadir un nuevo host a la infraestructura, es recomendable incluir la dirección IP del host para asegurar que no haya problemas de comunicación, sobre todo al registrar el dockerhost que contiene el propio servidor de Rancher.

Es muy importante recordar que estamos creando un swarm con varios dockerhosts, con lo que es necesario que creemos las reglas necesarias en los firewalls de cada nodo para asegurar el correcto funcionamiento del swarm. Relacionado con esta correcta configuración del cortafuegos de los dockerhosts, un punto importante a tener en cuenta para registrar correctamente el dockerhost donde se está ejecutando el contenedor con el servidor Rancher, es que debemos añadir el interfaz docker0 a la zona trusted del firewall o bien definir las reglas correspondientes para permitir las conexiones a la dirección IP física del host teniendo en cuenta el interfaz docker0 y las conexiones salientes desde el contenedor agente.

Una vez que hayamos realizado los pasos anteriores para todos nuestros nodos virtuales, incluyendo el dockerhost en el que se encuentra el propio servidor de Rancher, la infraestructura de nuestro entorno será similar a la siguiente:

Infraestructura de nuestro entorno Docker swarm con tres dockerhosts.

Revisando la imagen anterior, ¿que es lo que ha hecho Rancher? Pues como vemos ha creado un swarm en el que todos los hosts tiene el rol de manager y ha desplegado en ellos una serie de contenedores que implementan los servicios de infraestructura necesarios. Desde el menú SWARM podremos comprobar que el estado de toda la infraestructura del entorno es correcta:

Infraestructura del entorno swarm.

Servicios de infraestructura desplegado por Rancher en el swarm.

Como veremos en entradas futuras sobre Rancher, cada uno de estos servicios de infraestructura desempeñan una función determinada para el correcto funcionamiento de nuestro entorno y Rancher los implementa mediante un contenedor dedicado en cada dockehost.

En este punto tenemos un swarm el cual está controlado por Rancher, con lo que el siguiente paso es desplegar un servicio simple. Para esto, basta con acceder a la sección Containers del menú INFRASTRUCTURE y pinchar sobre Add Container:

Apartado contenedores del entorno docker swarm.

Al crear un contenedor a partir de una imagen, nos encontramos con todas las opciones disponibles en línea de comandos cuando estamos administrando Docker. Así, para nuestro ejemplo tenemos lo siguiente:

Definición de parámetros de configuración de un contenedor.

Como vemos, en las diferentes pestañas tenemos las opciones de configuración disponibles para nuestro contenedor. Estableciendo una configuración básica para nuestro ejemplo y pinchando sobre el botón Create se seguirá el proceso de descargar la imagen de Docker Hub y crear el contenedor con la configuración que hemos especificado. Una vez creado Rancher nos mostrará las estadísticas de rendimiento del contenedor así como sus parámetros de configuración:

Estadísticas de uso de nuestro contenedor.

Este contenedor no lo hemos definido como un servicio y por tanto, solo será accesible desde el nodo en el cual se esté ejecutando. Para crear un servicio debemos crear un stack, para lo cual debemos definir un archivo docker-compose.yaml que contenga la descripción de nuestro servicio o bien, usar uno de los servicios de infraestructura que Rancher ha desplegado al crear nuestro swarm. Este servicio de infraestructura se llama Portainer y se encuentra disponible en el menú SWARM:

Acceso a Portainer desde el menú SWARM.

Pantalla de acceso al interfaz de administración Portainer.

Portainer es un interfaz gráfico que nos permite administrar entornos Docker y está incluido como uno de los servicios de infraestructura desplegados por Rancher. Una vez que accedemos al interfaz de portainer, la consola de administración es como podemos ver en la siguiente imagen:

Interfaz de administración de Portainer.

Usando Portainer, podemos desplegar un servicio de forma muy sencilla desde el apartado Services con solo especificar los parámetros de configuración necesarios para nuestro servicio:

Creación de un servicio desde Portainer.

Panel de control de los servicios desplegados.

Ahora desde el interfaz de Rancher, en la sección Containers de nuestra infraestructura vemos los contenedores que están ejecutándose:

Los contenedores de nuestro servicio vistos desde Rancher.

Por tanto, y en resumen, podemos crear y gestionar nuestros entornos Docker Swarm desde Rancher y lo más importante es que añade nuevas funcionalidades gracias a los servicios de infraestructura que despliega. 

Adicionalment nos permite tener un análisis de uso de los contenedores de nuestros servicios y controlarlos directamente, aunque desde mi punto de vista lo recomendable es que usemos Portainer directamente ya que nos da acceso a las acciones de servicio.

En las próximas entradas sobre Docker Swarm y Rancher desplegaremos servicios, describiéndolos con los ficheros compose correspondientes e investigaremos los servicios de infraestructura disponibles y como podemos utilizarlos.

NOTA IMPORTANTE: Es necesario establecer el parámetro de configuración max_allowed_packet de nuestra base de datos, si usamos MySQL o MariaDB, en al menos 32M para que Rancher pueda refrescar correctamente el catálogo de plugins y plantillas de los repositorios de Rancher.