Jose Armesto's Blog

Introducing Wimpy

Sat, 20 May 2017 21:00:31 +0000

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!

Wimpy is an open source Platform as a Service that you run from your terminal to deploy your applications to AWS, following cloud best practices.

Heavily inspired on the great Ansistrano, it’s built as a set of Ansible roles and it’s executed using an Ansible playbook in your application’s repository.

Wimpy’s goal is to make it easy to follow AWS best practices, embracing immutable infrastructure patterns where your servers are considered to be immutable. Whenever a new version is released, the servers get never updated but replaced by new servers containing the new released version.

Usage

Let’s see an example for a playbook, where you can configure how Wimpy will deploy your application:

- hosts: all
  connection: local
  vars:
    # Name of the application, used to name resources in AWS
    wimpy_application_name: "awesome-application"
    # Where your application is listening for HTTP requests
    wimpy_application_port: "80"
    # It will create a new DNS for awesome-application.armesto.net
    wimpy_aws_hosted_zone_name: "armesto.net"
  roles:
    - role: wimpy.environment
    - role: wimpy.build
    - role: wimpy.deploy

Now you can just run the playbook using Ansible, or, if you don’t have Ansible installed, you can just use our Docker image that contains Ansible and all Wimpy roles:

$ docker run -v /var/run/docker.sock:/var/run/docker.sock \
    -v "$PWD:/app" fiunchinho/wimpy /app/deploy.yml \
    --extra-vars "wimpy_release_version=`git rev-parse HEAD` \
                  wimpy_deployment_environment=production"

In this case, there are two variables that we want to pass on every deploy we make: the version being deployed and in which environment we want to deploy it. In this case, the version being deployed is the SHA1 commit hash from Git, but you can choose any arbitrary tag for your version, like “v1.4.2” or whatever.

Once executed, you can browse to http://awesome-application.armesto.net to see your application, and you will have a bunch of resources in your AWS account.

What happened

As I said earlier, Wimpy has been build with modularity in mind, so it’s not an all-or-nothing kind of tool. You can choose which roles to execute. Let’s see what these roles do.

wimpy.environment

First of all, this role will enable CloudTrail for your account, an audit log so you can track who-did-what-when in your account. It also registers a master key in KMS for applications to encrypt and decrypt secrets.

Your AWS account must be prepared before you can deploy your applications. By executing this role, your accout gets two different isolated environments called staging and production. Each environment gets its own Virtual Private Cloud, meaning that applications in one environment can’t connect to applications in a different environment. Total isolation between environments right from the start.

The same applies for S3. Wimpy creates a single bucket for all your applications, but each application will only be able to access the application folder in the environment where is running. For example, if your S3 bucket is called storage, the application called cats-api will have access to the storage/production/cats-api/ folder when deployed in production, but it will have access only to storage/staging/cats-api/ when deployed in the staging environment.

Last but not least, this role creates the needed security groups to allow traffic to your applications:

From the internet to the Load Balancer specified port.
From the Load Balancer to your application exposed port.
From the application to the databases.

By default, any other access it not allowed, so for example, databases can’t be accesed from the internet.

wimpy.build

Docker is not only great for running applications but for packaging as well. By using Docker for packaging, Wimpy is language agnostic and can deploy any application written in any language.

By default, this role will use an Elastic Container Registry on AWS to store your applications images, but you can choose any Docker Registry that you like.

On every deployment, it will package your application as a Docker image that can be run anywhere. Not only is available for the deployments in production, but different teams within your organization can start sharing their applications to make development easier.

wimpy.deploy

This is probably the most interesting part! This role will deploy your application as an Auto Scaling Group with Scaling Policies that will scale up and down the number of instances. Each instance will run the application’s Docker container, supervised by systemd.

If you want, it will create a new Route53 DNS register pointing to your Load Balancer, which will balance the traffic between all the instances in your Auto Scaling Group.

The end result would be something like this:

The role offers two different deployment strategies.

Rolling Update

Using this deployment strategy, we rely on the built-in Rolling Update mechanism for Auto Scaling Groups, where each instance of the Auto Scaling Group is replaced by a new instance that contains the version being deployed.

If something fails while replacing old instances with new ones, AWS will handle the rollback for us.

Blue / Green (Red / Black) deployment

In this strategy, we create a new CloudFormation for every deploy. This means that every deploy will generate a new Auto Scaling Group (which instances contain the version being deployed), a new Load Balancer and a new DNS register. Since now we have two different registers for the same domain name (one for each version deployed), Wimpy uses Route53 weighted registers to control how much traffic goes to every version.

You can tune how much traffic goes to new versions, so you can use this feature for canary releases. This is great for testing in production with real traffic.

Example

I’ve two examples that show Wimpy in action

Fork of the Symfony demo project, but adding Wimpy to deploy the application from Travis.
Fork of the Spring pet-clinic demo project, also just adding Wimpy to be executed on every merge to master.

Summary

Wimpy tries to help you automate your deployments and infrastructure best practices in the AWS, making sure that different teams within your organization all deploy applications the same way.

It’s composed by different roles that you can combine, or even extend, building your own roles/tasks.

Everything is created on your own AWS account. That means that you are in full control of your resources, and if you don’t want to use Wimpy anymore, you won’t lose anything.

You can learn more about the project in the documentation page. Feel free to read through the code in the Github organization. Contributions are really welcomed!

Acknowledgements

Finally, I’d like to thank all the people that have helped me during the development of this project. This would’ve never happened without them, specially:

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

Fri, 01 May 2015 12:14:32 +0000

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.

Problemas con este enfoque

Esta manera de desplegar, que parece sencilla y perfecta, tiene algunas complicaciones. Con la que la gente más suele pelearse es con el hecho de que a pesar de haber desplegado una versión nueva en el servidor, a veces siguen viendo la versión vieja, debido a la extensión Opcache (antiguo APC) que guarda la compilación del código PHP interpretado en memoria. Por tanto, aunque la versión nueva ya está activa, PHP sigue tirando de esta caché para no tener que leer del disco y volver a compilar código PHP, así que se sirve el código de la versión vieja hasta que caduque esta caché (si es que lo tenemos configurado para que caduque), o hasta que reiniciemos el servidor dejando de dar servicio mientras dure el reinicio del servidor.

Antes de ver cómo solventarlo, vamos a ver un par de detalles interesantes.

Te presento a tu nueva amiga realpath_cache

Cada vez que utilizas una ruta del sistema de archivos, por ejemplo porque vas a hacer un require/include de ese archivo, o porque vas lees/escribir en esa ruta, el sistema tiene que resolver esa ruta: saber donde es exactamente, si es un directorio o un archivo, etc.

Para mejorar su rendimiento y minimizar lecturas de disco, PHP utiliza una caché interna donde guarda información sobre el sistema de archivos. No estoy hablando de Opcache, sino de otra caché llamada realpath_cache. Si intentas resolver la misma ruta dos veces seguidas, solo en la primera PHP le pedirá información al lentísimo sistema de archivos: la segunda se leerá directamente de la caché, mejorando mucho el rendimiento.

Esto es bueno, ¿no?

Sí, claro. El tema es que, como con todas las cachés del mundo, el problema viene a la hora de invalidar la caché y decirle que queremos utilizar contenido nuevo.

There are only two hard things in Computer Science: cache invalidation and naming things.

Cuando desplegamos código nuevo, el contenido de la ruta de nuestro Document Root cambia. Aunque en nuestro código siempre usemos la misma ruta para hacer algo, piensa por ejemplo la ruta relativa que usas para incluir el autoload, despues de cada deploy, esa ruta se resuelve a un lugar distinto en el disco, porque el enlace simbólico apunta a otro sitio. Esto evitará que veamos la versión nueva del código desplegado, hasta que esta caché no caduque o hagamos algo al respecto.

Cómo funciona Apache

A diferencia de Opcache, que se guarda en memoria compartida por todos los procesos, la realpath_cache es local para cada proceso del sistema. Este detalle es importante porque si utilizas Apache prefork para servir tu aplicación, cuando inicias Apache, este crea varios procesos hijos, tantos como le hayas configurado. Cada proceso hijo creado servirá X número de peticiones en su vida (esto también es configurable), y una vez que ha cumplido su deber, Apache lo matará y lo reemplazará con otro proceso hijo, poco a poco renovando todos los procesos que sirven páginas.

Es decir, no podemos preveer exactamente cuando los procesos dejarán de existir. Sumado a que la realpath_cache es local a cada proceso, la nueva versión que acabamos de desplegar se irá sirviendo aleatoriamente, dependiendo de qué proceso de Apache te haya asignado el servidor.

Como dijimos antes, podríamos solventarlo haciendo un reinicio de Apache despues de cada despliegue, pero dejaríamos de servir páginas el tiempo que tardase en reiniciar.

Mal, mal, mal, verdadera mal, por no deci borchenoso

Reiniciando elegantemente

Pero tranquilo, no sufras, hay solución. Apache nos ofrece una variante al reinicio, llamada graceful restart. Esta variante, en vez de matar al proceso de Apache y todos sus hijos para reiniciarlo, lo que hace es que el proceso padre revisa a los procesos hijos de forma que:

Si no están haciendo nada, los sustituye por un proceso nuevo.
Si está sirviendo una petición en este momento, cuando termine lo sustituye por un proceso nuevo.

Como dijimos que realpath_cache era local a cada proceso, cuando Apache levanta un nuevo proceso hijo la realpath_cache está vacía para ese proceso y las rutas se resolverán al código nuevo que acabamos de desplegar. Todo esto sin dejar de dar servicio, porque siempre hay procesos sirviendo páginas.

Pesao. Que yo venía aquí a solventar el problema de Opcache

Cierto. Opcache no es más que un diccionario (piensa en un array PHP), en el que cada key es la ruta del fichero compilado, y el value es el resultado de esa compilación. Cuando se va a ejecutar un fichero PHP, se ve si la ruta de ese archivo ya es una de las _keys_ en el diccionario, si ya lo está significa que ya lo hemos compilado antes, y se utiliza directamente el value. Si no, se compila y se guarda en el diccionario.

El ‘final plot twist’ de todo esto es que Opcache utiliza realpath_cache internamente para resolver la ruta de los ficheros. Por tanto, si hacemos un graceful restart después de cada despliegue, la ruta del archivo habrá cambiado, resuelve a una carpeta distinta, así que será como un fichero totalmente nuevo para Opcache y volverá a compilarlo, haciendo que sirvamos la versión nueva.

Conclusión

Lo que hemos visto hoy es tan solo uno de los posibles problemas a la hora de desplegar código. Otro problema, por ejemplo, sería el que se produce cuando iniciamos un despliegue, un visitante entra en la web, justo después se cambia el enlace simbólico y estamos sirviendo archivos estáticos como javascript o css. Es posible que algunos archivos hayan sido de la versión vieja, y otros de la versión nueva, llevando a posibles inconsistencias. Hay módulos de apache que intentan solventar este tipo de problemas.

El despliegue de código es un tema complicado y muy interesante. Últimamente está avanzando mucho con conceptos como servidores inmutables y los contenedores, pero eso ya es tema de otro post.