-
Notifications
You must be signed in to change notification settings - Fork 14
Deploys
Pour un "nouvel arrivant", déployer geocat reviendrait en théorie à:
cd /var/www/vhosts/tc-geocat/private
git clone --recursive [email protected]:camptocamp/geocat.git geocat.ch.$USER
cd geocat.ch.$USER
git submodule init
git submodule update --init --recursive
cd ..
Lancer le script nécessaire au déploiement sur l’environnement souhaité:
cd geocat.ch.deploy
./deploy.to.localhost.sh
pour dev par exemple. Pour int, lancer ./deploy.to.integration.sh sur dev.
Cette page documente le travail laissé par Jesse pour le déploiement sur GeoCat. Son travail fait l'objet d'un dépot spécifique disponible (en privé, car contenant des informations sensibles comme des mots de passes) ici: https://github.com/camptocamp/geocat_deploy.
Avant son départ, Jesse avait rédigé des procédures de déploiement sous forme de Shell-script. C'est cette procédure qui a permis de passer en production la version actuelle de Geocat.
A noter que ces scripts devaient addresser deux uses-cases:
- Mise en production du code (webapp uniquement)
- Chargement initial d’une base de données (ancienne ou nouvelle version du schéma) + données (datadir geonetwork), en plus de l'étape précédente, via le passage d'un paramêtre supplémentaire (./deploy.to. all).
Suite à la mise en production, le second mode de fonctionnement a été abandonné (pour éviter toute perte évidente de données dû à un potentiel rechargement inopportun de la base et/ou des données statiques).
- ssh0a.prod.bgdi.ch
- 10.220.4.5 (serveur de dev)
- 10.220.4.214 (serveur d’intégration)
- 10.220.5.105 (production)
Les 3 derniers serveurs ne sont accessibles que via le premier (Il convient donc de penser à bien forwarder son agent avec -A ou avoir une configuration SSH adéquate). L'agent sera dans tous les cas nécessaire pour lancer les scripts de déploiement sur le serveur de test.
test et intégration intègrent une base postgresql en local ; pour la production, la base est déportée sur un autre serveur (10.220.5.10) accessible via l'utilisateur admin.
Tous les scripts se trouvent sur le serveur de test dans le répertoire suivant:
/var/www/vhosts/tc-geocat/private/geocat.ch.deploy
C'est depuis ce serveur que sont pilotés les déploiements pour les 3 architectures. Si l'on regarde un répertoire plus haut dans l’arborescence:
pmauduit@ip-10-220-4-102 (vpc/geocat - test):/var/www/vhosts/tc-geocat/private$ ls -lh
[...]
lrwxrwxrwx 1 pmauduit geodata 18 Oct 13 18:20 geocat.ch -> geocat.ch.pmauduit
drwxr-sr-x 4 1112 geodata 4.0K Sep 30 08:53 geocat.ch.deploy
drwxr-sr-x 38 fgravin geodata 4.0K Sep 25 18:52 geocat.ch.git
drwxr-sr-x 38 pmauduit geodata 4.0K Jan 19 17:48 geocat.ch.pmauduit
drwxr-sr-x 38 1112 geodata 4.0K Sep 29 14:38 geocat.jesse.checkout
Comme chaque utilisateur a son compte propre, pour éviter des problèmes de droits, il est nécessaire pour la personne souhaitant déployer GeoCat d’effectuer un git clone spécifique dans geocat.ch.<utilisateur> et de faire pointer le lien symbolique geocat.ch (TODO: a vérifier, peut-être inutile) sur ce répertoire avant déploiement.
Retour dans le répertoire précédent, nous retrouvons quelques scripts shell ainsi qu’un sous-répertoire hooks. Il y a un script par environnement, et un principal utilisé par les autres: core.deploy.sh.
$ ls -l
[...]
-rwxrwxr-x 1 1112 geodata 2811 Jan 6 16:18 core.deploy.sh
-rwxrwxr-x 1 1112 geodata 99 Feb 20 2015 deploy.to.all.sh
-rwxrwxr-x 1 1112 geodata 237 Oct 8 2014 deploy.to.integration.sh
-rwxrwxr-x 1 1112 geodata 234 Oct 8 2014 deploy.to.jenkins.sh
-rwxrwxr-x 1 1112 geodata 230 Sep 25 18:24 deploy.to.localhost.sh
-rwxrwxr-x 1 1112 geodata 333 Oct 8 2014 deploy.to.production.sh
-rwxrwxr-x 1 1112 geodata 536 Nov 18 15:56 deploy.to.shadow.sh
-rw-rw-r-- 1 1112 geodata 723 Feb 23 21:11 geocat.cfg
drwxrwsr-x 4 1112 geodata 4096 Oct 27 21:02 hooks
core.deploy.sh contient donc toute la logique du processus de déploiement, deploy.to.all.sh, comme son nom ne l’indique pas, permet de déployer sur dev et int à la suite (mais omet le déploiement sur la production).
deploy.to.shadow.sh correspond au déploiement sur l’environnement “shadow” ; cet environnement n’est plus utilisé mais correspondait à la “nouvelle production” avant la mise en production effective de novembre 2015. Depuis le passage en production, nous utilisons deploy.to.production.sh pour le déploiement sur l'environnement de production.
deploy.to.localhost.sh permet de déployer sur l’environnement de test.
A noter que les deploy.to.*.sh permettaient le passage d’un argument optionel “all”, qui, si activé avait pour effet de recharger un dump de la base de données (situé dans hooks/geocat/initialDump.sql.gz). Ce paramêtre n’a quasiment jamais été utilisé suite au passage en production, pour éviter un rechargement intempestif d'un dump périmé de la base en production.
A noter la présence du répertoire hooks/geocat/conf/ qui définit la configuration (ip) des serveurs en fonction de l’environnement considéré (un peu redondant avec ce qui est déjà défini dans le core.deploy.sh, mais cette redondance peut s'expliquer par le fait que tout est rsync lorsque le déploiement n'est pas local, et que le script de deploy a sans doute besoin d'avoir l'information une fois envoyé sur un serveur distant).
hooks/geocat/data contient le datadir geocat à déployer (mais n’est censé être utilisé que si le mode all du deploy est utilisé ? TODO A vérifier).