Alexandre Vazquez

Verificación de Salud de Kubernetes: Cómo Hacerlo Más Simple

por

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.

Verificación de Salud de Kubernetes: Cómo Hacerlo Más Simple
Foto por Kent Pilcher en Unsplash

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 tiene como objetivo encontrar varios problemas en Kubernetes, como la mala configuración de aplicaciones, componentes de clúster no saludables y problemas de nodos.

KubeEye tiene como objetivo encontrar varios problemas en Kubernetes, como la mala configuración de aplicaciones, componentes de clúster no saludables y problemas de nodos. – GitHub – kubesphere/kubeeye: KubeEye tiene como objetivo encontrar 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:

git clone https://github.com/kubesphere/kubeeye.git
cd kubeeye
make install

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!

Arquitectura Orientada a Eventos: Mejorando la Capacidad de Respuesta de su Empresa para Tener Éxito

por

La arquitectura impulsada por eventos proporciona más agilidad para enfrentar los cambios de un ecosistema de clientes más exigente.

Aumentando la capacidad de respuesta de su empresa con un enfoque impulsado por eventos
Foto de Kristopher Roller en Unsplash
Tabla de contenidos
  1. ¿Qué es un Evento?
  2. EDA vs Arquitecturas Tradicionales
  3. Capas de una Arquitectura Impulsada por Eventos
  4. Resumen

El mercado está cambiando a una velocidad que requiere estar listo para cambiar muy rápidamente, los clientes se están volviendo cada vez más exigentes y necesitamos ser capaces de entregar lo que esperan, y para hacerlo necesitamos una arquitectura que sea lo suficientemente receptiva para poder adaptarse al ritmo que se requiere.

Las arquitecturas impulsadas por eventos (generalmente conocidas como EDA) son arquitecturas donde los eventos son la parte crucial y diseñamos componentes listos para manejar esos eventos de la manera más eficiente. Una arquitectura que está lista para reaccionar a lo que sucede a nuestro alrededor en lugar de simplemente establecer un camino específico para nuestros clientes.

Este enfoque proporciona muchos beneficios a las empresas debido a sus características, pero al mismo tiempo requiere una mentalidad diferente y un conjunto diferente de componentes en su lugar.

¿Qué es un Evento?

Comencemos por el principio. Un evento es cualquier cosa que pueda suceder y que sea importante para ti. Si piensas en un escenario donde un usuario simplemente está navegando por un sitio web de comercio electrónico, todo lo que tiene es un evento. Si llegamos al sitio de comercio electrónico porque tenía un enlace de referencia, eso es un evento.

Los eventos no solo ocurren en la vida virtual, sino también en la vida real. Una persona que simplemente entra al vestíbulo del hotel es un evento, ir frente al mostrador de recepción para hacer el check-in es otro, simplemente caminar a su habitación es otro… todo es un evento.

Los eventos en aislamiento proporcionan una pequeña pieza de información, pero juntos pueden proporcionar mucha información valiosa sobre los clientes, sus preferencias, sus expectativas y también sus necesidades. Y todo eso nos ayudará a proporcionar la experiencia más personalizada a cada uno de nuestros clientes.

EDA vs Arquitecturas Tradicionales

Las arquitecturas tradicionales funcionan en modo pull, lo que significa que un consumidor envía una solicitud a un servicio, ese servicio necesita otros componentes para hacer la lógica, obtiene la respuesta y responde. Todo está predefinido.

Los eventos funcionan de manera diferente porque operan en modo push, los eventos se envían y eso es todo, podría desencadenar una acción, muchas acciones o ninguna. Tienes una serie de componentes esperando, escuchando hasta que el evento o la secuencia de eventos que necesitan activar aparece frente a ellos y cuando lo hace, simplemente activa su lógica y como parte de esa ejecución genera uno o más eventos para poder ser consumidos nuevamente.

Modo Pull vs Push para la Comunicación.

Para poder construir una arquitectura impulsada por eventos, lo primero que necesitamos es tener componentes impulsados por eventos. Necesitamos componentes de software que se activen en función de eventos y también generen eventos como parte de su lógica de procesamiento. Al mismo tiempo, esta secuencia de eventos también se convierte en la forma de completar flujos complejos en un modo de cooperación sin la necesidad de un componente maestro que esté al tanto de todo el flujo de principio a fin.

Simplemente tienes componentes que saben que cuando sucede esto, necesitan hacer su parte del trabajo y otros componentes escucharán la salida de esos componentes y se activarán.

Este enfoque se llama Coreografía porque funciona de la misma manera en una compañía de ballet donde cada uno de los bailarines puede estar haciendo diferentes movimientos, pero cada uno de ellos sabe exactamente lo que debe hacer y todos juntos en sincronía generan la pieza completa.

Capas de una Arquitectura Impulsada por Eventos

Ahora que tenemos componentes de software que se activan usando eventos, necesitamos alguna estructura alrededor de eso en nuestra arquitectura para cubrir todas las necesidades en la gestión de los eventos, por lo que necesitamos manejar las siguientes capas:

Capas de la Arquitectura Impulsada por Eventos
  • Ingesta de Eventos: Necesitamos una serie de componentes que nos ayuden a introducir y recibir eventos en nuestros sistemas. Como explicamos, hay toneladas y toneladas de formas de enviar eventos, por lo que es importante que ofrezcamos flexibilidad y opciones en ese proceso. Los adaptadores y las API son cruciales aquí para asegurarse de que todos los eventos puedan ser recopilados y formar parte del sistema.
  • Distribución de Eventos: Necesitamos un Bus de Eventos que actúe como nuestro Océano de Eventos donde todos los eventos fluyen para poder activar todos los componentes que están escuchando ese evento.
  • Procesamiento de Eventos: Necesitamos una serie de componentes para escuchar todos los eventos que se envían y hacerlos significativos. Estos componentes deben actuar como guardias de seguridad: Filtran los eventos que no son importantes, también enriquecen los eventos que reciben con información de contexto de otros sistemas o fuentes de datos, y transforman el formato de algunos eventos para que sea fácil de entender para todos los componentes que están esperando esos eventos.
  • Acción de Eventos: Necesitamos una serie de componentes que escuchen esos eventos y estén listos para reaccionar a lo que se ve en el Bus de Eventos tan pronto como detecten que esperan comenzar a hacer su lógica y enviar la salida nuevamente al bus para ser utilizada por alguien más.

Resumen

La arquitectura impulsada por eventos puede proporcionar un ecosistema mucho más ágil y flexible donde las empresas pueden abordar los desafíos actuales para ofrecer una experiencia atractiva a los usuarios y clientes y al mismo tiempo proporcionar más agilidad a los equipos técnicos al poder crear componentes que trabajen en colaboración pero acoplados de manera flexible, haciendo que los componentes y los equipos sean más autónomos.

Opciones mejoradas de AutoScaling para aplicaciones impulsadas por eventos

por

KEDA proporciona un entorno rico para escalar su aplicación aparte del enfoque tradicional de HPA usando CPU y Memoria

Foto de Markus Winkler en Unsplash

El escalado automático es una de las grandes ventajas de los entornos nativos de la nube y nos ayuda a proporcionar un uso optimizado de las operaciones. Kubernetes ofrece muchas opciones para hacerlo, siendo una de ellas el enfoque del Escalador Automático de Pods Horizontal (HPA).

HPA es la forma en que Kubernetes detecta si es necesario escalar alguno de los pods, y se basa en métricas como el uso de CPU o memoria.

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

A veces esas métricas no son suficientes para decidir si el número de réplicas que tenemos disponibles es suficiente. Otras métricas pueden proporcionar una mejor perspectiva, como el número de solicitudes o el número de eventos pendientes.

Escalado Automático Basado en Eventos de Kubernetes (KEDA)

Aquí es donde KEDA viene a ayudar. KEDA significa Escalado Automático Basado en Eventos de Kubernetes y proporciona un enfoque más flexible para escalar nuestros pods dentro de un clúster de Kubernetes.

Se basa en escaladores que pueden implementar diferentes fuentes para medir el número de solicitudes o eventos que recibimos de diferentes sistemas de mensajería como Apache Kafka, AWS Kinesis, Azure EventHub y otros sistemas como InfluxDB o Prometheus.

KEDA funciona como se muestra en la imagen a continuación:

Tenemos nuestro ScaledObject que vincula nuestra fuente de eventos externa (es decir, Apache Kafka, Prometheus ..) con el Despliegue de Kubernetes que nos gustaría escalar y registrar eso en el clúster de Kubernetes.

KEDA monitoreará la fuente externa y, basado en las métricas recopiladas, comunicará al Escalador Automático de Pods Horizontal para escalar la carga de trabajo según lo definido.

Probando el Enfoque con un Caso de Uso

Entonces, ahora que sabemos cómo funciona, haremos algunas pruebas para verlo en vivo. Vamos a mostrar cómo podemos escalar rápidamente una de nuestras aplicaciones usando esta tecnología. Y para hacer eso, lo primero que necesitamos hacer es definir nuestro escenario.

En nuestro caso, el escenario será una aplicación nativa de la nube simple desarrollada usando una aplicación Flogo que expone un servicio REST.

El primer paso que necesitamos hacer es desplegar KEDA en nuestro clúster de Kubernetes, y hay varias opciones para hacerlo: gráficos Helm, Operación o archivos YAML. En este caso, vamos a usar el enfoque de gráficos Helm.

Entonces, vamos a escribir los siguientes comandos para agregar el repositorio helm y actualizar los gráficos disponibles, y luego desplegar KEDA como parte de nuestra configuración de clúster:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda

Después de ejecutar este comando, KEDA se despliega en nuestro clúster K8S, y al escribir el siguiente comando kubectl get all proporcionará una situación similar a esta:

pod/keda-operator-66db4bc7bb-nttpz 2/2 Running 1 10m
pod/keda-operator-metrics-apiserver-5945c57f94-dhxth 2/2 Running 1 10m

Ahora, vamos a desplegar nuestra aplicación. Como ya se comentó, para hacerlo vamos a usar nuestra Aplicación Flogo, y el flujo será tan simple como este:

Aplicación Flogo escuchando las solicitudes
  • La aplicación expone un servicio REST usando /hello como el recurso.
  • Las solicitudes recibidas se imprimen en la salida estándar y se devuelve un mensaje al solicitante

Una vez que tenemos nuestra aplicación desplegada en nuestra aplicación de Kubernetes, necesitamos crear un ScaledObject que sea responsable de gestionar la escalabilidad de ese componente:

Configuración de ScaleObject para la aplicación

Usamos Prometheus como un disparador, y debido a eso, necesitamos configurar dónde está alojado nuestro servidor Prometheus y qué consulta nos gustaría hacer para gestionar la escalabilidad de nuestro componente.

En nuestro ejemplo, usaremos el flogo_flow_execution_count que es la métrica que cuenta el número de solicitudes que son recibidas por este componente, y cuando esto tiene una tasa superior a 100, lanzará una nueva réplica.

Después de golpear el servicio con una Prueba de Carga, podemos ver que tan pronto como el servicio alcanza el umbral, lanza una nueva réplica para comenzar a manejar solicitudes como se esperaba.

Escalado automático realizado usando métricas de Prometheus.

Todo el código y los recursos están alojados en el repositorio de GitHub que se muestra a continuación:

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

Resumen

Este post ha mostrado que tenemos opciones ilimitadas para decidir las opciones de escalabilidad para nuestras cargas de trabajo. Podemos usar las métricas estándar como CPU y memoria, pero si necesitamos ir más allá, podemos usar diferentes fuentes externas de información para activar ese escalado automático.

Descubre tu herramienta perfecta para gestionar Kubernetes

por

Maximizando la productividad al trabajar con el entorno de Kubernetes con una herramienta para cada persona

Foto de Christina @ wocintechchat.com en Unsplash

Todos sabemos que Kubernetes es el entorno predeterminado para todas nuestras nuevas aplicaciones que desarrollamos y construiremos. El sabor de esa plataforma de Kubernetes puede ser de diferentes maneras y formas, pero una cosa está clara, es complejo.

Las razones detrás de esta complejidad son poder proporcionar toda la flexibilidad, pero también es cierto que el proyecto k8s nunca ha puesto mucho esfuerzo en proporcionar una forma sencilla de gestionar tus clústeres y kubectl es el punto de acceso para enviar comandos, dejando esta puerta abierta a la comunidad para proporcionar su propia solución y estas son las cosas que vamos a discutir hoy.

Tablero de Kubernetes: La Opción Predeterminada

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9rdWJlcm5ldGVzLmlvL2RvY3MvdGFza3MvYWNjZXNzLWFwcGxpY2F0aW9uLWNsdXN0ZXIvd2ViLXVpLWRhc2hib2FyZC8iLCJpbWFnZV9pZCI6MCwiaW1hZ2VfdXJsIjoiIiwidGl0bGUiOiIiLCJzdW1tYXJ5IjoiIiwidGVtcGxhdGUiOiJ1c2VfZGVmYXVsdF9mcm9tX3NldHRpbmdzIn0=»]

El Tablero de Kubernetes es la opción predeterminada para la mayoría de las instalaciones. Es una interfaz basada en la web que es parte del proyecto K8s pero no se despliega por defecto cuando instalas el clúster.

K9S: La opción de CLI

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9naXRodWIuY29tL2RlcmFpbGVkL2s5cyIsImltYWdlX2lkIjowLCJpbWFnZV91cmwiOiIiLCJ0aXRsZSI6IiIsInN1bW1hcnkiOiIiLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==»]

K9S es una de las opciones más comunes para aquellos que aman una interfaz de línea de comandos muy poderosa con muchas opciones a su disposición.

Es una mezcla entre todo el poder de una interfaz de línea de comandos con todas las opciones de teclado a tu disposición con una vista gráfica muy elegante para tener una visión rápida del estado de tu clúster de un vistazo.

Lens — La Opción Gráfica

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9rOHNsZW5zLmRldiIsImltYWdlX2lkIjowLCJpbWFnZV91cmwiOiIiLCJ0aXRsZSI6IiIsInN1bW1hcnkiOiIiLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==»]

Lens es una opción de GUI muy vitaminada que va más allá de solo mostrar el estado del clúster de K8S o permitir modificaciones en los componentes. Con integración con otros proyectos como Helm o soporte para el CRD. Proporciona una experiencia muy agradable de gestión de clústeres con soporte para múltiples clústeres también. Para saber más sobre Lens puedes echar un vistazo a este artículo donde cubrimos sus principales características:

[visual-link-preview encoded=»eyJ0eXBlIjoiaW50ZXJuYWwiLCJwb3N0Ijo4MSwicG9zdF9sYWJlbCI6IlBvc3QgODEgLSBMZW5zIENvdWxkIEJlIHRoZSBUb29sIFRoYXQgWW91IFdlcmUgTWlzc2luZyB0byBNYXN0ZXIgS3ViZXJuZXRlcy1CYXNlZCBEZXZlbG9wbWVudCBhbmQgTWFuYWdlbWVudCIsInVybCI6IiIsImltYWdlX2lkIjoyNDk1LCJpbWFnZV91cmwiOiJodHRwOi8vYWxleGFuZHJlLXZhenF1ZXouY29tL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDIyLzAxL2ltZ182MWVkMTNjNTllZjQ5LmpwZyIsInRpdGxlIjoiTGVucyBDb3VsZCBCZSB0aGUgVG9vbCBUaGF0IFlvdSBXZXJlIE1pc3NpbmcgdG8gTWFzdGVyIEt1YmVybmV0ZXMtQmFzZWQgRGV2ZWxvcG1lbnQgYW5kIE1hbmFnZW1lbnQiLCJzdW1tYXJ5IjoiRmluZCB0aGUgZ3JlYXRlc3Qgd2F5IHRvIG1hbmFnZSB5b3VyIEt1YmVybmV0ZXMgZGV2ZWxvcG1lbnQgY2x1c3RlciBQaG90byBieSBBZ2VuY2UgT2xsb3dlYiBvbiBVbnNwbGFzaC4gSSBuZWVkIHRvIHN0YXJ0IHRoaXMgYXJ0aWNsZSBieSBhZG1pdHRpbmcgdGhhdCBJIGFtIGFuIGFkdm9jYXRlIG9mIEdyYXBoaWNhbCBVc2VyIEludGVyZmFjZXMgYW5kIGV2ZXJ5dGhpbmcgdGhhdCBwcm92aWRlcyBhIHdheSB0byBzcGVlZCB1cCB0aGUgd2F5IHdlIGRvIHRoaW5ncyBhbmQgYmUgbW9yZSBwcm9kdWN0aXZlLiBTbyB3aGVuIHdlIHRhbGsgWyZoZWxsaXA7XSIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

Octant — La Opción Web

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9vY3RhbnQuZGV2IiwiaW1hZ2VfaWQiOjAsImltYWdlX3VybCI6IiIsInRpdGxlIjoiIiwic3VtbWFyeSI6IiIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

Octant proporciona una experiencia mejorada en comparación con la opción web predeterminada discutida en este artículo usando el tablero de Kubernetes. Construido para la extensión con un sistema de complementos que te permite extender o personalizar el comportamiento de octant para maximizar tu productividad gestionando clústeres de K8S. Incluyendo soporte para CRD y visualización gráfica de dependencias, proporciona una experiencia increíble.

Resumen

Hemos proporcionado en este artículo diferentes herramientas que te ayudarán durante la importante tarea de gestionar o inspeccionar tu clúster de Kubernetes. Cada una de ellas con sus propias características y cada una de ellas se enfoca en diferentes formas de proporcionar la información (CLI, GUI y Web) para que siempre puedas encontrar una que funcione mejor para tu situación y preferencias.

Mejora tu estrategia de implementación con Canarying en Kubernetes

por

Ahorra tiempo y dinero en tu plataforma de aplicaciones implementando aplicaciones de manera diferente en Kubernetes.

Foto por Jason Leung en Unsplash

Venimos de una época en la que implementamos una aplicación utilizando un proceso aparente y lineal. La forma tradicional es más o menos así:

  • Esperar hasta un fin de semana o algún momento en que la carga sea baja y el negocio pueda tolerar cierta indisponibilidad del servicio.
  • Programamos el cambio y avisamos a todos los equipos involucrados para que estén listos para gestionar el impacto.
  • Implementamos la nueva versión y tenemos a todos los equipos durante la prueba funcional que necesitan hacer para asegurarse de que funciona bien, y esperamos a que ocurra la carga real.
  • Monitoreamos durante las primeras horas para ver si ocurre algo malo, y en caso de que sí, establecemos un proceso de reversión.
  • Tan pronto como todo va bien, esperamos hasta el próximo lanzamiento en 3-4 meses.

Pero esto ya no es válido. El negocio exige que TI sea ágil, cambie rápidamente y no pueda permitirse hacer ese tipo de esfuerzo de recursos cada semana o, peor aún, cada día. ¿Crees que es posible reunir a todos los equipos cada noche para implementar los últimos cambios? No es factible en absoluto.

Entonces, la tecnología avanza para ayudarnos a resolver mejor ese problema, y aquí es donde Canarying vino a ayudarnos.

Introducción a los Despliegues Canary

Los despliegues canary (o simplemente Canarying, como prefieras) no son algo nuevo, y mucha gente ha estado hablando mucho sobre ello:

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9tYXJ0aW5mb3dsZXIuY29tL2JsaWtpL0NhbmFyeVJlbGVhc2UuaHRtbCIsImltYWdlX2lkIjotMSwiaW1hZ2VfdXJsIjoiaHR0cHM6Ly9tYXJ0aW5mb3dsZXIuY29tL2xvZ28tc3EucG5nIiwidGl0bGUiOiJibGlraTogQ2FuYXJ5UmVsZWFzZSIsInN1bW1hcnkiOiJBIGNhbmFyeSByZWxlYXNlIG9jY3VycyB3aGVuIHlvdSByb2xsIG91dCBhIG5ldyB2ZXJzaW9uIG9mIHNvbWUgc29mdHdhcmUgdG8gYSBzbWFsbCBzdWJzZXQgb2YgeW91ciB1c2VyIGJhc2UgdG8gc2VlIGlmIHRoZXJlIGFyZSBhbnkgcHJvYmxlbXMgYmVmb3JlIHlvdSBtYWtlIGl0IGF2YWlsYWJsZSB0byBldmVyeW9uZS4iLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==»]

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9zcmUuZ29vZ2xlL3dvcmtib29rL2NhbmFyeWluZy1yZWxlYXNlcy8iLCJpbWFnZV9pZCI6LTEsImltYWdlX3VybCI6Imh0dHBzOi8vbGgzLmdvb2dsZXVzZXJjb250ZW50LmNvbS9GTGUwZ0ZXczN6OVpETGgtUjV0UG1YLWVFWTZHaDZfWDNYeGotZm9Bc2lyaUhnM1lYN29rR1doNEUwdFMzd2ViNWthR2t2ak5pYjl0dHdZVnc4dnJ5VjZsd2p5NHpQN2MxcE9ZPXMxMDQzIiwidGl0bGUiOiJHb29nbGUgLSBTaXRlIFJlbGlhYmlsaXR5IEVuZ2luZWVyaW5nIiwic3VtbWFyeSI6IlJlbGVhc2UgZW5naW5lZXJpbmcgaXMgYSB0ZXJtIHdlIHVzZSB0byBkZXNjcmliZSBhbGwgdGhlIHByb2Nlc3NlcyBhbmQgYXJ0aWZhY3RzIHJlbGF0ZWQgdG8gZ2V0dGluZyBjb2RlIGZyb20gYSByZXBvc2l0b3J5IGludG8gYSBydW5uaW5nIHByb2R1Y3Rpb24gc3lzdGVtLiBBdXRvbWF0aW5nIHJlbGVhc2VzIGNhbiBoZWxwIGF2b2lkIG1hbnkgb2YgdGhlIHRyYWRpdGlvbmFsIHBpdGZhbGxzIGFzc29jaWF0ZWQgd2l0aCByZWxlYXNlIGVuZ2luZWVyaW5nOiB0aGUgdG9pbCBvZiByZXBldGl0aXZlIGFuZCBtYW51YWwgdGFza+KApiIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

Ha estado aquí por algún tiempo, pero antes no era ni fácil ni práctico implementarlo. Básicamente se basa en implementar la nueva versión en producción, pero aún manteniendo el tráfico apuntando a la versión antigua de la aplicación y solo comienzas a desviar parte del tráfico a la nueva versión.

Representación gráfica de un lanzamiento canary en un entorno de Kubernetes

Basado en ese pequeño subconjunto de solicitudes, monitoreas cómo se desempeña la nueva versión en diferentes niveles, nivel funcional, nivel de rendimiento, etc. Una vez que te sientes cómodo con el rendimiento que está proporcionando, simplemente desvías todo el tráfico a la nueva versión y deprecias la versión antigua.

Eliminación de la versión antigua después de que todo el tráfico ha sido desviado a la nueva versión implementada.

Los beneficios que vienen con este enfoque son enormes:

  • No necesitas un gran entorno de pruebas como antes porque puedes hacer algunas de las pruebas con datos reales en producción sin afectar tu negocio y la disponibilidad de tus servicios.
  • Puedes reducir el tiempo de comercialización y aumentar la frecuencia de los despliegues porque puedes hacerlo con menos esfuerzo y personas involucradas.
  • Tu ventana de despliegue se ha extendido mucho ya que no necesitas esperar una ventana de tiempo específica, y debido a eso, puedes implementar nuevas funcionalidades con más frecuencia.

Implementando Despliegue Canary en Kubernetes

Para implementar Despliegue Canary en Kubernetes, necesitamos proporcionar más flexibilidad en cómo se enruta el tráfico entre nuestros componentes internos, que es una de las capacidades que se extienden al usar un Service Mesh.

Ya discutimos los beneficios de usar un Service Mesh como parte de tu entorno, pero si deseas volver a echar un vistazo, por favor consulta este artículo:

[visual-link-preview encoded=»eyJ0eXBlIjoiaW50ZXJuYWwiLCJwb3N0Ijo5NiwicG9zdF9sYWJlbCI6IlBvc3QgOTYgLSBUZWNobm9sb2d5IHdhcnM6IEFQSSBNYW5hZ2VtZW50IFNvbHV0aW9uIHZzIFNlcnZpY2UgTWVzaCIsInVybCI6IiIsImltYWdlX2lkIjoyNTUzLCJpbWFnZV91cmwiOiJodHRwOi8vYWxleGFuZHJlLXZhenF1ZXouY29tL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDIyLzAxL2ltZ182MWVkMTNmNDVmNDRhLmpwZyIsInRpdGxlIjoiVGVjaG5vbG9neSB3YXJzOiBBUEkgTWFuYWdlbWVudCBTb2x1dGlvbiB2cyBTZXJ2aWNlIE1lc2giLCJzdW1tYXJ5IjoiU2VydmljZSBNZXNoIHZzLiBBUEkgTWFuYWdlbWVudCBTb2x1dGlvbjogaXMgaXQgdGhlIHNhbWU/IEFyZSB0aGV5IGNvbXBhdGlibGU/IEFyZSB0aGV5wqByaXZhbHM/IFBob3RvIGJ5IEFsdmFybyBSZXllcyBvbsKgVW5zcGxhc2ggV2hlbiB3ZSB0YWxrIGFib3V0IGNvbW11bmljYXRpb24gaW4gYSBkaXN0cmlidXRlZCBjbG91ZC1uYXRpdmUgd29ybGQgYW5kIGVzcGVjaWFsbHkgd2hlbiB3ZSBhcmUgdGFsa2luZyBhYm91dCBjb250YWluZXItYmFzZWQgYXJjaGl0ZWN0dXJlcyBiYXNlZCBvbiBLdWJlcm5ldGVzIHBsYXRmb3JtIGxpa2UgQUtTLCBFS1MsIE9wZW5zaGlmdCwgYW5kIHNvIG9uLCB0d28gdGVjaG5vbG9naWVzIGdlbmVyYXRlIGEgbG90IFsmaGVsbGlwO10iLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==»]

Tenemos varios componentes tecnológicos que pueden proporcionar esas capacidades, pero así es como podrás crear las rutas de tráfico para implementar esto. Para ver cómo puedes echar un vistazo al siguiente artículo sobre una de las opciones predeterminadas que es Istio:

[visual-link-preview encoded=»eyJ0eXBlIjoiaW50ZXJuYWwiLCJwb3N0IjoxMjMsInBvc3RfbGFiZWwiOiJQb3N0IDEyMyAtIEludGVncmF0aW5nIElzdGlvIHdpdGggQldDRSBBcHBsaWNhdGlvbnMiLCJ1cmwiOiIiLCJpbWFnZV9pZCI6Mjc4NCwiaW1hZ2VfdXJsIjoiaHR0cDovL2FsZXhhbmRyZS12YXpxdWV6LmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAyMi8wMS9pbWdfNjFlZDE0NjdlMzYxZi5wbmciLCJ0aXRsZSI6IkludGVncmF0aW5nIElzdGlvIHdpdGggQldDRSBBcHBsaWNhdGlvbnMiLCJzdW1tYXJ5IjoiSW50cm9kdWN0aW9uIFNlcnZpY2VzIE1lc2ggaXMgb25lIHRoZSDigJxncmVhdGVzdCBuZXcgdGhpbmfigJ0gaW4gb3VyIFBhYVMgZW52aXJvbm1lbnRzLiBObyBtYXR0ZXIgaWYgeW914oCZcmUgd29ya2luZyB3aXRoIEs4UywgRG9ja2VyIFN3YXJtLCBwdXJlLWNsb3VkIHdpdGggRUtTIG9yIEFXUywgeW914oCZdmUgaGVhcmQgYW5kIHByb2JhYmx5IHRyaWVkIHRvIGtub3cgaG93IGNhbiBiZSB1c2VkIHRoaXMgbmV3IHRoaW5nIHRoYXQgaGFzIHNvIG1hbnkgYWR2YW50YWdlcyBiZWNhdXNlIGl0IHByb3ZpZGVzIGEgbG90IG9mIG9wdGlvbnMgaW4gaGFuZGxpbmcgWyZoZWxsaXA7XSIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

Pero poder enrutar el tráfico no es suficiente para implementar un enfoque completo de despliegue canary. También necesitamos poder monitorear y actuar en base a esas métricas para evitar la intervención manual. Para hacer esto, necesitamos incluir diferentes herramientas para proporcionar esas capacidades:

Prometheus es la opción de facto para monitorear cargas de trabajo implementadas en el entorno de Kubernetes, y aquí puedes obtener más información sobre cómo ambos proyectos trabajan juntos.

[visual-link-preview encoded=»eyJ0eXBlIjoiaW50ZXJuYWwiLCJwb3N0IjoxMDksInBvc3RfbGFiZWwiOiJQb3N0IDEwOSAtIEt1YmVybmV0ZXMgU2VydmljZSBEaXNjb3ZlcnkgZm9yIFByb21ldGhldXMiLCJ1cmwiOiIiLCJpbWFnZV9pZCI6MjYyNCwiaW1hZ2VfdXJsIjoiaHR0cDovL2FsZXhhbmRyZS12YXpxdWV6LmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAyMi8wMS8xMVJubElVVHB0UjBEMkpMUE1GeE9Qdy5wbmciLCJ0aXRsZSI6Ikt1YmVybmV0ZXMgU2VydmljZSBEaXNjb3ZlcnkgZm9yIFByb21ldGhldXMiLCJzdW1tYXJ5IjoiSW4gcHJldmlvdXMgcG9zdHMsIHdlIGRlc2NyaWJlZCBob3cgdG8gc2V0IHVwIFByb21ldGhldXMgdG8gd29yayB3aXRoIHlvdXIgVElCQ08gQnVzaW5lc3NXb3JrcyBDb250YWluZXIgRWRpdGlvbiBhcHBzLCBhbmQgeW91IGNhbiByZWFkIG1vcmUgYWJvdXQgaXQgaGVyZS4gSW4gdGhhdCBwb3N0LCB3ZSBkZXNjcmliZWQgdGhhdCB0aGVyZSB3ZXJlIHNldmVyYWwgd2F5cyB0byB1cGRhdGUgUHJvbWV0aGV1cyBhYm91dCB0aGUgc2VydmljZXMgdGhhdCByZWFkeSB0byBtb25pdG9yLiBBbmQgd2UgY2hvb3NlIHRoZSBtb3N0IHNpbXBsZSBhdCB0aGF0IFsmaGVsbGlwO10iLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==»]

Y para gestionar el proceso general, puedes tener una herramienta de Despliegue Continuo para poner algo de gobernanza alrededor de eso usando opciones como Spinnaker o usando alguna de las extensiones para las herramientas de Integración Continua como GitLab o GitHub:

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9zcGlubmFrZXIuaW8vZG9jcy9ndWlkZXMvdXNlci9jYW5hcnkvIiwiaW1hZ2VfaWQiOi0xLCJpbWFnZV91cmwiOiJodHRwczovL3NwaW5uYWtlci5pby9pbWFnZXMvY2RmLWNvbG9yLnBuZyIsInRpdGxlIjoiVXNpbmcgU3Bpbm5ha2VyIGZvciBBdXRvbWF0ZWQgQ2FuYXJ5IEFuYWx5c2lzIiwic3VtbWFyeSI6IkF1dG9tYXRlZCBjYW5hcnkgYW5hbHlzaXMgbGV0cyB5b3UgcGFydGlhbGx5IHJvbGwgb3V0IGEgY2hhbmdlIHRoZW4gZXZhbHVhdGUgaXQgYWdhaW5zdCB0aGUgY3VycmVudCBkZXBsb3ltZW50IHRvIGFzc2VzcyBpdHMgcGVyZm9ybWFuY2UuIiwidGVtcGxhdGUiOiJ1c2VfZGVmYXVsdF9mcm9tX3NldHRpbmdzIn0=»]

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9kb2NzLmdpdGxhYi5jb20vZWUvdXNlci9wcm9qZWN0L2NhbmFyeV9kZXBsb3ltZW50cy5odG1sIiwiaW1hZ2VfaWQiOjAsImltYWdlX3VybCI6IiIsInRpdGxlIjoiIiwic3VtbWFyeSI6IiIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

Resumen

En este artículo, cubrimos cómo podemos evolucionar un modelo de despliegue tradicional para mantener el ritmo de la innovación que los negocios requieren hoy y cómo las técnicas de despliegue canary pueden ayudarnos en ese viaje, y los componentes tecnológicos necesarios para configurar esta estrategia en tu propio entorno.

#TIBFAQS Habilitación de la depuración remota para la aplicación TIBCO BusinessWorks en Kubernetes

por

Proporcione más agilidad a sus esfuerzos de resolución de problemas depurando exactamente donde ocurre el error utilizando técnicas de Depuración Remota

Foto de Markus Winkler en Unsplash

La revolución de los contenedores ha proporcionado muchos beneficios, como hemos discutido en profundidad en otros artículos, y al mismo tiempo, también ha proporcionado algunos nuevos desafíos que necesitamos abordar.

Toda la agilidad que ahora tenemos en manos de nuestros desarrolladores también necesita extenderse al trabajo de mantenimiento y solución de problemas. Necesitamos ser ágiles también. Conocemos algunos de los principales problemas que tenemos al respecto: Funciona en mi entorno, con el conjunto de datos que tengo, no pude ver el problema, o no pude reproducir el error, son solo frases que escuchamos una y otra vez y retrasan la resolución de algunos errores o mejoras, incluso cuando la solución es simple, luchamos por obtener un escenario real para probar.

Y aquí es donde entra la Depuración Remota. La Depuración Remota es, tal como su propio nombre indica claramente, poder depurar algo que no es local, que es remoto. Se ha centrado desde su concepción en el Desarrollo Móvil porque no importa cuán bueno sea el simulador. Siempre necesitarás probar en un dispositivo real para asegurarte de que todo funcione correctamente.

Así que este es el mismo concepto pero aplicable a un contenedor, lo que significa que tengo una aplicación TIBCO BusinessWorks ejecutándose en Kubernetes. Queremos depurarla como si estuviera ejecutándose localmente, como se muestra en la imagen anterior. Para poder hacer eso, necesitamos seguir estos pasos:

Habilitar la Depuración Remota en el pod

El primer paso es habilitar la opción de depuración remota en la aplicación y para hacerlo, necesitamos usar la API interna que proporciona BusinessWorks, y para hacerlo, necesitamos ejecutar desde dentro del contenedor:

curl -XPOST http://localhost:8090/bw/bwengine.json/debug/?interface=0.0.0.0&port=5554&engineName=Main

En caso de que no tengamos ninguna herramienta como curl o wget para acceder a una URL dentro del contenedor, siempre puedes usar la estrategia de port-forward para hacer que el puerto 8090 del pod sea accesible para habilitar el puerto de depuración usando un comando similar al siguiente:

kubectl port-forward hello-world-test-78b6f9b4b-25hss 8090:8090

Y luego, podemos acceder desde nuestra máquina local para habilitar la depuración remota

Hacer que el Puerto de Depuración sea accesible para el Studio

Para hacer la depuración remota, necesitamos poder conectar nuestro TIBCO BusinessStudio local a este pod específico que está ejecutando la carga y, para hacerlo, necesitamos tener acceso al puerto de depuración. Para obtener esto, tenemos principalmente dos opciones que son las que se muestran en las subsecciones a continuación: Exponer el puerto a nivel del pod y opción de port-forwarding.

Exponer el puerto a nivel del Pod

Necesitamos tener el puerto de depuración abierto en nuestro pod. Para hacer eso, necesitamos definir otro puerto que no esté en uso por la aplicación, y que no sea el puerto de administración predeterminado (8090) para el que se va a exponer. Por ejemplo, en mi caso, usaré 5554 como el puerto de depuración, y para hacerlo, defino otro puerto para ser accedido.

Definición del puerto de depuración como un Servicio

Opción de Port-Forwarding

Otra opción si no queremos exponer el puerto de depuración todo el tiempo, incluso si no se va a usar a menos que estemos ejecutando la depuración remota, tenemos otra opción para hacer un port-forward al puerto de depuración en nuestro local.

kubectl port-forward hello-world-test-78b6f9b4b-cctgh 5554:5554

Conexión al TIBCO Business Studio

Ahora que tenemos todo listo, necesitamos conectar nuestro TIBCO Business Studio local al pod, y para hacerlo, necesitamos seguir estos pasos:

Ejecutar → Configuraciones de Depuración, y seleccionamos el BusinessWorks Remoto

Selección de la opción de aplicación BusinessWorks Remoto en la Configuración de Depuración

Y ahora necesitamos proporcionar los detalles de la conexión. Para este caso, usaremos el localhost y el puerto 5554 y haremos clic en el botón de Depuración.

Configuración de las propiedades de conexión para la Depuración Remota

Después de ese momento, estableceremos una conexión entre ambos entornos: el pod ejecutándose en nuestro clúster de Kubernetes y nuestro TIBCO BusinessStudio local. Y tan pronto como accedamos al contenedor, podemos ver la ejecución en nuestro entorno local:

Ejecución de Depuración Remota desde nuestra instancia de TIBCO BusinesStudio

Resumen

Espero que encuentres esto interesante, y si eres uno de los que enfrenta este problema ahora, tienes información para no detenerte por este. Si deseas enviar tus preguntas, no dudes en 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

Maid: El organizador de archivos automatizado de código abierto definitivo para hackers

por

Maid ofrece lo mejor de ambos mundos: facilidad de uso y flexibilidad que viene con una interfaz basada en código.

Maid: El Organizador de Archivos Automatizado de Código Abierto Definitivo para Hackers
Foto de Kowon vn en Unsplash

Uno de los principales problemas que tengo debido a mis prácticas rutinarias usando computadoras es la falta de disciplina organizativa. Para mí es bastante complejo tener todos los diferentes archivos organizados en el lugar correcto todo el tiempo, y finalmente decidí dejar de luchar contra eso.

Esto es algo que me ha pasado desde el comienzo de mi uso de computadoras, pero empeoró cuando comencé a trabajar en la industria hace más de diez años.

Tengo colegas con un proceso de organización sólido desde el correo recibido (usando las conocidas carpetas de Lotus o Outlook) hasta los documentos que reciben o producen para los diferentes temas y cuentas usando una organización de carpetas específica.

Para mí, todo se deja en alguna carpeta, como Descargas, Escritorio, o una carpeta similar, y espero encontrar todo por ahí. Para los correos electrónicos, he resuelto este problema porque las capacidades de búsqueda de Gmail son tan poderosas que pueden recuperar cualquier correo en segundos, pero encontrar y organizar mis archivos es mucho más complejo.

Debido a eso, he estado buscando una herramienta para hacer todo este trabajo por mí porque sé que no puedo hacerlo. Puedo intentarlo… puedo hacerlo un día o tal vez dos, pero este es un hábito que no puedo mantener por un largo período de tiempo.

Así que, en esta búsqueda de opciones, he probado muchas cosas porque, en este tiempo, también he cambiado mucho de sistemas operativos, así que logré probar Hazel, FileJuggle, Drop, y así sucesivamente. Pero ninguno de ellos proporcionó la flexibilidad y la simplicidad que necesitaba al mismo tiempo. Y una y otra vez vuelvo a mi viejo amigo maid.

Maid es un proyecto creado por Ben Oakes que él define en sus propias palabras como un Hazel para Hackers, y eso es cierto. Así que proporciona las mismas capacidades que Hazel pero de una manera que es mucho más flexible para personas que tienen un trasfondo en programación.

Regla de ejemplo de maid para mover archivos pdf de Descargas a la carpeta Libros

Basado en Ruby On Rails, al final, tu tarea es tan fácil como definir las reglas que deseas aplicar usando este lenguaje. Pero para hacerlo más fácil y porque no es necesario ser un experto en Ruby para poder usar las herramientas, Ben ya ha desarrollado muchas funciones de ayuda para simplificar la creación de estas reglas.

Funciones de ayuda como weeks.accessed, downloaded_from, image_px, y al mismo tiempo las acciones comunes como move, trash, o copy.

Así que, al final, es como si codificaras tus reglas usando un lenguaje de muy alto nivel, como cuando usas una GUI en otros programas como Hazel. Pero al mismo tiempo, como esto es código, también tienes toda la flexibilidad y poder a tu disposición para ser usado cuando lo necesites.

Instalar las herramientas es tan fácil como simplemente escribir los siguientes comandos:

gem install maid
maid sample

Y después de eso, tendrás un archivo de reglas de ejemplo en tu carpeta .maid para ayudarte a crear el conjunto inicial de reglas. Y después de ese punto, solo estás limitado por tus necesidades y tu imaginación para finalmente manejar esta locura de archivos en la que, al menos yo, he estado durante mucho tiempo.

Promtail: El eslabón perdido entre registros y métricas para tu plataforma de monitoreo

por

Promtail es la solución cuando necesitas proporcionar métricas que solo están presentes en los rastros de registro del software que necesitas monitorear para proporcionar una plataforma de monitoreo consistente

Promtail: El Vínculo Perdido entre Registros y Métricas para tu Plataforma de Monitoreo.
Foto de SOULSANA en Unsplash

Es un entendimiento común que tres pilares en el mundo de la observabilidad nos ayudan a obtener una vista completa del estado de nuestras propias plataformas y sistemas: Registros, Trazas y Métricas.

Para proporcionar un resumen de las diferencias entre cada uno de ellos:

  • Las métricas son los contadores sobre el estado de los diferentes componentes desde una vista técnica y de negocio. Así que aquí podemos ver cosas como el consumo de CPU, el número de solicitudes, el uso de memoria o disco…
  • Los registros son los diferentes mensajes que cada una de las piezas de software en nuestra plataforma proporciona para entender su comportamiento actual y detectar algunas situaciones no esperadas.
  • La traza es la diferente información sobre el flujo de solicitudes de extremo a extremo a través de la plataforma con los servicios y sistemas que han sido parte de ese flujo y datos relacionados con esa solicitud concreta.

Tenemos soluciones que afirman abordar todos ellos, principalmente en el software empresarial con Dynatrace, AppDynamics y similares. Y por otro lado, intentamos ir con una solución específica para cada uno de ellos que podamos integrar fácilmente juntos y hemos discutido mucho sobre esas opciones en artículos anteriores.

Pero, algunas situaciones en ese software no funcionan siguiendo este camino porque vivimos en la era más heterogénea. Todos abrazamos, en algún nivel, el enfoque políglota en las nuevas plataformas. En algunos casos, podemos ver que el software está utilizando rastros de registro para proporcionar datos relacionados con métricas u otros asuntos, y aquí es cuando necesitamos confiar en piezas de software que nos ayuden a «arreglar» esa situación, y Promtail hace específicamente eso.

Promtail es principalmente un reenviador de registros similar a otros como fluentd o fluent-bit de CNCF o logstash del stack ELK. En este caso, esta es la solución de Grafana Labs, y como puedes imaginar, esto es parte del stack de Grafana con Loki para ser el «cerebro» que cubrimos en este artículo que te recomiendo que eches un vistazo si aún no lo has leído:

Descubre Loki: Una Alternativa Ligera al stack ELK

Aprende sobre el nuevo sistema de agregación de logs horizontalmente escalable, altamente disponible y multi-tenant inspirado por Prometheus que puede ser la mejor opción para tu arquitectura de logging Foto por Anthony Martino en Unsplash Cuando hablamos de Arquitectura Cloud-Native, la agregación de logs es algo clave que necesitas considerar. Las viejas prácticas que seguimos en las máquinas virtuales on-premises […]

Promtail tiene dos formas principales de comportarse como parte de esta arquitectura, y la primera es muy similar a otras en este espacio, como comentamos antes. Nos ayuda a enviar nuestros rastros de registro desde nuestros contenedores a la ubicación central que principalmente será Loki y puede ser una diferente y proporcionar las opciones habituales para jugar y transformar esos rastros como podemos hacer en otras soluciones. Puedes ver todas las opciones en el enlace a continuación, pero como puedes imaginar, esto incluye transformación, filtrado, análisis, y así sucesivamente.

Etapas

Etapas Esta sección es una colección de todas las etapas que Promtail soporta en una Tubería. Etapas de análisis: docker: Extraer datos analizando la línea de registro usando el …

Pero lo que hace a promtail tan diferente es solo una de las acciones que puedes hacer, y esa acción es metrics. Metrics proporciona una forma específica de, basado en los datos que estamos leyendo de los registros, crear métricas de Prometheus que un servidor de Prometheus puede recolectar. Eso significa que puedes usar los rastros de registro que estás procesando que pueden ser algo como esto:

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 123
[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 191
[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 522

Con esta información aparte de enviar esas métricas a la ubicación central para crear una llamada de métrica, por ejemplo: `total_request_count` que será generada por el agente promtail y también expuesta por él y siendo capaz también de usar un enfoque de métricas incluso para sistemas o componentes que no proporcionan una forma estándar de hacer eso como una API de métricas formal.

Y la forma de hacer esto está muy bien integrada con la configuración. Esto se hace con una etapa adicional (así es como llamamos a las acciones que podemos hacer en Promtail) que se llama metrics.

El esquema de esa etapa de métrica es sencillo, y si estás familiarizado con Prometheus, verás lo directo que es desde una definición de métricas de Prometheus a este fragmento:

# Un mapa donde la clave es el nombre de la métrica y el valor es un tipo de
# métrica específico.
metrics:
  [<string>: [ <metric_counter> | <metric_gauge> | <metric_histogram> ] ...]

Así que comenzamos definiendo el tipo de métricas que nos gustaría definir, y tenemos las habituales: contador, gauge o histograma, y para cada uno de ellos, tenemos un conjunto de opciones para poder declarar nuestras métricas como puedes ver aquí para una Métrica de Contador

# El tipo de métrica. Debe ser Counter.
type: Counter

# Describe la métrica.

[description: <string>]

# Define un nombre de prefijo personalizado para la métrica. Si no está definido, el nombre predeterminado «promtail_custom_» será prefijado.

[prefix: <string>]

# Clave del mapa de datos extraídos para usar en la métrica, # por defecto al nombre de la métrica si no está presente.

[source: <string>]

# Los valores de las etiquetas en las métricas son dinámicos, lo que puede causar que las métricas exportadas se vuelvan obsoletas (por ejemplo, cuando un flujo deja de recibir registros). # Para prevenir el crecimiento ilimitado del endpoint /metrics, cualquier métrica que no haya sido actualizada dentro de este tiempo será eliminada. # Debe ser mayor o igual a ‘1s’, si no está definido el valor predeterminado es ‘5m’

[max_idle_duration: <string>]

config: # Si está presente y es verdadero, todas las líneas de registro serán contadas sin # intentar coincidir la fuente con el mapa extraído. # Es un error especificar `match_all: true` y también especificar un `value`

[match_all: <bool>]

# Si está presente y es verdadero, todos los bytes de la línea de registro serán contados. # Es un error especificar `count_entry_bytes: true` sin especificar `match_all: true` # Es un error especificar `count_entry_bytes: true` sin especificar `action: add`

[count_entry_bytes: <bool>]

# Filtra los datos de origen y solo cambia la métrica # si el valor objetivo coincide exactamente con la cadena proporcionada. # Si no está presente, todos los datos coincidirán.

[value: <string>]

# Debe ser «inc» o «add» (insensible a mayúsculas). Si # se elige inc, el valor de la métrica aumentará en 1 por cada # línea de registro recibida que pase el filtro. Si se elige add, # el valor extraído debe ser convertible a un flotante positivo # y su valor se sumará a la métrica. action: <string>

Y con eso, tendrás tu métrica creada y expuesta, solo esperando que un servidor de Prometheus la recolecte. Si te gustaría ver todas las opciones disponibles, toda esta documentación está disponible en la documentación de Grafana Labs que puedes consultar en el enlace:

metrics

etapa de métricas La etapa de métricas es una etapa de acción que permite definir y actualizar métricas basadas en datos del mapa extraído. Nota que creado …

Espero que encuentres esto interesante y una forma útil de mantener toda tu información de observabilidad gestionada correctamente usando la solución adecuada y proporcionar una solución para estas piezas de software que no siguen tu paradigma.

Portainer: Un software visionario y un viaje de evolución

por

Descubre el estado actual de las primeras interfaces gráficas para contenedores docker y cómo proporciona una solución para las plataformas de contenedores modernas

Foto de HyoSun Rosy Ko en Unsplash

Quiero comenzar este artículo con una historia que no estoy seguro de que todos ustedes, increíbles lectores, conozcan. Hubo un tiempo en que no había interfaces gráficas para monitorear tus contenedores. Fue hace mucho tiempo, entendiendo mucho tiempo como podemos hacerlo en el mundo de los contenedores. Tal vez esto fue en 2014-2015 cuando Kubernetes estaba en su etapa inicial, y también, Docker Swarm acababa de ser lanzado y parecía la solución más confiable.

Así que la mayoría de nosotros no teníamos una plataforma de contenedores como tal. Simplemente ejecutábamos nuestros contenedores desde nuestras propias laptops o pequeños servidores para empresas de vanguardia usando comandos de docker directamente y sin más ayuda que la herramienta CLI. Como puedes ver, las cosas han cambiado mucho desde entonces, y si te gustaría refrescar esa visión, puedes consultar el artículo compartido a continuación:

Descubre Tu Herramienta Perfecta para Gestionar Kubernetes

Maximizando la productividad de trabajar con el entorno de Kubernetes con una herramienta para cada persona Foto de Christina @ wocintechchat.com en Unsplash Todos sabemos que Kubernetes es el entorno predeterminado para todas nuestras nuevas aplicaciones que desarrollamos construiremos. El sabor de esa plataforma Kubernetes puede ser de diferentes maneras y formas, pero una cosa es […]

Y en ese momento, un proyecto de código abierto proporciona la solución más increíble porque no sabíamos que necesitábamos eso hasta que lo usamos, y esa opción era portainer. Portainer proporciona una interfaz web muy impresionante donde puedes ver todos los contenedores docker desplegados en tu host docker y desplegar como otra plataforma.

Portainer: Un Software Visionario y un Viaje de Evolución
Página web de portainer en 2017 de https://ostechnix.com/portainer-an-easiest-way-to-manage-docker/

Fue el primero y generó un impacto tremendo, incluso generó una serie de otros proyectos que fueron nombrados: el portainer de… como dodo el portainer de la infraestructura de Kubernetes en ese momento.

Pero tal vez te preguntes… ¿y cómo está portainer? ¿sigue siendo portainer una cosa? Sigue vivo y coleando, como puedes ver en su página de proyecto de GitHub: https://github.com/portainer/portainer, con el último lanzamiento a finales de mayo de 2021.

Ahora tienen una versión Business pero aún como Community Edition, que es la que voy a estar analizando aquí con más detalle en otro artículo. Aún así, me gustaría proporcionar algunos aspectos destacados iniciales:

  • El proceso de instalación sigue el mismo enfoque que los lanzamientos iniciales para ser otro componente de tu clúster. Las opciones para ser utilizadas en Docker, Docker Swarm o Kubernetes cubren todas las soluciones principales que todas las empresas utilizan.

Introducción – Documentación de Portainer

Estas instrucciones son para Portainer Community Edition (CE). Para Portainer Business Edition (BE), consulta la documentación de BE.
  • Ahora proporciona una lista de plantillas de aplicaciones similar a la lista del Catálogo de Openshift, y también puedes crear las tuyas propias. Esto es muy útil para las empresas que suelen depender de estas plantillas para permitir a los desarrolladores usar un enfoque común de despliegue sin necesidad de hacer todo el trabajo.
Vista de Plantilla de Aplicación de Portainer 2.5.1
  • Las capacidades de Gestión de Equipos pueden definir usuarios con acceso a la plataforma y agrupar a esos usuarios como parte del equipo para una gestión de permisos más granular.
  • Soporte multi-registro: Por defecto, se integrará con Docker Hub, pero también puedes agregar tus propios registros y poder extraer imágenes directamente de esos directamente desde la GUI.

En resumen, esta es una gran evolución de la herramienta portainer mientras mantiene el mismo espíritu que todos los antiguos usuarios amaban en ese momento: Simplicidad y Enfoque en lo que un Administrador o Desarrollador necesita saber, pero también agregando más características y capacidades para mantener el ritmo de la evolución en la industria de plataformas de contenedores.

Apache NetBeans sigue siendo mi opción preferida para el desarrollo en Java

por

Descubre cuáles son las razones por las que, para mí, Apache NetBeans sigue siendo el mejor IDE de Java que puedes usar

Foto de Maximilian Weisbecker en Unsplash

Permíteme empezar desde el principio. Siempre he sido un Desarrollador Java desde mi tiempo en la Universidad. Aunque primero aprendí otro lenguaje de programación menos conocido (Modula-2), rápidamente pasé a Java para hacer todas las diferentes tareas y prácticamente cada tarea en mi camino como estudiante y luego como ingeniero de software.

Siempre estaba buscando el mejor IDE que pudiera encontrar para acelerar mis tareas de programación. La principal opción era Eclipse en la universidad, pero nunca fui fan de Eclipse, y eso se convirtió en un problema.

Si estás en la industria del Software Empresarial, habrás notado que prácticamente todas las herramientas basadas en Desarrolladores están basadas en Eclipse porque su licencia y la comunidad detrás lo hacen la mejor opción. Pero nunca pensé que Eclipse fuera un gran IDE, era demasiado flexible pero al mismo tiempo demasiado complejo.

Así que en ese momento es cuando descubrí NetBeans. Creo que la primera versión que probé fue en la rama 3.x, y Sun Microsystem lo desarrolló en ese momento. Era mucho mejor que Eclipse. De hecho, la cantidad de plugins disponibles no era comparable con Eclipse, pero las cosas que hacía, las hacía increíblemente bien.

Para mí, si necesito declarar por qué en ese momento NetBeans era mejor que Eclipse, probablemente las principales cosas serían estas:

  • Simplicidad en la Configuración de Ejecución: Aún creo que la mayoría de los IDE de Java hacen las cosas demasiado complejas solo para ejecutar el código. NetBeans simplemente ejecuta sin necesidad de crear una Configuración de Ejecución y configurarla (puedes hacerlo, pero no estás obligado a hacerlo)
  • Mejor Apariencia: Esto se basa más en una preferencia personal, pero prefiero la configuración predeterminada de NetBeans en comparación con Eclipse.

Así que por eso, NetBeans se convirtió en mi aplicación predeterminada para hacer mi Programación Java, pero Oracle llegó, y las cosas cambiaron un poco. Con la adquisición de Sun Microsystems por parte de Oracle, NetBeans se estancó como muchos otros proyectos de código abierto. Durante años no hubo muchas actualizaciones y progreso.

No es que hayan dejado de lado el producto, pero Oracle tenía un IDE diferente en ese momento, JDeveloper, que era la opción principal. Esto es fácil de entender. Continué siendo leal a NetBeans incluso cuando teníamos otro gran competidor: IntelliJ IDEA.

Esta es la opción elegante, la que la mayoría de los desarrolladores usan hoy en día para la programación en Java, y puedo entender por qué. He intentado varias veces en mi idea tratar de sentir las mismas sensaciones que otros tuvieron, y pude leer los diferentes artículos, y reconozco algunas de las ventajas de la solución:

  • Mejor rendimiento: Está claro que el tiempo de respuesta del IDE es mejor con IntelliJ IDEA que con NetBeans porque no proviene de un viaje de casi 20 años, y pudo comenzar desde cero y usar enfoques modernos para la GUI.
  • Menos Recursos de Memoria: Seamos honestos: Todos los IDE consumen toneladas de memoria. Ninguno lo hace genial aquí (a menos que estés hablando de editores de texto con compilador de Java; esa es otra historia). NetBeans de hecho requiere más recursos para funcionar correctamente.

Así que, hice el cambio y comencé a usar la solución de JetBrains, pero nunca me convenció, porque para mí sigue siendo demasiado complejo. Muchas cosas elegantes, pero menos enfoque en las que necesito. O, simplemente porque estaba demasiado acostumbrado a cómo NetBeans hace las cosas, no pude hacer el cambio mental que se requiere para adoptar una nueva herramienta.

Y entonces… cuando todo parecía perdido, algo increíble sucedió: NetBeans fue donado a la Fundación Apache y se convirtió en Apache NetBeans. Parece una nueva vida para la herramienta proporcionando cosas simples como el Modo Oscuro y manteniendo la solución actualizada con el progreso en el Desarrollo de Java.

Así que, hoy, Apache NetBeans sigue siendo mi IDE preferido, y no podría recomendar más el uso de esta increíble herramienta. Y estos son los puntos principales que me gustaría destacar aquí:

  • Mejor Gestión de Maven: Para mí, la forma y la simplicidad con la que puedes gestionar tu proyecto Maven con NetBeans está fuera de esta liga. Es simple y se enfoca en el rendimiento, agregando una nueva dependencia sin ir al archivo pom.xml, actualizando dependencias sobre la marcha.
  • Configuración de Ejecución: Nuevamente, esto sigue siendo un diferenciador. Cuando estoy codificando algo rápido debido a un nuevo tipo de utilidad, no me gusta perder tiempo creando configuraciones de ejecución o agregando un plugin maven exec a mi pom.xml para ejecutar el software que acabo de codificar. En su lugar, necesito hacer clic en Ejecutar, un botón verde, y dejar que la magia comience.
  • No hay necesidad de todo lo demás: Las cosas evolucionan demasiado rápido en el mundo de la programación Java, pero incluso hoy, nunca siento que me falte alguna capacidad o algo en mi IDE NetBeans que podría obtener si me muevo a una alternativa más moderna. Así que, no hay concesiones aquí a este nivel.

Así que, soy consciente de que probablemente mi elección se deba a que tengo una visión sesgada de esta situación. Después de todo, esta ha sido mi solución principal durante más de una década, y simplemente estoy acostumbrado a ella. Pero me considero una persona abierta, y si viera una diferencia clara, no tendría dudas en abandonar NetBeans como lo hice con muchas otras soluciones en el pasado (Evernote, OneNote, Apple Mail, Gmail, KDE Basket, Things, Wunderstling.. )

Así que, si tienes curiosidad por ver cómo ha progresado Apache NetBeans, por favor echa un vistazo a la última versión y dale una oportunidad. O, si sientes que no conectas con la herramienta actual, dale una oportunidad de nuevo. ¡¡¡Quizás tengas la misma visión sesgada que yo!!!