Pré-requis
- Java OpenJdk 8 : le mieux est de l'installer via le système de paquets de votre linux.
- Maven : le mieux est de l'installer via le système de paquets de votre linux.
- Postgresql 9 : le mieux est de l'installer via le système de paquets de votre linux.
- Tomcat (Tomcat 8) : http://tomcat.apache.org/
- Apache + libapache2-mod-shib2 : https://services.renater.fr/federation/docs/installation/sp
- Git
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 :
apt-get install postgresql
dans pg_hba.conf : ajout de
host all all 127.0.0.1/32 password
Redémarrage de postgresql
Création de la base :
su postgres psql create database esupsgc; create USER esupsgc with password 'esup'; grant ALL ON DATABASE esupsgc to esupsgc;
Cette application a été dévelopée en utilisant Spring ROO et donc ses technologies associées.
Comme annoncé ci-dessus, l'application a cependant été développée avec PostgreSQL : lecture/écriture des blobs dans une transaction par streaming ; idexation postgresql (usage de tsvector/tsquery).
Pour une bonne gestion des blob de cette application, il faut ajouter dans PostgreSQL un trigger sur la base de données sur la table big_file. La fonction lo_manage est nécessaire ici.
Sous debian :
apt-get install postgresql-contrib
Puis la création de l'extension lo se fait via un super-user:
avec postgresql 9 :
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)) :
CREATE TRIGGER t_big_file BEFORE UPDATE OR DELETE ON big_file FOR EACH ROW EXECUTE PROCEDURE lo_manage(binary_file);
CF https://www.postgresql.org/docs/9.4/static/lo.html
Vous devez démarrer l'application une fois.Ne pas oublier ensuite, pour ne pas écraser la base au redémarrage, de modifier src/main/resources/META-INF/persistence.xml : create-> update - cf ci-dessous.
Ajouter la contrainte postgresql supplémentaires :
alter table card_desfire_ids ADD CONSTRAINT unique_desfire_ids_desfire_ids_key UNIQUE (desfire_ids, desfire_ids_key);
Backup / restauration :
Avec l'utilisateur postgres backup :
pg_dump -b -F d -f /backup/esupsgc-dump esupsgc
restauration :
pg_restore -d esupsgc /backup/esupsgc-dump
et la conf CRON
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
Paramétrage mémoire JVM :
Pensez à paramétrer les espaces mémoire JVM :
export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m"
Pour maven :
export MAVEN_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m"
Sources https://github.com/EsupPortail/esup-sgc
cd /opt git clone https://github.com/EsupPortail/esup-sgc
Tests
Quelques tests junit sont implémentées dans esup-sgc mais ils ne sont pas lancés par défaut, ni à la compilation ni lors du packaging.
Ces tests correspondent plus à des tests d'intégration que des tests unitaires, et peuvent permettre de détecter des problèmes de configuration, de disponibilités de services et de code également bien sûr.
Ils ne couvrent pas toutes les configurations, ni l'ensemble du code, mais ils seront améliorés et peuplés en fonction des retours que l'on pourra avoir.
Pour les lancer, tapez depuis les sources :
mvn clean test -DskipTests=false
Vous devriez obtenir dans la console quelque chose comme :
Results : Tests run: 10, Failures: 0, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS
Vous pouvez également trouver plus de logs dans les fichiers donnés dans le répertoire target/surefire-reports
Le fichier src/test/resources/META-INF/spring/esup-sgc-test.properties vous permet de sépcifier un eppn identifiant un utilisateur sur lequel certaines commandes (de récupération d'information uniquement) seront lancer au travers de certains tests junit.
Packaging (et compilation)
cd /opt/esup-sgc mvn clean package
Déploiement
On copie/colle le répertoire webapp packagé ainsi dans le tomcat :
rm -rf /opt/tomcat-esup-sgc/webapps/ROOT && cp -rf /opt/esup-sgc/target/sgc-0.1.0.BUILD-SNAPSHOT /opt/tomcat-esup-sgc/webapps/ROOT
On arrête le tomcat avant et on le redémarre ensuite.
Configurations systèmes
- 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
Mises à jour
Les mises à jour devraient consister à fusionner votre version de sgc avec configurations (et donc commits) internes et le tag nouvellement proposé.
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).
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 :
mvn compile exec:java -Dexec.args="dbupgrade"