🇬🇧 Compiler un front Angular variabilisé comme un chef
Posté le 11/08/2020 par Florent Jaby
Seulement voilà, Angular, à l’instar de beaucoup d’autres frameworks front-end, vous inflige de construire/compiler votre application une fois par environnement en collant la configuration associée dans un fichier qui porte le nom de l’environnement cible.
Cela pousse en général aux défauts suivants :
Des secrets ajoutés au dépôt de code dans ces fichiers de configuration
Un livrable différent par environnement, avec potentiellement des comportements différents
Aucune injection possible de configuration sans ajouter au code
Pas possible d’imaginer d’autres environnements sans ajouter au code, par exemple des review apps pour votre application
Si vous voulez plus d’informations sur pourquoi ces points sont des défauts, je vous invite à lire les chapitres 3, 5 et 10 de twelve-factor apps (la référence en ce qui concerne les applications Cloud Ready / Native).
Nous souhaitons les caractéristiques suivantes pour notre application :
Constuire un seul artefact pour toutes nos cibles de déploiement
Injecter la configuration spécifique par les variables d’environnement
Adapter le comportement de l’application, typiquement la balise
<base href="...">
en fonction d’une configurationUn déploiement identique à n’importe quel autre type d’application
Sur mon projet, tous nos applicatifs sont packagés avec Docker et deployés soit sur des VMs avec Ansible soit dans un cluster Kubernetes. On a donc cherché à packager notre application Angular de la même manière.
Utiliser un serveur statique comme image de base
Nous avons choisi nginx:alpine
comme image de base. Dans notre SI, tous les applicatifs parlent HTTP. Pour faire rentrer notre application web dans le moule, il fallait donc que son image suive les mêmes principes que nos briques d’API par exemple :
J’écoute sur un
PORT
connu (ici80
car la terminaison TLS est faite soit par ingress soit par un F5)Je sais sur quel préfixe d’URI je suis exposé via la configuration
BASE_URL
(par exemple :https://www.domaine.fr/mon-appli
)
Voici donc à quoi ressemble notre Dockerfile
:
Multi Stage Build
Ce Dockerfile
décrit un Multi Stage Build. C’est une mécanisme proposé pour utiliser des images de bases différentes pour la phase de construction de l’image à proprement parler et la phase d’execution. On utilise node:slim
pour construire l’application Angular car nous avons besoin des executables node
, npm
et npx
. Ensuite, nous utilisons l’image de base nginx:alpine
pour disposer d’un serveur HTTP statique plutôt léger. nous utilisons une configuration spéciale nginx.front.conf
qui vient de notre base de code. Elle ne fait rien d’intéressant à part le strict minimum, ce qui n’est pas forcément le cas de la configuration de base. Elle sert également à servir le même index.html
même pour les routes enfants afin que ce soit bien notre application quoi soit chargée à chaque fois et prenne en charge le routage côté navigateur.
Nous pouvons faire ceci car l’output de la commande ng build
se trouve entièrement dans le dossier /app/dist/
et ne nécessite aucune execution par le serveur. (pas besoin non plus de nettoyer les dépendances avec npm prune --production
)
La dernière ligne CMD ["nginx", "-g", "daemon off;"]
quant à elle indique simplement qu’on démarre le serveur Nginx au premier plan avec la configuration que nous lui avons copiée. C’est le dossier dist/
qui sera servi statiquement pour toutes les requêtes entrantes sur le port 80.
Personnalisation du docker-entrypoint
docker-entrypoint
Je n’ai pas encore parlé de la curieuse ligne RUN npm ci && npx ng build --prod --base-href '\${BASE_URL}'
. Attention ici, l’objectif n’est pas de faire la substitution de valeur au moment du docker build
mais bien d’inscrire dans le fichier généré le placeholder ${BASE_URL}
. Il est donc important de respecter l’echappement. L’option --base-href '\${BASE_URL}'
aura pour conséquence de génerer un index.html
qui a cette tête là.
On peut remarquer la ligne <base href="${BASE_URL}">
. C’est vraiment cette version avec un placeholder qui est stockée dans l’image. En revanche, ce ne sera jamais cette version qui sera servie. En effet, dans notre Dockerfile
nous avons précisé aussi :
Pour Docker, l’entrypoint
est l’executable qui sera lancée dans le conteneur une fois l’image lancée. Ses arguments seront le contenu de CMD
. En pratique, nous l’utilisons pour exécuter du code avant de lancer réellement Nginx. Voici le contenu de notre entrypoint
envsubst
est un petit programme, installé sur à peu près toutes les distributions *nix, qui se charge de remplacer les chaînes de caractères de la forme ${MA_VARIABLE}
par la valeur présente dans l’environnement. On change donc le contenu de notre index.html
juste avant de lancer Nginx pour modifier cette ligne
en cette ligne
Ici nous bénéficions du fait que notre application n’est exposée que sur un seul préfixe d’URL ce qui n’est pas forcément le cas pour vos applications. Dans un cas pareil, vous pourrez soit déployer 2 fois la même image avec 2 configurations différentes (complexité dans le déploiement), ou alors vous orienter vers la solutions de Server-Side Rendering la plus adaptée à votre framework (complexité dans l’applicatif)
Templatisation de config.js
config.js
En ce qui concerne la configuration spécifique à notre application (API_BASE_URL
, AUTH_BASE_URL
, etc.), nous utilisons un service Angular ConfigService
Ce service cherche dans l’espace global (window
) un objet nommé 'config'
et en copie toutes les clés. Cet objet est initialisé par notre fichier assets/config.js
importé depuis notre index.html
. En revanche, lorsque nous construisons l’image, c’est seulement template.config.js
que nous incorporons dans notre container. Voici à quoi il ressemble :
Nous pouvons modifier notre docker-entrypoint.sh
pour utiliser ce template :
Et zou !
Reality Check
Maintenant que nous avons fait tout ça, vérifions donc que nos critères sont bien remplis :
Notre artefact est une image Docker que l’on peut balader sur plusieurs environnements, facilement transmissible.
Nous pouvons configurer notre application grâce aux variables d’environnements que l’on donne au démarrage de cette image afin d’adapter le comportement de l’application à son déploiement.
Nous déployons un service HTTP tout simple, il suffit donc de diriger les connexions vers notre container.
Aucune incidence pour travailler localement avec
ng serve
Cette approche nous permet également de faire plus facilement certaines choses :
Utiliser un registre docker pour la promotion d’une version de notre application avec les tags
Faire une configuration aux petits oignons de notre exposition HTTP, notamment en ce qui concerne les stratégies de cache ou des redirections
Rajouter une protection de type
BasicAuth
à notre application si on veut limiter la population qui y a accèsGérer la terminaison TLS directement dans nginx pour un chiffrement en profondeur
Cette manière de packager et livrer nos applications Angular nous a bien aidé, en particulier en rentrant dans le moule de tous nos processus de livraison pour la gestion de la configuration et l’exposition. Je vous recommande d’essayer, en particulier si vous entrez dans une logique de review apps et que vous souhaitez livrer exactement ce que vous avez validé !
J’imagine que cette approche est transposable à d’autres frameworks front. Comment cela se passe-t-il pour vous avec Vue, React ou Ember ?
Source : https://blog.octo.com/compiler-un-front-angular-variabilise-comme-un-chef/
Dernière mise à jour