Containers Archives - Alexandre Vazquez

Nomad vs Kubernetes: 1 contendiente emergente desafiando al rey probado

2026-01-182022-10-17 por Alexandre Vazquez

Tabla de contenidos

¿Cuáles son las principales características de Nomad?
Nomad vs Kubernetes: ¿Cómo funciona Nomad?
¿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.

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

2026-01-142022-09-19 por Alexandre Vazquez

Tabla de contenidos

¿Qué es un 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?
¿Cómo defines un Dockerfile de múltiples etapas?
¿Cómo copias recursos de una etapa a otra?
¿Cuál es la mejora que puedes obtener?
¿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.

¿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í.

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

2022-09-05 por Alexandre Vazquez

Tabla de contenidos

Introducción
Ejecutándolo como una herramienta independiente
Capacidad de Ignorar Reglas
Ejecutándolo como Contenedor Docker
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:

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:

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:

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:

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.

CICD Docker: Las 3 principales razones para usar contenedores en tu pipeline de DevSecOps

2026-01-142020-12-30 por Alexandre Vazquez

Mejora el rendimiento y la productividad de tu canalización DevSecOps usando contenedores.

Tabla de contenidos

1.- Solución mucho más escalable
2.- Fácil de mantener y extender
3.- Evitar el bloqueo del Orquestador
Resumen

CICD Docker significa el enfoque que la mayoría de las empresas están utilizando para introducir contenedores también en la fase de construcción y pre-despliegue para implementar una parte de la canalización CICD. Veamos por qué.

DevSecOps es la nueva norma para despliegues a gran escala en grandes empresas para cumplir con el ritmo requerido en los negocios digitales hoy en día. Estos procesos se orquestan utilizando una herramienta de orquestación CICD que actúa como el cerebro de este proceso. Las herramientas habituales para hacer este trabajo son Jenkins, Bamboo, AzureDevOps, GitLab, GitHub.

En el enfoque tradicional, tenemos diferentes servidores de trabajo realizando etapas del proceso DevOps: Código, Construcción, Prueba, Despliegue, y para cada uno de ellos, necesitamos diferentes tipos de herramientas y utilidades para hacer el trabajo. Por ejemplo, para obtener el código, podemos necesitar un git instalado. Para hacer la construcción, podemos confiar en maven o Gradle, y para probar, podemos usar SonarQube, etc.

CICD Docker: 3 Razones para usar Contenedores en tu canalización DevSecOps — Estructura de CICD Docker y la relación entre Orquestador y Trabajadores

Entonces, al final, necesitamos un conjunto de herramientas para desempeñarnos con éxito, y eso también requiere algo de gestión. En los nuevos días, con el auge del desarrollo nativo en la nube y el enfoque de contenedores en la industria, esto también está afectando la forma en que desarrollas tus canalizaciones para introducir contenedores como parte de la etapa.

En la mayoría de los Orquestadores CI, puedes definir una imagen de contenedor para ejecutar como cualquier paso de tu proceso DevSecOps, y déjame decirte que es genial si lo haces porque esto te proporcionará muchos de los beneficios de los que necesitas estar consciente.

1.- Solución mucho más escalable

Uno de los problemas cuando usas un orquestador como el elemento principal en tu empresa, y que está siendo utilizado por muchas tecnologías diferentes que pueden ser de código abierto, propietario, basado en código, desarrollo visual, etc., significa que necesitas gestionar muchas cosas e instalar el software en los trabajadores.

Usualmente, lo que haces es que defines algunos trabajadores para hacer la construcción de algunos artefactos, como la imagen mostrada a continuación:

Eso es genial porque permite la segmentación del proceso de construcción y no requiere que todo el software esté instalado en todas las máquinas, incluso cuando pueden ser incompatibles.

Pero, ¿qué pasa si necesitamos desplegar muchas aplicaciones de uno de los tipos que tenemos en la imagen a continuación, como aplicaciones de TIBCO BusinessWorks? Que estarás limitado según el número de trabajadores que tengan el software instalado para construirlo y desplegarlo.

Con un enfoque basado en contenedores, tendrás todos los trabajadores disponibles porque no se necesita software, solo necesitas extraer la imagen de docker, y eso es todo, así que solo estás limitado por la infraestructura que usas, y si adoptas una plataforma en la nube como parte del proceso de construcción, estas limitaciones simplemente se eliminan. Tu tiempo de comercialización y ritmo de despliegue mejoran.

2.- Fácil de mantener y extender

Si eliminas la necesidad de instalar y gestionar los trabajadores porque se activan cuando los necesitas y se eliminan cuando no son necesarios y todo lo que necesitas hacer es crear una imagen de contenedor que haga el trabajo, el tiempo y el esfuerzo que los equipos necesitan gastar en mantener y extender la solución disminuirán considerablemente.

También la eliminación de cualquier proceso de actualización para los componentes involucrados en los pasos ya que siguen el proceso habitual de imagen de contenedor.

3.- Evitar el bloqueo del Orquestador

Como confiamos en los contenedores para hacer la mayor parte del trabajo, el trabajo que necesitamos hacer para movernos de una solución DevOps a otra es pequeño, y eso nos da el control para elegir en cualquier momento si la solución que estamos usando es la mejor para nuestro caso de uso y contexto o necesitamos movernos a otra más optimizada sin el problema de justificar grandes inversiones para hacer ese trabajo.

Recuperas el control, y también puedes incluso ir a un enfoque de multi-orquestador si es necesario, como usar la mejor solución para cada caso de uso y obtener todos los beneficios de cada uno de ellos al mismo tiempo sin necesidad de luchar contra cada uno de ellos.

Resumen

Todos los beneficios que todos conocemos de los paradigmas de desarrollo nativo en la nube y los contenedores son relevantes para el desarrollo de aplicaciones y otros procesos que usamos en nuestra organización, siendo uno de esos tu canalización y procesos DevSecOps. Comienza hoy haciendo ese viaje para obtener todas esas ventajas en el proceso de construcción y no esperes hasta que sea demasiado tarde. Disfruta tu día. Disfruta tu vida.

Cómo escanear imágenes de Docker en tu máquina local

2026-01-182020-11-13 por Alexandre Vazquez

Aprende cómo puedes aprovechar el uso de Snyk dentro de tu instalación del motor Docker

La seguridad es el tema más relevante en la arquitectura moderna. Necesita ser manejado desde todas las diferentes perspectivas. Tener un solo equipo auditando las plataformas y los desarrollos que construimos no es suficiente.

La introducción de DevSecOps como la nueva normalidad, incluyendo a los equipos de seguridad y las políticas como parte del proceso de desarrollo para evitar que la seguridad se convierta en un obstáculo para la innovación y asegurar que los artefactos que desplegamos estén seguros, ha dejado esto claro.

El escaneo de imágenes Docker es uno de los temas más importantes que podemos cubrir respecto a las imágenes de contenedores para saber que todos los componentes internos que forman parte de la imagen están a salvo de vulnerabilidades. Usualmente confiamos en algunos sistemas para hacerlo.

Escribí un artículo sobre el uso de una de las opciones más relevantes (Harbor) del mundo de código abierto para hacer este trabajo.

Y esto también está siendo realizado por diferentes repositorios Docker de proveedores de nube como Amazon ECR a partir de este año. Pero, ¿por qué necesitamos esperar hasta que subamos las imágenes a un registro Docker externo? ¿Por qué no podemos hacerlo en nuestro entorno local?

Ahora podemos. La versión 2.5.0.1 del motor Docker también incluye los componentes de Snyk necesarios para inspeccionar las imágenes Docker directamente desde la línea de comandos:

https://www.docker.com/blog/combining-snyk-scans-in-docker-desktop-and-docker-hub-to-deploy-secure-containers/

Escaneando Tus Imágenes Locales

Entonces, comencemos. Abramos un nuevo terminal y escribamos el siguiente comando:

docker scan <nombre-de-imagen>

Tan pronto como escribamos esto, el comando nos dirá que este proceso de escaneo usará Snyk para hacerlo y necesitamos autorizar el acceso a esos servicios para realizar el proceso de escaneo.

Después de eso, obtenemos una lista de todas las vulnerabilidades detectadas, como puedes ver en la imagen a continuación:

Escaneo de vulnerabilidades usando tu cliente Docker local

Para cada una de las vulnerabilidades, puedes ver los siguientes datos:

Información de vulnerabilidad — Información detallada proporcionada para cada una de las vulnerabilidades detectadas

Obtenemos la biblioteca con la vulnerabilidad, el nivel de severidad y una breve descripción de la misma. Si necesitas más detalles, también puedes consultar la URL proporcionada que está vinculada a una página de descripción para esa vulnerabilidad:

Página de vulnerabilidades — Página detallada de vulnerabilidades de snyk

Finalmente, también proporciona las fuentes que introducen esta biblioteca en tu imagen para que esto pueda resolverse rápidamente.

También proporciona una vista de alto nivel de toda la imagen, como puedes ver aquí:

Visión general de imágenes Docker — Visión general de tus imágenes Docker con todas las vulnerabilidades detectadas

Así que ahora no tienes excusa para no tener todas tus imágenes seguras antes de subirlas a tu repositorio local. ¡Hagámoslo!

¿Cómo analizar y mejorar el tamaño de tus imágenes de Docker?

2026-01-142020-11-08 por Alexandre Vazquez

Descubre cómo puedes mejorar el tamaño de tus imágenes de Docker para una mejor experiencia y ahorros dentro de tu organización.

La contenedorización es la nueva normalidad. Todos somos conscientes de eso. Todas las nuevas versiones del software corporativo y todos los proyectos de código abierto están incluyendo las opciones para usar una imagen de Docker para ejecutar su software. Probablemente ya hayas estado haciendo tus pruebas o incluso ejecutando cargas de trabajo en producción basadas en imágenes de Docker que has construido tú mismo. Si ese es el caso, probablemente conozcas uno de los grandes desafíos cuando realizas este tipo de tarea: ¿Cómo optimizar el tamaño de la imagen que generas? Una de las principales razones por las que la imagen de Docker puede ser tan grande es porque se construyen siguiendo un concepto de capas. Y eso significa que cada una de las imágenes se crea como la adición de capas, cada una asociada con los diferentes comandos que tienes en tu Dockerfile.

Usa dive para analizar el tamaño de tus imágenes

dive es un proyecto de código abierto que proporciona una vista detallada de la composición de tus imágenes de Docker. Funciona como una aplicación de interfaz de línea de comandos que tiene una gran vista del contenido de las capas, como puedes ver en la imagen a continuación:

La herramienta sigue una interfaz n-curses (si eres lo suficientemente mayor para recordar cómo eran las herramientas antes de que las interfaces gráficas de usuario fueran algo; debería parecerte familiar) y tiene estas características principales:

Esta herramienta proporcionará la lista de capas en la parte superior izquierda de la pantalla y el tamaño asociado con cada una de ellas.
Proporciona estadísticas generales sobre la eficiencia de la imagen (un valor porcentual), una vista potencial del tamaño desperdiciado y el tamaño total de la imagen.
Para cada una de las capas seleccionadas, obtienes una vista en el sistema de archivos para esta vista con los datos del tamaño de cada carpeta.
También obtén una vista de los elementos más grandes y el número de replicaciones de estos objetos.

Ahora, tienes una herramienta que te ayudará primero a saber cómo se construye tu imagen y obtener datos de rendimiento de cada uno de los ajustes que haces para mejorar ese tamaño. Así que, comencemos con los trucos.

1.- ¡Limpia tu imagen!

Este primero es bastante obvio, pero eso no significa que no sea importante. Por lo general, cuando creas una imagen de Docker, sigues el mismo patrón:

Declaras una imagen base para aprovechar.
Agregas recursos para hacer algún trabajo.
Haces algún trabajo.

Por lo general, olvidamos un paso adicional: ¡Limpiar los recursos agregados cuando ya no son necesarios! Por lo tanto, es importante asegurarse de eliminar cada uno de los archivos que ya no necesitamos. Esto también se aplica a otros componentes como la caché de apt cuando estamos instalando un nuevo paquete que necesitamos o cualquier carpeta temporal que necesitemos para realizar una instalación o algún trabajo para construir la imagen.

2.- Ten cuidado con cómo creas tu Dockerfile

Como ya mencionamos, cada uno de los comandos que declaramos en nuestro Dockerfile genera una nueva capa. Por lo tanto, es importante tener mucho cuidado con las líneas que tenemos en el Dockerfile. Incluso si esto es un compromiso con respecto a la legibilidad del Dockerfile, es importante intentar fusionar comandos en la misma primitiva RUN para asegurarnos de no estar creando capas adicionales.

También puedes usar linters de Docker como Hadolint que te ayudarán con esto y otros anti-patrones que deberías evitar cuando estás creando un Dockerfile.

3.- Opta por docker build — squash

Las últimas versiones del motor de Docker proporcionan una nueva opción cuando construyes tus imágenes para crear con el tamaño minimizado squashing de las capas intermedias que pueden ser creadas como parte del proceso de creación del Dockerfile. Eso funciona, proporcionando una nueva bandera cuando estás haciendo la construcción de tu imagen. Así que, en lugar de hacer esto:

docker build -t <your-image-name>:<tag> <Dockerfile location>

Deberías usar una bandera adicional:

docker build --squash -t <your-image-name>:<tag> <Dockerfile location>

Para poder usar esta opción, debes habilitar las características experimentales en tu Docker Engine. Para hacer eso, necesitas habilitarlo en tu archivo daemon.json y reiniciar el motor. Si estás usando Docker para Windows o Docker para Mac, puedes hacerlo usando la interfaz de usuario como se muestra a continuación:

Resumen

Estos ajustes te ayudarán a hacer tus imágenes de Docker más delgadas y mucho más agradable el proceso de extraer y empujar y, al mismo tiempo, incluso ahorrar algo de dinero con respecto al almacenamiento de las imágenes en el repositorio de tu elección. Y no solo para ti, sino para muchos otros que pueden aprovechar el trabajo que estás haciendo. Así que piensa en ti mismo, pero también piensa en la comunidad.

Plataforma de Contenedores Gestionada: Ventajas y Beneficios Clave

2026-01-192020-06-15 por Alexandre Vazquez

La Plataforma de Contenedores Gestionada ofrece ventajas a cualquier sistema dentro de cualquier empresa. Echa un vistazo a las tres críticas.

Tabla de contenidos

La Plataforma de Contenedores Gestionada ofrece ventajas a cualquier sistema dentro de cualquier empresa. Echa un vistazo a las tres críticas.
1. Obtendrás todos los componentes aislados y actualizados más rápidamente
2.- Optimizarás el uso de tu infraestructura
3.- No necesitarás infraestructura para administración
Conclusión y próximos pasos

La Plataforma de Contenedores Gestionada está revolucionando todo. Estamos viviendo en una época donde el desarrollo y el panorama de TI están cambiando, nuevos paradigmas como microservicios y contenedores parecen estar presentes desde hace algunos años, y si confiamos en la realidad que los blogs y artículos muestran hoy, todos los usuarios ya los estamos usando todo el tiempo.

¿Has visto alguna publicación de blog sobre cómo desarrollar una aplicación J2EE que se ejecute en tu servidor Tomcat local? Probablemente no. El artículo más similar probablemente debería ser cómo contenerizar tu aplicación basada en Tomcat.

¿Pero sabes qué? La mayoría de las empresas todavía están trabajando de esa manera. Así que incluso si todas las empresas tienen un nuevo enfoque digital en algunos departamentos, también tienen otros que son más tradicionales.

Entonces, parece que necesitamos encontrar una manera diferente de traducir las principales ventajas de una plataforma basada en contenedores a un tipo de discurso que puedan ver y darse cuenta de los beneficios tangibles que pueden obtener de allí y tener el espíritu de «¡Hey, esto puede funcionar para mí!».

1. Obtendrás todos los componentes aislados y actualizados más rápidamente

Esa es una de las grandes cosas sobre las plataformas basadas en contenedores en comparación con enfoques anteriores como las plataformas basadas en servidores de aplicaciones. Cuando tienes un clúster de servidores de aplicaciones, todavía tienes un clúster con varias aplicaciones. Así que usualmente haces algo de aislamiento, mantienes aplicaciones relacionadas, proporcionas infraestructura independiente para las críticas, y así sucesivamente.

Pero incluso con eso, a algún nivel, la aplicación continúa estando acoplada, por lo que algunos problemas con algunas aplicaciones podrían derribar otra que no se esperaba por razones comerciales.

Con una plataforma basada en contenedores, obtienes cada aplicación en su burbuja, por lo que cualquier problema o error afectará a esa aplicación y nada más. La estabilidad de la plataforma es una prioridad para todas las empresas y todos los departamentos dentro de ellas. Solo pregúntate: ¿Quieres terminar con esas «cadenas de dominó» de fallos? ¿Cuánto mejorarán tus operaciones? ¿Cuánto aumentará tu felicidad?

Además, basado en el enfoque de contenedores, obtendrás componentes más pequeños. Cada uno de ellos realizará una sola tarea proporcionando una única capacidad a tu negocio, lo que significa que será mucho más fácil de actualizar, probar y desplegar en producción. Así que, al final, generará más despliegues en el entorno de producción y reducirá el tiempo de comercialización de tus capacidades empresariales.

Podrás desplegar más rápido y tener operaciones más estables al mismo tiempo.

2.- Optimizarás el uso de tu infraestructura

Costos, todo se trata de costos. No hay conversaciones con clientes que no estén tratando de pagar menos por su infraestructura. Así que, enfrentémoslo. Deberíamos poder ejecutar operaciones de manera optimizada. Así que, si el costo de nuestra infraestructura está aumentando, eso necesita significar que nuestro negocio está creciendo.

Las plataformas basadas en contenedores permitirán optimizar la infraestructura de dos maneras diferentes. Primero, si se utilizan dos conceptos principales: Elasticidad y Compartición de Infraestructura.

La elasticidad está relacionada porque solo voy a tener la infraestructura que necesito para soportar la carga que tengo en este momento. Así que, si la carga aumenta, mi infraestructura aumentará para manejarla, pero después de que ese momento pase, volverá a lo que necesita ahora después de que ese pico haya ocurrido.

La compartición de infraestructura se trata de usar cada parte del servidor que está libre para desplegar otras aplicaciones. Imagina un enfoque tradicional donde tengo dos servidores para mi conjunto de aplicaciones. Probablemente no tengo un uso del 100% de esos servidores porque necesito tener algo de capacidad de reserva para poder actuar cuando la carga aumente. Probablemente tengo un 60–70% de uso. Eso significa un 30% libre. Si tenemos diferentes departamentos con diferentes sistemas, y cada uno tiene su infraestructura con un 30% libre, ¿cuánta de nuestra infraestructura estamos simplemente desperdiciando? ¿Cuántos dólares/euros/libras estás simplemente tirando por la ventana?

Las plataformas basadas en contenedores no necesitan herramientas o software específicos instalados en la plataforma para ejecutar un tipo diferente de aplicación. No es necesario porque todo reside dentro del contenedor, por lo que puedo usar cualquier espacio libre para desplegar otras aplicaciones haciendo un uso más eficiente de esos.

3.- No necesitarás infraestructura para administración

Cada sistema que es lo suficientemente grande tiene algunos recursos dedicados para poder gestionarlo. Sin embargo, incluso la mayoría de las arquitecturas recomendadas recomiendan colocar esos componentes aislados de tus componentes de tiempo de ejecución para evitar cualquier problema relacionado con el administrador o el mantenimiento que pueda afectar tus cargas de trabajo de tiempo de ejecución, lo que significa infraestructura específica que estás usando para algo que no está ayudando a tu negocio. Por supuesto, puedes explicar a cualquier usuario de negocio que necesitas una máquina para ejecutar que proporcione las capacidades requeridas. Pero es más complejo que usar infraestructura adicional (y generar costo) para colocar otros componentes que no están ayudando al negocio.

Así que, las plataformas de contenedores gestionadas eliminan ese problema porque vas a proporcionar la infraestructura que necesitas para ejecutar tus cargas de trabajo, y se te proporcionarán de forma gratuita o por una tarifa tan baja las capacidades de administración. Y además de eso, ni siquiera necesitas preocuparte de que las funciones de administración estén siempre disponibles y funcionando bien porque esto se apoya en el propio proveedor.

Conclusión y próximos pasos

Como puedes ver, describimos beneficios muy tangibles que no están basados en la industria o enfocados en el desarrollo. Por supuesto, podemos tener muchos más para agregar a esta lista, pero estos son los críticos que afectan a cualquier empresa en cualquier industria en todo el mundo. Así que, por favor, tómate tu tiempo para pensar en cómo estas capacidades pueden ayudar a mejorar tu negocio. Pero no solo eso, tómate tu tiempo para cuantificar cómo eso mejorará tu negocio. ¿Cuánto puedes ahorrar? ¿Cuánto puedes obtener de este enfoque?

Y cuando tengas frente a ti un caso de negocio sólido basado en este enfoque, obtendrás todo el apoyo y el coraje que necesitas para avanzar en esa ruta. ¡Así que te deseo una transición pacífica!

Registro de Harbor: ¿Cómo usarlo para aumentar la seguridad en tu plataforma?

2026-01-142020-06-11 por Alexandre Vazquez

Aprende cómo puedes incluir el registro de Harbor en tu conjunto de herramientas DevSecOps para aumentar la seguridad y gestión en tu plataforma basada en contenedores

Con la transición a un proceso de desarrollo más ágil donde el número de implementaciones ha aumentado de manera exponencial. Esa situación ha hecho que sea bastante complejo mantener el ritmo para asegurarnos de que no solo estamos implementando código más a menudo en producción que proporciona las capacidades requeridas por el negocio. Sino que, al mismo tiempo, podemos hacerlo de manera segura y confiable.

Esa necesidad está llevando hacia la idea de DevSecOps para incluir la seguridad como parte de la cultura y prácticas de DevOps como una forma de garantizar la seguridad desde el principio en el desarrollo y a lo largo de todos los pasos estándar desde la máquina del desarrollador hasta el entorno de producción.

Además de eso, debido al paradigma de los contenedores, tenemos un enfoque más políglota con diferentes tipos de componentes ejecutándose en nuestra plataforma utilizando una imagen base diferente, paquetes, bibliotecas, etc. Necesitamos asegurarnos de que sigan siendo seguros de usar y necesitamos herramientas para poder gobernar eso de manera natural. Para ayudarnos en esa tarea es donde componentes como Harbor nos ayudan a hacerlo.

Harbor es un proyecto de CNCF en la etapa de incubación en el momento de escribir este artículo, y proporciona varias capacidades sobre cómo gestionar imágenes de contenedores desde una perspectiva de proyecto. Ofrece un enfoque de proyecto con su registro de docker y también un museo de gráficos si queremos usar Helm Charts como parte de nuestro desarrollo de proyectos. Pero también incluye características de seguridad, y esa es la que vamos a cubrir en este artículo:

Escaneo de Vulnerabilidades: te permite escanear todas las imágenes de docker registradas en los diferentes repositorios para verificar si tienen vulnerabilidades. También proporciona automatización durante ese proceso para asegurarse de que cada vez que empujamos una nueva imagen, esta se escanea automáticamente. Además, permitirá definir políticas para evitar extraer cualquier imagen con vulnerabilidades y también establecer el nivel de vulnerabilidades (bajo, medio, alto o crítico) que nos gustaría tolerar. Por defecto, viene con Clair como el escáner predeterminado, pero también puedes introducir otros.
Imágenes firmadas: el registro de Harbor proporciona opciones para desplegar notary como parte de sus componentes para poder firmar imágenes durante el proceso de empuje para asegurarse de que no se realicen modificaciones a esa imagen
Inmutabilidad de Etiquetas y Reglas de Retención: el registro de Harbor también proporciona la opción de definir la inmutabilidad de etiquetas y reglas de retención para asegurarse de que no haya ningún intento de reemplazar imágenes con otras usando la misma etiqueta.

El registro de Harbor se basa en docker, por lo que puedes ejecutarlo localmente usando docker y docker-compose siguiendo el procedimiento disponible en su página web oficial. Pero también admite ser instalado sobre tu plataforma Kubernetes usando el helm chart y el operador que están disponibles.

Una vez que la herramienta está instalada, tenemos acceso al Portal Web de la UI, y podemos crear un proyecto que tenga repositorios como parte de él.

Como parte de la configuración del proyecto, podemos definir las políticas de seguridad que nos gustaría proporcionar a cada proyecto. Eso significa que diferentes proyectos pueden tener diferentes perfiles de seguridad.

Y una vez que empujamos una nueva imagen al repositorio que pertenece a ese proyecto, vamos a ver los siguientes detalles:

En este caso, he empujado una aplicación de TIBCO BusinessWorks Container Edition que no contiene ninguna vulnerabilidad y solo muestra eso y también dónde se verificó.

Además, si vemos los detalles, podemos verificar información adicional como si la imagen ha sido firmada o no, o poder verificarla nuevamente.

Resumen

Así que, estas son solo algunas características que Harbor proporciona desde la perspectiva de seguridad. Pero Harbor es mucho más que solo eso, así que probablemente cubramos más de sus características en futuros artículos. Espero que, basado en lo que leíste hoy, te gustaría darle una oportunidad y comenzar a introducirlo en tu conjunto de herramientas DevSecOps.

Observabilidad en un Ecosistema de Microservicios Políglota

2022-05-092020-06-01 por Alexandre Vazquez

Aprende a gestionar los requisitos de observabilidad como parte de tu ecosistema de microservicios

“Que vivas en tiempos interesantes” es la traducción al inglés de la maldición china, y esto no podría ser más cierto como descripción de los tiempos en los que vivimos en cuanto a nuestra arquitectura de aplicaciones y desarrollo de aplicaciones.

Todos los cambios del enfoque nativo de la nube, incluyendo todas las nuevas tecnologías que vienen con él, como contenedores, microservicios, API, DevOps, etc., han transformado completamente la situación para cualquier arquitectura, desarrollador o administración de sistemas.

Es algo similar si te fuiste a la cama en 2003 y te despiertas en 2020, todos los cambios, todas las nuevas filosofías, pero también todos los desafíos únicos que vienen con los cambios y nuevas capacidades son cosas con las que necesitamos lidiar hoy.

Creo que todos podemos estar de acuerdo en que el presente es políglota en términos de desarrollo de aplicaciones. Hoy no se espera que ninguna gran empresa o corporación encuentre una tecnología disponible, un lenguaje disponible para soportar todos sus productos internos. Hoy todos seguimos y estamos de acuerdo con el principio de “la herramienta adecuada para el trabajo adecuado” para intentar crear nuestro conjunto de herramientas de tecnologías que vamos a usar para resolver diferentes casos de uso o patrones que necesitas enfrentar.

Pero ese acuerdo y movimiento también vienen con su desafío respecto a cosas en las que usualmente no pensamos, como el rastreo y la observabilidad en general.

Cuando usamos una sola tecnología, todo es más sencillo. Definir una estrategia común para rastrear tus flujos de extremo a extremo es fácil; solo necesitas incrustar la lógica en tu marco de desarrollo común o biblioteca que todos tus desarrollos están usando. Probablemente definir una arquitectura de encabezado típica con todos los datos que necesitas para poder rastrear efectivamente todas las solicitudes y definir un protocolo estándar para enviar todos esos rastros a un sistema estándar que pueda almacenarlos y correlacionarlos todos y explicar el flujo de extremo a extremo. Pero intenta mover eso a un ecosistema políglota: ¿Debería escribir mi marco o biblioteca para cada lenguaje o tecnología que necesitaría usar, o también puedo usar en el futuro? ¿Tiene sentido eso?

Pero no solo eso, ¿debería ralentizar la adopción de una nueva tecnología que puede ayudar rápidamente al negocio porque necesito proporcionar desde un equipo compartido este tipo de componentes estándar? Ese es el mejor caso en el que tengo suficiente gente que sabe cómo funcionan los internos de mi marco y tiene las habilidades en todos los lenguajes que estamos adoptando para poder hacerlo rápidamente y de manera eficiente. Parece poco probable, ¿verdad?

Entonces, a nuevos desafíos también nuevas soluciones. Ya he estado hablando sobre Service Mesh respecto a las capacidades que proporciona desde una perspectiva de comunicación, y si no lo recuerdas, puedes echar un vistazo a esas publicaciones:

Integrating Istio with BWCE Applications

Introduction Services Mesh is one the “greatest new thing” in our PaaS environments. No matter if you’re working with K8S, Docker Swarm, pure-cloud with EKS or AWS, you’ve heard and probably tried to know how can be used this new thing that has so many advantages because it provides a lot of options in handling […]

Pero también proporciona capacidades desde otras perspectivas y el rastreo y la observabilidad es una de ellas. Porque cuando no podemos incluir esas características en cualquier tecnología que necesitemos usar, podemos hacerlo en una tecnología general que sea compatible con todas ellas, y ese es el caso con Service Mesh.

Como Service Mesh es la forma estándar de comunicar sincrónicamente tus microservicios en una comunicación de este a oeste cubriendo la comunicación de servicio a servicio. Entonces, si puedes incluir en ese componente también la capacidad de rastreo, puedes tener un rastreo de extremo a extremo sin necesidad de implementar nada en cada una de las diferentes tecnologías que puedes usar para implementar la lógica que necesitas, así que, has cambiado de la Figura A a la Figura B en la imagen a continuación:

Y eso es lo que la mayoría de las tecnologías de Service Mesh están haciendo. Por ejemplo, Istio, como una de las opciones predeterminadas cuando se trata de Service Mesh, incluye una implementación del estándar OpenTracing que permite la integración con cualquier herramienta que soporte el estándar para poder recopilar toda la información de rastreo para cualquier tecnología que se use para comunicarse a través de la malla.

Entonces, ese cambio de mentalidad nos permite integrar fácilmente diferentes tecnologías sin necesidad de ningún soporte excepcional de esos estándares para cualquier tecnología específica. ¿Significa eso que la implementación de esos estándares para esas tecnologías no es necesaria? En absoluto, eso sigue siendo relevante, porque las que también soportan esos estándares pueden proporcionar aún más información. Después de todo, el Service Mesh solo conoce parte de la información que es el flujo que está sucediendo fuera de cada tecnología. Es algo similar a un enfoque de caja negra. Pero también agregar el soporte para cada tecnología al mismo estándar proporciona un enfoque adicional de caja blanca como puedes ver gráficamente en la imagen a continuación:

Ya hablamos sobre el cumplimiento de algunas tecnologías con el estándar OpenTracing como TIBCO BusinessWorks Container Edition que puedes recordar aquí:

OpenTracing support in TIBCO BusinessWorks Container Edition

The past month during the KubeCon 2019 Europe in Barcelona OpenTracing announces its merge with OpenCensus project to create a new standard named OpenTelemetry that is going to be live in September 2019. So, I think that would be awesome to take a look at the capabilities regarding OpenTracing we have available in TIBCO BusinessWorks […]

Entonces, también, el soporte de estas tecnologías de los estándares de la industria es necesario e incluso una ventaja competitiva porque sin necesidad de desarrollar tu marco de rastreo, puedes lograr un enfoque de Datos de Rastreo Completo adicional a lo que ya proporciona el nivel de Service Mesh en sí mismo.