Han pasado 5 años y toca renovar el storage. ¿Cuales son los errores más habituales?

La renovación de los sistemas almacenamiento empresarial, es una decisión crítica, compleja y con unos costes que hacen muy recomendable que sea abordado con mucho cuidado. Es común que se cometan errores al planificar y llevar a cabo este tipo de proyectos y en este artículo, vamos a comentar aquellos que nos encontramos con mayor frecuencia en nuestros nuevos clientes.

1. Dimensionamiento incorrecto

Uno de los errores más comunes al renovar el almacenamiento empresarial es subestimar o sobreestimar la capacidad (en TB, rendimiento y tiempo de respuesta) necesaria de almacenamiento. Un dimensionamiento incorrecto puede resultar en una inversión insuficiente o en una inversión excesiva en almacenamiento empresarial. Todos sabemos que una solución con NVMe es más rápida que otra con SSD, pero ¿la necesitamos? ¿y para el 100% de los datos? ¿a qué precio? ¿los servidores son capaces de alcanzar el ancho de banda que permite la cabina? (pista:  en el 95% de los casos no). Pero claro para saberlo es recomendable realizar un dimensionamiento o auditoría previa, que tiene un coste muy pequeño en comparación con la adquisición de las cabinas y lo que nos podemos llegar a ahorrar. Las prisas y las ofertas para mañana no son buenas compañeras de viaje en este tipo de proyectos.

2. No prever el coste a, al menos, 5 años

Uno de nuestros clientes compró hace años unas cabinas de uno de nuestros fabricantes favoritos. Era extremadamente potente y el precio era muy atractivo. Dos años después, quisieron añadir discos (la compraron con lo mínimo) y el precio de lista de los mismos superaba el millón de euros. Es más, todos los ejercicios mostraban que era más económico comprar una nueva cabina de menor gama pero con rendimiento más que suficiente y el almacenamiento que necesitaban, que ampliar la existente. ¿Absurdo? No, una mala praxis comercial muy habitual entre empresas sin personal técnico propio. Igual que nos regalan las impresoras, con muchos otros componentes de HW ocurren cosas similares. Switches que se licencian por puerto activado, cortafuegos cuyo precio varía según los usuarios que se conecten y otros miles de trucos para ocultar los costes en el medio y largo plazo, así como las dependencias generadas y la obligación de comprar servidores y cabinas adicionales cada poco tiempo. Si bien lo hacen todos los fabricantes, con un correcto asesoramiento muchas veces se le puede dar la vuelta y en el momento de la compra conseguir a un precio muy interesante todo lo que necesitemos mientras la máquina funcione.

3. No conocer el ciclo de vida de las máquinas (hasta cuándo tendrán mantenimiento)

Otro error frecuente es no comprender el ciclo de vida de las máquinas y no saber hasta cuándo estarán disponibles los servicios de mantenimiento. Es fundamental tener en cuenta la vida útil de las cabinas de discos y la disponibilidad de servicios de soporte técnico y mantenimiento en el medio y largo plazo. Muchas veces los sistemas al final de su ciclo de comercialización tienen importantes descuentos… pero es que también durante su lanzamiento. Lo segundo nos permite usarlos durante mucho más tiempo  reduciendo el coste anual significativamente. Si compramos una cabina que va a ser retirada de marketing próximamente, puede que cuando la hayamos puesto en funcionamiento solo le queden los años mínimos de soporte y a los 5 años la única alternativa sea soportarla nosotros mismos, pedir las piezas que fallen en brokers internacionales o comprar una nueva. Si hubiéramos adquirido un sistema que llevara poco en el mercado (aunque lo suficiente para que otros lo hayan probado y sufrido sus primeros fallos) será sencillo extender el mantenimiento durante 6, 7 o incluso 10 años que suele ser el tope de su ciclo de vida habitual. Los comerciales de empresas sin personal técnico te dirán “no se podía saber” o que “la culpa es de IBM / HP / Dell / Hitachi” pero no es cierto. Tenemos que saber lo que vendemos e informar a nuestros clientes de manera honesta sobre los pros y os contras de cada nueva infraestructura que les propongamos adquirir.

4. Desconocer las matrices de compatibilidad con los sistemas operativos

Otro error común es no considerar la compatibilidad del almacenamiento empresarial con los sistemas operativos existentes. Es fundamental asegurarse de que el storage sea compatible con los sistemas operativos existentes y que si debemos actualizar, lo hagamos antes de la puesta en marcha del nuevo almacenamiento. Esto es especialmente relevante cuando hay sistemas operativos fuera de soporte por la falta de de un servicio mantenimiento preventivo. Igual la nueva cabina soporta Red Hat o Windows, pero no la versión en producción porque todo nuevo hardware requiere drivers que sería raro existieran antes. Los viajes en el tiempo tampoco existen para los sistemas operativos, y un Windows de 2008 es probable que tenga problemas  de compatibilidad con una cabina de 2023.

5. No preveer el impacto de las migraciones de los entornos de producción existentes

Por último, otro error común es no prever el impacto de las migraciones de los sistemas existentes en el almacenamiento que hemos renovado. Es importante evaluar cuidadosamente los sistemas existentes que se migrarán y comprender cómo se integrarán en la nueva solución de almacenamiento,  quien se encargará de estos servicios profesionales y qué impacto tendrán en nuestra organización o negocio.

6. No tener un equipo técnico formado ni un soporte L2-L3 al que recurrir

Muchos clientes compran sistemas almacenamiento pero no tienen el tiempo para formarse en ellos ni disponen de servicios de soporte técnico externo al que recurrir, pensando que ante cualquier problema pueden recurrir al fabricante pues ya pagan un soporte por estos sistemas, cuando no siempre es así, sobretodo si el sistema funciona correctamente y el problema, aunque muy relacionado, es otro.

7. Confiar en empresas que no tienen equipos técnicos y cuyo negocio se basa en grandes márgenes en las ventas de SW y HW

A diferencia de nuestra competencia, en Sixe Ingeniería siempre nos pondremos del lado de nuestros clientes, pues vivimos fundamentalmente de la formación, consultoría y soporte técnico. Servicios que complementamos con la venta de HW que normalmente ayudamos a mantener, con lo que somos los principales interesados en que las soluciones sean las idóneas en el medio y largo plazo. Además, como partners de referencia de IBM y Lenovo, podemos ofreceros importantes descuentos, conocemos muy bien la mayoría de los tipos de entornos críticos y somos agnósticos en cuanto a tecnología, aunque tenemos nuestras preferencias en base a nuestra experiencia. ¿Hablamos?

Con la compra de Red Hat por parte de IBM, el conjunto del portfolio de soluciones de software para ciberseguridad, aplicaciones, bases de datos, automatización y gestión de nubes híbridas se ha ido portando a OpenShift bajo la marca IBM Cloud Paks. Esto implica que muchas de estas aplicaciones se ha rediseñado y adaptado para funcionar sobre contenedores (aunque algunas como QRadar ya lo hacían desde hace años) y ser controladas por Kubernetes, que es el orquestador de contenedores en el que se basa OpenShift.

¿Cómo se despliegan los IBM Cloud Paks?

Los Cloud Paks de IBM se instalan sobre un entorno PaaS con OpenShift tanto en data centers propios sobre IBM Power Systems, VMWare, KVM (RHEV / LinuxONE) como en las nubes públicas de Microsoft (Azure), IBM, Amazon (AWS) y Google (GCP). Gracias a IBM Satellite se puede desplegar en una combinación de recursos propios y en la nube, mediante una arquitectura híbrida y flexible. Nuestro departamento de servicios profesionales puede ayudaros.

¿Como se licencian IBM Cloud Paks? ¿Cuanto cuestan?

Esto es quizás una de las partes menos conocidas y a nuestro juicio más polémicas. IBM siempre ha vendido licencias perpetuas para todas su soluciones software. Estas licencias vienen con un soporte técnico básico para incidencias HW y otro más avanzado para el SW (SWMA) que se pueden ir renovando típicamente cada 3 años. Al pasar a un entorno “cloud” vamos hacia sistemas de pago por uso, muy escalable y para qué engañarnos, a veces complicado de estimar. Por ejemplo, en el de Data tiene estos precios por “core virtual”. Es decir, desde unos cientos de dólares hasta a unos cuantos cientos de miles.. :)

Esto tiene ventajas evidentes para soluciones donde el soporte lo razonable que se vaya renovando como es el caso de soluciones abiertas y extremadamente complejas como las basadas en micro-servicios y contenedores. Los clientes que no estén cómodos con este modelo, pueden seguir comprando appliances o licencias para desplegar en su infraestructura muchas de estas soluciones mediante un único pago y un soporte opcional a renovar cada varios años. En otras, este es el único modelo pues son soluciones nativas para entornos basados en Kubernetes y Cloud.

¿Necesito tener OpenShift para instalar un Cloud Pak de IBM?

Respuesta corta: si. Ahora bien, si no lo tienes, lo puedes desplegar sin demasiados problemas gracias a los instaladores incluidos en las últimas versiones tanto en tu propia infraestructura como en una externa (IaaS) de tu proveedor de cloud favorito.

¿Merecen la pena los IBM Cloud Paks?

Como buen verso libre que somos en el sector de los integradores de sistemas, pensamos que algunos si, y otros no tanto (al menos por ahora). Depende del uso que se les vaya a dar, de la dependencia que tengamos con otras aplicaciones y del nivel de madurez en la adopción de contenedores y uso de kubernetes de nuestra organización. Si estamos empezando con Dockers, OpenShift y entornos Cloud, quizás es mejor ceñirnos a un buen plan de transformación y modernización digital en vez de “empezar la casa por el tejado”.

¿Hay cursos o formación de IBM Cloud Paks?

Para poder aprovechar esta tecnología necesitas dominar tanto la infraestructura (OpenShift) de la cual hay formación oficial ofrecida por Red Hat, y un taller intensivo y práctico elaborado por nosotros mismos. Una vez que la infraestructura esté bajo control tendrás que formarte en los diferentes productos y soluciones de IBM que te interesen, pues no dejan de ser colecciones de Software agrupadas por categoría y licenciadas conjuntamente. Por ejemplo, el Cloud Pak for Security, es fundamentalmente IBM QRadar SOAR Platform  mientras que el Cloud Pak for Applications incluye toda la suite de Websphere.

Lo dicho, si queréis, hablamos.

 

Tras unirnos al programa OpenBeta de IBM, hemos podido descargar y probar la nueva versión de AIX 7.3 que llega en su 35 aniversario.

Entre sus novedades destacan:

• Los frameworks de Python y Bash que funcionan directamente con AIX, ¡no tendremos que volver a instalarlos manualmente!
• Soporte para el comando dnf (standard en Red Hat) para la instalación de paquetes de código abierto desde el AIX Toolbox. AIX habla Linux desde hace mucho tiempo, pero desde la versión 7.3 está cada vez más integrado facilitando a los desarrolladores y administradores de sistemas todas las ulilidades necesarias para modernizar los entornos UNIX.
• Reducción del tiempo para añadir dinámicamente procesadores/memoria a una LPAR en funcionamiento, de gran ayuda en LPARs con bases de datos que usen cientos de GB o varios TB de memoria RAM. Esto se une a la reducción de los tiempos de arranque (IPL) para este tipo de particiones
• Los comandos pigz y zlibNX ahora utilizan de forma transparente la aceleración GZIP de NX en Power9 y Power10
• Soporte mejorado para el cifrado de volúmenes lógicos (LVM) para incluir rootvg y dispositivo de dump.
• La pila de protocolos TCP ahora es compatible con CUBIC,  un algoritmo que evita la congestión de la red TCP que puede conseguir conexiones de gran ancho de banda a través de las redes de forma más rápida y fiable.
• Mejoras adicionales en la seguridad IP (IPsec)
• Posibilidad de crear un archivo OVA a partir de un mksysb mediante el comando create_ova con el objetivo de agilizar los despliegues en cloud (PowerVS) e híbridos.
• Creación de una imagen ISO a partir del nuevo comando mksysb_iso
• Integración con los nuevos compiladores IBM Open XL C/C++ y Fortran
• Aumento del tamaño de los archivos y del sistema de archivos
• Mejora de la compatibilidad con Ansible y Ansible Tower
• Integración con PowerVC 2.X

 

La introducción de las pipelines de Kubernetes (Tekton) ha supuesto una revolución en la forma de gestionar los flujos de trabajo de CI/CD en el desarrollo de software. La incorporación de Tekton a Kubernetes, nos ha dado más poder y flexibilidad en la creación y gestión de pipelines. Este artículo se centra en la importancia de Kubernetes Pipelines y Tekton en Red Hat OpenShift, y en cómo estas herramientas pueden ayudarte a que tu proceso de desarrollo sea realmente continuo.

¿Qué es una “pipeline”?

Una pipeline es un proceso automatizado que conduce el software a través de las etapas de construcción, prueba y despliegue del ciclo de vida del desarrollo de software. En otras palabras, una pipeline ejecuta el flujo de trabajo de Integración Continua y Entrega Continua (CI/CD). Gestiona automáticamente las tareas de ejecución del conjunto de pruebas, el análisis del código, la creación de binarios, la contenerización y el despliegue de los cambios en la nube o en las soluciones locales.

¿Por qué debería construir pipelines con Kubernetes?

A medida que el mundo del desarrollo avanza hacia la adopción de aplicaciones basadas en microservicios en lugar de aplicaciones monolíticas, el proceso de CI/CD se ha convertido en algo verdaderamente continuo con actualizaciones incrementales de la base de código que se pueden desplegar de forma independiente.

En un entorno así, Kubernetes simplifica el proceso de creación y mantenimiento de canalizaciones CI/CD. Despliega cada microservicio en un único clúster de Kubernetes y mantiene varias copias de cada microservicio para que sirvan como versiones de desarrollo, prueba y producción.

Con los pipelines de Kubernetes, ya no es necesario reconstruir toda la aplicación durante cada compilación. En su lugar, Kubernetes actualiza el contenedor del microservicio y lo despliega a través del pipeline definido. Ya no es necesario escribir scripts de compilación, ya que Kubernetes se encarga automáticamente del proceso con sólo unas pocas opciones de configuración que proporcionamos. Esto reduce la posibilidad de errores humanos en el flujo de trabajo de CI/CD.

¿Qué es Tekton?

Tekton le permite llevar los pipelines de Kubernetes al siguiente nivel. Es un marco de trabajo nativo de Kubernetes y de código abierto para el desarrollo de canalizaciones CI/CD. Tekton proporciona extensiones a las definiciones de recursos personalizadas (CRD) en Kubernetes para facilitar la creación y estandarización de canalizaciones. Tiene soporte incorporado para el acoplamiento con herramientas CI/CD existentes en la industria como Jenkins, Jenkins X, Skaffold, Knative y OpenShift.

La integración en OpenShift de Tekton, denominada OpenShift Pipelines, introduce aún más potencia y flexibilidad en este sistema a través de las herramientas para desarrolladores de RedHat y OpenShift.

¿Por qué debería utilizar Tekton?

Los pipelines de Tekton utilizan clusters de Kubernetes como tipo de primera clase y contenedores como sus principales bloques de construcción. La naturaleza desacoplada de Tekton garantiza que pueda utilizar una única canalización para desplegar en clústeres Kubernetes separados. Esto facilita el despliegue de servicios en múltiples soluciones en la nube suministradas por diferentes proveedores o incluso en sistemas locales.

Tekton permite ejecutar las tareas automatizadas de forma aislada, sin que se vean afectadas por otros procesos que se estén ejecutando en el mismo sistema. Otra especialidad de Tekton es la flexibilidad que proporciona para cambiar los recursos, como los repositorios de GitHub, entre las ejecuciones de la tubería.

También facilita el cambio de implementación de la tubería en función del tipo de recurso. Por ejemplo, puede configurar una implementación única para manejar imágenes.

Tekton acoplado a OpenShift garantiza una alta disponibilidad del sistema al permitir que cada unidad escale de forma independiente bajo demanda. Además, Kubernetes incorpora herramientas de registro y supervisión mejoradas y funciones de autorrecuperación rápida.

¿Cómo funciona Tekton?

Tekton proporciona CRDs al estilo de Kubernetes para declarar pipelines CI/CD. Los recursos se declaran en un yaml que, normalmente, se almacena con el repositorio de código. Vamos a considerar los CRD básicos que son esenciales a la hora de crear tuberías.

Tarea

Una Tarea es la unidad configurable más pequeña de una pipeline Tekton. Es similar a una función que acepta un conjunto de entradas y produce ciertos resultados. Cada tarea puede ejecutarse de forma individual e independiente o como parte de la cadena de producción. Un comando ejecutado por una Tarea se llama Paso. Cada tarea consta de uno o varios pasos. Tekton ejecuta cada tarea en su propio pod de Kubernetes.

Tubería (pipeline)

Una pipeline consiste en un número de tareas que forman el flujo de trabajo final automatizado de CI/CD. Además de las tareas, también contiene PipelineResources. Se proporcionan como entradas y salidas a las Tareas de la Red.

PipelineResource

Un PipelineResource es un objeto que se utiliza como entrada o salida de una Tarea. Por ejemplo, si la tarea acepta un repositorio de GitHub como entrada y construye y emite la imagen Docker relacionada, ambos se declaran como objetos PipelineResource.

PipelineRun

Un PipelineRun es una instancia de un Pipeline que se está ejecutando. Inicia la ejecución del Pipeline y gestiona los PipelineResources pasados a las Tareas como entradas y salidas.

TaskRun

Una TaskRun es una instancia en ejecución de una Tarea. PipelineRun crea objetos TaskRun para cada Tarea en el Pipeline para iniciar la ejecución.

Disparador

Un Trigger es un evento externo que desencadena el flujo de trabajo CI/CD. Por ejemplo, un pull request de Git podría actuar como un Trigger. La información transmitida con la carga útil del evento se utiliza entonces para activar las tareas en la canalización.

Condición

Las condiciones son similares a las sentencias if de la programación normal. Realizan una comprobación de validación con respecto a las condiciones proporcionadas y devuelven un valor Verdadero o Falso. El pipeline comprueba estas condiciones antes de ejecutar una tarea. Si la condición devuelve True, la tarea se ejecuta, y si devuelve False, la tarea se omite.

Con estos componentes, puede crear canalizaciones complejas y totalmente automatizadas para crear, probar e implantar sus aplicaciones en la nube o en soluciones locales.

¿Quién debe utilizar Tekton?

Los ingenieros de plataforma que construyen flujos de trabajo CI/CD para los desarrolladores de una organización encontrarán en Tekton un marco ideal para hacer este proceso más sencillo. Los desarrolladores también pueden crear flujos de trabajo CI/CD con Tekton para proyectos de desarrollo de software y aplicaciones. Esto les permite gestionar fácilmente las diferentes etapas del proceso de desarrollo, como las versiones de desarrollo, prueba y producción del producto, con una interferencia humana mínima.

¿Qué es lo siguiente?

Consulte la documentación oficial de Tekton y OpenShift Pipelines para obtener más información sobre cómo configurar pipelines de CI/CD que satisfagan las necesidades de su organización con facilidad.

¿Necesitas ayuda?

Ofrecemos Kubernetes y OpenShift formaciones y podemos ayudarle a comprar, desplegar y gestionar su
Entorno OpenShift en IBM Power Systems
.

Openshift Platform Plus es el último miembro de la familia OpenShift. La solución PaaS de Red Hat para aplicaciones basadas en Kubernetes. Se ha anunciado junto con la versión 8.4 de Red Hat Linux. Gracias a Red Hat Openshift Plus, las organizaciones pueden, por un ligero coste adicional (del que hablaremos más adelante) gestionar no solo las aplicaciones, sino también sus políticas y configuraciones de seguridad, independientemente de dónde se encuentren sus aplicaciones, ya que incluye un nuevo soporte integrado para el ciclo de vida de las aplicaciones en entornos multiclúster, así como la posibilidad de crear clústeres de tan solo 3 nodos o incluso con nodos “trabajadores” remotos que permiten ampliar los clústeres de Kubernetes a casi cualquier ubicación, lo que incluye instalaciones con poca potencia disponible.

¿Qué incluye OpenShift Platform Plus?

• MotorKubernetes (capa base de OpenShift en el sistema operativo Linux)
• Orquestación/control de gestión(Red Hat Advanced Cluster Manager for Kubernetes-ACM)
• Protocolos de seguridad(Red Hat Advanced Cluster Security for Kubernetes-ACS)
• Software de registro(Red Hat Quay)

OpenShift Platform Plus proporciona todas las características de base, gestión y seguridad en un solo paquete, que estaban disponibles por separado a sus precios. Advanced Cluster Security (ACS) se añadió a Openshift tras la adquisición de StackRox, un proveedor de seguridad nativo de Kubernetes.

Multi-nube y preparado para CI/CD

OpenShift ofrece una solución de configuración completa para crear un entorno o ejecutar una aplicación basada en contenedores en una nube híbrida o en una infraestructura de servidor local. Openshift ofrece dos tipos son infraestructura de aplicaciones de contenedores, es decir, gestionada y autogestionada. Las plataformas gestionadas son servicios basados en la nube con todas las funciones, como Azure, IBM, AWS y Google Cloud. Al mismo tiempo, las plataformas autogestionadas son altamente personalizables, pero requieren un equipo altamente cualificado para cada parte del despliegue.

OpenShift evolucionó con el tiempo e incluyó características críticas para mejorar la funcionalidad. Al principio, se introdujo OpenShift Kubernetes Engines, que incluye el tiempo de ejecución de Enterprise Kubernetes, el sistema operativo de contenedores inmutables Red Hat Enterprise Linux CoreOS, la consola del administrador y Red Hat OpenShift Virtualization. Luego viene la plataforma de contenedores OpenShift aumentada con la consola del desarrollador, la gestión de registros y costes, OpenShift Serverless (Knative), OpenShift Server Mesh (Istio), OpenShift Pipelines y OpenShift GitOps(Tekton, ArgoCD). Con todas las características disponibles anteriormente, OpenShift Platform Plus viene con características adicionales.

Características de la plataforma OpenShift Plus

Gestión avanzada de clústeres de Red Hat para Kubernetes

Es una opción de control de gestión avanzada de OpenShift. Proporciona a los clientes un acceso completo a la gestión unificada de múltiples clústeres (edición de los clústeres en nubes públicas o privadas, asignación de recursos para los clústeres y resolución de problemas en todo el dominio desde una única disposición) a través de la consola web de Openshift. Además, proporciona una gestión basada en políticas que incluye la estandarización de los parámetros de las políticas para la seguridad, la aplicación y el marco de la infraestructura.

Las aplicaciones pueden desplegarse en la red mediante una gestión avanzada del ciclo de vida de las aplicaciones. También ayuda a controlar el flujo de aplicaciones en los nodos, la gestión de la configuración del día 2 mediante Ansible. El objetivo de Advanced Cluster Management (ACM) es proporcionar soluciones de salud del clúster relacionadas con el almacenamiento, la optimización y la resolución de problemas. Las herramientas de monitorización de OpenShift están bien diseñadas para operar con facilidad y eficiencia.

Red Hat Advanced Cluster Security for Kubernetes (ACS)

ACS se incorporó a la familia OpenShift tras la adquisición de StackRox, potenciando el ACS como componente principal de OpenShift Platform Plus. Esta característica de seguridad es diferente de las medidas de seguridad implementadas anteriormente. Anteriormente, los protocolos de seguridad se aplicaban después de desarrollar la aplicación. ACS ofrece la inclusión de la seguridad desde el principio, es decir, en el código base. Las funciones de seguridad avanzadas aumentan cada paso del ciclo de vida del desarrollo de aplicaciones.

La seguridad avanzada de los clústeres sigue los estándares internacionales de seguridad de los contenedores, como las referencias del CIS y del NIST. Los protocolos de seguridad incluyen la seguridad contra la violación de datos, la protección de la red, la eliminación de puntos ciegos, la reducción de tiempo y costes mediante la aplicación eficaz de los códigos de la política de seguridad, la evitación de conflictos operativos, el solapamiento de datos y la redundancia. ACS es una ejecución perfecta de los protocolos DevSecOps.

Red Hat Quay

Un registro de contenedores es una plataforma de almacenamiento utilizada para almacenar contenedores para Kubernetes y otros desarrollos de aplicaciones basados en contenedores como DevOps. Cuando se forma una aplicación de contenedor, se crea su imagen. Es una especie de archivo .exe que contiene todos los archivos y componentes para una instalación exitosa. Cuando una imagen de contenedor se coloca en otras plataformas, se utiliza para crear la misma aplicación de contenedor. Una imagen de contenedor es una plantilla utilizada para crear más aplicaciones.

Red Hat Quay es un registro privado de contenedores utilizado para crear, distribuir y almacenar imágenes de contenedores. Cuando la imagen del contenedor se comparte en el repositorio de la red, aparecen vulnerabilidades específicas. RedHat Quay utiliza la seguridad Clair para hacer frente a estas vulnerabilidades proporcionando estrictos controles de acceso, protocolos de autenticación y otras cuestiones de distribución.

Características de RedHat Quay

• Cada imagen está etiquetada con la marca de tiempo; RedHat Quay ofrece Time Machine para etiquetar la versión de la imagen y la capacidad de reversión como la degradación o la restauración de la configuración de fábrica. Proporciona un historial configurable de 2 semanas para las etiquetas de las imágenes.
• La distribución geográfica garantiza imágenes rápidas e impecables utilizando redes de distribución de contenidos (CDN) para que cada punto de acceso tenga su repositorio cercano. RedHat Quay también utiliza la tecnología BitTorrent para reducir el tiempo de espera para la disponibilidad de contenidos.
• La recolección de basura de recursos en tiempo de ejecución ayuda a identificar las operaciones inútiles o menos utilizadas para optimizar el uso de los recursos y aumentar la eficiencia.
• RedHat Quay ofrece almacenamiento ilimitado para múltiples colecciones de imágenes.
• Activación automatizada de la canalización de integración continua/entrega continua (CI/CD)
• Auditoría basada en registros mediante el escaneo de APIs e interfaces de usuario
• Los protocolos de autenticación que utilizan LDAP, OAuth, OIDC y keystone garantizan un registro seguro y un control de acceso jerárquico de la organización.
• La automatización de la cuenta proporciona la creación de las credenciales necesarias para ejecutar el programa.
• Adaptabilidad multiplataforma

Precios de RedHat OpenShift Platform Plus

Se considera que las funciones avanzadas de OpenShift Platform Plus estarán disponibles entre abril de 2021 y junio de 2021. El precio actual aún no está disponible. OpenShift.io es una plataforma gratuita para el despliegue en la nube. El coste de la Plataforma Plus depende del tamaño y de la suscripción. Según Capterra, cada función Plus cuesta 20 dólares al mes en los planes autogestionados. Una mejor manera de leer y elegir un modelo de suscripción, y contactar con nuestro departamento de ventas. También puede solicitar una demostración de OpenShift Plus de forma gratuita.

Formación y servicios profesionales de RedHat OpenShift Platform

Ofrecemos cursos de Kubernetes y OpenShift asi como servicios de venta, instalación y soporte técnico para OpenShift en IBM Power Systems. Contáctenos para más información