Open thbar opened 8 months ago
vdegove
commented
8 months ago Il y a des appels directs à des variables d’environnements dans d’autres fichiers que ceux cités ici, par exemple dans config/datagouvfr.exs ou config/mail.exs. Qu’est-ce qu’on en fait ? C’est pas gênant ?
Sujet un peu connexe : on pourrait pas en profiter pour basculer entièrement sur dev.secret.exs au lieu d’avoir également un fichier .env ?
AntoineAugusti
commented
8 months ago on pourrait pas en profiter pour basculer entièrement sur dev.secret.exs au lieu d’avoir également un fichier .env ?
je n'ai pas de fichier .env sur ma machine. Le code ne lit pas le fichier .env mais accède seulement à des variables d'environnement. Peut-être que ton terminal lit automatiquement le .env pour le transformer en variable d'env ?
vdegove
commented
8 months ago je n'ai pas de fichier .env sur ma machine.
Alors moi non plus, je n’ai pas de fichier .env, mais il y a un fichier .env.example, et j’avais cru comprendre que pour développer certaines parties du site, on devait s’en servir (en le copiant sur un fichier .env et en remplissant les variables d’environnement), car tout n’avait pas été migré vers dev.secret.exs. Si ce n’est pas le cas, autant le supprimer.
thbar
commented
8 months ago Alors moi non plus, je n’ai pas de fichier .env, mais il y a un fichier .env.example
C'est poubelle effectivement je confirme - on peut se débrouiller à 100% mais il y a encore peu longtemps ce n'était pas le cas.
La partie "MinIO S3 local" par exemple est peu documentée mais très utile pour mes travaux de masse.
thbar
commented
8 months ago Il y a des appels directs à des variables d’environnements dans d’autres fichiers que ceux cités ici, par exemple dans config/datagouvfr.exs ou config/mail.exs. Qu’est-ce qu’on en fait ? C’est pas gênant ?
Tout ça est "avalé" par le config.exs et donc intégré à compile-time. Il faudra effectivement refactorer tout ça.
Mais pas d'urgence hein :-)
thbar
commented
8 months ago Sujet un peu connexe : on pourrait pas en profiter pour basculer entièrement sur dev.secret.exs au lieu d’avoir également un fichier .env ?
Réponse oui clairement - il faut s'assurer que le template reste bien à jour et documenté !
AntoineAugusti
commented
8 months ago Suppression de .env.example ici https://github.com/etalab/transport-site/pull/3690
Comme discuté avec @AntoineAugusti notamment, je note ici les points d'améliorations qu'on pourra envisager pour les livraisons.
Préambule
Distinction compile-time vs runtime: en Elixir aujourd'hui les fichiers
config.exs,prod.exs(utilisé autant pour le staging que pour la vraie production) sont pris en compte au moment de la compilation.Le fichier
runtime.exslui est pris en compte au moment du runtime.Il se trouve qu'aujourd'hui le compile-time et le runtime se produisent tous les deux sur CleverCloud, avec les variables d'environnement "sous le coude". Le compile-time a lieu dans une machine dite "de build", tandis que le runtime tourne dans un container d'execution.
Les variables sont injectées dans les deux, mais les deux containers peuvent être dimensionnés différemment (pour des raisons de coût).
Ce méli-mélo un peu historique introduit certaines complexités qu'il va falloir résoudre à un moment (voir plus bas) si on veut améliorer les choses.
1. Configuration applicative pas assez "solide"
La configuration a petit à petit été déplacée vers
runtime.exsvolontairement pour permettre la mise en place (à terme) de "releases" Elixir, qui présentent certains avantages (voir le point 2 - compilations déportées, et le préambule)Pour ce faire, on a déplacé des configurations de
config.exset/ouprod.exsqui étaient donc "compilées", versruntime.exsà la place, qui est évalué au runtime.Le souci qui en résulte est qu'on peut découvrir un peu trop tard des soucis, avec:
Le dernier cas en date est le suivant:
(mais il y a eu d'autres épisodes et c'est bien normal, ce qu'on a fait est un peu trop fragile)
Il est important de remettre les choses en "évaluation runtime" pour pouvoir dissocier l'environnement de build et de runtime (voir préambule et voir point 2), mais il faut qu'on améliore cela pour empêcher ce type d'incident assez frustrant / stressant.
Une recette que j'avais imaginé est la suivante: packager la totalité de
runtime.exsmais sous forme de méthode dans un module, beaucoup plus facile à tester, et stubber par exemple l'environnement via une petite behaviour.Le
runtime.exsne ferait qu'appeler à ce stade ce module testé, en passant en paramètre la table d'ENV réelle.De cette façon testabilité importante, détection des problèmes de production / staging dès le CI avec des tests associés, et moins de stress.
En découle la tâche suivante (on créera un ticket le temps venu)
runtime.exsen un module typeApplicationConfig, qui sera mis sous test complètement et qui assertera sur la config, avec notamment unENVmoxé2. Modèle de déploiement à revoir
Actuellement (voir préambule), le déploiement est fait comme suit:
prod.exset éventuellementconfig.exssi il reste des traces encore)Le souci principal de ce modèle est le temps de déploiement (proche des 15 minutes), pour les raisons suivantes:
On souhaiterait sur 2024 si possible traiter ce souci tant qu'on est un peu à l'aise (pas d'incident majeur jusque là).
Les solutions possibles sont:
Je préfère nettement la première solution, qui sera plus rapide en exécution théorique, moins consommatrice de bande passante si c'est bien fait, et qui permet d'historiser nos builds aussi assez facilement et à coût nul.
Etapes si on va dans ce sens: