Una de las herramientas con las que trabajamos diariamente es Terraform, pero ¿qué es?

Terraform es una herramienta de infraestructura como código (IaC) desarrollada por HashiCorp, siendo su objetivo principal permitirnos automatizar y gestionar la infraestructura de nuestros clientes de manera eficiente.

Una de las principales preguntas que hay que plantearse antes de comenzar a trabajar con Terraform es la organización del código, ya que lo normal en las arquitecturas es tener varios entornos: producción, preproducción, desarrollo o los que en cada caso existan.

Pues bien, para tener el código organizado por cada entorno pueden existir infinitas formas de plantearlo, pero hoy nos centraremos en dos:

• Opción 1: Mediante directorios.
• Opción 2: Uso de workspaces.

El pasado 10 de junio se publicó Debian 12, que viene bajo el nombre de “Bookworm”. Esta versión del popular sistema operativo tendrá soporte hasta 2028, y tras su salida, Debian 11 “Bullseye” ha pasado a ser oldstable aunque su soporte se mantiene hasta 2026. Mientras, Debian 10 “Stretch” pasa a ser oldoldstable y ya no recibe actualizaciones de seguridad, aunque aún tiene soporte LTS hasta el año que viene.

En este artículo vamos a comentar algunos de los cambios que más nos han llamado la atención y que creemos que se deben tener en cuenta para aquellos que vayan a actualizar a esta nueva versión. Os incluimos una guía de cómo realizar dicha actualización

¡Comenzamos!

En entornos de Kubernetes, los volúmenes persistentes desempeñan un papel crucial en el almacenamiento de datos de aplicaciones. Tener un entorno dinámico donde los recursos se crean y se destruyen de forma automática, es tan útil como peligroso si nuestros datos persistentes están entre estos recursos del cluster.

Uno de los almacenamientos más utilizados en entornos AWS es Amazon Elastic Block Store (EBS). En entornos de Kubernetes, gracias al controlador de almacenamiento externo EBS-CSI (EBS Container Storage Interface), tenemos la opción de utilizar volúmenes persistentes de EBS de manera eficiente y segura. La base radica en la capacidad de crear snapshots de volúmenes asociados a recursos de Kubernetes para manejarlos con facilidad.

Elasticsearch es un motor de búsqueda y analítica distribuido, gratuito y abierto para todos los tipos de datos, incluidos textuales, numéricos, geoespaciales, estructurados y no estructurados. Está desarrollado a partir de Apache Lucene y fue presentado por primera vez en 2010. Elasticsearch es el componente principal del Elastic Stack (ELK Stack), compuesto por Elasticsearch, Logstash y Kibana, que permite la ingesta, el enriquecimiento, el almacenamiento, el análisis y la visualización de datos.

Por su parte, Kibana es una aplicación de frontend que proporciona capacidades de visualización de datos y de búsqueda para los datos indexados en Elasticsearch, además de otras tareas de administración. Logstash es el software encargado de la ingesta, transformación y envío de los datos, en este caso a Elasticsearch.

En un artículo anterior vimos cómo realizar la instalación de un plugin en Jenkins (SSH Agent) y un pipeline con el objetivo de testar esta conexión remota por SSH.

En esta ocasión, vamos a crear un pipeline en 3 pasos: clonación de código, build y deploy. En éste, vamos a desplegar el código de sencilla aplicación node en una instancia remota.

Los englobaremos en 2 fases, la fase "sources" y la fase "deploy".

Para ello, utilizaremos un simple "Hello-world" en NodeJS cuyo código fuente puedes encontrar en este repositorio.

Según lo indicado, la definición del pipeline será la siguiente:

Unos meses atrás hicimos una pequeña introducción al servicio de WAF donde, además de hablar superficialmente de que trata este servicio y algunas configuraciones básicas, también comentamos muy brevemente que uno de sus atractivos eran las reglas administradas por AWS.

Pues bien, hoy hablaremos de estas reglas administradas y cómo podemos activarlas en nuestras WAF ACL. Algunas nociones y configuraciones básicas no las explicaremos en esta ocasión para no alargarnos mucho, pero las puedes consultar en este otro post que publicamos. 

Bien, comenzamos …

En este artículo nos alejaremos del apartado más técnico y hablaremos de arquitectura, pero no de aquella de estilo barroco o renacentista, ni de las grandes construcciones como el Burj Khalifa, sino de arquitectura en la nube.
 
Concretamente nos vamos a centrar en el servicio VPC de AWS y vamos a plantear la situación de tener los entornos de producción y preproducción (u otros entornos no productivos):

• En diferentes VPCs
• En diferentes subredes dentro de la misma VPC

Además, todo ello puede tener impacto en el tema de costes, que suele ser uno de los puntos que más nos preocupan.

Antes de nada convendría repasar el concepto de VPC.

OpenShift permite a los desarrolladores crear, implementar y administrar aplicaciones en contenedores de manera eficiente y escalable. Sin embargo, al trabajar con contenedores, es importante tener en cuenta la seguridad y la protección del sistema operativo subyacente.

En un artículo anterior, hablamos de seccomProfile como mecanismo de seguridad del kernel Linux con restricciones de llamadas al sistema. Hoy abordamos otro componente para mejorar la seguridad de nuestros contenedores en Openshift: los objetos SSC (SecurityContextConstraints).

¿Qué es SecurityContextConstraints?

SecurityContextConstraints (SCC) es una funcionalidad de OpenShift que permite definir políticas de seguridad para los contenedores que se ejecutan en la plataforma.

SCC permite a los administradores de la plataforma controlar los privilegios de los contenedores, limitando el acceso a ciertas acciones desde el contenedor que podrían comprometer la seguridad de la plataforma o de los datos de usuario.