Alexandre Vazquez

Kiali: Guía Esencial para Gestionar Istio Service Mesh

por
Kiali: Guía Esencial para Gestionar Istio Service Mesh

¿Qué es Kiali?

Kiali es un proyecto de código abierto que proporciona observabilidad para tu malla de servicios Istio. Desarrollado por Red Hat, Kiali ayuda a los usuarios a entender la estructura y el comportamiento de su malla y cualquier problema que pueda surgir.

Kiali proporciona una representación gráfica de tu malla, mostrando las relaciones entre los diversos componentes de la malla de servicios, como servicios, servicios virtuales, reglas de destino y más. También muestra métricas vitales, como tasas de solicitudes y errores, para ayudarte a monitorear la salud de tu malla e identificar posibles problemas.

 ¿Cuáles son las principales capacidades de Kiali?

Una de las características clave de Kiali es su capacidad para visualizar la comunicación de servicio a servicio dentro de una malla. Esto permite a los usuarios ver rápidamente cómo están conectados los servicios y cómo se enrutan las solicitudes a través de la malla. Esto es particularmente útil para la resolución de problemas, ya que puede ayudarte a identificar rápidamente problemas con la comunicación de servicios, como reglas de enrutamiento mal configuradas o tiempos de respuesta lentos.

Kiali 101: Comprendiendo y Utilizando esta Herramienta Esencial de Gestión de Malla de Servicios

Kiali también proporciona varias herramientas para monitorear la salud de tu malla. Por ejemplo, puede alertarte sobre problemas potenciales, como una alta tasa de errores o un servicio que no responde a las solicitudes. También proporciona información de seguimiento detallada, permitiéndote ver el camino exacto que tomó una solicitud a través de la malla y dónde pudieron haber ocurrido problemas.

Además de sus características de observabilidad, Kiali proporciona varias otras herramientas para gestionar tu malla de servicios. Por ejemplo, incluye un módulo de gestión de tráfico, que te permite controlar fácilmente el flujo de tráfico a través de tu malla, y un módulo de gestión de configuración, que te ayuda a gestionar y mantener los diversos componentes de tu malla.

En general, Kiali es una herramienta esencial para cualquiera que use una malla de servicios Istio. Proporciona valiosos conocimientos sobre la estructura y el comportamiento de tu malla, así como potentes herramientas de monitoreo y gestión. Ya sea que estés comenzando con Istio o seas un usuario experimentado, Kiali puede ayudar a garantizar que tu malla de servicios funcione de manera fluida y eficiente.

¿Cuáles son los principales beneficios de usar Kiali?

Los principales beneficios de usar Kiali son:

  • Mejorada observabilidad de tu malla de servicios Istio. Kiali proporciona una representación gráfica de tu malla, mostrando las relaciones entre diferentes componentes de la malla de servicios y mostrando métricas clave. Esto te permite entender rápidamente la estructura y el comportamiento de tu malla e identificar posibles problemas.
  • Facilita la resolución de problemas. La visualización de Kiali de la comunicación de servicio a servicio y la información de seguimiento detallada facilitan la identificación de problemas con la comunicación de servicios y localizar la fuente de cualquier problema.
  • Mejorada gestión del tráfico. Kiali incluye un módulo de gestión de tráfico que te permite controlar fácilmente el flujo de tráfico a través de tu malla.
  • Mejorada gestión de configuración. El módulo de gestión de configuración de Kiali te ayuda a gestionar y mantener los diversos componentes de tu malla.

¿Cómo instalar Kiali?

Hay varias formas de instalar Kiali como parte de tu implementación de Malla de Servicios, siendo la opción preferida usar el modelo de Operador disponible aquí.

Puedes instalar este operador usando Helm o OperatorHub. Para instalarlo usando Helm Charts, necesitas agregar el siguiente repositorio usando este comando:

 helm repo add kiali https://kiali.org/helm-charts

** Recuerda que una vez que agregues un nuevo repositorio, necesitas ejecutar el siguiente comando para actualizar los charts disponibles

helm repo update

Ahora, puedes instalarlo usando el comando helm install tal como en el siguiente ejemplo:

helm install 
    --set cr.create=true 
    --set cr.namespace=istio-system 
    --namespace kiali-operator 
    --create-namespace 
    kiali-operator 
    kiali/kiali-operator

Si prefieres seguir la ruta de OperatorHub, puedes usar la siguiente URL . Ahora, al hacer clic en el botón de Instalar, verás los pasos para tener el componente instalado en tu entorno de Kubernetes.

Kiali 101: Comprendiendo y Utilizando esta Herramienta Esencial de Gestión de Malla de Servicios

En caso de que desees una instalación simple de Kiali, también puedes usar el YAML de muestra disponible dentro de la carpeta de instalación de Istio usando el siguiente comando:

kubectl apply -f $ISTIO_HOME/samples/addons/kiali.yaml

¿Cómo funciona Kiali?

Kiali es solo la representación gráfica de la información disponible sobre cómo funciona la malla de servicios. Por lo tanto, no es responsabilidad de Kiali almacenar esas métricas, sino recuperarlas y dibujarlas de manera relevante para el usuario de la herramienta.

Prometheus realiza el almacenamiento de estos datos, por lo que Kiali utiliza la API REST de Prometheus para recuperar la información y dibujarla gráficamente, como puedes ver aquí:

  • Va a mostrar varias partes relevantes del gráfico. Mostrará el espacio de nombres seleccionado y dentro de ellos las diferentes aplicaciones (detectará una aplicación en caso de que tengas una etiqueta agregada a la carga de trabajo con el nombre app ). Dentro de cada aplicación se agregarán diferentes servicios y pods con otros íconos (triángulos para los servicios y cuadrados para los pods).
  • También mostrará cómo el tráfico llega al clúster a través de las diferentes puertas de enlace de entrada y cómo sale en caso de que tengamos alguna puerta de enlace de salida configurada.
  • Mostrará el tipo de tráfico que estamos manejando y las diferentes tasas de error basadas en el tipo de protocolo, como TCP, HTTP, y así sucesivamente, como puedes ver en la imagen a continuación. El protocolo se decide en base a una convención de nombres en el nombre del puerto del servicio con el formato esperado: nombre-del-protocolo
Kiali 101: Comprendiendo y Utilizando esta Herramienta Esencial de Gestión de Malla de Servicios

¿Puede Kiali usarse con cualquier malla de servicios?

No, Kiali está diseñado específicamente para su uso con mallas de servicios Istio.

Proporciona herramientas de observabilidad, monitoreo y gestión para mallas de servicios Istio, pero no es compatible con otras tecnologías de malla de servicios.

Si usas una malla de servicios diferente, necesitarás encontrar una herramienta adicional para gestionarla y monitorearla.

¿Existen otras alternativas a Kiali?

Aunque no puedas ver alternativas naturales a Kiali para visualizar tus cargas de trabajo y tráfico a través de la Malla de Servicios Istio, puedes usar otras herramientas para obtener las métricas que alimentan a Kiali y tener una visualización personalizada usando herramientas más genéricas como Grafana, entre otras.

Hablemos de herramientas similares a Kiali para otras Mallas de Servicios, como Linkerd, Consul Connect, o incluso Kuma. La mayoría sigue un enfoque diferente donde la parte de visualización no es un «proyecto» separado, sino que se basa en una herramienta de visualización estándar. Eso te da mucha más flexibilidad, pero al mismo tiempo, carece de la excelente visualización del tráfico que proporciona Kiali, como vistas de gráficos o la capacidad de modificar el tráfico directamente desde la vista de gráficos.

📚 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.

Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado en 10 Minutos

por
Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado en 10 Minutos

Las plantillas de Helm en archivos, como el contenido de ConfigMaps o el contenido de Secrets, son uno de los requisitos más comunes cuando estás en el proceso de crear un nuevo helm chart. Como ya sabes, el Helm Charts es cómo usamos Kubernetes para empaquetar nuestros recursos de aplicación y YAML en un solo componente que podemos gestionar de una vez para facilitar el proceso de mantenimiento y operación.

Visión General de las Plantillas de Helm

Por defecto, el proceso de plantillas funciona con archivos YAML, permitiéndonos usar algunas variables y algunas funciones lógicas para personalizar y templar nuestros recursos YAML de Kubernetes según nuestras necesidades.

Entonces, en resumen, solo podemos tener archivos yaml dentro de la carpeta de plantillas de un YAML. Pero a veces nos gustaría hacer el mismo proceso en ConfigMaps o Secrets o ser más concretos con el contenido de esos ConfigMaps, por ejemplo, archivos de propiedades y así sucesivamente.

Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado
Plantillas de Helm en Archivos: Visión General de las Plantillas de Helm mostrando los Archivos fuera de las plantillas que usualmente se requieren

Como puedes ver, es bastante normal tener diferentes archivos como archivos de configuración json, archivos de propiedades, scripts de shell como parte de tu helm chart, y la mayoría de las veces te gustaría dar un enfoque dinámico a su contenido, y es por eso que usar Plantillas de Helm en Archivos es tan importante para ser el enfoque principal de este artículo

Funciones de Ayuda de Helm para Gestionar Archivos

Por defecto, Helm nos proporciona un conjunto de funciones para gestionar archivos como parte del helm chart para simplificar el proceso de incluirlos como parte del gráfico, como el contenido de ConfigMap o Secret. Algunas de estas funciones son las siguientes:

  • .Files.Glob: Esta función permite encontrar cualquier patrón de archivos internos que coincida con el patrón, como el siguiente ejemplo:
    { range $path, $ := .Files.Glob ".yaml" }
  • .Files.Get: Esta es la opción más simple para reunir el contenido de un archivo específico que conoces la ruta completa dentro de tu helm chart, como el siguiente ejemplo: {{ .Files.Get "config1.toml" | b64enc }}

Incluso puedes combinar ambas funciones para usarlas juntas como en el siguiente ejemplo:

 {{ range $path, $_ :=  .Files.Glob  "**.yaml" }}
      {{ $.Files.Get $path }}
{{ end }}

Luego puedes combinar eso una vez que tengas el archivo que deseas usar con algunas funciones de ayuda para introducir fácilmente en un ConfigMap y un Secret como se explica a continuación:

  • .AsConfig : Usa el contenido del archivo para ser introducido como ConfigMap manejando el patrón: nombre-del-archivo: contenido-del-archivo
  • .AsSecrets: Similar al anterior, pero haciendo la codificación base64 para los datos.

Aquí puedes ver un ejemplo real de usar este enfoque en una situación real de helm chart

apiVersion: v1
kind: Secret
metadata:
  name: zones-property
  namespace: {{ $.Release.Namespace }}
data: 
{{ ( $.Files.Glob "tml_zones_properties.json").AsSecrets | indent 2 }}

Puedes encontrar más información sobre eso aquí. Pero esto solo nos permite tomar el archivo tal cual e incluirlo en un ConfigMap. No nos permite hacer ninguna lógica o sustitución al contenido como parte de ese proceso. Entonces, si queremos modificar esto, este no es un ejemplo válido.

¿Cómo Usar Plantillas de Helm en Archivos como ConfigMaps o Secrets?

En caso de que podamos hacer algunas modificaciones al contenido, necesitamos usar la siguiente fórmula:

apiVersion: v1
kind: Secret
metadata:
  name: papi-property
  namespace: {{ $.Release.Namespace }}
data:
{{- range $path, $bytes := .Files.Glob "tml_papi_properties.json" }}
{{ base $path | indent 2 }}: {{ tpl ($.Files.Get $path) $ | b64enc }}
{{ end }}

Entonces, lo que estamos haciendo aquí es primero iterar por los archivos que coinciden con el patrón usando la función .Files.Glob que explicamos antes, iterando en caso de que tengamos más de uno. Luego creamos manualmente la estructura siguiendo el patrón: nombre-del-archivo: contenido-del-archivo.

Para hacer eso, usamos la función base para proporcionar solo el nombre del archivo desde una ruta completa (y agregar la indentación adecuada) y luego usamos .Files.Get para obtener el contenido del archivo y hacer la codificación base64 usando la función b64enc porque, en este caso, estamos manejando un secreto.

El truco aquí es agregar la función tpl que permite que el contenido de este archivo pase por el proceso de plantillas; así es como todas las modificaciones que necesitamos hacer y las variables referenciadas desde el objeto .Values serán reemplazadas adecuadamente, dándote todo el poder y flexibilidad del helm chart en archivos de texto como propiedades, archivos JSON y mucho más.

¡Espero que esto sea tan útil para ti como lo ha sido para mí al crear nuevos gráficos de helm! Y mira aquí para otros trucos usando bucles en helm o dependencias de helm.

Nomad vs Kubernetes: 1 contendiente emergente desafiando al rey probado

por
Nomad vs Kubernetes: 1 contendiente emergente desafiando al rey probado
Tabla de contenidos
  1. ¿Cuáles son las principales características de Nomad?
  2. Nomad vs Kubernetes: ¿Cómo funciona Nomad?
  3.  ¿Es Nomad un reemplazo para Kubernetes?

Nomad es la alternativa de Hashicorp al patrón típico de usar una plataforma basada en Kubernetes como la única forma de orquestar tus cargas de trabajo de manera eficiente. Nomad es un proyecto iniciado en 2019, pero está ganando mucha más relevancia hoy en día después de 95 lanzamientos, y la versión actual de este artículo es 1.4.1, como puedes ver en su perfil de GitHub.

Nomad aborda los desafíos tradicionales de aislar el ciclo de vida de la aplicación para el ciclo de vida de operación de la infraestructura donde reside esa aplicación. Sin embargo, en lugar de ir completamente a una aplicación basada en contenedores, intenta proporcionar una solución de manera diferente.

¿Cuáles son las principales características de Nomad?

Basado en su propia definición, como puedes leer en su perfil de GitHub, ya destacan algunos de los puntos de diferencia con respecto al estándar de facto de la industria:

Nomad es un orquestador de cargas de trabajo fácil de usar, flexible y de alto rendimiento que puede desplegar una mezcla de aplicaciones de microservicios, por lotes, contenedorizadas y no contenedorizadas

Fácil de usar: Esta es la primera afirmación que incluyen en su definición porque el enfoque de Nomad es mucho más simple que alternativas como Kubernetes porque funciona con un enfoque de binario único donde tiene todas las capacidades necesarias ejecutándose como un agente de nodo basado en su propio «vocabulario» que puedes leer más en su documentación oficial.

Flexibilidad: Esta es la otra cosa crítica que proporcionan, un hipervisor, una capa intermedia entre la aplicación y la infraestructura subyacente. No se limita solo a aplicaciones de contenedores, sino que también admite este tipo de despliegue. También permite desplegarlo como parte de un enfoque tradicional de máquina virtual. Los casos de uso principales destacados son ejecutar aplicaciones estándar de Windows, lo cual es complicado cuando se habla de despliegues de Kubernetes; aunque los contenedores de Windows han sido una cosa durante mucho tiempo, su adopción no está al mismo nivel, como puedes ver en el mundo de los contenedores de Linux.

Integración con Hashicorp: Como parte del portafolio de Hashicorp, también incluye una integración perfecta con otros proyectos de Hashicorp como Hashicorp Vault, que hemos cubierto en varios artículos, o Hashicorp Consul, que ayuda a proporcionar capacidades adicionales en términos de seguridad, gestión de configuración y comunicación entre las diferentes cargas de trabajo.

Nomad vs Kubernetes: ¿Cómo funciona Nomad?

Como se comentó anteriormente, Nomad cubre todo con un enfoque de componente único. Un binario de Nomad es un agente que puede trabajar en modo servidor o modo cliente, dependiendo del rol de la máquina que lo ejecuta.

Así que Nomad se basa en un clúster de Nomad, un conjunto de máquinas que ejecutan un agente de Nomad en modo servidor. Esos servidores se dividen dependiendo del rol de líder o seguidores. El líder realiza la mayor parte de la gestión del clúster, y los seguidores pueden crear planes de programación y enviarlos al líder para su aprobación y ejecución. Esto se representa en la imagen a continuación de la página oficial de Hashicorp Nomad:

Nomad vs Kubernetes: 1 Contendiente Contra el Rey de la Orquestación
Arquitectura simple de Nomad de nomadproject.io

Una vez que tenemos el clúster listo, necesitamos crear nuestros trabajos, y un trabajo es una definición de la tarea que nos gustaría ejecutar en el clúster de Nomad que hemos configurado previamente. Una tarea es la unidad de trabajo más pequeña en Nomad. Aquí es donde la flexibilidad llega a Nomad porque el controlador de tareas ejecuta cada tarea, permitiendo que diferentes controladores ejecuten varias cargas de trabajo. Así es como siguiendo el mismo enfoque, tendremos un controlador de Docker para ejecutar nuestro despliegue de contenedores o un controlador de ejecución para ejecutarlo sobre una infraestructura virtual. Aún así, puedes crear tus controladores de tareas siguiendo un mecanismo de complementos que puedes leer más sobre aquí.

Los trabajos y las tareas se definen utilizando un enfoque basado en texto, pero no siguiendo el tipo habitual de archivos YAML o JSON, sino un formato diferente, como puedes ver en la imagen a continuación (haz clic aquí para descargar el archivo completo del repositorio de muestras de GitHub Nomad):

 ¿Es Nomad un reemplazo para Kubernetes?

Es una pregunta compleja de responder, e incluso Hashicorp ha documentado diferentes estrategias. Sin duda, puedes usar Nomad para ejecutar despliegues basados en contenedores en lugar de ejecutarlos en Kubernetes. Pero al mismo tiempo, también posicionan la solución junto a Kubernetes para ejecutar algunas cargas de trabajo en una solución y otras en la otra.

Al final, ambos intentan resolver y abordar los mismos desafíos en términos de escalabilidad, compartición y optimización de infraestructura, agilidad, flexibilidad y seguridad de los despliegues tradicionales.

Kubernetes se centra en diferentes tipos de cargas de trabajo, pero todo sigue el mismo modo de despliegue (basado en contenedores) y adopta paradigmas recientes (basados en servicios, patrones de microservicios, liderados por API, etc.) con una arquitectura robusta que permite una excelente escalabilidad, rendimiento, flexibilidad y con niveles de adopción en la industria que se ha convertido en la única alternativa de facto actual para plataformas modernas de orquestación de cargas de trabajo.

Pero, al mismo tiempo, también requiere esfuerzo en la gestión y transformación de aplicaciones existentes a nuevos paradigmas.

Por otro lado, Nomad intenta abordarlo de manera diferente, minimizando el cambio de la aplicación existente para aprovechar los beneficios de la plataforma y reduciendo la sobrecarga de gestión y complejidad que una plataforma de Kubernetes habitual proporciona, dependiendo de la situación.

📚 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.

DevSecOps vs DevOps: Fundamentos y Diferencias Respondiendo a 3 Preguntas

por
DevSecOps vs DevOps: Fundamentos y Diferencias Respondiendo a 3 Preguntas
Tabla de contenidos
  1. ¿Qué es DevSecOps?
  2. ¿Por qué es importante DevSecOps?
  3. DevSecOps vs DevOps: ¿Es DevSecOps solo DevOps actualizado?
  4.  Resumen

DevSecOps vs. DevOps: Diferencias y Similitudes Respondiendo 3 Preguntas

DevSecOps es un concepto que probablemente has escuchado extensamente en los últimos meses. Lo verás en alineación con la idea tradicional de DevOps. Esto probablemente, en algún momento, te hace preguntarte sobre una comparación entre DevSecOps y DevOps, incluso tratando de entender cuáles son las principales diferencias entre ellos o si son el mismo concepto. Y también, con otras ideas comenzando a aparecer, como Ingeniería de Plataformas o Confiabilidad del Sitio, está comenzando a crear algo de confusión en el campo que me gustaría aclarar hoy en este artículo.

¿Qué es DevSecOps?

DevSecOps es una extensión del concepto y metodología DevOps. Ahora, no es un esfuerzo conjunto entre las prácticas de Desarrollo y Operación, sino un esfuerzo conjunto entre Desarrollo, Operación y Seguridad.

DevSecOps vs DevOps: Fundamentos y Diferencias Respondiendo a 3 Preguntas
Diagrama por GeekFlare: Una Introducción a DevSecOps (https://geekflare.com/devsecops-introduction/)

Implica introducir políticas, prácticas y herramientas de seguridad para asegurar que los ciclos de DevOps proporcionen seguridad a lo largo de este proceso. Ya comentamos sobre incluir componentes de seguridad para proporcionar un proceso de despliegue más seguro. Incluso tenemos artículos específicos sobre estas herramientas, como escáneres, registros de docker, etc.

¿Por qué es importante DevSecOps?

DevSecOps, o para ser más explícitos, incluir prácticas de seguridad como parte del proceso DevOps, es crítico porque nos estamos moviendo hacia arquitecturas híbridas y en la nube donde incorporamos nuevos patrones de diseño, despliegue y desarrollo como contenedores, microservicios, y así sucesivamente.

Esta situación hace que nos movamos de un lado a tener cientos de aplicaciones en los casos más complejos a miles de aplicaciones, y de tener docenas de servidores a miles de contenedores, cada uno de ellos con diferentes imágenes base y bibliotecas de terceros que pueden estar obsoletas, tener un agujero de seguridad o simplemente surgir nuevas vulnerabilidades como hemos visto en el pasado con el Spring Framework o la biblioteca Log4J para mencionar algunos de los problemas de seguridad globales sustanciales más recientes que las empresas enfrentaron.

Así que, incluso el equipo de seguridad más extenso no puede estar al ritmo revisando manualmente o con un conjunto de scripts todos los diferentes nuevos desafíos a la seguridad si no los incluimos como parte del proceso general de desarrollo y despliegue de los componentes. Aquí es donde el concepto de seguridad de cambio a la izquierda suele considerarse, y ya cubrimos eso en este artículo que puedes leer aquí.

DevSecOps vs DevOps: ¿Es DevSecOps solo DevOps actualizado?

Así que, basado en la definición anterior, puedes pensar: «Ok, entonces cuando alguien habla de DevOps no está pensando en seguridad». Esto no es cierto.

En el mismo aspecto, cuando hablamos de DevOps, no es explícitamente todos los pasos detallados, como aseguramiento de calidad del software, pruebas unitarias, etc. Así que, como sucede con muchas extensiones en esta industria, el concepto original, global o genérico incluye también los contenidos de las alas.

Así que, al final, DevOps y DevSecOps son lo mismo, especialmente hoy cuando todas las empresas y organizaciones se están moviendo a la nube o entornos híbridos donde la seguridad es crítica y no negociable. Por lo tanto, cada tarea que hacemos, desde desarrollar software hasta acceder a cualquier servicio, necesita hacerse con la Seguridad en mente. Pero usé ambos conceptos en diferentes escenarios. Usaré DevSecOps cuando me gustaría resaltar explícitamente el aspecto de seguridad debido a la audiencia, el contexto o el tema que estamos discutiendo para hacer diferenciación.

Aún así, en cualquier contexto genérico, DevOps incluirá las verificaciones de seguridad que se mantendrán con seguridad porque si no es así, simplemente es inútil. Yo.

 Resumen

Así que, al final, cuando alguien habla hoy sobre DevOps, implícitamente incluye el aspecto de seguridad, por lo que no hay diferencia entre ambos conceptos. Pero verás y también encontrarás útil usar el término específico DevSecOps cuando quieras resaltar o diferenciar esta parte del proceso.

Trivy: Logra escanear imágenes locales de Docker con éxito

por
Trivy: Logra escanear imágenes locales de Docker con éxito

Escanear imágenes de Docker o, para ser más honestos, escanear tus imágenes de contenedores se está convirtiendo en una de las tareas cotidianas a realizar como parte del desarrollo de tu aplicación. El cambio de ritmo de cuán fácilmente surgen las nuevas vulnerabilidades, la explosión de dependencias que tiene cada una de las imágenes de contenedores y la cantidad de implementaciones por empresa hacen que sea bastante complejo mantener el ritmo para asegurar que puedan mitigar los problemas de seguridad.

Ya cubrimos este tema hace algún tiempo cuando la herramienta Docker Desktop introdujo la opción de escaneo basada en una integración con Synk y, más recientemente, con el último lanzamiento de Lens. Esta es una de las opciones para verificar las imágenes de contenedores de la versión “corporativa” de la herramienta. Y desde hace algún tiempo también, los registros centrales de la Nube han proporcionado tal como un ECR, incluyendo la opción de Escaneo como una de las capacidades para cualquier imagen implementada allí.

Pero, ¿qué pasa si ya te estás moviendo de Docker Desktop a otra opción, como podman o Rancher Desktop? ¿Cómo puedes escanear tus imágenes de docker?

Varios escáneres pueden usarse para escanear tus imágenes de contenedores localmente, y algunos de ellos son más fáciles de configurar que otros. Uno de los más conocidos es Clair, que también se está utilizando como parte del registro RedHat Quay y tiene mucha tracción. Funciona en un modo cliente-servidor que es excelente para ser utilizado por diferentes equipos que requieren una implementación más “empresarial”, generalmente estrechamente relacionada con un Registro. Sin embargo, no se adapta bien para ejecutarse localmente ya que requiere varios componentes y relaciones.

Como una opción fácil para probar localmente, tienes Trivy. Trivy es una herramienta interesante desarrollada por AquaSecurity. Puede que recuerdes la empresa ya que es la que está detrás de otros desarrollos relacionados con la seguridad en Kubernetes, como KubeBench, que ya cubrimos en el pasado.

En sus propias palabras, “Trivy es un escáner de seguridad integral. Es confiable, rápido y sencillo de usar y funciona donde lo necesites.”

¿Cómo instalar Trivy?

El proceso de instalación es relativamente fácil y está documentado para cada plataforma importante aquí. Sin embargo, al final, se basa en paquetes binarios disponibles como RPM, DEB, Brew, MacPorts, o incluso una imagen de Docker.

¿Cómo escanear imágenes de Docker con Trivy?

Una vez instalado, puedes simplemente ejecutar los comandos como este:

 trivy image python:3.4-alpine

Esto realizará las siguientes tareas:

  • Actualizar la base de datos del repositorio con todas las vulnerabilidades
  • Descargar la imagen en caso de que no esté disponible localmente
  • Detectar los lenguajes y componentes presentes en esa imagen
  • Validar las imágenes y generar un resultado

¿Qué salida proporciona Trivy?

Como ejemplo, esta es la salida para el python:3.4-alpine a partir de hoy:

Escanear imágenes de Docker con Trivy

Obtendrás una tabla con una fila por cada biblioteca o componente que haya detectado una vulnerabilidad mostrando el nombre de la Biblioteca y la exposición relacionada con ella con el código CVE. El código CVE es generalmente cómo se refieren a las vulnerabilidades ya que están presentes en un repositorio común con todas sus descripciones y detalles. Además de eso, muestra la severidad de la vulnerabilidad basada en el informe existente. También proporciona la versión actual detectada en la imagen y en caso de que haya una versión diferente que haya solucionado esa vulnerabilidad, la versión inicial que ha resuelto esa vulnerabilidad, y finalmente, un título para proporcionar un poco más de contexto sobre la vulnerabilidad:

Trivy: Logra escanear imágenes locales de Docker con éxito

Si una Biblioteca está relacionada con más de una vulnerabilidad, dividirá las celdas en esa fila para acceder a los diferentes datos para cada vulnerabilidad.

📚 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.

Dependencia de Helm: Descubre Cómo Funciona

por
Dependencia de Helm: Descubre Cómo Funciona
Tabla de contenidos
  1. ¿Qué es una Dependencia de Helm?
  2. ¿Cómo declaramos una Dependencia de Helm?
  3. ¿Cómo declaro una Dependencia Condicional de Helm?
  4. ¿Cómo declaro una Dependencia de Helm con una versión diferente?

La Dependencia de Helm es una parte crítica para entender cómo funciona Helm, ya que es la forma de establecer relaciones entre diferentes paquetes de helm. Hemos hablado mucho aquí sobre qué es Helm, y algunos temas relacionados, e incluso proporcionamos algunos trucos si creas tus gráficos.

Entonces, como se comentó, Helm Chart no es más que un paquete que colocas alrededor de los diferentes objetos de Kubernetes que necesitan ser desplegados para que tu aplicación funcione. La comparación habitual es que es similar a un Paquete de Software. Cuando instalas una aplicación que depende de varios componentes, todos esos componentes se empaquetan juntos, y aquí es lo mismo.

¿Qué es una Dependencia de Helm?

Una Dependencia de Helm no es más que la forma en que defines que tu Chart necesita otro chart para funcionar. Por supuesto, puedes crear un Helm Chart con todo lo que necesitas para desplegar tu aplicación, pero a veces te gustaría dividir ese trabajo en varios charts simplemente porque son fáciles de mantener o el caso de uso más común porque quieres aprovechar otro Helm Chart que ya está disponible.

Un caso de uso puede ser una aplicación web que requiere una base de datos, por lo que puedes crear en tu Helm Chart todos los archivos YAML para desplegar tu aplicación web y tu base de datos en Kubernetes, o puedes tener tus archivos YAML para tu aplicación web (Deployment, Services, ConfigMaps,…) y luego decir: Y necesito una base de datos y para proporcionarla voy a usar este chart.

Esto es similar a cómo funciona con los paquetes de software en sistemas UNIX; tienes tu paquete que hace el trabajo, como, por ejemplo, A, pero para que ese trabajo se realice, requiere la biblioteca L, y para asegurar que cuando estás instalando A, la Biblioteca L ya esté allí o si no, se instalará, declaras que tu aplicación A depende de la Biblioteca L, así que aquí es lo mismo. Declaras que tu Chart depende de otro Chart para funcionar. Y eso nos lleva al siguiente punto.

¿Cómo declaramos una Dependencia de Helm?

Este es el siguiente punto; ahora que entendemos qué es una Dependencia de Helm conceptualmente y tenemos un caso de uso, ¿cómo podemos hacer eso en nuestro Helm Chart?

Todo el trabajo se realiza en el archivo Chart.yml. Si recuerdas, el archivo Chart.yml es el archivo donde declaras todos los metadatos de tu Helm Chart, como el nombre, la versión del chart, la versión de la aplicación, la URL de ubicación, el icono y mucho más. Y generalmente tiene una estructura como esta:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"

Así que aquí podemos agregar una sección dependencies y, en esa sección es donde vamos a definir los charts de los que dependemos. Como puedes ver en el fragmento a continuación:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: 1.0.0
  repository: "file:///location_of_my_chart"

Aquí estamos declarando Dependency como nuestra Dependencia de Helm. Especificamos la versión que nos gustaría usar (similar a la versión que decimos en nuestro chart), y eso nos ayudará a asegurar que proporcionaremos la misma versión que ha sido probada como parte de la resolución de la dependencia y también la ubicación usando una URL que puede ser una URL externa si esto está apuntando a un Helm Chart que está disponible en internet o fuera de tu computadora o usando una Ruta de Archivo en caso de que estés apuntando a un recurso local en tu máquina.

Eso hará el trabajo de definir la dependencia de helm, y de esta manera, cuando instales tu chart usando el comando helm install, también proporcionará la dependencia.

¿Cómo declaro una Dependencia Condicional de Helm?

Hasta ahora, hemos aprendido cómo declarar una dependencia, y cada vez que aprovisiono mi aplicación, también proporcionará la dependencia. Pero generalmente nos gustaría tener un enfoque más detallado para eso. Imagina el mismo escenario anterior: Tenemos nuestra Aplicación Web que depende de la Base de Datos, y tenemos dos opciones, podemos aprovisionar la base de datos como parte de la instalación de la aplicación web, o podemos apuntar a una base de datos externa y en ese caso, no tiene sentido aprovisionar la Dependencia de Helm. ¿Cómo podemos hacer eso?

Entonces, fácil, porque uno de los parámetros opcionales que puedes agregar a tu dependencia es condition y hacer exactamente eso, condition te permite especificar una bandera en tu values.yml que en el caso sea igual a true, proporcionará la dependencia pero en el caso sea igual a false omitirá esa parte similar al fragmento mostrado a continuación:

 apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: 1.0.0
  repository: "file:///location_of_my_chart"
  condition: database.enabled

Y con eso, estableceremos el parámetro enabled bajo database en nuestro values.yml a true si nos gustaría aprovisionarlo.

¿Cómo declaro una Dependencia de Helm con una versión diferente?

Como se muestra en los fragmentos anteriores, ofrecemos que cuando declaramos una Dependencia de Helm, especificamos la versión; esa es una forma segura de hacerlo porque asegura que cualquier cambio realizado en el chart de helm no afectará tu paquete. Sin embargo, al mismo tiempo, no puedes estar al tanto de correcciones de seguridad o parches en el chart que te gustaría aprovechar en tu implementación.

Para simplificar eso, tienes la opción de definir la versión de una manera más flexible usando el operador ~ en la definición de la versión, como puedes ver en el fragmento a continuación:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: ~1.0.0
  repository: "file:///location_of_my_chart"
  condition: database.enabled

Esto significa que cualquier parche realizado en el chart será aceptado, por lo que esto es similar a que este chart usará la última versión de 1.0.X. Sin embargo, no usará la versión 1.1.0, por lo que eso permite tener más flexibilidad, pero al mismo tiempo mantener las cosas seguras y protegidas en caso de un cambio importante en el Chart del que dependes. Esta es solo una forma de definir eso, pero la flexibilidad es enorme ya que las versiones de Chart usan «Versiones Semánticas», Puedes aprender y leer más sobre eso aquí: https://github.com/Masterminds/semver.

Dockerfile de Múltiples Etapas: Enfoque Asombroso para Optimizar el Tamaño de tu Contenedor

por
Dockerfile de Múltiples Etapas: Enfoque Asombroso para Optimizar el Tamaño de tu Contenedor
Tabla de contenidos
  1. ¿Qué es un patrón de Dockerfile de múltiples etapas?
  2. ¿Por qué el patrón de construcción de múltiples etapas ayuda a reducir el tamaño de las imágenes de contenedores?
  3. ¿Cómo defines un Dockerfile de múltiples etapas?
  4. ¿Cómo copias recursos de una etapa a otra?
  5. ¿Cuál es la mejora que puedes obtener?
  6.  ¿Dónde puedo leer más sobre esto?

El Dockerfile de múltiples etapas es el patrón que puedes usar para asegurar que tu imagen de Docker esté en un tamaño optimizado. Ya hemos cubierto la importancia de mantener el tamaño de tu imagen de Docker al mínimo y qué herramientas podrías usar, como dive, para entender el tamaño de cada una de tus capas. Pero hoy, vamos a seguir un enfoque diferente y ese enfoque es una construcción de múltiples etapas para nuestros contenedores Docker.

¿Qué es un patrón de Dockerfile de múltiples etapas?

El Dockerfile de múltiples etapas se basa en el principio de que el mismo Dockerfile puede tener diferentes sentencias FROM y cada una de las sentencias FROM inicia una nueva etapa de la construcción.

Patrón de Dockerfile de múltiples etapas

¿Por qué el patrón de construcción de múltiples etapas ayuda a reducir el tamaño de las imágenes de contenedores?

La razón principal por la que el uso de patrones de construcción de múltiples etapas ayuda a reducir el tamaño de los contenedores es que puedes copiar cualquier artefacto o conjunto de artefactos de una etapa a otra. Y esa es la razón más importante. ¿Por qué? Porque eso significa que todo lo que no copias es descartado y no estás llevando todos estos componentes no requeridos de capa en capa, generando un tamaño innecesario mayor de la imagen final de Docker.

¿Cómo defines un Dockerfile de múltiples etapas?

Primero, necesitas tener un Dockerfile con más de un FROM. Como se comentó, cada uno de los FROM indicará el inicio de una etapa del Dockerfile de múltiples etapas. Para diferenciarlos o referenciarlos, puedes nombrar cada una de las etapas del Dockerfile usando la cláusula AS junto al comando FROM, como se muestra a continuación:

 FROM eclipse-temurin:11-jre-alpine AS builder

Como una buena práctica, también puedes agregar una nueva etiqueta de etapa con el mismo nombre que proporcionaste antes, pero eso no es necesario. Así que, en resumen, un Dockerfile de múltiples etapas será algo como esto:

FROM eclipse-temurin:11-jre-alpine AS builder
LABEL stage=builder
COPY . /
RUN apk add  --no-cache unzip zip && zip -qq -d /resources/bwce-runtime/bwce-runtime-2.7.2.zip "tibco.home/tibcojre64/*"
RUN unzip -qq /resources/bwce-runtime/bwce*.zip -d /tmp && rm -rf /resources/bwce-runtime/bwce*.zip 2> /dev/null


FROM  eclipse-temurin:11-jre-alpine 
RUN addgroup -S bwcegroup && adduser -S bwce -G bwcegroup

¿Cómo copias recursos de una etapa a otra?

Esta es la otra parte importante aquí. Una vez que hemos definido todas las etapas que necesitamos, y cada una está haciendo su parte del trabajo, necesitamos mover datos de una etapa a la siguiente. Entonces, ¿cómo podemos hacer eso?

La respuesta es usando el comando COPY. COPY es el mismo comando que usas para mover datos desde tu almacenamiento local a la imagen del contenedor, por lo que necesitarás una forma de diferenciar que esta vez no lo estás copiando desde tu almacenamiento local sino desde otra etapa, y aquí es donde vamos a usar el argumento --from. El valor será el nombre de la etapa que aprendimos a declarar en la sección anterior. Así que un comando COPY completo será algo como el fragmento mostrado a continuación:

 COPY --from=builder /resources/ /resources/

¿Cuál es la mejora que puedes obtener?

Esa es la parte esencial y dependerá de cómo se crean tus Dockerfiles e imágenes, pero el factor principal que puedes considerar es el número de capas que tiene tu imagen actual. Cuanto mayor sea el número de capas, más significativo será el ahorro que probablemente puedas lograr en la cantidad de la imagen final del contenedor en un Dockerfile de múltiples etapas.

La razón principal es que cada capa duplicará parte de los datos, y estoy seguro de que no necesitarás todos los datos de la capa en la siguiente. Y usando el enfoque comentado en este artículo, obtendrás una forma de optimizarlo.

 ¿Dónde puedo leer más sobre esto?

Si quieres leer más, debes saber que el Dockerfile de múltiples etapas está documentado como una de las mejores prácticas en la página web oficial de Docker, y tienen un gran artículo sobre esto por Alex Ellis que puedes leer aquí.

📚 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.

Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

por
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos
Tabla de contenidos
  1. Introducción
  2. Habilitando la Autenticación de Kubernetes en Hashicorp
  3. Definiendo una Cuenta de Servicio de Kubernetes y Definiendo una Política

Introducción

Este artículo cubrirá cómo inyectar secretos en Pods usando Hashicorp Vault. En artículos anteriores, cubrimos cómo instalar Hashicorp Vault en Kubernetes, configurar y crear secretos en Hashicorp, y cómo herramientas como TIBCO BW pueden recuperarlos. Sin embargo, hoy vamos a dar un paso más allá.

La razón por la cual inyectar secretos en pods es muy importante es que permite que la aplicación dentro del pod sea transparente en torno a cualquier comunicación con Hashicorp. Después de todo, para las aplicaciones, el secreto será solo un archivo regular ubicado en una ruta específica dentro del contenedor. No necesita preocuparse si este archivo proviene de un Secreto de Hashicorp o de un recurso totalmente diferente.

Este enfoque de inyección facilita el enfoque poliglota del ecosistema de Kubernetes porque libera cualquier responsabilidad de la aplicación subyacente. Lo mismo ocurre con enfoques de inyección como Istio o mucho más.

Pero, expliquemos cómo funciona este enfoque para inyectar secretos en Pods usando Hashicorp Vault. Como parte de la instalación junto al servidor de vault que hemos instalado (o varios si has hecho una instalación distribuida), hemos visto otro pod bajo el nombre de value-agent-injector, como puedes ver en la imagen a continuación:

Inyectar Secretos en Pods: Pod del Inyector de Vault

Este agente será responsable de escuchar los nuevos despliegues que realices y, basado en las anotaciones que tenga este despliegue, lanzará un sidecar junto a tu aplicación y enviará la configuración para poder conectarse al vault y descargar los secretos requeridos y montarlos como archivos dentro de tu pod como se muestra en la imagen a continuación:

Inyectar Secretos en Pods: Progreso de Inyección
Flujo de autenticación de Kubernetes de Vault

Para hacer eso, necesitamos realizar varios pasos como parte de la configuración que vamos a incluir en las próximas secciones del artículo

Habilitando la Autenticación de Kubernetes en Hashicorp

Lo primero que necesitamos hacer en esta etapa es habilitar la Autenticación de Kubernetes en Hashicorp. Este método permite a los clientes autenticarse con un Token de Cuenta de Servicio de Kubernetes. Hacemos eso con el siguiente comando:

 Vault auth enable kubernetes

Vault acepta un token de servicio de cualquier cliente en el clúster de Kubernetes. Durante la autenticación, Vault verifica que el token de la cuenta de servicio sea válido consultando un endpoint de revisión de tokens de Kubernetes. Ahora, necesitamos configurar este método de autenticación proporcionando la ubicación de nuestra API de Kubernetes, y para hacer eso, necesitamos ejecutar el siguiente comando:

 vault write auth/kubernetes/config 
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

Definiendo una Cuenta de Servicio de Kubernetes y Definiendo una Política

Ahora, crearemos una Cuenta de Servicio de Kubernetes que ejecutará nuestros pods, y a esta cuenta de servicio se le permitirá recuperar el secreto que generamos en el artículo anterior.

Para hacer eso, comenzaremos con la creación de la cuenta de servicio ejecutando este comando desde fuera del pod:

kubectl create sa internal-app

Esto creará una nueva cuenta de servicio bajo el nombre de internal-app, y ahora vamos a generar una política dentro del servidor de Hashicorp Vault usando este comando dentro del pod del servidor de vault:

 vault policy write internal-app - <<EOF
path "internal/data/database/config" {
  capabilities = ["read"]
}
EOF

Y ahora, asociamos esta política con la cuenta de servicio ejecutando este comando también dentro del pod del servidor de vault:

  vault write auth/kubernetes/role/internal-app 
    bound_service_account_names=internal-app 
    bound_service_account_namespaces=default 
    policies=internal-app 
    ttl=24h

Y eso es prácticamente toda la configuración que necesitamos hacer en el lado de Vault para poder inyectar secretos en pods usando Hashicorp Vault. Ahora, necesitamos configurar nuestra aplicación en consecuencia haciendo las siguientes modificaciones:

  • Especificar el ServiceAccountName en el despliegue para que sea el que creamos previamente: internal-app
  • Especificar las anotaciones específicas para inyectar los secretos de vault y la configuración de esos secretos.

Comencemos con el primer punto. Necesitamos agregar el serviceAccountName a nuestro archivo YAML de Manifiesto de Kubernetes como se muestra a continuación:

Inyectar Secretos en Pods: Definición del Nombre de la Cuenta de Servicio

Y con respecto al segundo punto, lo resolveríamos agregando varias anotaciones a nuestro despliegue, como se muestra a continuación:

Inyectar Secretos en Pods: Anotaciones

Las anotaciones utilizadas para inyectar secretos en pods son las siguientes:

  • vault.hashicorp.com/agent-inject: ‘true’: Esto le dice al inyector de vault que nos gustaría inyectar el agente sidecar en este despliegue y tener la configuración de Vault. Esto es necesario para hacer cualquier configuración adicional
  • vault.hashicorp.com/role: internal-app: Este es el rol de vault que vamos a usar cuando solicitemos secretos e información al vault para asegurarnos de que solo accedemos a los secretos que hemos permitido según la política que creamos en la sección anterior
  • vault.hashicorp.com/agent-inject-secret-secret-database-config.txt: internal/data/database/config: Esta será una anotación por cada secreto que planeamos agregar, y se compone de tres partes:
    • vault.hashicorp.com/agent-inject-secret- esta parte es fija
    • secret-database-config.txt esta parte será el nombre del archivo que se crea bajo /vault/secrets dentro de nuestro pod
    • internal/data/database/config Este es el camino dentro del vault de nuestro secreto para ser vinculado a ese archivo.

¡Y eso es todo! Si desplegamos ahora nuestro despliegue veremos las siguientes cosas:

  • Nuestra aplicación de despliegue se ha lanzado con tres contenedores en lugar de uno porque dos de ellos están relacionados con Hashicorp Vault, como puedes ver en la imagen a continuación:
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos
  • vault-agent-init será el contenedor que establece la conexión con el servidor de vault porque cualquier contenedor comienza y realiza la primera descarga e inyección de secretos en el pod según la configuración proporcionada.
  • vault-agent será el contenedor que se ejecuta como un observador para detectar cualquier modificación en los secretos relacionados y actualizarlos.
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Y ahora, si vamos al contenedor principal, veremos en la ruta /vault/secrets que el secreto ha sido finalmente inyectado como se esperaba:

Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Y así es como fácilmente y sin ningún conocimiento sobre la aplicación subyacente podemos inyectar secretos en pods usando Hashicorp Vault.

📚 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.

OpenLens vs Lens: Una nueva batalla comienza en enero de 2023

por
OpenLens vs Lens: A New Battle Starting in January 2023
Tabla de contenidos
  1. Introducción
  2. ¿Qué es OpenLens?
  3. ¿OpenLens vs Lens?
  4. ¿Lens va a ser privado?
  5. ¿Lens sigue siendo gratuito?
  6. ¿Debería dejar de usar Lens ahora?
  7. ¿Cómo puedo instalar OpenLens?
  8. ¿Qué características pierdo si cambio a OpenLens?

Introducción

Ya hablamos sobre Lens varias veces en diferentes artículos, pero hoy lo traigo aquí OpenLens porque después del lanzamiento de Lens 6 a finales de julio han surgido muchas preguntas, especialmente en relación con su cambio y la relación con el proyecto OpenLens, así que pensé que podría ser muy interesante reunir algunos de estos datos en el mismo lugar para que ninguno de ustedes esté bastante confundido. Así que intentaré explicar y responder las principales preguntas que puedan tener en este momento.

¿Qué es OpenLens?

OpenLens es el proyecto de código abierto que está detrás del código que soporta la funcionalidad principal de Lens, el software que te ayuda a gestionar y ejecutar tus Clústeres de Kubernetes. Está disponible en GitHub aquí (https://github.com/lensapp/lens) y es totalmente de código abierto y distribuido bajo una Licencia MIT. En sus propias palabras, esta es la definición:

Este repositorio ("OpenLens") es donde el Equipo Lens desarrolla el producto Lens IDE junto con la comunidad. Está respaldado por varios pioneros del ecosistema Kubernetes y nativo de la nube. Este código fuente está disponible para todos bajo la licencia MIT

¿OpenLens vs Lens?

Entonces, la pregunta principal que podrías tener en este momento es cuál es la diferencia entre Lens y OpenLens. La principal diferencia es que Lens está construido sobre OpenLens, incluyendo algunos software y bibliotecas adicionales con diferentes licencias. Es desarrollado por el equipo de Mirantis (la misma empresa que posee Docker Enterprise) y se distribuye bajo un EULA tradicional.

¿Lens va a ser privado?

Necesitamos comenzar diciendo que desde el principio Lens ha sido lanzado bajo un EULA tradicional, así que en ese aspecto no hay mucha diferencia, podemos decir que OpenLens es de código abierto pero Lens es Freeware o al menos era freeware en ese momento. Pero el 28 de julio tuvimos el lanzamiento de Lens 6 donde la diferencia entre los proyectos comenzó a surgir.

Como se comentó en el Blog de Mirantis, se han incluido muchos cambios y nuevas capacidades, pero además de eso también se ha revelado la visión. Como dice el equipo de Mirantis, no se detienen en el nivel actual que Lens tiene hoy para gestionar el clúster de Kubernetes, quieren ir más allá proporcionando también una versión web de Lens para simplificar aún más el acceso, también extender su alcance más allá de Kubernetes, y así sucesivamente.

Entonces, puedes admitir que esta es una visión muy convincente y muy ambiciosa al mismo tiempo y es por eso que también están haciendo algunos cambios en la licencia y el modelo, de los cuales vamos a hablar a continuación.

¿Lens sigue siendo gratuito?

Ya comentamos que Lens siempre se lanzó bajo un EULA tradicional, por lo que no era de código abierto como otros proyectos, como su núcleo en OpenLens, pero era gratuito para usar. Con el lanzamiento el 28 de julio, esto está cambiando un poco para apoyar su nueva visión.

Están lanzando un nuevo modelo de suscripción dependiendo del uso que estés haciendo de la herramienta y el enfoque es muy similar al que hicieron en su momento con Docker Desktop, si recuerdas que manejamos eso en un artículo también.

  • Lens Personal: las suscripciones son para uso personal, educación y startups (menos de $10 millones en ingresos anuales o financiación). Son gratuitas.
  • Lens Pro: se requieren suscripciones para uso profesional en empresas más grandes. El precio es de $19.90 por usuario/mes o $199 por usuario/año.

La nueva licencia se aplicó con el lanzamiento de Lens 6 el 28 de julio, pero han proporcionado un Período de Gracia hasta enero de 2023 para que puedas adaptarte a este nuevo modelo.

¿Debería dejar de usar Lens ahora?

Esto es, como siempre, decisión tuya, pero las cosas van a ser las mismas hasta enero de 2023 y en ese momento, necesitas formalizar tu situación con Lens y Mirantis. Si estás en la situación de una licencia Lens Personal porque trabajas para una startup o de código abierto, puedes continuar haciéndolo sin ningún problema. Si ese no es el caso, depende de la empresa si las características adicionales que están proporcionando ahora y también la visión para el futuro justifican la inversión que necesitas hacer en la licencia Lens Pro.

Siempre tendrás la opción de cambiar de Lens a OpenLens, no será 100% lo mismo, pero las funcionalidades y el enfoque principales en este momento seguirán siendo los mismos y el proyecto seguramente estará muy, muy activo. Y también, como Mirantis ya confirmó en el mismo blog: «No hay cambios en la licencia de OpenLens ni en ningún otro proyecto de código abierto upstream utilizado por Lens Desktop.» Así que no puedes esperar que la misma situación ocurra si estás cambiando a OpenLens o ya usando OpenLens.

¿Cómo puedo instalar OpenLens?

La instalación de OpenLens es un poco complicada porque necesitas generar tu compilación desde el código fuente, pero para facilitar ese camino ha habido varias personas increíbles que están haciendo eso en sus repositorios de GitHub, como Muhammed Kalkan, que está proporcionando un repositorio con las últimas versiones con solo componentes de código abierto para las principales plataformas (Windows, macOS X (Intel y Silicon) o Linux) disponible aquí:

OpenLens vs Lens: Una nueva batalla comienza en enero de 2023
Releases · MuhammedKalkan/OpenLens
OpenLens Binary Build Repository. Contribute to MuhammedKalkan/OpenLens development by creating an account on GitHub.

¿Qué características pierdo si cambio a OpenLens?

Seguramente habrá algunas características que perderás si cambias de Lens a OpenLens, que son las que se proporcionan utilizando las piezas de software con licencia. Aquí incluimos una lista no exclusiva de nuestras experiencias usando ambos productos:

  • Sincronización de Cuenta: Todas las capacidades de tener todos tus Clústeres de Kubernetes bajo tu Cuenta Lens y sincronizados no estarán disponibles en OpenLens. Dependerás del contenido del archivo kubeconfig.
  • Espacios: La opción de tener tu configuración compartida entre diferentes usuarios que pertenecen al mismo equipo no está disponible en OpenLens.
  • Escaneo de Imagen: Una de las nuevas capacidades de Lens 6 es la opción de escanear la imagen de los contenedores desplegados en el clúster, pero esto no está disponible en OpenLens.

📚 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.

Hadolint: Mejores prácticas para tus Dockerfiles en 3 modelos diferentes

por
Hadolint: Mejores prácticas para tus Dockerfiles en 3 modelos diferentes
Tabla de contenidos
  1. Introducción
  2. Ejecutándolo como una herramienta independiente
  3. Capacidad de Ignorar Reglas
  4. Ejecutándolo como Contenedor Docker
  5. Ejecutándolo dentro de VS Code

Introducción

Hadolint es una herramienta de código abierto que te ayudará a asegurar que todos los Dockerfiles que crees sigan todas las mejores prácticas de Dockerfile disponibles de manera automatizada. Hadolint, como el número ya sugiere, es una herramienta linter y, debido a eso, también puede ayudarte a enseñarte todas estas mejores prácticas al crear Dockerfiles por ti mismo. Ya hablamos sobre la optimización del tamaño de la imagen del contenedor, pero hoy vamos a intentar cubrirlo más a fondo.

Hadolint es una herramienta más pequeña escrita en Haskell que analiza el Dockerfile en un AST y realiza reglas sobre el AST. Se apoya en ShellCheck para analizar el código Bash dentro de las instrucciones RUN, como se muestra en la imagen a continuación:

Hadolint: Mejores prácticas para tus Dockerfiles en 3 modelos diferentes

Hay varias maneras de ejecutar la herramienta, dependiendo de lo que intentes lograr, y hablaremos un poco sobre las diferentes opciones.

Ejecutándolo como una herramienta independiente

Esta es la primera forma en que podemos ejecutarlo como una herramienta independiente completa que puedes descargar desde aquí, y necesitará hacer el siguiente comando.

 hadolint <Dockerfile path>

Se ejecutará contra él y mostrará cualquier problema que se encuentre, como puedes ver en la imagen a continuación:

Ejecución de Hadolint

Para cada uno de los problemas encontrados, mostrará la línea donde se detecta el problema, el código de la verificación de mejores prácticas de Dockerfile que se está realizando (DL3020), la severidad de la verificación (error, advertencia, información, etc.), y la descripción del problema.

Para ver todas las reglas que se están ejecutando, puedes revisarlas en el Wiki de GitHub, y todas ellas están basadas en las mejores prácticas de Dockerfile publicadas directamente por Docker en su página web oficial aquí.

Para cada una de ellas, encontrarás una página wiki específica con toda la información que necesitas sobre el problema y por qué esto es algo que debería cambiarse, y cómo debería cambiarse, como puedes ver en la imagen a continuación:

Página del Wiki de Hadolint en GitHub

Capacidad de Ignorar Reglas

Puedes ignorar algunas reglas si no quieres que se apliquen porque hay algunos falsos positivos o simplemente porque las verificaciones no están alineadas con las mejores prácticas de Dockerfile utilizadas en tu organización. Para hacer eso, puedes incluir un parámetro —ignore con la regla a aplicar:

 hadolint --ignore DL3003 --ignore DL3006 <Dockerfile>

Ejecutándolo como Contenedor Docker

Además, la herramienta está disponible como un contenedor Docker en los siguientes repositorios:

docker pull hadolint/hadolint
# O
docker pull ghcr.io/hadolint/hadolint

Y esto te ayudará a introducirlo en tu Integración Continua y Despliegue Continuo o simplemente para ser usado en tu entorno local si prefieres no instalar software localmente.

Ejecutándolo dentro de VS Code

Como muchos linters, es esencial tenerlo cerca de tu entorno de desarrollo; esta vez no es diferente. Nos gustaría tener las mejores prácticas de Dockerfile relativas al editor mientras estamos escribiendo por dos razones principales:

  • Tan pronto como obtengas el problema, lo solucionarás más rápido para que el código siempre tenga mejor calidad
  • Tan pronto como sepas del problema, no lo volverás a cometer en desarrollos nuevos.

Tendrás Hadolint como parte de las Extensiones: Marketplace, y puedes instalarlo:

Extensión de Hadolint para VS Code


Una vez que hayas hecho eso, cada vez que abras un Dockerfile, validarás contra todas estas mejores prácticas de Dockerfile, y mostrará los problemas detectados en la vista de Problemas, como puedes ver en la imagen a continuación:

Ejecución de la Extensión de Hadolint para VS Code

Y esos problemas serán reevaluados tan pronto como modifiques y guardes el Dockerfile nuevamente, por lo que siempre verás la versión en vivo del problema detectado contra las mejores prácticas de Dockerfile.