Bucles de Helm: Truco de Helm #1

Bucles de Helm: Truco de Helm #1

Introducción

Descubre cómo agregar bucles de Helm a tus helm charts para proporcionar un comportamiento más dinámico a tus Helm Charts.

Los Helm Charts se están convirtiendo en la solución predeterminada de facto cuando deseas empaquetar tu implementación de Kubernetes para poder distribuirla o instalarla rápidamente en tu sistema.

Definido varias veces como el apt para Kubernetes por su similitud con el antiguo gestor de paquetes de distribuciones GNU/Linux similares a Debian, parece seguir creciendo en popularidad cada mes en comparación con otras soluciones similares incluso más integradas en Kubernetes como Kustomize, como puedes ver en la imagen de Google Trends a continuación:

Helm Loops: Helm Charts vs Kustomize

Pero crear estos helm charts no es tan fácil como parece. Si ya has estado trabajando en ello, probablemente te hayas atascado en algún punto, o hayas pasado mucho tiempo tratando de hacer algunas cosas. Si es la primera vez que estás creando uno o intentando hacer algo avanzado, espero que todos estos trucos te ayuden en tu camino. Hoy vamos a cubrir uno de los trucos más importantes, y esos son los bucles de Helm.

Introducción a los Bucles de Helm

Si ves cualquier helm chart, seguro que tendrás muchos bloques condicionales. Prácticamente todo está cubierto bajo una estructura if/else basada en los archivos values.yml que estás creando. Pero esto se vuelve un poco complicado cuando hablamos de bucles. Pero lo bueno es que tendrás la opción de ejecutar un bucle de helm dentro de tus helm charts usando la primitiva range.

¿Cómo crear un Bucle de Helm?

El uso de la primitiva range es bastante simple, ya que solo necesitas especificar el elemento que deseas iterar, como se muestra en el fragmento a continuación:

{{- range .Values.pizzaToppings }}
- {{ . | title | quote }}
{{- end }}    

Este es un ejemplo bastante simple donde el yaml iterará sobre los valores que has asignado a la estructura pizzaToppings en tu values.yml.

Hay algunos conceptos a tener en cuenta en esta situación:

  • Puedes acceder fácilmente a todo dentro de esta estructura que estás recorriendo. Entonces, si el ingrediente de la pizza tiene campos adicionales, puedes acceder a ellos con algo similar a esto:
{{- range.Values.pizzaToppings }}
- {{ .ingredient.name | title | quote }}
{{- end }}    

Y esto accederá a una estructura similar a esta en tu values.yml:

 pizzaToppings:
	- ingredient:
		name: Piña
		weight: 3

Lo bueno es que puedes acceder a su atributo subyacente sin replicar toda la jerarquía principal hasta llegar a la estructura de bucle porque dentro de la sección de rango, el alcance ha cambiado. Nos referiremos a la raíz de cada elemento que estamos iterando.

¿Cómo acceder a elementos principales dentro de un Bucle de Helm?

En la sección anterior, cubrimos cómo podemos acceder fácilmente al atributo interno dentro de la estructura de bucle debido al cambio de alcance, lo que también tiene un problema. En caso de que quiera acceder a algún elemento en el padre de mi archivo values.yml o en algún lugar fuera de la estructura, ¿cómo puedo acceder a ellos?

Lo bueno es que también tenemos una gran respuesta para eso, pero puedes llegar allí. Necesitamos entender un poco sobre los alcances en Helm.

Como se comentó, . se refiere al elemento raíz en el alcance actual. Si nunca has definido una sección de rango u otra primitiva que cambie el contexto, . siempre se referirá a la raíz de tu values.yml. Es por eso que cuando ves un helm chart, ves todas las estructuras con la siguiente forma de trabajar: .Values.x.y.z, pero ya hemos visto que cuando tenemos una sección range, esto está cambiando, por lo que esta no es una buena manera.

Para resolver eso, tenemos el contexto $ que se refiere constantemente a la raíz del values.yml sin importar cuál sea el alcance actual. Así que eso significa que si tengo el siguiente values.yml:

base:
	- type: slim 
pizzaToppings:
	- ingredient:
		name: Piña
		weight: 3
	- ingredient:
		name: Manzana
		weight: 3

Y quiero referirme al tipo base dentro de la sección de rango similar a antes, puedo hacerlo usando el siguiente fragmento:

{{- range .Values.pizzaToppings }}
- {{ .ingredient.name | title | quote }} {{ $.Values.base.type }}
{{- end }}    

Eso generará la siguiente salida:

 - Piña slim
 - Manzana slim

¡Así que espero que este truco de helm chart te ayude con la creación, modificación o mejora de tus helm charts mejorados en el futuro utilizando bucles de helm sin ninguna preocupación adicional!

Operador de Registro de BanzaiCloud en Kubernetes Simplificado en 5 minutos

Operador de Registro de BanzaiCloud en Kubernetes Simplificado en 5 minutos

En el artículo anterior, describimos qué capacidad proporciona BanzaiCloud Logging Operator y sus características principales. Así que hoy vamos a ver cómo podemos implementarlo.

Lo primero que necesitamos hacer es instalar el operador en sí, y para hacerlo, tenemos un chart de helm a nuestra disposición, así que lo único que necesitaremos hacer son los siguientes comandos:

 helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com
helm upgrade --install --wait --create-namespace --namespace logging logging-operator banzaicloud-stable/logging-operator

Eso creará un namespace de logging (en caso de que aún no lo tengas), y desplegará los componentes del operador en sí, como puedes ver en la imagen a continuación:

Operador de Registro de BanzaiCloud en Kubernetes Simplificado en 5 minutos
BanzaiCloud Logging Operator instalado usando HelmChart

Así que, ahora podemos empezar a crear los recursos que necesitamos usando el CRD que comentamos en el artículo anterior, pero para hacer un resumen. Estos son los que tenemos a nuestra disposición:

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

Así que, primero que nada, vamos a definir nuestro escenario. No quiero hacer algo complejo; deseo que todos los logs que mis cargas de trabajo generen, sin importar en qué namespace estén, sean enviados a una instancia de Grafana Loki que también he instalado en ese clúster de Kubernetes en un endpoint específico usando la configuración Simple Scalable para Grafana Loki.

Así que, comencemos con los componentes que necesitamos. Primero, necesitamos un objeto de Logging para definir mi infraestructura de Logging, y lo crearé con el siguiente comando.

kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
  name: default-logging-simple
spec:
  fluentd: {}
  fluentbit: {}
  controlNamespace: logging
EOF

Mantendremos la configuración predeterminada para fluentd y fluent-bit solo por el bien del ejemplo, y más adelante en próximos artículos, podemos hablar sobre un diseño específico, pero eso es todo.

Una vez que el CRD se procese, los componentes aparecerán en tu namespace de logging. En mi caso, que estoy usando un clúster de 3 nodos, veré 3 instancias de fluent-bit desplegadas como un DaemonSet y un solo ejemplo de fluentd, como puedes ver en la imagen a continuación:

Operador de Registro de BanzaiCloud en Kubernetes Simplificado en 5 minutos
Configuración de BanzaiCloud Logging Operator después de aplicar el CRD de Logging

Así que, ahora necesitamos definir la comunicación con Loki, y como me gustaría usar esto para cualquier namespace que pueda tener en mi clúster, usaré la opción ClusterOutput en lugar de la normal Output que está basada en namespace. Y para hacer eso, usaremos el siguiente comando (por favor asegúrate de que el endpoint sea el correcto; en nuestro caso, este es loki-gateway.default ya que está ejecutándose dentro del clúster de Kubernetes:

kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
 name: loki-output
spec:
 loki:
   url: http://loki-gateway.default
   configure_kubernetes_labels: true
   buffer:
     timekey: 1m
     timekey_wait: 30s
     timekey_use_utc: true
EOF

Y prácticamente tenemos todo; solo necesitamos un flujo para comunicar nuestra configuración de Logging al ClusterOutput que acabamos de crear. Y nuevamente, iremos con el ClusterFlow porque nos gustaría definir esto a nivel de Clúster y no de manera basada en namespace. Así que usaremos el siguiente comando:

 kubectl -n logging  apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
  name: loki-flow
spec:
  filters:
    - tag_normaliser: {}
  match:
    - select: {}
  globalOutputRefs:
    - loki-output
EOF

Y después de un tiempo para recargar la configuración (1-2 minutos más o menos), comenzarás a ver en los rastros de Loki algo como esto:

Operador de Registro de BanzaiCloud en Kubernetes Simplificado en 5 minutos
Grafana mostrando los logs enviados por el BanzaiCloud Logging Operator

Y eso indica que ya estamos recibiendo el envío de logs de los diferentes componentes, principalmente el elemento fluentd que configuramos en este caso. Pero creo que es mejor verlo gráficamente con Grafana:

Operador de Registro de BanzaiCloud en Kubernetes Simplificado en 5 minutos
Grafana mostrando los logs enviados por el BanzaiCloud Logging Operator

¡Y eso es todo! Y cambiar nuestra configuración de logging es tan simple como cambiar el componente CRD que definimos, aplicando coincidencias y filtros, o enviándolo a un nuevo lugar. De manera sencilla, tenemos esto completamente gestionado.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

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

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

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

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

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

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

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

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

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

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

Aprende a Escribir Manifiestos YAML de Kubernetes de Manera Más Eficiente
Diálogo de Selección de Plantillas de Monokle

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

Aprende a Escribir Manifiestos YAML de Kubernetes de Manera Más Eficiente
Proceso de Población de Valores de Plantilla de Monokle

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

Aprende a Escribir Manifiestos YAML de Kubernetes de Manera Más Eficiente
Modificación de Helm Chart usando Monokle

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

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

Aprende a Escribir Manifiestos YAML de Kubernetes de Manera Más Eficiente
Monokle es parte del Paisaje de la Fundación CNCF

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

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

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

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

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

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

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

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

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

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

Clasificación de Módulos de TIBCO BW

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

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

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

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

Limitaciones de los Módulos de TIBCO BW

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

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

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

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

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

Casos de Uso de los Módulos de TIBCO BW

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

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

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

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

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

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

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

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

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

TIBCO BW + EMS: Conexión Directa

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

Aprende ahora 2 maneras de configurar la reconexión de TIBCO BW EMS
TIBCO BW + EMS: Conexión Directa

 TIBCO BW + EMS: Conexión JNDI

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

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

Aprende ahora 2 maneras de configurar la reconexión de TIBCO BW EMS
Aprende ahora 2 maneras de configurar la reconexión de TIBCO BW EMS
 TIBCO BW + EMS: Conexión JNDI

Propiedades de Reconexión de TIBCO EMS

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


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

Las propiedades concretas son las siguientes:

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

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

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

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

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

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

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

Pros y Contras

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

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

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

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Integración de TIBCO BW y EMS

Integración de TIBCO BW y EMS

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

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

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

Descripción del problema

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

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

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

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

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

Integración de TIBCO BW y EMS

Proceso de instalación

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

 TIBCO_HOME/bw/<version>/bin

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

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

 ./bwinstall ems-driver

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

Integración de TIBCO BW y EMS

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

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

Operadores de Kubernetes: 5 cosas que realmente necesitas saber

Operadores de Kubernetes: 5 cosas que realmente necesitas saber
Operadores de Kubernetes: 5 Cosas Que Realmente Necesitas Saber
Operadores de Kubernetes: 5 Cosas Que Realmente Necesitas Saber (Foto por Dan Lohmar en Unsplash)

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

¿Qué Son los Operadores de Kubernetes?

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

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

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

¿Cómo Funciona el Operador de Kubernetes?

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

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

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

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

¿Cómo Gestionar los Operadores de Kubernetes?

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

OperatorHub: Repositorio Central para Operadores de Kubernetes
OperatorHub: Repositorio Central para Operadores de Kubernetes

Operador de Kubernetes vs. Helm Charts

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

Cómo Construir un Operador de Kubernetes

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

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

 Más Recursos Para Aprender sobre el Operador de Kubernetes

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

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

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

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

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.