Guide du développeur

• 1: Protocole du service de découverte
• 2: Mettre en place un cluster local
• 3: Interaction avec etcd
• 4: Pourquoi utiliser une passerelle gRPC
• 5: Découverte et nommage gRPC
• 6: Intégration d'etcd dans une application Go
• 7: Limites système
• 8: etcd features
• 9: Référence de l'API
• 10: Référence API : concurrence

1 - Protocole du service de découverte

Le protocole de service de découverte aide un nouveau membre etcd à découvrir tous les autres membres du cluster pendant la phase d’initialisation, en utilisant une URL de découverte partagée.

Le protocole de service de découverte n’est utilisé que pendant la phase d’amorçage du cluster, et ne peut pas être utilisé pour la reconfiguration en temps réel ou la surveillance du cluster.

Le protocole utilise un nouveau jeton de découverte pour initialiser un unique cluster etcd. Souvenez-vous qu’un jeton de découverte ne peut représenter qu’un seul cluster etcd. Dès que le protocole de découverte associé à ce jeton est lancé, même s’il échoue en cours de route, il ne doit pas être utilisé pour initialiser un autre cluster etcd.

Le reste de cet article détaille le processus de découverte à l’aide d’exemples correspondant à un cluster de découverte auto-hébergé. Le service public de découverte, discovery.etcd.io, fonctionne de la même manière, mais avec une couche d’interface améliorée qui masque les URL complexes, génère automatiquement des UUID et met en place certaines protections contre les requêtes excessives. Au cœur de ce service public, un cluster etcd est toujours utilisé comme magasin de données, comme décrit dans ce document.

Flot de protocole

L’idée du protocole de découverte consiste à utiliser un cluster etcd interne pour coordonner le démarrage d’un nouveau cluster. Tout d’abord, tous les nouveaux membres interagissent avec le service de découverte et contribuent à générer la liste de membres attendue. Ensuite, chaque nouveau membre démarre son serveur en utilisant cette liste, ce qui permet d’obtenir la même fonctionnalité que l’option -initial-cluster.

Dans l’exemple de workflow suivant, nous allons présenter chaque étape du protocole au format curl afin de faciliter la compréhension.

Par convention, le protocole de découverte etcd utilise le préfixe de clé _etcd/registry. Si http://example.com héberge un cluster etcd pour le service de découverte, l’URL complète de l’espace de clés de découverte sera http://example.com/v2/keys/_etcd/registry. Nous utiliserons cette URL comme préfixe dans l’exemple.

Création d’un nouveau jeton de découverte

Générez un jeton unique qui identifiera le nouveau cluster. Ce jeton sera utilisé comme préfixe unique dans l’espace de clés de découverte aux étapes suivantes. Une méthode simple consiste à utiliser uuidgen :

UUID=$(uuidgen)

Spécification de la taille attendue du cluster

Le jeton de découverte attend une taille de cluster qui doit être précisée. Cette taille est utilisée par le service de découverte pour savoir quand il a trouvé tous les membres qui formeront initialement le cluster.

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size -d value=${cluster_size}

En général, la taille du cluster est de 3, 5 ou 7. Consultez taille optimale du cluster pour plus de détails.

Mise en marche des processus etcd

Étant donné l’URL de découverte, utilisez-la comme indicateur -discovery et lancez les processus etcd. Chaque processus etcd suivra automatiquement les étapes suivantes en interne s’il reçoit l’indicateur -discovery.

S’enregistrer lui-même

La première étape pour le processus etcd consiste à s’inscrire dans l’URL de découverte en tant que membre. Cela se fait en créant l’ID de membre comme clé dans l’URL de découverte.

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/${member_id}?prevExist=false -d value="${member_name}=${member_peer_url_1}&${member_name}=${member_peer_url_2}"

Vérification du statut

Il vérifie la taille attendue du cluster et l’état d’inscription à l’URL de découverte, puis détermine l’action suivante.

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size
curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}

Si le nombre de membres enregistrés reste insuffisant, l’attente sera poursuivie jusqu’à la réapparition de membres sortis.

Si le nombre de membres enregistrés est supérieur à la taille attendue N, le système considère les N premiers membres enregistrés comme la liste des membres du cluster. Si le membre lui-même figure dans cette liste, la procédure de découverte réussit et il récupère tous les pairs à partir de la liste des membres. Sinon, la procédure de découverte échoue, car le cluster est plein.

Dans l’implémentation etcd, le membre peut vérifier l’état du cluster même avant de s’enregistrer. Il peut donc échouer rapidement si le cluster est plein.

En attente de tous les membres

Le processus d’attente est décrit en détail dans la documentation de l’API etcd .

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}?wait=true&waitIndex=${current_etcd_index}

Il continue d’attendre jusqu’à la découverte de tous les membres.

Service de découverte publique

CoreOS Inc. héberge un service de découverte public à https://discovery.etcd.io/ , qui offre plusieurs fonctionnalités pratiques pour faciliter l’utilisation.

Préfixe de masquage de clé

Le service de découverte publique redirigera https://discovery.etcd.io/${UUID} vers le cluster etcd derrière pour la clé située à /v2/keys/_etcd/registry. Il masque le préfixe de clé d’enregistrement afin d’obtenir une URL de découverte plus courte et plus lisible.

Obtenir un nouveau jeton

GET /new

Sent query:
	size=${cluster_size}
Possible status codes:
	200 OK
	400 Bad Request
200 Body:
	generated discovery url

Le processus de génération dans le service suit les étapes allant de Création d’un jeton de découverte à Spécification de la taille attendue du cluster .

Vérifier l’état de découverte

GET /${UUID}

L’état de ce jeton de découverte, y compris les machines qui ont été enregistrées, peut être vérifié en demandant la valeur de l’UUID.

Dépôt open source

Le dépôt est situé à https://github.com/coreos/discovery.etcd.io .. Il peut être utilisé pour créer un service de découverte personnalisé.

2 - Mettre en place un cluster local

Pour les déploiements de test et de développement, la méthode la plus rapide et la plus simple consiste à configurer un cluster local. Pour un déploiement en production, reportez-vous à la section clustering .

Cluster autonome local

Démarrage d’un cluster

Exécutez la commande suivante pour déployer un cluster etcd en tant que cluster autonome :

$ ./etcd
...

Si le binaire etcd n’est pas présent dans le répertoire de travail courant, il se peut qu’il se trouve soit à $GOPATH/bin/etcd, soit à /usr/local/bin/etcd. Exécutez la commande en conséquence.

Le membre etcd en cours d’exécution écoute sur localhost:2379 pour les requêtes clientes.

Interaction avec le cluster

Utilisez etcdctl pour interagir avec le cluster en cours d’exécution :

1. Stockez une paire clé-valeur exemple dans le cluster :

     $ ./etcdctl put foo bar
     OK

   Si OK est affiché, la sauvegarde de la paire clé-valeur a réussi.

2. Récupérer la valeur de foo :

   $ ./etcdctl get foo
   bar

   Si bar est retourné, l’interaction avec le cluster etcd fonctionne comme prévu.

Cluster local à plusieurs membres

Démarrage d’un cluster

Un Procfile situé à la racine du dépôt git d’etcd est fourni pour configurer facilement un cluster local à plusieurs membres. Pour démarrer un cluster à plusieurs membres, accédez à la racine de l’arborescence source d’etcd et exécutez les étapes suivantes :

1. Installer goreman pour contrôler les applications basées sur Procfile :

   $ go install github.com/mattn/goreman@latest

2. Démarrez un cluster avec goreman en utilisant le Procfile par défaut d’etcd :

   $ goreman -f Procfile start

   Les membres démarrent. Ils écoutent respectivement sur localhost:2379, localhost:22379 et localhost:32379 les requêtes clientes.

Interaction avec le cluster

Utilisez etcdctl pour interagir avec le cluster en cours d’exécution :

1. Affichez la liste des membres :

   $ etcdctl --write-out=table --endpoints=localhost:2379 member list

   La liste des membres etcd s’affiche comme suit :

   +------------------+---------+--------+------------------------+------------------------+
   |        ID        | STATUS  |  NAME  |       PEER ADDRS       |      CLIENT ADDRS      |
   +------------------+---------+--------+------------------------+------------------------+
   | 8211f1d0f64f3269 | started | infra1 | http://127.0.0.1:2380  | http://127.0.0.1:2379  |
   | 91bc3c398fb3c146 | started | infra2 | http://127.0.0.1:22380 | http://127.0.0.1:22379 |
   | fd422379fda50e48 | started | infra3 | http://127.0.0.1:32380 | http://127.0.0.1:32379 |
   +------------------+---------+--------+------------------------+------------------------+

2. Stockez une paire clé-valeur exemple dans le cluster :

   $ etcdctl put foo bar
   OK

   Si OK est affiché, la sauvegarde de la paire clé-valeur a réussi.

Test de tolérance aux pannes

Pour tester la tolérance aux pannes d’etcd, arrêtez un membre et tentez de récupérer la clé.

1. Identifiez le nom du processus du membre à arrêter.

   Le Procfile liste les propriétés du cluster à plusieurs membres. Par exemple, considérez le membre dont le nom de processus est etcd2.

2. Arrêtez le membre :

   # kill etcd2
   $ goreman run stop etcd2

3. Stockez une clé :

   $ etcdctl put key hello
   OK

4. Récupérez la clé stockée à l’étape précédente :

   $ etcdctl get key
   hello

5. Récupérer une clé depuis un membre arrêté :

   $ etcdctl --endpoints=localhost:22379 get key

   La commande doit afficher une erreur due à un échec de connexion :

   2017/06/18 23:07:35 grpc: Conn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 127.0.0.1:22379: getsockopt: connection refused"; Reconnecting to "localhost:22379"
   Error:  grpc: timed out trying to connect

6. Redémarrez le membre arrêté :

   $ goreman run restart etcd2

7. Obtenez la clé depuis le membre redémarré :

   $ etcdctl --endpoints=localhost:22379 get key
   hello

   Redémarrer le membre rétablit la connexion. etcdctl pourra désormais récupérer la clé avec succès. Pour en savoir plus sur l’interaction avec etcd, consultez la section interaction avec etcd .

3 - 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.

export ETCDCTL_API=3

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 :

$ etcdctl version
etcdctl version: 3.1.0-alpha.0+git
API version: 3.1

É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 :

$ etcdctl put foo bar
OK

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.

$ etcdctl put foo1 bar1 --lease=1234abcd
OK

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 :

foo = bar
foo1 = bar1
foo2 = bar2
foo3 = bar3

Voici la commande pour lire la valeur de la clé foo :

$ etcdctl get foo
foo
bar

Voici la commande pour lire la valeur de la clé foo au format hexadécimal :

$ etcdctl get foo --hex
\x66\x6f\x6f          # Key
\x62\x61\x72          # Value

Voici la commande pour lire uniquement la valeur de la clé foo :

$ etcdctl get foo --print-value-only
bar

Voici la commande pour parcourir les clés allant de foo à foo3 :

$ etcdctl get foo foo3
foo
bar
foo1
bar1
foo2
bar2

Voici la commande permettant de parcourir toutes les clés ayant pour préfixe foo :

$ etcdctl get --prefix foo
foo
bar
foo1
bar1
foo2
bar2
foo3
bar3

Voici la commande pour parcourir toutes les clés ayant pour préfixe foo, en limitant le nombre de résultats à 2 :

$ etcdctl get --prefix --limit=2 foo
foo
bar
foo1
bar1

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 :

$ etcdctl get --stream --prefix foo
foo
bar
foo1
bar1
foo2
bar2
foo3
bar3

--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 :

foo = bar         # revision = 2
foo1 = bar1       # revision = 3
foo = bar_new     # revision = 4
foo1 = bar1_new   # revision = 5

Voici un exemple pour accéder aux versions antérieures des clés :

$ etcdctl get --prefix foo # access the most recent versions of keys
foo
bar_new
foo1
bar1_new

$ etcdctl get --prefix --rev=4 foo # access the versions of keys at revision 4
foo
bar_new
foo1
bar1

$ etcdctl get --prefix --rev=3 foo # access the versions of keys at revision 3
foo
bar
foo1
bar1

$ etcdctl get --prefix --rev=2 foo # access the versions of keys at revision 2
foo
bar

$ etcdctl get --prefix --rev=1 foo # access the versions of keys at revision 1

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 :

a = 123
b = 456
z = 789

Voici la commande permettant de lire les clés dont la valeur d’octet est supérieure ou égale à celle de la clé b :

$ etcdctl get --from-key b
b
456
z
789

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 :

foo = bar
foo1 = bar1
foo3 = bar3
zoo = val
zoo1 = val1
zoo2 = val2
a = 123
b = 456
z = 789

Voici la commande pour supprimer la clé foo :

$ etcdctl del foo
1 # one key is deleted

Voici la commande permettant de supprimer les clés comprises entre foo et foo9 :

$ etcdctl del foo foo9
2 # two keys are deleted

Voici la commande permettant de supprimer la clé zoo avec la paire clé-valeur supprimée renvoyée :

$ etcdctl del --prev-kv zoo
1   # one key is deleted
zoo # deleted key
val # the value of the deleted key

Voici la commande permettant de supprimer les clés dont le préfixe est zoo :

$ etcdctl del --prefix zoo
2 # two keys are deleted

Voici la commande permettant de supprimer les clés dont la valeur d’octet est supérieure ou égale à celle de la clé b :

$ etcdctl del --from-key b
2 # two keys are deleted

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 :

$ etcdctl watch foo
# in another terminal: etcdctl put foo bar
PUT
foo
bar

Voici la commande pour surveiller la clé foo au format hexadécimal :

$ etcdctl watch foo --hex
# in another terminal: etcdctl put foo bar
PUT
\x66\x6f\x6f          # Key
\x62\x61\x72          # Value

Voici la commande pour effectuer une surveillance sur une plage de clés de foo à foo9 :

$ etcdctl watch foo foo9
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put foo1 bar1
PUT
foo1
bar1

Voici la commande pour surveiller les clés ayant le préfixe foo :

$ etcdctl watch --prefix foo
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put fooz1 barz1
PUT
fooz1
barz1

Voici la commande pour effectuer une surveillance sur plusieurs clés foo et zoo :

$ etcdctl watch -i
$ watch foo
$ watch zoo
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put zoo val
PUT
zoo
val

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 :

$ etcdctl put foo bar         # revision = 2
OK
$ etcdctl put foo1 bar1       # revision = 3
OK
$ etcdctl put foo bar_new     # revision = 4
OK
$ etcdctl put foo1 bar1_new   # revision = 5
OK

Voici un exemple de surveillance des modifications historiques :

# watch for changes on key `foo` since revision 2
$ etcdctl watch --rev=2 foo
PUT
foo
bar
PUT
foo
bar_new

# watch for changes on key `foo` since revision 3
$ etcdctl watch --rev=3 foo
PUT
foo
bar_new

Voici un exemple de surveillance uniquement à partir du dernier changement historique :

# watch for changes on key `foo` and return last revision value along with modified value
$ etcdctl watch --prev-kv foo
# in another terminal: etcdctl put foo bar_latest
PUT
foo         # key
bar_new     # last value of foo key before modification
foo         # key
bar_latest  # value of foo key after modification

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 :

$ etcdctl watch -i
$ watch a
$ progress
progress notify: 1
# in another terminal: etcdctl put x 0
# in another terminal: etcdctl put y 1
$ progress
progress notify: 3

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 :

$ etcdctl compact 5
compacted revision 5

# any revisions before the compacted one are not accessible
$ etcdctl get --rev=4 foo
Error:  rpc error: code = 11 desc = etcdserver: mvcc: required revision has been compacted

$ etcdctl get mykey -w=json
{"header":{"cluster_id":14841639068965178418,"member_id":10276657743932975437,"revision":15,"raft_term":4}}

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 :

# grant a lease with 60 second TTL
$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)

# attach key foo to lease 32695410dcc0ca06
$ etcdctl put --lease=32695410dcc0ca06 foo bar
OK

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 :

$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)
$ etcdctl put --lease=32695410dcc0ca06 foo bar
OK

Voici la commande pour révoquer le même bail :

$ etcdctl lease revoke 32695410dcc0ca06
lease 32695410dcc0ca06 revoked

$ etcdctl get foo
# empty response since foo is deleted due to lease revocation

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 :

$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)

Voici la commande permettant de maintenir le bail actif :

$ etcdctl lease keep-alive 32695410dcc0ca06
lease 32695410dcc0ca06 keepalived with TTL(60)
lease 32695410dcc0ca06 keepalived with TTL(60)
lease 32695410dcc0ca06 keepalived with TTL(60)
...

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 :

# grant a lease with 500 second TTL
$ etcdctl lease grant 500
lease 694d5765fc71500b granted with TTL(500s)

# attach key zoo1 to lease 694d5765fc71500b
$ etcdctl put zoo1 val1 --lease=694d5765fc71500b
OK

# attach key zoo2 to lease 694d5765fc71500b
$ etcdctl put zoo2 val2 --lease=694d5765fc71500b
OK

Voici la commande permettant d’obtenir des informations sur le bail :

$ etcdctl lease timetolive 694d5765fc71500b
lease 694d5765fc71500b granted with TTL(500s), remaining(258s)

Voici la commande permettant d’obtenir des informations sur le bail ainsi que les clés associées au bail :

$ etcdctl lease timetolive --keys 694d5765fc71500b
lease 694d5765fc71500b granted with TTL(500s), remaining(132s), attached keys([zoo2 zoo1])

# if the lease has expired or does not exist it will give the below response:
Error:  etcdserver: requested lease not found

4 - Pourquoi utiliser une passerelle gRPC

etcd v3 utilise gRPC comme protocole de messagerie. Le projet etcd inclut un client Go basé sur gRPC ainsi qu’une utilitaire en ligne de commande, etcdctl , pour communiquer avec un cluster etcd via gRPC. Pour les langages ne disposant pas de prise en charge gRPC, etcd fournit une passerelle gRPC en JSON. Cette passerelle fournit un proxy RESTful qui traduit les requêtes HTTP/JSON en messages gRPC.

Utilisation de la passerelle gRPC

La passerelle accepte une correspondance JSON pour les définitions de messages du protocole buffer de etcd . Notez que les champs key et value sont définis comme des tableaux d’octets et doivent donc être encodés en base64 dans le JSON. Les exemples suivants utilisent curl, mais tout client HTTP/JSON devrait fonctionner de la même manière.

Notes

Point de terminaison de passerelle gRPC a changé depuis etcd v3.3 :

• etcd v3.2 ou antérieure utilise uniquement [CLIENT-URL]/v3alpha/*.
• etcd v3.3 utilise [CLIENT-URL]/v3beta/* tout en conservant [CLIENT-URL]/v3alpha/*.
• etcd v3.4 utilise [CLIENT-URL]/v3/* tout en conservant [CLIENT-URL]/v3beta/*.
  • [CLIENT-URL]/v3alpha/* est obsolète.
• etcd v3.5 ou ultérieure utilise uniquement [CLIENT-URL]/v3/*.
  • [CLIENT-URL]/v3beta/* est obsolète.

Le passerelle gRPC ne prend pas en charge l’authentification par le nom commun TLS.

Mettre et obtenir des clés

Utilisez les services /v3/kv/range et /v3/kv/put pour lire et écrire des clés :

<<COMMENT
https://www.base64encode.org/
foo is 'Zm9v' in Base64
bar is 'YmFy'
COMMENT

curl -L http://localhost:2379/v3/kv/put \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"}}

curl -L http://localhost:2379/v3/kv/range \
  -X POST -d '{"key": "Zm9v"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}

# get all keys prefixed with "foo"
curl -L http://localhost:2379/v3/kv/range \
  -X POST -d '{"key": "Zm9v", "range_end": "Zm9w"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}

Surveillance des clés

Utilisez le service /v3/watch pour surveiller les clés :

curl -N http://localhost:2379/v3/watch \
  -X POST -d '{"create_request": {"key":"Zm9v"} }' &
# {"result":{"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"1","raft_term":"2"},"created":true}}

curl -L http://localhost:2379/v3/kv/put \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}' >/dev/null 2>&1
# {"result":{"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"2"},"events":[{"kv":{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}}]}}

Transactions

Émettre une transaction avec /v3/kv/txn :

# target CREATE
curl -L http://localhost:2379/v3/kv/txn \
  -X POST \
  -d '{"compare":[{"target":"CREATE","key":"Zm9v","createRevision":"2"}],"success":[{"requestPut":{"key":"Zm9v","value":"YmFy"}}]}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"3","raft_term":"2"},"succeeded":true,"responses":[{"response_put":{"header":{"revision":"3"}}}]}

# target VERSION
curl -L http://localhost:2379/v3/kv/txn \
  -X POST \
  -d '{"compare":[{"version":"4","result":"EQUAL","target":"VERSION","key":"Zm9v"}],"success":[{"requestRange":{"key":"Zm9v"}}]}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"6","raft_term":"3"},"succeeded":true,"responses":[{"response_range":{"header":{"revision":"6"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"6","version":"4","value":"YmF6"}],"count":"1"}}]}

Authentification

Mettez en place une authentification avec le service /v3/auth :

# create root user
curl -L http://localhost:2379/v3/auth/user/add \
  -X POST -d '{"name": "root", "password": "pass"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# create root role
curl -L http://localhost:2379/v3/auth/role/add \
  -X POST -d '{"name": "root"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# grant root role
curl -L http://localhost:2379/v3/auth/user/grant \
  -X POST -d '{"user": "root", "role": "root"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# enable auth
curl -L http://localhost:2379/v3/auth/enable -X POST -d '{}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

Authentifiez-vous auprès d’etcd pour obtenir un jeton d’authentification en utilisant /v3/auth/authenticate :

# get the auth token for the root user
curl -L http://localhost:2379/v3/auth/authenticate \
  -X POST -d '{"name": "root", "password": "pass"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"},"token":"sssvIpwfnLAcWAQH.9"}

Définissez l’en-tête Authorization sur le jeton d’authentification pour récupérer une clé à l’aide des identifiants d’authentification :

curl -L http://localhost:2379/v3/kv/put \
  -H 'Authorization: sssvIpwfnLAcWAQH.9' \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"2","raft_term":"2"}}

Réponses d’erreur

La passerelle gRPC traduit les états gRPC en codes d’état HTTP et un corps d’erreur au format JSON. À compter d’etcd v3.6, la mise à jour vers grpc-gateway v2 a modifié la gestion des erreurs (voir la note gestion des erreurs dans le guide de migration v2), et le comportement de la passerelle est désormais conforme à google.rpc.Status (code, message, détails) tel que décrit dans modèle d’erreur d’API de Google . Historiquement, les versions antérieures de grpc-gateway incluaient également un champ de niveau supérieur error, mais ce champ n’est plus pris en charge à partir d’etcd v3.6 et des versions ultérieures.

Les clients doivent considérer le code d’état HTTP comme l’indicateur principal de succès ou d’échec. Si une requête échoue, les clients doivent s’appuyer sur le champ message comme source principale d’information d’erreur et utiliser tout détail supplémentaire pour obtenir un contexte plus précis.

Swagger

Les définitions d’API Swagger générées peuvent être trouvées dans rpc.swagger.json .

5 - Découverte et nommage gRPC

etcd fournit un résolveur gRPC afin de prendre en charge un système de noms alternatif qui récupère les points d’accès depuis etcd pour la découverte de services gRPC. Le mécanisme sous-jacent repose sur la surveillance des mises à jour des clés préfixées par le nom du service.

Notez que cette fonctionnalité est expérimentale car elle dépend du paquet google.golang.org/grpc/resolver , qui reste expérimental dans grpc-go.

Utilisation de la découverte etcd avec go-grpc

Le client etcd fournit un résolveur gRPC permettant de résoudre les points d’accès gRPC à l’aide d’un backend etcd. Le résolveur est initialisé avec un client etcd :

import (
	clientv3 "go.etcd.io/etcd/client/v3"
	etcdnaming "go.etcd.io/etcd/client/v3/naming/resolver"

	"google.golang.org/grpc"
)

...

cli, err := clientv3.NewFromURL("http://localhost:2379")
if err != nil {
    // ...
}
r, err := etcdnaming.NewBuilder(cli)
if err != nil {
    // ...
}
conn, gerr := grpc.NewClient("my-service", grpc.WithResolvers(r), ...)

Gestion des points de terminaison de service

Le résolveur etcd traite toutes les clés situées sous le préfixe de la cible de résolution suivant un “/” (par exemple, “foo/bar/my-service/”) dont les valeurs sont encodées au format JSON (historiquement go-grpc naming.Update) comme des points de terminaison de service potentiels. Les points de terminaison sont ajoutés au service en créant de nouvelles clés et supprimés du service en supprimant des clés.

Ajout d’un point de terminaison

De nouveaux points de terminaison peuvent être ajoutés au service via etcdctl :

ETCDCTL_API=3 etcdctl put foo/bar/my-service/1.2.3.4 '{"Addr":"1.2.3.4"}'

La méthode endpoints.Manager du client etcd peut également enregistrer de nouveaux points d’accès avec une clé correspondant à Addr :

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.AddEndpoint(context.TODO(),"foo/bar/my-service/e1", endpoints.Endpoint{Addr:"1.2.3.4"})

Pour activer l’équilibrage de charge en boucle (round-robin) lors de la connexion à un service disposant de plusieurs points d’accès, vous pouvez configurer votre connexion avec le chargeur de charge interne gRPC en boucle :

conn, gerr := grpc.NewClient("etcd:///foo", grpc.WithResolvers(etcdResolver),
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`))

Suppression d’un point de terminaison

Les hôtes peuvent être supprimés du service via etcdctl :

ETCDCTL_API=3 etcdctl del foo/bar/my-service/1.2.3.4

La méthode endpoints.Manager du client etcd prend également en charge la suppression des points de terminaison :

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.DeleteEndpoint(context.TODO(), "foo/bar/my-service/e1")

Inscrire un point de terminaison avec un bail

Inscrire un point de terminaison avec un bail garantit que, si l’hôte ne peut pas maintenir un signal de cœur (par exemple, en cas de panne matérielle), il sera retiré du service :

lease=`ETCDCTL_API=3 etcdctl lease grant 5 | cut -f2 -d' '`
ETCDCTL_API=3 etcdctl put --lease=$lease my-service/1.2.3.4 '{"Addr":"1.2.3.4"}'
ETCDCTL_API=3 etcdctl lease keep-alive $lease

En Go :

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.AddEndpoint(context.TODO(), "foo/bar/my-service/e1", endpoints.Endpoint{Addr:"1.2.3.4"})

Mise à jour atomique des points de terminaison

Si l’on souhaite modifier plusieurs points de terminaison dans une seule transaction, endpoints.Manager peut être utilisé directement :

em := endpoints.NewManager(c, "foo")

err := em.Update(context.TODO(), []*endpoints.UpdateWithOpts{
    endpoints.NewDeleteUpdateOpts("foo/bar/my-service/e1", endpoints.Endpoint{Addr: "1.2.3.4"}),
	endpoints.NewAddUpdateOpts("foo/bar/my-service/e1", endpoints.Endpoint{Addr: "1.2.3.14"})})

6 - Intégration d'etcd dans une application Go

Le paquet go etcd embed fournit un moyen simple d’intégrer un serveur etcd directement dans votre application.

Pour plus de détails, consultez la documentation du paquet embed .

7 - Limites système

Limite de taille de requête

etcd est conçu pour gérer des paires clé-valeur de petite taille, typiques des métadonnées. Les requêtes plus grandes fonctionnent, mais peuvent augmenter la latence des autres requêtes. Par défaut, la taille maximale de toute requête est de 1,5 MiB. Cette limite est configurable via le drapeau --max-request-bytes du serveur etcd.

Limite de taille du stockage

La limite par défaut de taille de stockage est de 2 GiB, configurable à l’aide du drapeau --quota-backend-bytes. Une taille maximale de 8 GiB est recommandée pour les environnements normaux, et etcd émet un avertissement au démarrage si la valeur configurée la dépasse.

8 - etcd features

Ce document présente un aperçu des fonctionnalités d’etcd afin d’aider les utilisateurs à mieux comprendre ces fonctionnalités et le processus de mise hors service associé. Si vous souhaitez en savoir plus sur la manière dont les fonctionnalités sont développées dans etcd, veuillez consulter ces guides de développement .

Les fonctionnalités d’etcd sont classées en trois états : expérimentales, stables et non sécurisées. Vous pouvez obtenir la liste des fonctionnalités en exécutant etcd --help.

Expérimental

Afin d’obtenir un retour rapide, toute nouvelle fonctionnalité est généralement ajoutée en tant que fonctionnalité expérimentale. Une fonctionnalité expérimentale peut être identifiée en examinant le nom du drapeau, qui doit comporter le préfixe --experimental. Veuillez prendre en compte les points suivants lors de l’utilisation d’une fonctionnalité expérimentale :

• Elle peut contenir des bogues en raison d’un manque de tests utilisateurs. Son activation peut ne pas fonctionner comme prévu.
• Elle est désactivée par défaut.
• Le support de cette fonctionnalité peut être supprimé à tout moment sans préavis.
  • Elle peut être supprimée dans la prochaine version mineure ou majeure sans respecter la politique de dépréciation des fonctionnalités , sauf si elle devient stable.
  • L’équipe du projet apprécierait que les utilisateurs signalent tout problème lié aux fonctionnalités expérimentales. Toutefois, ces problèmes peuvent être priorisés plus bassement que ceux liés aux fonctionnalités stables.
• Un indicateur de fonctionnalité expérimentale est déprécié lorsqu’il atteint l’état stable. Les utilisateurs doivent adopter l’indicateur stable dès que possible.

Stable

Ce stade est le plus courant pour les fonctionnalités dans etcd. Une fonctionnalité stable est caractérisée comme suit :

• Prise en charge dans le cadre des versions prises en charge d’etcd.
• Peut être activée par défaut.
• La suppression du support doit respecter la politique de dépréciation de fonctionnalité .

Non sécurisé

Les fonctionnalités non sécurisées sont rares et listées dans la section Unsafe feature: de la documentation d’utilisation d’etcd. Par défaut, elles sont désactivées. Elles doivent être utilisées avec précaution, conformément à la documentation. Une fonctionnalité non sécurisée peut être supprimée dans la prochaine version mineure ou majeure sans respecter la politique de dépréciation des fonctionnalités.

Dépréciation de fonctionnalité

Expérimental

Une fonctionnalité expérimentale est dépréciée lorsqu’elle atteint l’étape stable.

• La documentation de la fonctionnalité expérimentale affichera un message de dépréciation accompagné d’une recommandation visant à utiliser un indicateur de fonctionnalité stable associé. Par exemple, DEPRECATED. Use <feature-name> instead.
• Une fonctionnalité dépréciée sera supprimée dans la version suivante.

Stable

Lorsque le projet évolue, une fonctionnalité stable peut parfois devoir être dépréciée et supprimée. Lorsque cela se produit,

• la documentation de la fonctionnalité affichera un message d’avertissement avant la version planifiée de dépréciation. Par exemple, To be deprecated in <release>.. Si une nouvelle fonctionnalité est déjà prévue pour remplacer la fonctionnalité To be deprecated, la documentation indiquera également ce fait. Par exemple, Use <feature-name> instead..
• La fonctionnalité sera dépréciée lors de la version planifiée. À ce moment-là, la documentation de la fonctionnalité affichera un message de dépréciation accompagné d’une recommandation d’utilisation d’une fonctionnalité stable associée. Par exemple, DEPRECATED. Use <feature-name> instead..
• Une fonctionnalité dépréciée sera supprimée lors de la version suivante.

9 - Référence de l'API

Cette référence d’API est générée automatiquement à partir des fichiers nommés .proto.

service Auth (api/etcdserverpb/rpc.proto)

service Cluster (api/etcdserverpb/rpc.proto)

service KV (api/etcdserverpb/rpc.proto)

service Lease (api/etcdserverpb/rpc.proto)

service Maintenance (api/etcdserverpb/rpc.proto)

service Watch (api/etcdserverpb/rpc.proto)

message AlarmMember (api/etcdserverpb/rpc.proto)

message AlarmRequest (api/etcdserverpb/rpc.proto)

message AlarmResponse (api/etcdserverpb/rpc.proto)

message AuthDisableRequest (api/etcdserverpb/rpc.proto)

message AuthDisableResponse (api/etcdserverpb/rpc.proto)

message AuthEnableRequest (api/etcdserverpb/rpc.proto)

message AuthEnableResponse (api/etcdserverpb/rpc.proto)

message AuthRoleAddRequest (api/etcdserverpb/rpc.proto)

message AuthRoleAddResponse (api/etcdserverpb/rpc.proto)

message AuthRoleDeleteRequest (api/etcdserverpb/rpc.proto)

message AuthRoleDeleteResponse (api/etcdserverpb/rpc.proto)

message AuthRoleGetRequest (api/etcdserverpb/rpc.proto)

message AuthRoleGetResponse (api/etcdserverpb/rpc.proto)

message AuthRoleGrantPermissionRequest (api/etcdserverpb/rpc.proto)

message AuthRoleGrantPermissionResponse (api/etcdserverpb/rpc.proto)

message AuthRoleListRequest (api/etcdserverpb/rpc.proto)

message AuthRoleListResponse (api/etcdserverpb/rpc.proto)

message AuthRoleRevokePermissionRequest (api/etcdserverpb/rpc.proto)

message AuthRoleRevokePermissionResponse (api/etcdserverpb/rpc.proto)

message AuthStatusRequest (api/etcdserverpb/rpc.proto)

message AuthStatusResponse (api/etcdserverpb/rpc.proto)

message AuthUserAddRequest (api/etcdserverpb/rpc.proto)

message AuthUserAddResponse (api/etcdserverpb/rpc.proto)

message AuthUserChangePasswordRequest (api/etcdserverpb/rpc.proto)

message AuthUserChangePasswordResponse (api/etcdserverpb/rpc.proto)

message AuthUserDeleteRequest (api/etcdserverpb/rpc.proto)

message AuthUserDeleteResponse (api/etcdserverpb/rpc.proto)

message AuthUserGetRequest (api/etcdserverpb/rpc.proto)

message AuthUserGetResponse (api/etcdserverpb/rpc.proto)

message AuthUserGrantRoleRequest (api/etcdserverpb/rpc.proto)

message AuthUserGrantRoleResponse (api/etcdserverpb/rpc.proto)

message AuthUserListRequest (api/etcdserverpb/rpc.proto)

message AuthUserListResponse (api/etcdserverpb/rpc.proto)

message AuthUserRevokeRoleRequest (api/etcdserverpb/rpc.proto)

message AuthUserRevokeRoleResponse (api/etcdserverpb/rpc.proto)

message AuthenticateRequest (api/etcdserverpb/rpc.proto)

message AuthenticateResponse (api/etcdserverpb/rpc.proto)

message CompactionRequest (api/etcdserverpb/rpc.proto)

CompactionRequest compacte le magasin clé-valeur jusqu’à une révision donnée. Toutes les clés obsolètes dont la révision est inférieure à la révision de compactage seront supprimées.

message CompactionResponse (api/etcdserverpb/rpc.proto)

message Compare (api/etcdserverpb/rpc.proto)

message DefragmentRequest (api/etcdserverpb/rpc.proto)

message DefragmentResponse (api/etcdserverpb/rpc.proto)

message DeleteRangeRequest (api/etcdserverpb/rpc.proto)

message DeleteRangeResponse (api/etcdserverpb/rpc.proto)

message DowngradeInfo (api/etcdserverpb/rpc.proto)

message DowngradeRequest (api/etcdserverpb/rpc.proto)

message DowngradeResponse (api/etcdserverpb/rpc.proto)

message DowngradeVersionTestRequest (api/etcdserverpb/rpc.proto)

DowngradeVersionTestRequest n’est utilisé que à des fins de test. La version indiquée dans cette requête sera lue comme la version des enregistrements WAL. Si la version cible du downgrade est inférieure à cette version, alors le downgrade (en ligne) ou la migration (hors ligne) n’est pas sécurisé, et ne doit donc pas être autorisé.

message HashKVRequest (api/etcdserverpb/rpc.proto)

message HashKVResponse (api/etcdserverpb/rpc.proto)

message HashRequest (api/etcdserverpb/rpc.proto)

message HashResponse (api/etcdserverpb/rpc.proto)

message LeaseCheckpoint (api/etcdserverpb/rpc.proto)

message LeaseCheckpointRequest (api/etcdserverpb/rpc.proto)

message LeaseCheckpointResponse (api/etcdserverpb/rpc.proto)

message LeaseGrantRequest (api/etcdserverpb/rpc.proto)

message LeaseGrantResponse (api/etcdserverpb/rpc.proto)

message LeaseKeepAliveRequest (api/etcdserverpb/rpc.proto)

message LeaseKeepAliveResponse (api/etcdserverpb/rpc.proto)

message LeaseLeasesRequest (api/etcdserverpb/rpc.proto)

message LeaseLeasesResponse (api/etcdserverpb/rpc.proto)

message LeaseRevokeRequest (api/etcdserverpb/rpc.proto)

message LeaseRevokeResponse (api/etcdserverpb/rpc.proto)

message LeaseStatus (api/etcdserverpb/rpc.proto)

message LeaseTimeToLiveRequest (api/etcdserverpb/rpc.proto)

message LeaseTimeToLiveResponse (api/etcdserverpb/rpc.proto)

message Member (api/etcdserverpb/rpc.proto)

message MemberAddRequest (api/etcdserverpb/rpc.proto)

message MemberAddResponse (api/etcdserverpb/rpc.proto)

message MemberListRequest (api/etcdserverpb/rpc.proto)

message MemberListResponse (api/etcdserverpb/rpc.proto)

message MemberPromoteRequest (api/etcdserverpb/rpc.proto)

message MemberPromoteResponse (api/etcdserverpb/rpc.proto)

message MemberRemoveRequest (api/etcdserverpb/rpc.proto)

message MemberRemoveResponse (api/etcdserverpb/rpc.proto)

message MemberUpdateRequest (api/etcdserverpb/rpc.proto)

message MemberUpdateResponse (api/etcdserverpb/rpc.proto)

message MoveLeaderRequest (api/etcdserverpb/rpc.proto)

message MoveLeaderResponse (api/etcdserverpb/rpc.proto)

message PutRequest (api/etcdserverpb/rpc.proto)

message PutResponse (api/etcdserverpb/rpc.proto)

message RangeRequest (api/etcdserverpb/rpc.proto)

message RangeResponse (api/etcdserverpb/rpc.proto)

message RequestOp (api/etcdserverpb/rpc.proto)

message ResponseHeader (api/etcdserverpb/rpc.proto)

message ResponseOp (api/etcdserverpb/rpc.proto)

message SnapshotRequest (api/etcdserverpb/rpc.proto)

message SnapshotResponse (api/etcdserverpb/rpc.proto)

message StatusRequest (api/etcdserverpb/rpc.proto)

message StatusResponse (api/etcdserverpb/rpc.proto)

message TxnRequest (api/etcdserverpb/rpc.proto)

Du papier Google PaxosDB : Notre implémentation repose sur une primitive puissante que nous appelons MultiOp. Toutes les autres opérations sur la base de données, à l’exception de l’itération, sont implémentées comme un appel unique à MultiOp. Un MultiOp est appliqué de manière atomique et se compose de trois composants : 1. Une liste de tests appelée garde. Chaque test dans la garde vérifie une entrée unique dans la base de données. Il peut vérifier l’absence ou la présence d’une valeur, ou comparer avec une valeur donnée. Deux tests différents dans la garde peuvent s’appliquer à la même ou à des entrées différentes dans la base de données. Tous les tests de la garde sont appliqués, et MultiOp retourne les résultats. Si tous les tests sont vrais, MultiOp exécute l’opération t op (voir l’élément 2 ci-dessous), sinon il exécute l’opération f op (voir l’élément 3 ci-dessous). 2. Une liste d’opérations sur la base de données appelée t op. Chaque opération de la liste est soit une opération d’insertion, de suppression ou de recherche, et s’applique à une seule entrée de la base de données. Deux opérations différentes de la liste peuvent s’appliquer à la même ou à des entrées différentes dans la base de données. Ces opérations sont exécutées si la garde évalue à vrai. 3. Une liste d’opérations sur la base de données appelée f op. Comme t op, mais exécutée si la garde évalue à faux.

message TxnResponse (api/etcdserverpb/rpc.proto)

message WatchCancelRequest (api/etcdserverpb/rpc.proto)

message WatchCreateRequest (api/etcdserverpb/rpc.proto)

message WatchProgressRequest (api/etcdserverpb/rpc.proto)

Demande que le statut d’avancement du flux de surveillance soit envoyé dans le flux de réponse de surveillance dès que possible.

message WatchRequest (api/etcdserverpb/rpc.proto)

message WatchResponse (api/etcdserverpb/rpc.proto)

message Event (api/mvccpb/kv.proto)

message KeyValue (api/mvccpb/kv.proto)

message Lease (server/lease/leasepb/lease.proto)

message LeaseInternalRequest (server/lease/leasepb/lease.proto)

message LeaseInternalResponse (server/lease/leasepb/lease.proto)

message Permission (api/authpb/auth.proto)

Les autorisations constituent une entité unique

message Role (api/authpb/auth.proto)

Le rôle est une entrée unique dans le bac authRoles

message User (api/authpb/auth.proto)

Utilisateur est une entrée unique dans le bucket authUsers

message UserAddOptions (api/authpb/auth.proto)

10 - Référence API : concurrence

Cette référence d’API est générée automatiquement à partir des fichiers nommés .proto.

service Lock (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Le service de verrouillage expose des fonctionnalités de verrouillage côté client sous forme d’une interface gRPC.

message LockRequest (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

message LockResponse (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

message UnlockRequest (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

message UnlockResponse (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

service Election (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Le service d’élection expose des fonctionnalités d’élection côté client sous forme d’une interface gRPC.

message CampaignRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message CampaignResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message LeaderKey (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message LeaderRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message LeaderResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message ProclaimRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message ProclaimResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message ResignRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message ResignResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

message Event (api/mvccpb/kv.proto)

message KeyValue (api/mvccpb/kv.proto)