martes, 3 de febrero de 2015

Por qué deberías ir a FOSDEM

Todos los meses asisto a varios grupos de usuarios en Madrid, siempre que puedo al Madrid.rb, PostgreSQL y DevOps y a otros esporádicamente, como AngularJS, Node.js o programación funcional.

Además, todos los años intento ir a varias conferencias, las últimas en las que he estado fueron Codemotion y PGconf.

FOSDEM es ir un paso más allá, para los que no lo conoceis es la conferencia de software libre más grande de Europa. Se hace en Bruselas a principios de Febrero con entrada libre y más de 5.000 asistentes.

Lo primero que sorprende es la agenda, con más de 20 salas de conferencias simultáneas, tratando todo tipo de temáticas y tecnologías.

Este año he decidido ir a charlas diferentes, así que no he aparecido por las salas donde iría habitualmente, como PostgreSQL, Configuration Management o IaaS y en el track de Ruby solo fuí a una charla sobre MRI

Aun así me tuve que pasar los dos días continuamente eligiendo que quería ver, intentando cuadrar una agenda donde siempre tenía dos o más charlas simultaneas. He visto varias charlas de sistemas embebidos (CHDKDVR), ubuntu en móviles, releases de Mozilla, testing, sphinx, grafos, unas cuantas lighting talks, ...

Por poner un par de ejemplos, te puedes encontrar charlas tan increibles como la de un grupo que como regalo de jubilación para un amigo han diseñado un reloj con GPS (hardware, software y la parte mecánica) usando sólo herramientas libres o una fantastica disertación sobre los relojes de las CPU y el tiempo en general

Y cuando publiquen los vídeos, quiero ver algunas de las que no puede entrar, como lenguajes (Ada, Java, Go), rendimiento, GNU Radiodistribuciones o Mozilla.

En un evento como FOSDEM te das cuentas de la infinidad de ramas que tiene el software libre y de todo lo que nos queda por aprender...

Nos vemos el año que viene en Bruselas!

martes, 18 de noviembre de 2014

Swap en servidores de integración

En los servidores de integración tengo el mínimo de RAM necesaria para que funcionen ya que no es importante el tiempo de respuesta ni que estén continuamente levantados.

Ahora mismo es bastante normal que me falle al desplegar una nueva versión si tiene que compilar alguna libreria, y tengo que parar todos los servicios para que tenga memoria suficiente.

Tambien me llegan de vez en cuando mails de Logcheck avisando de que se ha quedado la máquina sin memoria:

System Events
=-=-=-=-=-=-=
Nov  8 08:00:16 staging kernel: [338269.889408] ruby invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Nov  8 08:00:16 staging kernel: [338269.889414] ruby cpuset=/ mems_allowed=0$ sudo apt-get install ntp

Hasta ahora he aceptado estos problemas sin darles mayor importancia ya que solo ocurren en integración. Esta mañana hablando con mi amigo David me ha comentado que estaba instalando un servidor y que le había añadido swap siguiendo las indicaciones de un artículo de la magnífica documentación de Digital Ocean.

Es una solución evidente que no se me había ocurrido hasta ahora. En producción nunca configuro swap por temas de rendimiento, pero en integración no hay ningún problema en añadirla y me soluciona los problemas comentados anteriormente.

Así que he creado una receta de ansible para añadir swap a un servidor basada en ese artículo.

# Based on https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04
- name: Create swap file
  command: fallocate -l 1G /swapfile creates=/swapfile

- name: Set swap file permissions
  file: dest=/swapfile owner=root group=root mode=600

- name: Check if swap already exists
  shell: "swapon -s | grep '/swapfile'"
  register: swapfile
  ignore_errors: True

- name: Set up the swap space
  command: mkswap /swapfile
  when: swapfile|failed

- name: Enable swap
  command: swapon /swapfile
  when: swapfile|failed

- name: Make the swap file permanent
  mount: name=none src=/swapfile fstype=swap opts=sw passno=0 dump=0 state=present

- name: Set swappiness
  sysctl: name=vm.swappiness value=10 state=present

- name: Set vfs_cache_pressure
  sysctl: name=vm.vfs_cache_pressure value=50 state=present

El playbook se podría hacer un poco más genérico con el tamaño y el nombre de la swap en ficheros de configuración, pero para mi caso no es necesario.

Por último, como en los comandos mkswap y swapon no hay ninguna opción para que no execute si ya existe, he añadido una condición chequeando previamente si ya está creada la swap en la máquina.



viernes, 19 de septiembre de 2014

Request Queuing en New Relic

Una de las herramientas que usamos en teowaki es New Relic para monitorizar el rendimiento de la API. Nos permite saber que páginas son las más lentas para optimizarlas y que areas de la aplicación necesitan mejoras.

Ayer por la noche nos empezaron a llegar alertas por mail de problemas con el Apdex, que mide el rendimiento de la aplicación




No había ningún motivo aparente, ya que no habíamos hecho ningún cambio significativo en los servidores ni había picos significativo de tráfico. Tampoco había carga en las máquinas y todos los servicios estaban levantados correctamente (redis, memcache, unicorn, nginx).

El problema era con el Request Queuing, que había subido desde prácticamente cero hasta unos 100ms, donde se había quedado estable. Este parámetro mide el tiempo desde que llega la petición al servidor web (en nuestro caso nginx) hasta que es servida por el servidor de aplicaciones (en nuestro caso unicorn).

Si tiene un valor alto quiere decir que el servidor de aplicaciones no es capaz de servir todas las peticiones que le llegan y se quedan encoladas en el servidor web y la solución habitual es optimizar la aplicación para que sirva las peticiones más rápido o añadir nuevos servidores de aplicaciones para distribuir la carga.

Para que aparezca esta métrica en las gráficas de New Relic, se debe añadir la cabecera X-Request-Start tal y como explican en la documentación.

Como la primera opción de reiniciar nginx y unicorn por si tenían algún problema no funcionó, el siguiente paso fue leer con detalle la documentación. Si el servidor web y el servidor de aplicaciones están en diferentes servidores físicos, hay que tener cuidado con el retraso entre relojes de los servidores, lo que llaman Clock Skew, que se soluciona instalando NTP.

NTP es un protocolo que permite sincronizar el reloj de nuestros servidores con bastante precisión a partir de una red de servidores distribuida y la instalación es tan simple como añadir un paquete
$ sudo apt-get install ntp
En este tutorial de Digital Ocean hay más detalles de configuración, pero en mi caso con la configuración por defecto ha sido suficiente. Y unos minutos despues de instalarlo los tiempos de respuesta han vuelto a su valor habitual


No se el motivo por el que se ha desincronizado de los servidores, pero bueno, al menos ya está solucionado :)



















viernes, 5 de septiembre de 2014

Eutanasia. El derecho a decidir

Normalmente en este blog siempre escribo sobre temas técnicos, pero a veces, pasan cosas en la vida que te hacen reflexionar, como hace unos años cuando escribí Sobre la (in)competencia médica.

El viernes pasado por la tarde, despues de un par de días con dolor de estómago y algo de fiebre, me subió la fiebre a casi 39, así que nos fuimos al centro médico, que nos redirigió a urgencias. Despues de unas horas y algunas pruebas, me diagnosticaron una apendicitis aguda y a la mañana siguiente me operaron de urgencias. No fue la mejor forma de celebrar que ese mismo día nos habían aprobado la beta de datawaki en heroku y que empezaba las vacaciones, pero las cosas vienen como vienen.

La primera reflexión es la suerte que tengo de vivir en un pais desarrollado, si esto mismo me hubiera pasado en un país subdesarrollado (o hace 100 años), la evolución más probable había sido que se me habría roto el apéndice, y ahora mismo ya estaría muerto o retorciéndome de dolor con una peritonitis sin posible cura.

En el post que he comentado antes, hablaba sobre lo despistada que sigue estando la medicina tradicional en temas musculares y óseos. En cambio en este caso no tengo ninguna queja, me parece que el trato recibido y la profesionalidad de todos los implicados en el hospital Ramón y Cajal de Madrid ha sido excelente.

Una vez operado, la planta de cirugía estaba completa, así que los días que he estado en el hospital los he pasado en otra planta, donde la mayoría de pacientes eran mayores y dependientes.

Mi compañero de habitación era un señor de 79 años con leucemia, ingresado por problemas respiratorios. Nos dijo que no podían hacerle un transplante de médula debido a su edad, así que tendrá que convivir con la enfermedad lo que le queda de vida. El pobre hombre lo estaba pasando bastante mal, con malestar general y estaba muy delgado y cansado.

Uno de los efectos de la leucemia, es la sudoración nocturna, lo que no le permitía dormir y en cuanto se dormía, se le empapaba la cama y se despertaba con frío. Además estaba con fiebre, lo que le incrementaba aún mas el malestar.

Dentro de unos días probablemente se encontrará algo mejor, le darán el alta y volverá a estar unas semanas en casa, hasta que de nuevo le ataque otra enfermedad, ya que por las defensas bajas de la leucemia está enfermo bastante a menudo, y probablemente tendrán que volver a ingresarlo.

Hablando con él nos estuvo contando un poco su vida. Por lo que nos contó ha tenido una vida muy feliz, con un trabajo de responsabilidad del que estaba bastante orgulloso, felizmente casado, y con cuatro hijos ya mayores todos con la vida resuelta.

Al pobre hombre se le veía agotado, sin ganas de vivir, además, nos contó que su mujer estaba con Alzheimer bastante avanzado y hablaba con muchísima pena de ella. Decía que la echaba mucho en falta.

Y de aquí el título del post. Me parece muy triste que una persona con una enfermedad sin cura, a la que solo le esperan algunas temporadas de encontrarse más o menos bien, junto con otras en las que realmente lo pasa mal y sin ilusion por vivir no tenga el derecho de morir dignamente.

Está claro que muchísima gente prefiere seguir viviendo hasta la muerte natural y que la mayoría no optaría por esa opción, pero espero que algún día tengamos la opción de poder decidir y no estar sufriendo cuando ya crees que has hecho todo lo que tenías que hacer en este mundo.

Si algún día estoy en ese estado, espero que al menos me den la opción, y si aquí no puedo y es lo que quiero, que me trasladen a donde si se pueda


Por último, si teneis dolor agudo estomacal con fiebre alta, rápido a urgencias, que es una combinación que puede ser muy grave....
















miércoles, 20 de agosto de 2014

Capistrano y Monit

Últimamente me ha pasado un par de veces que al hacer una subida a producción, Capistrano y Monit no se llevan muy bien.

El problema es que en el deploy se reinician algunos servicios, como Sidekiq, y si coincide con el chequeo de Monit, se lanza otro reinicio, con el resultado de tener 2 Sidekiq arrancados en producción.

Tambien puede pasar que quieras parar algún servicio manualmente, por ejemplo Unicorn desde una tarea de Capistrano y Monit lo levante automáticamente.

Afortunadamente, la solución es simple, consiste en añadir unas tareas en Capistrano y dar permisos al usuario de la aplicación para ejecutar Monit.

Para ejecutar los comandos de Monit, se necesitan permisos de sudo, pero por seguridad, no queremos dar acceso sudo sin más. Tampoco interesa dar acceso a toda la funcionalidad de Monit, ya que se podría parar cualquier servicio monitorizado con Monit externo a la aplicación.

Así que solo daremos permiso para ver el estado de la monitorización (monit summary) y parar o iniciar la monitorización (monit monitor y monit unmonitor)

La forma de conseguirlo es tan simple como añadir un nuevo fichero /etc/sudoers.d/monit con esos permisos
my_user ALL = NOPASSWD: /usr/bin/monit summary, /usr/bin/monit unmonitor *, /usr/bin/monit monitor *
No le pedimos la contraseña al usuario para ejecutar estos comandos, ya que el usuario no tiene contraseña asignada (solo le permitimos acceder por medio de clave pública).

Y ese mismo fichero creado desde ansible

- name: Allow execute monit commands to users
  action: 'lineinfile dest=/etc/sudoers.d/monit state=present create=yes regexp="{{item}}" line="{{item}} ALL = NOPASSWD: /usr/bin/monit summary, /usr/bin/monit unmonitor *, /usr/bin/monit monitor *" validate="visudo -cf %s"'
  with_items:
    - my_user
Una vez que tenemos permisos, creamos un módulo de capistrano con las diferentes tareas a ejecutar en lib/capistrano/tasks


namespace :monit do
  desc 'Monit summary'
  task :summary do
    on roles :app do
      puts capture :sudo, :monit, :summary
    end
  end

  desc 'Monit unmonitor'
  task :unmonitor do
    on roles :app do
      puts capture :sudo, :monit, :unmonitor, :sidekiq
    end
  end

  desc 'Monit monitor'
  task :monitor do
    on roles :app do
      puts capture :sudo, :monit, :monitor, :sidekiq
    end
  end
end

Y invocamos esas tareas al empezar y al acabar el deploy

after 'deploy:starting',  'monit:unmonitor'
after 'deploy:finished',  'monit:monitor'
Además, la tarea summary permite al usuario monitorizar el estado del servidor desde línea de comandos
$ cap production monit summary
...
System 'teowaki.com'                Running
Process 'sidekiq'                   Running
Process 'sshd'                      Running
Filesystem 'rootfs'                 Accessible
...
Por último, comentar que la gema capistrano-sidekiq incluye algunas tareas similares, pero no me cuadraba su uso en mi caso, ya que me obliga a cambiar el nombre del servicio monitorizado.