¿Cómo escalar adecuadamente Jenkins?

En mi proyecto, tenemos un servidor AWS que ejecuta Jenkins Master + 1 Jenkins slave (2 ejecutores) ... y necesitamos más
Para aumentar nuestra potencia de construcción, tenemos tres opciones:

1. Amplíe : aumente la instancia de AWS y agregue más ejecutores.
2. Amplíe : aumente la instancia de AWS y agregue otro proceso esclavo jenkins.
3. Escalar horizontalmente : cree otra instancia de AWS con un esclavo jenkins y conéctelo al maestro

Queremos hacer 2. ya que estamos en una gran organización y nuestro actual maestro Jenkins ya tiene acceso a todos los lugares que necesita. Opción 3. "Nuevo servidor" es complicado ya que necesita más aprobaciones burocráticas que tomarán semanas.

Entonces mis preguntas son:

• ¿Hay algún problema técnico en la opción 2? . ¿Quizás los ejecutores de cada esclavo jenkins no son conscientes de los otros ejecutores esclavos?
• En general, ¿cuál es el mejor enfoque para escalar Jenkins? Ampliar o reducir la escala?

No existen problemas técnicos fundamentales con la ejecución de múltiples esclavos jenkins en la misma máquina. De hecho, Running Multiple Slaves en la misma máquina enumera varias buenas razones para hacerlo:

Si bien el uso correcto de los ejecutores evita en gran medida la necesidad de múltiples instancias esclavas en la misma máquina, hay algunos casos de uso únicos a tener en cuenta:

• Desea más configurabilidad entre los nodos configurados. Supongamos que tiene un conjunto de nodos para usar tanto como sea posible, y el otro nodo para usarse solo cuando sea necesario.
• Es posible que tenga varias instalaciones maestras Jenkins construyendo cosas diferentes, por lo que esta configuración le permitiría tener esclavos para más de un maestro en la misma caja. Así es, con Jenkins realmente puedes servir a dos maestros.
• Es posible que desee aprovechar la facilidad de iniciar / detener / reemplazar máquinas virtuales, tal vez junto con los complementos de Jenkins, como el complemento Libvirt Slaves .
• Desea maximizar su inversión y utilización de hardware, al mismo tiempo que minimiza el costo operativo (por ejemplo, gastos de servicios públicos para ejecutar esclavos inactivos).

En general , se prefiere el escalado, principalmente porque la capacidad de escalar está típicamente limitada por los tipos / tamaños de los recursos físicos disponibles.

En particular, para aumentar la potencia de compilación, recomendaría un análisis de su compilación real para determinar cómo utiliza los recursos de la máquina, cuáles son sus cuellos de botella y qué limitaciones de escalabilidad plantea revelar si la ampliación incluso ayuda.

Por ejemplo, encontré casos en los que el tiempo de compilación para 2 compilaciones paralelas en la misma máquina fue más largo que los tiempos de compilación combinados de las mismas 2 compilaciones ejecutadas secuencialmente (sin superposición) en la misma máquina. En tal caso, ni siquiera consideraría la ampliación, ya que en realidad disminuiría la capacidad general de construcción.

Usa Kubernetes y Helm.

Recomendaría usar la tabla Jenkins Helm. Se instala con helm install stable/jenkinsy se escala automáticamente.

https://github.com/kubernetes/charts/tree/master/stable/jenkins

Creo que no deberías hacer nada;)

Así un poco. Creo que necesita más ejecutores, ¿quizás sus compilaciones realmente requieren muchos recursos? Yo correría al menos 4 pero corremos de 6 a 8 dependiendo de los trabajos. Me gusta hacer coincidir el número de núcleos con los ejecutores. Por lo tanto, es posible que desee ampliar sus nodos, creo que ejecutamos un M4 grande para nuestros ejecutores 4-8.

También creo que debería escalar, pero debería hacerlo de manera inteligente. Jenkins tiene un complemento para escalar automáticamente en AWS dependiendo de lo que esté en la cola de compilación. Básicamente le dices cuántos trabajos y cuánto tiempo la espera antes de que se levante un esclavo y envíe los trabajos al nuevo esclavo. También puede establecer la cantidad máxima de esclavos, la cantidad mínima, etc.

Escalaría en lugar de escalar, optando por la opción 3. Hemos realizado una configuración en la que todos los agentes de Jenkins se ejecutan en un ECS (Jenkins basado en Docker personalizado) con un grupo de escalado automático. Tenemos a todos nuestros maestros Jenkins comunicándose con el ECS, compartiendo así la carga de trabajo en el ECS, y no es necesario recrear al maestro Jenkins en un ejercicio de ampliación.