Forum général.cherche-logiciel Gestionnaire de configuration d'environnement

Posté par Spack le 04 juillet 2012 à 17:12.

Étiquettes : aucune

juil.

2012

Salut,

Il y a peu, j'avais tenté de poser la même question mais je pense que je m'étais mal fait comprendre. Je ré-essaye donc une nouvelle fois.

Les frameworks Web récents propose la fonctionnalité de configurer l'application en fonction de l'environnement où l'on se trouve. Cela permet d'utiliser une base de données pour le développement et d'en utiliser une autre lors de la mise en production.

Je suis à la recherche d'un outils générique proposant des fonctionnalités similaires. L'idée étant de définir mes différents environnements et de configurer mon code/fichiers par une simple commande. Un peu à la autoconf mais en plus simple.

Une idée de l'existence de ce genre d'outils?

# vi

Posté par BAud (site web personnel) le 04 juillet 2012 à 21:44. Évalué à 2.

Une idée de l'existence de ce genre d'outils?

vi ?

plus sérieusement : si tes environnements sont normalisés (compte applicatif, base(s), autres serveurs/noms de services applicaifs…) en différenciant d'une lettre (d pour développement, i pour intégration, h pour homologation ou q pour qualification, p pour prod'…), cela doit être possible de n'avoir qu'un paramètre pour déterminer tous les nommages.

Si ce n'est pas normalisé, bin livrer un fichier de conf' centralisé pour identifier les particularités de chaque environnements.

Tu imagines faire comment ? Tu aurais un exemple concret entre dév et intégration ?

Sinon, as-tu regardé cfengine ou puppet ou chef ? (c'est une logique de déploiement, pas de l'auto-configuration comme tu semblerais le souhaiter… c'est une mauvaise idée de vouloir laisser les développeurs impacter la production par une livraison de toute façon…).
- [^] # Re: vi
  
  Posté par Spack le 05 juillet 2012 à 09:14. Évalué à 2.
  
  Ben l'idée serait de définir dans les fichiers des variables du style ${ADRESSE_IP} ou ${DB_URL} puis de répertorier le tout dans un fichier qui en fonction de l'environnement remplace les variables par ce qui va bien…
  
  L'idée principale étant de pouvoir tester dans un environnement puis lorsque tout est OK, il n'y a plus qu'à passer en production à l'aide d'un truc du genre deploy prod qui va configurer le tout correctement.
  - [^] # Re: vi
    
    Posté par BAud (site web personnel) le 05 juillet 2012 à 11:08. Évalué à 2.
    bin, si tu as 3 environnements, tu fais 3 fichiers de conf' :
    - conf.dev
    - conf.intégration
    - conf.prod
    et ya pu qu'à faire le mv conf.${type_environnement} conf juste après déploiement.
    - [^] # Re: vi
      
      Posté par Spack le 05 juillet 2012 à 12:36. Évalué à 2.
      
      Sauf qu'il ne s'agit pas forcément de code capable d'aller lire dans le fichier voulu.
      
      Il faudrait modifier chaque fichier où les variables sont utilisées afin de les remplacer par la bonne valeur. Tout cela peu se faire avec un petit script maison mais j'aurais pensé qu'un outils de ce genre existait.
      - [^] # Le top : le code "je m'autoconfigure"
        
        Posté par ze_lionix (site web personnel) le 05 juillet 2012 à 12:57. Évalué à 1. Dernière modification le 05 juillet 2012 à 13:01.
        
        Il y a quelque années, après avoir "défoncé" la prod quelques fois en mettant le fichier de conf du dev la solution que j'ai trouvé ( pas trouvé mieux depuis ) est que le code doit gérer tout seule l'environnement !
        
        Par exemple pour un serveur web fichier en php :
        
        if ( $_SERVER['HTTP_HOST'] == "www.monsite.fr" ) { // variables et accès sgbd production } else if ( $_SERVER['HTTP_HOST'] == "dev.monsite.fr" ) { // variables et accès sgbd dev } else { die ( "c'est quoi cette bécanne ?" ) }
        
        Et exit les problèmes de fichiers spécifique à un environnement et qu'il faut surtout pas pousser….
        
        Petit inconvénient si une des deux machines est défoncée tu as les informations d'accès de l'autre, mais faut relativiser : si on a fait les choses proprement ( ségrégation réseau dev-prod ) les machines ne peuvent pas se joindre entre elles !
        
        Fuse : j'en Use et Abuse !