#SysAdmin – Porque deje de usar #Apache y me pase a #Nginx

Lo que leerán es más un relato de por qué dejé de usar Apache como mis server preferido de HTTP para pasar a usar Nginx.

Empecé como desarrollador font-end, como la mayoría empecé usando PHP y WordPress o si se trataba de un proyecto pequeño usaba simplemente un par de archivos HTML. Esta fue mi etapa como desarrollador front-end, poco a poco mis expectativas como persona y como desarrollador fueron creciendo, entonces empecé a pensar no solo en pequeños proyectos sino también en proyectos más grandes para los cuales WordPress ya no era una plataforma viable de trabajo y desarrollo (además que realmente nunca me llamaron mucho la atención los frameworks de PHP), una amistad me pidio que le ayudara a hacer un proyecto un poco mas dificil, el cual obligado tuve que buscar otras personas que me ayudases, ahí el que desarrollaba fue el que me dijo de hacerlo en Django, el framework más conocido escrito en Python.

Fui explorando las bondades y debilidades de Django así como las de Python y al analizarlas inmediatamente en mi mente la frase que más resonaba fue “posibilidades ilimitadas”, empecé buscando manuales del mismo a la hora del despliege pues ese era mi principal trabajo, tambien empese creando pequeños proyectos siguiendo mi natural proceso empírico de aprendizaje error/solución hasta que empecé a entender el framework.

Si bien Apache no es un servidor en el cual fácilmente puedes montar tu proyecto de Django pues hay que realizar algunas configuraciones adicionales, administrar tus entornos virtuales ordenadamente, a mediano plazo se volvió un proceso sencillo y rápido de hacer en Apache y nunca sentí la necesidad de migrar pues los proyectos que llevaba a cabo realmente no me solicitaban ser exigentes o exquisito con respecto al servidor que debía usar hasta que llegó el último proyecto llamado “Unicatel”.

Quienes conocen Django saben que un proyecto se puede dividir en múltiples aplicaciones que pueden trabajar de manera interconectada o de manera independiente de acuerdo a las necesidades que uno tiene.

Empecé buscando paquetes con los cuales uno puede hacer que Django pueda volverse amigo de los websockets y di a parar con Django-websockets-Redis, el proceso de desarrollo e implementación realmente fue sencillo, no hubo mucha dificultad del lado del backend, en el ámbito frontend de igual manera, el problema específicamente fue en el servidor de producción.

El proceso es el siguiente:

* El usuario ingresa al proyecto y se activa el websocket, a partir de éste momento se dejan de usar el router de Django para empezar a usar AngularJS quién negociará con el API administrado por Django Rest Framework a través de los métodos GET, POST, PUT, DELETE y OPTIONS que éste provee.
*Cada proyecto cuenta con tareas, notas, servicios, etc, y la información de cada uno de éstos debe estar actualizada en todo momento.
*Cada vez que un usuario negocia a través de AngularJS con el API del sistema ya sea por el método POST, PUT o DELETE automáticamente el websocket envía a los clientes que se encuentren dentro del mismo proyecto la información detallada de los cambios realizados.

Realicé múltiple pruebas, revisé muchísimos manuales, tutoriales, tips que encontraba en Stackoverflow pero ninguno de ellos consiguió el objetivo y me topé con las siguientes situaciones:

*Corría el sitio y a través de uwsgi corría el websocket pero no se comunicaba el uno con el otro además que la conexión del socket era inestable pues se conectaba y desconectaba indefinidamente.
*Corría a través de uwsgi el sitio y el websocket pero únicamente podía tener un sitio en todo el servidor usando éste método.
*Corría a través de uwsgi el sitio y el websocket en un puerto distinto al 80 y a través del módulo mod_uwsgi de Apache mostraba el sitio pero los archivos estáticos recodificaban y según leía no es un método viable para puesta en producción.

Jugando con Apache al sí se puede/no se puede invertí en 2 días quizás más de 24 horas intentando forzar a Apache a que juegue de mi lado, jugando con Nginx para que juegue de mi lado, tomó 15 minutos, sí, 14 minutos, con 0 experiencia con Nginx de mi lado. Solo me tomó seguir dos manuales, uno de la documentación de Uwsgi + Nginx + Django, y la documentación de Django-websockets-Redis para Nginx, si entre ambos manuales existen algunos pequeños conflictos nada que no se haya podido solucionar con algo de observación.

¿Es Nginx mejor que Apache? Es muy pronto para asegurar una respuesta pero lo que si es actualmente es un gran aliado para todos aquellos que buscan realizar proyectos con Django y Websockets. Éste es un post que comparto a pocas horas de haber salido de éste lío.

Bueno les dejo esta comporativa de digitalocean que habla por si sola
https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations

One Reply to “#SysAdmin – Porque deje de usar #Apache y me pase a #Nginx”

  1. Nginx barre al Apache fuera del agua en cualquier escenario, en un caso hipotético que tuvieran el mismo performance (que no lo tienen ni de lejos) igual me quedaría con nginx solo por la sintaxis de la config.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*