Lorsque vous accédez à un site ou une application en ligne, vous le faites le plus souvent de manière dite "sécurisée". C'est par exemple le fameux cadenas vert qui symbolise les connexions HTTPS dans votre navigateur, qui est devenu la norme depuis quelques années grâce à des initiatives comme Let's Encrypt. 

Cela signifie que les données transférées au serveur sont chiffrées, et que même si elles sont interceptées, elles sont illisibles par un tiers. Une protection assurée par le protocole TLS (Transport Layer Security) depuis près de 20 ans, qu'il s'agisse d'un site personnel, de vente en ligne ou même d'accès aux services de votre banque. 

À travers le temps, cette brique technique essentielle sur Internet a évolué pour renforcer le niveau de sécurité qu'elle offre. En août 2018, sa version 1.3 (la dernière en date) était publiée. Les versions 1.0 et 1.1 sont, elles, considérées comme n'offrant plus un niveau de protection suffisant. Elles sont ainsi dépréciées par l'IETF (Internet Engineering Task Force) depuis mars 2021 et ont été progressivement retirées des navigateurs récents comme Firefox, Chrome et ses dérivés ou Safari. 

Chez Clever Cloud, nous avons vu nos clients suivre ce mouvement et adopter peu à peu TLS 1.2 et 1.3. Sur nos load balancers, basés sur notre reverse proxy maison et open source Sōzu, la version la plus récente représente plus de 90 % des requêtes traitées chaque jour. TLS 1.2 compte pour un peu moins de 9 %. TLS 1.0 et 1.1 seulement quelques dizaines de milliers de requêtes par jour, moins de 0,1 % de notre trafic.

Si nous avons continué à gérer ces versions pour des questions de compatibilité, ce ne sera plus le cas à compter du 30 juin prochain. Nous allons bien entendu informer les clients concernés par cette démarche, et les inciter à passer sur des versions plus récentes, ce qui aura pour eux des avantages tant en termes de sécurité que de performance ou même de référencement. 

Plusieurs rappels leur seront envoyés d'ici à la coupure définitive de TLS 1.0 et 1.1. En cas de questions à ce sujet, contactez notre support via la Console.

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 :