KubeEye te apoya en la tarea de asegurar que tu clúster esté funcionando bien y asegurar que se sigan todas tus mejores prácticas.
Kubernetes se ha convertido en la nueva norma para desplegar nuestras aplicaciones y otras opciones sin servidor, por lo que la administración de estos clústeres se ha vuelto crítica para la mayoría de las empresas, y realizar una Verificación de Salud de Kubernetes adecuada se está volviendo crítico.
Esta tarea está clara que no es una tarea fácil. Como siempre, la flexibilidad y el poder que la tecnología proporciona a los usuarios (en este caso, los desarrolladores) también viene con una compensación con la complejidad de la operación y gestión. Y esto no es una excepción a eso.
Hemos evolucionado, incluyendo opciones gestionadas que simplifican toda la configuración subyacente y la gestión de bajo nivel de la infraestructura detrás de ella. Sin embargo, hay muchas cosas que deben hacerse para que la administración del clúster tenga una experiencia feliz en el viaje de un Administrador de Kubernetes.
Muchos conceptos con los que lidiar: namespaces, límites de recursos, cuotas, ingreso, servicios, rutas, crd… Cualquier ayuda que podamos obtener es bienvenida. Y con este propósito en mente, KubeEye ha nacido.
GitHub – kubesphere/kubeeye: KubeEye aims to find various problems on Kubernetes, such as application misconfiguration, unhealthy cluster components and node problems.
KubeEye aims to find various problems on Kubernetes, such as application misconfiguration, unhealthy cluster components and node problems. – GitHub – kubesphere/kubeeye: KubeEye aims to find variou…
KubeEye es un proyecto de código abierto que ayuda a identificar algunos problemas en nuestros Clústeres de Kubernetes. Usando las palabras de sus creadores:
KubeEye tiene como objetivo encontrar varios problemas en Kubernetes, como la mala configuración de aplicaciones (usando Polaris), componentes de clúster no saludables y problemas de nodos (usando Node-Problem-Detector). Además de las reglas predefinidas, también admite reglas definidas por el usuario.
Así que podemos pensar en él como un compañero que está revisando el entorno para asegurarse de que todo esté bien configurado y saludable. Además, nos permite definir reglas personalizadas para asegurarnos de que todas las acciones que los diferentes equipos de desarrollo están realizando estén de acuerdo con los estándares predefinidos y las mejores prácticas.
Así que veamos cómo podemos incluir KubeEye para hacer una verificación de salud de nuestro entorno. Lo primero que necesitamos hacer es instalarlo. En este momento, KubeEye solo ofrece una versión para sistemas basados en Linux, por lo que si estás usando otros sistemas como yo, necesitas seguir otro enfoque y escribir los siguientes comandos:
Después de hacer eso, terminamos con un nuevo binario en nuestro PATH llamado `ke`, y este es el único componente necesario para trabajar con la aplicación. El segundo paso que necesitamos hacer para obtener más detalles sobre esos diagnósticos es instalar el componente detector de problemas de nodos.
Este componente es un componente instalado en cada nodo del clúster. Ayuda a hacer más visibles para las capas superiores los problemas relacionados con el comportamiento del clúster de Kubernetes. Este es un paso opcional, pero proporcionará datos más significativos, y para instalarlo, necesitamos ejecutar el siguiente comando.
ke install npd
Y ahora estamos listos para comenzar a verificar nuestro entorno, y el orden es tan fácil como este.
ke diag
Esto proporcionará una salida similar a esta que se compone de dos tablas diferentes. La primera se centrará en el Pod y los problemas y eventos planteados como parte del estado de la plataforma, y la otra se centrará en el resto de los elementos y tipos de objetos para los Clústeres de Kubernetes.
Salida del comando ke diag
La tabla para los problemas a nivel de pod tiene los siguientes campos:
Namespace al que pertenece el pod.
Severidad del problema.
Nombre del Pod que es responsable del problema
Hora del Evento en la que se ha planteado este evento
Razón del problema
Mensaje con la descripción detallada del problema
La segunda tabla para los otros objetos tiene la siguiente estructura:
Namespace donde se despliega el objeto que tiene un problema que está siendo detectado.
Severidad del problema.
Nombre del componente
Tipo del componente
Hora en la que se ha planteado este problema
Mensaje con la descripción detallada del problema
La salida del comando también puede mostrar otras tablas si se detectan algunos problemas a nivel de nodo.
Hoy cubrimos un tema fascinante como es la Administración de Kubernetes e introducimos una nueva herramienta que ayuda en tu tarea diaria.
¡Realmente espero que esta herramienta pueda ser añadida a tu caja de herramientas y facilite el camino para una administración feliz y saludable del Clúster de Kubernetes!
La Seguridad en el Desarrollo es uno de los grandes temas de la práctica de desarrollo actual. Todas las mejoras que obtuvimos siguiendo las prácticas de DevOps han generado muchos problemas y preocupaciones desde la perspectiva de la seguridad.
La explosión de componentes con los que los equipos de seguridad necesitan lidiar, los enfoques de contenedores y los entornos poliglotas nos han dado muchos beneficios desde la perspectiva del desarrollo y la operativa. Sin embargo, ha hecho que el lado de la seguridad sea más complejo.
Es por eso que ha habido muchos movimientos respecto al enfoque de «Shift left» e incluir la seguridad como parte del proceso de DevOps, creando el nuevo término DevSecOps que se está convirtiendo en la nueva normalidad.
DevOps tech: Shifting left on security | Google Cloud
Security is everyone’s responsibility. The 2016 State of DevOps Report (PDF) research shows that high-performing teams spend 50 percent less time remediating security issues than low-performing teams. By better integrating information security (InfoSec) objectives into daily work, teams can achieve…
Entonces, hoy lo que me gustaría traerte es un conjunto de herramientas que acabo de descubrir que están creadas con el enfoque de hacer tu vida más fácil desde la perspectiva de la seguridad en el desarrollo porque los desarrolladores también necesitan ser parte de esto y no dejar toda la responsabilidad a un equipo diferente.
Este conjunto de herramientas se llama Anchore Toolbox, y son de código abierto y de uso gratuito, como puedes ver en la página web oficial (https://anchore.com/opensource/)
Entonces, ¿qué puede proporcionarnos Anchore? Por el momento, estamos hablando de dos aplicaciones diferentes: Syft y Grype.
Syft
GitHub – anchore/syft: CLI tool and library for generating a Software Bill of Materials from container images and filesystems
CLI tool and library for generating a Software Bill of Materials from container images and filesystems – GitHub – anchore/syft: CLI tool and library for generating a Software Bill of Materials from…
Syft es una herramienta CLI y biblioteca go para generar una Lista de Materiales de Software (SBOM) a partir de imágenes de contenedores y sistemas de archivos. La instalación es tan fácil como ejecutar el siguiente comando:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
Y después de hacer eso, necesitamos escribir syft para ver todas las opciones a nuestra disposición:
Menú de ayuda de Syft con todas las opciones disponibles
Entonces, en nuestro caso, lo usaré para generar una lista de materiales a partir de una imagen Docker existente de bitnami/kafka para mostrar cómo funciona esto. Necesito escribir el siguiente comando:
syft bitnami/kafka
Y después de unos segundos para cargar y analizar la imagen, obtengo como salida la lista de todos y cada uno de los paquetes que esta imagen tiene instalados y la versión de cada uno de ellos como se muestra en la imagen a continuación. Una gran cosa es que muestra no solo los paquetes del sistema operativo como lo que hemos instalado usando apk o apt, sino también otros componentes como bibliotecas java, por lo que podemos tener una lista completa de materiales para esta imagen de contenedor.
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-javadoc.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-javadoc.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/scala-java8-compat_2.12–0.9.1.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/scala-java8-compat_2.12–0.9.1.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-test-sources.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-test-sources.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/jackson-module-scala_2.12–2.10.5.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/jackson-module-scala_2.12–2.10.5.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka-streams-scala_2.12–2.7.0.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka-streams-scala_2.12–2.7.0.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-test.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-test.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/scala-collection-compat_2.12–2.2.0.jar’
[0019] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/scala-collection-compat_2.12–2.2.0.jar’
[0020] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0.jar’
[0020] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0.jar’
[0020] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-sources.jar’
[0020] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/kafka_2.12–2.7.0-sources.jar’
[0020] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/scala-logging_2.12–3.9.2.jar’
[0020] WARN coincidencias inesperadamente vacías para el archivo ‘/opt/bitnami/kafka/libs/scala-logging_2.12–3.9.2.jar’
NOMBRE VERSIÓN TIPO
java-archive
acl 2.2.53–4 deb
activation 1.1.1 java-archive
adduser 3.118 deb
aopalliance-repackaged 2.6.1 java-archive
apt 1.8.2.2 deb
argparse4j 0.7.0 java-archive
audience-annotations 0.5.0 java-archive
base-files 10.3+deb10u8 deb
base-passwd 3.5.46 deb
bash 5.0–4 deb
bsdutils 1:2.33.1–0.1 deb
ca-certificates 20200601~deb10u2 deb
com.fasterxml.jackson.module.jackson.module.scala java-archive
commons-cli 1.4 java-archive
commons-lang3 3.8.1 java-archive
...
Grype
GitHub – anchore/grype: A vulnerability scanner for container images and filesystems
A vulnerability scanner for container images and filesystems – GitHub – anchore/grype: A vulnerability scanner for container images and filesystems
Grype es un escáner de vulnerabilidades para imágenes de contenedores y sistemas de archivos. Es el siguiente paso porque verifica los componentes de la imagen y comprueba si hay alguna vulnerabilidad conocida.
Para instalar este componente nuevamente es tan fácil como escribir el siguiente comando:
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Después de hacer eso, necesitamos escribir grype para tener el menú de ayuda con todas las opciones a nuestra disposición:
Menú de ayuda de Grype con todas las opciones disponibles
Grype funciona de la siguiente manera. Lo primero que hace es cargar la base de datos de vulnerabilidades para verificar los diferentes paquetes contra esta base de datos en busca de cualquier vulnerabilidad conocida. Después de hacer eso, sigue el mismo patrón que syft y genera la lista de materiales y verifica cada uno de los componentes en la base de datos de vulnerabilidades, y si hay una coincidencia. Simplemente proporciona el ID de la vulnerabilidad, la gravedad y, si esto se soluciona en una versión superior, proporciona la versión donde se ha solucionado esta vulnerabilidad.
Aquí puedes ver la salida respecto a la misma imagen de bitnami/kafka con todas las vulnerabilidades detectadas
grype bitnami/kafka
✔ Base de datos de vulnerabilidades [actualizada]
✔ Imagen cargada
✔ Imagen analizada
✔ Imagen catalogada [204 paquetes]
✔ Imagen escaneada [149 vulnerabilidades]
[0018] ERROR el emparejador falló para pkg=Pkg(type=java-archive, name=, version=): el emparejador falló al buscar por CPE pkg=’’: se requiere el nombre del producto
[0018] ERROR el emparejador falló para pkg=Pkg(type=java-archive, name=, version=): el emparejador falló al buscar por CPE pkg=’’: se requiere el nombre del producto
[0018] ERROR el emparejador falló para pkg=Pkg(type=java-archive, name=, version=): el emparejador falló al buscar por CPE pkg=’’: se requiere el nombre del producto
[0018] ERROR el emparejador falló para pkg=Pkg(type=java-archive, name=, version=): el emparejador falló al buscar por CPE pkg=’’: se requiere el nombre del producto
[0018] ERROR el emparejador falló para pkg=Pkg(type=java-archive, name=, version=): el emparejador falló al buscar por CPE pkg=’’: se requiere el nombre del producto
[0018] ERROR el emparejador falló para pkg=Pkg(type=java-archive, name=, version=): el emparejador falló al buscar por CPE pkg=’’: se requiere el nombre del producto
NOMBRE INSTALADO CORREGIDO-EN VULNERABILIDAD GRAVEDAD
apt 1.8.2.2 CVE-2011–3374 Insignificante
bash 5.0–4 CVE-2019–18276 Insignificante
commons-lang3 3.8.1 CVE-2013–1907 Media
commons-lang3 3.8.1 CVE-2013–1908 Media
coreutils 8.30–3 CVE-2016–2781 Baja
coreutils 8.30–3 CVE-2017–18018 Insignificante
curl 7.64.0–4+deb10u1 CVE-2020–8169 Media
..
Resumen
Estas simples herramientas CLI nos ayudan mucho en el necesario camino para mantener nuestro software actualizado y libre de vulnerabilidades conocidas y mejorar nuestra seguridad en el desarrollo. Además, como estas son aplicaciones CLI y también pueden ejecutarse en contenedores, es muy fácil incluirlas como parte de tu pipeline CICD para que las vulnerabilidades se puedan verificar de manera automatizada.
También proporcionaron un complemento para ser incluido en los sistemas CI/CD más utilizados, como Jenkins, Cloudbees, CircleCI, GitHub Actions, Bitbucket, Azure DevOps, y así sucesivamente.
Conocer la configuración de TIBCO BW en tiempo de ejecución se ha vuelto crítico ya que siempre necesitas saber si los últimos cambios se han aplicado o simplemente quieres verificar el valor específico de una Propiedad del Módulo como parte de tu desarrollo.
Cuando hablamos de aplicaciones desplegadas en la nube, una de las cosas clave es la Gestión de Configuración. Especialmente si incluimos en la mezcla cosas como Kubernetes, Contenedores, Sistema de Gestión de Configuración Externa, las cosas se complican.
La configuración habitual cuando hablamos de un entorno Kubernetes para la gestión de configuración es el uso de Config Maps o Spring Cloud Config.
Cuando puedes cargar la configuración en un paso separado al de desplegar la aplicación, puedes encontrarte en una situación en la que no estás seguro de cuál es la configuración en ejecución que tiene una aplicación BusinessWorks.
Para verificar la configuración de TIBCO BW hay una manera fácil de saber exactamente los valores actuales:
Solo necesitamos entrar en el contenedor para poder acceder a la consola interna de OSGI que nos permite ejecutar comandos administrativos.
Hemos hablado otras veces sobre esa API, pero en caso de que quieras echar un vistazo más profundo solo necesitas revisar este enlace:
Y uno de los comandos es lcfg que permite saber qué configuración está siendo utilizada por la aplicación que está en ejecución:
Salida de ejemplo para el comando lcfg de una Aplicación de Contenedor BusinessWorks en Ejecución
Resumen
Espero que encuentres esto interesante, y si eres uno de los que enfrenta este problema ahora, tienes información para no ser detenido por este. Si deseas enviar tus preguntas, siéntete libre de usar una de las siguientes opciones:
Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQs que monitorearé.
Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
Instagram: Puedes enviarme un DM en Instagram a @alexandrev
Descubre las propiedades que te permitirán un uso optimizado de tu almacenamiento en disco y ahorros al almacenar tus datos de monitoreo
Prometheus se ha convertido en un componente estándar en nuestras arquitecturas en la nube y el almacenamiento de Prometheus se está convirtiendo en un aspecto crítico. Así que voy a suponer que si estás leyendo esto ya sabes qué es Prometheus. Si este no es el caso, por favor tómate tu tiempo para echar un vistazo a otros artículos que he creado:
Prometheus Monitoring for Microservices using TIBCO
We’re living a world with constant changes and this is even more true in the Enterprise Application world. I’ll not spend much time talking about things you already know, but just say that the microservices architecture approach and the PaaS solutions have been a game-changer for all enterprise integration technologies. This time I’d like to […]
Kubernetes Service Discovery for Prometheus
In previous posts, we described how to set up Prometheus to work with your TIBCO BusinessWorks Container Edition apps, and you can read more about it here. In that post, we described that there were several ways to update Prometheus about the services that ready to monitor. And we choose the most simple at that […]
Sabemos que usualmente cuando monitoreamos usando Prometheus tenemos tantos exportadores disponibles a nuestra disposición y también que cada uno de ellos expone muchas métricas muy relevantes que necesitamos para rastrear todo lo que necesitamos y que lleva a un uso muy intensivo del almacenamiento disponible si no lo gestionamos adecuadamente.
Hay dos factores que afectan esto. El primero es optimizar el número de métricas que estamos almacenando y ya proporcionamos consejos para hacerlo en otros artículos como los que se muestran a continuación:
How it optimize the disk usage in the Prometheus database?
Learn some tricks to analyze and optimize the usage that you are doing of the TSDB and save money on your cloud deployment. Photo by Markus Spiske on Unsplash In previous posts, we discussed how the storage layer worked for Prometheus and how effective it was. But in the current times, we are of cloud computing […]
El otro es cuánto tiempo almacenamos las métricas llamado el “período de retención en Prometheus.” Y esta propiedad ha sufrido muchos cambios durante las diferentes versiones. Si te gustaría ver toda la historia, por favor echa un vistazo a este artículo de Robust Perception:
How can you control how much history Prometheus keeps?
Las principales propiedades que puedes configurar son las siguientes:
storage.tsdb.retention.time: Número de días para almacenar las métricas por defecto a 15d. Esta propiedad reemplaza la obsoleta storage.tsdb.retention.
storage.tsdb.retention.size: Puedes especificar el límite de tamaño a utilizar. Este no es un límite estricto sino un mínimo, así que por favor define algún margen aquí. Unidades soportadas: B, KB, MB, GB, TB, PB, EB. Ej: “512MB”. Esta propiedad es experimental hasta ahora como puedes ver en la documentación oficial:
¿Qué tal configurar esta configuración en el operador para Kubernetes? En ese caso, también tienes opciones similares disponibles en el archivo de configuración values.yaml para el chart como puedes ver en la imagen a continuación:
values.yml para el Helm Chart del Operador de Prometheus
Esto debería ayudarte a obtener un despliegue optimizado de Prometheus que asegure todas las características que tiene Prometheus pero al mismo tiempo un uso óptimo de los recursos a tu disposición.
Además de eso, también deberías revisar las opciones de Servicio Gestionado que algunos proveedores tienen respecto a Prometheus, como los Servicios Gestionados de Amazon para Prometheus, como puedes ver en el enlace a continuación:
Amazon Prometheus Service to Provide More Availability to Your Monitoring Solution
Learn what Amazon Managed Service for Prometheus provides and how you can benefit from it. Photo by Casey Horner on Unsplash Monitoring is one of the hot topics when we talk about cloud-native architectures. Prometheus is a graduated Cloud Native Computing Foundation (CNCF) open-source project and one of the industry-standard solutions when it comes to monitoring your […]
Aprende sobre el nuevo sistema de agregación de logs escalable horizontalmente, altamente disponible y multi-inquilino inspirado en Prometheus que puede ser la mejor opción para tu arquitectura de registro
Loki vs ELK es algo que estás leyendo y escuchando cada vez más a menudo ya que desde hace algún tiempo hay un aumento en la disputa por convertirse en el estándar de facto para las arquitecturas de agregación de logs.
Cuando hablamos de Arquitectura Nativa de la Nube, la agregación de logs es algo clave que necesitas considerar. Las viejas prácticas que seguimos en el enfoque de máquinas virtuales on-premises para el registro ya no son válidas.
Ya cubrimos este tema en mi publicación anterior que te recomiendo echar un vistazo en caso de que no la hayas leído aún, pero este no es el tema de hoy.
Three reasons why you need a Log Aggregation Architecture today
Log Aggregation are not more a commodity but a critical component in container-based platforms Photo by Olav Ahrens Røtne on Unsplash Log Management doesn’t seem like a very fantastic topic. It is not the topic that you see and says: “Oh! Amazing! This is what I was dreaming about my whole life”. No, I’m aware that […]
Elasticsearch como el núcleo y las diferentes pilas derivadas como ELK/EFK han ganado popularidad en los últimos años, siendo prácticamente la opción predeterminada de código abierto cuando hablamos de agregación de logs y una de las opciones. Los principales proveedores de nube pública también han adoptado esta solución como parte de su propia oferta, como lo proporciona el Servicio de Elasticsearch de Amazon.
Pero Elasticsearch no es perfecto. Si ya lo has usado, probablemente lo sepas. Aún así, debido a que sus características son tan impresionantes, especialmente en las capacidades de búsqueda e indexación, ha sido el tipo de líder hoy en día. Pero otros temas como el uso del almacenamiento, la cantidad de poder que necesitas para manejarlo y la arquitectura con diferentes tipos de nodos (maestro, datos, ingestor) aumentan su complejidad para casos cuando necesitamos algo más pequeño.
Y para llenar este vacío es donde llega nuestro personaje principal para la publicación de hoy: Loki o Grafana Loki.
Loki es un sistema de gestión de logs creado como parte del proyecto Grafana, y ha sido creado con un enfoque diferente en mente que Elasticsearch.
Loki es un sistema de agregación de logs escalable horizontalmente, altamente disponible y multi-inquilino inspirado en Prometheus. Está diseñado para ser muy rentable y fácil de operar. No indexa el contenido de los logs, sino un conjunto de etiquetas para cada flujo de logs.
Así que, como podemos leer en la definición de su propia página arriba, cubre varios temas interesantes en comparación con Elasticsearch:
En primer lugar, aborda algunos de los puntos de dolor habituales para los clientes de ELK: Es muy rentable y fácil de operar.
Claramente dice que el enfoque no es el mismo que ELK, no vas a tener un índice completo de la carga útil para los eventos, sino que se basa en diferentes etiquetas que puedes definir para cada flujo de logs.
Prometheus inspira eso, lo cual es crítico porque permitió la idea de usar trazas de logs como métricas para potenciar nuestras soluciones de monitoreo.
Comencemos con las preguntas iniciales cuando mostramos una nueva tecnología interesante y nos gustaría comenzar a probarla.
¿Cómo puedo instalar Loki?
Loki se distribuye en diferentes versiones para ser instalado en tu entorno de la manera que lo necesites.
SaaS: proporcionado como parte de la solución de alojamiento de Grafana Cloud.
On-Premises: Proporcionado como un binario normal para descargar y ejecutar en modo on-premises.
Nube: Proporcionado como una imagen de Docker o incluso un Helm Chart para ser desplegado en tu entorno basado en Kubernetes.
Los equipos de GrafanaLabs también proporcionan Soporte Empresarial para Loki si deseas usarlo en modo de producción en tu empresa. Aún así, al mismo tiempo, todo el código está licenciado usando la Licencia Apache 2.0, por lo que puedes echar un vistazo a todo el código y contribuir a él.
En cuanto a la arquitectura, es muy similar a la pila ELK/EFK y sigue el mismo enfoque de “coleccionistas” e “indexadores” como tiene ELK:
Loki en sí mismo es el nodo central de la arquitectura responsable de almacenar las trazas de logs y sus etiquetas y proporciona una API para buscar entre ellas basándose en su propio lenguaje LogQL (un enfoque similar al PromQL de Prometheus).
promtail es el componente agente que se ejecuta en el borde obteniendo todas esas trazas de logs que necesitamos que pueden estar ejecutándose en una máquina on-prem o en un modo DaemonSet en nuestro propio clúster de Kubernetes. Desempeña el mismo papel que Logstash/Fluent-bit/Fluentd en la pila ELK/EFK. Promtail proporciona el modo de plugin habitual para filtrar y transformar nuestras trazas de logs como lo hacen las otras soluciones. Al mismo tiempo, proporciona una característica interesante para convertir esas trazas de logs en métricas de Prometheus que pueden ser recolectadas directamente por tu servidor Prometheus.
Grafana es la interfaz de usuario para toda la pila y desempeña un papel similar al de Kibana en la pila ELK/EFK. Grafana, entre otros plugins, proporciona integración directa con Loki como una fuente de datos para explorar esas trazas e incluirlas en los paneles.
Resumen
Grafana Loki puede ser una gran solución para tu arquitectura de registro para cubrir dos puntos: Proporcionar una solución de agregación de logs ligera para tu entorno y al mismo tiempo habilitar tus trazas de logs como una fuente para tus métricas, permitiéndote crear métricas detalladas, más orientadas al negocio que se utilizan en tus paneles y tus sistemas de monitoreo.
Descubre SARChart y kSAR como utilidades críticas para ser parte de tu cinturón de herramientas para administración o resolución de problemas
Hubo un tiempo en que no teníamos proveedores de nube pública que nos proporcionaran una variedad de tipos de servicios y toda una plataforma y experiencia unificada, cubriendo todos los aspectos de nuestras necesidades técnicas cuando hablábamos de un entorno de TI y las métricas de sysstat eran clave allí.
Hubo un tiempo en que AWS Cloud Watch, Azure Monitor, Prometheus no existían, y necesitábamos lidiar con servidores Linux sin un portal completo que proporcionara todas las métricas que podríamos necesitar.
Hubo un tiempo… que todavía es el presente para muchos clientes y organizaciones en todo el mundo y aún necesitan lidiar con esta situación, y probablemente te enfrentes a esta situación ahora o incluso en el futuro. Así que, veamos qué podemos hacer al respecto.
Presentando sysstat
Durante varias décadas, la forma estándar de extraer las métricas de uso de un servidor Linux fue sysstat. Basado en las palabras de su página web oficial, esto es lo que es sysstat:
Las utilidades sysstat son una colección de herramientas de monitoreo de rendimiento para Linux. Estas incluyen sar, sadf, mpstat, iostat, tapestat, pidstat, cifsiostat y herramientas sa
Sysstat es un software antiguo pero confiable que su propietario continúa actualizando incluso hoy… pero manteniendo la misma página web desde el principio 🙂
Sysstat es antiguo pero poderoso, y tiene tantas opciones que me han salvado la vida con muchos clientes y proporcionado mucha información útil que necesitaba en ese momento. Pero hoy, voy a hablar sobre una utilidad específica de todo el conjunto, que es sar.
sar es el comando para poder consultar las métricas de rendimiento de una máquina existente. Simplemente escribiendo el comando sar es suficiente para comenzar a ver cosas impresionantes. Eso te dará las métricas de CPU para todo el día para cada una de las CPUs que tiene tu máquina y también se dividirá dependiendo del tipo de uso (usuario, sistema, inactivo, todo).
Ejecución del comando sar en una máquina local
Pero estas métricas no son lo único que puedes obtener. Otras opciones disponibles
sar -r: Proporciona métricas de memoria
sar -q: Proporciona las métricas de carga.
sar -n: Proporciona las métricas de red.
sar -A: Proporciona TODAS las métricas.
sar -f /var/log/sysstat/sa[día-del-mes]: Proporcionará métricas para el día del mes en lugar del día actual.
Hay muchas más opciones que puedes usar en tu día a día, así que si necesitas algo concreto, echa un vistazo a la página del manual para el comando sar:
sar(1) – Linux man page
The sar command writes to standard output the contents of selected cumulative activity counters in the operating system. The accounting system, based on …
Pero todos somos personas visuales, ¿verdad? Es cierto que ver tendencias y evoluciones es más complejo en modo texto y también ver solo datos diarios a la vez. Así que echa un vistazo a las opciones para manejar ese desafío:
Frontend desarrollado en Java usando la biblioteca Swing para representar visualmente los datos de sar. Es portátil, por lo que necesitas el archivo JAR para ejecutarlo. Y puedes invocarlo de varias maneras:
Proporcionando el archivo que obtuviste de una máquina en la que ejecutaste el comando sar.
Conectando mediante SSH a una máquina remota y ejecutando el comando que necesitas.
Visualización gráfica de las métricas de sar usando kSAR
SARChart
¿Qué pasa cuando estás en una máquina en la que no tienes los derechos para instalar ninguna aplicación, incluso una portátil como kSAR, o tal vez solo tienes tu tableta disponible? En ese caso, tenemos SARChart.
SARChart es una aplicación web que proporciona un análisis gráfico de los archivos sar. Así que solo necesitas subir el archivo para obtener un análisis gráfico completo y bien presentado de tus datos cubriendo todos sus aspectos. Además, todo el trabajo se realiza a nivel del cliente sin enviar ninguno de tus datos a ningún servidor.
Análisis de uso de CPU proporcionado por SARChart
Resumen
Espero que encuentres estas herramientas interesantes si no las conocías, y también espero que puedan ayudarte con tu trabajo diario o al menos ser parte de tu conjunto de herramientas para estar a tu disposición cuando las necesites.
El servicio Mesh Linkerd patrocinado por CNCF proporciona muchas características necesarias en las arquitecturas de microservicios actuales.
Si estás leyendo esto, probablemente ya estés al tanto de los desafíos que vienen con una arquitectura de microservicios. Podría ser porque estás leyendo sobre ellos o incluso porque los estás enfrentando ahora mismo en tu propia piel.
Uno de los desafíos más comunes es la red y la comunicación. Con la eclosión de muchos componentes que necesitan comunicación y el enfoque efímero de los desarrollos nativos de la nube, muchas características nuevas son una necesidad cuando en el pasado eran solo un «agradable de tener».
Conceptos como el registro de servicios y el descubrimiento de servicios, la autenticación de servicios, las políticas de enrutamiento dinámico y los patrones de disyuntor ya no son cosas que todas las empresas geniales están haciendo, sino algo básico para dominar la nueva arquitectura de microservicios como parte de una plataforma de arquitectura nativa de la nube, y aquí es donde el proyecto Service Mesh está aumentando su popularidad como una solución para la mayoría de estos desafíos y proporcionando estas características que se necesitan.
Si recuerdas, hace mucho tiempo, ya cubrí ese tema para presentar Istio como una de las opciones que tenemos:
Integrating Istio with BWCE Applications
Introduction Services Mesh is one the “greatest new thing” in our PaaS environments. No matter if you’re working with K8S, Docker Swarm, pure-cloud with EKS or AWS, you’ve heard and probably tried to know how can be used this new thing that has so many advantages because it provides a lot of options in handling […]
Pero este proyecto creado por Google e IBM no es la única opción que tienes para proporcionar esas capacidades. Como parte de la Cloud Native Computing Foundation (CNCF), el proyecto Linkerd proporciona características similares.
Cómo instalar Linkerd
Para comenzar a usar Linkerd, lo primero que necesitamos hacer es instalar el software y para hacerlo. Necesitamos hacer dos instalaciones, una en el servidor de Kubernetes y otra en el host.
Para instalar en el host, necesitas ir a la página de lanzamientos y descargar la edición para tu sistema operativo e instalarla.
Estoy usando un sistema basado en Windows en mi ejemplo, así que uso chocolatey para instalar el cliente. Después de hacerlo, puedo ver la versión del CLI escribiendo el siguiente comando:
linkerd version
Y obtendrás una salida que dirá algo similar a esto:
PS C:WINDOWSsystem32> linkerd.exe version
Client version: stable-2.8.1
Server version: unavailable
Ahora necesitamos hacer la instalación en el servidor de Kubernetes, y para hacerlo, usamos el siguiente comando:
linkerd install | kubectl apply -f -
Y obtendrás una salida similar a esta:
PS C:WINDOWSsystem32> linkerd install | kubectl apply -f -
namespace/linkerd created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity created
serviceaccount/linkerd-identity created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-controller created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-controller created
serviceaccount/linkerd-controller created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-destination created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-destination created
serviceaccount/linkerd-destination created
role.rbac.authorization.k8s.io/linkerd-heartbeat created
rolebinding.rbac.authorization.k8s.io/linkerd-heartbeat created
serviceaccount/linkerd-heartbeat created
role.rbac.authorization.k8s.io/linkerd-web created
rolebinding.rbac.authorization.k8s.io/linkerd-web created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-web-check created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-check created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-admin created
serviceaccount/linkerd-web created
customresourcedefinition.apiextensions.k8s.io/serviceprofiles.linkerd.io created
customresourcedefinition.apiextensions.k8s.io/trafficsplits.split.smi-spec.io created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created
serviceaccount/linkerd-prometheus created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created
serviceaccount/linkerd-proxy-injector created
secret/linkerd-proxy-injector-tls created
mutatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-proxy-injector-webhook-config created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created
serviceaccount/linkerd-sp-validator created
secret/linkerd-sp-validator-tls created
validatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-sp-validator-webhook-config created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap-admin created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-delegator created
serviceaccount/linkerd-tap created
rolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-reader created
secret/linkerd-tap-tls created
apiservice.apiregistration.k8s.io/v1alpha1.tap.linkerd.io created
podsecuritypolicy.policy/linkerd-linkerd-control-plane created
role.rbac.authorization.k8s.io/linkerd-psp created
rolebinding.rbac.authorization.k8s.io/linkerd-psp created
configmap/linkerd-config created
secret/linkerd-identity-issuer created
service/linkerd-identity created
deployment.apps/linkerd-identity created
service/linkerd-controller-api created
deployment.apps/linkerd-controller created
service/linkerd-dst created
deployment.apps/linkerd-destination created
cronjob.batch/linkerd-heartbeat created
service/linkerd-web created
deployment.apps/linkerd-web created
configmap/linkerd-prometheus-config created
service/linkerd-prometheus created
deployment.apps/linkerd-prometheus created
deployment.apps/linkerd-proxy-injector created
service/linkerd-proxy-injector created
service/linkerd-sp-validator created
deployment.apps/linkerd-sp-validator created
service/linkerd-tap created
deployment.apps/linkerd-tap created
configmap/linkerd-config-addons created
serviceaccount/linkerd-grafana created
configmap/linkerd-grafana-config created
service/linkerd-grafana created
deployment.apps/linkerd-grafana created
Ahora podemos verificar que la instalación se ha realizado correctamente usando el comando:
linkerd check
Y si todo se ha hecho correctamente, obtendrás una salida como esta:
PS C:WINDOWSsystem32> linkerd check
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ controller pod is running
√ can initialize the client
√ can query the control plane API
linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
√ control plane CustomResourceDefinitions exist
√ control plane MutatingWebhookConfigurations exist
√ control plane ValidatingWebhookConfigurations exist
√ control plane PodSecurityPolicies exist
linkerd-identity
----------------
√ certificate config is valid
√ trust anchors are using supported crypto algorithm
√ trust anchors are within their validity period
√ trust anchors are valid for at least 60 days
√ issuer cert is using supported crypto algorithm
√ issuer cert is within its validity period
√ issuer cert is valid for at least 60 days
√ issuer cert is issued by the trust anchor
Luego podemos ver el panel de Linkerd usando el siguiente comando:
linkerd dashboard
Página web inicial del panel después de una instalación limpia de Linkerd
Despliegue de las aplicaciones
Usaremos las mismas aplicaciones que usamos hace algún tiempo para desplegar istio, así que si quieres recordar lo que están haciendo, necesitas mirar de nuevo ese artículo.
Para desplegar, necesitas tener tus imágenes de docker subidas a un registro de docker, y usaré Amazon ECR como el repositorio de docker que voy a usar.
Así que necesito construir y subir esas imágenes con los siguientes comandos:
Y si alcanzamos el endpoint, obtuvimos la respuesta esperada del proveedor.
Respuesta de muestra proporcionada por el proveedor
Y en el panel, podemos ver las estadísticas del proveedor:
Panel de Linkerd mostrando las estadísticas del flujo
Además, Linkerd por defecto proporciona un panel de Grafana donde puedes ver más métricas, puedes llegar allí usando el enlace de grafana que tiene el panel.
Enlace de Grafana en el Panel de Linkerd
Cuando entras, podrías ver algo como el panel que se muestra a continuación:
Panel de Grafana mostrando las estadísticas de linkerd
Resumen
Con todo este proceso, hemos visto lo fácil que podemos desplegar un servicio mesh de linkerd en nuestro clúster de Kubernetes y cómo las aplicaciones pueden integrarse e interactuar con ellos. En los próximos posts, profundizaremos en las características más avanzadas que nos ayudarán en los nuevos desafíos que vienen con la arquitectura de Microservicios.
Transmisión de Eventos, API y Datos son los tres mosqueteros que cubren todos los aspectos de dominar la integración en la nube.
Foto de Simon Rae en Unsplash
La Integración de Aplicaciones Empresariales ha sido uno de los temas más desafiantes en el panorama de TI desde el principio de los tiempos. Tan pronto como el número de sistemas y aplicaciones en grandes corporaciones comenzó a crecer, esto se convirtió en un problema que debíamos abordar. La eficiencia de este proceso también definirá qué empresas tendrán éxito y cuáles fracasarán, ya que la cooperación entre aplicaciones se vuelve crítica para responder al ritmo que el negocio demanda.
Usualmente me gusta usar la «analogía de la carretera» para definir esto:
No importa si tienes los autos más rápidos, si no tienes carreteras adecuadas no llegarás a ninguna parte
Esta situación genera muchas inversiones por parte de las empresas. Además, se lanzaron muchos proveedores y productos para apoyar esa situación. Algunas soluciones están comenzando a emerger: EAI, ESB, SOA, Middleware, Plataformas de Integración Distribuida, solución Nativa de la Nube e iPaaS.
Cada uno de los enfoques proporciona una solución para los desafíos existentes. A medida que el resto de la industria evolucionaba, las soluciones cambiaron para adaptarse a la nueva realidad (contenedores, microservicios, DevOps, API-led, Event-Driven..)
Entonces, ¿cuál es la situación hoy? Hoy en día está extendida la idea errónea de que la integración es lo mismo que API y también que API es HTTP asincrónico basado en (REST, gRPC, GraphQL) API. Pero es mucho más que esto.
API-led es clave para la solución de integración, especialmente enfocándose en el enfoque filosófico detrás de ella. Cada componente que creamos hoy se crea con la colaboración en mente para trabajar con componentes existentes y futuros para beneficiar al negocio de una manera fácil y ágil. Esto trasciende completamente la discusión del protocolo.
API cubre todo tipo de soluciones desde API REST existentes hasta AsyncAPI para cubrir la API basada en eventos.
2.- Transmisión de Eventos
La comunicación asincrónica es necesaria porque los patrones y los requisitos cuando se habla de grandes empresas y diferentes aplicaciones hacen que esto sea esencial. Requisitos como el enfoque pub-sub para aumentar la independencia entre servicios y aplicaciones, control de flujo para gestionar la ejecución de flujos de alta demanda que pueden exceder la limitación para aplicaciones, especialmente cuando se habla de soluciones SaaS.
Entonces, puedes pensar que esta es una visión muy opinada, pero al mismo tiempo, esto es algo que la mayoría de los proveedores en este espacio han realizado basándose en sus acciones:
AWS lanza SNS/SQS, su primer sistema de mensajería, como su única solución.
Nov 2017 AWS lanza Amazon MQ, otro sistema de mensajería en cola para cubrir los escenarios que SQS no puede cubrir.
May 2019 AWS lanza Amazon MSK, un servicio gestionado para soluciones Kafka para proporcionar capacidades de distribución y procesamiento de datos en streaming.
Y esa situación es porque cuando nos alejamos de aplicaciones más pequeñas, cuando estamos migrando de un enfoque monolítico a una aplicación de microservicios, se necesitan más patrones y más requisitos, y aquí es donde las soluciones de integración han demostrado en el pasado que esto es crítico para las soluciones de integración.
3.- Integración de Datos
Usualmente, cuando hablamos de integración, hablamos de Integración de Aplicaciones Empresariales porque tenemos este sesgo del pasado. Incluso yo uso este término para cubrir este tema, EAI, porque usualmente nos referimos a estas soluciones. Pero desde los últimos años, estamos más enfocados en la distribución de datos en la empresa en lugar de cómo las aplicaciones se integran porque lo que realmente importa son los datos que están intercambiando y cómo podemos transformar estos datos en bruto en conocimientos que podamos usar para conocer mejor a nuestros clientes u optimizar nuestros procesos o descubrir nuevas oportunidades basadas en eso.
Hasta hace poco, esta parte se manejaba aparte de las soluciones de integración. Probablemente dependías de un ETL (Extract-Transform-Load) enfocado que ayuda a mover los datos de una base de datos a otra o a un tipo diferente de almacenamiento como un Data Warehouse para que tus Científicos de Datos puedan trabajar con ellos.
Pero nuevamente, la agilidad ha hecho que esto necesite cambiar, y todos los principios de integración en términos de proporcionar más agilidad al negocio también se aplican a cómo intercambiamos datos. Tratamos de evitar el movimiento técnico de los datos y tratamos de facilitar el acceso y la organización adecuada de estos datos. La Virtualización de Datos y la Transmisión de Datos son las capacidades centrales que abordan y manejan esos desafíos proporcionando una solución optimizada para cómo se distribuyen los datos.
Resumen
Mi principal expectativa con este artículo es hacerte consciente de que cuando piensas en integrar tu aplicación, esto es mucho más que la API REST que estás exponiendo, tal vez usando algún API Gateway, y las necesidades pueden ser muy diferentes. Cuanto más fuerte sea tu plataforma de integración, más fuerte será tu negocio.
SetApp proporciona un conjunto fantástico de herramientas que pueden aumentar tu productividad como Desarrollador de Software.
Acabo de cambiar la laptop PC que usé extensamente durante los últimos años por una nueva Macbook Pro la semana pasada, y he entrado en un nuevo mundo. He usado entornos OS X en el pasado. Tuve mi primer Macbook en 2008 y mi segundo en 2016, así que no soy nuevo en el ecosistema OS X, pero incluso con eso, las cosas cambian rápidamente en la industria de las aplicaciones, especialmente en los últimos cuatro años.
Así que, cuando me enfrento a la pantalla de inicio de sesión de Big Sur frente a mí, me pregunté cómo puedo equiparme, y recordé SetApp. Descubrí SetApp hace mucho tiempo porque uno de los principales podcasters que escucho, Emilio Cano, es un fan muy entusiasta de SetApp y utiliza cualquier oportunidad que tiene para hablar sobre sus beneficios.
Así que decidí darle una oportunidad, y no podría estar más feliz de haberlo hecho. Pero antes de empezar a hablar sobre las aplicaciones, me gustaría dar un resumen de lo que es SetApp, y usaré sus propias palabras de su sitio web oficial:
Setapp es un conjunto de aplicaciones multiplataforma, resolviendo tus tareas diarias. Mantente en tu flujo, en cualquier lugar.
Así que, es como un Netflix para aplicaciones, pagas una suscripción mensual, y tienes acceso a aplicaciones de pago automáticamente, y siguen agregando nuevas a su repositorio para que puedas usarlas.
Como Desarrollador de Software, trato de enfocar esta publicación en las aplicaciones que me ayudan en mi trabajo diario, y aquí están las tres (3) que más me ayudan:
1.- Shimo — Un Cliente VPN Asombroso
En estos días de trabajo remoto, necesitaremos conectarnos a varias VPN cada día para acceder al entorno de tu empresa o incluso al entorno del cliente. Si eres como yo, que trabajas diariamente para varios clientes, cambiar de una VPN de cliente a otra es tu tarea diaria, y si puedes hacerlo rápido, optimizas tu tiempo.
Shimo es un cliente VPN que soporta todos los principales protocolos que las empresas utilizan: Cisco, Juniper, OpenVPN… todo lo que puedas necesitar.
Opciones de VPN que Shimo te proporciona (captura de pantalla por el autor)
Puedes conectarte a más de una VPN si no se superponen, y también puedes acceder a una forma rápida de conectar o desconectar cualquier VPN desde la barra de menú.
2.- Paste — El Portapapeles Definitivo
Esta es una aplicación que es clave para cualquier desarrollador y para cualquier persona que use una computadora. Paste es simplemente como debería ser el portapapeles. Es un portapapeles mejorado con un historial, para que puedas retroceder y seleccionar algo que copiaste ayer y necesitas recuperar.
Y seamos honestos, como Desarrollador de Software, uno de nuestros principales trucos es el CTRL+C, CTRL+V. Puede ser necesario para todo: un fragmento de código que un colega compartió contigo o el comando UNIX que siempre olvidas o recuperar el nombre de usuario que alguien compartió contigo usando un correo electrónico o Slack.
Captura de pantalla de Paste tomada por el autor
3.- DevUtils
Esta es una elección clara. Una herramienta que se llama DevUtils debería estar en esta lista. Pero, ¿qué es DevUtils? Es una colección de todas esas herramientas que siempre buscas en internet para hacer tareas simples pero habituales.
Tareas como codificar o decodificar desde base64, un probador de expresiones regulares, convertidor de tiempo UNIX, formateador de JSON, depurador de JWT, y mucho más… ¿Cuántas veces buscas en Google para hacer una de estas tareas? ¿Cuánto tiempo puedes ahorrar simplemente teniendo eso en tu dock todo el tiempo? La respuesta es simple: ¡mucho!
Captura de pantalla de DevUtils tomada por el Autor
Resumen
Hay muchas más aplicaciones en el catálogo de SetApp. Al escribir este artículo, el número asciende a 210 aplicaciones que cubren todos los aspectos de tu vida, incluyendo una de las aplicaciones más vendidas en la App Store. Pero me gustaría centrarme en las que más uso en mi vida como Desarrollador de Software, y si eres como yo, ¡te parecerán increíbles!
Aprende las principales razones detrás de un estado Deteriorado y cómo puedes realizar la resolución de problemas para identificar y resolver el error.
Este es otro post de la serie #TIBFAQS. Para recordarte de qué se trata todo esto, puedes enviar tus preguntas sobre problemas o dudas de desarrollo de TIBCO e intentar proporcionar una respuesta aquí para tratar de ayudar a la comunidad de desarrolladores de TIBCO.
Así que hoy voy a comenzar con uno de los problemas más comunes cuando trabajamos con BusinessWorks, y es cuando voy a desplegar mi aplicación o probarla localmente, y obtengo este rastro de registro y nada después de eso: Estado Deteriorado de TIBCO BW.
Mensaje de error de estado deteriorado
Esta es una de las situaciones habituales para un desarrollador junior de BusinessWorks y una de las razones por las que pasas más tiempo haciendo resolución de problemas. Vamos a obtener algunos trucos hoy, para que este mensaje nunca más te detenga en tu camino a producción.
¿Cuál es la causa de este error?
Este error significa que el tiempo de ejecución de BusinessWorks no puede cumplir con todas las dependencias entre los componentes para poder iniciar. Como probablemente sepas, en BusinessWorks cada uno de los componentes de las aplicaciones se gestiona de manera independiente y se referencian entre sí.
Por ejemplo, la Aplicación depende del Módulo de Aplicación y el Módulo Compartido. El módulo de Aplicación puede tener una dependencia de una Conexión JMS y así sucesivamente.
Situaciones que pueden provocar este error
Veamos ahora la situación que puede provocar este error y cómo resolverlo.
1.- Módulo faltante o versiones incompatibles
Una situación habitual que puede llevar a este problema es la falta de módulos o versiones incompatibles de los módulos. En ese caso, el componente referenciable esperará un módulo o una versión específica de un módulo para iniciarse. Sin embargo, este módulo falta o está iniciando otra versión.
2.- Conexiones compartidas no válidas
Otra opción puede ser si algunos de los componentes requieren establecer la conexión con otras tecnologías como conexiones JDBC, conexiones JMS, conexiones KAFKA u otro de los más de 200 conectores disponibles.
3.- Componente de Inicio faltante en los Descriptores de Módulo
El último de los sospechosos habituales aquí es cuando tienes un componente de Inicio en los Descriptores de Módulo, pero este proceso no está disponible dentro del archivo EAR que estás desplegando. Esa dependencia nunca se satisface, y eso lleva a un estado Deteriorado ilimitado.
¿Cómo detectar qué componente está faltando?
Para ayudarte en el proceso de detectar en qué situación te encuentras, tienes una herramienta increíble a tu disposición que es el comando la de la Interfaz de Consola OSGi.
Este comando nos ayuda a listar las aplicaciones desplegadas en este AppNode o contenedor específico y nos da los detalles de ellas, incluyendo la razón de una situación Deteriorada.
Cómo ejecutar la consola OSGi depende de tu modelo de despliegue, pero puedes leer toda la información al respecto en el siguiente enlace:
403 Forbidden
Resumen
Espero que encuentres esto interesante para resolver el estado Deteriorado de TIBCO BW en tus aplicaciones, y si eres uno de los que enfrenta este problema ahora, tienes información para no ser detenido por este. Si deseas enviar tus preguntas, siéntete libre de usar una de las siguientes opciones:
Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usar el hashtag #TIBFAQs que monitorearé.
Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
Instagram: Puedes enviarme un DM en Instagram a @alexandrev
