Utiliser PostgreSQL 10 dans un environnement de développement

Le serveur de bases de données PostgreSQL est installé. Cette installation a été reconfigurée pour créer un cluster personnalisé pour l’utilisateur – développeur authentifié sur la machine de bureau. Ces sujets ont été abordés dans des articles précédents. Dans cet article on verra les aspects les plus importants de l’utilisation de ce serveur pour le développement d’applications logicielles qui l’utilisent.

Cet article fait partie d’une série qui concerne le serveur de bases de données PostgreSQL et son utilisation dans un environnement de développement:

  1. Installation de base de PostgreSQL
  2. Utiliser Postgres pgAdmin 3 pour administrer PostgreSQL
  3. Installer PostgreSQL 10
  4. Reconfigurer l’installation par défaut de PostgreSQL 10
  5. Cet article: Utiliser PostgreSQL 10 dans un environnement de développement
  6. Administrer PostgreSQL avec psql
  7. Postgres pgAdmin 4 : installation et configuration
  8. Postgres pgAdmin 4: Utilisation courante

 Créer un utilisateur de base de données standard

Il est fortement conseillé, même dans un environnement de test/développement, de ne pas utiliser le super administrateur pour une utilisation courante. Pour cela la première chose à faire après l’installation du serveur est de créer un utilisateur standard.

Se connecter au serveur en tant que super administrateur:

psql -d postgres

Une fois connecté, exécuter:

create user utappli with login encrypted password 'mputappli';

Ensuite vérifier la création effective de cet utilisateur:

select * from pg_roles where rolname='utappli';

Enfin quitter psql

\q

Pour tester la connexion de l’utilisateur utappli, exécuter:

psql -h localhost -d postgres -U utappli

Fournir le mot de passe paramétré: mputappli, quand il sera réclamé. 

Cet utilisateur et son mot de passe peuvent être utilisés par l’application en développement pour se connecter au serveur.

Créer une base de données

Pour stocker les données de l’application en développement, il y a un besoin de créer une base de données. Pour cela se connecter en tant que super administrateur et exécuter la requête de création d’une base de données dont le propriétaire est utappli:

psql -d postgres
create database bdappli owner utappli;
\q

Créer les tables de données

L’utilisateur utappli étant le propriétaire de la base de données bdappli, il a tous les droits sur cet objet. Par conséquent, on n’a plus besoin de se connecter en tant que super administrateur. Pour créer une table dans la base de donnée qui vient d’être créée, il faut se connecter à cette base de données en tant que utappli et exécuter les requêtes:

psql -h localhost -U utappli -d bdappli
create schema commerce;
create table commerce.produits (id serial, code varchar(12), nom varchar(100));
select * from commerce.produits;

La dernière requête SQL exécutée permet de vérifier la création effective de la table. Au cours du développement cette requête permettra de vérifier le contenu géré par le code de l’application. Bien entendu d’autres tables ou schémas peuvent être créés de la même manière.

Se connecter au serveur à partir d’une autre machine

Par défaut, la configuration du serveur ne permet que des connexions à partir de la même machine. Cela peut convenir pour un utilisateur-développeur qui utilise seul son serveur. Si une autre personne, qui utilise donc une autre machine, souhaite utiliser les données de ce serveur elle ne pourra pas. Ce comportement peut être changé par la modification de deux fichiers de configuration.

Editer pg_hba.conf:

vi /etc/postgresql/10/pgtest/pg_hba.conf

Ajouter la ligne suivante:

host    all     all    0.0.0.0/0     md5

Editer postgresql.conf:

vi /etc/postgresql/10/pgtest/postresql.conf

Repérer la ligne:

#listen_addresses = 'localhost'

Modifier cette ligne, en (enlever le # et remplacer localhost par *):

listen_addresses = '*'

Pour tenir compte de ces modifications, redémarrer le serveur:

pg_ctlcluster 10 pgtest restart

Pour se connecter, la personne distante, doit utiliser la même commande que pour la connexion locale sauf pour le paramètre -h (host):

psql -h xxx.xxx.xxx.xxx -U utappli -d bdappli

xxx.xxx.xxx.xxx est l’adresse IP de la machine serveur de base de données, par exemple 192.168.0.1. Pour trouver cette adresse IP, exécuter sur cette machine:

sudo ifconfig

Repérer dans la réponse l’adresse qui est mentionnée par le libellé inet. Si cela vous semble compliqué, exécuter:

sudo ifconfig | sed "s/^[ ]*//g" | egrep ^inet | egrep -v "(^inet6|127.0.0.1)" | awk '{ print $2 }'

Cette commande doit afficher une seule adresse IP, utilisez la. Si elle affiche plusieurs, c’est que la machine est connectée à plusieurs réseaux (filaire et wifi par exemple). Dans ce cas toutes ces adresses peuvent être utilisées si la machine de connexion est également connectée au même réseau.

Contrôler les requêtes SQL exécutées par l’application

Il est très utile de pouvoir contrôler les requêtes SQL exécutées par le code de l’application en développement, afin de les affiner. Cette faculté de contrôle est plus nécessaire encore s’il s’agit d’une application de type JEE qui s’exécute dans un serveur d’application.

Par défaut le serveur PostgreSQL n’inscrit pas dans son fichier de log le texte de ces requêtes. Ce comportement est modifiable par le fichier postgresql.conf. Editer ce fichier et repérer la ligne qui commence par:

#log_statement = 'none'

Modifier cette ligne, en (enlever # et remplacer none par all):

log_statement = 'all'

Pour la prise en compte, recharger les fichiers de configuration par la commande:

pg_ctlcluster 10 pgtest reload

A partir de ce moment, le serveur inscrit dans son fichier de log toutes les requêtes exécutées. Pour tester ce comportement, se connecter et exécuter une requête quelconque:

psql -d postgres
select * from pg_roles;
\q

Ensuite vérifier:

cat ~/pgtest.log

La requête qui vient d’être exécutée doit apparaître à la fin de ce fichier.

 

Share

Poster un Commentaire

Soyez le premier à commenter !

avatar
  Subscribe  
Me notifier des