Jenkins es una de las herramientas de integración continua más utilizadas dentro de los stacks de DevOps a nivel mundial. Una de sus características clave es la escalabilidad mediante topología maestro-esclavo, donde los stages de los jobs se ejecutan en distintos agentes mientras el Jenkins maestro funciona con recursos mínimos.

Esto resuelve dos problemas comunes con un solo servidor: la sobrecarga en momentos de muchas ejecuciones y el desperdicio de recursos cuando no hay actividad (por ejemplo, en las madrugadas). Pero aparece otro reto: si tienes varios agentes esclavo, ¿cómo mantienes la infraestructura eficiente y evitas llenarte de instancias EC2 ociosas?

AWS ofrece las instancias spot de Amazon EC2, que permiten ahorrar hasta un 90% de costos comparado con instancias on-demand. Son candidatos perfectos para agentes de Jenkins: se crean solo cuando se necesita ejecutar un job y se destruyen automáticamente cuando ya no se requieren.

Comparativo de costos para un Jenkins que ejecuta jobs durante 4 horas al día:

ConfiguraciónCosto mensual
Spot fleet t3.medium (4 h/día)$2.76
On-demand t3.small (24×7)$30.37

En este tutorial vamos a construir una arquitectura maestro-esclavo usando un Spot Fleet Request de EC2 Spot para cargas de trabajo Windows.

Arquitectura

Tenemos una instancia EC2 con Jenkins instalado, con un rol IAM para listar y manipular el Spot Fleet Request. El Spot Fleet escala automáticamente con la ejecución de los jobs, pudiendo bajar a 0 instancias cuando no hay ningún job corriendo.

Para implementar la arquitectura, primero crearemos una AMI base que se usará en el Spot Fleet Request.

1. Creación de AMI base

Necesitamos una AMI con el software requerido para funcionar como agentes de Jenkins.

Lanza una instancia EC2 basada en Windows Server 2019 with containers (para usar Docker dentro de los pipelines de despliegue). En los grupos de seguridad abre los puertos 3389 (RDP) y 22 (SSH) para conexión.

Crear usuario administrador

Jenkins usará este usuario para conectarse con los agentes:

  1. Conéctate por RDP a la instancia.
  2. Abre lusrmgr.msc (Local Users and Groups).
  3. Click derecho en Users → New User.
  4. Nombre: jenkins, contraseña segura. Desmarca “User must change password at next logon”. Marca “Password never expires” y “User cannot change password”.
  5. Click derecho en el usuario creado → Properties → pestaña Member of → Add → grupo Administrators.

Instalar OpenSSH

Necesitamos OpenSSH para permitir conexión maestro-agente por SSH:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'

Validación:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

Instalar Java y Git

Los agentes de Jenkins necesitan Git y Java. Los instalamos con Chocolatey:

[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls"
Set-ExecutionPolicy RemoteSigned -Confirm:$false
iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex

choco install javaruntime -y
choco install git.install -y

Crear AMI

En la consola de AWS, selecciona la instancia y ve a Actions → Image → Create Image para generar la imagen.

2. Generación del Spot Fleet Request

Una vez creada la AMI, creamos un Spot Fleet Request mediante una plantilla CloudFormation.

Si necesitas la plantilla CloudFormation que usamos en este caso, escríbenos a /contacto?servicio=devops y te la compartimos.

En los parámetros, ingresa:

  • AMI generada en el paso anterior.
  • VPC y grupo de seguridad del Jenkins maestro.
  • Tamaño de instancia preferido.
  • Llave SSH para acceso a los agentes (si fuera necesario).

3. Configuración de Jenkins

Para usar el Spot Fleet, instala el plugin EC2 Fleet Jenkins Plugin.

  1. Configuración de Jenkins (/configure): en la sección Nube, Añadir una nueva nube → EC2 Fleet.

  2. Ingresa un Name, selecciona la región del Spot Fleet Request y selecciona el Spot Fleet creado.

  3. Launcher: crea credenciales con el usuario jenkins y la contraseña configurada en la AMI.

  4. Host Key Verification Strategy: selecciona Non verifying Verification Strategy.

  5. Avanzado → Prefix Start Agent Command:

    powershell -Command "cd C:\Users\jenkins ; java -jar remoting.jar" ; exit 0 ; # '

  6. Suffix Start Agent Command:

    '

  7. Marca Connect using private IP.

  8. Define un label para usar en los Jenkinsfile (por ejemplo ec2-fleet).

  9. Jenkins Filesystem Root: C:\Users\jenkins.

  10. Minimum Cluster Size: 0.

4. Validación con un pipeline de prueba

Crea un nuevo Job de tipo Pipeline y usa el siguiente script:

pipeline {
    // Etiqueta del Spot Fleet configurado en el paso anterior
    agent { node { label 'ec2-fleet' } }

    stages {
        stage('Build') {
            steps {
                echo 'Build'
            }
        }
        stage('Test') {
            steps {
                script {
                    docker.image('hello-world').inside() {
                        echo 'example inside docker container'
                    }
                }
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploy'
            }
        }
    }
}

Cuando el pipeline se ejecuta, en la pantalla principal de Jenkins verás el estado de las flotas de instancias, indicando para cada Spot Fleet Request el número actual de instancias y las instancias objetivo.

Conclusión

Con esta configuración tu flota de instancias spot está lista para distribuir la carga de trabajo de tus pipelines automáticamente, escalando a cero cuando no hay actividad. El ahorro vs on-demand suele ser de 80-90% en cargas variables como CI/CD.

Algunas consideraciones operativas para producción:

  • Define un mix de tipos de instancia en el Spot Fleet para tolerar interrupciones de capacidad spot.
  • Usa Spot Fleet con On-Demand baseline para jobs críticos que no toleran interrupción.
  • Monitorea métricas de fulfillment y interruption rate del Spot Fleet en CloudWatch.
  • Considera alternativas modernas como CodeBuild Managed Runners si tu CI corre en GitLab — más sobre esto en GitLab + AWS CodeBuild Managed Runners.

Cómo lo aplicamos en Caleidos

Reducciones de 80-90% en infraestructura de CI/CD son habituales en clientes que migran de Jenkins on-prem a esta arquitectura. La pieza de FinOps continuo va más allá: rightsizing automático, mix óptimo on-demand/spot por carga y observabilidad de fulfillment.

Caleidos diseña, implementa y opera plataformas DevOps modernas como parte de nuestro servicio DevOps & Automatización y FinOps & Optimización de Costos AWS. Operación 24×7 incluida con Caleidos Lens©.

¿Quieres reducir tu factura de CI/CD? Hablemos →