Alexandre Vazquez – Página 13

MinIO: Almacenamiento de Objetos Multinube

2025-11-03 por Alexandre Vazquez

Todo el poder del almacenamiento de objetos en tu entorno de Kubernetes

MinIO: Almacenamiento de Objetos Multi Nube (Foto por Timelab Pro en Unsplash)

En este post, me gustaría presentarles MinIO, una verdadera solución de almacenamiento de objetos en la nube con todas las características que puedas imaginar e incluso algunas más. Probablemente estés al tanto del almacenamiento de objetos del servicio AWS S3 que surgió hace algunos años y de la mayoría de las alternativas en los principales proveedores de nube pública como Google o Azure.

¿Pero qué pasa con las nubes privadas? ¿Existe algo disponible que pueda proporcionar todos los beneficios del almacenamiento de objetos, pero sin necesidad de depender de un solo proveedor de nube? Y aún más importante que eso, en el presente y futuro, donde todas las empresas van a ser multi nube, ¿tenemos a nuestra disposición una herramienta que proporcione todas estas características pero que no nos obligue a tener un bloqueo de proveedor? Incluso algunos software, como Loki, te animan a usar una solución de almacenamiento de objetos.

¡La respuesta es sí! Y de eso se trata MinIO, y solo quiero usar sus propias palabras:

“MinIO ofrece almacenamiento de objetos de alto rendimiento, compatible con S3. Nativo de Kubernetes, MinIO es la única suite de almacenamiento de objetos disponible en cada nube pública, distribución de Kubernetes, la nube privada y el edge. MinIO es definido por software y es 100% de código abierto bajo GNU AGPL v3.”

Así que, como dije, todo lo que puedas imaginar e incluso más. Centrémonos en algunos puntos:

Nativo de Kubernetes: Puedes desplegarlo en cualquier distribución de Kubernetes de tu elección, ya sea pública o privada (o incluso en el edge).
100% de código abierto bajo GNU AGPL v3, por lo que no hay bloqueo de proveedor.
Almacenamiento de objetos compatible con S3, lo que incluso simplifica la transición para clientes con un fuerte vínculo con el servicio AWS.
El alto rendimiento es la característica esencial.

Suena genial. ¡Probémoslo en nuestro entorno! Así que voy a instalar MinIO en mi entorno de rancher-desktop, y para hacerlo, voy a usar el operador que tienen disponible aquí:

Para poder instalar, la opción recomendada es usar krew, el gestor de plugins del que ya hablamos en otro artículo. Lo primero que necesitamos hacer es ejecutar el siguiente comando.

 kubectl minio init

Este comando desplegará el operador en el clúster como puedes ver en la imagen a continuación:

Una vez hecho y todos los componentes estén en funcionamiento, podemos lanzar las interfaces gráficas que nos ayudarán a crear el inquilino de almacenamiento. Para hacerlo, necesitamos ejecutar el siguiente comando:

 kubectl minio proxy -n minio-operator

Esto expondrá la interfaz interna que nos ayudará durante ese proceso. Se nos proporcionará un token JWT para poder iniciar sesión en la plataforma como puedes ver en la imagen a continuación:

Ahora necesitamos hacer clic en el botón que dice “Crear Inquilino” que nos proporcionará un menú de asistente para crear nuestro inquilino de almacenamiento de objetos MinIO:

En ese asistente podemos seleccionar varias propiedades dependiendo de nuestras necesidades, como esto es para mi escritorio rancher, intentaré mantener la configuración al mínimo como puedes ver aquí:

Sería útil si tuvieras el espacio de nombres creado de antemano para ser recuperado aquí. Además, debes tener en cuenta que solo puede haber un inquilino por espacio de nombres, por lo que necesitarás espacios de nombres adicionales para crear otros inquilinos.

Tan pronto como presiones crear, se te proporcionará una clave API y un secreto que necesitas almacenar (o descargar) para poder usar más tarde, y después de eso, el inquilino comenzará su despliegue. Después de unos minutos, tendrás todos tus componentes en funcionamiento, como puedes ver en la imagen a continuación:

Si vamos a nuestro console-svc, encontrarás la siguiente interfaz gráfica disponible:

Después de que las credenciales se descarguen en el paso anterior, ingresaremos a la consola de nuestro almacenamiento de objetos en la nube y podremos comenzar a crear nuestros buckets como puedes ver en la imagen a continuación:

En la pantalla de creación de un bucket, puedes ver varias opciones, como Versionado, Cuota y Bloqueo de Objetos, que dan una visión de las características y capacidades que tiene esta solución.

Y podemos comenzar a subir y descargar objetos a este nuevo bucket creado:

Espero que puedas ver esto como una opción para tus despliegues, especialmente cuando necesitas una opción de solución de almacenamiento de objetos para despliegues privados o simplemente como una alternativa a AWS S3.

Principales 6 comandos de Kubectl y consejos de Kubectl

2025-11-03 por Alexandre Vazquez

Los 6 mejores comandos de Kubectl y consejos de Kubectl

El comando kubectl puede ser el comando más utilizado que puedes escribir al trabajar con el ecosistema de Kubernetes. Como sabes, kubectl es la puerta de entrada a todo el mundo de Kubernetes, ya que prácticamente todas nuestras interacciones pasan por esa parte, a menos que estés utilizando un enfoque de CLI.

Entonces, basándonos en los principios de productividad, si puedes mejorar solo un 1% en la tarea que realizas más, la mejora global será masiva. Así que, veamos cómo podemos hacer eso aquí.

kubectl es un comando con muchas opciones diferentes que podrían ayudar a aumentar tu productividad mucho. Pero al mismo tiempo, como tiene tantas opciones, es bastante complejo conocerlas todas o estar al tanto de que hay una forma más rápida de hacer el trabajo, y por eso me gustaría agregar algunas opciones aquí para intentar ayudarte con este conjunto de consejos de kubectl.

Consejos de Comandos de Kubectl

Comencemos con los primeros comandos de kubectl que ayudan mucho a mejorar tu productividad:

kubectl explain <resource-object>

Este comando mostrará la referencia de la API para cualquier Objeto de Kubernetes, por lo que te ayudará a conocer la ortografía exacta de la opción que siempre escribes mal.

kubectl get <resource-object> —watch-output

La opción —watch-output añadida a cualquier comando de kubectl funcionará de la misma manera que el comando watch en sí, por lo que actualizará el mismo comando cada 2.0 segundos para ver la versión en tiempo real de ese comando y evitar que necesites escribirlo de nuevo o depender de un comando externo como watch

kubectl get events --sort-by=".lastTimestamp"

Este comando te ayudará cuando quieras ver los eventos en tu contexto actual, pero la principal diferencia es que ordenará la salida por la marca de tiempo de más reciente a más antiguo, por lo que evitarás tener que desplazarte para encontrar los últimos eventos.

kubectl logs --previous

Siempre hablamos de una de las necesidades de una Arquitectura de Agregación de Logs porque los logs son desechables, pero ¿qué pasa si quieres obtener los logs en un contenedor eliminado? Puedes usar la bandera --previous para acceder a los logs de un contenedor que se ha terminado recientemente. Esto no eliminará la necesidad de una técnica de agregación de logs, pero ayudará a solucionar problemas cuando Kubernetes comience a eliminar cosas y necesites saber qué sucedió.

kubectl create <object> <options> -o=yaml --dry-run=client

kubectl create nos permite crear un objeto de nuestra preferencia proporcionando los argumentos requeridos de manera imperativa, pero si añadimos la opción -o=yaml --dry-run=client, no obtendremos nuestro objeto creado. En su lugar, tendremos un archivo YAML que define ese objeto. Así que podemos modificarlo fácilmente a nuestras necesidades sin tener que hacerlo desde cero buscando en Google un ejemplo para comenzar.

kubectl top pods --all-namespaces --sort-by='memory'

Este comando alterará el orden estándar de top pods para mostrar los pods y los recursos que están consumiendo, y al mismo tiempo, ordenará esa salida por el uso de memoria. Así que, en entornos con muchos pods, proporcionará justo en la parte superior aquellos en los que deberías centrarte primero para optimizar los recursos de todo tu clúster.

Alias de Kubectl

Un paso más allá es simplificar esos comandos añadiendo un alias a esto. Como puedes ver, la mayoría de estos comandos son bastante largos ya que tienen muchas opciones, por lo que escribir cada una de estas opciones tomará un tiempo.

Entonces, si quieres ir un paso más allá en esta optimización, siempre puedes añadir un alias a ese comando para simplificarlo mucho. Y si quieres aprender más sobre esos alias, recomiendo encarecidamente el repositorio de GitHub de Ahmet Alp Balkan:

GitHub – ahmetb/kubectl-aliases: Alias de kubectl generados programáticamente y útiles.

Alias de kubectl generados programáticamente y útiles. Contribuye al desarrollo de ahmetb/kubectl-aliases creando una cuenta en GitHub.

Operadores de Kubernetes: 5 cosas que realmente necesitas saber

2025-11-03 por Alexandre Vazquez

Operadores de Kubernetes: 5 Cosas Que Realmente Necesitas Saber (Foto por Dan Lohmar en Unsplash)

El Operador de Kubernetes ha sido la nueva norma para desplegar grandes cargas de trabajo en Kubernetes, pero como algunos de estos principios no se alinean inmediatamente con los conceptos principales de Kubernetes, generalmente genera un poco de confusión y dudas cuando necesitas usarlos o incluso crearlos.

¿Qué Son los Operadores de Kubernetes?

Los operadores son la forma de extender las capacidades de Kubernetes para gestionar grandes cargas de trabajo donde se relacionan diferentes opciones. En componentes con una arquitectura distribuida, como un sistema de monitoreo, un sistema de agregación de registros, o incluso un service mesh, puedes encontrar eso. Basado en las palabras de la documentación oficial de Kubernetes, los operadores se definen de la siguiente manera:

Los operadores son extensiones de software para Kubernetes que utilizan recursos personalizados para gestionar aplicaciones y sus componentes. Los operadores siguen los principios de Kubernetes, notablemente el bucle de control.

Su uso principal es para servicios estándar y no tanto para aplicaciones simples o cargas de trabajo de usuario, pero podría usarse en casos incluso para ese escenario.

¿Cómo Funciona el Operador de Kubernetes?

El concepto central detrás del Operador de Kubernetes es el concepto de extensión. Se basa en la definición y gestión de objetos personalizados de Kubernetes llamados Definición de Recursos Personalizados (CRDs) que permiten una descripción al estilo Kubernetes de nuevos conceptos que podrías necesitar para tus cargas de trabajo.

Algunos ejemplos de estos CRDs son el ServiceMonitor o PodMonitor que explicamos en publicaciones anteriores, por ejemplo, pero hay muchos más para agregar. Entonces, eso significa que ahora tienes un nuevo archivo YAML para definir tus objetos, y puedes usar las primitivas principales de Kubernetes para crearlos, editarlos o eliminarlos según sea necesario.

Entonces, para que estos componentes realicen cualquier trabajo, necesitas codificar algunos controladores específicos que traduzcan los cambios realizados en esos archivos YAML para alcanzar primitivas al estado del clúster.

Patrón de Operador de Kubernetes (https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md#foundation)

¿Cómo Gestionar los Operadores de Kubernetes?

El operador de Kubernetes se puede instalar como cualquier otra carga de trabajo de Kubernetes, por lo que dependiendo del caso puede distribuirse como un archivo YAML o un Helm Chart. Incluso puedes encontrar un repositorio compartido de operadores en OperatorsHub.

OperatorHub: Repositorio Central para Operadores de Kubernetes

Operador de Kubernetes vs. Helm Charts

Como ya se discutió, no son el mismo tipo de objeto que los Helm Charts porque los Helm Charts solo funcionan a nivel de despliegue haciendo el empaquetado y gestionando esos lanzamientos, pero los operadores van un paso más allá porque gestionan y controlan el ciclo de vida a nivel de tiempo de ejecución. Y como se comentó, Helm y los Operadores son compatibles; este es, por ejemplo, cómo funciona el Operador de Prometheus que tiene un Helm Chart para desplegarse, como puedes encontrar aquí.

Cómo Construir un Operador de Kubernetes

Si tu objetivo después de leer esto es crear un Operador de Kubernetes, necesitas saber que ya existen algunos marcos que harán tu vida más fácil en esa tarea.

Herramientas como Kopf, kubebuilder, metacontroller, o incluso el CNCF Operator Framework te proporcionarán las herramientas y las tareas cotidianas para comenzar a enfocarte en lo que tu operador necesita hacer, y ellos manejarán las principales tareas diarias por ti.

Más Recursos Para Aprender sobre el Operador de Kubernetes

Si deseas aprender más sobre los Operadores de Kubernetes o el patrón de Operador, en ese caso, te recomiendo encarecidamente que mires el Libro Blanco del Operador de CNCF que puedes encontrar aquí.

Esto cubrirá todos los temas discutidos anteriormente con más detalle técnico e introducirá otros temas vitales, como la gestión del ciclo de vida de la seguridad o incluso las mejores prácticas.

Otros recursos interesantes son el recurso bibliográfico del propio Libro Blanco que voy a agregar aquí por si deseas ir directamente a la fuente:

Dobies, J., & Wood, J. (2020). Kubernetes Operators. O’Reilly.
Ibryam, B. (2019). Kubernetes Patterns. O’Reilly.
Operator Framework. (n.d.). Operator Capabilities. Operator Framework. Retrieved 11 2020, 24, from https://operatorframework.io/operator-capabilities/
Philips, B. (2016, 03 16). Introducing Operators: Putting Operational Knowledge into Software. CoreOS Blog. Retrieved 11 24, 2020, from https://coreos.com/blog/introducing-operators.html
Hausenblas, M & Schimanski, S. (2019). Programming Kubernetes. O’Reilly.

Integración de TIBCO BW y EMS

2025-11-03 por Alexandre Vazquez

TIBCO BW admite muchos métodos de integración diferentes y cientos de conectores que te permiten conectarte a cualquier fuente posible. Pero la verdad debe ser dicha, EMS es uno de los conectores estándar que necesitas habilitar. Es por eso que TIBCO BW y EMS generalmente van juntos cuando se trata de una Plataforma de Integración adecuada.

El soporte JMS para TIBCO BW está listo para usar, pero como cualquier otra implementación de JMS, necesitas proporcionar las bibliotecas del cliente para establecer una conexión real.

Para hacer eso, desde TIBCO BW 6, se proporciona una forma sencilla para simplificar ese proceso, y esto es lo que vamos a cubrir en este artículo.

Descripción del problema

Lo primero es saber que necesitas hacer algo y lo más importante es aprender a entender qué tipo de error está relacionado con este problema. Podrías encontrar dos errores diferentes dependiendo de dónde estés probando esto: en tiempo de diseño o en tiempo de ejecución.

Si estamos hablando de un problema en tiempo de ejecución, puedes ver un rastro similar a este:

2022-06-02T13:27:15,867 ERROR [pool-13-thread-2] c.t.b.thor.runtime.model.Constituent - Se ha producido el siguiente error para "nombre: test-app versión: 1.0.0.qualifier nombre del paquete: test-app " que necesita ser resuelto.
2022-06-02T13:27:15,878 ERROR [pool-13-thread-2] c.t.b.thor.runtime.model.Constituent - TIBCO-BW-FRWK-600053: No se pudo inicializar el Componente BW [ComponentStarter].
<CausedBy> com.tibco.bw.core.runtime.api.BWEngineException: TIBCO-BW-CORE-500232: No se pudo inicializar el Componente BW [ComponentStarter], Aplicación [test-app:1.0] debido a un error de inicialización de actividad.
<CausedBy> com.tibco.bw.core.runtime.ActivityInitException: TIBCO-BW-CORE-500408: No se pudo inicializar la actividad ProcessStarter [JMSReceiveMessage] en el proceso [com.test.Starter], módulo [test-app] **debido a un error inesperado en el ciclo de vida de la actividad.**
**<CausedBy> java.lang.NullPointerException**

Cada vez que veas un java.lang.NullPointerException relacionado con una actividad de Recepción JMS, puedes estar seguro de que el problema está relacionado con la instalación de los controladores.

Si estamos hablando de tiempo de diseño, verás el mismo error cuando intentes iniciar una sesión de Ejecución o Depuración, pero adicionalmente verás el siguiente error cuando estés probando un Recurso de Conexión JMS, como puedes ver en la imagen a continuación:

Proceso de instalación

El proceso de instalación es bastante simple, pero necesitas acceso a una instalación de EMS o al menos una ubicación en disco con los clientes almacenados. Si ya tienes eso, solo necesitas ir a la siguiente ubicación:

 TIBCO_HOME/bw/<version>/bin

Donde TIBCO_HOME es la carpeta de instalación para la aplicación BusinessWorks, y version es el formato de versión menor (como 6.7, 2.7, 6.8, etc.).

En esta ubicación, ejecutarás el siguiente comando:

 ./bwinstall ems-driver

Esto comenzará y pedirá la ubicación de las bibliotecas del cliente, como puedes ver en la imagen a continuación:

Y después de eso, realizará el proceso de instalación y terminará con la salida BUILD SUCCESSFULL. Y después de ese punto, necesitarás reiniciar el Business Studio o los componentes de tiempo de ejecución (como AppNodes o bwagent) para que la configuración se aplique.

Grafana y LDAP: Aumenta la seguridad en menos de 5 minutos

2025-11-03 por Alexandre Vazquez

Este artículo cubrirá cómo integrar rápidamente Grafana y el servidor LDAP para aumentar la seguridad de su aplicación

Grafana es una de las herramientas de panel más utilizadas, principalmente para las plataformas de observabilidad en entornos de carga de trabajo en la nube. Pero ninguna de estas herramientas está completa hasta que pueda configurarlas para cumplir con sus estándares de seguridad. La seguridad se está volviendo cada vez más importante y esto es especialmente cierto cuando hablamos de cualquier componente relacionado con la nube. Por lo tanto, este tema siempre debe ser algo que cualquier arquitecto de la nube tenga en mente cuando esté definiendo o implementando cualquier pieza de software hoy en día.

Y en ese punto, la integración LDAP es una de las principales cosas que siempre necesitarás hacer. No conozco ninguna empresa, grande o pequeña, que permita el uso de cualquier herramienta con una interfaz gráfica de usuario si no está conectada al directorio corporativo.

Así que, veamos cómo podemos implementar esto con una herramienta popular como Grafana. En mi caso, voy a usar una versión en contenedor de Grafana, pero los pasos y cosas a hacer siguen siendo los mismos sin importar el modelo de implementación.

La tarea que vamos a realizar se basa en tres pasos:

Habilitar la configuración de LDAP
Configuración básica de LDAP
Configuración de mapeo de grupos

Lo primero que necesitamos modificar es el grafana.ini añadiendo el siguiente fragmento:

    [auth.ldap]
    enabled = true
    config_file = /etc/grafana/ldap.toml

Eso significa que estamos habilitando la autenticación basada en LDAP y estableciendo la ubicación del archivo de configuración de LDAP. Este ldap.toml tiene toda la configuración necesaria para el LDAP:

    [[servers]]
    host = "localhost"
    port = 389
    use_ssl = false
    start_tls = false
    ssl_skip_verify = false
  
    bind_dn = "XXXXXX-XXXXXXXXX"
    bind_password = "XXXXXX"
    
	search_filter = "(&(sAMAccountName=%s)(memberOf=ADMIN_GROUP))"
    search_base_dns = [DC=example,DC=org"]

  
    [servers.attributes]
    member_of = "member"
    email =  "mail"
    name = "givenName"
    surname = "sn"
    username = "sAMAccountName"

    [[servers.group_mappings]]
    group_dn = "*"
    org_role = "Admin"

La primera parte se refiere a la conexión principal. Estableceremos la ubicación del host y el puerto, el usuario administrador y la contraseña. Después de eso, necesitaremos una segunda sección que defina search_filter y search_base_dns para definir los usuarios que pueden acceder al sistema.

Finalmente, tenemos otra sección para definir el mapeo entre los atributos de LDAP y los atributos de Grafana para poder recopilar los datos del LDAP.

    [servers.attributes]
    member_of = "member"
    email =  "mail"
    name = "givenName"
    surname = "sn"
    username = "sAMAccountName"

Además, podemos definir los privilegios que los diferentes grupos permiten tener a los varios org_roles en Grafana, como puedes ver en el fragmento a continuación:

    [[servers.group_mappings]]
    group_dn = "*"
    org_role = "Admin"

Con todos esos cambios en su lugar, necesitas reiniciar el servidor de Grafana para ver toda esta configuración aplicada. Después de ese punto, puedes iniciar sesión usando las credenciales de LDAP como puedes ver en la imagen a continuación y ver todos los datos recuperados del servidor LDAP:

Usando el servidor admin por defecto, también puedes usar una nueva función para probar la configuración de LDAP usando la opción LDAP que puedes ver en la imagen a continuación:

Y luego puedes buscar un Usuario y verás cómo este usuario se desempeñará en el servidor de Grafana:

Verificar los atributos que se mapearán del servidor LDAP al servidor Grafana
También verificar el estado de actividad y el rol permitido a este usuario

Puedes ver un ejemplo en la imagen a continuación:

Espero que este artículo te ayude a mejorar la configuración de seguridad en tus instalaciones de Grafana para integrarse con el servidor LDAP. Si deseas ver más información sobre este y temas similares, te animo a que eches un vistazo a los enlaces que encontrarás debajo de estas oraciones.

Aprende ahora 2 maneras de configurar la reconexión de TIBCO BW EMS

2025-11-03 por Alexandre Vazquez

En este artículo vamos a cubrir cómo funciona la reconexión de TIBCO BW EMS y cómo puedes aplicarla en tu aplicación, así como los pros y contras de las diferentes opciones disponibles.

Uno de los principales problemas que todos hemos enfrentado al trabajar en una integración de TIBCO BW y EMS es la parte de la reconexión. Aunque esto es algo que necesitamos en ocasiones mínimas debido a la extrema fiabilidad del servidor TIBCO EMS, puede tener consecuencias graves si no lo tenemos bien configurado.

Pero antes de empezar a hablar sobre las opciones, necesitamos hacer una pequeña explicación de fondo para entender completamente la situación.

Normalmente, hay dos formas que podemos usar para conectar nuestra aplicación TIBCO BW a nuestro servidor TIBCO EMS: Directa y JNDI. Y basado en eso, esto cambiará cómo y dónde necesitamos configurar nuestras propiedades de reconexión.

TIBCO BW + EMS: Conexión Directa

Esto es, como suena, una conexión directa de la aplicación TIBCO BW al servidor EMS en sí, con el listener usado para enviar y recibir mensajes. No hay un componente en el medio, y puedes detectarlo porque en los Recursos de Conexión JMS, se mostrará como “Directo”, y la URL siempre será de la siguiente manera: tcp://servidor: puerto como puedes ver en la imagen a continuación:

TIBCO BW + EMS: Conexión JNDI

Esta es un tipo de conexión diferente, y tiene un componente central comparado con el enlace Directo, como puedes imaginar. En este escenario, en el momento de la conexión, la aplicación TIBCO BW realiza una primera conexión al servidor JNDI que está dentro del servidor TIBCO EMS y busca los detalles de la conexión basándose en una “Fábrica de Conexiones”. Esta fábrica de conexiones tendrá su URL de conexión y propiedades de conexión. La aplicación TIBCO BW recibirá esa información y comenzará a conectarse a ese servidor EMS.

Sabrás que estás usando una Conexión JNDI porque el Tipo de Fábrica de Conexiones ahora mostrará JNDI. Además, requerirás un nombre de recurso adicional, recurso JNDI, y tu URL de conexión será algo como esto tibjmsnaming://servidor:puerto.

Propiedades de Reconexión de TIBCO EMS

Diferentes propiedades gestionan el proceso de reconexión. Esas propiedades afectarán el comportamiento de la biblioteca cliente EMS que reside en la aplicación cliente, en este caso, la aplicación TIBCO BW. Las propiedades controlarán los siguientes aspectos: el número de intentos de conexión, intervalos de tiempo entre ellos y el tiempo de espera del intervalo para considerarlo un intento fallido.

Y tendrás cada una de estas propiedades para el proceso de reconexión y el proceso de conexión. La principal diferencia es que el proceso de conexión solo actuará cuando estés estableciendo una conexión por primera vez (al inicio de la aplicación TIBCO BW). Las configuraciones de reconexión se aplicarán cuando pierdas una conexión previamente establecida.

Las propiedades concretas son las siguientes:

tibco.tibjms.reconnect.attemptcount/tibco.tibjms.connect.attemptcount: Definirá el número de intentos que realizarás cuando se detecte un escenario de reconexión.
tibco.tibjms.reconnect.attemptdelay/tibco.tibjms.connect.attemptdelay: Definirá el intervalo de tiempo entre dos intentos de reconexión.
tibco.tibjms.reconnect.attempts/tibco.tibjms.connect.attempts: Servirá como una combinación de attemptcount y attemptdelay en una versión separada por comas.
tibco.tibjms.reconnect.attempt.timeout/tibco.tibjms.connect.attempt.timeout: Definirá el tiempo de espera para cada uno de los intentos de reconexión, y si se alcanza ese tiempo, la reconexión no se establece; se detectará como un intento fallido.

¿Dónde Configurar las Propiedades de Reconexión?

En el caso de que estemos hablando de una conexión Directa, estas propiedades deben especificarse en la aplicación TIBCO BW, y estas propiedades se establecerán como propiedades JVM.

Por lo tanto, dependiendo de tu modelo de implementación, estas propiedades deberán agregarse al archivo AppNode TRA o a las variables de entorno BW_JAVA_OPS si estamos hablando de una implementación en contenedores.

Por otro lado, si hablamos de una conexión JNDI, estas propiedades se establecerán a nivel de EMS como parte de las propiedades de reconexión de la Fábrica de Conexiones. Esto se puede hacer usando el componente CLI tibemsadmin, poniéndolo directamente en el archivo factories.conf, o incluso usando una herramienta gráfica como gEMS usando la sección de Fábricas para actualizar eso, como se muestra en la imagen a continuación:

Dependiendo del enfoque que sigas, las propiedades se aplicarán en tiempo de ejecución (enfoque gEMS o tibemsadmin) o en el próximo reinicio (factories.conf)

Pros y Contras

Hay diferentes pros y contras al usar un modo de conexión. Basado en las propiedades de reconexión, usar una forma centralizada como el modelo JNDI asegura que todos los componentes que usan esa conexión tendrán las mismas propiedades de reconexión. Si necesitas cambiarlo, no necesitas cambiar todas tus aplicaciones TIBCO BW. Eso puede ser un número de hasta cientos.

Pero, al mismo tiempo, el uso de una forma centralizada proporciona menos flexibilidad que la conexión directa donde puedes decidir los valores específicos para cada aplicación o incluso cuáles necesitan configuración de reconexión y cuáles no.

Supongamos que estás buscando simplicidad y facilidad de gestión. En ese caso, siempre optaré por la conexión basada en JNDI porque proporciona más beneficios en esos aspectos, y la falta de flexibilidad generalmente no se requiere en absoluto.

Módulos TIBCO BW: 3 cosas que necesitas saber para tener éxito

2025-11-03 por Alexandre Vazquez

Los módulos de TIBCO BW son uno de los contenidos más relevantes en tus desarrollos de TIBCO BW. Aprende todos los detalles sobre los diferentes módulos de TIBCO BW disponibles y cuándo usar cada uno de ellos.

TIBCO BW ha evolucionado de varias maneras y se ha adaptado a los últimos cambios de arquitectura. Debido a eso, desde la concepción de la última versión principal, ha introducido varios conceptos que es importante dominar para poder desatar todo el poder que esta notable herramienta te proporciona. Hoy vamos a hablar sobre los módulos.

Cada aplicación de TIBCO BW está compuesta por diferentes módulos que son los componentes que alojan toda la lógica que puedes crear, y eso es lo primero que hay que anotar: Todo tu código y todo lo que haces en tu aplicación pertenecerá a un módulo de TIBCO BW.

Si pensamos en la jerarquía normal de los componentes de TIBCO BW, será algo como la imagen a continuación:

En el nivel superior, tendremos la aplicación; en el segundo nivel, tendremos los módulos, y después de eso, tendremos los paquetes y finalmente, los componentes técnicos como Procesos, Recursos, Clases, Esquemas, Interfaces, etc. Aprende más sobre esto aquí.

Clasificación de Módulos de TIBCO BW

Hay varios tipos de módulos y cada uno de ellos proporciona un caso de uso específico y tiene algunas características asociadas con él.

Módulo de Aplicación: Es el tipo de módulo más importante porque sin él no puedes tener una aplicación. Es el módulo maestro y solo puede haber uno por aplicación. Es donde residirá toda tu lógica principal para esa aplicación.
Módulo Compartido: Es el otro único módulo nativo de BW y su propósito principal, como muestra el nombre, es alojar todo el código y componentes que pueden ser compartidos entre varias aplicaciones. Si tienes experiencia con versiones anteriores de TIBCO BW, puedes pensar en este módulo de TIBCO BW como un reemplazo de una Biblioteca de Tiempo de Diseño (también conocida como DTL) o si tienes experiencia con un lenguaje de programación, una biblioteca que se importa al código. Debido a eso, no tiene una restricción en el número de aplicaciones que pueden usar un módulo compartido y no hay limitación en el número de módulos compartidos que una aplicación de TIBCO BW puede tener.
Módulo OSGI: Este módulo es el que no es nativo de BW y no va a incluir objetos de BW como Procesos, Recursos, etc., y están principalmente concebidos para tener clases Java. Y nuevamente, es más como un módulo auxiliar que también puede ser compartido según sea necesario. Los escenarios habituales para usar este tipo de módulo son definir funciones XPath personalizadas, por ejemplo, o tener código Java compartido entre varias aplicaciones.

Tanto los módulos compartidos como los módulos OSGI pueden definirse como dependencias de Maven y usar el proceso de Maven para publicarlos en un repositorio de Maven y también para ser recuperados de él según la declaración.

Eso proporciona una forma muy eficiente para la distribución y control de versiones de estos componentes compartidos y, al mismo tiempo, ofrece un proceso similar para otros lenguajes de programación como Java, de modo que disminuirá la curva de aprendizaje para ese proceso.

Limitaciones de los Módulos de TIBCO BW

Como ya comentamos, hay algunas limitaciones o características especiales que cada módulo tiene. Debemos ser muy conscientes de ello para ayudarnos a distribuir adecuadamente nuestro código utilizando el tipo correcto de módulos.

Como se comentó, una aplicación solo puede tener un módulo de aplicación de TIBCO BW. Aunque técnicamente es posible tener el mismo módulo de aplicación de BW en más de una aplicación, eso no tiene sentido porque ambas aplicaciones serán las mismas ya que su código principal será el mismo.

Los módulos compartidos de TIBCO BW, por otro lado, no pueden tener componentes de inicio o procesos de activación como parte de su declaración y todos ellos deben residir en el módulo de aplicación de TIBCO BW.

Tanto el módulo de aplicación de TIBCO BW como el módulo compartido de TIBCO BW pueden tener código Java, pero por otro lado, el módulo OSGI puede solo tener código Java y ningún otro recurso de TIBCO BW.

Los módulos compartidos de TIBCO BW pueden exportarse de dos maneras diferentes, como módulos regulares (archivo ZIP con el código fuente) y en formato binario, para ser compartidos entre otros desarrolladores pero no permitiéndoles cambiar o cambiar su vista de los detalles de implementación. Esto todavía se admite por razones de legado, pero la forma recomendada hoy en día para distribuir el software es usando Maven, como se discutió anteriormente.

Casos de Uso de los Módulos de TIBCO BW

Como se comentó, hay diferentes casos de uso para cada uno de los módulos que debido a eso te ayudará a decidir qué componente funciona mejor para cada escenario:

Los módulos compartidos de TIBCO BW cubren todos los componentes estándar necesarios para todas las aplicaciones. Aquí, el caso de uso principal son los componentes del marco o patrones principales que simplifican el desarrollo y homogeneizan. Esto ayuda a controlar capacidades estándar como manejo de errores, auditoría, registro, o incluso comunicación interna, por lo que los desarrolladores solo necesitan centrarse en la lógica de negocio para su caso de uso.
Otro caso de uso para el módulo compartido de TIBCO BW encapsula cualquier cosa compartida entre aplicaciones, como recursos, para conectarse a un backend, por lo que todas las aplicaciones que necesitan conectarse a ese backend pueden importar y evitar la necesidad de rehacer esa parte.
El módulo OSGi es para tener código Java que tiene una relación débil con el código BW, como un componente para realizar una actividad como firmar un documento PDF o integrar con un elemento usando una API nativa de Java para que podamos mantenerlo y evolucionarlo separado del código de TIBCO BW.
Otro caso para el módulo OSGI es definir las funciones XPath personalizadas que necesitarás como parte de tu módulo compartido o tu módulo de aplicación.
El módulo de aplicación de TIBCO BW, por otro lado, solo debe tener código que sea específico para el problema de negocio que estamos resolviendo aquí, moviendo todo el código que pueda ser utilizado para más de una aplicación a un módulo compartido.

Aprende a Escribir Manifiestos YAML de Kubernetes de Manera Más Eficiente

2025-11-03 por Alexandre Vazquez

Aprende a Escribir Manifiestos YAML de Kubernetes de Manera Más Eficiente (Foto por Stillness InMotion en Unsplash)

Cuando todos estamos en este nuevo entorno nativo de la nube donde Kubernetes es el rey indiscutible, necesitas aprender a manejar los manifiestos YAML de Kubernetes todo el tiempo. Te convertirás en un experto en secciones de sangría para asegurarte de que esto pueda ser procesado, etc. Pero debemos admitir que es tedioso. Todos los beneficios del despliegue de Kubernetes hacen que el esfuerzo valga la pena, pero incluso con eso, es bastante complejo poder manejarlo.

Es cierto que, para simplificar esta situación, se han lanzado muchos proyectos, como Helm para gestionar plantillas de manifiestos YAML de Kubernetes relacionados o Kustomize diferentes enfoques para llegar al mismo lugar o incluso soluciones específicas para una distribución de Kubernetes como las Plantillas de Openshift. Pero al final, nada de esto puede resolver el problema a nivel primario. Así que necesitas escribir esos archivos manualmente tú mismo.

¿Y cuál es el proceso ahora? Probablemente estés siguiendo uno diferente, pero te contaré mi enfoque. Dependiendo de lo que estoy tratando de crear, trato de encontrar una plantilla disponible para el Manifiesto YAML de Kubernetes que quiero hacer. Esta plantilla puede ser algún recurso previo que ya he creado. Por lo tanto, uso eso como base, podría ser algo generado para alguna carga de trabajo que ya está desplegada (¡qué bueno que Lens ha existido para simplificar la gestión de cargas de trabajo de Kubernetes en ejecución! Si no conoces Lens, por favor echa un vistazo a este artículo) o si no tienes nada a mano, buscas en Google algo similar probablemente en la documentación de Kubernetes, stack overflow o el primer recurso razonable que Google te proporcione.

Y después de eso, el enfoque es el mismo. Vas a tu Editor de Texto, VS Code en mi caso. Tengo muchos plugins diferentes para hacer este proceso menos doloroso. Muchos linters diferentes validan la estructura del Manifiesto YAML de Kubernetes para asegurarse de que todo esté correctamente sangrado, que no haya etiquetas repetidas o que no falten etiquetas obligatorias en la última versión del recurso, etc.

Las cosas se complican un poco si estás creando un Helm Chart porque en ese caso los linters para YAML no funcionan tan bien y detectan algunos falsos positivos porque no entienden realmente la sintaxis de Helm. También completas tu configuración con algunos linters más para Helm, y eso es todo. Luchas error tras error y cambio tras cambio para tener tu deseado Manifiesto YAML de Kubernetes.

Pero, ¿debería haber una mejor manera de hacer eso? Sí, debería, y esto es lo que herramientas como Monokle intentan proporcionar una mejor experiencia de ese proceso. Veamos cómo funciona. Comenzando con las palabras de su contribuyente:

Monokle es tu amigable interfaz de usuario de escritorio para gestionar manifiestos de Kubernetes. Monokle te ayuda a obtener rápidamente una vista de alto nivel de tus manifiestos y sus recursos contenidos, editar recursos fácilmente sin tener que aprender la sintaxis yaml, comparar recursos con tu clúster, previsualizar y depurar recursos generados con kustomize o Helm, y más.

Monokle te ayuda de las siguientes maneras. En primer lugar, presenta al inicio de tu trabajo un conjunto de plantillas para crear tus Manifiestos YAML de Kubernetes, como puedes ver en la imagen a continuación:

Diálogo de Selección de Plantillas de Monokle

Cuando seleccionas una plantilla, puedes completar los valores requeridos gráficamente sin necesidad de escribir código YAML tú mismo, como puedes ver en la imagen a continuación:

Proceso de Población de Valores de Plantilla de Monokle

También admite el reconocimiento de recursos de Helm Chart y Kustomize, por lo que verás rápidamente tus gráficos, y puedes editarlos de una manera más moderna incluso gráficamente para algunos de los recursos también:

Modificación de Helm Chart usando Monokle

Permite una buena integración de varias maneras, en primer lugar con OPA para que pueda validar todas las reglas y mejores prácticas que has definido y también puedes conectarte a un clúster en ejecución para ver los recursos desde allí y también ver la diferencia entre ellos si existe para simplificar el proceso y proporcionar más agilidad en el proceso de creación de Manifiestos YAML de Kubernetes

Además de todo eso, Monokle es un componente certificado por la fundación CNCF, por lo que estarás utilizando un proyecto respaldado por la misma fundación que se encarga de Kubernetes en sí, entre otras tareas:

Monokle es parte del Paisaje de la Fundación CNCF

Si deseas descargar Monokle, pruébalo y puedes hacerlo desde su página web: https://monokle.kubeshop.io/ y estoy seguro de que tu rendimiento escribiendo Manifiestos YAML de Kubernetes te lo agradecerá pronto!

Grafana Loki y MinIO: ¡Una combinación perfecta!

2025-11-03 por Alexandre Vazquez

Grafana Loki y MinIO: ¡Una combinación perfecta!

Grafana Loki se está convirtiendo en uno de los estándares de facto para la agregación de logs en cargas de trabajo de Kubernetes hoy en día, y hoy vamos a mostrar cómo podemos usar juntos Grafana Loki y MinIO. Ya hemos cubierto en varias ocasiones las capacidades de Grafana Loki que han surgido como la principal alternativa al liderazgo de Elasticsearch en los últimos 5-10 años para la agregación de logs.

Con un enfoque diferente, más ligero, más nativo de la nube, más enfocado en las cosas buenas que Prometheus ha proporcionado pero para logs y con el patrocinio de una gran empresa como Grafana Labs con las herramientas de paneles como líder de un stack de herramientas cada día más enorme en el mundo de la observabilidad.

Y también, ya hemos cubierto MinIO como un almacén de objetos que se puede implementar en cualquier lugar. Es como tener tu servicio S3 en cualquier nube que te guste o en las instalaciones. Así que hoy, vamos a ver cómo ambos pueden trabajar juntos.

Grafana Loki principalmente admite tres modelos de implementación: monolítico, simple-escalable y distribuido. Prácticamente todo excepto el monolítico tiene el requisito de tener una solución de Almacenamiento de Objetos para poder trabajar en un modo escalable distribuido. Entonces, si tienes tu implementación en AWS, ya estás cubierto con S3. Además, Grafana Loki admite la mayoría de las soluciones de Almacenamiento de Objetos para el ecosistema en la nube de los principales proveedores. Aún así, el problema surge cuando deseas confiar en Grafana Loki para una instalación en la nube privada o en las instalaciones.

En ese caso, es donde podemos confiar en MinIO. Para ser honesto, puedes usar MinIO también en el mundo de la nube para tener una solución más flexible y transparente y evitar cualquier dependencia con un proveedor de nube. Aún así, para las instalaciones, su uso se ha vuelto obligatorio. Una de las grandes características de MinIO es que implementa la API de S3, por lo que prácticamente cualquier cosa que admita S3 funcionará con MinIO.

En este caso, solo necesito adaptar algunos valores en el gráfico de helm de Loki en el modo simple-distribuido como se muestra a continuación:

 loki:
  storage:
    s3:
      s3: null
      endpoint: http://minio.minio:9000
      region: null
      secretAccessKey: XXXXXXXXXXX
      accessKeyId: XXXXXXXXXX
      s3ForcePathStyle: true
      insecure: true

Simplemente estamos apuntando al endpoint de nuestro inquilino de MinIO, en nuestro caso, también implementado en Kubernetes en el puerto 9000. También estamos proporcionando las credenciales para conectar y finalmente mostrando que necesita s3ForcePathSyle: true es necesario para que el endpoint se transforme a minio.minio:9000/bucket en lugar de bucket.minio.minio:9000, por lo que funcionará mejor en un ecosistema de Kubernetes.

Y eso es prácticamente todo; tan pronto como lo inicies, comenzarás a ver que los buckets comienzan a poblarse como lo harían en caso de que estuvieras usando S3, como puedes ver en la imagen a continuación:

MinIO mostrando buckets y objetos de la configuración de Loki

Ya cubrimos los modelos de implementación de MinIO. Como se muestra aquí, puedes usar su gráfico de helm o el operador de MinIO. Pero, la integración con Loki es aún mejor porque los gráficos de helm de Loki ya incluyen MinIO como un sub-gráfico para que puedas implementar MinIO como parte de tu implementación de Loki basado en la configuración que encontrarás en el values.yml como se muestra a continuación:

 # -------------------------------------
# Configuración para el gráfico hijo `minio`
# -------------------------------------
minio:
  enabled: false
  accessKey: enterprise-logs
  secretKey: supersecret
  buckets:
    - name: chunks
      policy: none
      purge: false
    - name: ruler
      policy: none
      purge: false
    - name: admin
      policy: none
      purge: false
  persistence:
    size: 5Gi
  resources:
    requests:
      cpu: 100m
      memory: 128Mi

¡Así que con un solo comando, puedes tener ambas plataformas implementadas y configuradas automáticamente! Espero que esto sea tan útil para ti como lo fue para mí cuando descubrí e hice este proceso.

Potencia la agregación de registros en Kubernetes con BanzaiCloud Logging Operator

2025-11-03 por Alexandre Vazquez

Potenciar la Agregación de Logs en Kubernetes con BanzaiCloud Logging Operator (Foto por Markus Spiske en Unsplash)

Ya hemos hablado sobre la importancia de la Agregación de Logs en Kubernetes y por qué el cambio en el comportamiento de los componentes lo convierte en un requisito obligatorio para cualquier nueva arquitectura que implementemos hoy.

Para resolver esa parte, tenemos muchas pilas diferentes de las que probablemente hayas oído hablar. Por ejemplo, si seguimos el camino tradicional de Elasticsearch, tendremos la pila ELK pura de Elasticsearch, Logstash y Kibana. Ahora esta pila se ha ampliado con los diferentes «Beats» (FileBeat, NetworkBeat, …) que proporcionan un reenviador de logs ligero para ser añadido a la tarea.

Además, puedes cambiar Logstash por un componente de CNCF como Fluentd del que probablemente hayas oído hablar, y en ese caso, estamos hablando de una pila EFK siguiendo el mismo principio. Y también, tener la vista de Grafana Labs usando promtail, Grafana Loki, y Grafana para paneles de control siguiendo una perspectiva diferente.

Luego puedes cambiar y modificar cualquier componente por el de tu preferencia, pero al final, tendrás tres tipos diferentes de componentes:

Reenviador: Componente que escuchará todas las entradas de logs, principalmente la salida stdout/stderr de tus contenedores, y lo enviará a un componente central.
Agregador: Componente que recibirá todos los rastros del reenviador, y tendrá algunas reglas para filtrar algunos de los eventos, formatear y enriquecer los recibidos antes de enviarlos al almacenamiento central.
Almacenamiento: Componente que recibirá los rastros finales para ser almacenados y recuperados por los diferentes clientes.

Para simplificar la gestión de eso en Kubernetes, tenemos un gran Operador de Kubernetes llamado BanzaiCloud Logging Operator que intenta seguir ese enfoque de manera declarativa / política. Así que veamos cómo funciona, y para explicarlo mejor, usaré su diagrama central de su sitio web:

Arquitectura de BanzaiCloud Logging Operator

Este operador utiliza las mismas tecnologías de las que estábamos hablando. Cubre principalmente los dos primeros pasos: Reenvío y Agregación y la configuración para ser enviada a un Almacenamiento Central de tu elección. Para hacer eso, trabaja con las siguientes tecnologías, todas ellas parte del Paisaje CNCF:

Fluent-bit actuará como un reenviador desplegado en modo DaemonSet para recopilar todos los logs que hayas configurado.
Fluentd actuará como un agregador definiendo los flujos y reglas de tu elección para adaptar el flujo de rastros que estás recibiendo y enviando a la salida de tu elección.

Y como este es un Operador de Kubernetes, esto funciona de manera declarativa. Definiremos un conjunto de objetos que definirán nuestras políticas de registro. Tenemos los siguientes componentes:

logging – El recurso de logging define la infraestructura de registro para tu clúster que recopila y transporta tus mensajes de log. También contiene configuraciones para Fluentd y Fluent-bit.
output / clusteroutput – Define una Salida para un flujo de registro, donde se envían los mensajes de log. output será basado en el espacio de nombres, y clusteroutput será basado en el clúster.
flow / clusterflow – Define un flujo de registro usando filtros y salidas. El flujo dirige los mensajes de log seleccionados a las salidas especificadas. flow será basado en el espacio de nombres, y clusterflows será basado en el clúster.

En la imagen a continuación, verás cómo estos objetos están «interactuando» para definir tu arquitectura de registro deseada:

Relación CRD de BanzaiCloud Logging Operator

Y aparte del modo de política, también incluye muchas características geniales como:

Aislamiento de espacio de nombres
Selectores de etiquetas nativos de Kubernetes
Comunicación segura (TLS)
Validación de configuración
Soporte para múltiples flujos (multiplicar logs para diferentes transformaciones)
Soporte para múltiples salidas (almacenar los mismos logs en múltiples almacenamientos: S3, GCS, ES, Loki, y más…)
Soporte para múltiples sistemas de registro (múltiples despliegues de Fluentd, Fluent Bit en el mismo clúster)

En próximos artículos hablaremos sobre cómo podemos implementar esto para que puedas ver todos los beneficios que este enfoque basado en CRD y políticas puede proporcionar a tu arquitectura.