Retour aux fondamentaux avec ce premier article d’une nouvelle série. Découvrons ensemble le fonctionnement du cloud computing, ses différentes architectures (public, privé, hybride), ses nombreux avantages pour les entreprises ainsi que les différences entre cloud computing, edge computing, et on-premise pour vous aider à choisir la solution la plus adaptée à vos besoins.

Cloud computing : définition et origines

Le cloud computing a profondément transformé la manière dont les entreprises et les particuliers accèdent aux ressources informatiques. L'idée est simple mais novatrice : plutôt que de posséder et de gérer ses propres serveurs et centres de données, l'utilisateur peut désormais accéder à des services informatiques à la demande, via un réseau. Ces services incluent la puissance de calcul, le stockage de données, et parfois même la gestion de bases de données, offrant une flexibilité et une accessibilité jusqu’alors inédites. Une idée qui ne date d’ailleurs pas d’hier…

L’évolution de l’« informatique en nuage »

Le concept de l’informatique en nuage, plus connu sous le nom de cloud computing, bien que largement popularisé au début des années 2000, puise ses racines dans les années 1960. À cette époque, des pionniers de l'informatique envisageaient déjà l'idée de rendre la puissance de calcul accessible comme d’utilité publique. Durant les années 1990, les schémas réseaux ont commencé à utiliser l'image d'un "nuage" pour représenter Internet, symbolisant la complexité et l'interconnexion des réseaux qui permettent aujourd'hui au cloud computing de fonctionner comme une architecture mondiale et flexible.

La véritable force du cloud réside dans sa capacité à fournir des ressources informatiques distantes et évolutives, permettant aux entreprises de simplifier la gestion de leur infrastructure, d'éviter le gaspillage de ressources, et d'améliorer l'efficacité énergétique à travers trois piliers :

• Unification de la facturation : Le cloud propose un système de facturation unique qui simplifie la gestion des coûts pour les entreprises. Cette transparence permet de suivre précisément les dépenses et d'optimiser les coûts ;
• Accès centralisé et sécurisé : Le cloud offre une interface unique qui simplifie l'accès aux services, tout en centralisant la gestion. Les systèmes IAM (Identity and Access Management) assurent une sécurité renforcée avec des outils d'auditabilité pour une meilleure conformité ;
• Marketplace riche et diversifiée : Le cloud met à disposition une vaste place de marché, permettant aux entreprises d'accéder à un large éventail de produits et services. Cette diversité favorise la flexibilité et la scalabilité des solutions déployées.

Comment définir simplement le cloud computing ?

En termes simples, le cloud computing se définit comme l'accès à distance à des ressources informatiques partagées, sans la complexité de gérer l'infrastructure physique sous-jacente. Cette approche permet aux entreprises d'investir à long terme dans la pérennité de la gestion et de l'hébergement de leurs données, tout en leur offrant la flexibilité nécessaire pour ajuster rapidement leurs capacités selon leurs besoins. Par exemple, Clever Cloud automatise cette scalabilité, optimisant les ressources en temps réel pour répondre à la demande.

Comment fonctionne le cloud computing ?

Reposant sur un modèle de services informatiques via réseaux, le cloud permet aux entreprises d'accéder à des ressources telles que le stockage de données, la puissance de calcul, et l’accès à un catalogue d’applications en ligne, sans la nécessité de gérer directement l'infrastructure matérielle. Cette approche offre une flexibilité accrue, une optimisation des coûts, et une efficacité opérationnelle qui favorisent l'innovation.

Les éléments clés du fonctionnement du cloud

Plusieurs éléments fondamentaux assurent l’efficacité et l’évolutivité du cloud. Voici un aperçu des éléments clés qui le composent.

L'infrastructure matérielle

Au cœur du cloud, se trouve une infrastructure physique composée de serveurs, de systèmes de stockage, et de réseaux interconnectés. Ces infrastructures sont présentes dans des centres de données répartis à travers le monde, promettant une très haute disponibilité, une sécurité renforcée, et une performance optimale. Les fournisseurs de cloud comme Clever Cloud investissent massivement pour maintenir des standards de qualité élevés, vérifiés à travers différentes certifications.

La virtualisation

Ce principe fondamental permet de créer des versions virtuelles de ressources physiques, comme des serveurs ou des systèmes de stockage. La virtualisation améliore l'efficacité en permettant à plusieurs utilisateurs ou applications d'exploiter les mêmes ressources de manière optimisée : les fameuses Virtual Machines (VM) . Cette technologie simplifie également la gestion et réduit les coûts d'exploitation en déconnectant l'infrastructure matérielle de l'expérience utilisateur.

Les interfaces d'accès et API

Les interfaces des services cloud sont conçues pour être sécurisées et performantes, facilitant la gestion des ressources et le déploiement d'applications. Les API offrent aux administrateurs systèmes, DevOps et développeurs la possibilité d'automatiser et d'intégrer des services cloud dans leurs propres systèmes, maximisant ainsi la personnalisation, l'efficacité, la flexibilité et élargissant les fonctionnalités possibles.

Les différentes architectures cloud : public, privé et hybride

Chaque architecture cloud présente ses propres avantages et s'adresse à des besoins différents. La clé est de choisir celle qui s'aligne le mieux avec les objectifs stratégiques et les contraintes opérationnelles propres à votre organisation.

Cloud public : l’accessibilité et scalabilité simplifiées pour l’hébergement de données

Le cloud public est l'architecture la plus courante. Ici, les ressources informatiques y sont hébergées sur des serveurs appartenant à des fournisseurs de services cloud, comme Clever Cloud. Ces services sont accessibles via réseau, offrant une solution évolutive et particulièrement scalable, capable de s'adapter rapidement aux besoins changeants des entreprises.

Le cloud public propose différents niveaux de services, allant de l'Infrastructure as a Service (IaaS) à la Platform as a Service (PaaS), en passant par le Software as a Service (SaaS). Cette diversité permet aux entreprises de choisir la solution la plus adaptée à leurs besoins, tout en bénéficiant de l'absence d'investissement initial dans l'infrastructure.

Cloud privé : l’hébergement de données contrôlé et sécurisé

Le cloud privé est une solution dédiée à une seule organisation, par définition. Contrairement au cloud public, les serveurs du client lui sont dédiés. Il s’agit souvent d’une zone d’hébergement derrière le pare-feu du client, mise à disposition par un fournisseur de cloud. Cette architecture offre un contrôle total sur les données et une sécurité renforcée, ce qui est idéal pour les secteurs soumis à des régulations strictes (financier, santé, pharmaceutique, public, défense, juridique, industriel, etc.). Le cloud privé permet une personnalisation accrue de l’architecture d’hébergement de données, adaptée aux besoins spécifiques de l'entreprise.

Cloud hybride : ne pas mettre tous ses œufs dans le même panier

Le cloud hybride permet de gagner en résilience en combinant les avantages du cloud public et privé. En diversifiant les environnements, les entreprises évitent de mettre tous leurs œufs dans le même panier. Par exemple, elles peuvent stocker leurs données sensibles dans un cloud privé tout en utilisant un cloud public pour les sauvegardes ou les charges de travail moins critiques. Cela permet de basculer d'un environnement à l'autre selon les besoins en termes de performance, de coût ou de sécurité. Cependant, avec les frais de sortie (egress fees) élevés des hyperscalers, cette approche peut devenir coûteuse.

En réalité, le cloud hybride est déjà une pratique courante, souvent sans que les entreprises en aient pleinement conscience. Depuis la démocratisation du SaaS, la majorité des applications ne sont plus uniquement en on-premise, mais reposent sur un mix de cloud public, cloud privé et services SaaS.

Quels sont les différents types de cloud computing ?

Le cloud computing est divisé en plusieurs catégories principales : Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) et le Function as a Service (FaaS). Chaque type offre des niveaux de contrôle, de flexibilité et de gestion différents, permettant à chacun de choisir celui qui répond le mieux à ses besoins.

Infrastructure as a Service (IaaS) pour une personnalisation  maximale

L'Infrastructure as a Service (IaaS) est historiquement le modèle le plus répandu du cloud computing. Avec l'IaaS, les entreprises louent des ressources informatiques telles que des serveurs, des machines virtuelles, du stockage et des réseaux directement auprès d'un fournisseur de services cloud.  Les clients  s’occupent du maintien en conditions opérationnelles de leur OS, des bases de données, des runtimes, etc. grâce à des administrateurs systèmes, présents en interne ou chez un infogéreur. Cela permet aux entreprises d’avoir une architecture spécifique répondant à leur besoin. 

Platform as a Service (PaaS) pour un déploiement rapide et une mise à jour automatique

Le Platform as a Service (PaaS) va un cran plus loin que l'IaaS en fournissant un OS, le middleware,  une console permettant de facilement déployer des runtimes voire même des bases de données ou des services tiers, que l’on appelle add-ons. Le client n’a plus à se préoccuper du maintien en condition opérationnelle (MCO), c’est à la charge du fournisseur de cloud. 

Les solutions PaaS facilitent le déploiement rapide des applications, tout en assurant la maintenance et la mise à jour automatiques de l'infrastructure. Avec des outils de développement intégrés et une architecture modulable, Clever Cloud simplifie le travail des développeurs et des DevOps en leur offrant un environnement prêt à l'emploi pour accélérer l'innovation : déployez du code, on se charge du reste ! 

Software as a Service (SaaS) pour plus de simplicité

Le Software as a Service (SaaS) est le modèle le plus courant du cloud computing. Les applications SaaS sont hébergées et gérées par des fournisseurs de services, permettant aux utilisateurs d'y accéder via Internet, généralement sur abonnement. Ce modèle élimine le besoin d'installer et de maintenir des logiciels localement, ce qui réduit les coûts et la complexité technique.

Le SaaS est particulièrement utile pour les entreprises cherchant à standardiser leurs outils logiciels sans investir dans l'infrastructure IT. Par exemple, les outils de collaboration, les systèmes de gestion de la relation client (CRM) et les suites bureautiques sont souvent déployés sous forme de services SaaS pour une simplicité maximale.

Functions as a Service  (FaaS) pour une grande agilité

Le Functions as a Service (FaaS), est une évolution du modèle PaaS qui permet aux développeurs de créer et de déployer des fonctions individuelles sans se soucier de la gestion des serveurs. Le fournisseur de cloud s'occupe de l'ensemble de l'infrastructure, de la mise à l'échelle et de la gestion des ressources, ne facturant que le temps d'exécution des fonctions.

Les fonctions sont déclenchées suite à des événements définis à l’avance, permettant à la fonction de lancer son action (traitement d’une image, conversion d’un fichier, etc.) et donc de s’allumer, d’être active le temps de l’action puis de s'éteindre. services pour des questions économiques. Le FaaS est souvent complémentaire d’un PaaS. 

Quels sont les avantages du cloud computing ?

Que ce soit en matière de scalabilité et de sécurité, le cloud offre de nombreux bénéfices pour les organisations qui décident de l’adopter, dont voici les principales.

Optimisation des coûts : une approche stratégique plutôt que de simples économies

Le cloud computing peut répondre à une stratégie financière, notamment en transformant les dépenses d'investissement (CAPEX) en dépenses opérationnelles (OPEX). Cette transition budgétaire permet aux entreprises d’externaliser leurs coûts initiaux liés à l'infrastructure informatique (achat des serveurs, entretiens des datacenters, maintenance, gestion de la fibre, recrutement d’une équipe dédiée, etc.). Les organisations peuvent adopter un modèle de paiement à l'usage, ajustant ainsi leurs dépenses en fonction de leurs besoins réels. Certains hyperscalers vont tout de même proposer de payer des instances réservées, qui seront à payer même si elles ne sont pas utilisées mais il ne s'agit pas de la majorité des usages. 

Scalabilité : le cloud s’adapte à vos besoins

Que ce soit pour augmenter la capacité de traitement lors d'un pic d'activité ou pour réduire les ressources pendant les périodes creuses, le cloud se veut flexible et scalable à la demande, grâce à des sondes et des orchestrateurs. Cette réactivité garantit une utilisation optimale des ressources et offre aux entreprises une agilité accrue pour faire face aux évolutions du marché et de la demande. Chez Clever Cloud, la scalabilité est automatique, ce qui signifie qu’elle s’adapte en temps réel à vos besoins et vous permet de ne payer que ce que vous consommez réellement.

Sécurité : un pilier capital pour les entreprises

Le cloud computing améliore grandement la sécurité de vos données. Les clouds providers investissent, assurent une veille constante et ont pour rôle d’avertir leur clients ou de mettre à jour les zones exposées. Le stockage dans le cloud et ses sauvegardes permettent une grande résilience. Il est facilement possible d’accéder aux  données sauvegardées ou de lancer un PRA ou un PCA. Chez Clever Cloud, nous allons même plus loin : nos bases de données Materia sont automatiquement répliquées sur  nos trois datacenters parisiens, ce qui vous assure une grande tranquilité d’esprit. Autre point capital : de nombreuses certifications de sécurité peuvent être demandées lorsque l’on héberge des données critiques ou personnelles. Les fournisseurs de clouds s’engagent à les respecter. 

Accessibilité : l’instantané comme répondre aux nouvelles tendances de travail

Le cloud computing favorise l’accessibilité à vos données, permettant à vos équipes de collaborer efficacement, peu importe leur localisation. Les données et les applications hébergées dans le cloud peuvent être disponibles 24/7. Ce qui facilite le télétravail, accélère les processus de prise de décision et améliore la productivité des équipes, tout en garantissant une synchronisation en temps réel des informations.

Mises à jour automatiques et maintien en condition opérationnelle

Avec le cloud computing, les mises à jour logicielles et les correctifs de sécurité sont automatiquement gérés par le fournisseur, sans intervention de l'équipe informatique du client. Cela permet non seulement de réduire la charge de travail interne, mais aussi de garantir que les systèmes n’ont pas de failles de sécurité.

Qui utilise le cloud computing ?

Le cloud computing est désormais une composante essentielle pour les entreprises de toutes tailles et de tous secteurs. Son adoption massive est motivée par l'externalisation de la gestion et du MCO, par l’unification des coûts et par l’accès à une marketplace.  Que ce soit pour le stockage et la sauvegarde de données, l'analyse de Big Data, l’hébergement de serveurs mails ou encore le développement et le déploiement d'applications web, le cloud est devenu incontournable pour répondre aux exigences croissantes du marché.

À titre d’exemple, les organisations du secteur financier utilisent le cloud computing pour détecter et prévenir les fraudes en temps réel, en s'appuyant sur des algorithmes de machine learning et des analyses prédictives. Les entreprises de santé, quant à elles, exploitent ces technologies pour offrir des traitements plus personnalisés, améliorant ainsi la qualité des soins pour leurs patients. Le secteur du divertissement et les créateurs de jeux vidéo s'appuient sur le cloud pour diffuser leurs contenus à des millions d'utilisateurs dans le monde entier, garantissant une expérience fluide et immersive.

Mais cette technologie n'est pas réservée aux grandes entreprises : PME, startups, freelance et particuliers adoptent également le cloud pour bénéficier d'une infrastructure évolutive sans avoir à supporter les coûts élevés liés aux datacenters physiques. En optant pour ces solutions, elles peuvent se concentrer sur leur besoin.

Quelles sont les utilisations du cloud computing ?

Le cloud computing offre une multitude d'utilisations pour les entreprises et les particuliers, dont voici les principales.

Stocker et sauvegarder des données

Le cloud permet aux entreprises de protéger leurs informations tout en bénéficiant d'une grande capacité de stockage, et ce, tout en gardant un contrôle sur la facturation. Les données peuvent être facilement accessibles depuis n'importe quel appareil connecté, ce qui facilite la récupération en cas de problème technique.

Héberger des applications, des sites web

L'hébergement d'applications et de sites web est une autre utilisation clé du cloud computing permettant de créer et déployer des applications tout en bénéficiant d’une grande scalabilité. Les développeurs bénéficient ainsi d'une solution fiable pour offrir une expérience utilisateur fluide et performante.

Diffuser des logiciels et des contenus as a service

Le cloud computing facilite également le développement de logiciels et de contenus sous forme de services (SaaS). Ce modèle réduit les besoins en installations locales et permet aux entreprises de proposer des mises à jour régulières sans interruption de service, accessible à tout moment et sur tout type d’appareil. Elles peuvent se concentrer sur l'amélioration continue de leurs produits tout en simplifiant la gestion des versions logicielles.

Analyse de données et intelligence artificielle (IA)

L'analyse de données et l'intégration de l'intelligence artificielle (IA) sont rendues possibles grâce aux capacités et performances du cloud computing. Les entreprises peuvent centraliser leurs données dans des systèmes cloud, comme des datalakes ou des data warehouse  et utiliser et entraîner des services de machine learning pour en extraire des éléments souhaités. Ces technologies aident à développer des modèles prédictifs, à automatiser des processus, générer du texte ou des images , etc.

Test et développement d'applications

Le cloud est également un outil puissant pour le test et le développement d'applications. Grâce à la standardisation des environnements de tests, il est désormais possible d’obtenir des espaces dédiés en quelques clics, et permet aux équipes de développeurs de gagner du temps. Les infrastructures cloud offrent une forte flexibilité pour créer, tester et déployer des applications tout en facilitant l'intégration continue et le déploiement continu (CI/CD). Cette approche accélère le cycle de développement et permet aux entreprises de réduire leur time to market.

Edge computing et cloud computing : les différences

Le cloud computing et l'edge computing sont deux architectures distinctes qui répondent à des besoins différents. Alors que le cloud computing centralise les ressources et les traitements dans de grands datacenters, l'edge computing déplace ces opérations au plus près des sources de données grâce à des infrastructures de petites tailles.

Cette approche permet à l'edge computing de réduire la latence et d'améliorer la rapidité de traitement, un atout essentiel pour des applications telles que l'Internet des objets (IoT), les véhicules autonomes et la réalité augmentée. Le choix entre ces deux technologies dépend souvent du contexte et des exigences de performance, de sécurité et de connectivité. L’edge computing permet aussi de proposer une architecture hybride, qui peut prendre le relai en cas de problématique de disponibilité.

Le cloud computing se distingue par sa capacité à offrir des ressources évolutives et mutualisées, accessibles via Internet, ce qui en fait une solution idéale pour des applications nécessitant une grande puissance de calcul et de stockage. En revanche, l'edge computing privilégie un traitement local pour des réponses en temps réel, réduisant ainsi les dépendances vis-à-vis de la connectivité réseau.

Quand choisir l’edge computing plutôt que le cloud computing ?

Choisir entre edge computing et cloud computing dépend de plusieurs facteurs clés :

• Réactivité et faible latence : L'edge computing est la meilleure solution lorsqu'une réponse instantanée est cruciale. Par exemple, pour les systèmes de contrôle industriel ou les véhicules autonomes, chaque milliseconde compte. Le traitement local des données par l'edge computing réduit les délais et améliore la fiabilité des opérations ;
• Volume de données à traiter : Lorsque le volume de données généré est trop important pour être transféré rapidement vers un datacenter central, l'edge computing devient indispensable. Il permet de filtrer et de traiter les données à la source, minimisant ainsi le trafic réseau et optimisant l'utilisation de la bande passante ;
• Environnements isolés ou à connectivité limitée : Dans des zones où la connexion à Internet est instable ou inexistante, l'edge computing assure le traitement des données sans interruption. Cela en fait une solution idéale pour des sites distants, comme les installations industrielles ou les infrastructures critiques ;
• Sécurité et confidentialité des données : L'edge computing offre un niveau de sécurité supplémentaire en traitant les données localement, ce qui limite leur exposition aux cybermenaces potentielles. Ce point est particulièrement important pour les secteurs sensibles, comme la santé ou les services financiers.

Ainsi, bien que le cloud computing soit adapté aux tâches nécessitant de vastes ressources et une accessibilité globale, l'edge computing s'impose dans les contextes où la rapidité, la localité et la sécurité des données sont primordiales.

On-premise et cloud computing : les différences

L’évolution des infrastructures informatiques a mené à deux principales approches : le on-premise et le cloud computing. Ces deux solutions présentent des différences fondamentales en termes de déploiement, de gestion, de coûts et d'évolutivité. Le on-premise implique d’acheter, d'installer et de gérer le matériel et les logiciels directement sur les serveurs de l'entreprise grâce à une équipe formée, offrant ainsi un contrôle total sur les données, le réseau et la sécurité. En revanche, le cloud computing repose sur l’externalisation de ces tâches afin de laisser l’entreprise se concentrer sur son cœur de métier.

Quand choisir du on-premise plutôt que le cloud computing ?

Opter pour une infrastructure on-premise peut être un choix stratégique, tant d’un point de vue budgétaire, technique que RH. Si l’entreprise souhaite payer et amortir ses investissements, contrôler l’ensemble de la chaîne de valeurs  et est en capacité de recruter et garder ses talents, le choix de l’on-premise peut à fait lui convenir. Si elle souhaite se concentrer sur son coeur de mieux, elle se tournera plus facilement vers le cloud computing afin d’externaliser cette charge à un prestataire dont c’est le métier. 

Le futur du cloud computing

Le cloud computing continue d'évoluer à une vitesse fulgurante, et son potentiel ne cesse de se développer. Nous sommes à l'aube d'une ère où les technologies de pointe comme l'intelligence artificielle (IA), l'informatique quantique et l'edge computing vont redéfinir les paradigmes actuels du cloud. Ce futur promet une intégration accrue des plateformes low-code et no-code, ainsi qu'une adoption massive de l'Internet des Objets (IoT), permettant aux entreprises et développeurs de concevoir des solutions innovantes sans forcément bénéficier d’une expertise technique avancée.

Une mise à jour mineure, des conséquences plus importantes

L'incident global a commencé après que nous ayons lancé une mise à jour mineure de maintenance d'Apache Pulsar (3.3.1). Elle activait un nouvel algorithme d'équilibrage pour l'optimisation du placement des bundles, qui a causé des problèmes. Nous l'avons rapidement détecté, avons conservé la version 3.3.1 et annulé la configuration défectueuse.

Le problème initial, bien que résolu, a entraîné un conflit de métadonnées. Nous avons dû arrêter tous les brokers de messagerie pour n'en démarrer qu'un seul, afin d'éviter tout conflit de métadonnées entre eux, et avons réussi à revenir à une situation nominale. Mais par la suite, notre infrastructure a subi une pression sur les entrées/sorties (E/S) et la mémoire, provoquant le plantage de certains hyperviseurs.

L'indisponibilité de la couche de messagerie Apache Pulsar a entraîné la mise en mémoire tampon de certains agents de télémétrie sur les machines virtuelles (VM) fonctionnant sur des hyperviseurs (HV). Elle a commencé alors que les endpoints du service de messagerie étaient indisponibles. 

Les limites de nos plus petites machines virtuelles 

Les petites machines virtuelles ont rapidement atteint une limite de mémoire, déclenchant une forte pression sur le noyau. Lorsque cela se produit, le noyau tente de vider la mémoire et les caches, de supprimer les processus de la mémoire pour les charger instruction par instruction à partir du disque. Cela génère une forte pression sur les E/S disque de l'hyperviseur sous-jacent. Quelques minutes après l'augmentation de la charge des HV, nous avons commencé à observer des “paniques” du noyau sur certains d'entre eux.

Les petites machines virtuelles étant réparties globalement entre nos zones de disponibilité, nous nous sommes retrouvés avec une infrastructure de serveurs surchargée. Alors que nous avions besoin du scheduler pour gérer la situation, le control plane ne fonctionnait pas de manière optimale et l'infrastructure avait du mal à fournir les ressources disponibles.

Nous avons donc dû arrêter tous les services non critiques et notre équipe SRE a redéployé une à une les petites machines virtuelles surchargées. Nous avons alors commencé à reprendre le contrôle de tous les hyperviseurs et avons pu ramener notre infrastructure à son état optimal.

Les prochaines étapes

Pour les versions non mineures, nous utilisons un processus de simulation qui émule un environnement complet dans lequel nous injectons des changements. Cela permet de valider les mises à jour et les changements en observant le comportement de l'infrastructure avant de passer en production. Ce processus n'était pas utilisé pour les mises à jour de maintenance mineures ou les (apparemment) petits changements du profil de configuration.

Cet incident nous a beaucoup appris et nous avons identifié quelques domaines de progrès concernant nos images, la configuration et l'intégration des outils, ou la configuration des petites machines virtuelles. Nous avons pris des mesures immédiates et travaillerons sur des sujets plus approfondis dans les semaines à venir. 

Nous nous excusons sincèrement pour les désagréments que cet incident a pu causer. Votre confiance est primordiale pour nous, et nous nous engageons à vous fournir le plus haut niveau de fiabilité de service. Vous pourrez en apprendre plus sur le calendrier et l'analyse technique de l'incident dans notre post-mortem public. 

Si vous avez des questions ou des inquiétudes, n'hésitez pas à contacter notre support.

Pour nous assurer que chaque Clever App ait assez de ressources pour fonctionner, nous utilisons les métriques comme indicateur pour augmenter ou non le nombre d'instances d'une application.

Ces métriques, comme toutes celles de notre infrastructure interne, sont stockées dans une base de données time serie. Avec une croissance de 2 To par semaine, nous devons penser au cycle de vie de chaque métrique. Puisque nous ne souhaitons pas la supprimer, nous avons mis en place une solution d'archivage automatisée à partir de Cellar.

Notre infrastructure

Avec plusieurs milliers d'applications clientes, et plusieurs centaines pour des usages internes, nous avions besoin d'un moyen permettant d’accepter des centaines de milliers de points par seconde.

En production depuis octobre 2023, notre cluster warp10-c2 permet de répondre à ce besoin. Basé sur Warp10 et grâce à sa couche de stockage utilisant FoundationDB, nous sommes capables de tenir la charge face à des piques d'ingestions de plus de 500 000 points/seconde tout en permettant de lire 5 millions de points/seconde.

Un cluster en constante linéaire

Bien avant de pouvoir mettre en place cette stratégie d’archivage, notre équipe data a été confrontée à bon nombre de problèmes depuis la mise en production de c2.

Tout d’abord, pendant les premières semaines, le cluster a subi des problèmes de performances. Afin de pouvoir se concentrer sur ces derniers, nous avons continuellement ajouté de l’espace de stockage physique. Dès lors que ces problèmes de stabilité furent résolus, en ajoutant des nœuds permettant d’augmenter notre capacité de stockage, nous avons fait face à de nouveaux problèmes de ressources. Cette fois-ci liés au CPU et à la RAM. Et puisque nous n’avons pas des ressources infinies, nous avons gagner en capacité de stockage sans perte d’informations.

Les strategies possibles

La solution la plus naïve serait de sélectionner continuellement toutes les séries et points, et de les réécrire dans Cellar sans apporter de changement. Bien que c2 soit capable de gérer des millions de lectures par seconde, nous parlons ici de milliards de points. Même avec des machines de requêtes dédiées, cela aurait entraîné des problèmes de performances provenant de notre couche de stockage. De plus, nous aurons un espace disque utilisé similaire à celui des données dans le stockage à chaud.

Une seconde manière de procéder serait de réduire la résolution des métriques, plutôt que d’avoir des informations avec une précision à la seconde, la réduire pour avoir la moyenne sur une heure ou une journée. Cette stratégie amène beaucoup plus de questions que de réponses, comme :

• Que faire des extremums dans une série, doivent-ils être supprimés ou conservés ? 
• Comment savoir depuis combien de temps une application fonctionne ?
• Doit-on appliquer cette stratégie sur nos applications internes, doit-on les traiter au cas par cas ?

Cette solution aurait exigé trop d’efforts dans un système qui aurait tout de même des défauts.

Enfin, la dernière stratégie consiste à utiliser l’extension Warp10 HFiles, une extension vendue par l'éditeur du logiciel permettant de générer des fichiers compacts de manière efficiente, avec des capacités de chiffrement. Cette solution peut nous aider à avoir un taux de compression fort en garantissant zéro perte, transformant des téraoctets de données en quelques dizaines de gigaoctets. Ce fort ratio de compression est notamment dû au fait que le nombre de valeurs qu’un point peut prendre est rarement infini, un pourcentage d’utilisation CPU par exemple ne peut avoir qu’un nombre fini de valeurs.

En février 2024, nous avons choisi cette troisième stratégie comme solution à notre problème. Cependant, nous avons dû mettre en place tout un workflow automatisé autour de cette extension afin de ne pas avoir à exécuter cette tâche manuellement chaque mois.

Automatiser le processus

Avant d’aborder la manière dont nous avons rendu cela possible, une brève introduction aux HFiles est nécessaire afin de mieux comprendre pourquoi nous avons procédé ainsi. Ensuite, nous explorons la mise en place de l’orchestrateur de workflow que nous utilisions pour automatiser le processus. Enfin, nous partagerons les chiffres du lancement de ce processus d’archivage.

Introduction aux HFiles de Warp10

Un "HFile" est une extension de fichier proposé par l’extension Warp10 HFiles. Le processus de génération d’un HFile est assez simple. Tout d’abord, nous l’extension va générer un cache local avec toutes les séries qui doivent être archivées en se basant sur des critères de sélection donnés par l’utilisateur. Pour chacune des séries, l’extension va récupérer tous les points dans une plage de temps spécifiée, tout en compressant continuellement ces points. Au travers de plusieurs expérimentations, nous savons que ce processus peut facilement prendre beaucoup de temps, parfois plusieurs jours. 

Cependant, avec des paramètres et des critères de sélection spécifiques, nous sommes capables de générer des HFiles en quelques heures. Ces générations sont synchrones, ce qui signifie que vous devez conserver une connexion HTTP ouverte avec la machine exécutant la génération.

Nous avons principalement ajusté trois paramètres afin d'optimiser le temps de traitement :

• Plage temporelle des points : elle permet de récupérer uniquement des points de données entre deux dates ;
• Parallélisation : puisqu’une génération peut prendre plusieurs heures, nous pouvons paralléliser plusieurs exécution afin d’optimiser une mieux nos capacités de génération ;

• Nombre de séries : parce que pour chaque série dans le cache, l’extension essaiera de récupérer les données liées (même si la série est vide dans la plage de temps spécifiée), réduire le nombre de série dans le cache permet de limiter le nombre de requêtes au système de stockage.

Que signifie une « série » ?

Une série, aussi appelée GTS (“Geo Time Serie”) dans le contexte de Warp10 est un nom unique sous lequel sont enregistrés des points de données. Une série est composée d’un nom de métrique et de labels permettant de donner du contexte. Par exemple, pour une Clever App, une série qui contient la consommation du processeur serait cpu.usage_guest{app_id='app_87e33fea-9dde-4a99-b347-674de382ff7b'}.

Dans notre cluster c2, nous avons plus de 150 millions de séries uniques.

L'orchestrateur de workflow

Pour permettre un archivage de manière automatisée, nous étions à la recherche d’un outil répondant aux contraintes suivantes :

• Planification : pour éviter de devoir déclencher l'action manuellement chaque mois ;
• Retry et failover : en cas d'échec d'une génération de HFile, il doit pouvoir réessayer, ou si un nœud du système crash, l’outil doit pouvoir reprendre la ou il s’était arrêté ;
• Alerting : lorsque plusieurs tentatives ne suffisent pas, nous devons être informé par un message Slack que le système n’a pas réussi de générer un HFile;
• Capacité à exécuter de longues tâches : comme nous le savons, nos générations peuvent prendre plusieurs heures, il ne faut donc pas que l’outil empêche cela.

Après avoir essayé plusieurs outils d’orchestration, notre avis final s’est placé sur Kestra. Un outil Open Source qui répond à toutes nos contraintes et à notre besoin. Déployé en tant que Clever App, nous avons pu mettre en place des workflows qui minimisent le temps de génération d’un HFile en utilisant nos paramètres optimisés. 

Fin février, nous avons terminé notre workflow complet de génération de HFile, comme le montre le schéma ci-dessus, il est plutôt simple, mais très efficace. Jusqu'à présent, il a été exécuté sur les données du mois de Novembre, sans supprimer les données. Il s’agissait d’un test qui nous a permis d’avoir suffisamment confiance en Kestra pour permettre de valider nos dernières interrogations. Nous avons ensuite exécuté la suppression manuellement, afin de s’assurer qu’il n’y ait pas d’effet de bord, ou d’oublis.

Aujourd’hui, la génération des HFiles et la suppression des données est complètement automatisée grâce à Kestra. Même si notre utilisation de l’outil est assez simple, nous avons l’ambition de l’utiliser pour de nouveaux cas à l'avenir.

Chiffres sur les métriques du mois de Novembre 2023

Début Mars, nous avons lancé notre premier archivage, avec succès. Cet archivage est basé sur le mois de Novembre puisque nous souhaitons garder 3 mois de mesures disponibles. 

Ce premier mois est particulier puisque c2 a été mis en production fin octobre, et toutes les applications clientes de Clever Cloud ont dû être redéployées pour utiliser le nouveau cluster. Cela signifie que les chiffres suivants comportent un nombre de séries et de points plus élevé que les mois qui suivront.

Nous avons archivé plus de 22 milliards de points provenant de plus de 33 millions de séries. Ces séries et points utilisaient environ 20 To d’espace disque. Une fois compressé, nous sommes rendus à 20 Go. Une chose importante à noter est que les données dans le cluster sont chiffrées, ce qui signifie que la taille d’un point est plusieurs fois celle du vrai point, puisque nous appliquons un algorithme de chiffrement.

Depuis quelques mois, les questions pour déployer depuis GitHub ou GitLab vers Clever Cloud se sont multipliées parmi nos clients. Les deux plateformes diffèrent sensiblement sur le sujet, mais sont celles massivement utilisées pour stocker leur code et collaborer.

Chez Clever Cloud, nous avons à cœur de fournir, une diversité de produits et de fonctionnalités à même de faciliter les déploiements et la maintenance des applications. Nous souhaitons améliorer constamment l'expérience de l'usage de la plateforme. Dans cet article, nous vous détaillons comment nous avons abordé le sujet de la CI/CD pour simplifier celle-ci.

Deux plateformes, des principes communs

Clever Cloud fournit une CLI pour déployer et gérer aussi bien les applications que les add-ons. Jusqu'à présent, nous avons suggéré à nos clients de l'utiliser pour construire leur CI/CD et déployer depuis GitHub ou GitLab. Toutefois, écrire une pipeline pour déployer depuis GitHub ou GitLab, même avec un outil facilitateur comme une CLI pour se connecter à Clever Cloud, est une tâche longue et fastidieuse. Surtout quand on est occupés à développer son application.

En gardant en tête l'un de nos principes fondateurs, à savoir, faciliter un maximum le travail des développeurs et des équipes IT, nous avons commencé à fournir des outils un peu plus poussés de CI/CD pour GitHub et GitLab.

Déployer depuis GitHub : aller plus loin avec des review apps

Les clients utilisant GitHub connaissent déjà notre intégration permettant de déployer depuis cette plateforme. En plus de cette intégration, n'importe qui pouvait utiliser la CLI pour personnaliser sa pipeline grâce aux GitHub Actions. Ces dernières permettent d'automatiser de nombreuses tâches, ce dont nous avons tiré profit sur notre projet public de documentation.

À partir de cette configuration, nous avons mis à disposition un template de workflow permettant de déployer des review apps depuis GitHub vers Clever Cloud. Ce script réalise les actions suivantes :

1. Créer et déployer une application sur Clever Cloud depuis la branche où la PR est ouverte, avec un nom de domaine de test ;
2. Mettre à jour l'application à chaque nouveau commit ;
3. Supprimer l'application à la fermeture de la PR.

Un commentaire poste le lien vers la review app à chaque nouveau déploiement, et annonce la suppression de l'app une fois ce job effectué.

Le script récupère les variables d'environnement et les secrets ajoutés à votre projet sur GitHub. Il est possible d'aller plus loin et d'y ajouter des commandes ; par exemple, pour connecter la review app à une base de données de test, vous pourriez ajouter la commande clever service link-addon <nom-de-l-addon>.

Ce template est en développement constant pour simplifier progressivement votre flux de travail et le rendre plus efficace. À terme, cette Action devrait fonctionner uniquement avec des inputs plutôt que des lignes de commandes. En attendant, n'hésitez pas à ouvrir une issue sur le projet en fonction de vos besoins.

Déployer depuis GitLab

Nos clients travaillant sur GitLab (en SaasS ou en instance autohébergée) ont également exprimé des besoins similaires pour automatiser leurs déploiements. GitLab diffère sensiblement de GitHub, avec une approche bien plus DIY de la CI/CD, et des configurations différentes. Sur GitLab, aucune variable ne permet la détection de l'état d'une Merge Request (ouverte ou fermée), contrairement à GitHub. Si nous souhaitons lancer un job automatiquement à sa fermeture, à la place, nous devrons utiliser l'état des environnements, et non celui des MR.

Chez Clever Cloud, nous avions déjà différentes pipelines de déploiement en place depuis GitLab pour certains projets. Nous avons unifié et simplifié leur usage en créant des composants de pipelines dans le catalogue CI/CD de GitLab. Les composants remplacent l'ancien catalogue de templates chez GitLab. Ils permettent de construire une pipeline modulaire à l'aide d'inputs. Plus besoin, donc, de personnaliser un fichier de script à la main.

Notre contribution au catalogue comporte actuellement quatre composants :

1. Déployer en production ;
2. Créer une review app depuis une Merge Request ;
3. Mettre à jour la review app ;
4. Supprimer la review app.

Les valeurs des inputs ont été prédéfinies pour vous faire économiser du temps lors de l'utilisation. Ces composants peuvent être utilisés aussi bien sur gitlab.com que sur votre instance auto-hébergée. Il n'y a rien à modifier dans le projet, mais quelques configurations de votre instance à vérifier.

Dans les deux cas, nous vous conseillons de tester le déclenchement manuel des composants sur votre projet, dans un premier temps. Nous ajouterons d'autres composants en fonction des besoins de nos clients, et sommes ouverts à vos propositions. Vous pouvez les soumettre directement sur le projet qui leur est dédié.

Le meilleur des deux mondes : Heptapod

Si vous utilisez le fork de l'édition Community de GitLab hébergé par nos soins, vous bénéficierez des avantages d'une offre GitLab as a Service, mais aussi d'un hébergement sur des serveurs européens et managés par une entreprise française.

Le catalogue de pipeline CI/CD est déjà intégré à notre offre Heptapod, vous permettant d'utiliser les composants directement dans votre projet, sans configuration de l'instance à réaliser.

Une pipeline simplifiée

Lors de vos déploiements, Clever Cloud intègre les phases de build, d'installation et de run. Vous n'avez qu'à pousser votre code, le processus est automatique. En incluant le déploiement sur Clever Cloud dans votre pipeline, vous obtiendrez ainsi les logs de votre application lors du déploiement et de ses différentes étapes directement dans la console du runner. Ainsi:

• Vous pouvez vous passer du job de build dans votre pipeline, notre plateforme s'en charge déjà
• Vous pouvez surveiller votre pipeline et ses logs directement depuis GitHub, GitLab ou Heptapod, du début à la fin

Le déploiement échoue ? Pas d'inquiétude, votre app restera en ligne avec le dernier commit poussé avant votre mis à jour. Vos utilisateurs ne le remarquerons même pas.

Les deux projets étant en développement constant, nous prévoyons d'aller encore plus loin dans l'ajout de souplesse et d'agilité à vos processus de déploiements. Nous restons ouverts à vos propositions !

Si l'IA fait parler d'elle ces derniers temps, c'est notamment au travers des larges modèles de langages (LLMs) qui nécessitent une puissance de calcul conséquente pour leur entrainement ou leur exécution. Ainsi, il est courant de voir les développeurs y recourir à travers des API clés en main, comme nous l'avions fait dans un précédent article. Mais cela change grâce à des modèles et outils plus ouverts et efficaces, que vous pouvez très facilement déployer sur Clever Cloud.

En effet, si notre plateforme a été pensée pour certains usages, nous avons toujours accordé une grande importance à sa flexibilité et à la liberté laissée à nos clients. Ils peuvent ainsi aisément l'exploiter pour attaquer de nouveaux marchés, avec très peu de travail d'adaptation.

Pour le vérifier, nous avons récemment tenté de déployer des modèles d'IA open source tels que ceux dérivés de LLaMA et Mistral. Ils ont pour particularité d'exister dans des versions allégées, ne nécessitant pas forcément de GPU pour fonctionner. Ainsi, il est possible de les héberger comme de simples applications Clever Cloud, tant qu'assez de mémoire leur est attribuée.

Let's ollama (avec une interface web) !

Pour cela, nous avons choisi d'utiliser ollama, un projet sous licence MIT qui permet de télécharger des modèles disponibles depuis un registre ou même les vôtres. Il prend la forme d'un serveur qui communique via une API, très simple à héberger sur nos infrastructures.

• Créer un compte Clever Cloud (et obtenir 20 euros de crédits)

Pour commencer, vous devrez disposer d'un compte Clever Cloud. Vous pouvez créer l'application et suivre les étapes suivantes en utilisant notre interface web, la Console, mais aussi à travers notre CLI open source : Clever Tools. C'est ce que nous ferons ci-dessous.

Nous partirons ainsi du principe que vous disposez d’une machine avec git et Node.js dans une version récente. Si vous n’avez pas encore installé les Clever Tools sur votre système, tapez (avec les droits administrateur de votre système ou sudo si nécessaire) :

npm i -g clever-tools
clever login

Une fois connecté, vous pourrez vérifier que tout s’est bien passé avec la commande suivante :

clever profile

Ensuite, nous créons une application Clever Cloud avec Node.js. Elle installera ollama pour télécharger et exécuter nos modèles, en lui ajoutant avec une interface web (chatbot-ollama, également sous licence MIT) qui nous permettra d'interroger le serveur depuis n'importe quel navigateur, exécuté depuis un ordinateur ou même un simple smartphone.

Cette solution a également l'intérêt de stocker les conversations localement, dans le navigateur. Elle ne nécessite donc pas de base de données, mais propose une fonction d'import/export. On peut également choisir entre différents modèles, régler certains de leurs paramètres, configurer des instructions système, différents prompts, etc.

mkdir myollama && cd myollama
git init
curl -L https://github.com/ivanfioravanti/chatbot-ollama/archive/refs/heads/main.tar.gz | tar -xz --strip-components=1

clever create -t node myollama && clever scale --flavor L
clever env set CC_POST_BUILD_HOOK "npx next telemetry disable && npm run build"
clever env set CC_PRE_BUILD_HOOK "./ollama_setup.sh"
clever env set CC_PRE_RUN_HOOK "./ollama_start.sh"

echo "orca-mini" > models.list
echo "mistral" >> models.list
echo "codellama" >> models.list

Le code ci-dessus créé l'application. Nous y ajoutons un fichier qui contiendra la liste des modèles à récupérer lors de son initialisation. Nous optons pour une instance L, la taille minimale pour charger de tels modèles en mémoire. On déclare ensuite plusieurs variables d'environnement pour lancer des scripts afin d'installer ollama, démarrer le serveur et désactiver la télémétrie du framework Next.js, utilisé pour construire l'interface web après l'installation des dépendances.

Ajoutons quelques scripts

Notre application est presque prête. Il nous reste en effet à créer deux fichiers, exécutables :

touch ollama_setup.sh && chmod +x ollama_setup.sh
touch ollama_start.sh && chmod +x ollama_start.sh

ollama_setup.sh télécharge le binaire d'ollama puis les modèles de notre liste. Ouvrez-le avec l'éditeur de votre choix et placez-y le contenu suivant :

#!/bin/bash

# We define the folder (in $PATH), where the ollama binary will be placed
BIN_DIR=${HOME}/.local/bin
mkdir -p ${BIN_DIR} 

ollama_start() {
    echo "Downloading and launching ollama..."
    curl -Ls https://ollama.ai/download/ollama-linux-amd64 -o ${BIN_DIR}/ollama
    chmod +x ${BIN_DIR}/ollama
    ollama serve &> /dev/null &
    echo -e "Finished: \033[32m✔\033[0m\n"
}

get_models() {
    MODELS_FILE="models.list"
    MODELS_DEFAULT="orca-mini"

    # We check if the models file exists
    if [ ! -f ${MODELS_FILE} ]; then
        echo "File ${MODELS_FILE} not found, ${MODELS_DEFAULT} used by default."
        echo ${MODELS_DEFAULT} > ${MODELS_FILE}
    fi

    # Loop through each line and pull model
    while IFS= read -r line; do
        echo "Pulling ${line} model..."
        ollama pull "${line}" > /dev/null 2>&1
        echo -e "Finished: \033[32m✔\033[0m\n"

    done < ${MODELS_FILE}
}

# We start ollama, and wait for it to respond
ollama_start
if [ $? -ne 0 ]; then
    echo -e "\nError during ollama setup."
    exit 1
fi

count=0
MAX_TIME=10

while ! pgrep -x "ollama" > /dev/null; do
    if [ ${count} -lt ${MAX_TIME} ]; then
        sleep 1
        count=$((count+1))
    else
        echo "Application 'ollama' did not launch within 10 seconds."
        exit 1
    fi
done

get_models
if [ $? -ne 0 ]; then
    echo -e "\nError during models downloading."
    exit 1
fi

Ce code peut paraître un peu long, mais c'est notamment parce que nous l'avons rendu modulaire, en n'écrivant dans les logs que les étapes réussies ou les éventuelles erreurs.

ollama_start.sh détecte si le serveur ollama est déjà présent avant de démarrer l'interface web. Si ce n'est pas le cas, on le lance en tâche de fond (nous verrons plus bas pourquoi).

Ouvrez-le avec l'éditeur de votre choix et placez-y le contenu suivant :

if ! pgrep -f "ollama" > /dev/null; then
    # If 'ollama' is not running, start it in the background
    ollama serve &
    echo "Application 'ollama' started."
else
    # If 'ollama' is already running
    echo "'ollama' application is already running."
fi

Une fois ces deux fichiers créés, on peut déployer notre application :

git add . && git commit -m "Init application"
clever deploy
clever domain

Vous verrez alors le domaine pour accéder à votre application (que vous pouvez personnaliser).

Cache et (re)démarrage rapide

Utiliser Clever Cloud, ce n'est pas simplement déployer facilement une telle application, disposer de logs et de monitoring, pouvoir changer instantanément son scaling horizontal et/ou vertical. C'est aussi pouvoir en faire une image prête à redéployer très rapidement.

En effet, toute application que nous hébergeons est stockée sous la forme d'une archive constituée juste avant l'installation des dépendances. Elle peut ainsi être arrêtée et de rédémarrée sous cette forme, ce qui nous permet de ne pas retélécharger les modèles à chaque fois. Pour cela, il suffit d'indiquer les dossiers à ajouter à l'archive :

clever env set CC_OVERRIDE_BUILDCACHE "/:../.ollama/:../.local/bin/"
clever restart --without-cache --follow

L'application redémarrera, mais prendra cette fois les l'interface web construite, ollama et les modèles dans son cache, les étapes CC_PRE_BUILD_HOOK et CC_PRE_BUILD_HOOK n'étant pas exécutées. C'est notamment pour cela que nous devons nous assurer que l'on démarre bien le serveur ollama avec CC_PRE_RUN_HOOK, mais que l'on vérifie que cela n'a pas déjà été fait lors d'un démarrage classique; où il est utilisé pour télécharger les modèles avant de les exécuter.

Dès que cette étape est terminée, vous pouvez arrêter l'application et la redémarrer lorsque vous voulez, cela sera désormais bien plus rapide. Et vous ne serez facturé que le temps de son usage, à la seconde. Si vous voulez modifier la liste des modèles à utiliser, faites le dans le fichier prévu à cet effet, un git push suffira à reconstituer le nouveau cache.

# Stop/Restart the application
clever stop
clever restart

# After a modification in models.list, git push to recreate the cache
git add models.list && git commit -m "New models" 
clever deploy

Vous retrouverez le fichiers nécessaires à ce projet dans ce dépôt GitHub, avec les variables d'environnement prêtes à importer (clever env import < .env).

Et si jamais vous voulez aller plus loin en déployant d'autres modèles et outils pour vos applications, qui nécessitent plus de puissance et/ou du GPU, faites-le nous savoir !

Clever Cloud est aujourd'hui le principal développeur de Sōzu, un Reverse Proxy créé par nos soins, en Rust, pour répondre aux besoins de notre infrastructure en termes de performance et de rechargement à chaud. Sōzu est utilisé sur tout le périmètre Clever Cloud, associé à HAProxy, pour acheminer le trafic vers les applications de nos clients.

Ce que nous faisions :

Jusqu'à présent, notre Reverse Proxy Sōzu était géré dans Clever Cloud à l'aide d'un programme propriétaire exécuté sur la même machine et assurant deux grandes responsabilités :

• Premièrement, écouter un topic RabbitMQ et rediriger les requêtes vers Sōzu (via sa socket UNIX).
• Deuxièmement, surveiller un dossier PKI (Public Key Infrastructure) pour rediriger les certificats TLS vers Sōzu (via sa socket UNIX).

Virage open source

Alors que nous travaillions sur un nouveau connecteur Prometheus pour Sōzu, nous nous sommes rendus compte que nous pouvions le rendre open source. C'est ainsi qu'est née l'idée de porter l'ancien gestionnaire de Sōzu (décrit ci-dessus) de son état propriétaire vers de nouveaux dépôts Open Source.
Notre objectif final est de développer un écosystème entièrement open-source autour de notre reverse proxy Sōzu.
Ce billet de blog décrit ces nouveaux composants open source et résume ce qu'ils font.

Notre écosystème Open Source autour de Sōzu

Connecteur Sōzu Prometheus

Prometheus est une suite logicielle de surveillance et d'alerte.
Ce connecteur simple fonctionne parallèlement à Sōzu. Il écoute les requêtes HTTP sur la route /metrics, demande à Sōzu ses métriques, les formate pour qu'elles soient compatibles avec Prometheus et les envoie dans la réponse HTTP.
Cela signifie que les métriques Prometheus sont facilement disponibles sur l'adresse IP d'une machine Sōzu.

Connecteur Sōzu Pulsar

Apache Pulsar est une plateforme de messagerie hautement évolutive. Nous l'apprécions chez Clever Cloud en raison de son aspect distribué et de ses performances de pointe en matière de débit.
Le connecteur Sōzu Pulsar s'abonne à un topic Pulsar et transmet des messages à Sōzu. Sōzu utilise ces messages pour effectuer un chargement à chaud sur le proxy, cette fonction est une caractéristique clé de notre Reverse Proxy.
Pour tout utilisateur de l'écosystème Sōzu, cela signifie que ce connecteur permet de mettre à jour la redirection du trafic en temps réel.

Connecteur Sōzu PKI

PKI signifie Public Key Infrastructure (infrastructure à clé publique), un cadre de sécurité omniprésent sur l'internet, généralement utilisé pour sécuriser les connexions avec HTTPS (entre autres). Dans le cadre du PKI, Sōzu fonctionne comme une terminaison TLS : il déchiffre le trafic HTTPS en trafic HTTP.
Le connecteur PKI de Sōzu fonctionne parallèlement à ce dernier, surveille un répertoire donné du système de fichiers, lit les certificats TLS qui y ont été placés par l'homme ou la machine et les transmet à Sōzu.
En résumé, cela signifie que si l'on écrit un certificat TLS sur la machine, Sōzu l'aura.

Client Sōzu

C'est une librairie utilisée par tous les connecteurs pré-cités. Elle poole les connections à la socket UNIX de Sōzu, et fonctionne de façon entièrement asynchrone. En somme, elle permet d'écrire de nouveaux connecteurs facilement.

Et la suite ?

La meilleure chose que nous puissions souhaiter serait que la communauté open-source se joigne à nous pour utiliser et améliorer Sōzu au fur et à mesure.

Nous espérons ainsi à terme construire une interface web pour gérer une instance de Sōzu dans le navigateur.

Lorsque j'ai commencé à travailler chez Clever Cloud, j'ai passé du temps à m'amuser pour me familiariser avec la plateforme et ses outils. Ce billet de blog vous présentera comment j'ai réussi à :

• créer une simple application Scala/Akka HTTP template avec persistance PostgreSQL
• lier l'application à un serveur PostgreSQL géré
• la déployer
• l'essayer !

Créer un modèle HTTP Scala/Akka 🔨

Obtenez les sources

Clonez le projet généré à partir du modèle de démarrage rapide Akka Github.

Ce service offre la possibilité de gérer un simple registre d'utilisateurs en mémoire exposant 4 routes :

• Lister tous les utilisateurs
• Obtenir un utilisateur spécifique
• Créer un utilisateur
• Supprimer un utilisateur

Une description complète des commandes cURL disponibles peut être trouvée ici.

Ajouter des fonctionnalités supplémentaires

Quelques fonctionnalités ont été ajoutées à l'exemple original :

• stocker le registre dans une base de données PostgreSQL (au lieu d'être en mémoire)
• lire les paramètres de la base de données à partir des variables d'environnement
• ajouter une basic auth codée en dur

Tous les paramètres peuvent être spécifiés dans le fichier application.conf :

• basic auth
• paramètres de la base de données

Les paramètres sont récupérés à partir des variables d'environnement, ou de la valeur par défaut spécifiée si aucune n'est trouvée.

app {
  basic-auth {
    user = "foo"
    user = ${?BASIC_AUTH_USER}
    password = "bar"
    password = ${?BASIC_AUTH_PASSWORD}
  }
  routes {
    # If ask takes more time than this to complete the request is failed
    ask-timeout = 5s
  }

  db {
    host = "localhost"
    host = ${?POSTGRESQL_ADDON_HOST}
    port = "5432"
    port = ${?POSTGRESQL_ADDON_PORT}
    database = "postgres"
    database = ${?POSTGRESQL_ADDON_DB}
    user = "login"
    user = ${?POSTGRESQL_ADDON_USER}
    pass = "pass"
    pass = ${?POSTGRESQL_ADDON_PASSWORD}
  }
}

Exécuter l'application en utilisant Clever Cloud CLI 🚀

Créez une application Clever Cloud

clever create --type sbt myakka --region par --org testorg

Cette commande crée une nouvelle application

• de type sbt pour Scala
• nommée myakka
• dans la région de Paris
• dans mon organisation de test testorg

Activer une instance de build dédiée pour un build plus rapide (pro tip optionnel)

Par défaut, une application nouvellement créée exécutera une instance XS qui est assez petite pour construire rapidement des applications Scala. Une façon de construire plus rapidement est d'utiliser une instance de build dédiée : Dans la console Clever Cloud, allez dans votre application -> options, et cochez la case [] Activer l'instance de build dédiée. De cette façon, vous pouvez conserver votre instance XS pour exécuter l'application, mais vous pouvez choisir une instance XL pour le temps de build. Ou avec l'outil de ligne de commande :

clever scale -a myakka --build-flavor XL

Créez une base de données PostgreSQL

clever addon -l myakka create postgresql-addon myakkadb

Cette commande commande une instance d'addon PostgreSQL et la lie à myakka, en injectant les bonnes variables d'environnement dans l'instance de l'application pour contacter la base de données.

La création et la migration de la base de données sont effectuées à l'aide de l'outil flywaydb. Ces scripts se trouvent dans le répertoire migration/db des ressources de l'application.

La migration sera automatiquement appelée une fois que vous aurez spécifié le hook de build approprié dans les variables d'environnement

CC_POST_BUILD_HOOK avec la valeur sbt flywayMigrate

clever env -a myakka set CC_POST_BUILD_HOOK "sbt flywayMigrate"

Configurer les variables d'environnement de la basic auth

Le login et le mot de passe de la basic auth peuvent être spécifiés comme variables d'environnement en utilisant la commande clever env. Si aucune variable n'est trouvée, la basic auth prendra par défaut les valeurs du fichier application.conf

clever env -a myakka set BASIC_AUTH_USER <YOUR_AUTH_USER>
clever env -a myakka set BASIC_AUTH_PASSWORD <YOUR_AUTH_PASSWORD>

Reliez votre repo local à votre instance d'application Clever Cloud.

Récupérez l'identifiant de votre application avec

clever applications

Liez ensuite le référentiel local à l'application (en créant un fichier .clever.json)

clever link app_<UUID>

Déployer

Vous êtes maintenant prêt à déployer et à exécuter votre code, il suffit d'exécuter

clever deploy

Vous pouvez maintenant suivre le processus de déploiement jusqu'à ce qu'il se termine avec succès.

Votre application fonctionne maintenant !

Essayez-la

Il est temps de l'expérimenter en utilisant curl ou votre interface graphique préférée.

Ajouter un utilisateur

Adaptez cette commande afin d'insérer un nouvel utilisateur dans le registre :

curl --request POST \
  --url https://app-<UUID>.cleverapps.io/users \
  --header 'Content-type: application/json' \
  -u '<YOUR_AUTH_USER>:<YOUR_AUTH_PASSWORD>' \
  --data '{
  "name": "Serge",
  "age": 42,
  "countryOfResidence": "Greenland"
}'

{
	"description": "User Serge created."
}

Récupérer tous les utilisateurs

Vérifiez que l'utilisateur a été correctement créé, en obtenant la liste des utilisateurs :

curl --request GET \
  --url https://app-<UUID>.cleverapps.io/users \
  -u '<YOUR_AUTH_USER>:<YOUR_AUTH_PASSWORD>'

{"users":[{"age":42,"countryOfResidence":"Greenland","name":"Serge"}]}

Ça marche, c'est un succès ! 🎉

Bonne nouvelle ! La procédure pour installer Matomo (anciennement Piwik) sur une instance Clever Cloud est désormais beaucoup plus simple ! Nous avons automatisé l'ensemble pour que vous n'ayez plus qu'à ajouter un add-on depuis la Console Clever Cloud.

Matomo est pour rappel un outil de mesure d'audience reconnu pour sa qualité, qui apporte des statistiques fiables et détaillées sur les visiteurs et leur parcours. Il vous permet de remplacer des solutions telles que Google Analytics dont l'utilisation est devenue illicite en Europe, du fait d'un transfert vers les États-Unis, en l’absence d’un consentement spécifique avant toute collecte de données.

Il y a quelques années, nous vous expliquions comment installer Piwik (devenu depuis Matomo) chez Clever Cloud, au sein de nos serveurs hébergés en France. La procédure nécessitait alors plusieurs étapes. Il suffit désormais d’ajouter un add-on via la Console. Vous profiterez alors de tous les avantages de notre plateforme en termes d’adaptation à la montée en charge, de facturation à la seconde, de maintien en conditions opérationnelles, de gestion simplifiée et de mise à jour.

Avant de vous expliquer comment faire, expliquons pourquoi.

Pourquoi imposer Google Analytics est devenu illégal en France

Dans un communiqué du 10 février, la CNIL a fait savoir à l’ensemble des éditeurs de sites et applications français qu’ils ne peuvent plus intégrer Google Analytics comme ils le faisaient, sous peine de sanctions.

Trois entreprises ont été mises en demeure de changer d’outil pour leur analyse d’audience, sauf à exclure des statistiques tous ceux qui refusent le dépôt d’un cookie Google Analytics. La commission chargée de veiller à la protection des données personnelles constate en effet que la solution de Google implique un transfert des données des visiteurs vers les États-Unis d’Amérique, ce qui n’est pas légal actuellement au regard du RGPD. En avril 2022, l'autorité autrichienne de protection des données est arrivée à la même conclusion.

Ces décisions sont une conséquence attendue de l’arrêt “Schrems II” de la Cour de justice de l’Union européenne (CJUE) du 16 juillet 2020. Elle a en effet invalidé le mécanisme juridique par lequel la Commission européenne prétendait que les USA assurent un niveau adéquat de protection des données personnelles reçues. D’un avis totalement contraire, la Cour a dit très clairement que la législation américaine en matière de renseignement est disproportionnée et que les voies de recours sont insuffisantes. 

Elle a donc supprimé le cadre juridique global par lequel les transferts vers les USA étaient possibles, et laissé aux autorités nationales le soin de vérifier si d’autres mécanismes (contractuels) étaient exploitables. En France et en Autriche, les APD concluent qu’il est impossible de transférer des données vers les USA en l’état actuel de la législation américaine et des encadrements prévus. D’où les discussions en cours, à l’issue encore incertaine, sur un aménagement permettant un nouvel accord UE-USA de transferts.

D’ici là, les entreprises qui ne remplaceront pas Google Analytics ou des outils opérant des transferts avec les USA sans consentement spécifique et préalable prennent le risque d’être sanctionnés par la CNIL ou une autre APD en cas de contrôle. En rendant public des mises en demeure sans donner le nom des entreprises sanctionnées, la Commission veut faire comprendre que toutes doivent se conformer, par exemple en utilisant une alternative, qui permet aux données de rester dans l’Union européenne.

Remplacer Google Analytics par Matomo

C’est ce que vous permet Matomo, un outil d’analyse d’audience très complet et open source, recommandé depuis plusieurs années par la CNIL. Il peut même faire l’objet d’une exemption de demande de consentement lorsqu'il est configuré de la bonne manière. 

S’il est déjà possible de le mettre en place sur Clever Cloud, nous avons facilité la procédure avec la création d’un add-on dédié. En installant une instance Matomo via notre plateforme, vous gardez la main sur les données d’analyse de l’audience de vos visiteurs. Elles ne sont plus envoyées vers les Etats-Unis. 

Clever Cloud héberge ces données pour vous, sur des serveurs situés en France.

Comment installer Matomo ?

Depuis la Console Clever Cloud et dans l’organisation souhaitée, sélectionnez "Créer…" puis "... un add-on" et "Matomo". Validez et c’est terminé ! Nous avons fait le choix de rendre les dépendances de cet add-on transparentes et indépendantes.

Comment fonctionne Matomo sur Clever Cloud

L’add-on Matomo sur Clever Cloud déploie ainsi automatiquement :

• Une application PHP configurée avec un Matomo fonctionnel (instance Nano)
• Une base de données MySQL (instance XXS BigStorage)
• Un cache Redis (instance S)

Vous pourrez alors ajuster les paramètres à votre convenance pour adapter le niveau de performance selon votre besoin, ou même activer l'auto-scaling (horizontal et/ou vertical). 

Comme pour les autres add-ons que nous proposons, Matomo est spécialement configuré pour exploiter l’identification Single Sign On (SSO) de la console Clever Cloud, vous pourrez ensuite créer vos utilisateurs directement depuis Matomo. La documentation est disponible ici.

Bonjour 🖖, amis humains et robots ! Notre équipe d'ingénieurs est fière d'annoncer un tout nouveau kit de développement logiciel (sdk) Rust, également connu sous le nom de "clevercloud-sdk" sur crates.io.

Certains d'entre vous ont peut-être remarqué qu'il y a de nouveaux dépots sur notre organisation GitHub. Ces dépots sont nommés "clevercloud-sdk-rust" et "oauth10a-rust". Leur objectif est de fournir un moyen pratique d'interagir avec l'API de Clever Cloud avec des fonctionnalités intéressantes que nous allons vous faire découvrir dans ce blogpost!

Conçu pour être asynchrone

Le kit de développement logiciel et le client oauth 1.0a sont principalement construits sur la base de deux crates bien connus de la communauté. Il s'agit de hyper, et du runtime asynchrone qui le propulse, nommé tokio.

L'idée principale derrière l'utilisation de la crate hyper et par extension du runtime asynchrone tokio est de tirer parti de l'écosystème actuel qui gravite autour de ces crates et des efforts pour intégrer une nouvelle API du kernel appelée io_uring. Une fois que cette nouvelle API kernel sera intégrée dans le runtime tokio, cela conduira à une amélioration significative de la performance, selon le billet de blog de l'annonce de tokio. Nous attendons avec impatience cette amélioration qui nous permettra d'itérer plus rapidement ! 🚀

L'observabilité au cœur de l'outil

Ces crates sont développées avec l'idée d'être entièrement observables. Cela a été réalisé par d'autres crates bien connus comme log et tracing, ou en utilisant des initiatives communautaires comme le crate prometheus. Les intégrations de ces crates font partie du système de flags de fonctionnalités de compilateur fourni par le dépot cargo.

Façade de logs standard

Tout d'abord, vous devez savoir que la façade de logs standard est activée par défaut. Elle fournira des informations utiles sur les comportements internes des crates ci-dessus, en utilisant le logger standard s'il est défini. Elle vous aidera à comprendre comment les appels à l'API de Clever Cloud sont réalisés avec quelques informations de débogage, si vous en avez besoin.

clevercloud-sdk = { version = "^0.10.0", default-features = false }

Si vous voulez le désactiver, vous devez désactiver les ensembles par défaut de fonctionnalités activées. Cela peut être réalisé en utilisant la syntaxe suivante pour le crate clevercloud-sdk dans votre fichier Cargo.toml.

Orienté métriques

Nous pensons que les métriques sont importantes. Elles aident à comprendre les systèmes en mettant en corrélation des choses qui ne semblent pas être liées au départ.

C'est pourquoi nous avons lancé Clever Cloud Metrics assez rapidement, il y a quelques années. Nous l'avons récemment enrichi de nouvelles fonctionnalités en offrant plus de moyens d'interroger Clever Cloud Metrics, grâce à Erlenmeyer qui est un proxy de langage d'interrogation de séries temporelles. Vous trouverez plus de détails sur la façon dont vous pouvez l'utiliser dans cet article de blog.

Enfin, nous avons annoncé le produit Tardis qui vous permet de nous envoyer vos métriques et nous nous occupons du reste comme nous le faisons toujours et, plus récemment, nous avons intégré des tableaux de bord Grafana pré-construits pour vous aider à visualiser l'état de vos applications et add-ons, vous pouvez en savoir plus ici.

Revenons à nos crates. Vous pouvez activer la collecte de métriques à l'aide du crate prometheus, en activant les flags de métriques au niveau du crate dans votre fichier Cargo.toml. Cela peut être réalisé en utilisant la syntaxe suivante.

Une fois cette fonctionnalité activée, il n'y a plus grand-chose à faire. Vous devrez exposer les métriques via un serveur HTTP ou les envoyer en utilisant la passerelle push de prometheus. Cette partie est décrite dans la documentation du crate prometheus ou dans ces exemples.

Capacités de traces

Le dernier pilier de l'observabilité, mais non le moindre, sont les traces. Selon l'initiative et la documentation d'OpenTelemetry, les traces sont définies comme suit :

Les traces suivent la progression d'une demande unique, appelée trace, telle qu'elle est traitée par les services qui composent une application. La demande peut être initiée par un utilisateur ou une application. Les traces distribués sont une forme de trace qui traverse les frontières du processus, du réseau et de la sécurité. Chaque unité de travail dans une trace est appelée un span ; une trace est un arbre de spans. Les spans sont des objets qui représentent le travail effectué par les services ou les composants individuels impliqués dans une requête au fur et à mesure qu'elle circule dans un système. Un span contient un contexte de span, qui est un ensemble d'identifiants uniques au monde représentant la demande unique dont chaque span fait partie. Un span fournit des mesures de Demande, Erreur et Durée (RED) qui peuvent être utilisées pour déboguer les problèmes de disponibilité et de performance…

Documentation sur OpenTelemetry

Si vous souhaitez vous intéresser de plus près aux traces, même si elles ne sont pas en Rust, vous pouvez consulter l'organisation OpenTelemetry GitHub. Il y a beaucoup de bibliothèques, de SDKs et de documentation pour vous aider à construire votre solution de traces ou à l'intégrer à une solution déjà existante. En outre, si vous utilisez le langage rust et peut-être le runtime tokio, vous pouvez consulter les articles de blog qui expliquent comment les traces fonctionnent dans le runtime asynchrone ci-dessus et comment les visualiser à l'aide de la console ou en utilisant le connecteur OpenTelemetry qui permet d'envoyer des traces à plus de puits, la liste est disponible sur le dépot rust GitHub d'OpenTelemetry.

Alors comment activer concrètement la fonctionnalité de traces à l'aide de clevercloud-sdk ? Comme mentionné ci-dessus, toutes les fonctionnalités sont pilotées par un flag de fonctionnalité, donc pour obtenir des capacités de traces, vous devez activer le flag de trace.

Une fois que l'indicateur de fonctionnalité a été activé, vous devrez collecter et envoyer des traces en utilisant le connecteur et les sinks ci-dessus.

À quoi ça ressemble ?

Prenons un exemple concret pour illustrer ce à quoi ressemble le clevercloud-sdk. Mais avant de passer en revue l'utilisation de clevercloud-sdk, je vais vous présenter les dépendances et les exigences dont vous aurez besoin. La première chose à faire est de déclarer les crates dans le fichier Cargo.toml.

Nous sommes maintenant capables d'écrire un logiciel à l'aide de clevercloud-sdk. Voici un exemple de la façon d'utiliser le SDK :

...
use clevercloud_sdk::{
    oauth10a::{
        proxy::{self, ProxyConnectorBuilder},
        Credentials,
    },
    v2::myself,
    Client,
};
...

// See the full code at:
// - https://github.com/CleverCloud/clevercloud-sdk-rust/blob/main/examples/cleverctl
// - https://github.com/CleverCloud/clevercloud-sdk-rust/blob/main/examples/cleverctl/src/cmd/myself.rs
pub async fn get(config: Arc<Configuration>, output: &Output) -> Result<(), Error> {
    let credentials: Credentials = config.credentials.to_owned().into();
    let connector = ProxyConnectorBuilder::try_from_env().map_err(Error::ProxyConnector)?;
    let client = Client::builder()
        .with_credentials(credentials)
        .build(connector);

    let user = myself::get(&client).await.map_err(Error::Get)?;

    println!(
        "{}",
        output
            .format(&user)
            .map_err(|err| Error::FormatOutput(Box::new(err)))?
    );

    Ok(())
}

Un autre exemple du sdk qui interagit avec les add-ons :

En 2017, l’équipe du français Octobus part d’un constat : Git monte en puissance dans le domaine des outils de gestion de version (CVS), accompagné par des plateformes propriétaires telles que GitHub ou ouvertes comme GitLab. Cela décourage peu à peu d’autres acteurs qui délaissent des solutions concurrentes et leurs communautés.

C’était notamment le cas de Mercurial dont les utilisateurs voulaient profiter des avantages tout en bénéficiant d'une solution moderne de gestion des projets. L’idée est alors d’adapter l’édition communautaire de GitLab à Mercurial. 

Heptapod était né. L’outil, open source, sera développé pendant deux ans avant une première démonstration, puis stabilisé. Il est entré dans sa phase de production en 2020. C’est à cette époque que la rencontre entre Georges Racinet, mainteneur du projet, et Clever Cloud a donné lieu à la création de notre premier service hébergé : heptapod.host.

Il nous était en effet régulièrement demandé de proposer des forges en complément de notre offre et de nos solutions CI/CD, permettant à nos clients un déploiement en France, avec la simplicité et l’efficacité de la plateforme Clever Cloud, sans être dépendant d’une solution tierce, propriétaire, dont les conditions peuvent changer du jour au lendemain. 

Heptapod nous semblait être le candidat parfait pour répondre à ce besoin : il s’agit d’une offre GitLab pleine et entière, avec la possibilité d’utiliser Mercurial comme CVS pour ceux qui le souhaitent. Surtout, cela nous permet d’y proposer nos propres fonctionnalités avec un déploiement facilité, comme pour les runners récemment mis en place.

L’hébergement de projets open source peut être proposé gratuitement. Vous pouvez également profiter d’un maximum de 1 Go et 100 utilisateurs publics sans frais. Au-delà ou pour des utilisateurs/dépôts privés, cela vous sera facturé à la tarification en vigueur.

Pour utiliser Heptapod dès maintenant, un compte Clever Cloud suffit.