
Comment utiliser les commandes "locales" du skeleton HTTP enthousiaste Objectifs Depuis la version 3.7 du Skeleton d'elasticms nous avons la possibilité de travailler avec des templates, des routes et des clés de traduction en local. L'avantage de cette approche est de pouvoir travailler en local, avec n'importe quels environments de publication (preview, staging, live) et n'importe quels environments de déploiement (test, intégration, acceptation, live) directement avec des fichiers yaml pour les routes et les traductions et des twig pour les templates. Remarques Pour que ces versions locales des routes, clés de traduction et templates fonctionnent, il est impératif d'être en mode debug. C'est à dire que la variable `APP_ENV` soit égale à `dev`. Autrement dit, si tu vois pas la debug bar de Symfony c'est mort. Tu peux changer tous ce que tu veux, tu ne veras aucuns changements. Sans cela les fichiers locaux sont ignorés et seuls les contenus indexés dans le cluster elasticsearch depuis l'elasticms seront considérés. Flux standard Imaginons que nous ayons un projet elasticms avec les 3 environnements suivants: template preview live Déployé en acc. Et qu'il faille mettre à jour un développement CSS dans les assets. Une fois le développement validé, il faudra alors le pousser jusqu'en production live. 1: Identifier la commande du skeleton Dans votre projet skeleton vous devriez voir un folder `configs/skeleton`. Dans ce folder il doit y avoir tout une série de fichier Dotenv (.env). Idéalement vous devriez avoir un fichier par environnement de publication (template, preview, live): preview.env template.env zz_live.env Sur cette base on vient d'identifier 3 environements de publication `preview`, `template` et `zz_live`. NB: le `zz_` est ajouté par le développeur car il a un "catch all domains" définit dans le fichier. Pour faire simple il y a très probablement la ligne suivante `SERVER_ALIASES=""` qui s' assure que si une requête arrive dans le pod avec un domaine inconnu il aura d'office une réponse avec un contenu 'live' plutôt qu'une page d'erreur. Si ce n'est pas le cas je vous invite à refactorer vos fichiers .env pour que cela soit le cas. Dans ce fichier les variables propres à l'environnement de publication devraient référencer d'autres variables définies dans le docker-compose. Comme ici avec les variables `ENVIRONMENT_ALIAS_BASE_PATH` et `BACKEND_URL`: ENVIRONMENT_ALIAS='${ENVIRONMENT_ALIAS_BASE_PATH}artists_preview' EMS_STORAGES='[{"type":"fs","path":"/tmp/assets","usage":"cache"},{"type":"s3","usage":"external","credentials":{"version":"2006-03-01","credentials":{"key":"${S3_ACCESS_KEY_ID}","secret":"${S3_SECRET_ACCESS_KEY}"},"region":"${S3_DEFAULT_REGION}","endpoint":"${S3_ENDPOINT_URL}","use_path_style_endpoint":true},"bucket":"${S3_BUCKET_NAME}"},{"type":"http","usage":"external","base-url":"${BACKEND_URL}"}]' EMSCH_BACKEND_URL='${BACKEND_URL}' EMSCH_ENVS='{"preview":{"regex":"/./","alias":"artists_preview","request":{"_locale":"fr"},"backend":"${BACKEND_URL}"}}' Pour résumer vous ne devriez jamais retrouver dans ces fichiers des urls vers les clusters elasticsearch ou vers les admins elasticsearch liés à un quelconque environment de déploiement (test, int, acc, prod). Mais plutôt des références du type `${BACKEND_URL}` ou `${EMS_ELASTICSEARCH_HOSTS}`. Vous pouvez maintenant lancer la commande `docker-compose ps --services` qui devrait vous donner: `artists-acc artists-prd` Nous venons d'identifier 2 environnements de déploiement `artists-acc` et `artists-prd`. Vous êtes en mesure de lancer la commande Symfony du Skeleton pour toutes les combinaisons d'environments: acc: template: `docker-compose exec artists-acc template` preview: `docker-compose exec artists-acc preview` live: `docker-compose exec artists-acc zz_live` prd: template: `docker-compose exec artists-prd template` preview: `docker-compose exec artists-prd preview` live: `docker-compose exec artists-prd zz_live` Si vous voulez connaitre le status entre vos fichier locaux et ceux publiés en `preview` sur `artists-prd` vous lancez: `docker-compose exec artists-prd preview ems:local:status` Et pour faire de même mais depuis `template` sur `artists-acc`: `docker-compose exec artists-acc template ems:local:status` vat donner: Local development - status ========================== -------------- ------------------------------------------------- Environment template Backend url https://artists-admin.acc.ext.socialsecurity.be Logged in as No Up to date Yes -------------- ------------------------------------------------- +--------------+-------+---------+---------+ \| \| Added \| Updated \| Deleted \| +--------------+-------+---------+---------+ \| Routing \| 0 \| 0 \| 0 \| \| Templating \| 0 \| 0 \| 0 \| \| Translations \| 0 \| 0 \| 0 \| +--------------+-------+---------+---------+ * Duration: 0 s * Memory: 18 MB 2: Avant de faire un ems:local:pull ! J'espère vraiment pour vous que vous utilisez un outil de versionning comme git. Mais il est important (vraiment) de bien versioner son travail dans votre repository de développement. En effet chaque environment de déploiement (test, int, acc, prod) peut être vu comme un repository remote. Vous êtes donc un peu dans une situation comme si vous aviez repository remotes pour vos fichiers. Donc si vous lancez une commande `ems:local:pull`; toutes vos modifications en local seront perdues à jamais. Donc avant de faire un `ems:local:pull` pensez à toujours faire au moins un `git commit`, ne fusse que pour sauver localement les derniers changements. 3: Reprendre la source authentique Votre projet git est à jour, vous avez bien créé une nouvelle branche pour traiter la demande. Et tout est bien commité. On peut donc reprendre les fichier depuis la source authentique. En effet, on ne sait jamais. Il est possible que quelqu'un ait modifié quelque chose directement dans l'elasticms de production sans rien dire à personne et qu'il l'ait publié en live. Pour cela nous allons donc reprendre les contenus en local depuis la production live: `docker-compose exec artists-prd zz_live ems:local:pull` Cette opération écrase, vous l'aurez compris, vos fichiers locaux. Je vous invite donc à vérifier tous les éventuels changements (rollback depuis git) qu'il y aura eu en production live. Mais à priori, il devrait suffire d'annuler tous les changements. Car, en théorie, personne n'aurait rien publié directement depuis l'elasticms de production ;-). 4: Reprendre le hash depuis l'environment par défaut Avant d'être en mesure de pousser vos modifications dans l'environnement par défaut (template dans notre exemple) de l'acceptation, vous devez démontrer que vous venez bien faire une modification de la version "courante" des contenus. Pour cela elasticms se base sur un hash qui représente la signature numérique de l'état de vos contenus. Si vous voulez mettre à jour le template d'acc il est impératif de d'abord récupérer la signature des contenus template d'acc avant. Cela s'obtient avec la commande pull: `docker-compose exec artists-acc template ems:local:pull` Comme toujours avec le pull vous perdez vos modifications. Même s'il est toujours bon de vérifier les différences, l'idée ici est de faire un rollback de toutes les modifications par rapport au git saur pour le fichier `skeleton/.version` qui contient justement ce hash. Je vous invite à commiter cette modification. 5: Faire votre boulot Vous pouvez désormais traiter, et tester en local, votre ticket. Ou vos tickets. Une fois fini, toujours bien commiter (et puller) vos fichiers dans git, hg, cvs, .... Dans notre exemple, il était question de mettre à jour une CSS. On doit donc, à priori, uploader une nouvelle version des assets. 5.1: Générer les assets de production Il faut générer les css et js minifiés. Mais il n'est plus utile de les compresser dans un zip (`npm run release` a été supprimé): `npm run prod` 5.2: Identifier son skeleton local Avant de modifier quelque chose on doit s'identifier dans l'elasticms d'acceptation: `docker-compose exec artists-acc template ems:local:login` Donne: `Username: > mdk Password: > Local development - login ========================= [OK] Welcome mdk on https://artists-admin.mondomaine.be * Duration: 9 s * Memory: 18 MB` En cas de problème toujours vérifier que votre utilisateur à bien les droits API dans elasticms (sur /profile/). 5.3: Uploader les assets Il existe une commande qui s'occupe d'uploader les assets. L'environment de déploiement n'a pas vraiment de sens ici, mais j'utilise l'environment par défaut `template` par cohérence. Voici la commande `docker-compose exec artists-acc template ems:local:upload-asset` Qui donne: `Local development - Upload assets ================================= 2620273/2620273 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100% [OK] Assets cc84833dd68cd71dfaea873e93d17c314feda34a have been uploaded * Duration: 5 s * Memory: 18 MB` Cette commande archive les assets, les upload et affiche le hash. Ici `cc84833dd68cd71dfaea873e93d17c314feda34a`. 5.4: Mettre à jour le variables.twig Avec ce hash vous pouvez mettre à jour la variable `hash`, `hashAssets` ou `site_hash` dans les clés de traduction ou dans le Twig variables.twig. C'est selon les cas. 6. Pousser les modifications en acc template On est fin prêt à pousser en template acc: `docker-compose exec artists-acc template ems:local:push` Cette commande vat mettre à jour le hash dans `skeleton/.version`. Je vous invite à commiter ces derniers changements (hash des assets et hash du contenu template d'acc). 7. Aligner le preview et le live d'acc Après vos tests en template, vous pouvez aligner vos contenus route, template et translation en acc depuis l'admin elasticms d'acceptation. 8. Reprendre le hash de production template Avant d'être en mesure de pousser vos modifications dans l'environnement par défaut (template dans notre exemple) de production, vous devez démontrer que vous venez bien faire une modification sur la version "courante" des contenus. C'est donc la même chose que ce qu'on a fait pour l'acceptation, il est impératif de d'abord récupérer la signature des contenus template de production avant. Cela s'obtient avec la commande pull: `docker-compose exec artists-prd template ems:local:pull` Comme toujours avec le pull vous perdez vos modifications. Comme vous êtes sûr de vos modifications vous pouvez faire un rollback de toutes les modifications par rapport au git sauf pour le fichier `skeleton/.version` qui contient justement le hash du contenu template de production. 9. Pousser en production template Vous pouvez maintenant déployer vos modifications en production: `docker-compose exec artists-prd template ems:local:push` 10: Aligner le preview et le live de production Après vos tests en template, vous pouvez aligner vos contenus route, template et translation en production depuis l'admin elasticms de production. Objectifs Remarques Flux standard 1: Identifier la commande du skeleton 2: Avant de faire un ems:local:pull ! 3: Reprendre la source authentique 4: Reprendre le hash depuis l'environment par défaut 5: Faire votre boulot 5.1: Générer les assets de production 5.2: Identifier son skeleton local 5.3: Uploader les assets 5.4: Mettre à jour le variables.twig 6. Pousser les modifications en acc template 7. Aligner le preview et le live d'acc 8. Reprendre le hash de production template 9. Pousser en production template 10: Aligner le preview et le live de production Derniers posts Draw.io on a website Deploy elasticms on AWS Intégrer BOSA Accessibility Check dans un site web [Content in French] PHP - Convert Human Readable Size to Bytes Composer: How to use a specific branch acting like a specific revision in composer dependencies Stream a CSV from a JSON array Comment utiliser les commandes "locales" du skeleton [Content in French] How to extract data from a JsonMenuNestedEditorField Backup on AWS glacier Refer to environment variables in twig https://mathieu.dekeyzer.net https://github.com/theus77 https://www.linkedin.com/in/mathieudk/ https://www.instagram.com/dekeyzermathieu/

Comment utiliser les commandes "locales" du skeleton

HTTP enthousiaste

Objectifs

Depuis la version 3.7 du Skeleton d'elasticms nous avons la possibilité de travailler avec des templates, des routes et des clés de traduction en local.

L'avantage de cette approche est de pouvoir travailler en local, avec n'importe quels environments de publication (preview, staging, live) et n'importe quels environments de déploiement (test, intégration, acceptation, live) directement avec des fichiers yaml pour les routes et les traductions et des twig pour les templates.

Remarques

Pour que ces versions locales des routes, clés de traduction et templates fonctionnent, il est impératif d'être en mode debug. C'est à dire que la variable APP_ENV soit égale à dev.

Autrement dit, si tu vois pas la debug bar de Symfony c'est mort. Tu peux changer tous ce que tu veux, tu ne veras aucuns changements.

Sans cela les fichiers locaux sont ignorés et seuls les contenus indexés dans le cluster elasticsearch depuis l'elasticms seront considérés.

Flux standard

Imaginons que nous ayons un projet elasticms avec les 3 environnements suivants:

template
preview
live

Déployé en acc.

Et qu'il faille mettre à jour un développement CSS dans les assets.

Une fois le développement validé, il faudra alors le pousser jusqu'en production live.

1: Identifier la commande du skeleton

Dans votre projet skeleton vous devriez voir un folder configs/skeleton. Dans ce folder il doit y avoir tout une série de fichier Dotenv (.env).

Idéalement vous devriez avoir un fichier par environnement de publication (template, preview, live):

preview.env
template.env
zz_live.env

Sur cette base on vient d'identifier 3 environements de publication preview, template et zz_live.

NB: le zz_ est ajouté par le développeur car il a un "catch all domains" définit dans le fichier. Pour faire simple il y a très probablement la ligne suivante SERVER_ALIASES="*" qui s' assure que si une requête arrive dans le pod avec un domaine inconnu il aura d'office une réponse avec un contenu 'live' plutôt qu'une page d'erreur.

Si ce n'est pas le cas je vous invite à refactorer vos fichiers .env pour que cela soit le cas. Dans ce fichier les variables propres à l'environnement de publication devraient référencer d'autres variables définies dans le docker-compose. Comme ici avec les variables ENVIRONMENT_ALIAS_BASE_PATH et BACKEND_URL:

ENVIRONMENT_ALIAS='${ENVIRONMENT_ALIAS_BASE_PATH}artists_preview'
EMS_STORAGES='[{"type":"fs","path":"/tmp/assets","usage":"cache"},{"type":"s3","usage":"external","credentials":{"version":"2006-03-01","credentials":{"key":"${S3_ACCESS_KEY_ID}","secret":"${S3_SECRET_ACCESS_KEY}"},"region":"${S3_DEFAULT_REGION}","endpoint":"${S3_ENDPOINT_URL}","use_path_style_endpoint":true},"bucket":"${S3_BUCKET_NAME}"},{"type":"http","usage":"external","base-url":"${BACKEND_URL}"}]'
EMSCH_BACKEND_URL='${BACKEND_URL}'
EMSCH_ENVS='{"preview":{"regex":"/.*/","alias":"artists_preview","request":{"_locale":"fr"},"backend":"${BACKEND_URL}"}}'

Pour résumer vous ne devriez jamais retrouver dans ces fichiers des urls vers les clusters elasticsearch ou vers les admins elasticsearch liés à un quelconque environment de déploiement (test, int, acc, prod). Mais plutôt des références du type ${BACKEND_URL} ou ${EMS_ELASTICSEARCH_HOSTS}.

Vous pouvez maintenant lancer la commande docker-compose ps --services qui devrait vous donner:

artists-acc
artists-prd

Nous venons d'identifier 2 environnements de déploiement artists-acc et artists-prd. Vous êtes en mesure de lancer la commande Symfony du Skeleton pour toutes les combinaisons d'environments:

acc:
- template: docker-compose exec artists-acc template
- preview: docker-compose exec artists-acc preview
- live: docker-compose exec artists-acc zz_live
prd:
- template: docker-compose exec artists-prd template
- preview: docker-compose exec artists-prd preview
- live: docker-compose exec artists-prd zz_live

Si vous voulez connaitre le status entre vos fichier locaux et ceux publiés en preview sur artists-prd vous lancez:

docker-compose exec artists-prd preview ems:local:status

Et pour faire de même mais depuis template sur artists-acc:

docker-compose exec artists-acc template ems:local:status

vat donner:

Local development - status
==========================

 -------------- ------------------------------------------------- 
  Environment    template                                         
  Backend url    https://artists-admin.acc.ext.socialsecurity.be  
  Logged in as   No                                               
  Up to date     Yes                                              
 -------------- ------------------------------------------------- 

+--------------+-------+---------+---------+
|              | Added | Updated | Deleted |
+--------------+-------+---------+---------+
| Routing      | 0     | 0       | 0       |
| Templating   | 0     | 0       | 0       |
| Translations | 0     | 0       | 0       |
+--------------+-------+---------+---------+

 * Duration: 0 s
 * Memory: 18 MB

2: Avant de faire un ems:local:pull !

J'espère vraiment pour vous que vous utilisez un outil de versionning comme git. Mais il est important (vraiment) de bien versioner son travail dans votre repository de développement.

En effet chaque environment de déploiement (test, int, acc, prod) peut être vu comme un repository remote. Vous êtes donc un peu dans une situation comme si vous aviez repository remotes pour vos fichiers.

Donc si vous lancez une commande ems:local:pull; toutes vos modifications en local seront perdues à jamais. Donc avant de faire un ems:local:pull pensez à toujours faire au moins un git commit, ne fusse que pour sauver localement les derniers changements.

3: Reprendre la source authentique

Votre projet git est à jour, vous avez bien créé une nouvelle branche pour traiter la demande. Et tout est bien commité. On peut donc reprendre les fichier depuis la source authentique.

En effet, on ne sait jamais. Il est possible que quelqu'un ait modifié quelque chose directement dans l'elasticms de production sans rien dire à personne et qu'il l'ait publié en live.

Pour cela nous allons donc reprendre les contenus en local depuis la production live:

docker-compose exec artists-prd zz_live ems:local:pull

Cette opération écrase, vous l'aurez compris, vos fichiers locaux. Je vous invite donc à vérifier tous les éventuels changements (rollback depuis git) qu'il y aura eu en production live.

Mais à priori, il devrait suffire d'annuler tous les changements. Car, en théorie, personne n'aurait rien publié directement depuis l'elasticms de production ;-).

4: Reprendre le hash depuis l'environment par défaut

Avant d'être en mesure de pousser vos modifications dans l'environnement par défaut (template dans notre exemple) de l'acceptation, vous devez démontrer que vous venez bien faire une modification de la version "courante" des contenus.

Pour cela elasticms se base sur un hash qui représente la signature numérique de l'état de vos contenus. Si vous voulez mettre à jour le template d'acc il est impératif de d'abord récupérer la signature des contenus template d'acc avant.

Cela s'obtient avec la commande pull:

docker-compose exec artists-acc template ems:local:pull

Comme toujours avec le pull vous perdez vos modifications.

Même s'il est toujours bon de vérifier les différences, l'idée ici est de faire un rollback de toutes les modifications par rapport au git saur pour le fichier skeleton/.version qui contient justement ce hash.

Je vous invite à commiter cette modification.

5: Faire votre boulot

Vous pouvez désormais traiter, et tester en local, votre ticket. Ou vos tickets.

Une fois fini, toujours bien commiter (et puller) vos fichiers dans git, hg, cvs, ....

Dans notre exemple, il était question de mettre à jour une CSS. On doit donc, à priori, uploader une nouvelle version des assets.

5.1: Générer les assets de production

Il faut générer les css et js minifiés. Mais il n'est plus utile de les compresser dans un zip (npm run release a été supprimé):

npm run prod

5.2: Identifier son skeleton local

Avant de modifier quelque chose on doit s'identifier dans l'elasticms d'acceptation:

docker-compose exec artists-acc template ems:local:login

Donne:

 Username:
 > mdk

 Password:
 > 

Local development - login
=========================

                                                                                                                        
 [OK] Welcome mdk on https://artists-admin.mondomaine.be                                                    
                                                                                                                        


 * Duration: 9 s
 * Memory: 18 MB

En cas de problème toujours vérifier que votre utilisateur à bien les droits API dans elasticms (sur /profile/).

5.3: Uploader les assets

Il existe une commande qui s'occupe d'uploader les assets. L'environment de déploiement n'a pas vraiment de sens ici, mais j'utilise l'environment par défaut template par cohérence.

Voici la commande

docker-compose exec artists-acc template ems:local:upload-asset

Qui donne:

Local development - Upload assets
=================================

 2620273/2620273 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

                                                                                                                        
 [OK] Assets cc84833dd68cd71dfaea873e93d17c314feda34a have been uploaded                                                
                                                                                                                        


 * Duration: 5 s
 * Memory: 18 MB

Cette commande archive les assets, les upload et affiche le hash. Ici cc84833dd68cd71dfaea873e93d17c314feda34a.

5.4: Mettre à jour le variables.twig

Avec ce hash vous pouvez mettre à jour la variable hash, hashAssets ou site_hash dans les clés de traduction ou dans le Twig variables.twig. C'est selon les cas.

6. Pousser les modifications en acc template

On est fin prêt à pousser en template acc:

docker-compose exec artists-acc template ems:local:push

Cette commande vat mettre à jour le hash dans skeleton/.version. Je vous invite à commiter ces derniers changements (hash des assets et hash du contenu template d'acc).

7. Aligner le preview et le live d'acc

Après vos tests en template, vous pouvez aligner vos contenus route, template et translation en acc depuis l'admin elasticms d'acceptation.

8. Reprendre le hash de production template

Avant d'être en mesure de pousser vos modifications dans l'environnement par défaut (template dans notre exemple) de production, vous devez démontrer que vous venez bien faire une modification sur la version "courante" des contenus.

C'est donc la même chose que ce qu'on a fait pour l'acceptation, il est impératif de d'abord récupérer la signature des contenus template de production avant.