mirror of https://github.com/dapr/docs.git
add configuration api how-to and overview placeholder (#1928)
* add configuration api how-to and overview placeholder * fix code tab * change format * add docs * Updated to text * Update building-blocks-concept.md * Minor updates * Update to overview Co-authored-by: Mark Fussell <mfussell@microsoft.com>
This commit is contained in:
parent
441e95a365
commit
632ab379dc
|
|
@ -26,4 +26,5 @@ The following are the building blocks provided by Dapr:
|
|||
| [**Resource bindings**]({{<ref "bindings-overview.md">}}) | `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service.
|
||||
| [**Actors**]({{<ref "actors-overview.md">}}) | `/v1.0/actors` | An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the Virtual Actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use.
|
||||
| [**Observability**]({{<ref "observability-concept.md">}}) | `N/A` | Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications.
|
||||
| [**Secrets**]({{<ref "secrets-overview.md">}}) | `/v1.0/secrets` | Dapr offers a secrets building block API and integrates with secret stores such as Azure Key Vault and Kubernetes to store the secrets. Service code can call the secrets API to retrieve secrets out of the Dapr supported secret stores.
|
||||
| [**Secrets**]({{<ref "secrets-overview.md">}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as Hashicorp valut, local files, Azure Key Vault and Kubernetes to store the secrets. Services can call the secrets API to retrieve secrets, for example to get a connection string to a database.
|
||||
| [**Configuration**]({{<ref "app-configuration-overview.md">}}) | `/v1.0/configuration` | Dapr provides a Configuration API that enables you to retrieve and subscribe to application configuration items for Dapr supported configuration stores. This enables an application to set specific configuration information for example at start up or when configuration changes are made in the stores.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Configuration"
|
||||
linkTitle: "Configuration"
|
||||
weight: 30
|
||||
description: Manage application configuration
|
||||
---
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Configuration overview"
|
||||
linkTitle: "Configuration overview"
|
||||
weight: 1000
|
||||
description: "Use Dapr to get and watch application configuration"
|
||||
---
|
||||
|
||||
Consuming application configuration is a common task when writing applications and frequently configuration stores are used to manage this configuration data. A configuration item is often dynamic in nature and is tightly coupled to the needs of the application that consumes it. For example, common uses for application configuration include names of secrets that need to be retrieved, different identifiers, partition or consumer IDs, names of databased to connect to etc. These configuration items are typically stored as key-value items in a database.
|
||||
|
||||
Dapr provides a [State Management API]({{<ref "state-management-overview.md">}})) that is based on key-value stores. However, application configuration can be changed by either developers or operators at runtime and the developer needs to be notified of these changes in order to take the required action and load the new configuration. Also the configuration data may want to be read only. Dapr's Configuration API allows developers to consume configuration items that are returned as key/value pair and subscribe to changes whenever a configuration item changes.
|
||||
|
||||
*This API is currently in `Alpha state` and only available on gRPC. An HTTP1.1 supported version with this URL `/v1.0/configuration` will be available before the API becomes stable. *
|
||||
|
||||
## References
|
||||
|
||||
- [How-To: Manage application configuration]({{< ref howto-manage-configuration.md >}})
|
||||
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Manage application configuration"
|
||||
linkTitle: "How-To: Manage application configuration"
|
||||
weight: 2000
|
||||
description: "Learn how to get application configuration and watch for changes"
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Consuming application configuration is a common task when writing applications and frequently configuration stores are used to manage this configuration data. A configuration item is often dynamic in nature and is tightly coupled to the needs of the application that consumes it. For example, common uses for application configuration include names of secrets that need to be retrieved, different identifiers, partition or consumer IDs, names of databased to connect to etc. These configuration items are typically stored as key-value items in a database.
|
||||
|
||||
Dapr provides a [State Management API]({{<ref "state-management-overview.md">}})) that is based on key-value stores. However, application configuration can be changed by either developers or operators at runtime and the developer needs to be notified of these changes in order to take the required action and load the new configuration. Also the configuration data may want to be read only. Dapr's Configuration API allows developers to consume configuration items that are returned as key/value pair and subscribe to changes whenever a configuration item changes.
|
||||
|
||||
*This API is currently in `Alpha state` and only available on gRPC. An HTTP1.1 supported version with this URL `/v1.0/configuration` will be available before the API becomes stable. *
|
||||
|
||||
This HowTo uses the Redis configuration store component as an exmaple to retrieve a configuration item.
|
||||
|
||||
## Step 1: Save a configuration item
|
||||
|
||||
First, create a configuration item in a supported configuration store. This can be a simple key-value item, with any key of your choice. For this example, we'll use the Redis configuration store component
|
||||
|
||||
### Run Redis with Docker
|
||||
|
||||
```
|
||||
docker run --name my-redis -p 6379:6379 -d redis
|
||||
```
|
||||
|
||||
### Save an item
|
||||
|
||||
Using the [Redis CLI](https://redis.com/blog/get-redis-cli-without-installing-redis-server/), connect to the Redis instance:
|
||||
|
||||
```
|
||||
redis-cli -p 6379
|
||||
```
|
||||
|
||||
Save a configuration item:
|
||||
|
||||
```
|
||||
set myconfig "wookie"
|
||||
```
|
||||
|
||||
### Configure a Dapr configuration store
|
||||
|
||||
Save the following file component file, for example to the default components folder on your machine. You can use this as the Dapr component YAML for Kubernetes using kubectl or when running with the Dapr CLI. Hint: The Redis configuration component has identical metadata to the Redis statestore component, so you can simply copy and change the component type if you already have a Redis statestore YAML file.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: redisconfiguration
|
||||
spec:
|
||||
type: configuration.redis
|
||||
metadata:
|
||||
- name: host
|
||||
value: localhost:6379
|
||||
```
|
||||
|
||||
### Get configuration items using gRPC API
|
||||
|
||||
Using your [favorite language](https://grpc.io/docs/languages/), create a Dapr gRPC client from the [Dapr proto](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/dapr.proto). The following examples show Java, C#, Python and Javascript clients.
|
||||
|
||||
{{< tabs Java Dotnet Python Javascript >}}
|
||||
|
||||
{{% codetab %}}
|
||||
```java
|
||||
|
||||
Dapr.ServiceBlockingStub stub = Dapr.newBlockingStub(channel);
|
||||
stub.GetConfigurationAlpha1(new GetConfigurationRequest{ StoreName = "redisconfig", Keys = new String[]{"myconfig"} });
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```csharp
|
||||
|
||||
var call = client.GetConfigurationAlpha1(new GetConfigurationRequest { StoreName = "redisconfig", Keys = new String[]{"myconfig"} });
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```python
|
||||
response = stub.GetConfigurationAlpha1(request={ StoreName: 'redisconfig', Keys = ['myconfig'] })
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```javascript
|
||||
client.GetConfigurationAlpha1({ StoreName: 'redisconfig', Keys = ['myconfig'] })
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
### Watch configuration items
|
||||
|
||||
Using your [favorite language](https://grpc.io/docs/languages/), create a Dapr gRPC client from the [Dapr proto](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/dapr.proto).
|
||||
Use the proto method `SubscribeConfigurationAlpha1` on your client stub to start subscribing to events. The method accepts the following request object:
|
||||
|
||||
```proto
|
||||
message SubscribeConfigurationRequest {
|
||||
// The name of configuration store.
|
||||
string store_name = 1;
|
||||
|
||||
// Optional. The key of the configuration item to fetch.
|
||||
// If set, only query for the specified configuration items.
|
||||
// Empty list means fetch all.
|
||||
repeated string keys = 2;
|
||||
|
||||
// The metadata which will be sent to configuration store components.
|
||||
map<string,string> metadata = 3;
|
||||
}
|
||||
```
|
||||
|
||||
Using this method, you can subscribe to changes in specific keys for a given configuration store. gRPC streaming varies widely based on language - see the [gRPC examples here](https://grpc.io/docs/languages/) for usage.
|
||||
Loading…
Reference in New Issue