telefonicaiot/tk8s-jenkins-agent repository overview

⁠Esta es una guía para crear un contenedor con herramientas de desarrollo

1. Crear un contenedor con herramientas de desarrollo

   • El contenedor se crea con "docker compose up -d"
   • Se ha creado un archivo "Dockerfile" con las herramientas y dependencias necesarias
   • Se usa creacion de imagen en etapas para reducir el tamaño de la imagen.  

2. Se accede al contenedor con

docker exec -it herramientas /bin/bash

La imagen telefonicaiot/tk8s-jenkins-agent:0.15.0 ya está construida y publicada. Los comandos siguientes permiten reconstruirla y ejecutarla manualmente. Ejecutar la construcción desde este directorio docker/ para que el contexto incluya tests/check-tools.sh.

Podemos construir la imagen con el comando:

docker build --rm -t telefonicaiot/tk8s-jenkins-agent:0.15.0 .

Y ejecutar el contenedor con usuario no root con:

docker run --rm --user 1000 -it telefonicaiot/tk8s-jenkins-agent:0.15.0 bash

1. Se comprueban las versiones de las herramientas con los comandos:

helm version
helm plugin list
oc version
sops --version
stern --version
kubectl version --client
kubectl-1.35 version --client
kubectl-1.36 version --client
ansible --version
talosctl version --client
talosctl-1.11 version --client
talosctl-1.12 version --client
talosctl-1.13 version --client
talosctl-1.14 version --client
cilium version --client
yq --version
java -jar /usr/local/bin/agent.jar -version
mongosh --version
ansible-galaxy collection list | grep postgresql
pip3 show psycopg2-binary
nano --version
check-upgrade-tools

La comprobación check-upgrade-tools no escribe archivos ni llama a APIs del clúster. Permite verificar las herramientas de la imagen publicada; falla si falta un binario o si una versión fijada no coincide. Para Remoting comprueba que agent.jar se ejecuta y devuelve una versión, sin exigir un valor fijo. Comprobar después en Jenkins que cada agente aparece conectado y puede ejecutar un job con su label. Las comprobaciones locales no demuestran esa conexión.

⁠Contrato de herramientas para la actualización de east2

La misma imagen puede permanecer en los agentes para gestionar el clúster actualizado: talosctl apunta a talosctl-1.14 y kubectl a kubectl-1.36. El values.yml del mantenimiento debe fijar tools.kubectl: kubectl-1.35; este cliente es compatible con todos los saltos, incluso cuando los API servers tienen versiones mixtas. Para comandos manuales durante el recorrido, usar también kubectl-1.35. El predeterminado 1.36 no cubre servidores 1.34. Durante los saltos, los jobs deben seleccionar explícitamente el cliente de la fase. No cambiar en conjunto todas las referencias JENKINS_AGENT_VERSION: el backup de etcd también la utiliza. Las dos releases de mantenimiento usarán un override de imagen con el mismo digest inmutable de la versión publicada.

Para el init del agente, configurar talos.clientBinary: talosctl-auto en el chart. El wrapper requiere TALOSVIP y conserva todos los argumentos recibidos:

talosctl-auto kubeconfig -n "$TALOSVIP" "$KUBECONFIG"

Sondea mediante version --short los clientes instalados (1.14 a 1.11), con un timeout de 15 segundos por intento. Sólo considera el Tag del bloque Server; selecciona la minor correspondiente y ejecuta una vez el comando recibido. Falla si no puede detectar el servidor, si su minor no está soportada o si falta el cliente adecuado. El kubeconfig y las credenciales Talos preexistentes siguen siendo responsabilidad del init; el sondeo no modifica configuración. Este selector no cambia la selección explícita por fase del playbook.

Pruebas locales del selector, sin acceder al clúster:

python3 -B tests/test_talosctl_auto.py

Las pruebas conservan sus fixtures en /tmp y muestran su ruta; no limpian ni eliminan archivos.

Cilium CLI y Cilium tienen numeraciones independientes: la CLI es 0.20.0 y el destino del chart en east2 es Cilium 1.20.1. El README oficial de Cilium CLI 0.20.0⁠ declara soporte para Cilium 1.17 y posteriores. Por ello se incluye una sola CLI 0.20.0 para todo el recorrido, sin mantener también la 0.19. Esta compatibilidad publicada no sustituye las comprobaciones de salud de cada fase en el clúster.

Los agentes CP y worker deben tener nombres, secretos y labels distintos en Jenkins. Un job activo no se traslada entre pods; la fase siguiente se asigna al otro agente una vez terminada la anterior y comprobada su conexión.

⁠Obtención de Remoting desde Jenkins Tools

El Dockerfile descarga agent.jar directamente del controlador mediante https://${JENKINS_SERVER}/jnlpJars/agent.jar. El argumento JENKINS_SERVER vale tools-jenkins.iotplatform.telefonica.com por defecto y también está configurado en docker-compose.yml. Se conserva así el origen de descarga anterior, sin fijar una versión ni un SHA-256 de Remoting en el repositorio. El endpoint oficial del agente⁠ proporciona el archivo correspondiente al controlador.

La descarga necesita acceso a Jenkins Tools desde el entorno de construcción. Si Docker reutiliza la capa en caché, no vuelve a consultar el controlador; para recoger una actualización de Remoting, reconstruir con --no-cache. Una imagen ya construida conserva su agent.jar hasta que se reconstruya y se despliegue la nueva imagen.

Para consultar la versión incluida, ejecutar dentro de la imagen:

java -jar /usr/local/bin/agent.jar -version

check-upgrade-tools ejecuta esta consulta y muestra el resultado. La comprobación de conexión al orquestador se realiza después desde Jenkins.

⁠Procedencia e integridad

Versiones y hashes consultados el 2026-09-13 y el 2026-09-14:

• Talos: https://github.com/siderolabs/talos/releases/download/<version>/sha256sum.txt, entrada talosctl-linux-amd64 para cada versión de la tabla.
• kubectl: SHA-256 oficiales de v1.35.8⁠ y v1.36.4⁠.
• Cilium CLI: SHA-256 oficial del archivo Linux amd64 de v0.20.0⁠.
• Margen de versiones de kubectl⁠.

El Dockerfile verifica los SHA-256 de Talos, kubectl y Cilium CLI antes de instalarlos. Si se cambia una versión mediante --build-arg, se debe actualizar también su hash y el contrato de tests/check-tools.sh; un hash no coincidente aborta el build. No se usa latest para estas herramientas. Otros componentes preexistentes del Dockerfile conservan su mecanismo de instalación.

La imagen 0.15.0 está publicada. La comprobación de conexión de los agentes con Jenkins se realiza al desplegar sus releases en el clúster.