CategoryRBS Cooking

[RBS Cooking] Effectuer un dump d’une base de données et récupérer le fichier dans le répertoire du projet sur sa VM

…où polethermal est le nom du projet dans l’exemple ci-dessous :

A l’éxecution de cette commande, la machine nous fournit une URL temporaire vers le dump de la base.

Pour le déplacer à la racine du projet sur notre VM :

Restaurer au base de donnée dont le dump se trouve à la racine de notre projet

Vérifier la présence d’un dump en prod et le télécharger en local

[Sans cook] Restaurer une base de donnée à la main

Manipulation valable pour n’importe quel CMS (Magento, Drupal, WordPress, …).

A la racine du dossier contenant votre fichier docker-compose.yml, créer un dossier dump et placez-y le dump de votre base de données. Dans mon exemple, mon projet est manbow et le libellé de mon dump est: prod.2019-03-20.sql.gz

Dans le fichier docker-compose.yml, sous la section services > db > volumes (et, si la ligne existe, sous - mysql-data:/var/lib/mysql) ajouter la ligne:

Depuis la racine du dossier qui contient le fichier docker-compose.yml, lancer le container:

Se connecter en bash au container de la db:

Se rendre dans le dossier contenant le dump:

Lancer la commande de restoration de la base:
(username et password sont récupérables dans le fichier docker-compose.yml, sous la section services > db > environment)

Exécuter les commandes clear-all; compile-all; de Change.

[Sans cook] Si le front affiche l’erreur ERR_CONNECTION_REFUSED

  • Vérifier que l’URL de votre site en BO correspond bien à celle que vous tapez dans le navigateur.
  • (VirtualBox > Windows) Vérifier que l’IP de votre machine virtuelle (eth1) est bien celle que vous déclarez dans le fichier hosts de Windows.
  • Vérifier que l’URL de votre site en BO correspond bien à celle que vous avez ajouté au fichier hosts.

Tenter de désactiver le protocole https:

Dans le container de la db, pour la db concernée:

Dans le container Change (ou via cook) :

[RBS Cooking] Mettre à jour les URLs Git de vos projets

Procédure à mettre en oeuvre pour RBS Cooking et le dossier /projects pour chaque projet Change en local.

Manipulations à n’effectuer qu’une seule fois pour tous vos projets

Changer l’origin de /rbscooking

Dans /home/intlangf/rbscooking :

(Vous trouverez cette URL dans le dossier netapsys.rbs-change/interne.projects sur https://gitlab.netapsys.fr/)

Changer l’origin de /projects

Dans home/intlangf/projects (le repository qui détient tous les settings de tous les projets – à ne faire qu’une fois, donc…) :

(Vous trouverez cette URL dans le dossier netapsys.rbs-change/interne.projects sur https://gitlab.netapsys.fr/)

Manipulations à répéter pour chacun de vos projets

Rebrancher votre repository local vers le nouveau repository distant (https://gitlab.netapsys.fr)

Dans le dossier local qui contient votre projet (exemple : /home/intlangf/change30/accastillage) :

Vérifier l’intégrité des URLs dans le change.xml de votre projet

Pour les modules versionnés sous GIT

Remplacer :

par le nouvel URL que vous trouverez dans le dossier netapsys/rbs-change/ sur le repository distant https://gitlab.netapsys.fr/ :

/!\ SUPPRIMER VOTRE LOGIN de l’URL :

Pour les modules versionnés sous SVN

Remplacer :

par le nouvel URL se présentant sous la forme https://svn.netapsys.fr/webedit4/wfrepo/modules//branches/ :

/!\ Pour l’ensemble des modules versionnés sous SVN, rajouter un attribut vcs= »svn »

  • ch compile-config
  • git status
  • git add change.xml
  • git commit -m « « 
  • git push origin master

Changer les settings par défaut du projet

Opération à effectuer obligatoirement

Ouvrir le fichier defaults.py relatif à votre projet dans un éditeur :

et remplacer :

par le nouvel URL du projet que vous trouverez sur le repository distant https://gitlab.netapsys.fr/ :

/!\ SUPPRIMER VOTRE LOGIN DE L’URL

Commiter les modifs :

  • git pull
  • git status
  • git add
  • git commit -m
  • git push

Opération facultative

L’opération suivante est facultative. Elle vous servira éventuellement pour d’anciens projets si votre mise en intégration/production bloque sur les modules concernés, mais c’est normalement dans le change.xml (voir https://wiki.netapsys.fr/grand-est/web/interne/rbscooking/start/update_git_urls#verifier_l_integrite_des_urls_dans_le_changexml_de_votre_projet) que ces informations doivent être consignées et seront prises en compte par cook.

Pour info :

  • la mise en intégration du projet Accastillage qui sert d’exemple dans cette doc est passée alors que j’ai supprimé les lignes ci-dessous du fichier defaults.py.
  • pour visualiser un sample des infos que doit contenir un fichier defaults.py, allez dans default/sample/settings/.

ATTENTION : les URLs dans les deux bouts de code ci-dessous ne sont pas forcément justes. Les vérifier depuis votre navigateur.

AVANT :

APRES :

Commiter les modifs :

  • git pull
  • git status
  • git add + fichier settings.py modifié
  • git commit -m
  • git push

Mise en intégration

Les URLs d’intégration de vos projets ont changé également.

Dans projects//settings ouvrir int.py.

Remplacer l’URL sous « hostname » : « «  par l’adresse IP du site en intégration.
(pour obtenir l’IP d’un site à partir de son URL, taper « dig « ).

Pour accastillage :

[RBS Cooking] Créer un vhost dynamique pour les nuls

Cette opération va vous permettre de consulter depuis son IP un projet hébergé sur votre VM à partir d’un support mobile connecté au réseau local (wifi).

Récupérer l’adresse IP à placer dans l’url

Connectez-vous à votre VM en SSH et tapez :

L’adresse IP qui nous intéresse commence par 10.199.xx.xx

Créez un vhost pour le projet

Créez un vhost pour le projet que vous souhaitez rendre accessible depuis un support mobile connecté au réseau local.

**1.** Depuis la racine de votre VM, rendez-vous dans le répertoire qui stocke les fichiers vhosts :

Commencez par faire une copie du vhost servant de base à tous les projets Change hébergés sur votre VM en la nommant comme votre projet :

La commande « sudo » permet de jouir des droits d’administrateur requis à ce type de manipulations.

**2.** Lancez l’édition du vhost que vous venez de créer :

**Remarque** : le répertoire « sites-available » contient l’ensemble des vhosts disponibles, tandis que le répertoire « sites-enabled » contient l’ensemble des vhosts en cours d’éxecution (n’éditez rien dans ce répertoire; cette remarque est faite pour info).

**3.** Depuis l’interface d’édition que vous venez de lancer, modifiez en deux endroits l’adresse IP par celle fournie par le ifconfig :
* //ligne 1// «  »
* //ligne 3// « ServerName 10.199.xx.xx »

**4.** Modifiez également le répertoire cible du projet :
* //ligne 2// « DocumentRoot /home/intlangf/change30//webapp/www »
* //ligne 7// « webapp/www> »

**Petit rappel des fonctionnalités vi utiles :**
* [activer/quitter le mode insertion] echap
* [sauvegarder les modifications] :wq (:write quit)
* [quitter sans sauvegarder] :q!

Modifiez l’url du site dans Change

* Depuis un éditeur de code, modifiez l’url du site dans le fichier « config/project.xml » par l’IP fournie par le ifconfig : 10.199.xx.xx
* Modifiez également l’url en backoffice dans les propriétés du site.
* Puis, sous SSH, éxecuter : ch cconf

Activer/désactiver un vhost

**1.** Un seul host doit être activé à la fois, donc toujours désactiver le host en cours avant d’en activer un autre :

*

*

**Attention :** « change » est le vhost qui fera tourner l’ensemble des sites se trouvant sur la VM. Si vous activez le vhost que vous venez juste de créer, les autres sites hébergés sur votre VM ne seront plus consultables à moins de switcher à nouveau sur le vhost « change ».

**2.** Relancer apache après avoir enablé/disablé un vhost :

**3.** Lancer le site dans le navigateur depuis son IP :
10.199.xx.xx

**4.** Le site est en maintenance ?

[RBS Cooking] Création d’un projet vierge pour les nuls

Déployer un pack [[http://www.rbschange.fr/addons/distributions/RBS-Change-complet-Open-Source,67203.html|RBS Change complet]] comprenant le thème //Default//, l’ensemble des modules open-source, des pages et du contenu fictifs.

===== Méthode de déploiement =====

**1.** Sous SSH, rendez-vous à la racine du répertoire dans lequel vous avez l’habitude de déployer vos projets et débuter par un **cook update** :

cook update

**2.** Créez le nouveau projet :

cook create_new_project:,

(exemple: **cook create_new_project:aubert,3.6.4**)

Si aucune version de Framework n’est spécifiée dans la commande, c’est la version la plus récente qui sera installée.

**3.** Dans un éditeur de code, ouvrir le fichier //change.xml// du projet que vous venez de déployer et commenter les modules qui commencent par « wf ». Exemple :


<!--module source="wfgit@wf.ssxbgit01.intra.rbs-fr.net:repo/module.wf.git">wf-4.0.0</module-->

**4.** Toujours dans le fichier //change.xml//, ajouter la liste des modules à installer. Une liste à jour est disponible sous git dans le fichier //change.xml// du projet [[http://wf.ssxbgit01.intra.rbs-fr.net/gitweb/?p=project.demo.git;a=summary|Demo]].

**5.** Sous SSH, se rendre à la racine du nouveau projet et lancer la commande **ch create-new-project** (où **ch** est un alias de la commande change) :

ch create-new-project

**6.** Si des erreurs interviennent lorsque le script exécute la commande **rebuildFiles** :

ch gdb ; ch ca ; ch richtext.rebuild-files

**7.** Dans le fichier //change.xml//, dé-commenter les modules qui commencent par « wf ».

**8.** Faire un theme.install :
* du thème //Default// :

cook e:local c.install_theme

* du thème de votre choix :

cook e:local c.install_theme:,branch=master

**9.** Si pas encore installé, installer le module sample :

ch install-module sample-3.6.4 (ou autre version, suivant la version de Change que vous venez de déployer)

Cette commande vaut pour installer n’importe quel module supplémentaire.

**10.** Déployer les pages et le contenu fictif (cette commande peut être lancée à chaque fois qu’un nouveau module est installé – **Attention : pour déployer le contenu fictif, il faut __obligatoirement__ avoir installé le thème Default.**) :

ch sample.import full-os

**11.** (optionnel) Exécuter les commandes suivantes :

ch compile-all ; ch clear-all

**12.** Pour les e-commerces (notamment ceux avec facettes, qui ne font pas partie du pack open-source) :

ch catalog.compile-catalog ; ch indexer reset

**13.** Ne pas oublier d’ajouter votre nouveau site dans votre //host//.

===== Troubleshooting =====

=== Si la connexion en admin est impossible ===

ch reset-database

=== Si le site s’affiche mal (pas de css, problème d’url) ===
**1.** Vérifier le contenu du fichier //profile// se trouvant à la racine du site. Par exemple :


intlangf

**2.** Se rendre à la racine du répertoire //config// de votre projet.

**3.** Repérer le fichier //project..xml//. Dans notre exemple : project.intlangf.xml.

**4.** Vérifier dans ce fichier que l’url vers votre projet est correcte.


<entry name="server-fqdn">url_de_mon_projet</entry>

===== Installer le module wfslider =====

**1.** Dans change.xml (toujours, pour les nouveaux déploiements) :

wfslider-1.0

**2.** Pour téléchargement depuis git quand projet déjà déployé :

git clone ssh://wfgit@wf.ssxbgit01.intra.rbs-fr.net/home/wfgit/repo/module.wfslider.git repository/modules/wfslider/wfslider-1.0

**3.**

php framework/bin/change.php install-module wfslider-1.0

[RBS Cooking] Déploiement d’un projet existant pour les nuls

Déployer un projet existant __en local__.

===== Méthode de déploiement en local =====

Sous SSH, rendez-vous à la racine du répertoire dans lequel vous avez l’habitude de déployer vos projets et débuter par un **cook update** :

=== Récupérer les fichiers du projet : ===

**A.** Si projet versionné sous Git :

**B.** Si projet versionné sous SVN :

=== Récupérer la base de données : ===

**1.** Faire un //dump// de la base :

**2.** Faire un //fetch// de la base :

**3.** Le //fetch// terminé, une url va vous être communiquée. Par exemple :

**3a.** Faire un copier de cette url en prenant garde à :
– retirer tout ce qui se trouve après « <- /data/www..." qui ne fait pas partie de l'url - **BIEN RESTAURER LA BASE DANS LE PROJET LOCAL (paramètre __e:local__ de la commande) LORS DE L'EXECUTION DE LA COMMANDE QUI VA SUIVRE!!!** **3b.** Faire un coller de cette url à la suite de la commande suivante :

Par exemple : **cook manbow e:local c.db.restore:/tmp/manbow.prod/prodmanbow@10.128.0.114/prod.2012-10-08.sql.gz** === Quelques manipulations pour finir : === **1.** Définir l'url du site :

**2.** Pour les e-commerces (notamment ceux avec facettes) :

**3.** Webdeveloper toolbar : Cookies > Delete session cookies

**4.** Ne pas oublier d’ajouter votre nouveau site dans votre //host//.

===== Déployer un projet qui nécessite une clé webfactory =====

Il peut arriver que le déploiement s’arrête et que cook nous affiche une erreur du type //Unable to download : /modules/synchronizer/synchronizer-3.5.1 in local repository//.
Le projet utilise un module payant qui nécessite l’ajout d’une clé webfactory dans les settings de cook.

Les settings de cook, si ils sont identiques par défaut pour chaque projet, peuvent être surchargés pour des besoins spécifiques.
Le fichier //defaults.py// se trouve dans le répertoire :// /home/nom_du_user/projects/nom_du_projet/settings/ //.

ATTENTION : vous pouvez modifier ce fichier pour vos besoins, mais ne commitez pas vos modifications !

===== Mettre à jour les médias =====

Il est possible que le projet ait été déployé sans les médias.

Pour mettre à jour les médias sur votre projet local __depuis__ un serveur distant (demo, prod, int), utiliser c.media.rsync.__to__ :

Pour mettre à jour les médias sur un serveur distant (demo, prod, int) __depuis__ votre projet local, utiliser c.media.rsync.__from__ :

===== Troubleshooting =====

=== Si la connexion en admin est impossible ===

=== Si le site s’affiche mal (pas de css, problème d’url) ===
**1.** Vérifier le contenu du fichier //profile// se trouvant à la racine du site. Par exemple :

**2.** Se rendre à la racine du répertoire //config// de votre projet.

**3.** Repérer le fichier //project..xml//. Dans notre exemple : project.intlangf.xml.

**4.** Vérifier dans ce fichier que l’url vers votre projet est correcte.

===== Méthode de déploiement en intégration ou en production =====
(à mettre au propre choli-bô)

Depuis la branche ‘master’ :

* git st -> on vérifie d’abord que tout a bien été commité.
* git co integration/production
* git pull
* git merge master -> (où ‘master’ est la branche de travail)
* git push
* git co master -> (où ‘master’ est la branche de travail)

* cook update
* cook rbscorpo e:int/e:prod c.deploy

Effectuer un déploiement qui comprend uniquement des changements de fichiers (ne lance aucune commande Change) :
* cook rbscorpo e:int/e:prod c.deploy.dirty

Pour lancer une commande après le c.deploy.dirty (clear-webapp-cache par exemple) :
* cook rbscorpo e/int/e:prod c.cmd: »cwc »

Pour lancer plusieurs commandes après le c.deploy.dirty :
* cook rbscorpo e/int/e:prod c.cmd: »clear-all,compile-all »

cook groupauto e:int c.deploy.dirty:branch=forfait

Connexion impossible à la base de données pendant un déploiement de projet existant en local

Se connecter à mysql :

Extraction et remplissage d’une base de données

ATTENTION: veiller à créer d’abord une base de données vide sous mysql (C4_manbow dans notre exemple) !

© 2020 devfrontend.info

Theme by Anders NorénUp ↑