Je me suis lancé dans l’arcade et l’écran explose : les scores grimpent, des pas résonnent dans les haut-parleurs, le Cosmic Silverback charge mon flanc. Je me fige, réalise que chaque point compte, et le classement devient soudainement la seule langue qui vaille. Vous ressentez la même chose : une seule partie peut tout changer. […]
Le post Black Ops 7 Dead Ops Arcade 4 : Guide complet des défis et des récompenses est apparu en premier sur Moyens I/O.
Pas besoin de scripts ; juste des fichiers de configuration décrivant l’état des hôtes.
Telle était la promesse de CFEngine lorsqu’il émergea dans les années 90. Avec son langage dédié, l’outil devait faciliter la maintenance des environnements BSD et System V (UNIX) en les organisant en classes. Il s’agissait déjà de répondre à la fragmentation des systèmes d’information…
Dans les années 2000, Puppet et Chef sont arrivés sur le même créneau, chacun avec son langage basé sur Ruby. L’un et l’autre fonctionnaient en mode pull, le client contactant régulièrement le serveur pour récupérer la configuration. On ne parlait pas encore de DevOps, mais d’automatisation du travail des sysadmins.
Au début des années 2010, AWS pousse le templating JSON/YAML avec CloudFormation. Ansible décline le concept en playbooks. Terraform l’adopte avec son propre langage (HCL) et le porte à l’échelle de déploiements multifournisseurs.
Face aux limites des langages dédiés et de l’option « tout YAML » apparaissent des outils comme Pulumi, qui adaptent les langages impératifs (Go, Python…) à la gestion d’infrastructure.
Avec ce bagage, l’approche « as code » s’est développée sur d’autres pans des systèmes informatiques : documentation, sécurité, politiques organisationnelles… ou encore observabilité. Dashboards, alertes, logs, traces, métriques, SLO/SLI, etc. deviennent autant d’éléments « codifiés » sur le même plan que l’infra ; et, in fine, déployés en parallèle, avec un repo Git comme « source de vérité ».
Corollaire de cette convergence, l’observability as code (OaC) porte globalement les mêmes promesses que l’infrastructure as code (IaC). À commencer par les bénéfices de l’automatisation.
Sur le papier, outre la réduction du potentiel d’erreurs humaines, on a des configurations reproductibles favorisant la cohérence entre environnements et la mise à l’échelle dans le contexte d’architectures dynamiques (microservices, workloads IA). On crée par ailleurs une boucle de rétroaction avec l’IaC, en bénéficiant de la traçabilité de Git – lequel permet aussi, en théorie, une reconstruction rapide de la stack d’observabilité.
En parallèle de leurs API, les principales solutions d’observabilité sont pilotables via Terraform, grâce à un provider. Elles proposent aussi d’empaqueter des configurations en charts Helm et d’utiliser des CRD pour définir des artefacts en tant qu’objets Kubernetes standards.
À cheval entre ces deux univers, il y a le projet Upjet. Celui-ci transforme les providers Terraform en providers Crossplane, tout en générant les contrôleurs de réconciliation et la documentation API avec des exemples de manifestes.
Du côté de Grafana, on expérimente actuellement une fonctionnalité Git Sync. Elle assure une synchronisation bidirectionnelle l’UI et le Git, avec la possibilité d’imposer que les changements réalisés sur l’interface passent par des PR. Pour le moment, certains artefacts ne sont pas pris en charge (alertes, panels…) et seul GitHub est géré (authentification par PAT uniquement).
Grafana a aussi, dans sa boîte à outils, un SDK Foundation orienté sur les langages à typage fort (on définit des dashboards en chaînant des appels de méthodes). Il a également une bibliothèque qui met en œuvre Jsonnet. Cette extension de JSON a été influencée par plusieurs langages de configuration utilisés chez Google. Elle facilite les regroupements logiques de configurations avec ajustement des variables à la volée pour contextualiser les artefacts.
À partir de Jsonnet, Prometheus a créé les mixins. Ce format encapsule des alertes/règles et des dashboards Grafana en compagnie du code avec lequel ils sont déployés.
Autre langage qui a ses racines chez Google : CUE (Configure, Unify, Execute). Il s’est en l’occurrence inspiré du langage utilisé pour configurer Borg, le prédécesseur de Kubernetes. En son cœur, une technique communément exploitée en linguistique informatique pour gérer grammaires et lexiques : l’unification de graphe. Types et valeurs sont fusionnés en un seul concept et ordonnés en une hiérarchie unique.
Associatif, CUE est aussi commutatif et idempotent : peu importe leur ordre, les valeurs produisent toujours le même résultat. On s’en servira typiquement pour la validation de schémas ou de données. Les types agissent alors comme des contraintes, réconciliables depuis plusieurs sources sans avoir à effectuer d’importations.
À petite échelle, un pattern traditionnel de déploiement de l’OaC repose sur la pile open source* Prometheus/Grafana/Loki/Jaeger. Souvent en monorepo avec un dossier pour les artefacts d’observabilité, un déploiement Helm ou CI/CD simple et une synchro par Git Sync ou API/webhooks.
À un deuxième niveau, chaque équipe possède son repo et sa configuration d’observabilité (« You build it, you run it »). Le déploiement peut impliquer Kustomize. Cet outil de gestion intégré à Kubernetes se distingue de Helm en permettant de surcharger toute valeur d’une configuration de base.
À ce même niveau, on voit souvent apparaître une gestion GitOps (réconciliation automatisée avec Flux ou Argo CD). Et le recours au collecteur OpenTelemetry pour standardiser la collecte sans modifier la couche d’instrumentation.
Viennent ensuite les plates-formes d’observabilité. À ce niveau, les identités machine se généralisent dans les pipelines. Et, avec elles, les systèmes de promotion automatisée, le contrôle de cardinalité (liste blanche de tags, politiques d’échantillonnage avec des outils comme Cribl et Vector) voire l’exploitation d’eBPF.
« Tout le monde échantillonne la data. La seule raison pour laquelle on le fait, c’est le coût de stockage », explique à ce sujet Stéphane Estevez, EMEA Market Advisor observabilité chez Splunk. Sa société, poursuit-il, a l’avantage de la taille : « Par rapport à nos concurrents, nos économies d’échelle ne sont pas les mêmes. On peut se permettre d’être compétitif tout en garantissant toutes les données ».
Vodafone en est arrivé à ce dernier stade. Il a plus précisément mis en place des modules d’observabilité Terraform. Ses développeurs consomment en self-service (ils n’ont qu’à déclarer les variables) et peuvent les modifier par PR.
Vu le nombre de développeurs, de services et d’artefacts d’observabilité, il a fallu diviser le fichier d’état (Terraform mettait sinon 17 minutes à s’exécuter).
Que ce soit pour créer un dashboard lors d’un incident ou modifier des seuils afin de « faire taire » des alertes, dans une approche OaC, l’utilisation de l’UI soulève la question de la réconciliation avec la partie as code. Une des réponses consiste à n’autoriser que ce qui passe par cette dernière, au minimum en production. Une autre, à verrouiller les états pour éviter les corruptions.
« Si on pousse la logique OaC, il faut accepter que la source de vérité, c’est ce qui est dans la codebase », confirme Pejman Tabassomi, Field CTO EMEA de Datadog.
Quant à enrichir l’OaC avec du machine learning, ce n’est pas forcément si évident. IBM, qui a son Cloud Pak for AIOps (évolutions des outils de Tivoli), en témoigne par la voie d’Éric Cattoir. L’intéressé fait partie d’une équipe technique au niveau EMEA couvrant les sujets regroupés sous la marque IT Automation. « On a essayé de faire des modèles basés sur l’analyse des logs, explique-t-il. On s’est aperçu que cette fonctionnalité dépend beaucoup de la structure et de la stabilité des fichiers. Chez certains clients, ça a nécessité beaucoup de rééducation des modèles, car il y avait trop de variabilité entre leurs systèmes ».
* Dans le domaine de l’open source, le projet Perses, en sandbox à la CNCF, pousse une spécification ouverte pour la visualisation des données d’observabilité. Pour le moment, métriques Prometheus, traces Tempo, logs Loki et profilage Pyroscope. Il inclut un vérificateur statique, un opérateur Kubernetes et un CLI pour réaliser des actions dans les pipelines CI/CD. Des SDK Go et CUE implémentent l’approche « as code ».
Illustration principale © Aryan – Adobe Stock
The post De l’infra à l’observabilité, mille et une nuances « as code » appeared first on Silicon.fr.
Dans cet article, l'ingénieur Alberto Donini présente une méthode innovante, la « méthode d'érosion relative » (MER), qu'il a mise au point pour déterminer la date de construction de structures anciennes.
Il applique cette méthode à la pyramide de Khéops sur le plateau de Gizeh. Est-il possible que la datation archéologique actuelle de ce monument égyptien antique soit incorrecte ?
Est-il également possible que les dates alternatives proposées par divers chercheurs soient tout aussi incorrectes ? Pour répondre à ces questions, l'auteur analyse la pyramide de Khéops sous un angle non conventionnel afin de déterminer la période la plus probable de sa construction.
La REM est basée sur le rapport entre deux types d'érosion affectant le même type de roche au même endroit : l'un avec une date connue et l'autre avec une date à déterminer. Ce rapport est ensuite utilisé pour calculer l'âge du bloc de pierre examiné.
Ces conclusions sont préliminaires et feront l'objet d'études plus approfondies grâce à des mesures supplémentaires, étendues à toutes les structures et bâtiments du plateau de Gizeh. Il est toujours possible d'améliorer la précision des mesures, la détermination des volumes érodés et la précision globale des résultats.
Alberto Donini a l'intention de poursuivre ses recherches et invite les archéologues du monde entier à collaborer à de futures études.
La REM n'a pas pour but de déterminer une date de construction précise pour un bâtiment ancien, mais plutôt d'identifier un intervalle temporel et de lui attribuer une probabilité. Bien que les fourchettes de dates obtenues soient larges, les conclusions indiquent une faible probabilité pour la datation archéologique officielle de 2 560 avant J.-C.
Pour ces raisons, il est probable que les pyramides d'Akhet Khufu (G1) remontent à environ 23 000 avant J.-C. Il est donc plausible que le pharaon Khéops ait simplement rénové la pyramide de Khufu, s'attribuant la paternité de celle-ci.
Sur la base de ce rapport préliminaire sur les mesures d'érosion relative (MER) effectuées sur la pyramide de Khéops, on peut conclure qu'il existait en Égypte, environ 20 000 ans avant Jésus-Christ, une civilisation capable de construire au moins la pyramide de Khéops (G1).
La grande pyramide de Gizeh, ou pyramide de Khéops, serait-elle plus ancienne qu'on ne le pense ? Une nouvelle étude de l'Université de Bologne, publiée jeudi 29 janvier, vient relancer le débat. L'ingénieur italien Alberto Donini y remet en question la datation qui situe sa construction vers 2 560 avant notre ère, sous le règne du pharaon Khéops. Il estime que l'érosion visible à la base du monument pourrait indiquer une origine antérieure, qui remonterait "possiblement jusqu'à la fin du Paléolithique".
L'usure observée dans certains recoins correspondrait à plus de 5 700 ans d'exposition, mais d'autres points indiqueraient plus de 20 000 ans, et parfois plus de 40 000 ans, avec une moyenne "autour de 22 900 avant notre ère".
Connexion