La documentación de IBM Maximo Application Suite explica bien el camino feliz: preparas OpenShift, lanzas el mas install del CLI oficial y esperas. En la realidad, la instalación se para varias veces por cosas que no tienen nada que ver con MAS y sí mucho con el cluster en el que aterriza. Estas son las que me he encontrado instalando MAS 9.1, y las que ahora reviso antes de lanzar nada.
1. El catálogo decide tu versión de OpenShift, no al revés. Cada catálogo de operadores de MAS soporta un rango concreto de versiones de OpenShift. Antes de elegir versión de OCP para un cluster nuevo, mira qué catálogo vas a usar y qué versiones admite, y cruza eso con el fin de soporte de cada versión de OpenShift. Elegir la más estable que conoces puede dejarte fuera de soporte en pocos meses.
2. El almacenamiento falla antes que MAS. Mis primeros bloqueos no fueron de MAS. Fueron parámetros del driver CSI mal puestos en la StorageClass, el secreto de credenciales del proveedor de almacenamiento que faltaba, y el registro interno de imágenes de OpenShift sin PVC. MAS necesita a la vez almacenamiento RWO (bases de datos, componentes con estado) y RWX (los volúmenes compartidos de Manage). Prueba a crear un PVC de cada tipo y móntalo en un pod de prueba antes de instalar. Te ahorra horas de leer logs de operadores.
3. Las dependencias que ya existen en el cluster te pueden romper la instalación. cert-manager, por ejemplo. Si ya había una instalación previa o un OperatorGroup duplicado en su namespace, OLM se niega a resolver la suscripción y el error que ves no apunta claramente a la causa. Revisa qué operadores comunes ya hay en el cluster antes de que el instalador intente añadir los suyos.
4. Si la base de datos es externa, prepárala tú. Con una DB2 externa, el instalador no te va a crear lo que Manage necesita. Hay que dejar listos los tablespaces de datos e índices, un bufferpool de 32K y los permisos para que el usuario de Maximo pueda crear tablas. Y, por supuesto, la regla de firewall desde los workers al puerto de la base de datos. Ese último punto parece obvio y es el que más días de espera me ha costado, porque depende de otro equipo.
5. Los permisos de los volúmenes compartidos de Manage son delicados. Los pods de Manage corren con un UID aleatorio de OpenShift y acceden a los volúmenes compartidos (adjuntos, carpetas globales de la aplicación) a través del grupo 0. Cualquier cosa que toque esos volúmenes desde fuera puede dejar a Manage sin escritura en sus propias carpetas sin que salte ninguna alarma: un pod auxiliar, una copia de ficheros, un contenedor que hace chown al arrancar. El síntoma tampoco ayuda: errores 404 en la consola o un “the entered path is not a directory” al adjuntar un fichero. Desde entonces, todo lo que monto sobre esos PVC usa subPath y respeta el grupo 0 con g+rwX y el bit setgid en los directorios.
6. La red de salida también es parte de la instalación. Las integraciones de verdad llegan después: correo, LDAP, SSO, ServiceNow… y casi todas acaban en una petición de firewall. Si los pods salen con la IP de cualquier worker, cada apertura hay que hacerla para todos los nodos. Configurar una EgressIP fija para el namespace de Manage simplifica esas peticiones a una sola IP. Lo mismo pasa con los certificados: un wildcard público para las rutas de MAS es un requisito real para muchas integraciones, no un detalle cosmético. Pídelo pronto, porque suele tardar.
Ninguno de estos puntos aparece como “paso” en la guía de instalación, porque ninguno es estrictamente de MAS. Pero son exactamente los que deciden si la instalación dura un día o tres semanas.
¿Habéis instalado MAS sobre OpenShift? ¿Qué os bloqueó a vosotros que no aparecía en la documentación?
Si trabajas con OpenShift en producción, la parte de seguridad y monitorización del cluster la trato a fondo en mi manual “Seguridad y monitorización en Kubernetes” (950 páginas, en español). [Descarga la muestra gratuita]([URL de la muestra]) · Consigue el manual completo
Leave a Reply