Pré-requis
PostgreSQL
L'ensemble des données est stocké dans une base de données, photos comprises, cela nous a ammené à utiliser PostgreSQL (et non MySQL) pour ses possibilités de streaming sur les blobs.
Sous debian :
Bloc de code |
---|
|
apt-get install postgresql |
dans pg_hba.conf : ajout de
Bloc de code |
---|
|
host all all 127.0.0.1/32 password |
...
Création de la base :
Bloc de code |
---|
|
su postgres
psql
create database esupsgc;
create USER esupsgc with password 'esup';
grant ALL ON DATABASE esupsgc to esupsgc;
ALTER DATABASE esupsgc OWNER TO esupsgc; |
Cette application a été dévelopée en utilisant Spring ROO et donc ses technologies associées.
...
Sous debian :
Bloc de code |
---|
|
apt-get install postgresql-contrib |
...
avec postgresql 9 :
Bloc de code |
---|
|
apt-get install postgresql-contrib
psql
\c esupsgc
CREATE EXTENSION lo; |
Et enfin ajout du trigger (afin que les tables soient préalablement créées, notamment la table big_file sur lequel on souhaite mettre le trigger lo_manage, il faudra avant celà démarrer une fois esup-sgc (avec le paramètre 'create' dans le persistence.xml)) :
Bloc de code |
---|
|
CREATE TRIGGER t_big_file BEFORE UPDATE OR DELETE ON big_file FOR EACH ROW EXECUTE PROCEDURE lo_manage(binary_file); |
...
Ajouter la contrainte postgresql supplémentaires supplémentaire :
Bloc de code |
---|
|
alter table card_desfire_ids ADD CONSTRAINT unique_desfire_ids_desfire_ids_key UNIQUE (desfire_ids, desfire_ids_key); |
Optimisation PostgreSQL
Si les configurations par défaut de PostgreSQL peuvent suffire, il peut être toutefois intéressant de les adapter pour que PostgreSQL puisse mettre à profit les ressources matérielles de votre serveur.
https://pgtune.leopard.in.ua peut vous permettre d'obtenir des paramétrages satisfaisants.
Suivant la distribution utilisée, le stats_temp_directory peut ne pas être monté en RAM. Sous debian stats_temp_directory est bien monté en tmps au travers du répertoire /run, mais ce n'est pas le cas sous centos 7 par exemple.
Cela peut être alors très pénalisant et provoquer énormément d'IO disque ou/et l'usage de 100% d'un cpu par un voir plusieurs vacuum postgresql.
Monter le stats_temp_directory en RAM est une opération rapide, simple et peu coûteuse dont il ne faut pas se priver sur une installation d'un PostgreSQL - la documentation suivante peut aider par exemple : http://hacksoclock.blogspot.com/2014/04/putting-statstempdirectory-on-ramdisk.html
Backup / restauration :
Avec l'utilisateur postgres backup :
Bloc de code |
---|
|
pg_dump -b -F d -f /backup/esupsgc-dump esupsgc |
restauration :
Bloc de code |
---|
|
pg_restore -d esupsgc /backup/esupsgc-dump |
et la conf CRON
Bloc de code |
---|
|
11 12,19,23 * * * postgres rm -f /opt/pg-backup/esupnfctag-`date +\%A-\%HH`.dump.bz2 && pg_dump -f /opt/pg-backup/esupnfctag-`date +\%A-\%HH`.dump esupnfctag && bzip2 /opt/pg-backup/esupnfctag-`date +\%A-\%HH`.dump
21 00 * * * postgres rm -rf /opt/pg-backup/esupsgc-dump && pg_dump -b -F d -f /opt/pg-backup/esupsgc-dump esupsgc |
...
Bloc de code |
---|
|
cd /opt
git clone https://github.com/EsupPortail/esup-sgc |
...
Pour les lancer, tapez depuis les sources :
Bloc de code |
---|
|
mvn clean test -DskipTests=false |
Vous devriez obtenir dans la console quelque chose comme :
Bloc de code |
---|
|
Results :
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS |
...
Packaging (et compilation)
Bloc de code |
---|
|
cd /opt/esup-sgc
mvn clean package |
...
On copie/colle le répertoire webapp packagé ainsi dans le tomcat :
Bloc de code |
---|
|
rm -rf /opt/tomcat-esup-sgc/webapps/ROOT && cp -rf /opt/esup-sgc/target/sgc-01.13.0.BUILD-SNAPSHOT /opt/tomcat-esup-sgc/webapps/ROOT |
...
- Logs : src/main/resources/log4j.properties
- Base de données :
- src/main/resources/META-INF/spring/database.properties pour paramètres de connexion
- src/main/resources/META-INF/persistence.xml pour passage de create à update après premier lancement (création + initialisation de la base de données)
- Mails : src/main/resources/META-INF/spring/email.properties
...
Celà peut se faire via une commande de type git pull
mise à jour en suivant le master (ne devrait plus être utile à partie du tag 1.0.0 actuellement en préparation - juin 2018)
Si vous faites des mises à jour sur le master directement, et sans suivre les tags, il peut y avoir des instructions sql issus du import.sql à reprendre ; le plus simple est de le réimporter : les entrées que vous avez déjà (et que vous avez éventuellement modifiées) ne seront pas écrasées grâce au jeu des noms de clefs / fonctions / triggers (des 'erreurs' seront signalés simplement).
:
Bloc de code |
---|
|
git pull origin esup-sgc-1.3.0 |
Bloc de code |
---|
|
su postgres -c "psql esupsgc < /opt/esup-sgc/src/main/resources/import.sql" |
mise à jour depuis un tag
Lors d'une mise à jour majeure de l'application, lancez la commande suivant pour mettre à jour la base :
Bloc de code |
---|
|
mvn compile exec:java -Dexec.args="dbupgrade" |
repackaging et redéploiement
N'oubliez pas alors de repackager et redéployer esup-sgc (cf ci-dessus packagin et déploiement).
Configuration
Configurations ESUP-SGC et ESUP-NFC-TAG-SERVER