Instalar app ZendFramework en hosting compartido
noviembre 9, 2010 Publicado en Admin-tips, Configuración, InfraEstructura con 6 Comentarios
En este momento como proyecto personal me encuentro pasando una aplicación a ZendFramework, todo funciona 1A en mi maquina virtual, pero en el momento de subirlo a mi proveedor de hosting compartido se presentaron varios inconvenientes, a continuación les cuento como logre solucionarlos para instalar la app.
La estructura de mi aplicación en mi maquina local era la siguiente:
/projectname
/application
/controllers
/views
/models
/public
/ZendFramework
y tenia definido en mi virtualHost de apache el ambiente en el cual me encontraba, y el include del framework de Zend asi:
php_value include_path /home/ubuntu/ZendFramework/ZF-1.10.8/library:/home/ubuntu/projectname
SetEnv APPLICATION_ENV “development”
Claramente y como muchos de ustedes deben saber, no es posible hacer esto en un hosting compartido, no tenemos acceso al virtualHost del apache, por tal razon tuve que crear una carpeta “library” , copiar el framework de zend dentro de ella y modificar el archivo index.php dentro de public para que me tomara la carpeta library en el include asi:
set_include_path(implode(PATH_SEPARATOR, array(
realpath(APPLICATION_PATH . ‘/../library’),
realpath(APPLICATION_PATH . ‘/modules/admin/models’),
get_include_path(),
)));
Perfecto, asi ya funciona la aplicación, nuestro DocumentRoot apunta a nuestra cuenta y no a la carpeta /public como lo hariamos en una maquina local, entonces tendremos que acceder a nuestra aplicación especificando /public en la URl, lo cual no es muy elegante:
http://projectname/public
para solucionar esto, creamos un archivo .htaccess con las siguientes reglas y lo ubicaremos en el DocumentRoot :
#Definimos el ambiente de la APP para aplicar la configuracion de el application.ini
SetEnv APPLICATION_ENV production
#Habilitamos el mod_rewrite
RewriteEngine On
#Ignoramos este archivo, no aplicamos ninguna regla
RewriteRule ^\.htaccess$ – [F]
#Si el URI no tiene nada es decir si accedemos a /, hacemos un rewrite a /public/index.php
RewriteCond %{REQUEST_URI} =”"
RewriteRule ^.*$ /public/index.php [NC,L]
#Si el URI no empieza con /public, le adicionamos /public y hacemos el rewrite, de esta manera no necesitamos escribirlo
RewriteCond %{REQUEST_URI} !^/public/.*$
RewriteRule ^(.*)$ /public/$1
#Si el archivo existe fisicamente en el servidor no hacemos nada
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.*$ – [NC,L]
#Todo lo que venga /public/cualquiercosa lo redireccionamos al index.php para que el bootstrap haga su trabajo
RewriteRule ^public/.*$ /public/index.php [NC,L]
La estructura final es la siguiente:
/projectname
/application
/controllers
/views
/models
/public
/library
/ZendFramework
.htaccess
Y de esa manera queda completamente funcional nuestra aplicacion en un hosting compartido
Tags: app, application, godaddy, hosting, hosting compartido, htaccess, mod_rewrite, shared, shared hosting, web, webserver, ZendFramework
Bug Php ZendFrameWork – Memcached
septiembre 30, 2010 Publicado en Admin-tips, Escalabilidad, InfraEstructura con 39 Comentarios
Tengo varias aplicaciones que hacen uso del aplicativo memcached y las cuales se estaban comportando de manera extraña, donde al hacer una modificación de información e invalidar la llave de memcached, la información parecia no ser actualizada.
Lo primero que hice fue aislar el aplicativo para que solo utilizara un servidor de BackEnd, y que este a su vez utilizara unicamente un servidor de Memcached, para poder monitorear de manera controlada el comportamiento de la aplicación.
Una vez aislada la aplicación, ingrese mensajes de debug en el error_log del apache, donde imprimia en la primer linea la operación que estaba realizando, en la segunda linea el valor devuelto por el servidor de memcached y por ultimo el MD5 del key que se almacena en memcached, este era el resultado:
[Thu Sep 30 11:25:09 2010] [error] [client X.X.X.X] REMOVE CACHE, referer: http://myhost.com/somepath/to/my/app
[Thu Sep 30 11:25:09 2010] [error] [client X.X.X.X] 0, referer: http://myhost.com/somepath/to/my/app
[Thu Sep 30 11:25:09 2010] [error] [client X.X.X.X] e81afd654486c19cb137475a687c7f5e
Despues de ver esto se puede evidenciar que el valor devuelto por el aplicativo era cero (0) o false, lo cual indicaba que no estaba realizando la operación de borrado de la información.
Para verificar la información en el servidor de memcached, me conecte por consola y solicite el valor del key antes y despues de modificar un dato en la aplicación web, evidenciando que el dato permanecia intacto en memcached y no era actualizado, por lo tanto el efecto en la aplicación web era que no se estaba actualizando la información, aun cuando en la BD estaba de manera correcta. Para verificar por consola en memcached nos debemos conectar por telnet al puerto definido en la instalación:
[user@webserver ~]$ telnet 192.168.1.XXX 22522
Trying 192.168.1.XXX…
Connected to 192.168.1.XXX (192.168.1.XXX).
Escape character is ‘^]’.
get e81afd654486c19cb137475a687c7f5e
VALUE e81afd654486c19cb137475a687c7f5e 1 49
a:3:{i:0;s:5:”i:11;”;i:1;i:1285880685;i:2;i:300;}
END
Al ver este comportamiento investigue primero en el framework de Zend, en la libreria para trabajar con Memcache, en la funcion “remove” que era la que estaba fallando, alli pude ver que ZendFramework lo que realiza es un llamado a la función “delete” de la clase memcache de PHP.
Investigando en el sitio web de php, http://www.php.net/manual/es/memcache.delete.php, encontre que se trata de un Bug que se presenta en esta función donde recibe un segundo parametro “Opcional” especificando el tiempo en el cual se debe borrar el key, al parecer no resulto ser tan “Opcional” y para que funcione debe especificarse siempre.
Por tal motivo, tuve que editar el archivo de ZendFramework, ZendFramework-1.7.8/library/Zend/Cache/Backend/Memcached.php
ANTES
public function remove($id)
{
return $this->_memcache->delete($id);
}DESPUES
public function remove($id)
{
return $this->_memcache->delete($id, 0);
}
adicionando ese segundo paramétro en cero (0), se soluciona el inconveniente y vuelve a trabajar de manera adecuada el servidor de memcached.
NOTA: Esto sucede con ZendFramework inferior a la versión 1.10.X + pecl-memcache 3.0.4 + memcached 1.4.4
Tags: bug, memcache, php, ZendFramework
Instalación de Nginx como servidor estático
septiembre 27, 2010 Publicado en Admin-tips, Configuración, Escalabilidad, InfraEstructura con 31 Comentarios
En una entrada anterior hablamos sobre los origines y las bondades que tiene el servidor http Nginx, en esta ocasión vamos a instalarlo y a realizar una configuración basica del mismo.
Lo primero que debemos hacer es descargar la ultima versión del servidor Nginx aqui, y la ultima version de pcre(Perl Compatible Regular Expressions) aqui. Para este tutorial vamos a trabajar con las versiónes nginx-0.8.51.tar.gz y pcre-8.10.tar.gz. Adicionalmente vamos a instalar un modulo para nginx que nos permite manejar las cabeceras eTag, desarrollado por kkung, el cual se puede descargar aqui.
Instalando PCRE
Descomprimimos el paquete pcre-8.10.tar.gz e ingresamos a la carpeta generada, ejecutamos los comandos configure, make y make install
tar -zxvf pcre-8.10.tar.gz
cd pcre-8.10
./configure
make
make install
Si todo sale bien, ya tendremos instalado el paquete pcre en nuestro sistema y continuaremos instalando el servidor Nginx.
Instalando Nginx
Lo primero que debemos hacer es descomprimir el modulo de eTags para archivos estaticos y renombrar la carpeta por facilidad, simplemente con:
tar -zxvf kkung-nginx-static-etags-s20090317-3-gce0fdd4.tar.gz
mv kkung-nginx-static-etags-s20090317-3-gce0fdd4 nginx-static-etags
Descomprimimos el paquete nginx-0.8.51.tar.gz e ingresamos a la carpeta generada. Ejecutamos el comando configure incluyendo el paquete que acabamos de descomprimir, asi como la opción que nos permite tener estadisticas del servidor (server-status en apache), seguido de make y make install
tar -zxvf nginx-0.8.51.tar.gz
cd nginx-0.8.51
./configure –user=userowner –group=groupowner –with-http_stub_status_module –add-module=/instaladores/nginx/static-etags
make
make install
Nota: En caso en que al ejeuctar el comando “make” opbtengamos el siguiente error, lo unico que debemos hacer es entrar al archivo /instaladores/nginx-static-etags/ngx_http_static_etags_module.c y generar una linea vacia al final.
/instaladores/nginx-static-etags/ngx_http_static_etags_module.c:168:2: no newline at end of file
make[1]: *** [objs/addon/nginx-static-etags/ngx_http_static_etags_module.o] Error 1
make[1]: Leaving directory `/instaladores/nginx-0.8.51′
make: *** [build] Error 2
Hasta aqui ya tenemos instalado nuestro servidor nginx para HTTP el cual se encuentra en /usr/local/nginx, ahora vamos a realizar unas tareas administrativas para que sea mas sencillo configurar y trabajar con nginx.
Primero que todo vamos a configurar el sistema para que podamos acceder a la configuración del servidor nginx en /etc/nginx, para esto necesitamos crear dos links simbólicos de la siguiente manera:
ln -s /usr/local/nginx/conf/ /etc/nginx
ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx
lo segundo, es que vamos a crear un script por medio del cual podemos subir y bajar el servidor nginx como cualquier otro servicio de linux, y lo alojaremos en /etc/init.d/, aca les dejo el script para que los descarguen nginx script inicio
Por último modificaremos el archivo de configuración para colocar un sitio de ejemplo, para esto debemos modificar el archivo /etc/nginx/nginx.conf para que quede de la siguiente manera:
user userowner groupowner;
worker_processes 1;events {
worker_connections 512;
}http {
include mime.types;
default_type application/octet-stream;log_format main ‘$remote_addr – $host $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” “$http_user_agent” “$gzip_ratio” “$http_x_forwarded_for” “$upstream_status”‘;
server {
listen 80;
server_name test.local;access_log /var/log/access.log main;
# [ debug | info | notice | warn | error | crit ]
error_log /var/log/error.log debug;etags on;
etag_hash on;
etag_hash_method md5;#SECCION PRINCIPAL
location / {
root /var/www/;
index index.html index.htm;
}#####NGINGX STATUS
location /nginx_status {
stub_status on;
access_log off;
allow all;
}
error_page 404 /error.html;
}
}
Una vez creado el archivo de configuración de nuestro sitio de prueba, subimos el servicio y listo, al acceder por un navegador podremos ver nuestro sitio funcionando.
/etc/init.d/nginx start
En una próxima entrada estare hablando de configuraciones y optimizaciones especificas para este servidor.
Tags: etag, nginx, pcre, proxy, reverse proxy, web, webserver
Los 4 secretos de escalabilidad en Facebook
junio 24, 2010 Publicado en Escalabilidad, InfraEstructura con 55 Comentarios
Aditya Agarwal, Director de Ingenieía de Facebook, dio una excelente conferencia acerca del escalamiento en Facebook que cubrio su arquitectura, pero la charla realmente fue más sobre como escalar una organizacion preservando lo mejor de su cultura. La clave de la conferencia es:
You can get the code right, you can get the products right, but you need to get the culture right first. If you don’t get the culture right then your company won’t scale.
Puedes tener el codigo bien, puedes tener los productos bien, pero necesitas tener bien la cultura primero. Si no tienes bien la cultura entonces la compañia no podrá escalar
Esto nos lleva a los 4 secretos de escalabilidad en Facebook:
- Escalamiento necesita Iteración
- No sobredimensione
- Escoja la mejor herramienta, pero tenga en cuenta que traerá consigo otras consideraciones
- Ajuste la cultura. Muevase rápido – rompa paradigmas. Alto Impacto – equipos pequeños. Sea valiente – innove.
Estas son algunas consideraciones antes de hablar sobre cada uno de los cuatro secretos en Facebook:
Facebook es muy grande
400 millones de usuarios actuvos; los usuarios utilizan facebook 20 minutos al dia en promedio; 5 billones de piezas de contenido (actualizaciones de estado, comentarios, gustos, carga de fotos, carga de videos, mensajes de chat, mensajes de correo, eventos, paginas de fans, conexiones de amigos) son compartidas en facebook cada semana; 3 billones de fotos cargadas cada mes; 250 aplicaciones que tienen mas de 1 millon de usuarios al mes; 80.000 conexiones de aplicacion, 500.000 aplicaciones; 2 millones de desarrolladores; 150 millones de operaciones por segundo en memcache; miles de servidores de memcache con decenas de Terabytes en memoria.
Facebook es dificil de escalar
Cada tipo de contenido tiene su propio patrón de acceso lo cual hace dificil el escalamiento. Todos usan Facebook de una manera diferente. Cada experiencia de usuario es unica. La mayoria de sitios web escalan de manera horizontal, porque su data puede ser particionada. En Facebook los usuarios no pueden ser particionados porque pueden unirse a cualquier red, Facebook es una red global que trata de cautivar a todo el mundo, permite a cualquiera ser amigo de cualquiera, y puede representar cualquier relación entre usuarios. cada usuario nuevo puede acceder los datos de cualquier otro usuario por lo tanto no se puede particionar geograficamente o por otra tipo de criterio. En promedio, cada usuario de Facebook tiene 130 amigos.
La arquitectura tiene 4 componentes principales
- Balanceador de Carga
- Servidores Web (PHP)
- Servicios (Buscador, publicidad, memcache,etc)
- Bases de Datos
Los 4 secretos de escalabilidad en Facebook
1. Escalamiento necesita Iteración. Las soluciones por lo general funcionan al principio, pero deben ser modificadas a medida que pasa el tiempo. Lo que funciona en el primer año, podria no funcionar despues. PHP, por ejemplo, es simple usarlo al principio, pero no es una buena elección cuando se tienen miles de webservers.
Otro ejemplo son las fotos, actualmente sirven 1.2 millones de fotos por segundo. La primera versión se creo de la manera facil, sin preocuparse ucho por como escalaba, simplemente enfocandose en que funcionara bien. El cargador almacenaba el archivo en un NFS y la meta-data en MySql, funciono bien los 3 primeros meses y causo muchas noches sin poder dormir, aun lo hace. El Time to market, o tiempo para salir al mercado fue la ventaja más competitiva que se tenia, tener la funcionalidad era más importante que si esta escalaba bien o no.
La segunda fase fue la optimización, se evidencio que las imagenes pequeñas son mas accesadas por lo cual se empezaron a almacenar en cache, además empezaron a usar un CDN, el servicio NFS no fue diseñado para almacenar 80 billones de pequeños archivos, asi que toda la meta-data no se ajustaba a la memoria, por lo cual eran necesarios 2 o 3 IOs a disco, lo cual era lento.
La tercera fase es un sistema que crea un archivo que es un BLOB almacenado en el sistema de archivos. Las imagenes son almacenadas en un BLOB y se conoce el offset de la foto en el BLOB para su recuperacion, esto se traduce en 1 IO por cada foto.
2. No sobredimensione. Unicamente utilice lo necesario a medida que va escalando. Descubra donde debe iterar en una solución, optimice o construya la solución usted mismo. Ellos dedicaron mucho tiempo tratando de optimizar PHP, terminaron escribiendo HipHop, un transformador de código que convierte PHP en C++, lo cual genero una cantidad masiva de ahorro en CPU y memoria. Esto no debe ser realizado en el dia 1, pero deberia, enfoquese primero en el producto antes de escribir un lengueaje nuevo por completo.
3. Escoja la mejor herramienta, pero tenga en cuenta que traerá consigo otras consideraciones. Si usted realmente necesita usar Python adelante, pero tenga en cuenta que tendrá su costo, usualmente en instalación, monitoreo, operación. Si usted decide usar una arquitectura basada en servicios, tendrá que construir la mayoria del backend usted mismo y eso toma tiempo, con LAMP por ejemplo tiene todo esto gratis. A medida que incursiona en el alcance por servicios, tendrá que reinventar la rueda.
4. Ajuste la cultura. Muevase rapido – rompa paradigmas. Alto Impacto – equipos pequeños. Sea valiente – innove. Construya un ambiente interno que promueva la construcción correcta de las funcionalidades y despues se optimicen segun sea necesario, sin preocuparse por la innovación, sin preocuparse por romper paradigmas, pensando en grande, pensando en que será lo siguiente en construir despues de este primer paso. Usted puede tener el codigo correcto, los productos correctos, pero si la cultura no es la apropiada no podrá escalar de manera eficiente.
- Muevase rápido. Sea el primero en el mercado, esta bien si rompe paradigmas. Por ejemplo, Facebook corre en una capa web compuesta en su totalidad por HipHop, el cual fue desarrollado por 3 personas. Muy arriesgado, esto llevo a que el sitio se cayera regularmente (Sin memoria, cilcos infinitos), pero al final la recompensa es que encontraron como hacer que funcionará. La alternativa era que se realizaran pruebas durante 3 meses, lo cual retrasaba todo el desarrollo. Este es un ejemplo puntual, pero lo más importante es la cultura, que la gente crea que lo más importante es que tan rápido se pueden mover en el mercado.
- Alto Impacto. Los equipos pequeños pueden hacer grandes cosas. Buscador, fotos, chat, HipHop, fueron desarrollados por pequeños equipos. Arme los equipos con la gente adecuada, empoderelos y dejelos trabajar.
- Sea Valiente. No le tema al fracaso, esta bien intentar cosas nuevas y fallar, puede ser descabellado decir “Vamos a hacer una nueva JVM”, pero la recompensa puede ser grandiosa cuando funciona.
En Facebook no hay dueños del producto, todos son dueños del producto. Dele a la gente apropiación de lo que hacen, si solo una persona obtiene el crédito, entonces nadie contribuira para llevar el producto al siguiente nivel. Las ideas vienen internamente de los usuarios y las personas, si la responsabilidad no esta distribuida y solo un número de personas siente que son parte del producto, entonces solo ellos serán suceptibles de ser motivados. Moverse rápido no es solo un deseable, las compañias deben encontrar maneras para que la gente sienta que es una realidad.
A continuación les dejo el link donde pueden ver el video completo de la conferencia :
http://www.infoq.com/presentations/Scale-at-Facebook
Tags: arquitectura, blob, C++, cdn, escalabilidad, Facebook, hackatons, HipHop, IO, LAMP, MySql, NFS, php, Python, scale, server, web, webserver
Comandos linux para asignar propietario de archivos y carpetas
junio 23, 2010 Publicado en Admin-tips, InfraEstructura con 41 Comentarios
En Red Hat, y en linux en general, encontramos que todo esta basado en archivos, inclusive los directorios en realidad son archivos especiales donde en su estructura se lista los archivos que contiene, pero esto lo veremos en una entrada posterior sobre el sistema de archivos y los inodos. Adicional a esto, para todos los archivos tenemos un usuario propietario y un grupo propietario:
[niquepa@vm1 ~]$ ls -l /tmp/
-rw-r–r– 1 niquepa wordpress 192 Jun 23 13:40 basura
-rw-r–r– 1 root root 109 Jun 23 16:47 abc.txt
-rw-r–r– 1 root root 381 Nov 10 2005 index.html
drwx—— 2 root root 4096 Jun 23 16:38 deploy
-rw-rw-r– 1 zabbix zabbix 26976 Jun 18 17:08 zabbix_agentd.log
[niquepa@vm1 ~]$
en el anterior comando podemos observar que para el archivo “basura” el usuario propietario es “niquepa” y el grupo propietario es “wordpress”, al igual que para el directorio “deploy”. Existe una manera de cambiar estos propietarios, para efectos de seguridad principalmente, y es por medio de dos comandos “chown” y “chgrp”, aunque con “chown” es más que suficiente.
chown Asigna el usuario propietario, y el grupo propietario si asi se quiere chgrp Asigna el grupo propietario, en caso de solo querer cambiar el grupo
Sintaxis para usar chown:
chown [OPCIONES]... [USUARIO][:GRUPO] ARCHIVO...
a continuación mostramos dos ejemplos de que como se usa, y en rojo se pueden evidenciar los cambios:
[niquepa@vm1 ~]$ ls -l /tmp/
-rw-r–r– 1 niquepa wordpress 192 Jun 23 13:40 basura
-rw-r–r– 1 root root 109 Jun 23 16:47 abc.txt
-rw-r–r– 1 root root 381 Nov 10 2005 index.html
drwx—— 2 root root 4096 Jun 23 16:38 deploy
-rw-rw-r– 1 zabbix zabbix 26976 Jun 18 17:08 zabbix_agentd.log
[niquepa@vm1 ~]$ chown root basura
[niquepa@vm1 ~]$ ls -l /tmp/
-rw-r–r– 1 root wordpress 192 Jun 23 13:40 basura
-rw-r–r– 1 root root 109 Jun 23 16:47 abc.txt
-rw-r–r– 1 root root 381 Nov 10 2005 index.html
drwx—— 2 root root 4096 Jun 23 16:38 deploy
-rw-rw-r– 1 zabbix zabbix 26976 Jun 18 17:08 zabbix_agentd.log
[niquepa@vm1 ~]$ chown -R niquepa:wordpress deploy
[niquepa@vm1 ~]$ ls -l /tmp/
-rw-r–r– 1 root wordpress 192 Jun 23 13:40 basura
-rw-r–r– 1 root root 109 Jun 23 16:47 abc.txt
-rw-r–r– 1 root root 381 Nov 10 2005 index.html
drwx—— 2 niquepa wordpress 4096 Jun 23 16:38 deploy
-rw-rw-r– 1 zabbix zabbix 26976 Jun 18 17:08 zabbix_agentd.log
al escribir dentro de las opciones -R estamos diciendo que queremos cambiar de manera recursiva el propietario para todos los archivos que contenga la carpeta. dentro de las posibles opciones tenemos:
-c, --changes Reporta unicamente los cambios realizados sobre archivos o carpetas --dereference Afecta el archivo o carpeta que se referencia en un link simbolico, en lugar de modificar el link simbolico como tal, Asi se comporta por defecto -h, --no-dereference Afecta el link simbolico en lugar de su referencia -f, --silent, --quiet Ejecuta de manera silenciosa -R, --recursive Ejecuta de manera recursiva para directorios -v, --verbose Muestra mensajes en pantalla de cada archivo o carpeta procesados
Sintaxis para usar chgrp:
chgrp [OPTION]... GROUP FILE...
Por medio de este comando modificaremos unicamente el grupo propietario de los archivos o las carpetas deseadas, y tiene las mismas opciones disponibles que “chown”
Tags: archivo, carpeta, chgrp, chown, dueño, group, grupo, linux, owner, propietario, redhat, rhel, user, usuario
