Merge branch 'v1.13' into preview-feature-component-hot-reloading

daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md

@@ -253,7 +253,7 @@ async function start() {
         }
     });
     await server.binding.receive('checkout', async (orderId) => console.log(`Received Message: ${JSON.stringify(orderId)}`));
-    await server.startServer();
+    await server.start();
 }
 
 ```
@@ -292,4 +292,4 @@ Event delivery guarantees are controlled by the binding implementation. Dependin
 - [Bindings building block]({{< ref bindings >}})
 - [Bindings API]({{< ref bindings_api.md >}})
 - [Components concept]({{< ref components-concept.md >}})
-- [Supported bindings]({{< ref supported-bindings >}})
+- [Supported bindings]({{< ref supported-bindings >}})

daprdocs/content/en/developing-applications/debugging/debug-k8s/debug-daprd.md

@@ -11,7 +11,7 @@ description: "How to debug the Dapr sidecar (daprd) on your Kubernetes cluster"
 
 Sometimes it is necessary to understand what's going on in the Dapr sidecar (daprd), which runs as a sidecar next to your application, especially when you diagnose your Dapr application and wonder if there's something wrong in Dapr itself. Additionally, you may be developing a new feature for Dapr on Kubernetes and want to debug your code.
 
-his guide will cover how to use built-in Dapr debugging to debug the Dapr sidecar in your Kubernetes pods.
+This guide covers how to use built-in Dapr debugging to debug the Dapr sidecar in your Kubernetes pods. To learn how to view logs and troubleshoot Dapr in Kubernetes, see the [Configure and view Dapr logs guide]({{< ref "logs-troubleshooting.md#logs-in-kubernetes-mode" >}})
 
 ## Pre-requisites
 
@@ -87,6 +87,62 @@ Forwarding from [::1]:40000 -> 40000
 
 All done. Now you can point to port 40000 and start a remote debug session to daprd from your favorite IDE.
 
+## Commonly used `kubectl` commands
+
+Use the following common `kubectl` commands when debugging daprd and applications running on Kubernetes.
+
+Get all pods, events, and services: 
+
+```bash
+kubectl get all
+kubectl get all --n <namespace>
+kubectl get all --all-namespaces
+```
+
+Get each specifically:
+
+```bash
+kubectl get pods
+```
+
+```bash
+kubectl get events --n <namespace>
+kubectl get events --sort-by=.metadata.creationTimestamp --n <namespace>
+```
+
+```bash
+kubectl get services
+```
+
+Check logs:
+
+```bash
+kubectl logs <podId> daprd
+kubectl logs <podId> <myAppContainerName>
+kuebctl logs <deploymentId> daprd
+kubectl logs <deploymentId> <myAppContainerName>
+```
+
+```bash
+kubectl describe pod <podId>
+kubectl describe deploy <deployId>
+kubectl describe replicaset <replicasetId>
+```
+
+Restart a pod by running the following command: 
+
+```bash
+kubectl delete pod <podId>
+```
+
+This causes the `replicaset` controller to restart the pod after the delete.
+
+## Watch the demo
+
+See the presentation on troubleshooting Dapr on Kubernetes in the [Dapr Community Call #36](https://youtu.be/pniLPRbuLD8?si=bGid7oYSp9cThtiI&t=838). 
+
+<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/pniLPRbuLD8?si=bGid7oYSp9cThtiI&amp;start=838" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
 ## Related links
 
 - [Overview of Dapr on Kubernetes]({{< ref kubernetes-overview >}})

daprdocs/content/en/developing-applications/debugging/debugging-docker-compose.md

@@ -0,0 +1,81 @@
+---
+type: docs
+title: "Debugging Dapr Apps running in Docker Compose"
+linkTitle: "Debugging Docker Compose"
+weight: 300
+description: "Debug Dapr apps locally which are part of a Docker Compose deployment"
+---
+
+The goal of this article is to demonstrate a way to debug one or more daprised applications (via your IDE, locally) while remaining integrated with the other applications that have deployed in the docker compose environment.
+
+Let's take the minimal example of a docker compose file which contains just two services :
+- `nodeapp` - your app
+- `nodeapp-dapr` - the dapr sidecar process to your `nodeapp` service
+
+#### compose.yml
+```yaml
+services:
+  nodeapp:
+    build: ./node
+    ports:
+      - "50001:50001"
+    networks:
+      - hello-dapr
+  nodeapp-dapr:
+    image: "daprio/daprd:edge"
+    command: [
+      "./daprd",
+     "--app-id", "nodeapp",
+     "--app-port", "3000",
+     "--resources-path", "./components"
+     ]
+    volumes:
+        - "./components/:/components"
+    depends_on:
+      - nodeapp
+    network_mode: "service:nodeapp"
+networks:
+  hello-dapr
+```
+
+When you run this docker file with `docker compose -f compose.yml up` this will deploy to Docker and run as normal.
+
+But how do we debug the `nodeapp` while still integrated to the running dapr sidecar process, and anything else that you may have deployed via the Docker compose file? 
+
+Lets start by introducing a *second* docker compose file called `compose.debug.yml`. This second compose file will augment with the first compose file when the `up` command is ran.
+
+#### compose.debug.yml
+```yaml
+services:
+  nodeapp: # Isolate the nodeapp by removing its ports and taking it off the network
+    ports: !reset []
+    networks: !reset
+      - ""
+  nodeapp-dapr:
+    command: ["./daprd",
+     "--app-id", "nodeapp",
+     "--app-port", "8080", # This must match the port that your app is exposed on when debugging in the IDE
+     "--resources-path", "./components",
+     "--app-channel-address", "host.docker.internal"] # Make the sidecar look on the host for the App Channel
+    network_mode: !reset "" # Reset the network_mode...
+    networks: # ... so that the sidecar can go into the normal network
+      - hello-dapr
+    ports:
+      - "3500:3500" # Expose the HTTP port to the host
+      - "50001:50001" # Expose the GRPC port to the host (Dapr Worfklows depends upon the GRPC channel)
+
+```
+
+Next, ensure that your `nodeapp` is running/debugging in your IDE of choice, and is exposed on the same port that you specifed above in the `compose.debug.yml` - In the example above this is set to port `8080`.
+
+Next, stop any existing compose sessions you may have started, and run the following command to run both docker compose files combined together :
+
+`docker compose -f compose.yml -f compose.debug.yml up`
+
+You should now find that the dapr sidecar and your debugging app will have bi-directional communication with each other as if they were running together as normal in the Docker compose environment.
+
+**Note** : It's important to highlight that the `nodeapp` service in the docker compose environment is actually still running, however it has been removed from the docker network so it is effectively orphaned as nothing can communicate to it.
+
+**Demo** : Watch this video on how to debug local Dapr apps with Docker Compose
+
+<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/nWatANwaAik?start=1738" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md

@@ -60,6 +60,8 @@ With the following command, simultaneously run the following services alongside
 ```bash
 dapr run -f .
 ```
+> **Note**: Since Python3.exe is not defined in Windows, you may need to change  `python3` to `python` in the  [`dapr.yaml`]({{< ref "#dapryaml-multi-app-run-template-file" >}}) file before running `dapr run -f .`
+
 
 **Expected output**
 

daprdocs/content/en/getting-started/quickstarts/serviceinvocation-quickstart.md

@@ -57,6 +57,7 @@ With the following command, simultaneously run the following services alongside
 ```bash
 dapr run -f .
 ```
+> **Note**: Since Python3.exe is not defined in Windows, you may need to change  `python3` to `python` in the  [`dapr.yaml`]({{< ref "#dapryaml-multi-app-run-template-file" >}}) file before running `dapr run -f .`
 
 **Expected output**
 

daprdocs/content/en/getting-started/quickstarts/statemanagement-quickstart.md

@@ -51,8 +51,9 @@ cd state_management/python/sdk/order-processor
 Run the `order-processor` service alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}).
 
 ```bash
-dapr run -f
+dapr run -f .
 ```
+> **Note**: Since Python3.exe is not defined in Windows, you may need to change  `python3` to `python` in the  [`dapr.yaml`]({{< ref "#dapryaml-multi-app-run-template-file" >}}) file before running `dapr run -f .`
 
 The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
 
@@ -173,7 +174,7 @@ cd state_management/javascript/sdk/order-processor
 Run the `order-processor` service alongside a Dapr sidecar.
 
 ```bash
-dapr run -f
+dapr run -f .
 ```
 
 The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
@@ -299,7 +300,7 @@ cd state_management/csharp/sdk/order-processor
 Run the `order-processor` service alongside a Dapr sidecar.
 
 ```bash
-dapr run -f
+dapr run -f .
 ```
 
 The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
@@ -423,10 +424,16 @@ In a terminal window, navigate to the `order-processor` directory.
 cd state_management/java/sdk/order-processor
 ```
 
+Install the dependencies:
+
+```bash
+mvn clean install
+```
+
 Run the `order-processor` service alongside a Dapr sidecar.
 
 ```bash
-dapr run -f
+dapr run -f .
 ```
 
 The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
@@ -553,7 +560,7 @@ cd state_management/go/sdk/order-processor
 Run the `order-processor` service alongside a Dapr sidecar.
 
 ```bash
-dapr run -f
+dapr run -f .
 ```
 
 The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.

daprdocs/content/en/operations/troubleshooting/logs-troubleshooting.md

@@ -73,6 +73,8 @@ dapr run node myapp.js
 
 ## Logs in Kubernetes mode
 
+> [Learn how to debug `daprd` on Kubernetes.]({{< ref "debug-daprd.md" >}}) 
+
 You can set the log level individually for every sidecar by providing the following annotation in your pod spec template:
 
 ```yml

daprdocs/content/en/reference/cli/dapr-init.md

@@ -49,32 +49,44 @@ dapr init [flags]
 
 ### Examples
 
-#### Self hosted environment
+{{< tabs "Self-hosted" "Kubernetes" >}}
 
-Install Dapr by pulling container images for Placement, Redis and Zipkin. By default these images are pulled from Docker Hub. To switch to Dapr Github container registry as the default registry, set the `DAPR_DEFAULT_IMAGE_REGISTRY` environment variable value to be `GHCR`. To switch back to Docker Hub as default registry, unset this environment variable. 
+{{% codetab %}}
+
+**Install**
+
+Install Dapr by pulling container images for Placement, Redis, and Zipkin. By default, these images are pulled from Docker Hub. 
 
 ```bash
 dapr init
 ```
 
-You can also specify a specific runtime version. Be default, the latest version is used.
+Dapr can also run [Slim self-hosted mode]({{< ref self-hosted-no-docker.md >}}), without Docker.
 
 ```bash
-dapr init --runtime-version 1.4.0
+dapr init -s
 ```
 
-You can also install Dapr with a particular image variant, for example: [mariner]({{< ref "kubernetes-deploy.md#using-mariner-based-images" >}}).
+> To switch to Dapr Github container registry as the default registry, set the `DAPR_DEFAULT_IMAGE_REGISTRY` environment variable value to be `GHCR`. To switch back to Docker Hub as default registry, unset this environment variable. 
+
+**Specify a runtime version**
+
+You can also specify a specific runtime version. Be default, the latest version is used.
 
 ```bash
-dapr init --image-variant mariner
+dapr init --runtime-version 1.13.0
 ```
 
-Dapr can also run [Slim self-hosted mode]({{< ref self-hosted-no-docker.md >}}) without Docker.
+**Install with image variant**
+
+You can also install Dapr with a particular image variant, for example: [mariner]({{< ref "kubernetes-deploy.md#using-mariner-based-images" >}}).
 
 ```bash
-dapr init -s
+dapr init --image-variant mariner
 ```
 
+**Use Dapr Installer Bundle**
+
 In an offline or airgap environment, you can [download a Dapr Installer Bundle](https://github.com/dapr/installer-bundle/releases) and use this to install Dapr instead of pulling images from the network.
 
 ```bash
@@ -87,17 +99,17 @@ Dapr can also run in slim self-hosted mode without Docker in an airgap environme
 dapr init -s --from-dir <path-to-installer-bundle-directory>
 ```
 
-You can also specify a private registry to pull container images from. These images need to be published to private registries as shown below to enable Dapr CLI to pull them successfully via the `dapr init` command - 
+**Specify private registry**
+
+You can also specify a private registry to pull container images from. These images need to be published to private registries as shown below to enable Dapr CLI to pull them successfully via the `dapr init` command:
 
 1. Dapr runtime container image(dapr) (Used to run Placement) - dapr/dapr:<version>
 2. Redis container image(rejson)   - dapr/3rdparty/rejson
 3. Zipkin container image(zipkin)  - dapr/3rdparty/zipkin
 
-> All the required images used by Dapr needs to be under the`dapr` path.
+All the required images used by Dapr needs to be under the `dapr` path. The 3rd party images have to be published under `dapr/3rdparty` path.
 
-> The 3rd party images have to be published under `dapr/3rdparty` path.
-
-> image-registry uri follows this format - `docker.io/<username>`
+`image-registry` uri follows the `docker.io/<username>` format.
 
 ```bash
 dapr init --image-registry docker.io/username
@@ -114,7 +126,37 @@ You can specify a different container runtime while setting up Dapr. If you omit
 dapr init --container-runtime podman
 ```
 
-#### Kubernetes environment
+**Use Docker network**
+
+You can deploy local containers into Docker networks, which is useful for deploying into separate networks or when using Docker Compose for local development to deploy applications.
+
+Create the Docker network.
+
+```bash
+docker network create mynet
+```
+
+Initialize Dapr and specify the created Docker network.
+
+```bash
+dapr init --network mynet
+```
+
+Verify all containers are running in the specified network.
+
+```bash
+docker ps 
+```
+
+Uninstall Dapr from that Docker network.
+
+```bash
+dapr uninstall --all --network mynet
+```
+
+{{% /codetab %}}
+
+{{% codetab %}}
 
 ```bash
 dapr init -k
@@ -149,3 +191,7 @@ Scenario 2 : dapr image hosted under a new/different directory in private regist
 ```bash
 dapr init -k --image-registry docker.io/username/<directory-name>
 ```
+
+{{% /codetab %}}
+
+{{< /tabs >}}