martes, 12 de diciembre de 2017

Error común: "Too many open files", en Tomcat o PHP


Si Tomcat os devuelve un error HTTP 500 y en el 'catalina.out' encontráis algo de este tipo

[] org.apache.tomcat.util.net.JIoEndpoint$Acceptor run SEVERE: Socket accept failed
java.net.SocketException: Too many open files

es que tenéis un problema de ficheros abiertos; con

> ulimit -a

puedes ver tu configuración actual; repasa la variable "open files" que te da cuántos ficheros abiertos puede haber por proceso. Puedes modificarla con

> ulimit -n #

donde # es el nuevo valor; prueba con 4096 y reinicia el tomcat para que coja el cambio de esta variable de sistema

Para controlar cuántos ficheros tiene un proceso abierto, lo puedes hacer con  

> lsof -l | grep tomcat

Este tipo de fallo es aplicable a cualquier otra aplicación, no sólo a tomcat; también PHP requiere abrir muchos ficheros y puede  arrojar un error similar. Tenlo en cuenta cuando una aplicación se pare de repente después de rato funcionando bien.



Gracias!


viernes, 1 de septiembre de 2017

Compilar y configurar PHP-FPM 5.6.30 para que escuche en un puerto sobre Debian 8

Aprovecho que he tenido que compilar de nuevo PHP para poder utilizarlo con nGinx, y os dejo mi receta


> mkdir /opt/source
> mkdir -p /opt/php-5.6
> cd /opt/source # Bajo y descomprimo el código fuente en este directorio
> get http://es1.php.net/get/php-5.6.30.tar.gz
> tar -xzvf php-5.6.30.tar.gz
> apt-get install build-essential
> apt-get install libcurl4-openssl-dev pkg-config
> apt-get install libbz2-dev
> apt-get install libjpeg62 libjpeg62-dev
> apt-get install libpng12-dev
> apt-get install libfreetype6-dev
> apt-get update && apt-get install -y libc-client-dev libkrb5-dev
> mkdir /usr/lib64/
> ln -s /usr/lib/libc-client.a /usr/lib64/libc-client.a
> apt-get install make
> cd php-5.6.30
> ./configure \
--prefix=/opt/php-5.6 \
--with-zlib-dir \
--with-freetype-dir \
--enable-mbstring \
--with-libxml-dir=/usr \
--enable-soap \
--enable-calendar \
--with-curl \
--with-mcrypt \
--with-zlib \
--with-gd \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-zlib \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-pcntl \
--enable-mbregex \
--with-mhash \
--enable-zip \
--with-pcre-regex \
--with-mysql \
--with-pdo-mysql \
--with-mysqli \
--with-png-dir=/usr \
--enable-gd-native-ttf \
--with-openssl \
--with-libdir=lib64 \
--enable-ftp \
--with-imap \
--with-imap-ssl \
--with-kerberos \
--with-gettext \
--with-gd \
--with-jpeg-dir=/usr/lib/ \
--enable-fpm \
--with-fpm-user=www-data \
--with-fpm-group=www-data \
--enable-intl \
--with-xsl \
--with-pear
> make
> make install

# Configuro PHP-fpm

> cp /opt/php-5.6/etc/php-fpm.conf.default /opt/php-5.6/etc/php-fpm.conf
> cp /opt/source/php-5.6.30/php.ini-production /opt/php-5.6/lib/php.ini
> vi /opt/php-5.6/etc/php-fpm.conf
[...]
pid = run/php-fpm.pid
[...]
user = www-data
group = www-data
[...]
listen = 127.0.0.1:9001
[...]
#include=/opt/php-5.6/etc/pool.d/*.conf
[...]
[www-PHP56]
> cp /opt/source/php-5.6.30/sapi/fpm/init.d.php-fpm /etc/init.d/php5.6-fpm
> chmod 755 /etc/init.d/php5.6-fpm
> /etc/init.d/php5.6-fpm start

Solo faltaría configurar nGinx para que envíe las peticiones PHP a este puerto. También se podría configurar por socket.

sábado, 12 de agosto de 2017

Compilar PHP 5.6.29 con Apache2.2.16 sobre Debian 8

Os dejo mi receta para compilar PHP 5.6.29 para Apache2.2; no tiene pérdida!


# Preparo apache2 ya instalado para poder compilar PHP

> cd /root
> wget http://archive.debian.org/debian/pool/main/a/apache2/apache2-threaded-dev_2.2.16-6+squeeze15_i386.deb  ## Busca tu paquete según la distribución que utilices y tu versión de Apache
> apt-get install libaprutil1-dev
> dpkg -i apache2-threaded-dev_2.2.16-6+squeeze15_i386.deb
> updatedb
> locate apxs     ## Comprueba donde ha instalado el sistema las apxs, las necesitarás en el primer paso de la compilación del PHP; en mi caso será /usr/bin/apxs2, pero si el directorio es otro no pasa nada

# PHP

> mkdir /opt/source
> mkdir -p /opt/php-5.6
> cd /opt/source # Bajo y descomprimo el código fuente en este directorio.
> apt-get install build-essential
> apt-get install libfcgi-dev libfcgi0ldbl libjpeg62-dbg libmcrypt-dev libssl-dev libc-client2007e libc-client2007e-dev
> ln -s /usr/lib/libc-client.a /usr/lib64/libc-client.a
> cd php-5.6.29
> ./configure \
--with-apxs2=/usr/bin/apxs2 \ # Cambia aquí la localización de apxs
--prefix=/opt/php-5.6 \
--with-pdo-pgsql \
--with-zlib-dir \
--with-freetype-dir \
--enable-mbstring \
--with-libxml-dir=/usr \
--enable-soap \
--enable-calendar \
--with-curl \
--with-mcrypt \
--with-zlib \
--with-gd \
--with-pgsql \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-zlib \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-pcntl \
--enable-mbregex \
--with-mhash \
--enable-zip \
--with-pcre-regex \
--with-mysql \
--with-pdo-mysql \
--with-mysqli \
--with-png-dir=/usr \
--enable-gd-native-ttf \
--with-openssl \
--with-libdir=lib64 \
--enable-ftp \
--with-imap \
--with-imap-ssl \
--with-kerberos \
--with-gettext \
--with-gd \
--with-jpeg-dir=/usr/lib/ \
--with-pear
> make
> make install

# Configuro PHP
# Por último, configurar Apache2 para que trabaje con PHP5.6

> cat /etc/apache2/mods-available/php5.load
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so

jueves, 22 de junio de 2017

DevOps, A New Hope...

Hace unos meses que llevo con una serie de entradas dedicadas a Docker en especial, aunque el último (penúltimo) post introduje lo que (para mí, porque hay mucha literatura sobre el tema) son los principios de la filosofía DevOps. Según la wikipedia, este nuevo movimiento lo que busca es la automatización y monitorización de todos los estadios de la construcción del software, además de abogar por ciclos de desarrollo más cortos y más frecuencia de implementación  dando como resultado la construcción de software más confiable.

Para llegar a ese estado ideal, se marcan tres fases importantes, aunque después de la primera viene todo más o menos rodado, que serían

- Integración Continua (Continuous integration -CI- en inglés): Seguro que has escuchado este término alguna vez, pero si no lo has hecho que sepas que es el proceso por el cual el nuevo código se integra a menudo, por ejemplo cada pocas horas, siendo así posible la detección de errores lo más rápido posible, y para ello también se añaden una serie de tests y controles para localizar problemas o bugs fácilmente.

- Entrega Continua (Continuous Delivery -CD- en inglés): En esta fase la automatización es muy importante, ya que se definen más test y controles para que las subidas se puedan automatizar y sean más fiables. Estas nuevas pruebas van orientadas a mantener la calidad del software y a confirmar la integridad del código. Una vez el código ha superado todas las pruebas y mantiene la calidad deseada, se puede automatizar la subida al entorno de producción, aunque esto ya entraría en el terreno de un "continuous deployment"


Hay otras fases como la monitorización continua que yo personalmente no las considero fases propiamente dichas sino más bien parte de la carrera de fondo de un departamento de sistemas

Cada una de estas dos fases tienen software que nos ayuda en la implementa-ción de todas esta manera de trabajar, pero eso lo iremos viendo. Sólo una pincelada ya que hemos hablado de docker: al trabajar con contenedores se minimizan los fallos derivados del entorno, por lo que cualquier cambio o implementación que tengamos que hacer es mucho más fluida.



Saludos y gracias!

domingo, 26 de marzo de 2017

DevOps y Docker


No lo parece, pero la aplicación de Docker en un entorno de producción requiere de un cambio importante de mentalidad.

Dicho así, suena raro, pero las ventajas de docker tienen mucho que ver con una manera de trabajar más colaborativa, que se identifica con una filosofía DevOps más que con una visión más clásica de la infraesctructura. Al menos es mi visión, y me voy a explicar.


Yo vengo del mundo de sistemas y siempre he trabajado con una filosofía según la cual no podía tocar ni una línea de código; en general la idea es provisionar entornos y entregarlos al equipo de desarrollo correspondiente para que haga su magia, y a partir de ahí ponerte la gorra de policía. Con la llegada y la implantación de la filosofía DevOps, la infraestructura ha pasado a ser parte del código, y se actualiza y modifica de la misma manera. Y estos modelos requieren de herramientas que permitan que estos cambios se hagan de la manera más fluida posible, y que los equipos se fusionan, integrando miembros multidisciplinares y que sepan jugar en equipo.Están empezando a llegar nuevos aires, y esto va a cambiar mucho los modelos que hemos tenido hasta ahora.

Alguien puede decirme que esta manera de trabajar es algo puntual (aunque lo he vivido en diferentes empresas) o el resultado de una mala (o buena) gestión; yo no voy a entrar en eso, sólo quiero explicar mi experiencia y cómo lo he visto yo.


Un saludo!

martes, 7 de febrero de 2017

Pinceladas de Docker (III) - Ventajas que te puede aportar Docker

Quería haber escrito y publicado esta entrada mucho antes, pero un accidente me ha dejado fuera de circulación durante unos meses, así que perdonad si llega un poco tarde pero tenía muchas ganas de seguir con esta serie.

Según lo veo yo, estas son las ventajas que (en este mismo momento) creo que son más... eso, ventajosas de utilizar docker en diferentes entornos

  • Docker se puede ver como un pequeño "ordenador" dentro de tu equipo: un pequeño entorno virtual con lo justo para que puedas ejecutar tu código o lanzar tus scritps. Las imágenes de docker se pueden tratar como pequeñas instancias virtuales, que podrás compartir con el resto del equipo de manera que todos tengáis el mismo entorno de trabajo independientemente de la plataforma que utilizéis.
  • Esto es gracias a que Docker tiene  una "cross platform architecture", una arquitectura de plataforma cruzada que permite que la misma imagen se pueda ejecutar igualmente sobre Windows o Linux. En equipos multidisciplinares, es ideal ya que todos podrán trabajar con el mismo entorno.
  • Al ser imágenes, las subidas a producción también son más sencillas y rápida, sin tener que entrar en configuraciones y dependencias de otros módulos del sistema, lo que permite implementar más fácilmente modelos de integración contínua que tanto se buscan en este momento.
  • Las diferentes imágenes son directamente las versiones de tu producto totalmente paquetizada y con la seguridad de que va a funcionar en cualquier entorno.
  • Gracias a herramientas como DockerFile, podemos automatizar y  desplegar entornos utilizando recetas y, de la misma manera que se hace con el código, mantener un control de versiones de nuestra infrastructura.


 Seguro que me salen más ventajas, os las iré comentando


Saludos!