Aller au contenu. | Aller à la navigation

Outils personnels

Navigation

Vous êtes ici : Accueil / Suivi serveur / Installation d'une instance zope personnelle

Installation d'une instance zope personnelle

avec "buildout" et "virtualenv"

Tutoriel inspiré par cet autre tutoriel.

La partie "Virtualenv" et "création de l'instance zope" sont "depracated" => le plus simple est de faire une installation à partir des sources que l'on trouve sur plone.org (d'une version choisie) et de se brancher sur le python mis en place par l'installeur.

Virtualenv

Virtualenv permet d'isoler une instance zope dans un environnement python "propre". C'est-à-dire que les librairies nécessaires au fonctionnement de l'instance sont copiées en local et que lorsqu'on active "virtualenv" python se réfère à ces librairies en priorité.

Ainsi plusieurs versions différentes des librairies peuvent exister sur le serveur sans générer de conflits

Pour plus d'info : Virtualenv

Buildout

Outil de déploiement mis au point par zopecorporation et utilisé par la communauté python. Il permet de prévoir la configuration d'autres applications (ex: Apache).

Il existe des scripts de base "buildout" pour les applications comme Plone.

Nous allons

  • utiliser dans ce tutoriel le buildout de Plone fourni par défaut et
  • modifier le fichier de configuration généré (buildout.cfg) pour intégrer les produits de base que l'on désire

Création de l'environnement virtuel

Voici la liste des commandes que nous allons appliquées (dans le répertoire "home" d'un utilisateur en étant connecté en tant que cet utilisateur)

virtualenv --no-site-packages virtualplone
cd virtualplone/
source bin/activate

La première commande crée l'environnement virtuel dans un dossier "virtualplone"

On se rend dans ce nouveau dossier puis on exécute la commande "source" qui exécute le script "bin/activate", cela a pour action de mettre python dans une "bulle", ainsi toutes lies installations de librairies se feront en local dans les dossier de "virtualplone"

L'option "--no-site-packages" signifie que l'on n'hérite dans ce nouvel environnement pas des paquets dans "site-packages" du python d'origine (ex: /usr/lib/python2.4/site-packages), par contre les paquets disponibles "en dessous" de "site-packages" (ex: /usr/lib/python2.4) sont quand même incorporés.

Par contre, une fois le virtualenv activé, l'appel à "python" lance celui de l'environnement, et "easy_install" va permettre d'installer des eggs dans le dossier "lib/python" de l'environnement virtuel.

Création de l'instance Zope (pour Plone)

paster create -t plone3_buildout ploneproject
cd ploneproject/
python bootstrap.py

On crée un dossier "ploneproject" (on est dans "virtualplone", on aurait pu être ailleurs, mais on est dans la bulle python de ce virtualplone) avec la commande "paster" qui se réfère à un dépôt où se trouve des recettes de "buildout".

On a choisi la recette "plone3_buildout", qui va installer le dernier plone3 disponible (il prend aussi des versions beta).

Le système nous pose des questions sur le numéro de port choisi et le nom de l'utilisateur "admin" et son mot de passe.

Toute l'arborescence de l'instance zope est créée avec le produit plone et les dépendances (produits nécessaires à plone).

A partir de là, nous avons déjà une instance opérationnelle et on peut la tester en lançant la commande

bin/instance fg

On remarque que ce n'est plus la commande bin/zopectl , mais bin/instance qui la remplace dans cette version avec "buildout"

La base de donnée Zope est contenu dans le sous-dossier var/filestorage/ de cette instance.

On peut imaginer recopier dans ce dossier un "Data.fs" d'une autre instance (celle qui avait été installée de manière traditionnelle, par exemple).

Les produits complémentaires

Il nous reste à installer les produits supplémentaires, et là 2 pistes s'offrent à nous:

  1. faire une installation manuelle à la manière "traditionnelle"
  2. modifier le fichier de configuration du buildout (buildout.cfg) pour y insérer les nouveaux produits

Dans le premier cas, on applique la technique traditionnelle de décompresser l'archive du produit dans le dossier "products" de l'instance (attention ce n'est plus "Products" avec majuscule, mais "products" avec minuscule).

Dans le deuxième cas, Il faut éditer le fichier "buildout.cfg" :

il est dans virtualplone/ploneprojetct ; pour l'éditer : vi buildout.cfg

Rappels sur vi (voir par ex http://www.commentcamarche.net/contents/tutlinux/linvi.php3)

Vi possède 3 modes de fonctionnement :

  • Le mode normal: celui dans lequel vous êtes à l'ouverture du fichier. Il permet de taper des commandes
  • Le mode insertion: Ce mode permet d'insérer les caractères que vous saisissez à l'intérieur du document. Pour passer en mode insertion, il suffit d'appuyer sur la touche Insert de votre clavier, ou à défaut de la touche i
  • Le mode de remplacement: Ce mode permet de remplacer le texte existant par le texte que vous saisissez. Il vous suffit de réappuyer sur insert (ou i) pour passer du mode insertion au mode remplacement, et d'appuyer sur la touche Echappour revenir en mode normal

 

 

:q Quitte l'éditeur (sans sauvegarder)
:q! Force l'éditeur à quitter sans sauvegarder (même si des modifications ont été apportées au document)
:wq Sauvegarde le document et quitte l'éditeur
:filenom Sauvegarde le document sous le nom spécifié

 

Deux voies s'offrent à nous:

  1. des produits avec "buildout"
  2. des produits sous forme d'archive "tar.gz" ou ".tgz" ou ".zip"

Produits avec "buildout"

Dans le cas de produit avec "buildout" il suffit d'ajouter le nom du produit dans la partie "eggs" de la section buildout ([buildout])

Par exemple, le produit "Ploneboard", on ajoute le nom "Products.Ploneboard" à la ligne suivant "elementree" (qui avait été ajouté automatiquement pour l'installation de plone).

# elementtree is required by Plone
eggs =
    elementtree
    Products.Ploneboard

Produits sous forme d'archive

Dans ce deuxième cas, il faut enregistrer l'adresse du lien de téléchargement de l'archive (sous http://plone.org/products, par ex.) et l'ajouter dans la section [productdistros] sous la partie "urls"

[productdistros]
recipe = plone.recipe.distros
urls =
       http://plone4artists.org/products/plone4artistscalendar/releases/1.1/Plone4ArtistsCalendar-1.1b1-plone3.0-bundle.tar.gz
       http://plone.org/products/fckeditor/releases/2.4.7/fckeditor-plone_2-4-7.tgz
       http://plone.org/products/plonearticle/releases/4.1.0-beta1/plonearticle-4-1-0-beta1.tgz
       http://weblion.psu.edu/static/products/cssmanager/cssmanager-0.8.tar.gz

Cette deuxième façon d'introduire des produits complémentaires permet une meilleure "portabilité", pour reproduire l'installation plusieurs fois. Par exemple, pour l'Ageliaco, on copie un "buildout.cfg" qui contient tous les produits complémentaires et on modifie simplement le numéro de port pour chaque utilisateur (cela ne dispense pas de faire toute la procédure d'installation du buildout de base une première fois!).

[instance]
...
http_address = 16007

 

Tester l'instance

On lance la création de l'instance (ou sa re-création si on a ajouté un nouveau produit dans le "buildout.cfg") en lançant la commande (dans un environnement virtuel)

bin/buildout

et on teste cette instance en lançant la commande

bin/instance fg

ce qui a pour effet de mettre l'instance en mode "debug" et affiche dans le terminal tous les messages d'erreur ou les "warnings".

S'il y a une erreur l'instance s'arrête, il faut voir quelle est l'erreur et modifier la configuration en conséquence.

On arrête l'instance, soit par un "control-C" dans le terminal, soit dans le Control_panel dans la ZMI.

Lancer l'instance

Enfin si on a passé l'épreuve du test avec succès on peut lancer l'instance comme un processus indépendant (avec un "watchdog", deuxième processus qui redémarre l'instance si elle devait défaillir) avec la commande :

bin/instance start