Aller au contenu. | Aller à la navigation

Outils personnels

Navigation

Vous êtes ici : Accueil / Wiki / Génération des fichiers de configuration de la prod

Génération des fichiers de configuration de la prod

deprecated

 

 

procédure changée avec l'introduction de ageliaco.recipe.csvconfig

Intro

La gestion des instances de prod devient lourd car il y a beaucoup d'instances et à tout moment il faut introduire un changement, comme par exemple un nouveau nom de domaine pour une instance existante.

En plus, un ajout d'un domaine ou sous-domaine implique des changements à plusieurs niveaux. Comme il y a une systématique à la chose et que cela ne touche pas que les fichiers buildout, mais aussi les fichiers de configuration pour les statistiques, j'ai décidé que la seule façon de gérer la chose était de générer les fichiers et de répercuter un changement sur l'ensemble des fichiers touchés.

Ci-dessous, j'explique comment je m'y prends (j'ai généré la doc avant d'avoir effectué le travail pour m'éclaircir les idées et surtout pour avoir une référence pour le suivi de la procédure => car je ne vais pas pouvoir faire cela en un coup)

 

Procédure

  1. chaque fichier à générer a un modèle qui porte le nom du fichier généré avec "init-" en préfixe
    1. main.cfg => init-main.cfg (pour la configuration de nginx)
    2. varnish.cfg => init-varnish.cfg (pour la configuration de varnish)
    3. awstats.domain.com.conf =>init-awstats.conf (pour la configuration de chaque domaine pour les stats)
  2. les parties variables dans ces modèles sont identifiées par des variables commençant par "$$$"
  3. un script python se base sur un fichier "csv" de départ (par défaut : instances.csv) et génère les fichiers de configuration en se basant sur les fichiers modèle,
  4. le fichier csv contient par ligne un enregistrement avec des champs suivants séparés par des virgules
    1. nom d'instance (sans espace => pour permettre d'identifier l'instance zope, il peut y avoir plusieurs lignes avec le même nom d'instance, pour permettre d'avoir plusieurs noms de domaine ou sous-domaine par instance)
    2. port de l'instance
    3. domain (nom de domaine de base => sur lequel on se base pour les statistiques et les logs ex: sismondi.ch)
    4. host (nom de domaine ou sous-domaine complet ex: www.sismondi.ch)
    5. plone (l'identifiant du plone correspondant, si '/' c'est la racine, ex: '/monplone')
  5. Il faut que le script génère les fichiers suivants:
    1. Dans le dossier de base du buildout
      1. instances.cfg => les données pour chaque instance avec ses domaines et sous-domaines (entièrement construit par le script => pas simplement des remplacements dans un fichier modèle)
      2. main.cfg => la config de nginx avec des variables à générer (que le système de macro du buildout n'arrive pas à générer)
      3. varnish.cfg => la config de varnish aussi avec des variables à générer (remarque idem à nginx)
    2. Dans le dossier /etc/awstats
      1. un fichier "awstats.$domain.conf" par nom de domaine (ex: awstats.sismondi.ch.conf)

 

Description du script

Arguments:

  1. le chemin du projet => base du buildout et des fichiers modèles "init-... .cfg"
  2. le nom du fichier csv pour les instances
  3. le chemin des fichiers de conf d'awstats (par défaut = "/etc/awstats") et du fichier modèle "init-... .conf" de conf

il identifie ce qui I

 

Procédure à suivre pour refaire les instances de prod

  1. mettre à jour le fichier instances.csv
  2. lancer python
  3. python
  4. import makebuild
  5. makebuild.makebuildout('/opt/zope/newprod','/opt/zope/newprod/instances.csv','/etc/awstats')

ensuite il faut refaire le buildout :

sudo bin/buildout -v

et lancer les commandes :

sudo bin/supervisorctl shutdown
sudo cp /home/admin/bin/sitecustomize.py parts/zope2/lib/python/ #pour corriger un bug
sudo chown -R nobody files
sudo chown -R nobody parts
sudo chown -R nobody var

sudo bin/supervisord

Pour la génération de supervisor

Quand les scripts bin/supervisord et bin/supervisorctl ne sont plus présents => ils doivent être recréés.

Il faut lancer la commande suivante:

sudo bin/buildout -v install supervisor

où "supervisor" est la partie du buildout qui appelle la recette "collective.recipe.supervisor"