Lecture 4 minutes
Lors de notre visite aux équipes d’Oro à Los Angeles en novembre dernier, nous avons eu la chance de nous entretenir avec Dima Soroka, CTO, et Oleg Makovetskiy, team lead. De cet échange, nous avons extrait 5 astuces concernant OroCloud et son fonctionnement.
1 - Les patchs GIT
L’application d’un patch GIT sur un environnement OroCloud peut être réalisé de 2 manières différentes :
La première consiste à placer un dossier /patch à la racine de l’application contenant les différents fichiers .patch à appliquer. Ces patchs seront alors exécutés une seule fois lors du prochain composer install effectué par l'outil orocloud-cli, pendant une migration.
Point d’attention : il faudra prévenir les conflits que pourrait causer l'exécution de plusieurs patchs successifs. Le mieux est de tester l’application de ces patchs avant déploiement.
La deuxième consiste à appliquer le patch en se connectant au maintenance node de l’environnement visé via la passerelle VPN Oro et une connexion SSH sécurisée. A partir de là, l’outil en ligne de commande fourni par Oro permet différentes opérations dont :
patch:list - Liste les patchs déjà appliqués au sein de l’environnement
|
1 2 3 4 5 6 |
➤ Executing task patch:list +---------------------+----------------------------------+------------+ | DATE | HASH (md5) | PATCH | +---------------------+----------------------------------+------------+ | 2018-10-16 17:18:29 | b3d1e7ea5c476f0dba0b7588a8a93b70 | test.patch | +---------------------+----------------------------------+------------+ |
patch:apply - Permet d’appliquer un patch
La commande qui nous intéresse particulièrement est celle-ci puisque c’est grâce à elle que nous allons appliquer le patch. Il faudra dans un premier temps copier le fichier sur le serveur (soit via le repository du projet, soit via la commande scp, etc.) puis le déplacer dans le dossier /tmp/ du serveur afin que l’outil en ligne de commande orocloud-cli puisse l’exécuter.
|
1 2 3 4 5 |
scp file.patch user@serveur1:chemin/vers/dossier/destination ssh user@serveur1 cp file.patch /tmp/file.patch orocloud-cli patch:apply /tmp/file.patch orocloud-cli patch:apply /tmp/file.patch --force |
Pour plus d’informations sur les différentes commandes et l’ensemble des possibilités offertes par orocloud-ci, voici un lien vers la documentation.
2 - Personnaliser la page de maintenance d'OroCloud
Par défaut, OroCloud affiche une page de maintenance classique avec le minimum d’informations et dénuée de style. Dans certains cas, il peut être intéressant de personnaliser cette page avec la charte graphique du client. Pour le faire, il faut placer à la racine de l’application un premier fichier orocloud.yaml contenant les informations suivantes :
|
1 2 3 |
orocloud_options: application: maintenance_page: '/mnt/ocom/app/www/maintenance.html' |
Puis un fichier maintenance.html, toujours à la racine de l’application.
Il faut toutefois noter que cette page sera affichée pour tous les sites web de l’application. Il faut donc choisir une charte commune à tous ces sites.
3 - Sécuriser l’accès au backend
Plusieurs actions peuvent être entreprises pour sécuriser l’accès au backend d’une application hébergée sur OroCloud.
La première et la plus simple est de modifier l’url d’accès au backend de l’application avec la configuration suivante au sein du fichier orocloud.yaml, à la racine de votre application :
|
1 2 3 |
orocloud_options: application: web_backend_prefix: '/my_admin_console_prefix' |
La deuxième peut être un ensemble de configurations apportant des restrictions par IP, accès utilisateur sur une partie ou la totalité de l’application :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
orocloud_options: webserver: locations: 'root': type: 'php' location: '~ /app\.php(/|$)' auth_basic_enable: true auth_basic_userlist: user1: ensure: 'present' password: 'password1' user2: ensure: 'absent' password: 'password2' 'admin': type: 'php' location: '~ /app\.php(/admin|$)' auth_basic_enable: true auth_basic_userlist: user3: ensure: 'present' password: 'password1' user4: ensure: 'absent' password: 'password2' allow: - '127.0.0.1' - '127.0.0.2' deny: - 'all' |
Le détail des options se trouvant sur la documentation officielle.
4 - Comprendre les 3 types de mise à jour sur OroCloud
Au sein de l’outil orocloud-cli mis à disposition par l’éditeur, il est possible de réaliser 3 types de migrations :
| Commande | Description | Temps d'exécution |
|---|---|---|
| upgrade:source | Permet la mise à jour des sources sans downtime | 15 minutes |
| upgrade:rolling | Doit être utilisée si les modifications sur la base de données sont réversibles. 2 downtime de 10s environ | 20 minutes |
| upgrade | Concerne les migrations comportant des changements de schéma avec des effets irréversibles | 15 minutes |
Dans la plupart des cas, upgrade:rolling sera suffisant mais upgrade:source doit être utilisé avec précaution car il peut déclencher des erreurs liées à la non mise à jour du cache de l’application.
5 - Configurer Blackfire
Enfin, dernier point, mais sans doute le plus important en phase de développement et de debugging : il est possible d’utiliser le service Blackfire au sein de l’application. En renseignant, toujours dans le fichier orocloud.yaml à la racine de votre application, les différentes options suivantes :
|
1 2 3 4 5 6 7 8 |
orocloud_options: webserver: blackfire_options: agent_enabled : true server_id : '#server-id#' server_token : '#server-token#' log_level : '1' log_path : '/var/log/blackfire/agent.log' |
Dès lors, les effets seront disponibles sur la page de résultats blackfire.io avec un niveau de détail dépendant du forfait souscrit.
Le détail des options se trouvant aussi sur la documentation officielle.
Pour en savoir plus, n'hésitez pas à découvrir OroCommerce et OroCRM !
