Continuous Integrating my Kubernetes controller using Kind

Kubernetes controllers are processes that react to changes in the state of some objects saved on the Kubernetes API. They do this by watching the Kubernetes API so that they get notified whenever the state changes.

But how do we know if our Kubernetes controller is doing what’s supposed to do? We can write unit tests that test our logic in isolation to get some confidence, but it would be great if we could add some end to end tests using the real Kubernetes API.

However, deploying Kubernetes is not an easy task. And even if we managed to accomplish it, it would take a long time to deploy a Kubernetes cluster so we could test every change to our code base.

In this post, I’m going to explain how I used kind to test that my controller is working as expected, using a real Kubernetes API.

Automatically versioning your Application on Jenkins X

Having a good versioning strategy for our applications is key. Specially in Jenkins X, which follows the GitOps flow to deploy our applications, specifying which version of our application will be used on each environment.

But having to manually create tags or releases for our applications can be a tedious task. Jenkins X automatically takes care of versioning for us. It uses a tool called jx-release-version to figure out which is the next version to be released. In order to do that it checks what’s the current released version in the repository looking at the released Git tags. It can also read this version from your pom.xml file, or your Makefile.

If we use semver semantics, and versions are written in the format major.minor.patch, jx-release-version will tell you which is the next patch version.

The cool thing is that you don’t need to use Jenkins X to use jx-release-version!

Let’s go through some examples.

Jenkins X Environments

This year Jenkins X has been announced. If you haven’t heard, Jenkins X is a tool that lets you automate the whole delivery process of your software to a Kubernetes cluster. One key aspect of Jenkins X is that the deployment of applications is implemented following the GitOps flow. In this approach every environment is represented by a Git repository. In this post we’ll see how Jenkins X environments work.

Layered architecture and Kubernetes operators

If you’ve been developing applications for some time, you’ve probably developed some kind of HTTP application. This is the most solved problem there is in our industry, with lots of frameworks and tools that help you solve this problem easily. Also, there are some patterns and practices that we apply when solving this, that come from years of experience learning the pain points while developing these applications. I’m talking about things like not coupling your business rules to your framework, or using layers to separate things like data access objects from your domain model.

However, sometimes we forget that we can apply these patterns to almost any kind of software project. Lately I’ve been involved in projects that contain some Kubernetes Operators and the code in there could benefit a lot from the patterns that we already apply to our typical HTTP applications.

I didn't know you could do that with a Dockerfile!

Docker released the multi-stage builds feature in the version 17.05. This allowed developers to build smaller Docker images by using a final stage containing the minimum required for the application to work. Even though this is being used more and more over time, there are still multi-stage patterns that are not that widely used.

In this post I’ll show you how to use multi-stage builds to:

• avoid having different Dockerfiles for every environment
• copy files from remote images
• use parameters in the FROM image

Introducing Wimpy

Today I want to share with you the project I’ve been working on for the last year in my free time. For me, the project has already been a success: it’s a pet project that has allowed me to learn a lot about Amazon Web Services, Docker and Ansible. But letting that aside, I believe is a useful project that can help you deploy your software better!

Stackless Exceptions

Este es un post corto donde os enseñaré qué son y por qué son utiles las Stackless Exceptions, o excepciones que no contienen stack trace.

Codemotion 2016

Ya sé que voy un poco tarde con el post hablando sobre cómo fue la Codemotion 2016, pero tenía ganas de compartir mi experiencia en la conferencia.

Vaya por delante que es dificilísimo organizar una conferencia a nivel nacional, y que hacerlo durante varios años seguidos, tiene mucho mérito. Pero también es importante compartir aquellas cosas que son mejorables para, entre todos, conseguir eventos de mejor calidad en nuestro país. Así que sin más dilación, compartiré con vosotros mi experiencia en la Codemotion 2016, tanto desde el punto de vista de asistente, como desde el punto de vista de ponente.

Hace tiempo escribí un post sobre cómo sacarle el máximo rendimiento a tu terminal utilizando zsh, en el que introducía zsh y el framework oh-my-zsh para tener una experiencia más placentera usando el terminal.

Hoy veremos algunas funcionalidades extras que nos aporta esta herramienta y que nos puede ayudar a decidirnos a empezar a utilizarla.

Problemas desplegando código si usas Apache, symlinks y opcache

Muchas de las soluciones disponibles en el mercado para desplegar aplicaciones se basan en el uso de enlaces simbólicos (o symlinks) para activar la última versión de código en el servidor.

Simplificando mucho, podríamos decir que un flujo habitual a la hora de desplegar sería el siguiente:

• Ejecutamos comando para iniciar el proceso de despliegue de código nuevo.
• Se descarga el código del repositorio y se construye la aplicación. Esto suele significar instalar dependencias, generar ficheros, etc.
• Se mueve el resultado del paso anterior al servidor y se pone en una carpeta nueva.
• La carpeta a la que apunta el document root de nuestro servidor web es en realidad un enlace simbólico a otra carpeta que contiene código en la versión anterior. Por tanto solo nos queda cambiar ese enlace simbólico para que apunte a la nueva que acabamos de crear.

Como el cambio de enlace simbólico es practicamente instantáneo, conseguimos reducir la ventana de tiempo en la que el servidor está en un estado inconsistente, por ejemplo, porque todavía no se hayan terminado de copiar ficheros. Mientras se están subiendo la versión nueva, seguimos sirviendo la versión vieja, sin dejar de dar servicio. Y solo cuando la nueva está lista, hacemos el cambio de forma casi instantánea.