Hacks Archives - Alexandre Vazquez

Seguridad en Kubernetes: Un Viaje Colaborativo para Todos los Roles

2026-01-192023-06-02 por Alexandre Vazquez

La seguridad de Kubernetes es uno de los aspectos más críticos hoy en día en el mundo de TI. Kubernetes se ha convertido en la columna vertebral de la gestión moderna de infraestructuras, permitiendo a las organizaciones escalar y desplegar aplicaciones en contenedores con facilidad. Sin embargo, el poder de Kubernetes también conlleva la responsabilidad de garantizar que se implementen medidas de seguridad robustas. Esta responsabilidad no puede recaer únicamente en los desarrolladores o los operadores. Requiere un esfuerzo colaborativo donde ambas partes trabajen juntas para mitigar riesgos y vulnerabilidades potenciales.

Aunque los enfoques de DevOps e Ingeniería de Plataformas son bastante estándar, todavía hay tareas responsables de diferentes equipos, incluso aunque hoy en día existan equipos de plataforma y de proyecto.

Aquí verás tres formas fáciles de mejorar la seguridad de Kubernetes desde las perspectivas de desarrollo y operaciones:

Sin Vulnerabilidades en Imágenes de Contenedores

El escaneo de vulnerabilidades en imágenes de contenedores es algo crucial en los desarrollos actuales porque el número de componentes desplegados en el sistema ha crecido exponencialmente, así como su opacidad. El escaneo de vulnerabilidades utilizando herramientas como Trivy o las opciones integradas en nuestros entornos locales de Docker como Docker Desktop o Rancher Desktop es obligatorio, pero ¿cómo puedes usarlo para hacer tu aplicación más segura?

Responsabilidad del desarrollador:
- Usar solo imágenes base estándar permitidas, bien conocidas
- Reducir, al mínimo, el número de componentes y paquetes a instalar con tu aplicación (mejor Alpine que Debian)
- Usar un enfoque de múltiples etapas para incluir solo lo que necesitarás en tus imágenes.
- Realizar un escaneo de vulnerabilidades localmente antes de hacer push
Responsabilidad del operador:
- Forzar la descarga de todas las imágenes base para el registro de contenedores corporativo
- Imponer el escaneo de vulnerabilidades al hacer push, generando alertas y evitando el despliegue si no se cumplen los criterios de calidad.
- Realizar escaneos de vulnerabilidades regulares para imágenes en tiempo de ejecución y generar incidentes para los equipos de desarrollo basados en los problemas descubiertos.

Sin Privilegios Adicionales en Imágenes de Contenedores

Ahora que nuestra aplicación no incluye ninguna vulnerabilidad, necesitamos asegurarnos de que la imagen no esté permitida para hacer lo que no debería, como elevar privilegios. Ve lo que puedes hacer dependiendo de tu rol:

Responsabilidad del desarrollador:
- Nunca crear imágenes con usuario root y usar opciones de contexto de seguridad en tus archivos de manifiesto de Kubernetes
- Probar tus imágenes con todas las capacidades posibles eliminadas a menos que se necesiten por alguna razón específica
- Hacer que tu sistema de archivos sea de solo lectura y usar volúmenes para las carpetas requeridas en tu aplicación.
Responsabilidad del operador:
- Crear una política usando OPA/Gatekeeper o la Política de Seguridad de Pods obsoleta para prohibir el despliegue si las aplicaciones se ejecutan con usuario root o en modo privilegiado.

Restringir la visibilidad entre componentes

Cuando diseñamos aplicaciones hoy en día, se espera que necesiten conectarse a otras aplicaciones y componentes, y las capacidades de descubrimiento de servicios en Kubernetes son excelentes en cómo podemos interactuar. Sin embargo, esto también permite que otras aplicaciones se conecten a servicios a los que tal vez no deberían. Ve lo que puedes hacer para ayudar en ese aspecto dependiendo de tu rol y responsabilidad:

Responsabilidad del desarrollador:
- Asegurarse de que tu aplicación tenga políticas adecuadas de autenticación y autorización para evitar cualquier uso no autorizado de tu aplicación.
Responsabilidad de operación:
- Gestionar a nivel de plataforma la visibilidad de red de los componentes, pero denegar todo el tráfico por defecto y permitir las conexiones requeridas por diseño usando Políticas de Red.
- Usar herramientas de Service Mesh para tener un enfoque central para la autenticación y autorización.
- Usar herramientas como Kiali para monitorear el tráfico de red y detectar patrones de tráfico irrazonables.

Conclusión

En conclusión, la importancia de la seguridad en Kubernetes no puede ser subestimada. Requiere colaboración y responsabilidad compartida entre desarrolladores y operadores. Al enfocarse en prácticas como el escaneo de vulnerabilidades, la restricción de privilegios adicionales y la restricción de visibilidad entre componentes, las organizaciones pueden crear un entorno de Kubernetes más seguro. Al trabajar juntos, los desarrolladores y operadores pueden fortalecer el ecosistema de contenedores, protegiendo aplicaciones, datos y activos empresariales críticos de posibles brechas de seguridad. Con un enfoque colaborativo en la seguridad de Kubernetes, las organizaciones pueden aprovechar con confianza todo el potencial de esta poderosa plataforma de orquestación mientras mantienen los más altos estándares de seguridad. Al adoptar estas prácticas, las organizaciones pueden crear un entorno de Kubernetes más seguro, protegiendo sus aplicaciones y datos de amenazas potenciales.

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

Bucles de Helm: Truco de Helm #1

2026-01-272022-08-16 por Alexandre Vazquez

Tabla de contenidos

Introducción
Introducción a los Bucles de Helm
¿Cómo crear un Bucle de Helm?
¿Cómo acceder a elementos principales dentro de un Bucle de Helm?

Introducción

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

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

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

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

Introducción a los Bucles de Helm

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

¿Cómo crear un Bucle de Helm?

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

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

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

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

Puedes acceder fácilmente a todo dentro de esta estructura que estás recorriendo. Entonces, si el ingrediente de la pizza tiene campos adicionales, puedes acceder a ellos con algo similar a esto:

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

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

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

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

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

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

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

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

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

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

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

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

Eso generará la siguiente salida:

 - Piña slim
 - Manzana slim

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

3 herramientas inusuales para aumentar tu productividad como desarrollador

2022-09-152021-01-21 por Alexandre Vazquez

Una lista no-VS Code para ingenieros de software

Este no va a ser uno de esos artículos sobre herramientas que pueden ayudarte a desarrollar código más rápido. Si estás interesado en eso, puedes revisar mis artículos anteriores sobre extensiones de VS Code, linters y otras herramientas que hacen tu vida como desarrollador más fácil.

Mi trabajo no solo trata sobre desarrollo de software, sino también sobre resolver problemas que tienen mis clientes. Aunque sus problemas pueden estar relacionados con el código, pueden ser un error de operación o incluso un problema de diseño.

Usualmente tiendo a definir mi rol como un llanero solitario. Salgo sin saber a qué me enfrentaré, y necesito estar listo para adaptarme, resolver el problema y hacer felices a los clientes. Esta experiencia me ha ayudado a desarrollar una cadena de herramientas que es importante para hacer ese trabajo.

¡Vamos a sumergirnos!

1. MobaXterm

MobaXterm free Xserver and tabbed SSH client for Windows

The ultimate toolbox for remote computing – includes X server, enhanced SSH client and much more!

Esta es la mejor herramienta para gestionar diferentes conexiones a diferentes servidores (acceso SSH para un servidor Linux, RDP para un servidor Windows, etc.). Aquí están algunas de sus características clave:

Reenvío de puertos SSH gráfico para esos casos en los que necesitas conectarte a un servidor al que no tienes acceso directo.
Gestión de identidades fácil para guardar las contraseñas de los diferentes servidores. Puedes organizarlas jerárquicamente para facilitar el acceso, especialmente cuando necesitas acceder a tantos servidores para diferentes entornos e incluso diferentes clientes.
Conexión automática SFTP cuando te conectas a un servidor SSH. Te permite descargar y subir archivos tan fácilmente como arrastrar archivos allí.
Reenvío X11 automático para que puedas lanzar aplicaciones gráficas desde tus servidores Linux sin necesidad de configurar nada o usar otros servidores X como XMing.

2. Beyond Compare

Scooter Software: Home of Beyond Compare

Beyond Compare is a multi-platform utility that combines directory compare and file compare functions in one package. Use it to manage source code, keep directories in sync, compare program output, etc.

Hay tantas herramientas para comparar archivos, y creo que he usado todas ellas — desde aplicaciones independientes como WinMerge, Meld, Araxis, KDiff, y otras hasta extensiones para editores de texto como VS Code y Notepad++.

Sin embargo, ninguna de ellas puede compararse con la única e inigualable Beyond Compare.

Conocí Beyond Compare cuando comencé a trabajar en ingeniería de software en 2010, y es una herramienta que me acompaña en cada proyecto que tengo. La uso todos los días. Entonces, ¿qué hace que esta herramienta sea diferente del resto?

Es simplemente la mejor herramienta para hacer cualquier comparación porque no solo compara texto y carpetas. Lo hace perfectamente, pero al mismo tiempo, también compara archivos ZIP mientras navega por el contenido, archivos JAR, y así sucesivamente. Esto es muy importante cuando queremos verificar si dos archivos JAR que se suben en DEV y PROD son la misma versión de la herramienta o saber si un archivo ZIP tiene el contenido correcto cuando se sube.

Beyond Compare en acción — Beyond Compare 4

3. Editor Vi

welcome home : vim online

Vim is rock stable and is continuously being developed to become even better.
Among its features are:

Este es el más importante — el mejor editor de texto de todos los tiempos — y está disponible prácticamente en cada servidor.

Es un editor de texto de línea de comandos con una gran cantidad de atajos que te permiten ser muy productivo cuando estás dentro de un servidor revisando registros y archivos de configuración para ver dónde está el problema.

Durante mucho tiempo, he tenido una hoja de trucos de Vi impresa para asegurarme de poder dominar los atajos más importantes y así aumentar mi productividad mientras lucho dentro de las líneas enemigas (los servidores del cliente).

Editor de texto Vi — VIM — Vi mejorado, el editor de texto definitivo.

Procesamiento de XML con Shell: Cómo actualizar un valor en un archivo XML en 5 minutos

2022-10-102020-11-22 por Alexandre Vazquez

Aprende a usar xmlstarlet para actualizar valores en archivos XML y manejar cargas XML complejas de manera eficiente en tus scripts de shell

Si trabajas en TI o incluso si consideras TI como uno de tus principales pasatiempos, has escrito un script de shell en algún momento. Si también trabajas en el lado operativo del negocio, esta puede ser tu tarea diaria. Crear, mantener o actualizar el proceso existente.

Hoy en día, es más común interactuar con sistemas externos que utilizan cargas en archivos XML o incluso archivos de configuración escritos en este formato.

El script de shell nativo no proporciona una manera fácil de hacer eso ni bibliotecas de soporte para manejarlo como podemos en lenguajes de programación modernos como Python, Java o Go. Así que, probablemente te has encontrado escribiendo código para analizar este tipo de carga. Pero esta no es la única manera de hacerlo, y podemos (¡y debemos!) aprovechar las utilidades existentes para hacer este trabajo por nosotros.

xmlstarlet

No pude encontrar una mejor manera de explicar lo que hace xmlstarlet que la definición que los propietarios hacen en su repositorio de código fuente:

XMLStarlet es un conjunto de herramientas XML de línea de comandos que se puede usar para transformar,
consultar, validar y editar documentos y archivos XML usando un conjunto simple de comandos de shell
de manera similar a como se hace para archivos de texto plano usando grep/sed/awk/
tr/diff/patch.

Así que, xmlstarlet proporciona todo el poder para hacer cualquier cosa que puedas imaginar al tratar con XML de manera similar a como si fueran archivos de texto plano.

XMLStarlet Command Line XML Toolkit: News

XMLStarlet Command Line XML Toolkit

Instalación

El proceso de instalación de esta utilidad es bastante fácil y depende del sistema operativo que estés usando. Asumiré que la mayoría de los scripts de shell están dirigidos a una máquina Unix. Instalar esto es bastante fácil ya que la mayoría de los repositorios de paquetes tienen una versión de esta herramienta.

Así que, si estás usando un sistema basado en apt, necesitas ejecutar el comando:

sudo apt-get install xmlstarlet

Si estás usando otra plataforma, no te preocupes porque tienen versiones disponibles para todos los sistemas operativos y plataformas más utilizados, como puedes ver en el enlace a continuación:

XMLStarlet Command Line XML Toolkit: Download

XMLStarlet Command Line XML Toolkit

Uso

Tan pronto como tengamos este software instalado, lo primero que haremos es lanzarlo para ver las opciones disponibles.

XMLStarlet Toolkit: Utilidades de línea de comandos para XML
Uso: D:DataDownloadsxmlstarlet-1.6.1-win32xmlstarlet-1.6.1xmlstarlet.exe [<opciones>] <comando> [<opciones-cmd>]
donde <comando> es uno de:
  ed    (o edit)      - Editar/Actualizar documento(s) XML
  sel   (o select)    - Seleccionar datos o consultar documento(s) XML (XPATH, etc)
  tr    (o transform) - Transformar documento(s) XML usando XSLT
  val   (o validate)  - Validar documento(s) XML (bien formado/DTD/XSD/RelaxNG)
  fo    (o format)    - Formatear documento(s) XML
  el    (o elements)  - Mostrar estructura de elementos del documento XML
  c14n  (o canonic)   - Canonicalización XML
  ls    (o list)      - Listar directorio como XML
  esc   (o escape)    - Escapar caracteres especiales XML
  unesc (o unescape)  - Desescapar caracteres especiales XML
  pyx   (o xmln)      - Convertir XML en formato PYX (basado en ESIS - ISO 8879)
  p2x   (o depyx)     - Convertir PYX en XML
<opciones> son:
  -q o --quiet        - sin salida de error
  --doc-namespace     - extraer enlaces de espacio de nombres del documento de entrada (por defecto)
  --no-doc-namespace  - no extraer enlaces de espacio de nombres del documento de entrada
  --version           - mostrar versión
  --help              - mostrar ayuda
Dondequiera que se mencione el nombre del archivo en la ayuda del comando, se asume
que se puede usar una URL en su lugar también.

Escribe: xmlstarlet <comando> --help <ENTER> para ayuda del comando

Así que lo primero que necesitamos decidir es qué comando necesitamos usar, y estos comandos están relacionados uno a uno con la acción que queremos realizar. Me centraré en los comandos principales en este post, pero como puedes ver, esto cubre desde seleccionar valores en un XML, actualizarlo o incluso validarlo.

Caso de uso 1: Seleccionar un valor.

Vamos a comenzar con el caso de uso más simple, intentar seleccionar un valor de un XML (file.xml) como este:

<root>
<object1 name="attribute_name">valor en XML</object1>

</root>

Así que, vamos a comenzar con el comando más simple:

./xmlstarlet  sel  -t -v "/root/object1"  ./file.xml


valor en XML

Esto proporciona el valor dentro del elemento object1, usando -t para definir una nueva plantilla y -v para especificar la sentencia value-of. Si ahora, quisiéramos obtener el valor del atributo, podemos hacerlo de manera muy similar al comando anterior:

./xmlstarlet  sel  -t -v "/root/object1/@name"  ./file.xml


attribute_name

Caso de uso 2: Actualizar valor.

Ahora, seguiremos el otro enfoque basado en el mismo archivo. Actualizaremos el valor del elemento object1 para establecer el texto «texto actualizado».

Para hacer eso, ejecutamos el siguiente comando:

./xmlstarlet ed -u "/root/object1" -v "texto actualizado" ./file.xml


<?xml version="1.0"?>
<root>
  <object1 name="attribute_name">texto actualizado</object1>
</root>

Resumen

xmlstarlet nos proporcionará todas las opciones para manejar algo tan complicado como lo es XML y realizar todas las tareas que puedas imaginar de manera simple sin necesidad de codificar tú mismo toda la lógica de análisis. Espero que seas un desarrollador más feliz desde ahora cuando necesites manejar un XML dentro de un script de shell.

Los 3 mejores trucos de Bash para mejorar tu rendimiento

2022-09-142020-06-04 por Alexandre Vazquez

Encuentra la lista de los trucos de rendimiento de bash que uso todo el tiempo y que pueden ayudarte a ahorrar mucho tiempo en tu trabajo diario.

Tabla de contenidos

Encuentra la lista de los trucos de rendimiento de bash que uso todo el tiempo y que pueden ayudarte a ahorrar mucho tiempo en tu trabajo diario.

El conocimiento de trucos de bash es una de las formas de mejorar tu rendimiento. Pasamos muchas horas dentro de ellos y hemos desarrollado patrones y hábitos cuando iniciamos sesión en una computadora. Por ejemplo, si tienes dos personas con un nivel de habilidad similar y les das la misma tarea para hacer, probablemente, usen herramientas diferentes y diferentes caminos para llegar al mismo resultado.

Y eso es porque la cantidad de opciones disponibles para realizar cualquier tarea es tan significativa que cada uno de nosotros aprende una o dos formas de hacer algo, y nos aferramos a ellas, y simplemente las automatizamos, así que no estamos pensando cuando las escribimos.

Entonces, la idea de hoy es proporcionar una lista de algunos comandos que uso todo el tiempo que probablemente ya conozcas, pero para mí son como ahorros de tiempo cada día de mi vida laboral. Así que, comencemos con ellos.

1.- CTRL + R

Este comando es mi truco de bash predilecto. Es el que uso todo el tiempo; tan pronto como inicio sesión en una máquina remota que es nueva o simplemente regreso a ellas, lo uso para casi todo. Desafortunadamente, este comando solo te permite buscar en el historial de comandos.

Te ayuda a autocompletar basado en los comandos que ya estás escribiendo. Es como lo mismo que escribir history | grep <algo> pero simplemente más rápido y más natural para mí.

Este truco de bash también me permite autocompletar rutas que no recuerdo el nombre exacto de la subcarpeta o lo que sea. Hago este comando complicado cada dos semanas para limpiar algo de memoria de procesos o aplicar alguna configuración. O simplemente para solucionar problemas en qué máquina estoy iniciando sesión en un momento específico.

2.- find + action

El comando find es algo que todos conocemos, pero la mayoría de ustedes probablemente lo usen como una funcionalidad limitada de todas las disponibles del comando find. Y eso es porque ese comando es increíble. Proporciona tantas características. Pero esta vez, solo voy a cubrir un tema específico. Acciones después de localizar los archivos que estamos buscando.

Usualmente usamos el comando find para encontrar archivos o carpetas, lo cual es evidente para un comando que se llama de esa manera. Pero también nos permite agregar el parámetro -exec para concatenar una acción que se realizará para cada uno de los archivos que coincidan con tus criterios, por ejemplo, algo como esto

Encuentra todos los archivos yaml en tu carpeta actual y simplemente renómbralos para moverlos a una carpeta diferente. Puedes hacerlo directamente con este comando:

find . -name “*.yaml” -exec mv {} /tmp/folder/yamlFiles/ ;

3.- cd –

Un truco de bash tan simple y tan útil. Al igual que nuestro comando de bash para CTRL-Z. El comando cd - nos permite volver a la carpeta anterior en la que estábamos.

Tan valioso para cuando nos equivocamos de carpeta a la que queremos ir, solo para cambiar rápidamente entre dos carpetas y así sucesivamente. Es como volver atrás en tu navegador o el CTRL-Z en tu procesador de textos.

Conclusión

Espero que ames este comando tanto como yo, y si ya lo conoces, por favor déjame en las respuestas los trucos de bash que son más relevantes para ti diariamente. Puede ser porque lo usas todo el tiempo como yo hago con estos o porque incluso si no lo usas tantas veces, las veces que lo haces, ¡te ahorra una cantidad masiva de tiempo!

Usar estadísticas a tu favor para detectar cuellos de botella en TIBCO BusinessWorks Container Edition

2026-01-272019-08-12 por Alexandre Vazquez

Generalmente, cuando estás desarrollando o ejecutando tu aplicación de contenedores, llegarás a un momento en que algo sale mal. Pero no de una manera que puedas resolver con tu sistema de registro y con pruebas.

Un momento en el que hay algún cuello de botella, algo que no está funcionando tan bien como deseas, y te gustaría echar un vistazo adentro. Y eso es lo que vamos a hacer. Vamos a mirar adentro.

Porque nuestra BusinessWorks Container Edition proporciona características tan buenas para hacerlo que necesitas usarlo a tu favor porque me lo vas a agradecer por el resto de tu vida. Así que no quiero pasar un minuto más en esto. Me gustaría comenzar a contarte ahora mismo.

Lo primero que necesitamos hacer es entrar en la consola OSGi desde el contenedor. Entonces, lo primero que hacemos es exponer el puerto 8090 como puedes ver en la imagen a continuación

Ahora, podemos exponer ese puerto a tu host, usando el comando port-forward

kubectl port-forward deploy/phenix-test-project-v1 8090:8090

Y luego podemos ejecutar una solicitud HTTP para ejecutar cualquier información usando comandos como este:

curl -v http://localhost:8090/bw/framework.json/osgi?command=<command>

Y vamos a ejecutar primero la activación de las estadísticas del proceso así:

curl -v http://localhost:8090/bw/framework.json/osgi?command=startpsc

Y como puedes ver, dice que las estadísticas han sido habilitadas para la aplicación echo, así que usando ese nombre de aplicación vamos a recopilar las estadísticas a nivel

curl -v http://localhost:8090/bw/framework.json/osgi?command=lpis%20echo

Y puedes ver las estadísticas a nivel de proceso donde puedes ver las siguientes métricas:

Metadatos del proceso (nombre, proceso padre y versión)
Total de instancias por estado (creado, suspendido, fallido y ejecutado)
Tiempo de ejecución (total, promedio, mínimo, máximo, más reciente)
Tiempo transcurrido (total, promedio, mínimo, máximo, más reciente)

Y podemos obtener las estadísticas a nivel de actividad:

Y con eso, puedes detectar cualquier cuello de botella que estés enfrentando en tu aplicación y también estar seguro de qué actividad o qué proceso es responsable de ello. Así que puedes resolverlo de una manera rápida.

¡Diviértete y usa las herramientas a tu disposición!

Configuración de TIBCO Flogo: ¿Cómo dominarla en 5 minutos?

2026-01-182019-07-29 por Alexandre Vazquez

TIBCO Flogo es una plataforma excelente para construir tus microservicios y, desde el principio, vas a alcanzar un número de rendimiento increíble.

Pero, incluso con eso, estamos trabajando en un mundo donde cada milisegundo cuenta y cada MB de memoria cuenta, por lo que es importante conocer las herramientas que tenemos en nuestras manos para ajustar a un nivel más fino nuestra aplicación Flogo Enterprise.

Como ya sabes, Flogo está construido sobre el lenguaje de programación Go, por lo que vamos a diferenciar los parámetros que pertenecen al propio lenguaje de programación, y luego otros parámetros que son específicos de Flogo.

Todos estos parámetros deben definirse como variables de entorno, por lo que la forma de aplicarlos dependerá de cómo configures las variables de entorno en tu propia plataforma de destino (Windows, Linux, OSX, Docker, etc…)

Parámetros Específicos de Flogo OSS

Puedes consultar todos los parámetros y sus valores predeterminados en la documentación de Flogo:

Configuraciones Relacionadas con el Rendimiento

FLOGO_LOG_LEVEL: Permite establecer a nivel de inicio el nivel de registro que deseas usar para la ejecución de la aplicación. El valor predeterminado está configurado en «INFO» y se puede aumentar a DEBUG para realizar algunos diagnósticos o análisis adicionales y configurar en «WARN» o «ERROR» para aplicaciones de producción que necesitan el máximo rendimiento evitando imprimir trazas adicionales.
FLOGO_RUNNER_TYPE: Permite establecer a nivel de inicio el tipo de corredor y el valor predeterminado es POOLED.
FLOGO_RUNNER_WORKERS: Permite establecer a nivel de inicio el número de trabajadores de Flogo que van a ejecutar la lógica. El valor predeterminado es 5 y se puede aumentar cuando estás ejecutando en hardware potente que tiene mejores capacidades de paralelismo.
FLOGO_RUNNER_QUEUE: Permite configurar a nivel de inicio el tamaño de la cola del corredor que va a mantener en memoria las solicitudes que van a ser manejadas por los trabajadores. El valor predeterminado es 50 y cuando el número es alto también será alto el consumo de memoria, pero el acceso de los trabajadores a la tarea será más rápido.

Otras Configuraciones

FLOGO_CONFIG_PATH: Establece la ruta del archivo JSON de configuración que se va a usar para ejecutar la aplicación en caso de que no esté incrustado en el propio binario. El valor predeterminado es flogo.json
FLOGO_ENGINE_STOP_ON_ERROR: Establece el comportamiento del motor cuando ocurre un error interno. Por defecto está configurado en true y significa que el motor se detendrá tan pronto como ocurra el error.
FLOGO_APP_PROP_RESOLVERS: Establece cómo se van a recopilar las propiedades de la aplicación para ser utilizadas. El valor es el resolvedor de propiedades a usar en tiempo de ejecución. Por defecto es None y se incluye información adicional en la sección de documentación de propiedades de la aplicación.
FLOGO_LOG_DTFORMAT: Establece cómo se van a mostrar las fechas en las trazas de registro. El valor predeterminado es «2006–01–02 15:04:05.000».

Parámetros Específicos de Flogo Enterprise

Incluso cuando todas las propiedades de Project Flogo son compatibles con Flogo Enterprise, la versión empresarial incluye propiedades adicionales que se pueden usar para establecer comportamientos adicionales del motor.

FLOGO_HTTP_SERVICE_PORT: Esta propiedad establece el puerto donde se alojarán los puntos finales internos. Este punto final interno se utiliza para el punto final de verificación de estado, así como para la exposición de métricas y cualquier otro acceso interno que proporcione el motor.

FLOGO_LOG_FORMAT: Esta propiedad nos permite definir el formato de notación para nuestras trazas de registro. TEXT es el valor predeterminado, pero podemos usar JSON para que nuestras trazas se generen en JSON, por ejemplo, para ser incluidas en algún tipo de plataforma de ingestión de registros.

Parámetros Específicos del Lenguaje de Programación Go

GOMAXPROCS: Limita el número de hilos del sistema operativo que pueden ejecutar código Go a nivel de usuario simultáneamente. No hay límite para el número de hilos que pueden estar bloqueados en llamadas al sistema en nombre del código Go; esos no cuentan contra el límite de GOMAXPROCS.
GOTRACEBACK: Controla la cantidad de salida generada cuando un programa Go falla debido a un pánico no recuperado o una condición de tiempo de ejecución inesperada. Por defecto, un fallo imprime una traza de pila para la goroutine actual, omitiendo funciones internas del sistema de tiempo de ejecución y luego sale con el código de salida 2. El fallo imprime trazas de pila para todas las goroutines si no hay una goroutine actual o el fallo es interno al tiempo de ejecución. GOTRACEBACK=none omite completamente las trazas de pila de goroutine. GOTRACEBACK=single (el valor predeterminado) se comporta como se describe arriba. GOTRACEBACK=all agrega trazas de pila para todas las goroutines creadas por el usuario. GOTRACEBACK=system es como «all» pero agrega marcos de pila para funciones de tiempo de ejecución y muestra goroutines creadas internamente por el tiempo de ejecución. GOTRACEBACK=crash es como «system» pero falla de una manera específica del sistema operativo en lugar de salir.
GOGC: Establece el porcentaje objetivo inicial de recolección de basura. Se activa una recolección cuando la proporción de datos recién asignados a datos vivos restantes después de la recolección anterior alcanza este porcentaje. El valor predeterminado es GOGC=100. Configurar GOGC=off desactiva completamente el recolector de basura.

Manejo de Errores de Flogo

2026-01-182019-06-24 por Alexandre Vazquez

Tabla de contenidos

Introducción
Manejador de Errores
Condición de Error
Actividad de Lanzar Error

Introducción

Hemos cubierto los conceptos básicos del desarrollo de Flogo Enterprise en los artículos anteriores, pero hay un tema importante que no se ha discutido hasta ahora, y este es el manejo de errores de flogo. Siempre pensamos que todo va a funcionar como lo planeamos, y todo va a seguir el camino verde, pero la mayoría de las veces no es así, por lo que necesitas preparar tus flujos para estar listo para manejar estas situaciones.

Si estás acostumbrado al desarrollo de TIBCO BusinessWorks te vas a acostumbrar porque la mayoría de las formas de hacer las cosas son prácticamente las mismas, por lo que cualquier tipo de lógica que apliques a tus desarrollos se puede aplicar aquí. Cubramos primero los conceptos básicos.

Manejador de Errores

Un manejador de errores de flogo es la forma principal en que los desarrolladores de Flogo manejan los problemas que ocurren en el desarrollo y ha sido así para todas las versiones desde la primera hasta Flogo Enterprise 2.6.0 porque hasta ese momento era la única forma de hacerlo.

El manejador de errores es un flujo de errores diferente que se va a invocar cuando algo está mal, similar a un flujo de captura en el desarrollo de TIBCO BusinessWorks. Cuando haces clic en el botón de Manejador de Errores vas a entrar en un nuevo flujo con un iniciador predefinido llamado error como puedes ver en la imagen a continuación:

Los datos que van a iniciar este flujo son el nombre de la actividad que falló y el mensaje de falla, y luego puedes realizar cualquier lógica de manejo que necesites hacer hasta que el flujo sea devuelto. Las actividades que podrías usar y la lógica son exactamente las mismas que puedes usar en tu flujo principal.

Condición de Error

Desde Flogo Enterprise 2.6.0 se ha incluido una nueva forma de manejar errores, como dijimos hasta ese punto cualquier error genera una invocación del manejador de errores, pero esto no cubre todos los escenarios de uso cuando ocurre un error.

Como Flogo Enterprise comienza con un escenario de caso de uso de microservicio simple, el manejo de errores era suficiente para manejarlo, pero ahora, a medida que el poder y las características que Flogo proporciona han ido aumentando, se necesitan nuevos métodos para capturar y actuar cuando ocurre un error para cubrir estos nuevos escenarios. Entonces, ahora cuando creas una condición de rama puedes elegir tres opciones: Éxito, Éxito con Condición y Error.

Para hacer eso, solo necesitas hacer clic en el botón de motor que aparece en la creación de la rama desde la actividad que está generando el error:

Y podrías elegir una de las tres situaciones como puedes ver en la imagen a continuación:

Como las ramas son acumulativas, podemos tener una actividad con diferentes ramas de diferentes tipos:

Pero solo puedes agregar una rama de Tipo de Error para cada actividad, si intentas agregar otro campo se va a deshabilitar, por lo que no podrás hacerlo:

Actividad de Lanzar Error

Todo este contenido se ha centrado en cómo manejar errores cuando ocurren, pero también puedes necesitar lo contrario para poder detectar algo, hacer algunas verificaciones y decidir que esto debería manejarse como un error.

Para hacer eso tienes la Actividad de Lanzar Error donde puedes pasar los datos del error que deseas manejar en una interfaz de elemento de dos claves, una para el mensaje de error y otra para los datos del error, como puedes ver en la imagen a continuación:

Instalación de extensiones Flogo

2026-01-272019-05-27 por Alexandre Vazquez

En publicaciones anteriores, hemos hablado sobre las capacidades de Flogo y cómo construir nuestra primera aplicación Flogo, así que en este momento, si has leído ambos, tienes un conocimiento claro sobre lo que Flogo ofrece y lo fácil que es crear aplicaciones en Flogo.

Pero en esas capacidades, hemos hablado de que una de las fortalezas de Flogo es lo fácil que es extender las capacidades predeterminadas que Flogo ofrece. Las Extensiones de Flogo permiten aumentar las capacidades de integración del producto así como las capacidades de cómputo y se construyen usando Go. Puedes crear diferentes tipos de extensiones:

Disparadores: Mecanismo para activar un flujo de Flogo (generalmente conocidos como Iniciadores)
Actividades/Acciones: Lógica de implementación que puedes usar dentro de tus flujos de Flogo.

Existen diferentes tipos de extensiones dependiendo de cómo se proporcionan y el alcance que tienen.

Conectores Empresariales de TIBCO Flogo: Estos son los conectores proporcionados directamente por TIBCO Software para los clientes que están usando TIBCO Flogo Enterprise. Se lanzan usando TIBCO eDelivery como todos los demás productos y componentes de TIBCO.
Extensiones de Código Abierto de Flogo: Estas son las extensiones desarrolladas por la Comunidad y que generalmente se almacenan en repositorios de GitHub o cualquier otro sistema de control de versiones que esté públicamente disponible.
Extensiones Personalizadas de TIBCO Flogo Enterprise: Estas son las extensiones equivalentes a las Extensiones de Código Abierto de Flogo pero construidas para ser usadas en TIBCO Flogo Enterprise o TIBCO Cloud Integration (iPaaS de TIBCO) y que siguen los requisitos definidos por la Documentación de Flogo Enterprise y proporcionan un poco más de opciones de configuración sobre cómo se muestra esto en la interfaz de usuario.

Instalación usando la Interfaz Web de TIBCO

Vamos a cubrir en este artículo cómo trabajar con todos ellos en nuestro entorno y vas a ver que el procedimiento es prácticamente el mismo, pero la principal diferencia es cómo obtener el objeto desplegable.

Necesitamos instalar alguna extensión y para nuestro caso, vamos a usar ambos tipos de extensiones posibles: Un conector proporcionado por TIBCO para conectar a GitHub y una actividad de código abierto construida por la comunidad para gestionar las operaciones de archivos.

Primero, vamos a comenzar con el conector de GitHub y vamos a usar el Conector de Flogo para GitHub, que se va a descargar a través de TIBCO eDelivery como lo hiciste con Flogo Enterprise. Una vez que tengas el archivo ZIP, necesitas agregarlo a tu instalación y para hacer eso, vamos a ir a la página de Extensiones

Y vamos a hacer clic en Subir y proporcionar el archivo ZIP que hemos descargado con el conector de GitHub

Hacemos clic en el botón «Subir y compilar» y esperamos hasta que el proceso de compilación termine y después de eso, deberíamos notar que tenemos un disparador adicional disponible como puedes ver en la imagen a continuación:

Así que, ya tenemos nuestro disparador de GitHub, pero necesitamos nuestras actividades de Archivo y ahora vamos a hacer el mismo ejercicio pero con un conector diferente. En este caso, vamos a usar una actividad de código abierto que está alojada en el repositorio de GitHub de Leon Stigter. Y vamos a descargar el repositorio completo de flogo-components y subir ese archivo ZIP a la página de Extensiones como lo hicimos antes:

Vamos a extraer el repositorio completo e ir a la ruta de actividad y generar un archivo zip desde la carpeta llamada «writetofile» y ese es el archivo ZIP que vamos a subir a nuestra página de Extensiones:

La estructura del repositorio es prácticamente la misma para todos estos tipos de repositorios de código abierto, generalmente tienen el nombre flogo-components y dentro tienen dos carpetas principales:

actividad: Carpeta que agrupa todas las diferentes actividades que están disponibles en este repositorio.
disparador: Carpeta que agrupa todos los diferentes disparadores que están disponibles en este repositorio.

Cada una de estas carpetas va a tener una carpeta para cada una de las actividades y disparadores que se están implementando en este repositorio como puedes ver en la imagen a continuación:

Y cada una de ellas va a tener la misma estructura:

activity.json: Que va a describir el modelo de la actividad (nombre, descripción, autor, configuraciones de entrada, configuraciones de salida)
activity.go: Contiene todo el código de programación en Go para construir la capacidad que la actividad expone.
activity_test.go: Contiene todas las pruebas que la actividad debe tener listas para ser usadas por otros desarrolladores y usuarios.

NOTA: Las extensiones para TIBCO Flogo Enterprise tienen un archivo adicional llamado activity.ts que es un archivo TypeScript que define las validaciones de la interfaz de usuario que se deben realizar para la actividad.

Y una vez que tengamos el archivo, podemos subirlo de la misma manera que lo hicimos con la extensión anterior.

Usando CLI para Instalar

Además, si estamos usando el CLI de Flogo, aún podemos instalarlo usando directamente la URL a la carpeta de actividad sin necesidad de proporcionar el archivo zip. Para hacer eso, necesitamos habilitar el Administrador de Instalación usando el siguiente comando:

<FLOGO_HOME>/tools/installmgr.bat

Y eso va a construir una imagen de Docker que representa una herramienta CLI con los siguientes comandos:

Instalar: Instalar Flogo Enterprise, Conectores de Flogo, Servicios, etc. en el directorio de instalación actual.
Desinstalar: Desinstalar Flogo Enterprise, Conectores de Flogo, Servicios del directorio de instalación actual.

Y este proceso se puede usar con un Conector oficial así como con una Extensión OSS