HowDoWeDoDjangoTenants¶

Individuellement les projets n'ont pas à se soucier de multitenant, c'est totalement pris en charge par de la configuration.

Voir http://git.entrouvert.org/hobo.git/tree/debian/debian_config_common.py?h=master (à partir de # multitenant adaptations, ligne 206)

Exemple de fichier /usr/lib/<project>/debian_config.py appelé à la fin du settings.py du projet :

# /usr/lib/<project>/debian_config.py
# appelé en execfile() en toute fin des settings.py de <project>

PROJECT_NAME = 'foobar'

# si nécessaire:
#INSTALLED_APPS += ('mellon',)   # SAML2 authentication

execfile('/usr/lib/hobo/django_config_common.py')   # cf http://git.entrouvert.org/hobo.git/tree/debian/debian_config_common.py?h=debian

# en cas de besoin supplémentaire au niveau de la gestion des settings.py
# par tenant pour <project>. Par exemple pour Authentic:
TENANT_SETTINGS_MIDDLEWARE_LOADERS = +(
        'hobo.multitenant.settings_loaders.Authentic',
        # 'hobo.multitenant.settings_loaders.SettingsPy',
)

execfile('/etc/%s/settings.py' % PROJECT_NAME)

Utilisation¶

Création d'une base de données (avec comme propriétaire l'utilisateur faisant tourner le code de l'appli)

# su - postgres
$ createdb -O user foobar

Création d'un tenant

$ ./manage.py create_tenant foobar.example.net
[...]
$ ls /var/tmp/foobar/tenants/foobar.example.net/
media  static  templates

Appel des commandes de management

$ manage.py tenant_command createsuperuser -d foobar.example.net
Username (leave blank...)

Visite avec postgresql

$ psql foobar
foobar=> set schema 'foobar_example_net';
SET
foobar=> select username from auth_user;
 username 
----------
 fred
(1 ligne)
...

Fonctionnement¶

tenant_schema, "schémas" dans postgresql, + de notre côté des fichiers dans le filesystem, /var/lib/xxx/tenants/yyy.

Lancer des commandes¶

Commande unique:

package-manage tenant_command command -d domain ...

Commande multiple (pour les cron):

package-manage tenant_command command --all-tenants domain ...

Suppression des tenants¶

• supprimer le service dans hobo
  

  sudo -u hobo hobo-manage shell -d hobo.<domaine client>
  
  In [1]: from hobo.environment.models import Brique
  In [2]: Brique.objects.get().delete()
  Out[2]: (1, {'environment.Brique': 1})
  

• renommage du répértoire du tenant: sudo mv /var/lib/brique/tenants/brique<domaine client> /var/lib/brique/tenants/brique<domaine client>.<date>.invalid
• suppression du service SAML dans authentic

Renommage des tenants¶

Renommage d'un site wcs (note: rien à voir avec les tenants Django)¶

• déclarer le domaine et le vhost nginx
• se rendre dans le backoffice de wcs /backoffice/settings/identification/idp/sp et /backoffice/settings/sitename et modifier les urls avec le nouveau nom.
• renommer le répértoire du tenant
• mettre à jour les méta-données dans authentic à partir de la nouvelle url des métadonnées
• mettre à jour l'url de base dans le serveur hobo (dans le shell django)
• dans l'ancien vhost nginx mettre en place la redirection vers le nouveau nom.

Migrations Django¶

Il faut utiliser une commande dédiée pour gérer les migrations sur les tenants.

Revenir à la migration d'avant¶

$ passerelle-manage migrate_schemas iparapheur 0005 -v2
$ passerelle-manage migrate_schemas iparapheur 0005 -v2 --fake  # uniquement en base

Ajouter une migration¶

$ passerelle-manage makemigrations
$ git add passerelle/contrib/iparapheur/migrations/0006_iparapheur_wsdl_endpoint_location.py
$ passerelle-manage migrate_schemas