Primeros ejemplos
Creación del primer proyecto freestyle
Creamos el primer proyecto de Jenkins. Comprueba que Jenkins puede llamar a Docker. Para ello crea un nuevo proyecto tipo freestyle.
En la sección Build Steps, añade un nuevo paso, Ejecutar linea de comandos (shell) . Pega estos comandos:
whoami
git --version
java -version
docker -vGuarda los cambios. Haz clic sobre Build now. Haz clic sobre la bolita verde para ver el la salida por consola.
Por consola se visualiza el resultado de ejecutar los comandos dentro del contenedor. Como puedes ver, git y java están instalados, venían ya en la imagen jenkins:lts de la que hemos partido en la definición del Dockerfile. Además, docker también está disponible, se ha instalado correctamente mediante la definición incluida en el Dockerfile. La ejecución finaliza correctamente, con el mensaje Finished: SUCCESS, por ello la bolita verde.
Creación del primer pipeline
Nodos de ejecución
De forma predeterminada, Jenkins ejecuta los proyectos sobre el nodo principal (main), que es el nodo (contenedor o máquina virtual) donde se ejecuta el propio Jenkins.
Puedes consultar los nodos disponibles en Jenkins en la sección Administrar Jenkins > Nodos.
|
Hasta ahora no hemos configurado otros nodos ni clouds donde ejecutar los proyectos, así que por defecto se ejecutan en el principal. |
Pipeline sobre el nodo principal
Creamos el primer proyecto de Jenkins tipo pipeline. Vamos a darle el nombre hello-maven-pipeline-on-master-node. Este pipeline se ejecutará sobre el nodo (agent) master, es decir, sobre el mismo contenedor que está ejecutando Jenkins.
Copia la siguiente definición de pipeline en el bloque Pipeline, Pipeline script.
pipeline {
agent any
tools {
maven 'Default Maven' (1)
}
stages {
stage('Build') {
steps {
sh '''
java -version
mvn -v
''' (2)
}
}
}
}| 1 | Utiliza la instalación de Maven que hemos hecho en la sección anterior, y le dimos el nombre Default Maven. |
| 2 | En la shell ejecutará los comandos para mostrar las versiones de Java y Maven. |
Haz clic sobre Build now, y visualiza la consola. Como parte de la salida, se debe visualizar algo así (puede que los números de versiones varíen):
[Pipeline] sh
+ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment Temurin-17.0.10+7 (build 17.0.10+7)
OpenJDK 64-Bit Server VM Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
+ mvn -v
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /var/jenkins_home/tools/hudson.tasks.Maven_MavenInstallation/Default_Maven
Java version: 17.0.10, vendor: Eclipse Adoptium, runtime: /opt/java/openjdk
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "6.5.0-1014-gcp", arch: "amd64", family: "unix"|
Lanzar las construcciones de proyectos en el nodo principal puede acarrear problemas de seguridad. De hecho, Jenkins (dependiendo de la versión) avisa de que esta configuración es inadecuada, y recomienda configurar agentes independientes donde lanzar las ejecuciones de los proyectos. 
Fig. 5. Aviso de evitar ejecuciones en el nodo máster de Jenkins
|
Pipeline con un contenedor como agente
La alternativa es que el pipeline se ejecute, en lugar de en el nodo principal, en un nodo tipo "agente" que se creará ex profeso a partir de un contenedor Docker disponible de DockerHub.
A continuación creamos el segundo proyecto de Jenkins tipo pipeline. Vamos a darle el nombre hello-maven-pipeline-on-container-node
pipeline {
agent {
docker {
image 'maven:3.9-eclipse-temurin-21-jammy' (1)
args '-v $HOME/.m2:/root/.m2' (2)
}
}
stages {
stage('Build') {
steps {
sh '''
java -version
mvn -v
'''
}
}
}
}| 1 | Elige entre las imágenes de Maven disponibles. En este caso, se ha elegido la versión 3.9 con Java 21, que es distinta a la que hemos instalado en el nodo principal. |
| 2 | Mapea el volumen del host $HOME/.m2 donde se almacenan las dependencias de Maven, para que estén disponibles en el contenedor, eliminando así la necesidad de volver a descargarlas en sucesivas ejecuciones. |
Te dará error al construir el proyecto.
[Pipeline] sh
+ docker inspect -f . maven:3.9-eclipse-temurin-21-jammy
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/maven:3.9-eclipse-temurin-21-jammy/json": dial unix /var/run/docker.sock: connect: permission deniedEl motivo es que en la máquina Jenkins, sobre el S.O. host, hay que abrir permisos en el socket de Docker para que desde dentro del contenedor Jenkins permita crear otros contenedores hermanos. Para ello, mediante el terminal ssh modifica los permisos así:
sudo chmod 666 /var/run/docker.sockTras ello deben construirse correctamente. La nueva salida será algo así:
[Pipeline] sh
+ java -version
openjdk version "21.0.2" 2024-01-16 LTS
OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode, sharing)
+ mvn -v
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/share/maven
Java version: 21.0.2, vendor: Eclipse Adoptium, runtime: /opt/java/openjdk
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.5.0-1014-gcp", arch: "amd64", family: "unix"|
Para que tras reiniciar la máquina se mantengan los permisos del socket de Docker: Crea el archivo Por último, dale los permisos adecuados al archivo Tras ello reinicia la máquina. Tras ello, comprueba que el socket de Docker tiene los permisos adecuados: |
|
No olvides que abrir permisos aL archivo |
Otros ejemplos similares con contenedores NodeJS están disponibles en la documentación de Jenkins
Usando varios contenedores como agente
Es habitual tener varias tecnologías en un mismo proyecto. Por ejemplo, un repositorio puede tener tanto un back-end basado en Java como un front-end basado en JavaScript. Combinar Docker y Pipeline permite usar diferentes agentes en diferentes fases (stages) del pipeline. Crea un nuevo pipeline `hello-pipeline-multiple-containers`con el siguiente contenido:
pipeline {
agent none
stages {
stage('Back-end') {
agent {
docker {
image 'maven:3.9-eclipse-temurin-21-jammy'
args '-v $HOME/.m2:/root/.m2'
}
}
steps {
sh 'mvn --version'
}
}
stage('Front-end') {
agent {
docker { image 'node:20.11.1-alpine3.19' }
}
steps {
sh 'node --version'
}
}
}
}
Conexión con la máquina de despliegue
Para automatizar el despliegue sobre la instancia que tenemos creada para ello, deberás permitir que Jenkins ejecute comandos sobre la máquina de despliegue a través de SSH. Para ello, la instancia Jenkins debe poder conectarse a la instancia de despliegue mediante una conexión SSH basada en autenticación por pareja de claves pública/privada, que ha demostrado ser más seguro sobre la autenticación estándar de nombre de usuario/contraseña.
Para ello, los pasos que se detallan a continuación permiten:
-
generar una nueva pareja de claves que usaremos para el despliegue,
-
copiar la clave pública generada en la instancia de despliegue,
-
y por último probar que la conexión se realiza correctamente.
Ejecuta los siguientes pasos:
Generar la nueva pareja de claves de despliegue
-
Conecta por SSH a la máquina Jenkins:
ssh ubuntu@instancia-jenkins
-
Crea la carpeta donde se va a guardar la nueva pareja de claves:
mkdir /home/ubuntu/jenkins_home/.ssh -
Crea una pareja de claves ssh de despliegue:
ssh-keygen -t rsa -b 4096 -
Cuando pida el nombre, escribe el nuevo nombre id_rsa_deploy junto con la ubicación donde Jenkins va a buscar las claves de forma predeterminada, que es:
/home/ubuntu/jenkins_home/.ssh/id_rsa_deploy -
Por último, deja la contraseña en blanco (pulsa ENTER):
Enter passphrase (empty for no passphrase):
Esto crea la clave privada en /home/ubuntu/jenkins_home/.ssh/id_dsa_deploy y una clave pública asociada en /home/ubuntu/jenkins_home/.ssh/id_dsa_deploy.pub. Esta nueva pareja de claves la usaremos exclusivamente para el despliegue de nuestros proyectos.
Al haberla guardado en la carpeta /home/ubuntu/jenkins_home/ los archivos están accesibles dentro del contenedor de Jenkins, porque como recordarás, al lanzar el contenedor Jenkins esa carpeta del host la habíamos mapeado con la carpeta /var/jenkins_home del contenedor.
Copiar la clave pública a la instancia de despliegue
-
Muestra el contenido de la clave pública:
cat /home/ubuntu/jenkins_home/.ssh/id_rsa_deploy.pub
-
Copia el contenido: con el ratón, selecciona el contenido de la clave, desde “ssh-rsa” hasta el final, y pulsa ENTER (o CTRC+C)
|
Debido a que algunos terminales añaden saltos delinea al copiar texto desde el terminal, como ocurre con cloud shell de GCP, es recomendable copiar el contenido de la clave pública en cualquier editor de texto "plano" (Notepad++, Sublime, VS Code, etc) y eliminar los saltos de línea, si los hubiera. |
-
Ahora pégalo en tu PC, lo necesitaremos más adelante.
-
Desconecta de la máquina Jenkins:
exit -
Conecta por ssh a la instancia de despliegue
-
Edita el archivo
authorized_keys:
nano /home/ubuntu/.ssh/authorized_keys
-
Ese archivo ya tenía una clave pública, la correspondiente a tu pareja de claves personal que inyectamos en la creación de la instancia con Terraform (por eso has podido conectar por ssh a esa máquina). Pega el contenido de la clave pública de despliegue. Ahora debe tener 2 claves públicas.
-
Ya puedes desconectar de la instancia de despliegue.
Prueba de la conexión desde jenkins a despliegue
Vamos a probar que funciona:
-
Conecta de nuevo a la instancia jenkins y prueba la conexión ssh a la instancia de despliegue. Recuerda que puesto que Jenkins se está ejecutando como un contenedor, debes probar la conexión ssh desde dentro del contenedor:
docker exec -it jenkins-docker ssh ubuntu@instancia_deploy -i /var/jenkins_home/.ssh/id_rsa_deployEn el comando anterior:
-
docker exec -itindica ejecutar un comando desde dentro del contenedor -
jenkins-dockeres el nombre del contenedor -
ssh ubuntu@instancia_deploy -i /var/jenkins_home/.ssh/id_rsa_deployes el comando a ejecutar en el contenedor. En este caso,sshcon el parámetro-i …para indica la clave privada que debe usar para conectar.
Antes de ejecutar el comando, modifica instancia_deploy por el nombre DNS de tu instancia de despliegue.
-
Recuerda que
/var/jenkins_homees la carpeta HOME del usuario jenkins dentro del contenedor, y jenkins es el usuario del contenedor que ejecuta Jenkins.
-
La primera vez que realizas una conexión ssh desde un usuario en una máquina origen a una destino, te pregunta si deseas almacenar la clave de host de destino en la lista de hosts conocidos (
known_hosts) de tu máquina origen. Contesta:yes
-
Si todo ha ido bien, la conexión se ha debido realizar. Puedes comprobarlo porque en el
promptte aparecerá que estás en la máquina de despliegue. Sal conexit. Ahora elpromptte muestra que estás en la máquina Jenkins.
|
Si no ha correcto, verifica que la ruta al archivo de la clave privada es correcta, y que el nombre de la máquina de despliegue es correcto. |
-
Comprueba que la clave de host de la máquina de destino (despliegue) se ha guardado en la máquina origen (jenkins) en el archivo
~/.ssh/known_hostsdel usuario que ha ejecutado el comando ssh, en nuestro caso, del usuario jenkins de contenedor:
docker exec -it jenkins-docker cat /var/jenkins_home/.ssh/known_hosts
-
Puedes comprobarlo también mostrando el contenido de known_hosts en el archivo
/home/ubuntu/jenkins_home/.ssh/known_hosts. Ambos coinciden, recuerda que hay un volumen mapeado entre la carpeta local/home/ubuntu/jenkins_homey la carpeta del contenedor/var/jenkins_home.
-
Ahora que la conexión por SSH entre la máquina Jenkins y la máquina de despliegue es correcta, vamos a hacer que Jenkins automatice la ejecución de comandos sobre la máquina de despliegue: entra en Jenkins y añade el siguiente comando al proyecto hello_docker existente, sustituyendo MAQUINA_DEPLOY por el nombre DNS de la máquina de despliegue.
ssh -i ~/.ssh/id_rsa_deploy ubuntu@MAQUINA_DEPLOY "pwd && ls -la"Como aclaración de este comando:
-
el parámetro
-iindica la clave privada que queremos usar en la conexión ssh -
"pwd && ls -la"son comandos básicos que ejecuta sobre la máquina remota. Hemos indicado estos comandos simplemente para probar que la conexión se realiza correctamente.
Tras ejecutar el proyecto en Jenkins, el resultado debe ser correcto.
