Lorsque vous déployez vos applications sur Clever Cloud, vous pouvez configurer la construction et le démarrage de votre application ou de services secondaires en utilisant des variables d’environnement. Nous avons récemment revu leur gestion. Cette refonte apporte clarté et cohérence aux variables de configuration, avec quelques changements incompatibles. Dans cet article, nous détaillons ce qui a changé et le travail fait pour vous éviter les problèmes.
Configurer votre déploiement
Un peu de contexte
Clever Cloud essaie de construire et d’exécuter vos applications en détectant la technologie que vous utilisez : un fichier composer.json existe ? Nous exécutons composer install. Vous avez déjà un composer.phar dans votre dépôt ? Nous utilisons celui-ci à la place de celui du système.
Cependant, vous devez parfois nous indiquer quoi faire. Votre application nécessite une version spécifique de PHP ou de Java pour fonctionner ? Nous ne pouvons pas le deviner. C’est là que les variables de configuration interviennent : pour nous indiquer quelle version de PHP utiliser ou si nous devons activer une extension PHP, vous devez utiliser des variables d’environnement, qui seront interprétées par le logiciel chargé du déploiement de l’application.
Un traitement empirique de la configuration
Historiquement, nous avons commencé à utiliser des variables d’environnement pour modifier le comportement du processus de déploiement. Le processus lui-même vérifiait la présence et validait les variables lorsqu’il devait les utiliser. La prise en charge de chaque variable était empirique et sujette à variations.
Par exemple, pour activer l’extension PHP APCu, vous pouvez définir ENABLE_APCU="true". Dans le script d’activation de l’extension, la valeur de la variable ENABLE_APCU était vérifiée juste avant d’activer (ou non) l’extension. Ce morceau de code acceptait la chaîne “true” sans tenir compte de la casse.
Ailleurs dans le code, CC_CACHE_DEPENDENCIES n’était vérifié que pour la chaîne exacte “true”. Ainsi “True” ou “TRUE” étaient considérées comme fausses. Pour d’autres variables, “yes” et “no” étaient autorisés à la place ou en plus de “true” et “false”.
Différentes variables impliquaient différentes stratégies de validation. Cela compliquait l’assistance client, puisqu’il fallait parfois consulter le code pour aider des utilisateurs confus.
Ce logiciel nécessitait depuis longtemps une refonte.
Nettoyer tôt, valider tôt, arrêter tôt
Ces derniers mois, nous avons commencé à réécrire la gestion de plus de 300 variables d’environnement. Il fallait :
- Localiser toutes les variables utilisées
- Lister toutes les manières dont elles étaient utilisées
- Documenter les différents types de variables existants
- Tout nettoyer
Les LLM à la rescousse !
Comme mentionné auparavant, ce nettoyage était attendu depuis longtemps. Il était dans nos esprits depuis plusieurs années. Cependant, le travail quotidien, les nouvelles fonctionnalités à développer, la croissance rapide de l’entreprise, etc., empêchaient de s’y consacrer.
Plus nous attendions, plus nous ajoutions de variables, et plus le travail devenait énorme. C’est à ce moment que les LLM sont arrivés. Trouver des motifs et réorganiser du texte est l’une de leurs forces ! Armés de ces outils, s’attaquer à cette tâche immense est soudainement devenu possible.
Tout centraliser
Nous avons commencé par lister toutes les variables. Avec l’aide de LLM, toutes les variables ont été trouvées et centralisées dans un fichier unique. Ce fichier sert désormais de source de vérité pour toutes les variables. Nous les avons également typées et noté comment chaque variable était utilisée.
À l’avenir, ce fichier sera utilisé pour générer la documentation et la validation dans nos API et nos clients.
Les types, pierre angulaire d’un code sain
Lorsque vous construisez des programmes qui reçoivent des données des utilisateurs, vous voulez respecter deux principes :
- Les utilisateurs sont imprévisibles : ils s’attendent à être compris quoi qu’ils envoient. Pour offrir une expérience fluide, vous devez accepter un large éventail de valeurs. Si vous ne les acceptez pas, affichez des messages d’erreur clairs.
- À l’intérieur de votre programme, vous voulez de la cohérence, de la simplicité et de la prédictibilité.
Pour cela, l’une des meilleures approches est d’utiliser des types forts. Par exemple, la chaîne “true” indique une valeur booléenne, vraie ou fausse. Dans le programme, nous ne vérifions que si la valeur est “true” ou “false” (toute autre valeur signifiant false). Autant utiliser un booléen.
Dans l’ensemble du programme de déploiement, les valeurs booléennes sont exposées aux utilisateurs de diverses manières :
- “true” / “false”
- “yes” / “no”
- “enable” / “disable”
- “enabled” / “disabled”
- “1” / “0”
- … (oui, il y en a d’autres !)
Pourquoi ne pas toutes les accepter ? C’est ce que nous avons décidé.
Pour les booléens, les utilisateurs peuvent désormais utiliser l’une des valeurs suivantes :
- Pour faux : 0, false, no, off, disable, disabled
- Pour faux : 0, false, no, off, disable, disabled
… plus quelques valeurs spécifiques pour la rétrocompatibilité.
Dans le code, nous récupérons la variable et obtenons une valeur booléenne. Plus besoin d’analyser plusieurs fois les mêmes chaînes dans des dizaines de fonctions !
Au final, nous avons défini les types suivants :
- Boolean
- Disabler (presque un booléen, mais “disable” signifie true)
- Alternatives (choix dans une liste définie, comme les versions Java)
- Number
- String
Pour chaque type, nous appliquons les mêmes étapes de nettoyage. Nous levons des erreurs cohérentes.
Arrêter tôt
Dans l’ancienne version du code de déploiement, les valeurs des variables étaient vérifiées au moment de leur utilisation. Cela signifiait qu’une variable utilisée pour démarrer votre application était validée après la construction ! Vous deviez attendre toute la phase de build pour savoir si la variable était correcte. Puis vous corrigiez la variable et réessayiez. Ensuite, une autre erreur apparaissait plus tard dans le processus. 🤦
Pour respecter les deux principes ci-dessus, nous devions tout valider dès le début.
Le programme de déploiement vérifie désormais toutes vos variables au lancement. Cela signifie que, quelle que soit la quantité de variables incorrectes, vous obtenez la liste complète des erreurs immédiatement et le déploiement s’arrête là. Plus besoin d’attendre 20 minutes avant de voir une erreur !
La cohérence implique un comportement plus strict
Puisque chaque partie du code analysait les chaînes fournies par les utilisateurs, différents comportements apparaissaient :
- Parfois, une valeur inattendue provoquait une exception
- Parfois, elle était simplement ignorée
- Parfois, elle était ignorée puis faisait échouer l’application pour des raisons obscures
Cette nouvelle validation étant cohérente, elle devient plus stricte pour certaines variables. Nous avons aussi choisi de considérer toutes les valeurs non prises en charge comme un échec. Cela signifie que votre application, auparavant déployée sans erreur, peut soudain échouer à cause d’une valeur non supportée.
Les déploiements blue-green de Clever Cloud empêchent toute interruption en cas de mauvaise valeur ! Le déploiement échoue tôt et vos instances existantes continuent de servir l’application.
Avant de publier cette mise à jour, nous avons également revu toutes vos variables de configuration Clever Cloud. Nous les avons testées et corrigées avant de déployer la mise à jour.
À quoi cela ressemble-t-il ?
Si votre déploiement échoue parce que certaines variables ne passent pas la validation, vous verrez ce message dans les logs :
Ce message indique que quatre variables ont une valeur inattendue. Les valeurs correctes sont affichées.
Lorsque vous obtenez ce message, allez dans l’onglet “Environment variables” de votre application dans la console et corrigez les variables. Par exemple :
CC_CGI_IMPLEMENTATION: il y avait une faute de frappe, facile à corriger !CC_COMPOSER_VERSION: la variable est définie, mais sa valeur est une chaîne vide.
Si vous corrigez toutes les erreurs, c’est terminé ! Aucune nouvelle erreur de variable non supportée n’apparaîtra au prochain déploiement.