Interaction avec etcd
Les utilisateurs interagissent généralement avec etcd en définissant ou en récupérant la valeur d’une clé. Cette section décrit comment effectuer ces opérations à l’aide d’etcdctl, un outil en ligne de commande pour interagir avec le serveur etcd. Les concepts décrits ici s’appliquent également aux API gRPC ou aux API des bibliothèques clientes.
La version de l’API utilisée par etcdctl pour communiquer avec etcd peut être définie à 2 ou 3 via la variable d’environnement ETCDCTL_API. Par défaut, etcdctl sur la branche master (3.4) utilise l’API v3, tandis que les versions antérieures (3.3 et antérieures) utilisent par défaut l’API v2.
Notez qu’une clé créée à l’aide de l’API v2 ne pourra pas être interrogée via l’API v3. Une requête v3 etcdctl get d’une clé v2 se terminera avec le code 0 et sans données de clé ; il s’agit du comportement attendu.
Rechercher les versions
La version d’etcdctl et la version de l’API serveur peuvent être utiles pour identifier les commandes appropriées à utiliser pour effectuer diverses opérations sur etcd.
Voici la commande permettant de trouver les versions :
Écrire une clé
Les applications stockent des clés dans le cluster etcd en écrivant sur des clés. Chaque clé stockée est répliquée sur tous les membres du cluster etcd via le protocole Raft afin d’assurer la cohérence et la fiabilité.
Voici la commande permettant de définir la valeur de la clé foo à bar :
Un clé peut également être définie pour une durée déterminée en lui associant un bail.
Voici la commande permettant de définir la valeur de la clé foo1 à bar1 pendant 10 s.
L’identifiant de bail 1234abcd dans la commande ci-dessus fait référence à l’identifiant retourné lors de la création du bail de 10 s. Cet identifiant peut ensuite être associé à une clé.
Lire les clés
Les applications peuvent lire les valeurs des clés d’un cluster etcd. Les requêtes peuvent lire une seule clé ou une plage de clés.
Supposons que le cluster etcd ait stocké les clés suivantes :
Voici la commande pour lire la valeur de la clé foo :
Voici la commande pour lire la valeur de la clé foo au format hexadécimal :
Voici la commande pour lire uniquement la valeur de la clé foo :
Voici la commande pour parcourir les clés allant de foo à foo3 :
foo3 est exclu car la plage se situe dans l’intervalle demi-ouvert [foo, foo3), en excluant foo3.
Voici la commande permettant de parcourir toutes les clés ayant pour préfixe foo :
Voici la commande pour parcourir toutes les clés ayant pour préfixe foo, en limitant le nombre de résultats à 2 :
Voici la commande permettant de parcourir toutes les clés préfixées par foo en utilisant l’API RPC RangeStream
. Le résultat est identique à un appel unaire Range :
--stream ne prend pas en charge --order, --sort-by ni les filtres de révision.
Lire les versions antérieures des clés
Les applications peuvent souhaiter lire des versions obsolètes d’une clé. Par exemple, une application peut souhaiter revenir à une configuration ancienne en accédant à une version antérieure d’une clé. En outre, une application peut souhaiter obtenir une vue cohérente sur plusieurs clés au fil de plusieurs requêtes en accédant à l’historique des clés.
Étant donné qu’une modification apportée au magasin clé-valeur d’un cluster etcd incrémente la révision globale du cluster etcd, une application peut lire des clés obsolètes en fournissant une révision etcd antérieure.
Supposons qu’un cluster etcd dispose déjà des clés suivantes :
Voici un exemple pour accéder aux versions antérieures des clés :
Lire les clés dont la valeur en octets est supérieure ou égale à celle de la clé spécifiée
Les applications peuvent souhaiter lire des clés dont la valeur en octets est supérieure ou égale à celle de la clé spécifiée.
Supposons qu’un cluster etcd dispose déjà des clés suivantes :
Voici la commande permettant de lire les clés dont la valeur d’octet est supérieure ou égale à celle de la clé b :
Supprimer des clés
Les applications peuvent supprimer une clé ou une plage de clés d’un cluster etcd.
Supposons qu’un cluster etcd dispose déjà des clés suivantes :
Voici la commande pour supprimer la clé foo :
Voici la commande permettant de supprimer les clés comprises entre foo et foo9 :
Voici la commande permettant de supprimer la clé zoo avec la paire clé-valeur supprimée renvoyée :
Voici la commande permettant de supprimer les clés dont le préfixe est zoo :
Voici la commande permettant de supprimer les clés dont la valeur d’octet est supérieure ou égale à celle de la clé b :
Surveillance des modifications de clé
Les applications peuvent surveiller une clé ou une plage de clés afin de détecter toute mise à jour.
Voici la commande pour surveiller la clé foo :
Voici la commande pour surveiller la clé foo au format hexadécimal :
Voici la commande pour effectuer une surveillance sur une plage de clés de foo à foo9 :
Voici la commande pour surveiller les clés ayant le préfixe foo :
Voici la commande pour effectuer une surveillance sur plusieurs clés foo et zoo :
Surveillance des modifications historiques des clés
Les applications peuvent souhaiter surveiller les modifications historiques de clés dans etcd. Par exemple, une application peut souhaiter recevoir toutes les modifications d’une clé ; si l’application reste connectée à etcd, alors watch est suffisant. Toutefois, si l’application ou etcd échoue, une modification peut survenir pendant l’indisponibilité, et l’application ne recevra pas la mise à jour en temps réel. Pour garantir que la mise à jour soit livrée, l’application doit pouvoir surveiller les modifications historiques des clés. Pour cela, une application peut spécifier une révision historique lors d’une surveillance, tout comme lors de la lecture d’une version antérieure de clés.
Supposons que nous ayons terminé la séquence d’opérations suivante :
Voici un exemple de surveillance des modifications historiques :
Voici un exemple de surveillance uniquement à partir du dernier changement historique :
Progression de la surveillance
Les applications peuvent souhaiter vérifier l’avancement d’une surveillance afin de déterminer à quel point le flux de surveillance est à jour. Par exemple, si une surveillance est utilisée pour mettre à jour un cache, il peut être utile de savoir si le cache est périmé par rapport à la révision obtenue à partir d’une lecture en quorum.
Les requêtes de progression peuvent être émises à l’aide de la commande « progress » dans une session de surveillance interactive afin de demander au serveur etcd d’envoyer une mise à jour de notification de progression dans le flux de surveillance :
Le numéro de révision dans la réponse de notification de progression est la révision du nœud local du serveur etcd auquel le flux de surveillance est connecté. Si ce nœud est isolé et n’appartient pas au quorum, cette révision de notification de progression peut être inférieure à la révision retournée par une lecture effectuée en quorum contre un nœud serveur etcd non isolé.
Révisions compactées
Comme nous l’avons mentionné, etcd conserve des révisions afin que les applications puissent lire des versions antérieures des clés. Toutefois, afin d’éviter de accumuler une quantité illimitée d’historique, il est important de compacter les révisions passées. Une fois la compaction effectuée, etcd supprime les révisions historiques, libérant ainsi des ressources pour une utilisation future. Toutes les données obsolètes dont la révision est antérieure à la révision compactée deviendront indisponibles.
Voici la commande pour compacter les révisions :
La révision actuelle du serveur etcd peut être obtenue en utilisant la commande get sur une clé quelconque (existante ou non) au format JSON. L’exemple ci-dessous montre la requête pour mykey, qui n’existe pas sur le serveur etcd :
Accorder des bails
Les applications peuvent accorder des bails pour des clés depuis un cluster etcd. Lorsqu’une clé est associée à un bail, sa durée de vie est liée à celle du bail, qui à son tour est régulée par une durée de vie (TTL). Chaque bail a une valeur minimale de durée de vie (TTL) spécifiée par l’application au moment de l’accord. La valeur réelle de TTL du bail est au moins égale à la durée minimale et est choisie par le cluster etcd. Dès qu’une durée de vie (TTL) d’un bail a expiré, le bail expire et toutes les clés associées sont supprimées.
Voici la commande pour accorder un bail :
Révoquer les bails
Les applications révoquent les bails par identifiant de bail. La révocation d’un bail supprime toutes les clés associées.
Supposons que nous ayons terminé la séquence d’opérations suivante :
Voici la commande pour révoquer le même bail :
Maintenir les bails actifs
Les applications peuvent maintenir un bail actif en actualisant périodiquement son TTL afin qu’il ne expire pas.
Supposons que nous ayons terminé la séquence d’opérations suivante :
Voici la commande permettant de maintenir le bail actif :
Obtenir les informations sur le bail
Les applications peuvent souhaiter connaître les informations relatives aux bails, afin de les renouveler ou de vérifier s’ils existent encore ou ont expiré. Les applications peuvent également souhaiter connaître les clés auxquelles un bail particulier est associé.
Supposons que nous ayons terminé la séquence d’opérations suivante :
Voici la commande permettant d’obtenir des informations sur le bail :
Voici la commande permettant d’obtenir des informations sur le bail ainsi que les clés associées au bail :