[pyar] Django como servicio web

Ariel Camino arielcamino en gmail.com
Lun Jun 23 14:35:59 ART 2014


El 23/06/14 14:28, Ariel Camino escribió:
> 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
> 

Otra forma de encararlo, deployas 1 instancia sola de django, creas un
settings base y un settings "de instancia", por ejemplo:

base.py -> todos los settings
misitio1.com.py -> import base.py y config de la base de datos
misitio2.com.py -> import base.py y config de otra base de datos

luego creas dos wsgi.py, uno que importa misitio1.com.py, y el otro
(wsgi2.py) que importa misitio2.com.py, y configuras
apache/gunicorn/lo_que_sea con ambas instancias

Nótese que en misitio1.com.py podes sobreescribir cualquier setting, por
ejemplo que en vez de cargar tu app con modelos free, cargue tu app con
modelos pagos.

Igual es el mismo caso que el anterior, tenes código en común, pero las
"instancias" de django son distintas.

Suerte!
--
Ariel


More information about the pyar mailing list