Merge branch 'v1.11' into nyemade-uversky-patch-1
|
@ -15,14 +15,54 @@ Now that you've read about [Cryptography as a Dapr building block]({{< ref crypt
|
|||
|
||||
## Encrypt
|
||||
|
||||
Using the Dapr gRPC APIs in your project, you can encrypt a stream of data, such as a file.
|
||||
{{< tabs "JavaScript" "Go" >}}
|
||||
|
||||
{{< tabs "Go" >}}
|
||||
{{% codetab %}}
|
||||
|
||||
<!--JavaScript-->
|
||||
|
||||
Using the Dapr SDK in your project, with the gRPC APIs, you can encrypt data in a buffer or a string:
|
||||
|
||||
```js
|
||||
// When passing data (a buffer or string), `encrypt` returns a Buffer with the encrypted message
|
||||
const ciphertext = await client.crypto.encrypt(plaintext, {
|
||||
// Name of the Dapr component (required)
|
||||
componentName: "mycryptocomponent",
|
||||
// Name of the key stored in the component (required)
|
||||
keyName: "mykey",
|
||||
// Algorithm used for wrapping the key, which must be supported by the key named above.
|
||||
// Options include: "RSA", "AES"
|
||||
keyWrapAlgorithm: "RSA",
|
||||
});
|
||||
```
|
||||
|
||||
The APIs can also be used with streams, to encrypt data more efficiently when it comes from a stream. The example below encrypts a file, writing to another file, using streams:
|
||||
|
||||
```js
|
||||
// `encrypt` can be used as a Duplex stream
|
||||
await pipeline(
|
||||
fs.createReadStream("plaintext.txt"),
|
||||
await client.crypto.encrypt({
|
||||
// Name of the Dapr component (required)
|
||||
componentName: "mycryptocomponent",
|
||||
// Name of the key stored in the component (required)
|
||||
keyName: "mykey",
|
||||
// Algorithm used for wrapping the key, which must be supported by the key named above.
|
||||
// Options include: "RSA", "AES"
|
||||
keyWrapAlgorithm: "RSA",
|
||||
}),
|
||||
fs.createWriteStream("ciphertext.out"),
|
||||
);
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
<!--go-->
|
||||
|
||||
Using the Dapr SDK in your project, you can encrypt a stream of data, such as a file.
|
||||
|
||||
```go
|
||||
out, err := sdkClient.Encrypt(context.Background(), rf, dapr.EncryptOptions{
|
||||
// Name of the Dapr component (required)
|
||||
|
@ -35,18 +75,8 @@ out, err := sdkClient.Encrypt(context.Background(), rf, dapr.EncryptOptions{
|
|||
})
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
The following example puts the `Encrypt` API in context, with code that reads the file, encrypts it, then stores the result in another file.
|
||||
|
||||
{{< tabs "Go" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
<!--go-->
|
||||
|
||||
```go
|
||||
// Input file, clear-text
|
||||
rf, err := os.Open("input")
|
||||
|
@ -81,18 +111,8 @@ if err != nil {
|
|||
fmt.Println("Written", n, "bytes")
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
The following example uses the `Encrypt` API to encrypt a string.
|
||||
|
||||
{{< tabs "Go" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
<!--go-->
|
||||
|
||||
```go
|
||||
// Input string
|
||||
rf := strings.NewReader("Amor, ch’a nullo amato amar perdona, mi prese del costui piacer sì forte, che, come vedi, ancor non m’abbandona")
|
||||
|
@ -121,15 +141,41 @@ if err != nil {
|
|||
|
||||
## Decrypt
|
||||
|
||||
To decrypt a file, add the `Decrypt` gRPC API to your project.
|
||||
{{< tabs "JavaScript" "Go" >}}
|
||||
|
||||
{{< tabs "Go" >}}
|
||||
{{% codetab %}}
|
||||
|
||||
<!--JavaScript-->
|
||||
|
||||
Using the Dapr SDK, you can decrypt data in a buffer or using streams.
|
||||
|
||||
```js
|
||||
// When passing data as a buffer, `decrypt` returns a Buffer with the decrypted message
|
||||
const plaintext = await client.crypto.decrypt(ciphertext, {
|
||||
// Only required option is the component name
|
||||
componentName: "mycryptocomponent",
|
||||
});
|
||||
|
||||
// `decrypt` can also be used as a Duplex stream
|
||||
await pipeline(
|
||||
fs.createReadStream("ciphertext.out"),
|
||||
await client.crypto.decrypt({
|
||||
// Only required option is the component name
|
||||
componentName: "mycryptocomponent",
|
||||
}),
|
||||
fs.createWriteStream("plaintext.out"),
|
||||
);
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
<!--go-->
|
||||
|
||||
In the following example, `out` is a stream that can be written to file or read in memory, as in the examples above.
|
||||
To decrypt a file, use the `Decrypt` gRPC API to your project.
|
||||
|
||||
In the following example, `out` is a stream that can be written to file or read in memory, as in the examples above.
|
||||
|
||||
```go
|
||||
out, err := sdkClient.Decrypt(context.Background(), rf, dapr.EncryptOptions{
|
||||
|
|
|
@ -186,7 +186,7 @@ Place `subscription.yaml` in the same directory as your `pubsub.yaml` component.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs to subscribe to the topic you defined in `subscription.yaml`.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript>}}
|
||||
{{< tabs Dotnet Java Python Go JavaScript>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ For more information on how workflow state is managed, see the [workflow archite
|
|||
|
||||
## Workflows
|
||||
|
||||
Dapr Workflows are functions you write that define a series of steps or tasks to be executed in a particular order. The Dapr Workflow engine takes care of coordinating and managing the execution of the steps, including managing failures and retries. If the app hosting your workflows is scaled out across multiple machines, the workflow engine may also load balance the execution of workflows and their tasks across multiple machines.
|
||||
Dapr Workflows are functions you write that define a series of tasks to be executed in a particular order. The Dapr Workflow engine takes care of scheduling and execution of the tasks, including managing failures and retries. If the app hosting your workflows is scaled out across multiple machines, the workflow engine may also load balance the execution of workflows and their tasks across multiple machines.
|
||||
|
||||
There are several different kinds of tasks that a workflow can schedule, including
|
||||
- [Activities]({{< ref "workflow-features-concepts.md#workflow-activities" >}}) for executing custom logic
|
||||
|
@ -24,7 +24,7 @@ There are several different kinds of tasks that a workflow can schedule, includi
|
|||
|
||||
### Workflow identity
|
||||
|
||||
Each workflow you define has a type name, and individual executions of a workflow have a unique _instance ID_. Workflow instance IDs can be generated by your app code, which is useful when workflows correspond to business entities like documents or jobs, or can be auto-generated UUIDs. A workflow's instance ID is useful for debugging and also for managing workflows using the [Workflow APIs]({{< ref workflow_api.md >}}).
|
||||
Each workflow you define has a type name, and individual executions of a workflow require a unique _instance ID_. Workflow instance IDs can be generated by your app code, which is useful when workflows correspond to business entities like documents or jobs, or can be auto-generated UUIDs. A workflow's instance ID is useful for debugging and also for managing workflows using the [Workflow APIs]({{< ref workflow_api.md >}}).
|
||||
|
||||
Only one workflow instance with a given ID can exist at any given time. However, if a workflow instance completes or fails, its ID can be reused by a new workflow instance. Note, however, that the new workflow instance effectively replaces the old one in the configured state store.
|
||||
|
||||
|
@ -36,8 +36,8 @@ When a workflow "awaits" a scheduled task, it unloads itself from memory until t
|
|||
|
||||
When a workflow function is replayed, it runs again from the beginning. However, when it encounters a task that already completed, instead of scheduling that task again, the workflow engine:
|
||||
|
||||
1. Returns the result of the completed task to the workflow.
|
||||
1. Continues execution until the next "await" point.
|
||||
1. Returns the stored result of the completed task to the workflow.
|
||||
1. Continues execution until the next "await" point.
|
||||
|
||||
This "replay" behavior continues until the workflow function completes or fails with an error.
|
||||
|
||||
|
|
|
@ -10,32 +10,32 @@ description: "Overview of Dapr Workflow"
|
|||
Dapr Workflow is currently in alpha.
|
||||
{{% /alert %}}
|
||||
|
||||
Dapr Workflow makes orchestrating the logic required for messaging, state management, and failure handling across various microservices easier for developers. Dapr Workflow enables you to create long running, fault-tolerant, stateful applications. Prior to Dapr Workflow, you'd often need to build ad-hoc workflows in custom, complex code in order to achieve long running, fault-tolerant, stateful applications.
|
||||
Dapr workflow makes it easy for developers to write business logic and integrations in a reliable way. Since Dapr workflows are stateful, they support long-running and fault-tolerant applications, ideal for orchestrating microservices. Dapr workflow works seamlessly with other Dapr building blocks, such as service invocation, pub/sub, state management, and bindings.
|
||||
|
||||
The durable, resilient Dapr Workflow capability:
|
||||
|
||||
- Offers a built-in workflow runtime for driving Dapr Workflow execution
|
||||
- Provides SDKs for authoring workflows in code, using any language
|
||||
- Provides HTTP and gRPC APIs for managing workflows (start, query, suspend/resume, terminate)
|
||||
- Integrates with any other workflow runtime via workflow components
|
||||
- Offers a built-in workflow runtime for driving Dapr Workflow execution.
|
||||
- Provides SDKs for authoring workflows in code, using any language.
|
||||
- Provides HTTP and gRPC APIs for managing workflows (start, query, suspend/resume, terminate).
|
||||
- Integrates with any other workflow runtime via workflow components.
|
||||
|
||||
<img src="/images/workflow-overview/workflow-overview.png" width=800 alt="Diagram showing basics of Dapr Workflow">
|
||||
|
||||
Some example scenarios that Dapr Workflow can perform are:
|
||||
|
||||
- Order processing involving inventory management, payment systems, shipping, etc.
|
||||
- Order processing involving orchestration between inventory management, payment systems, and shipping services.
|
||||
- HR onboarding workflows coordinating tasks across multiple departments and participants.
|
||||
- Orchestrating the roll-out of digital menu updates in a national restaurant chain.
|
||||
- Image processing workflows involving API-based classification and storage.
|
||||
|
||||
|
||||
## Features
|
||||
|
||||
### Workflows and activities
|
||||
|
||||
With Dapr Workflow, you can write activites and then compose those activities together into a workflow. Workflow activities are:
|
||||
With Dapr Workflow, you can write activities and then orchestrate those activities in a workflow. Workflow activities are:
|
||||
|
||||
- The basic unit of work in a workflow
|
||||
- The tasks that get orchestrated in the business process
|
||||
- Used for calling other (Dapr) services, interacting with state stores, and pub/sub brokers.
|
||||
|
||||
[Learn more about workflow activities.]({{< ref "workflow-features-concepts.md##workflow-activities" >}})
|
||||
|
||||
|
@ -47,7 +47,7 @@ In addition to activities, you can write workflows to schedule other workflows a
|
|||
|
||||
### Timers and reminders
|
||||
|
||||
Same as Dapr actors, you can schedule reminder-like durable delays for any time range.
|
||||
Same as Dapr actors, you can schedule reminder-like durable delays for any time range.
|
||||
|
||||
[Learn more about workflow timers]({{< ref "workflow-features-concepts.md#durable-timers" >}}) and [reminders]({{< ref "workflow-architecture.md#reminder-usage-and-execution-guarantees" >}})
|
||||
|
||||
|
|
|
@ -12,10 +12,10 @@ Dapr Workflows simplify complex, stateful coordination requirements in microserv
|
|||
|
||||
In the task chaining pattern, multiple steps in a workflow are run in succession, and the output of one step may be passed as the input to the next step. Task chaining workflows typically involve creating a sequence of operations that need to be performed on some data, such as filtering, transforming, and reducing.
|
||||
|
||||
In some cases, the steps of the workflow may need to be orchestrated across multiple microservices. For increased reliability and scalability, you're also likely to use queues to trigger the various steps.
|
||||
|
||||
<img src="/images/workflow-overview/workflows-chaining.png" width=800 alt="Diagram showing how the task chaining workflow pattern works">
|
||||
|
||||
In some cases, the steps of the workflow may need to be orchestrated across multiple microservices. For increased reliability and scalability, you're also likely to use queues to trigger the various steps.
|
||||
|
||||
While the pattern is simple, there are many complexities hidden in the implementation. For example:
|
||||
|
||||
- What happens if one of the microservices are unavailable for an extended period of time?
|
||||
|
|
|
@ -64,8 +64,9 @@ cd ./crypto-quickstart
|
|||
```
|
||||
|
||||
The application code defines two required keys:
|
||||
|
||||
- Private RSA key
|
||||
- A 256-bit symmetric (AES) key
|
||||
- A 256-bit symmetric (AES) key
|
||||
|
||||
Generate two keys, an RSA key and and AES key using OpenSSL and write these to two files:
|
||||
|
||||
|
|
|
@ -6,14 +6,18 @@ weight: 4500
|
|||
description: "Choose which Dapr sidecar APIs are available to the app"
|
||||
---
|
||||
|
||||
In certain scenarios such as zero trust networks or when exposing the Dapr sidecar to external traffic through a frontend, it's recommended to only enable the Dapr sidecar APIs that are being used by the app. Doing so reduces the attack surface and helps keep the Dapr APIs scoped to the actual needs of the application.
|
||||
In certain scenarios, such as zero trust networks or when exposing the Dapr sidecar to external traffic through a frontend, it's recommended to only enable the Dapr sidecar APIs that are being used by the app. Doing so reduces the attack surface and helps keep the Dapr APIs scoped to the actual needs of the application.
|
||||
|
||||
Dapr allows developers to control which APIs are accessible to the application by setting an API allow list using a [Dapr Configuration]({{<ref "configuration-overview.md">}}).
|
||||
Dapr allows developers to control which APIs are accessible to the application by setting an API allowlist or denylist using a [Dapr Configuration]({{<ref "configuration-overview.md">}}).
|
||||
|
||||
### Default behavior
|
||||
|
||||
If an API allow list section is not specified, the default behavior is to allow access to all Dapr APIs.
|
||||
Once an allow list is set, only the specified APIs are accessible.
|
||||
If no API allowlist or denylist is specified, the default behavior is to allow access to all Dapr APIs.
|
||||
|
||||
- If only a denylist is defined, all Dapr APIs are allowed except those defined in the denylist
|
||||
- If only an allowlist is defined, only the Dapr APIs listed in the allowlist are allowed
|
||||
- If both an allowlist and a denylist are defined, the allowed APIs are those defined in the allowlist, unless they are also included in the denylist. In other words, the denylist overrides the allowlist for APIs that are defined in both.
|
||||
- If neither is defined, all APIs are allowed.
|
||||
|
||||
For example, the following configuration enables all APIs for both HTTP and gRPC:
|
||||
|
||||
|
@ -28,9 +32,11 @@ spec:
|
|||
samplingRate: "1"
|
||||
```
|
||||
|
||||
### Enabling specific HTTP APIs
|
||||
### Using an allowlist
|
||||
|
||||
The following example enables the state `v1.0` HTTP API and block all the rest:
|
||||
#### Enabling specific HTTP APIs
|
||||
|
||||
The following example enables the state `v1.0` HTTP API and blocks all other HTTP APIs:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
@ -41,14 +47,14 @@ metadata:
|
|||
spec:
|
||||
api:
|
||||
allowed:
|
||||
- name: state
|
||||
version: v1.0
|
||||
protocol: http
|
||||
- name: state
|
||||
version: v1.0
|
||||
protocol: http
|
||||
```
|
||||
|
||||
### Enabling specific gRPC APIs
|
||||
#### Enabling specific gRPC APIs
|
||||
|
||||
The following example enables the state `v1` gRPC API and block all the rest:
|
||||
The following example enables the state `v1` gRPC API and blocks all other gRPC APIs:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
@ -59,9 +65,47 @@ metadata:
|
|||
spec:
|
||||
api:
|
||||
allowed:
|
||||
- name: state
|
||||
version: v1
|
||||
protocol: grpc
|
||||
- name: state
|
||||
version: v1
|
||||
protocol: grpc
|
||||
```
|
||||
|
||||
### Using a denylist
|
||||
|
||||
#### Disabling specific HTTP APIs
|
||||
|
||||
The following example disables the state `v1.0` HTTP API, allowing all other HTTP APIs:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: myappconfig
|
||||
namespace: default
|
||||
spec:
|
||||
api:
|
||||
denied:
|
||||
- name: state
|
||||
version: v1.0
|
||||
protocol: http
|
||||
```
|
||||
|
||||
#### Disabling specific gRPC APIs
|
||||
|
||||
The following example disables the state `v1` gRPC API, allowing all other gRPC APIs:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: myappconfig
|
||||
namespace: default
|
||||
spec:
|
||||
api:
|
||||
denied:
|
||||
- name: state
|
||||
version: v1
|
||||
protocol: grpc
|
||||
```
|
||||
|
||||
### List of Dapr APIs
|
||||
|
@ -70,12 +114,18 @@ The `name` field takes the name of the Dapr API you would like to enable.
|
|||
|
||||
See this list of values corresponding to the different Dapr APIs:
|
||||
|
||||
| Name | Dapr API |
|
||||
| ------------- | ------------- |
|
||||
| state | [State]({{< ref state_api.md>}})|
|
||||
| invoke | [Service Invocation]({{< ref service_invocation_api.md >}}) |
|
||||
| secrets | [Secrets]({{< ref secrets_api.md >}})|
|
||||
| bindings | [Output Bindings]({{< ref bindings_api.md >}}) |
|
||||
| publish | [Pub/Sub]({{< ref pubsub.md >}}) |
|
||||
| actors | [Actors]({{< ref actors_api.md >}}) |
|
||||
| metadata | [Metadata]({{< ref metadata_api.md >}}) |
|
||||
| API group | HTTP API | [gRPC API](https://github.com/dapr/dapr/blob/master/pkg/grpc/endpoints.go) |
|
||||
| ----- | ----- | ----- |
|
||||
| [Service Invocation]({{< ref service_invocation_api.md >}}) | `invoke` (`v1.0`) | `invoke` (`v1`) |
|
||||
| [State]({{< ref state_api.md>}})| `state` (`v1.0` and `v1.0-alpha1`) | `state` (`v1` and `v1alpha1`) |
|
||||
| [Pub/Sub]({{< ref pubsub.md >}}) | `publish` (`v1.0` and `v1.0-alpha1`) | `publish` (`v1` and `v1alpha1`) |
|
||||
| [(Output) Bindings]({{< ref bindings_api.md >}}) | `bindings` (`v1.0`) |`bindings` (`v1`) |
|
||||
| [Secrets]({{< ref secrets_api.md >}})| `secrets` (`v1.0`) | `secrets` (`v1`) |
|
||||
| [Actors]({{< ref actors_api.md >}}) | `actors` (`v1.0`) |`actors` (`v1`) |
|
||||
| [Metadata]({{< ref metadata_api.md >}}) | `metadata` (`v1.0`) |`metadata` (`v1`) |
|
||||
| [Configuration]({{< ref configuration_api.md >}}) | `configuration` (`v1.0` and `v1.0-alpha1`) | `configuration` (`v1` and `v1alpha1`) |
|
||||
| [Distributed Lock]({{< ref distributed_lock_api.md >}}) | `lock` (`v1.0-alpha1`)<br/>`unlock` (`v1.0-alpha1`) | `lock` (`v1alpha1`)<br/>`unlock` (`v1alpha1`) |
|
||||
| Cryptography | `crypto` (`v1.0-alpha1`) | `crypto` (`v1alpha1`) |
|
||||
| [Workflow]({{< ref workflow_api.md >}}) | `workflows` (`v1.0-alpha1`) |`workflows` (`v1alpha1`) |
|
||||
| [Health]({{< ref health_api.md >}}) | `healthz` (`v1.0`) | n/a |
|
||||
| Shutdown | `shutdown` (`v1.0`) | `shutdown` (`v1`) |
|
||||
|
|
|
@ -58,6 +58,18 @@ dapr init -k
|
|||
✅ Success! Dapr has been installed to namespace dapr-system. To verify, run "dapr status -k" in your terminal. To get started, go here: https://aka.ms/dapr-getting-started
|
||||
```
|
||||
|
||||
To run the dashboard, run:
|
||||
|
||||
```bash
|
||||
dapr dashboard -k
|
||||
```
|
||||
|
||||
If you installed Dapr in a non-default namespace, run:
|
||||
|
||||
```bash
|
||||
dapr dashboard -k -n <your-namespace>
|
||||
```
|
||||
|
||||
### Install Dapr (a private Dapr Helm chart)
|
||||
There are some scenarios where it's necessary to install Dapr from a private Helm chart, such as:
|
||||
- needing more granular control of the Dapr Helm chart
|
||||
|
@ -125,7 +137,7 @@ The latest Dapr helm chart no longer supports Helm v2. Please migrate from Helm
|
|||
### Add and install Dapr Helm chart
|
||||
|
||||
1. Make sure [Helm 3](https://github.com/helm/helm/releases) is installed on your machine
|
||||
2. Add Helm repo and update
|
||||
1. Add Helm repo and update
|
||||
|
||||
```bash
|
||||
// Add the official Dapr Helm chart.
|
||||
|
@ -134,10 +146,11 @@ The latest Dapr helm chart no longer supports Helm v2. Please migrate from Helm
|
|||
helm repo add dapr http://helm.custom-domain.com/dapr/dapr/ \
|
||||
--username=xxx --password=xxx
|
||||
helm repo update
|
||||
# See which chart versions are available
|
||||
// See which chart versions are available
|
||||
helm search repo dapr --devel --versions
|
||||
```
|
||||
3. Install the Dapr chart on your cluster in the `dapr-system` namespace.
|
||||
|
||||
1. Install the Dapr chart on your cluster in the `dapr-system` namespace.
|
||||
|
||||
```bash
|
||||
helm upgrade --install dapr dapr/dapr \
|
||||
|
@ -158,8 +171,7 @@ The latest Dapr helm chart no longer supports Helm v2. Please migrate from Helm
|
|||
--wait
|
||||
```
|
||||
|
||||
|
||||
See [Guidelines for production ready deployments on Kubernetes]({{<ref kubernetes-production.md>}}) for more information on installing and upgrading Dapr using Helm.
|
||||
See [Guidelines for production ready deployments on Kubernetes]({{< ref kubernetes-production.md >}}) for more information on installing and upgrading Dapr using Helm.
|
||||
|
||||
### Uninstall Dapr on Kubernetes
|
||||
|
||||
|
@ -172,6 +184,22 @@ helm uninstall dapr --namespace dapr-system
|
|||
- Read [this guide]({{< ref kubernetes-production.md >}}) for recommended Helm chart values for production setups
|
||||
- See [this page](https://github.com/dapr/dapr/blob/master/charts/dapr/README.md) for details on Dapr Helm charts.
|
||||
|
||||
## Installing the Dapr dashboard as part of the control plane
|
||||
|
||||
If you want to install the Dapr dashboard, use this Helm chart with the additional settings of your choice:
|
||||
|
||||
`helm install dapr dapr/dapr-dashboard --namespace dapr-system`
|
||||
|
||||
For example:
|
||||
|
||||
```bash
|
||||
helm repo add dapr https://dapr.github.io/helm-charts/
|
||||
helm repo update
|
||||
kubectl create namespace dapr-system
|
||||
# Install the Dapr dashboard
|
||||
helm install dapr dapr/dapr-dashboard --namespace dapr-system
|
||||
```
|
||||
|
||||
## Verify installation
|
||||
|
||||
Once the installation is complete, verify that the dapr-operator, dapr-placement, dapr-sidecar-injector and dapr-sentry pods are running in the `dapr-system` namespace:
|
||||
|
|
|
@ -5,26 +5,28 @@
|
|||
<div class="col-6 col-sm-2 text-xs-center order-sm-2" style="margin-top: 1rem;">
|
||||
{{ with $links }}
|
||||
{{ with index . "user"}}
|
||||
{{ template "footer-links-block" . }}
|
||||
{{ template "footer-links-block" . }}
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
</div>
|
||||
<div class="col-6 col-sm-2 text-right text-xs-center order-sm-3" style="margin-top: 1rem;">
|
||||
{{ with $links }}
|
||||
{{ with index . "developer"}}
|
||||
{{ template "footer-links-block" . }}
|
||||
{{ template "footer-links-block" . }}
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
</div>
|
||||
<div class="col-12 col-sm-6 text-center py-2 order-sm-2">
|
||||
{{ with .Site.Params }}<small class="text-white">© {{ now.Year}} {{ .trademark | markdownify }}</small>{{ end }}
|
||||
{{ if not .Site.Params.ui.footer_about_disable }}
|
||||
{{ with .Site.GetPage "about" }}<p class="mt-2"><a href="{{ .RelPermalink }}">{{ .Title }}</a></p>{{ end }}
|
||||
{{ end }}
|
||||
{{ if not .Site.Params.ui.footer_about_disable }}
|
||||
{{ with .Site.GetPage "about" }}<p class="mt-2"><a href="{{ .RelPermalink }}">{{ .Title }}</a></p>{{ end }}
|
||||
{{ end }}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=4848fb3b-3edb-4329-90a9-a9d79afff054" />
|
||||
<script> (function (ss, ex) { window.ldfdr = window.ldfdr || function () { (ldfdr._q = ldfdr._q || []).push([].slice.call(arguments)); }; (function (d, s) { fs = d.getElementsByTagName(s)[0]; function ce(src) { var cs = d.createElement(s); cs.src = src; cs.async = 1; fs.parentNode.insertBefore(cs, fs); }; ce('https://sc.lfeeder.com/lftracker_v1_' + ss + (ex ? '_' + ex : '') + '.js'); })(document, 'script'); })('JMvZ8gblPjda2pOd'); </script>
|
||||
<script async src="https://tag.clearbitscripts.com/v1/pk_3f4df076549ad932eda451778a42b09b/tags.js" referrerpolicy="strict-origin-when-cross-origin"></script>
|
||||
</footer>
|
||||
{{ define "footer-links-block" }}
|
||||
<ul class="list-inline mb-0">
|
||||
|
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 113 KiB After Width: | Height: | Size: 89 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 8.7 KiB |
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 12 KiB |
|
@ -1 +1 @@
|
|||
Subproject commit f42b690f4c67e6bb4209932f660c46a96d0b0457
|
||||
Subproject commit edb09a08b7a2ca63983f5237b307c40cae86d3bb
|
|
@ -1 +1 @@
|
|||
Subproject commit d02f9524d96779350323128f88fefdd6fbd6787a
|
||||
Subproject commit effc2f0d3c92ad76e11958e427c8d3b0900e1932
|
|
@ -1 +1 @@
|
|||
Subproject commit 10d09619db5981ba45ec1268687c7a104cb338c1
|
||||
Subproject commit d1c61cae40e7c5d933d92705198506d947960aaa
|
|
@ -1 +1 @@
|
|||
Subproject commit ae34854397150715fe440dec831461d70e17d07a
|
||||
Subproject commit 11145914a5fddd1ada06b6a3b938c27b401f7025
|
|
@ -1 +1 @@
|
|||
Subproject commit 5190e79f4275ffcdaffe7efb59c21dffddefb5f8
|
||||
Subproject commit 5051a9d5d92003924322a8ddbdf230fb8a872dd7
|