[pyar] Django como servicio web

[Lucas]

2014-06-23 16:17 GMT-03:00 Manuel Kaufmann <humitos en gmail.com>:

> Claro, con respecto a "la misma instancia" y "múltiples db por
> diferencias de Fields" es porque quiero tener un código genérico que
> todos los sitios van a usar, pero además también quiero ser flexible
> bajo ciertos límites para hacer que esos sitios sean customizable.
>
> Para eso, lo que quiero usar es django-easyconfig[1] que, mediante un
> objeto Config te permite decir qué View, Model y Form utilizar, por
> ejemplo. Entonces la idea sería algo así como "hacer una Django
> Application que se pueda instalar muchas veces en un Django Project y
> sea customizable por ese objeto Config".
>
> Lo primero que había pensado era usar Site y no me convenció porque
> quiero aislación de datos entre los sitios y lo otro era múltiples DBs
> que se seleccione automáticamente la correcta basándose en el Request
> pero eso agrega algunas complicaciones (como ese tema de hilos -que no
> tengo claro) y otros.
>
> Ahora, habiendo leído un poco lo que comentan ustedes, me parece que
> una aproximación interesante sería mezclar:
>
>  * django-easyconfig (un objeto Config por cada sitio -cada sitio
> sería una mini-django-app con View, Model y Forms específicos para
> ella)
>  * diferentes settings.py (para algunas pequeñas cosas que
> django-easyconfig no cubra) con su DB particular
>  * múltiples instancias de uwsgi con diferentes settings
>  * un server nginx con múltiples hosts apuntando a los diferentes uwsgi
>
> ¿Cómo lo ven? ¿Es más claro ahora el problema que quiero resolver?
>
> Entiendo que esto me permitiría hacer que todos los sitios utilicen el
> mismo código de la App genérica (cosa de que si hay un bug lo arreglo
> en esa y todos heredan el FIX) y además, poder hacer customizaciones
> por sitio usando el objeto Config de esa app específica.
>
> Por otro lado, ¿se podría llegar a algo similar a esto pero sin
> múltiples instancias de uwsgi? ¿cuál es el problema de tener muchas
> instancias uwsgi además del consumo de memoria?
>
> [1] https://bitbucket.org/petersanchez/django-easyconfig/
>
> 2014-06-23 14:28 GMT-03:00 Ariel Camino <arielcamino en gmail.com>:
> > El 23/06/14 14:02, Manuel Kaufmann escribió:
> >> Hola,
> >>
> >> Estoy migrando un Proyecto Django para convertirlo en una Aplicación
> >> Django con el fin de alojar muchos sitios en una sola instancia de
> >> Django (en pocas palabras). Para eso, el servidor va a hostear muchos
> >> nombres de dominios y, dependiendo de eso, se debería mostrar X o Y
> >> (datos, templates, demáses)
> >>
> >> Esto quiere decir que todos los sitios "instalados" en mi instancia de
> >> Django van a tener las mismas tablas de datos -pero no deben compartir
> >> información- e incluso, puede ser que haya algunas pequeñas
> >> modificaciones en esas tablas. Por ejemplo, un sitio puede ser pago y
> >> tener un BooleanField llamado "ya_pago" en la tabla UserProfile y los
> >> otros sitios no tener ese Field.
> >>
> >> Entonces, estuve buscando información y caí en maejar estas dos
> opciones:
> >>
> >>  1) Usar Sites Framework
> >>
> >> Un perno. Tengo que cambiar toda la implementación del sitio para
> >> filtrar por Site y agregar un Field a cada uno de mis modelos. Además,
> >> tampoco me queda la información separada ya que usaría la misma DB y
> >> los datos estarían todos mezclados...
> >>
> >> No me gustó mucho esa aproximación...
> >>
> >>  2) Usar Múltiples Databases
> >>
> >> Hasta ahora, no encontré una forma de decir: "si viene de
> >> foo.example.com, utilizar la DB 'foo' y si viene de bar.example.com
> >> utilizar la DB 'bar' " :(
> >>
> >> Lo que encontré es una aproximación a lo que quiero: usas SCHEMAS;
> >> pero casi que estoy en lo mismo que arriba: una sola DB con todos los
> >> datos mezclados pero asignados a un SCHEMA.
> >>
> >> https://github.com/bernardopires/django-tenant-schemas/
> >>
> >> Por otro lado, encontré este:
> >>
> >> https://github.com/mik3y/django-db-multitenant
> >>
> >> que implementa "muy bien" eso pero solo funciona en MySQL y yo lo
> >> necesito en PostgreSQL. Estoy viendo qué tan complicado puede ser
> >> modificarlo para que se la banque. Igualmente, si lo hago, tampoco
> >> podría medir los riesgos que estaría corriendo ya que hay un tema con
> >> los threads de Django en este approach :S
> >>
> >> ¿Sugerencias? ¿Opiniones? ¿Etcéteras?
> >>
> >> ¿Han tenido este problema? ¿Cómo lo resolvieron?
> >>
> >> Gracias. Muchas gracias, y hasta luego.
> >>
> >> === Lo que estuve leyendo ===
> >>
> >>  * http://en.wikipedia.org/wiki/Multitenancy
> >>
> >>  * https://docs.djangoproject.com/en/dev/ref/contrib/sites/
> >>  *
> https://docs.djangoproject.com/en/dev/ref/contrib/sites/#the-currentsitemanager
> >>
> >>  * https://docs.djangoproject.com/en/dev/topics/db/multi-db/
> >>
> >>  *
> http://stackoverflow.com/questions/16721051/multi-tenant-django-applications-altering-database-connection-per-request
> >>  *
> http://stackoverflow.com/questions/7970872/how-to-use-a-different-database-per-application-instance-in-django
> >>
> >>  * https://github.com/mik3y/django-db-multitenant (MySQL-only (this
> >> should be fixed eventually).)
> >>
> >>  * https://github.com/bernardopires/django-tenant-schemas/
> >>    * http://www.postgresql.org/docs/9.1/static/ddl-schemas.html
> >>
> >
> > Hola, para ver si te entendí bien, necesito entender cual es el problema.
> >
> > 1- No queres tener multiples dbs: Primero entendí esto ("en mi instancia
> > de Django van a tener las mismas tablas de datos"), pero después decís
> > que no te convence Sites, porque vas a tener los datos en las mismas
> > tablas, por lo que entiendo que entonces esto no es un problema.
> >
> > 2- No queres tener distintas instancias de django que hagan lo mismo:
> > Esto se puede encarar de varias formas, pero si tenes diferencias en el
> > código (por ejemplo un sitio puede tener un BooleanField y otro no)
> > claramente no puede ser la misma instancia de django, o al menos no
> > "toda" la misma instancia.
> >
> > Si mi interpretación anterior es correcta, creo que lo que necesitás
> > hacer son apps enchufables que puedas agregar (por ejemplo con pip) a tu
> > proyecto de django, luego si necesitás por ejemplo modificar un modelo
> > puntual, podes seguir usando todas las cosas de tu app enchufable, menos
> > x modelo que sobreescribis en el proyecto.
> >
> > Esa es la forma más sencilla que se me ocurre (así funcionan todas las
> > apps/plugins de django que están dando vueltas por ahí).
> >
> > Igual en este caso las "instancias" de django serían distintas, solo
> > compartirían partes de código en común (views, models, templates, etc).
> >
> > Saludos!
> > --
> > Ariel
> > _______________________________________________
> > pyar mailing list pyar en python.org.ar
> > http://listas.python.org.ar/listinfo/pyar
> >
> > PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
> >
> > La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
>
>
> --
> Kaufmann Manuel
> -- http://elblogdehumitos.com.ar
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>


Por lo que entiendo de esta ultima solución que planteas, me parece que ya
al tener varios uwsgi (y en concecuencia multiples instancias de tu
proyecto django) hacer un solo proyecto django con multiples settings y
multiples instancias de tu app generica, estarias complicando las cosas sin
demasiados beneficios.
Ya que podrias tener un proyecto django para cada sitio con su propia
instacia de app generica (recorda que las apps de django son packages de
python, con lo cual ya estarias compartiendo el codigo entre todos los
proyectos si instalas el package en la venv o interprete, o lo agregas al
pythonpath que van a usar los proyectos) y su propio uwsgi, y te ahorras
meter easy-config y de implementar codigo extra para que puedas tener
varias instancias de tu app con sus respectivas customizaciones.

No se si se entendio lo que planteo, pero basicamenter seria lo siguiente:
Si vas a tener uwsgi propios para cada sitio y ademas queres settings y db
para cada uno, entonces lo que queres son proyectos Django para cada sitio,
y podes compartir codigo entre los proyectos instalando el package de tu
app generica en el interprete o en la venv con la que configures los uwsgi
de los distintos sitios.

Saludos,

-- 
Lucas
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140623/68d3f5fe/attachment-0001.html>