Le portail francophone de la géomatique

Pierre · Thu 11 January 2018 14:43

Aloha

Si vous êtes l'heureux, l'heureuse, administrateur-trice d'un SIG avec une architecture séparée en base(s) de production, base(s) de publication Pg, j'ai une question simple :
- comment procédez-vous pour publier les données (schémas, tables, droits,...) dans votre base de données de publication ?

La procédure, la technique, je suis preneur de tout élément de réflexion ou d'expérience.

D'avance, merci

Nicolas Ribot · Thu 11 January 2018 15:17

Bonjour,

Code:

pg_dump -p prod_port -h prod -n schema1 -n schema2 -n ... bd_prod | psql -h publi -p publi_port bd_publi

L'organisation en schémas permet de bien séparer les choses, de préparer avant copie vers la publication par exemple.
C'est tres simple et direct en ligne de commande, avec pg_dump et psql (ou en passant par une archive en cas de tres gros volumes ou réseau très lent)

Nicolas

Pierre · Fri 12 January 2018 09:48

Aloha

Question sans doute idiote : par schéma, on entend bien tous les objets du schéma (fonction, trigger, table, vue,...). Mais quid des droits ? Si l'on crée un nouveau rôle de connexion dans la base de prod, peut-on le publier dans la base de publ ? Comment se comporterait une table sur laquelle des droits sont donnés au rôle A, non publié dans la base de publ ?

Autre question : on souhaite huiler au maximum la procédure : i.e. quand un utilisateur expérimenté estime que le schéma de ses données en prod doit être publié, on souhaite qu'il puisse aisément commander cette publication. Comment le faites-vous ? Comment le feriez-vous ? Sans que cela n'alourdisse plus que de raison le plan de charge des administrateurs.

Merci encore pour cette piste, en tous les cas.

ChristopheV · Fri 12 January 2018 10:00

Bonjour,

Mais quid des droits ? Si l'on crée un nouveau rôle de connexion dans la base de prod, peut-on le publier dans la base de publ ? Comment se comporterait une table sur laquelle des droits sont donnés au rôle A, non publié dans la base de publ ?

Sans parler de technique c'est une question de philosophie de sécurité. Même si physiquement c'est la même personne qui produit et qui consulte ce n'est pas le même rôle (au sens de l'acteur).
Pour notre part nous sommes sur Windows en poste clients, avec un Active Directory sur le réseau, nous essayons tant que faire ce peu de n'avoir qu'une seule stratégie et nous calquons sur l'AD. Et comme nous développons nos logiciels c'est souvent le possesseur du thread en cours qui a les droits. En fait le programme en cours d’exécution est la "personne" qui a les droits.

Attention ce domaine est particulièrement complexe, après une formation d'une semaine par un spécialiste (sur la sécu windows), je suis pas sur de maîtriser tous les concepts.Ce sujet doit faire l'objet d'une réflexion globale sans considérer la technique a priori.

ChristopheV · Fri 12 January 2018 18:20

Bonjour

Je me suis peut être mal exprimé.Je pense que les rôles entre prod et publ doivent être dissociés.
Ont attribue pas de droit d'écriture (par exemple) sur une base de consultation à une personne qui a ce droit sur production, même si c'est physiquement la même personne.
prod possède sa stratégie et publ la sienne.

Et pour ce qui est de mettre de l'huile dans les rouages, l'utilisateur expérimenté produit le script SQL permettant la génération et c'est ce script qui est répliqué sur la base de pub, par un batch nocturne ou ce qu'on veut mais un process avec des droits, mais un seul process, comme cela ont cré un "sas" entre prod et pub au sacrifice de quelques heures de temps réel.

Dernière modification par ChristopheV (Fri 12 January 2018 18:28)

Pierre · Sat 13 January 2018 12:15

Aloha

Ma question était mal formulée. Ou mon exemple mal choisi. En effet, nous pensons effectivement à ne pas utiliser les même rôles en prod et en publ. Cependant, si l'on prend le cas d'une nouvelle application web à mettre en place, nous allons probablement tester la connexion, les rôles, dans une base prod/intégration avant de publier dans la base de prod.
Effectivement, l'écriture de script et leur passage en base de publ semblent être adaptés. Un peu de temps pour plus d'efficacité.

Cependant, reste ma seconde question :

on souhaite huiler au maximum la procédure : i.e. quand un utilisateur expérimenté estime que le schéma de ses données en prod doit être publié, on souhaite qu'il puisse aisément commander cette publication. Comment le faites-vous ? Comment le feriez-vous ? Sans que cela n'alourdisse plus que de raison le plan de charge des administrateurs.

Le moissonnage d'un tableur contenant les demandes de publication des "administrateurs métier" par un script pour générer les scripts de publication des schémas est-elle une solution que vous avez envisagé ? Mis en place ? Quelle techno utilisez-vous ?

Je met de côté la réflexion architecture qui est bien avancée chez nous, de même que celles des rôles de chacun. Nous sommes dans le flou sur les technos à utiliser pour répondre à notre besoin.

Cordialement

xav · Mon 15 January 2018 15:11

Bonjour,
je ne suis pas dans un cas avec 2 serveur PG mais j'ai mis en place un peu le même système (Production/Diffusion) mais entre schéma d'une même base.
Dans la plupart des cas, ce sont que les données que je met à jour en automatique (si la structure change, il faut intervenir dans les outils métiers).
Pour cela j'utilise FME pour transférer (et contrôle voir modifier) les données. Nous disposons également de GTF (de veremes) pour mettre directement ces traitements en accès aux producteurs de données.
Je travail actuellement sur la mise à jour automatique du pci-vcecteur depuis qu'il est publié en Opendata. J'utilise à peut près ce type de fonctionnement (intégration dans un schéma de maj puis transfère vers le schéma de diffusion), pour la question des droits, je lis les droits appliqués sur le schéma et les tables de diffusion sous postgres via la table INFORMATION_SCHEMA.TABLE_PRIVILEGES puis je les ré applique sur le schéma de maj (comme ça pas d'intervention manuelle dans le script en cas d'ajout de droits).
Si ça peu vous aider dans votre cas.

Bonne journée

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Thu 11 January 2018 14:43

PostgreSQL/PostGis : réplication, publication : quelle méthode ?

#2 Thu 11 January 2018 15:17

Re: PostgreSQL/PostGis : réplication, publication : quelle méthode ?

Code:

#3 Fri 12 January 2018 09:48

Re: PostgreSQL/PostGis : réplication, publication : quelle méthode ?

#4 Fri 12 January 2018 10:00

Re: PostgreSQL/PostGis : réplication, publication : quelle méthode ?

#5 Fri 12 January 2018 18:20

Re: PostgreSQL/PostGis : réplication, publication : quelle méthode ?

#6 Sat 13 January 2018 12:15

Re: PostgreSQL/PostGis : réplication, publication : quelle méthode ?

#7 Mon 15 January 2018 15:11

Re: PostgreSQL/PostGis : réplication, publication : quelle méthode ?

Pied de page des forums