Integración Continua vs Continuous Delivery vs Continuous Deployment

delivery

Bueno, lo primero es lo primero: este post no es la verdad absoluta, así que si vienes en busca de iluminación, espero que esta entrada sirva como punto de partida, pero te recomendaría leer todo lo posible sobre este tema, empezando por consultar los enlaces del final del post.

Por mi parte, con esta entrada he querido resumir los conceptos principales de cada una de estas prácticas, para intentar aclarar(me) con las diferencias entre ellas.

Integración Continua

Los equipos de desarrollo de software que trabajan en un mismo proyecto, suelen encontrarse a menudo con los siguientes problemas:

  • Merge conflicts: dos programadores modifican el mismo fichero o incluso la misma línea, lo cual da lugar a conflictos que deben resolverse y que pueden llegar a ser un quebradero de cabeza.
  • Compile conflicts: si por ejemplo un programador usa el método foo() y alguien elimina ese método, ésto no dará problemas al hacer el merge, pero a nivel de compilación dará error porqué no encontrará ese método.
  • Test conflicts: un ejemplo de test conflict sería cuando tu código depende de otro que ha cambiado (y ahora funciona diferente), lo cual haría que tu código no esté funcionando como esperabas y por tanto tu código no pase los tests.

La integración continua es una práctica de desarrollo de software que pretende minimizar este tipo de conflictos, permitiendo a las desarrolladores desarrollar, en lugar de perder su tiempo solucionando conflictos. La idea básica es que los desarrolladores commiteen los cambios muy frecuentemente (al menos una vez al día) para que en caso de conflicto se puedan solucionar de forma más rápida y sencilla, pues el propio programador tendrá el código que acaba de commitear “fresco” en su cabeza, y además no tendrá que preocuparse de investigar grandes cantidades de código, pues al commitear muy frecuentemente sabe que ha cambiado poco código desde su anterior commit.

La integración contínua, pues, consiste en automatizar los tests y los builds de tu software muy frecuentemente. A no ser que seas el único desarrollador en un proyecto, no hay razón por la que no quieras usar integración continua.

Continuar leyendo «Integración Continua vs Continuous Delivery vs Continuous Deployment»

Instalación de Zabbix

zabix¿Por qué Zabbix?

Acostumbrado a Nagios, lo primero que busqué en Google para documentarme sobre Zabbix, fue la cadena «Zabbix vs Nagios» (hay un debate muy interesante en reddit). En cualquier caso, aquí hacen una buena comparación entre ambos sistemas de monitorización.

Tras unos días con Zabbix, mi primera impresión es que la configuración vía web de Zabbix quizá sea más amigable que la configuración vía archivos de Nagios, aunque sin duda (y quizá por pasar varios años con Nagios) ésta última resulta más sencilla que no la de Zabbix, que requiere de múltiples configuraciones para poder monitorizar un elemento (el ítem en sí, su triger, el action asociado, la aplicación del ítem, etc.).

Un punto a favor de Zabbix es que parece que la comunicación cliente servidor no ocasionará los problemas que alguna vez me he encontrado con Nagios, de falsos positivos debidos a timeouts en la conexión SSH entre el servidor Nagios y el host a monitorizar (Nagios requiere de plugins adicionales para monitorizar vía NRPE).

A favor de Nagios, pero, está la gran cantidad de plugins que la comunidad ha puesto a nuestra disposición en Nagios Exchange, a primera vista mucho más completos que los plugins de Zabbix.

Componentes de Zabbix

Zabbix consta de un seguido de componentes que interaccionan entre sí:

  • Zabbix agent: el agente (o cliente) de Zabbix se instala en aquellos elementos a monitorizar. El agente se encargará de recoger información del sistema y de las aplicaciones y se las hará llegar al Zabbix server. El Zabbix agent puede recoger datos:
    • de forma pasiva: el server contacta al agente pidiéndole un dato (por ejemplo el consumo de CPU en ese instante) y el agente responde al server con ese dato.
    • de forma activa: en un primer momento, el server le enviará al agente el listado de items a monitorizar. A partir de ese momento, será el agente que de forma periódica recogerá datos sobre esos ítems y se los hará llegar al server.
  • Zabbix server: el servidor de Zabbix y por tanto la pieza principal. Consta de una base de datos, una interfaz web y el propio server. Como servidor, se encarga de recoger los datos de los agentes, calcular los triggers, enviar notificaciones, etc. El servidor por tanto, es el repositorio central donde están definidas las configuraciones y donde se almacenan todos los datos y estadísticas recogidos de los agentes.
  • Proxy (opcional): se trata de un «recolector de datos» que se situa entre el servidor y los agentes. Si se tiene por ejemplo servidores repartidos en 5 datacenters, cada datacenter podría tener su propio proxy encargado de recoger los datos de los agentes de su datacenter, para posteriormente, hacerle llegar los datos al Zabbix server. Todo proxy requiere de su propia base de datos.
  • Java Gateway (opcional): permite monitorizar aplicaciones JMX (Java Management eXtensions) como WildFly/JBoss, Tomcat, Weblogic o Websphere. Zabbix Java Gateway usa la «JMX Management API» para recoger los datos de las aplicaciones JMX remotas monitorizadas.

Fuentes:
https://www.zabbix.com/documentation/2.2/manual/concepts

Continuar leyendo «Instalación de Zabbix»

Instalar JBoss AS7 en entornos Red Hat

JBoss_logoJBoss es un Servidor de Aplicaciones Java completo, de código abierto, desarrollado por Red Hat. Y sí, yo también pienso en Apache Tomcat en estos momentos, pero hay diferencias entre ellos explicadas por ejemplo aquí o aquí. Voy a copiar literalmente una respuesta de StackOverflow que explica la diferencia entre un Servlet Container como Tomcat y un Application Server como JBoss:

«A servlet-container supports only the servlet API (including JSP, JSTL).

An application server supports the whole JavaEE – EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.

It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology.» por Bozho

Ahora que quizá tenemos algo más claro qué es JBoss y por qué este post no habla sobre Tomcat, faltará ver qué diferencias hay entre la versión de la comunidad y la enterprise (más info aquí). Como es de esperar, la versión de la comunidad siempre irá por delante respecto a la empresarial en cuanto a novedades y funcionalidades, con lo cual no estará tan testeada ni será tan estable como debería ser la versión empresarial, más pensada para alojar aplicaciones críticas.

En esta entrada se instalará y pondrá en marcha la versión de la comunidad.

Continuar leyendo «Instalar JBoss AS7 en entornos Red Hat»

Migrar de Apache/PHP a Nginx/PHP en CentOS

nginx2Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:

  • CentOS release 6.6
  • Apache/2.2.15 sin módulos adicionales
  • VirtualHosts para un proyecto PHP 5.3.3

Lo que haremos con nginx es instalarlo y configurarlo de forma muy básica en un puerto diferente y posteriormente una vez esté todo bien, cambiar puertos de escucha.

ATENCIÓN: Si estás pensando en migrar de Apache a Nginx, en producción, ten en cuenta que dependiendo de tu entorno, deberás hacerlo de una u otra manera. No es lo mismo migrar un proyecto python que sirve Apache via mod_wsgi, que un proyecto PHP que ni si quiera usa mod_rewrite (como en este ejemplo). Este post, por tanto, te puede servir de punto de partida, pero no es la «guía definitiva».

Instalación de nginx

En primer lugar, deberemos crear el fichero para acceder al repositorio de nginx, pues éste no viene en los repositorios de CentOS.

[root@lab01 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Tras configurar el repo, ya podremos instalar nginx via yum:

[root@lab01 ~]# yum install nginx

Continuar leyendo «Migrar de Apache/PHP a Nginx/PHP en CentOS»

Algunos apuntes sobre Bash

bashHe querido recoger algunas notas de Bash scripting para no tener que correr a Google (o a cualquier página de StackExchange) cada vez que las dudas me asalten.

/usr/bin/env bash vs /usr/bin/bash

Leí en la siguiente página sobre las «mejores prácticas en Bash» acerca del uso de «#!/usr/bin/env bash» en lugar del habitual «#!/usr/bin/bash» o «#!/bin/bash«. La idea es usar»#!/usr/bin/env bash» pues de esta manera lo que hacemos es buscar en el PATH dónde está bash, el cual es probable se encuentre en ubicaciones distintas en servidores diferentes. Ésto evitará problemas portando scripts a otros entornos. [Más info] [2]

#!/usr/bin/env bash

Corchete simple vs Doble corchete

Básicamente, ambos sirven para evaluar expresiones. «[» es un alias para el comando «test» y tanto uno como el otro están disponibles en el estándar POSIX. «[[» sin embargo es una keyword, no un programa, y se trata una versión mejorada para evaluar expresiones, únicamente disponible en Bash, KornShell y Zsh. Si no estás preocupado por la portabilidad de tus scripts con sistemas donde no cuentes con Bash, es mejor usar siempre el doble corchete, por la funcionalidad extra que aporta (posibilidad de usar && y ||, expresiones regulares, pattern matching, etc.). [Más info] [2]

La siguiente evaluación será «true» pues b és mayor que a, 8 mayor que 4, y abcd entra dentro del patrón «a*»:

if [[ b > a && 8 -gt 4 && abcd = a* ]]; then ...

PD: Dejo un enlace a la wikipedia donde se especifican los nombres en inglés de éstos símbolos, según la zona.

Continuar leyendo «Algunos apuntes sobre Bash»

Configuración inicial de un servidor CentOS

centosHace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.

Hoy en día, ese documento, muy pensado para instalaciones CentOS 6, tanto en entornos Cloud Computing como para en máquinas propias, es algo parecido a lo que listo a continuació.

NOTA: No te tomes todos los puntos al pie de la letra, seguramente querrás valorar si lo que propongo a continuación tiene sentido en tu entorno antes de aplicarlo, y seguro que más de un punto es mejorable.

1. Actualización del SO

Tras la instalación, es una buena idea forzar un update para estar a la última de los paquetes de nuestro SO.

yum update

2. Deshabilitar selinux

Selinux es una herramienta útil, pero que no compensa, y proporciona más dolores de cabeza de los que pretende solucionar. Es por eso que proveedores como RackSpace o Hetzner proveen sistemas con Selinux deshabilitado de fábrica. Si aún así quieres trabajar con Selinux, seguramente este sea el momento de configurarlo adecuadamente. En caso contrario, símplemente deshabilitalo tal y como sigue:

vi /etc/selinux/config
SELINUX=disabled

Tras deshabilitarlo, será necesario reinciar el sistema para activar los cambio. Así pues, reinicia para evitar tener problemas con los próximos pasos.

Continuar leyendo «Configuración inicial de un servidor CentOS»

Entradas más vistas en 2014 y estadísticas

rafikiComo viene siendo habitual, llega el post resumen del año pasado, con el que pretendo mostrar de forma transparente los números de helloit.es.

2013 vs 2014

Mediante Google Analytics podemos ver como en general, la gráfica de sesiones durante 2014 (en azúl) es ligeramente superior a la de 2013 (en naranja) y mantiene una tendencia positiva desde mediados de año. ¿Se estarán haciendo bien las cosas y el contenido del blog estará siendo de ayuda? En eso confío.

estadisticas2014

Los parámetros referentes a sesiones, usuarios y número de páginas vistas son significativamente mejores comparados con 2013.

  • El número de sesiones se ha incrementado un 30,36 % (45.034 frente a 34.546)
  • Prácticamente igual con los usuarios, que ha crecido un 29,76 % (37.541 frente a 28.932)
  • Como consecuencia, el número de páginas vistas también ha sufrido un incremento de un 24,87 %
    (52.436 frente a 41.992)

Continuar leyendo «Entradas más vistas en 2014 y estadísticas»

¿Cuantas CPUs tiene mi servidor Linux? ¿Y RAM?

cpuOtro post que tenía en borradores y que he decidido rescatar. Esta vez sobre hardware, con comandos tan básicos como útiles.

¿Cuantas CPUs tiene mi servidor?

En la mayoría de distribuciones Linux, pero concretamente en CentOS, podemos saber cuantas CPUs tiene el servidor, consultando /proc.

[root@myserver]# cat /proc/cpuinfo

El comando anterior nos mostrará la información referente a nuestras CPUs, pero «a simple vista» no sabemos si lo que nos está enseñando es el número de CPUs físicas, el número de nucleos, todo mezclado, etc. Para ello, hemos de prestar atención especialmente a los siguientes campos:

  • «Pyhisical id«: id de CPU física. Nos servirá para saber el número de CPUs físicas del servidor. En el ejemplo, vemos 4 CPUs pero en realidad un único «physical id», lo cual nos indicará que tenemos una única CPU física con 4 núcleos:
[root@myserver]# grep "physical id" /proc/cpuinfo        
physical id     : 0
physical id     : 0
physical id     : 0
physical id     : 0

Continuar leyendo «¿Cuantas CPUs tiene mi servidor Linux? ¿Y RAM?»

Medidas de seguridad en WordPress

seguridadWordPress va genial, pero todo sea dicho, también puede ser un coladero si no se ponen medidas para hacerlo seguro. A continuación listo algunas de las medidas que se podrían aplicar para empezar a hacer de nuestro site, un sitio más seguro.

1. Eliminar el usuario «Admin»

Si vas a instalar un WordPress de cero, no uses «admin» como nombre de usuario. Tampoco «root» ni «administrador» ni cosas así. Si en su momento instalaste WordPress con el usuario «admin», lo mejor es que crees un nuevo usuario con permisos de Administrador (ésto puedes hacerlo fácilmente desde el panel de control de WordPress) y una vez creado, te loguees con tu nuevo usuario y elimines el usuario «admin». Tranquilo, al borrar el usuario te pedirá si quieres conservar los posts escritos por «admin» y a qué otro usuario atribuírselos. Sólo con ésto te evitarás más de un dolor de cabeza.

Ah, también ayuda usar un password complejo, a ser posible una combinación de mayúsculas, minúsculas, números y carácteres alfanuméricos.

Continuar leyendo «Medidas de seguridad en WordPress»

Resumen de Scrum desde las trincheras

scrumEste es mi resumen de la parte de Scrum (sin incluir XP) del libro «Scrum y XP desde las trincheras» de Henrik Kniberg. No es la biblia ni debe ser una referencia, pero sí que puede ayudar a refrescar algún concepto o a empezar con Scrum.

Scrum = marco de trabajo

1- Pilas de producto

Lista priorizada de requisitos/historias en jerga del cliente.

  • Id
  • Nombre: de 2 a 10 palabras
  • Importancia: más alto = más importante. La importancia la da el product owner.
  • Estimación inicial: la unidad son puntos de historia [PH en adelante] (días/persona ideales). Ojo, no es un contrato ni un compromiso. Las estimaciones absolutas no son importantes, lo son las relativas. P.ej. Una historia con 2 PH debería durar la mitad que una con 4 PH.
  • Cómo probarlo: descripción a alto nivel de cómo testearlo (descripciones simples).
  • Notas: otra info breve.

El product owner se encarga de los objetivos del negocio y no interviene en decisiones técnicas.

Debe existir la pila de producto, con las importancias, antes de empezar el sprint.

Continuar leyendo «Resumen de Scrum desde las trincheras»