2015-01-17 20:27:27 +00:00
|
|
|
---
|
|
|
|
layout: "docs"
|
2015-01-18 00:28:53 +00:00
|
|
|
page_title: "Key/Value store (HTTP)"
|
2015-01-17 20:27:27 +00:00
|
|
|
sidebar_current: "docs-agent-http-kv"
|
2015-01-18 00:28:53 +00:00
|
|
|
description: >
|
2015-02-12 02:54:03 +00:00
|
|
|
The KV endpoint is used to access Consul's simple key/value store, useful for storing
|
2015-02-12 04:44:10 +00:00
|
|
|
service configuration or other metadata.
|
2015-01-17 20:27:27 +00:00
|
|
|
---
|
|
|
|
|
2015-01-18 00:28:53 +00:00
|
|
|
# Key/Value HTTP Endpoint
|
|
|
|
|
2015-02-12 02:54:03 +00:00
|
|
|
The KV endpoint is used to access Consul's simple key/value store, useful for storing
|
2015-02-12 04:44:10 +00:00
|
|
|
service configuration or other metadata.
|
2015-02-12 02:54:03 +00:00
|
|
|
|
|
|
|
It has only a single endpoint:
|
2015-01-18 00:28:53 +00:00
|
|
|
|
|
|
|
/v1/kv/<key>
|
|
|
|
|
2015-02-12 02:54:03 +00:00
|
|
|
The `GET`, `PUT` and `DELETE` methods are all supported.
|
|
|
|
|
2015-02-12 04:44:10 +00:00
|
|
|
By default, the datacenter of the agent is queried; however, the dc can be provided
|
2015-02-12 02:54:03 +00:00
|
|
|
using the "?dc=" query parameter. It is important to note that each datacenter has
|
|
|
|
its own KV store, and there is no built-in replication between datacenters. If you
|
2015-02-12 04:44:10 +00:00
|
|
|
are interested in replication between datacenters, look at the
|
2015-02-25 01:29:41 +00:00
|
|
|
[Consul Replicate project](https://github.com/hashicorp/consul-replicate).
|
2015-01-18 00:28:53 +00:00
|
|
|
|
2015-02-12 02:54:03 +00:00
|
|
|
The KV endpoint supports the use of ACL tokens.
|
2015-01-18 00:28:53 +00:00
|
|
|
|
|
|
|
### GET Method
|
|
|
|
|
2015-02-12 02:54:03 +00:00
|
|
|
When using the `GET` method, Consul will return the specified key.
|
|
|
|
If the "?recurse" query parameter is provided, it will return
|
2015-01-18 00:28:53 +00:00
|
|
|
all keys with the given prefix.
|
|
|
|
|
2015-02-12 02:54:03 +00:00
|
|
|
This endpoint supports blocking queries and all consistency modes.
|
|
|
|
|
2015-01-18 00:28:53 +00:00
|
|
|
Each object will look like:
|
|
|
|
|
|
|
|
```javascript
|
|
|
|
[
|
|
|
|
{
|
|
|
|
"CreateIndex": 100,
|
|
|
|
"ModifyIndex": 200,
|
|
|
|
"LockIndex": 200,
|
|
|
|
"Key": "zip",
|
|
|
|
"Flags": 0,
|
|
|
|
"Value": "dGVzdA==",
|
|
|
|
"Session": "adf4238a-882b-9ddc-4a9d-5b6758e4159e"
|
|
|
|
}
|
|
|
|
]
|
|
|
|
```
|
|
|
|
|
2015-02-12 02:54:03 +00:00
|
|
|
`CreateIndex` is the internal index value that represents
|
|
|
|
when the entry was created.
|
|
|
|
|
|
|
|
`ModifyIndex` is the last index that modified this key. This index corresponds
|
|
|
|
to the `X-Consul-Index` header value that is returned in responses, and it can
|
|
|
|
be used to establish blocking queries by setting the "?index" query parameter.
|
|
|
|
You can even perform blocking queries against entire subtrees of the KV store:
|
|
|
|
if "?recurse" is provided, the returned `X-Consul-Index` corresponds
|
|
|
|
to the latest `ModifyIndex` within the prefix, and a blocking query using that
|
|
|
|
"?index" will wait until any key within that prefix is updated.
|
|
|
|
|
2015-10-09 16:04:52 +00:00
|
|
|
`LockIndex` is the number of times this key has successfully been acquired in
|
|
|
|
a lock. If the lock is held, the `Session` key provides the session that owns
|
|
|
|
the lock.
|
2015-02-12 02:54:03 +00:00
|
|
|
|
|
|
|
`Key` is simply the full path of the entry.
|
|
|
|
|
|
|
|
`Flags` are an opaque unsigned integer that can be attached to each entry. Clients
|
|
|
|
can choose to use this however makes sense for their application.
|
|
|
|
|
|
|
|
`Value` is a Base64-encoded blob of data. Note that values cannot be larger than
|
|
|
|
512kB.
|
|
|
|
|
|
|
|
It is possible to list just keys without their values by using the "?keys" query
|
|
|
|
parameter. This will return a list of the keys under the given prefix. The optional
|
|
|
|
"?separator=" can be used to list only up to a given separator.
|
2015-01-18 00:28:53 +00:00
|
|
|
|
|
|
|
For example, listing "/web/" with a "/" separator may return:
|
|
|
|
|
|
|
|
```javascript
|
|
|
|
[
|
|
|
|
"/web/bar",
|
|
|
|
"/web/foo",
|
|
|
|
"/web/subdir/"
|
|
|
|
]
|
|
|
|
```
|
|
|
|
|
|
|
|
Using the key listing method may be suitable when you do not need
|
2015-02-12 02:54:03 +00:00
|
|
|
the values or flags or want to implement a key-space explorer.
|
2015-01-18 00:28:53 +00:00
|
|
|
|
|
|
|
If the "?raw" query parameter is used with a non-recursive GET,
|
2015-02-12 02:54:03 +00:00
|
|
|
the response is just the raw value of the key, without any
|
2015-01-18 00:28:53 +00:00
|
|
|
encoding.
|
|
|
|
|
|
|
|
If no entries are found, a 404 code is returned.
|
|
|
|
|
|
|
|
### PUT method
|
|
|
|
|
|
|
|
When using the `PUT` method, Consul expects the request body to be the
|
2015-02-12 02:54:03 +00:00
|
|
|
value corresponding to the key. There are a number of query parameters that can
|
2015-01-18 00:28:53 +00:00
|
|
|
be used with a PUT request:
|
|
|
|
|
|
|
|
* ?flags=\<num\> : This can be used to specify an unsigned value between
|
2015-11-17 23:21:47 +00:00
|
|
|
0 and (2^64)-1. Clients can choose to use this however makes sense for their application.
|
2015-01-18 00:28:53 +00:00
|
|
|
|
|
|
|
* ?cas=\<index\> : This flag is used to turn the `PUT` into a Check-And-Set
|
2015-02-12 02:54:03 +00:00
|
|
|
operation. This is very useful as a building block for more complex
|
|
|
|
synchronization primitives. If the index is 0, Consul will only
|
|
|
|
put the key if it does not already exist. If the index is non-zero,
|
2015-01-18 00:28:53 +00:00
|
|
|
the key is only set if the index matches the `ModifyIndex` of that key.
|
|
|
|
|
|
|
|
* ?acquire=\<session\> : This flag is used to turn the `PUT` into a lock acquisition
|
|
|
|
operation. This is useful as it allows leader election to be built on top
|
|
|
|
of Consul. If the lock is not held and the session is valid, this increments
|
|
|
|
the `LockIndex` and sets the `Session` value of the key in addition to updating
|
2015-10-09 16:04:52 +00:00
|
|
|
the key contents. A key does not need to exist to be acquired. If the lock is
|
|
|
|
already held by the given session, then the `LockIndex` is not incremented but
|
|
|
|
the key contents are updated. This lets the current lock holder update the key
|
|
|
|
contents without having to give up the lock and reacquire it.
|
2015-01-18 00:28:53 +00:00
|
|
|
|
|
|
|
* ?release=\<session\> : This flag is used to turn the `PUT` into a lock release
|
|
|
|
operation. This is useful when paired with "?acquire=" as it allows clients to
|
|
|
|
yield a lock. This will leave the `LockIndex` unmodified but will clear the associated
|
|
|
|
`Session` of the key. The key must be held by this session to be unlocked.
|
|
|
|
|
2015-02-12 02:54:03 +00:00
|
|
|
The return value is either `true` or `false`. If `false` is returned,
|
|
|
|
the update has not taken place.
|
2015-01-18 00:28:53 +00:00
|
|
|
|
|
|
|
### DELETE method
|
|
|
|
|
|
|
|
The `DELETE` method can be used to delete a single key or all keys sharing
|
2015-02-12 02:54:03 +00:00
|
|
|
a prefix. There are a few query parameters that can be used with a
|
2015-01-18 00:28:53 +00:00
|
|
|
DELETE request:
|
|
|
|
|
|
|
|
* ?recurse : This is used to delete all keys which have the specified prefix.
|
|
|
|
Without this, only a key with an exact match will be deleted.
|
|
|
|
|
|
|
|
* ?cas=\<index\> : This flag is used to turn the `DELETE` into a Check-And-Set
|
2015-02-12 02:54:03 +00:00
|
|
|
operation. This is very useful as a building block for more complex
|
|
|
|
synchronization primitives. Unlike `PUT`, the index must be greater than 0
|
|
|
|
for Consul to take any action: a 0 index will not delete the key. If the index
|
|
|
|
is non-zero, the key is only deleted if the index matches the `ModifyIndex` of that key.
|