[pyar] Django como servicio web

[Manuel Kaufmann]

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