Simplificando el setup de Jenkins con Docker

A la hora de hacer el setup de Jenkins hay diversas cuestiones que resolver las cuales pueden variar dependiendo del contexto. En términos muy generales esas cuestiones se resuelven:

  • operando directamente sobre Jenkins, por ejemplo para instalar plugins
  • o bien operando sobre el servidor en el cual Jenkins está corriendo, por ejemplo para instalar un SDK

La importancia que se le da al primer punto es muy variable y depende de si se trata de un “Jenkins Silvestre” (Jenkins manejado por un equipo de desarrollo sin ningún tipo de soporte organizacional) o si se trata de un “Jenkins Corporativo” que es administrado por un grupo de la organización.

Pero el segundo punto, es algo central si pretendemos utilizar Jenkins para buildear. Si queremos utilizar Jenkins para buildear C#, tendremos que asegurar que el servidor donde corre Jenkins tenga el correspondiente SDK instalado (o eventualmente necesitaremos un Jenkins Slave que tenga el SDK.) Esta situación se repite para cada tecnología/lenguaje que uno pretenda buildear. Más allá de la tarea de instalar el SDK en si misma, el punto es que hay que loguearse en el servidor para llevarla a cabo. Una forma de simplificar este setup es utilizar Docker. O sea, en lugar de instalar los SDK en el servidor de Jenkins, uno instala simplemente Docker y luego utiliza un contenedor Docker que contenga el SDK que cada proyecto requiera. Al mismo tiempo esto simplifica el escenario donde tenemos proyectos con dependencias de SDK que tiene conflictos entre si.

A mi parecer esta estrategia aún no está muy difundida pero me parece que a mediado plazo se impondrá como estándar de facto. De hecho, las últimas versiones de Jenkins (las que vienen nativamente con el plugin de Pipeline 2.5 o superior) simplifican mucho este setup. Basta con tener Docker instalado en el servidor de Jenkins y declarar la imagen builder a utilizar en nuestro Jenkinsfile.

El siguiente fragmento de código muestra un job de Jenkins que utiliza una imagen de node 8.9. Lo que hace es trivial, simplemente invoca node –version y escribe el output en un archivo de texto. Lo interesante es que el archivo de texto resultante queda dentro del workspace del job, o sea: Jenkins se está encargando de “sacar” el archivo que se genera dentro del contenedor Docker.

node {
docker.image('node:8.9-alpine').inside {
stage('Test') {
sh 'node --version > version.txt'
}
}
}

Servidores CI/CD: diferencias de modelos, Jenkins vs CircleCI

Servidores CI/CD: diferencias de modelos, Jenkins vs CircleCI

Jenkins es una de las herramientas de CI/CD más difundidas, posiblemente por su potencia y también por su larga historia (su primera versión es de 2005). Yo empecé a utilizarlo allá por 2008 cuando aún era Hudson. Inicialmente era un servidor de integración continua. Luego con el auge de la entrega continua se lo empezó a utilizar para hacer deployments. Esta última característica cobró más impulso a partir de la versión 2.

CircleCI es una herramienta de aparición mucho más reciente y viene a resolver el mismo problema que Jenkins pero con un modelo distinto.

En este post decidí hablar concretamente de Jenkins y Circle porque hoy en día estoy trabajando en dos proyectos, cada uno con una de estas herramientas. Pero en realidad es que en lugar de Circle podría referirme a Travis o a los Builders de Gitlab, pues conceptualmente representan el mismo modelo. Del mismo modo, en lugar de Jenkins podría hablar de Bamboo.

Veamos entonces algunas diferencias de estos dos modelos. CircleCI funciona atado a un repositorio Git (puede ser GitHub, BitBucket o algún otro). Al mismo tiempo, el funcionamiento de la herramienta está definido por un archivo (en formato yaml) donde uno define sus Jobs/Workflows. Si bien la herramienta provee una interface gráfica web, la misma es principalmente para visualización y solo permite ajustar algunos pocos settings, pero no permite la creación de Jobs. La situación es análoga al utilizar Travis o GitLab. Este modelo va muy bien con las estrategias del tipo GitOps, donde todo el pipeline de delivery se articula a partir de operaciones/eventos Git.

Por otro lado, Jenkins ofrece un modelo distinto, uno puede crear jobs asociados a distintos tipos de repositorios o incluso permite crear jobs sin asociación alguna a repositorios. Al mismo tiempo ofrece una interface de usuario web que permite manipular completamente la herramienta, de hecho, durante mucho tiempo esta era la única opción. Luego fueron apareciendo distintas opciones/plugins que posibilitaron tener un manejo similar al de Circle/Travis.

En otra dimensión de análisis podríamos decir que el modelo de Circle/Travis es en cierto modo “CI/CD as a Service”. Son herramientas muy enfocadas en CI/CD con toda una serie de cuestiones de diseño ya tomadas de antemano. De hecho en general el modelo de extensibilidad de estas herramientas es bastante limitado.

Por su parte Jenkins surgió inicialmente en modelo más On-Premises/Producto, contando desde su inicio con un modelo muy potente de extensibilidad y luego fue evolucionando incorporando características de los modelo más SaaS. La arquitectura extensible de Jenkins ha posibilitado la aparición de nuevos proyectos montados sobre Jenkins como ser JenkinsX.

Personalmente me siendo muy a gusto trabajando con Jenkins, creo que es un producto muy versátil y lo he utilizado para algunas cosillas más allá de CI/CD. Al mismo tiempo que creo en un contexto organizacional Jenkins ofrece varias características y posibilidades de extensibilidad no presentes en el otro modelo. Entre las bondades de Jenkins podría nombrar la integración con muchísimas herramientas, las capacidades de templating, slicing configuration y la posibilidad de generar plugins en caso que uno lo necesite (lo he hecho y no pareció complicado). Sin embargo y a pesar de mi gusto por Jenkins, creo que la característica de Pipeline as Code (jenkinsfile) no está lo suficientemente lograda. Perdón, creo que la funcionalidad está bien, pero personalmente me siento más a gusto utilizando un set de plugins tradicionales (como JobDSL, el JobBuilder y BuildPipeline) que usando los Jenkinsfile.

Configuring Jenkins Authentication with Auth0

The procedure described here is based on Jenkins 2.7.4 but I think it should also work with other (not so distant) versions.

First of all, log into your Auth0 account.

Then create a new client application (“Clients” item in left-hand menu).

auth0_1

In  the “Create Client” dialog set the name of your client application (for example “MyJenkins“) and choose the application type “Regular Web Applications“, finally click “Create“.

auth0_2

Once the application is created, go to “Settings” and set the value of the “Allowed Callback URLs” to “http://YOUR_JENKINS_URL/securityRealm/finishLogin“. Click “Save Changes“.

auth0_4

Scroll down to the “Advanced Settings” section, click on “Endpoints“. Take the SAML Metadata URL and save the content in that URL into a file (remember this file because we will use it later when configuring Jenkins).

auth0_9

Go to the “Addons” tab and enable “SAML2” option.

auth0_5

In the Addon configuration dialog edit the settings to set the “audience” and “recipient” values to “http://%5BYOUR_JENKINS_URL%5D/securityRealm/finishLogin“.

auth0_6

Click “Save” and close de dialog. Now you should see the SAML2 option is enabled.

auth0_7

 

That’s all on Auth0 size, now let’s work on Jenkins.

To perform the following steps, you need to be logged in with a user with administrator profile. I assume the reader is already familiar with Jenkins so the instructions won’t be so detailed.

First of all we need to install the “SAML Plugin“.

auth0_8

Once the installation is ready go to “Manage Jenkins > Configure Global Security“. In the “Security Realm” pick “SAML 2.0” and in the “IdP Metadata” box paste the content of metadata file you saved on before.

Scroll down to the “Authorization” section and ensure the option “Logged-in users can do anything” is selected (authorization  is something we will work on later). Scroll down to the bottom of the page and click “Save“.

That’s all.  Close the browser [*] and the next time you try to log in you will be redirected to Auth0. Now every user enabled in your Auth0 account will be able to log into Jenkins.

In the next article I will explain how to configure authorization.

[*] at the moment of this writing there is bug in the SAML plugin that affect a logout feature https://issues.jenkins-ci.org/browse/JENKINS-37311.

Integrating .Net Build tools: MSBuild, NuGet, FxCop, StyleCop and NUnit

These days it is very common to have a continuous build process that includes: compilation, code analysis and automated tests. The way of implementing this kind of process varies depending on the technology of the project.

I have worked with Ruby, Python, Java, JavaScript, Smalltalk and some other languages and in all cases you just need to install 3 tools:

  • the runtime/sdk (like ruby, jdk, cog)
  • a package manager (like bundle, maven, pip, metacello)
  • a build tool (like rake, maven, fabric)

Any other thing you may need (linter, testing framework, etc), you can get it using the package manager and make it run as part of your build script.

But in .Net the situation is more complex. First of all everything seems to be very tight to Visual Studio (the IDE). Because of this, many people just install the Visual Studio in the build server.

Additionally to this the .Net SDK does not provide a test framework. You can use NUnit (which you will have to install manually) or you can use MSTest but to use it you need to install Visual Studio.

FxCop (the linter) comes with Visual Studio but if you don’t want Visual Studio, then you have to install it manually.

So, in order to avoid several manual tasks when setting up a new dev box and also to minimize any possible difference between dev boxes and the build server box I did the following:

  • I downloaded all the tools I wanted to use in my build process and placed them into the same directory (c:\BuildTools).
  • I wrote a build script (using MSBuild and defining my own targets). This script “glues” the invocation to all of these tools: NuGet, FxCop, StyleCop and NUnit.
  • Finally I package all these stuff in a self-extracting .zip file so all the team members can easily replicate my setup.

In order to have the build process to run continuously I also installed this package in the Jenkins build server.

buildtools-v4buildtools-layout

Jenkins: Jobs as Code

Jenkins: Jobs as Code

Una de las funcionalidades destacadas en la nueva versión de Jenkins es la posibilidad de definir los pipelines utilizando un lenguaje de dominio específico. Esto resulta muy útil cuando uno tiene que manejar una cantidad importante de jobs y al mismo tiempo facilita el control de configuración ya que permite que la definición de los jobs sea tratada como código en lo referente al almacenamiento y versionado.

Esta posibilidad de manejar los jobs como código es algo que está ahora más presente en Jenkins 2, pero la realidad es que es una funcionalidad que ya estaba disponible para las versiones anteriores de Jenkins mediante el uso de plugins y algunas otras herramientas.

En particular yo venia utilizando el Jenkins Job Builder, una herramienta de la gente de Open Stack que permite definir jobs en un archivo .yml, definiendo también relaciones “de herencia” entre los jobs. El Job build es básicamente un script python que parsea los .yml y utiliza la api de Jenkins para crear los jobs correspondientes.

Otra herramienta que provee una experiencia similar es el Job DSL Plugin. Este plugin provee la posibilidad de definir Job utilizando un DSL Groovy para la definición de Jobs. La forma de uso es: poner los scripts de definición de jobs en un repo y luego crear un job en Jenkins (típicamente llamado Seed) que monitorea el repo de scripts y que cuando detecta cambios ejecuta los scripts los cuales generan los jobs que hayamos definido.

Otras herramientas similares pero que no he probado lo suficiente son: el Build Flow Plugin y el Workflow plugin.

Delivery Pipeline con Jenkins 2

Si bien vengo trabajando con Jenkins2 desde que se publicó el release candidate, no había echado mano a la nueva funcionalidad nativa de pipelines. Sinceramente la miré por arriba apenas instalé Jenkins2, no me convenció y decidí seguir con la combinación de plugins que venia usando con Jenkins 1.6.

El lunes pasado me actualicé a Jenkins 2.8 y decidí investigar más en profundidad la funcionalidad de pipelines nativos.  Finalmente esta mañana logré completar una primera versión de mi pipeline utilizando el nuevo soporte nativo. Al hacerlo descubrí un montón de cosas interesantes que pueden llegar a disminuir considerablemente el costo de control de configuración de Jenkins (principalmente las cuestiones versionado, actualización y backups de jobs)

jenkins2-pipeline

 

Jenkins 2 ha llegado

Así es, Jenkins 2 finalmente está aquí. Según se cuenta en el sitio oficial los puntos destacados de esta nueva versión mayor (major release) son:

  • Soporte nativo para delivery pipelines
  • Mejoras de usabilidad
  • Completa compatibilidad con versiones anteriores

Tuve la oportunidad de verificarlos cuando pasé uno de mis proyectos a la versión pre-release que Jenkins publicó hace un tiempo. Adicionalmente a esto noté:

  • “Independencia” de Maven, lo pongo entre comillas porque no estoy seguro que el término apropiado sea independencia. Lo que noté es que en la versión anterior, al crear un nuevo job existía la opción “proyecto Maven”, cosa que ya no existe. Creo que inicialmente esto tenía sentido pues Jenkins había surgido en el mundo Java, pero en los últimos años creo que ha transcendido ampliamente el mundo Java y se ha convertido en la herramienta de-facto para integración continua.
  • Integración con Gradle para la definición de los pipelines, los cual tiene mucho sentido ya que Gradle es una herramienta que se posiciona como herramienta de build genérica capaz de buildear proyectos en distintos lenguajes.
  • Se removió el soporte nativo para repositorios CVS, quedándo nativamente soporte solo para Git y Subversion.

Más allá de estos puntos, un detalle que me llamó positivamente la atención fue que como parte del proceso de instalación, se ofrece instalar un conjunto de plugins que son los más comunmente utilizados por la comunidad.

A partir de esta nueva versión de Jenkins y de algunas charlas que he tenido con mi equipo actual de proyecto he decido empezar a trabajar en la preparación de un curso de Jenkins para dictar en Julio o Agosto.