Support #28287
Procédure pour faire tourner des scripts sur les plate-formes
0%
Description
Je pose la question par rapport à #27305.
J'ai développé un script1 pour le cd06 qui vient moissonner deux formulaires pour en extraire les pièces jointes, les dépose dans un répertoire selon un nommage <form_id>/piece_jointe.ext et le tout est synchronisé sur un sftp hébergé dans la collectivité.
Le script posé à la main dans /home/bdauvergne/cd06 tourne sur passerelle.rbx.tst.entrouvert.org mais pourrait tourner n'importe où, pourvu que ce soit sur une des IPs déclarées auprès de la collectivité, pour éviter que ça devienne vite le bordel, est-ce qu'on pourrait réfléchir à comment ce sera fait en prod ? Je n'ai pas tellement envie d'en faire un connecteur passerelle mais je m'y plierai si vous ne voyez que ça pour cadrer les choses.
Historique
Mis à jour par Christophe Siraut il y a plus de 5 ans
Je dirais soit dans un paquet debian, soit dans puppet.
Si puppet, je peux m'en occuper. On a un module "clients" qui pourrait contenir le script et le cron, lesquels seraient déployés en fonction du nom du serveur.
Si debian je peux m'en occuper également. Bref je n'ai pas de critère établi pour opter pour l'un ou l'autre. Puppet est un peu plus souple, les trucs sérieux j'essaie d'en faire des paquets.
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
C'est assez sérieux pour devoir être déployé sur nos recettes et nos prod pour ce client, mon idée étant de ne pas avoir à conserver une page de déploiement spécifique pour ce client (genre quand on bouge une prod où une recette faudra se souvenir qu'il faut déployer ce script, faire telle configuration, etc..); donc si ça peut passer par un paquet publik-client-scripts et un bout de puppet pour la configuration, ça me va.
Comme je le disais ma seule autre possibilité c'est d'en faire un connecteur passerelle spécifique, ce qui m'embête c'est de créer un précédent (i.e. chaque fois qu'on a un bout de script pour un client, hop un connecteur...).
Mis à jour par Frédéric Péters il y a plus de 5 ans
un paquet publik-client-scripts et un bout de puppet pour la configuration, ça me va.
Oublions puppet, sur des infras tierces on ne peut pas.
Un paquet, donc, publik-client-scripts, construit à partir d'un module git du même nom, dont la structure serait simplement un répertoire par client, et au plus simple ça copierait le tout vers /usr/lib/publik/.
Veut-on également que ce paquet déclare des jobs cron, je dirais pour commencer que non, qu'on pourra voir plus tard.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Et si on est ok là-dessus je peux créer le module et le packaging.
Mis à jour par Christophe Siraut il y a plus de 5 ans
- Assigné à changé de Christophe Siraut à Frédéric Péters
ok
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Nouveau à Fermé
Dépôt git créé et packaging debian et job jenkins associé également,
https://jenkins.entrouvert.org/job/publik-client-scripts-deb/
J'y ai actuellement posé un script spécifique à Strasbourg.