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 :

1. Localiser toutes les variables utilisées
2. Lister toutes les manières dont elles étaient utilisées
3. Documenter les différents types de variables existants
4. 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 :

1. 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.
2. À 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 :

• For true: 1, true, yes, on, enable, enabled
• 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.

Cette semaine, nous avons mis en production des améliorations de présentation de nos factures. Le résultat : des factures qui vous aident à comprendre ce que vous payez et à quel montant vous attendre pour la facture suivante. Regardons cela en détail !

Pour introduire la problématique : Clever Cloud vous facture ce que vous avez utilisé pendant la dernière période, ainsi qu'une provision ("crédits prépayés") pour la période de facturation suivante. D'une facture à l'autre, la provision va évoluer en fonction de votre utilisation de Clever Cloud. Jusqu'ici, le montant de crédits provisionnés à l'instant T n'était pas clairement affiché. L'autre problématique était la gestion du compte de crédits offerts. Ces derniers sont toujours soumis à expiration. Il fallait donc l'expliciter dans les factures.

Une première page plus claire

Premièrement, nous avons renommé plusieurs descriptions sur la première page. En partie pour faire plaisir à notre service juridique. Mais principalement pour rendre ces lignes compréhensibles. Ainsi, là où il y avait « Consommation Clever Cloud », on peut maintenant lire « Redevance utilisation de la plateforme ». Nous avons également amélioré l'affichage des montants : tout d'abord, un sous-total représentant le total à payer (après remises) pour avoir utilisé Clever Cloud ("Redevance totale"). Ensuite, un montant de crédits retirés ou à ajouter à votre compte prépayé. La somme des deux vous donne le total à payer.

Les crédits gratuits explicités

Le changement suivant apparaît sur la deuxième page : nous vous donnons le détail de tous les crédits gratuits consommés / expirés ce mois-ci et comment nous calculons les crédits à supprimer ou à ajouter à la facture.

Sur cette deuxième page, vous avez : tous les crédits gratuits auxquels vous avez droit, ceux qui sont arrivés à expiration, combien il vous reste pour couvrir la prochaine période de facturation. Vous avez également toutes les variables que nous utilisons pour calculer les crédits ajoutés ou consommés qui s'affichent sur la première page.

Cette deuxième page vous aidera à suivre le solde de vos crédits prépayés et à mieux comprendre pourquoi nous vous facturons ce montant précis.

Avec ces changements, votre comptable devrait être content ! D'une part, nous espérons que cela les aidera à comprendre nos factures. Et d'autre part, qu'ils pourront consacrer du temps à essayer de comprendre les factures de vos autres fournisseurs! 😇