mirror of https://github.com/dapr/quickstarts.git
Add some additional improvements for kubernetes examples (#415)
This commit is contained in:
Charlie Stanley
GitHub
parent
01b8aa85ac
commit
9cd1410aab
|
|
@ -34,7 +34,7 @@ jobs:
|
|||
os: [ubuntu-latest]
|
||||
steps:
|
||||
- name: Configure KinD
|
||||
if: matrix.quickstart == 'distributed-calculator' || matrix.quickstart == 'observability' || matrix.quickstart == 'bindings' || matrix.quickstart == 'hello-kubernetes'
|
||||
if: matrix.quickstart != '.' && matrix.quickstart != 'hello-world'
|
||||
# Generate a KinD configuration file that uses:
|
||||
# A couple of worker nodes: this is needed to run both
|
||||
# ZooKeeper + Kakfa
|
||||
|
|
@ -60,14 +60,14 @@ jobs:
|
|||
cat kind.yaml
|
||||
|
||||
- name: Create KinD Cluster
|
||||
if: matrix.quickstart == 'distributed-calculator' || matrix.quickstart == 'observability' || matrix.quickstart == 'bindings' || matrix.quickstart == 'hello-kubernetes'
|
||||
if: matrix.quickstart != '.' && matrix.quickstart != 'hello-world'
|
||||
uses: helm/kind-action@v1.0.0
|
||||
with:
|
||||
config: kind.yaml
|
||||
cluster_name: kind
|
||||
version: ${{ env.KIND_VERSION }}
|
||||
- name: Get KinD info
|
||||
if: matrix.quickstart == 'distributed-calculator' || matrix.quickstart == 'observability' || matrix.quickstart == 'bindings' || matrix.quickstart == 'hello-kubernetes'
|
||||
if: matrix.quickstart != '.' && matrix.quickstart != 'hello-world'
|
||||
run: |
|
||||
kubectl cluster-info --context kind-kind
|
||||
NODE_IP=$(kubectl get nodes \
|
||||
|
|
@ -94,13 +94,12 @@ jobs:
|
|||
dapr init --runtime-version=${{ env.DAPR_RUNTIME_VERSION }}
|
||||
dapr --version
|
||||
- name: Install Dapr - Kubernetes
|
||||
if: matrix.quickstart == 'distributed-calculator' || matrix.quickstart == 'observability' || matrix.quickstart == 'bindings' || matrix.quickstart == 'hello-kubernetes'
|
||||
if: matrix.quickstart != '.' && matrix.quickstart != 'hello-world'
|
||||
run: |
|
||||
helm repo add bitnami https://charts.bitnami.com/bitnami
|
||||
helm repo update
|
||||
helm install redis bitnami/redis
|
||||
dapr init -k --runtime-version=${{ env.DAPR_RUNTIME_VERSION }}
|
||||
sleep 40
|
||||
dapr init -k --runtime-version=${{ env.DAPR_RUNTIME_VERSION }} --wait
|
||||
- name: Check out code
|
||||
uses: actions/checkout@v2
|
||||
- name: Install utilities dependencies
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Find SDK-specific samples in the links below:
|
|||
|
||||
- **[.NET SDK](https://github.com/dapr/dotnet-sdk)**
|
||||
- **[Getting Started with ASP.NET Core](https://github.com/dapr/dotnet-sdk/tree/master/examples/AspNetCore)** - Samples for developing ASP.NET applications using the Dapr .NET SDK
|
||||
- **[Getting Started with .NET Actors](https://docs.dapr.io/developing-applications/sdks/dotnet/dotnet-actors/dotnet-actor-howto/)** - Tutorial for developing actor applications using the Dapr .NET SDK including **[actor samples](https://github.com/dapr/dotnet-sdk/tree/master/examples/Actor)**
|
||||
- **[Getting Started with .NET Actors](https://docs.dapr.io/developing-applications/sdks/dotnet/dotnet-actors/dotnet-actors-howto/)** - Tutorial for developing actor applications using the Dapr .NET SDK including **[actor samples](https://github.com/dapr/dotnet-sdk/tree/master/examples/Actor)**
|
||||
- **[Java SDK](https://github.com/dapr/java-sdk)**
|
||||
- **[Examples](https://github.com/dapr/java-sdk/tree/master/examples/src/main/java/io/dapr/examples)** - Examples for developing Java applications using Dapr
|
||||
- **[Example for Java Actors](https://github.com/dapr/java-sdk/tree/master/examples/src/main/java/io/dapr/examples/actors)** - Example for developing an actor application using the Java SDK.
|
||||
|
|
|
|||
|
|
@ -282,17 +282,27 @@ expected_stdout_lines:
|
|||
- service/bindings-nodeapp created
|
||||
- deployment.apps/bindings-nodeapp created
|
||||
- deployment.apps/bindings-pythonapp created
|
||||
- 'deployment "bindings-nodeapp" successfully rolled out'
|
||||
- 'deployment "bindings-pythonapp" successfully rolled out'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl apply -f .
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
This will deploy bindings-nodeapp and bindings-pythonapp microservices. It will also apply the Kafka bindings component configuration you set up in the last step.
|
||||
|
||||
3. Run `kubectl get pods -w` to see each pod being provisioned.
|
||||
Kubernetes deployments are asyncronous. This means you'll need to wait for the deployment to complete before moving on to the next steps. You can do so with the following command:
|
||||
|
||||
```bash
|
||||
kubectl rollout status deploy/bindings-nodeapp
|
||||
kubectl rollout status deploy/bindings-pythonapp
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
|
||||
3. Run `kubectl get pods` to see that pods were correctly provisioned.
|
||||
|
||||
|
||||
### Observe Logs
|
||||
|
|
|
|||
|
|
@ -398,36 +398,52 @@ multiplyapp-6989454d77-tkd6c 2/2 Running 0 16s
|
|||
subtractapp-869b74f676-9mw94 2/2 Running 0 16s
|
||||
```
|
||||
|
||||
5. Next, take a look at the services and wait until you have an external IP configured for the front-end: `kubectl get svc -w`
|
||||
5. Next, setup access to your service
|
||||
|
||||
```bash
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
dapr-api ClusterIP 10.103.71.22 <none> 80/TCP 135m
|
||||
dapr-placement ClusterIP 10.103.53.127 <none> 80/TCP 135m
|
||||
dapr-sidecar-injector ClusterIP 10.104.220.35 <none> 443/TCP 135m
|
||||
addapp-dapr ClusterIP 10.0.1.170 <none> 80/TCP,50001/TCP 2m
|
||||
calculator-front-end LoadBalancer 10.0.155.131 40.80.152.125 80:32633/TCP 3m
|
||||
calculator-front-end-dapr ClusterIP 10.0.230.219 <none> 80/TCP,50001/TCP 3m
|
||||
divideapp-dapr ClusterIP 10.0.240.3 <none> 80/TCP,50001/TCP 1m
|
||||
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 33d
|
||||
multiplyapp-dapr ClusterIP 10.0.217.211 <none> 80/TCP,50001/TCP 1m
|
||||
subtractapp-dapr ClusterIP 10.0.146.253 <none> 80/TCP,50001/TCP 2m
|
||||
```
|
||||
There are several different ways to access a Kubernetes service depending on which platform you are using. Port forwarding is one consistent way to access a service, whether it is hosted locally or on a cloud Kubernetes provider like AKS.
|
||||
|
||||
Each service ending in "-dapr" represents your services respective sidecars, while the `calculator-front-end` service represents the external load balancer for the React calculator front-end.
|
||||
<!-- STEP
|
||||
name: Port forward
|
||||
background: true
|
||||
sleep: 2
|
||||
timeout_seconds: 10
|
||||
expected_return_code:
|
||||
-->
|
||||
|
||||
> **Note:** Minikube users cannot see the external IP. Instead, you can use `minikube service [service_name]` to access loadbalancer without external IP.
|
||||
```bash
|
||||
kubectl port-forward service/calculator-front-end 8000:80
|
||||
```
|
||||
|
||||
6. Take the external IP address for `calculator-front-end` and drop it in your browser and voilà! You have a working distributed calculator!
|
||||
<!-- END_STEP -->
|
||||
|
||||
This will make your service available on http://localhost:8000. Navigate to this address with your browser and voilà! You have a working distributed calculator!
|
||||
|
||||
> **Optional**: If you are using a public cloud provider, you can substitue your EXTERNAL-IP address instead of port forwarding. You can find it with:
|
||||
|
||||
```bash
|
||||
kubectl get svc
|
||||
```
|
||||
|
||||
```bash
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
dapr-api ClusterIP 10.103.71.22 <none> 80/TCP 135m
|
||||
dapr-placement ClusterIP 10.103.53.127 <none> 80/TCP 135m
|
||||
dapr-sidecar-injector ClusterIP 10.104.220.35 <none> 443/TCP 135m
|
||||
addapp-dapr ClusterIP 10.0.1.170 <none> 80/TCP,50001/TCP 2m
|
||||
calculator-front-end LoadBalancer 10.0.155.131 40.80.152.125 80:32633/TCP 3m
|
||||
calculator-front-end-dapr ClusterIP 10.0.230.219 <none> 80/TCP,50001/TCP 3m
|
||||
divideapp-dapr ClusterIP 10.0.240.3 <none> 80/TCP,50001/TCP 1m
|
||||
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 33d
|
||||
multiplyapp-dapr ClusterIP 10.0.217.211 <none> 80/TCP,50001/TCP 1m
|
||||
subtractapp-dapr ClusterIP 10.0.146.253 <none> 80/TCP,50001/TCP 2m
|
||||
```
|
||||
|
||||
Each service ending in "-dapr" represents your services respective sidecars, while the `calculator-front-end` service represents the external load balancer for the React calculator front-end.
|
||||
|
||||
**For Minikube users**, execute the below command to open calculator on your browser
|
||||
```
|
||||
$ minikube service calculator-front-end
|
||||
```
|
||||
|
||||
<!-- STEP
|
||||
name: Pause for manual validation
|
||||
manual_pause_message: "Calculator APP running on http://<service_ip>:80. Please open in your browser and test manually."
|
||||
manual_pause_message: "Calculator APP running on http://localhost:8000. Please open in your browser and test manually."
|
||||
-->
|
||||
|
||||
<!-- We will pause here and print the above message when mm.py is run with '-m'. Otherwise, this step does nothing -->
|
||||
|
|
@ -437,7 +453,7 @@ manual_pause_message: "Calculator APP running on http://<service_ip>:80. Please
|
|||
|
||||
|
||||
|
||||
7. Open your browser's console window (using F12 key) to see the logs produced as you use the calculator. Note that each time you click a button, you see logs that indicate state persistence:
|
||||
6. Open your browser's console window (using F12 key) to see the logs produced as you use the calculator. Note that each time you click a button, you see logs that indicate state persistence:
|
||||
|
||||
```js
|
||||
Persisting State:
|
||||
|
|
@ -459,23 +475,8 @@ Calling divide service
|
|||
|
||||
The client code calls to an Express server, which routes the calls through Dapr to the back-end services. In this case the divide endpoint is called on the nodejs application.
|
||||
|
||||
8. **Optional:** As with the local steps above, you can validate that all the individual calculator apps are working:
|
||||
7. **Optional:** If your environment doesn't have easy access to a browser, or you just like using curl
|
||||
|
||||
Port forwarding is another way you can access a kubernetes service:
|
||||
|
||||
<!-- STEP
|
||||
name: Port forward
|
||||
background: true
|
||||
sleep: 2
|
||||
timeout_seconds: 1
|
||||
expected_return_code:
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl port-forward service/calculator-front-end 8000:80
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
Then you can use the following curl commands to make sure each one of the microservies is working:
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,11 @@ Once you have a cluster, follow the steps below to deploy Dapr to it. For more d
|
|||
> If you need to deploy to a different namespace, you can use ```-n mynamespace```. See [Deploy Dapr on a Kubernetes cluster](https://docs.dapr.io/operations/hosting/kubernetes/kubernetes-deploy/) for more info.
|
||||
|
||||
```
|
||||
$ dapr init --kubernetes
|
||||
dapr init --kubernetes --wait
|
||||
```
|
||||
|
||||
Sample output:
|
||||
```
|
||||
⌛ Making the jump to hyperspace...
|
||||
ℹ️ Note: To install Dapr using Helm, see here: https://docs.dapr.io/getting-started/install-dapr-kubernetes/#install-with-helm-advanced
|
||||
|
||||
|
|
@ -35,7 +39,7 @@ $ dapr init --kubernetes
|
|||
✅ 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
|
||||
```
|
||||
|
||||
The ```dapr``` CLI will exit as soon as the kubernetes deployments are created. Kubernetes deployments are asyncronous, so you will need to make sure that the dapr deployments are actually completed before continuing.
|
||||
> Without the ```--wait``` flag the Dapr CLI will exit as soon as the kubernetes deployments are created. Kubernetes deployments are asyncronous by default, so we use ```--wait``` here to make sure the dapr control plane is completely deployed and running before continuing.
|
||||
|
||||
<!-- STEP
|
||||
name: Check dapr status
|
||||
|
|
@ -114,56 +118,41 @@ This will deploy the Node.js app to Kubernetes. The Dapr control plane will auto
|
|||
|
||||
You'll also see the container image that you're deploying. If you want to update the code and deploy a new image, see **Next Steps** section.
|
||||
|
||||
This deployment provisions an External IP.
|
||||
Wait until the IP is visible: (may take a few minutes)
|
||||
|
||||
```
|
||||
kubectl get svc nodeapp
|
||||
```
|
||||
|
||||
> Note: Minikube users cannot see the external IP. Instead, you can use `minikube service [service_name]` to access loadbalancer without external IP.
|
||||
|
||||
Once you have an external IP, save it.
|
||||
You can also export it to a variable:
|
||||
|
||||
```
|
||||
Linux/MacOS
|
||||
export NODE_APP=$(kubectl get svc nodeapp --output 'jsonpath={.status.loadBalancer.ingress[0].ip}')
|
||||
|
||||
Windows
|
||||
for /f "delims=" %a in ('kubectl get svc nodeapp --output 'jsonpath={.status.loadBalancer.ingress[0].ip}') do @set NODE_APP=%a
|
||||
```
|
||||
|
||||
**Optional:** You can also use port forwarding if you don't have easy access to your Kubernetes cluster service IPs:
|
||||
There are several different ways to access a Kubernetes service depending on which platform you are using. Port forwarding is one consistent way to access a service, whether it is hosted locally or on a cloud Kubernetes provider like AKS.
|
||||
|
||||
<!-- STEP
|
||||
name: Port forward
|
||||
background: true
|
||||
sleep: 2
|
||||
timeout_seconds: 1
|
||||
timeout_seconds: 10
|
||||
expected_return_code:
|
||||
-->
|
||||
|
||||
```bash
|
||||
export NODE_APP=localhost:8080
|
||||
kubectl port-forward service/nodeapp 8080:80
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
## Step 4 - Verify Service call using external IP
|
||||
To call the service using the extracted external IP, from a command prompt run:
|
||||
This will make your service available on http://localhost:8080.
|
||||
|
||||
> **Optional**: If you are using a public cloud provider, you can substitue your EXTERNAL-IP address instead of port forwarding. You can find it with:
|
||||
|
||||
```bash
|
||||
kubectl get svc nodeapp
|
||||
```
|
||||
|
||||
## Step 4 - Verify Service
|
||||
To call the service that you set up port forwarding to, from a command prompt run:
|
||||
|
||||
<!-- STEP
|
||||
name: Curl Test
|
||||
expected_stdout_lines:
|
||||
- '{"DAPR_HTTP_PORT":"3500","DAPR_GRPC_PORT":"50001"}'
|
||||
env:
|
||||
NODE_APP: "localhost:8080"
|
||||
-->
|
||||
|
||||
```bash
|
||||
curl $NODE_APP/ports
|
||||
curl http://localhost:8080/ports
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
|
@ -174,23 +163,16 @@ Expected output:
|
|||
{"DAPR_HTTP_PORT":"3500","DAPR_GRPC_PORT":"50001"}
|
||||
```
|
||||
|
||||
> Note: This assumes that the external IP is available in the `NODE_APP` environment variable from the previous step.
|
||||
Minikube users cannot see the external IP. Instead, you can use `minikube service [service_name]` to access loadbalancer without external IP. Then export it to an environment variable.
|
||||
|
||||
Here you can see that two ports are displayed. Both the ports have been injected when Dapr was enabled for this app. Additionally, in this quickstart the HTTP Port is used for further communication with the Dapr sidecar.
|
||||
|
||||
Next submit an order to the app
|
||||
|
||||
<!-- STEP
|
||||
name: neworder Test
|
||||
expected_stdout_lines:
|
||||
- ''
|
||||
env:
|
||||
NODE_APP: "localhost:8080"
|
||||
-->
|
||||
|
||||
```bash
|
||||
curl --request POST --data "{\"data\": { \"orderId\": \"42\" } }" --header "Content-Type:application/json" http://$NODE_APP/neworder
|
||||
curl --request POST --data "{\"data\": { \"orderId\": \"42\" } }" --header "Content-Type:application/json" http://localhost:8080/neworder
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
|
@ -204,12 +186,10 @@ Confirm the order was persisted by requesting it from the app
|
|||
name: order Test
|
||||
expected_stdout_lines:
|
||||
- '{"orderId":"42"}'
|
||||
env:
|
||||
NODE_APP: "localhost:8080"
|
||||
-->
|
||||
|
||||
```bash
|
||||
curl http://$NODE_APP/order
|
||||
curl http://localhost:8080/order
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
|
|
|||
|
|
@ -256,7 +256,6 @@ Now deploy the distributed calculator application to your cluster:
|
|||
|
||||
<!-- STEP
|
||||
name: Deploy Calculator Kubernetes
|
||||
sleep: 60
|
||||
expected_stdout_lines:
|
||||
- "deployment.apps/subtractapp created"
|
||||
- "deployment.apps/addapp created"
|
||||
|
|
@ -273,6 +272,35 @@ kubectl apply -f ../distributed-calculator/deploy
|
|||
|
||||
<!-- END_STEP -->
|
||||
|
||||
Kubernetes deployments are asyncronous. This means you'll need to wait for the deployment to complete before moving on to the next steps. You can do so with the following commands:
|
||||
|
||||
<!-- STEP
|
||||
name: "Deploy Kubernetes"
|
||||
expected_stdout_lines:
|
||||
- 'deployment "addapp" successfully rolled out'
|
||||
- 'deployment "subtractapp" successfully rolled out'
|
||||
- 'deployment "divideapp" successfully rolled out'
|
||||
- 'deployment "multiplyapp" successfully rolled out'
|
||||
- 'deployment "calculator-front-end" successfully rolled out'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl rollout status deploy/addapp
|
||||
kubectl rollout status deploy/subtractapp
|
||||
kubectl rollout status deploy/divideapp
|
||||
kubectl rollout status deploy/multiplyapp
|
||||
kubectl rollout status deploy/calculator-front-end
|
||||
```
|
||||
|
||||
|
||||
You can view the status of the running pods with:
|
||||
|
||||
```bash
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
Then, open the distributed calculator UI.
|
||||
|
||||
If this is the first time trying the distributed calculator, find more detailed instructions in the [distributed-calculator](https://github.com/dapr/quickstarts/blob/master/distributed-calculator/README.md) quickstart.
|
||||
|
|
@ -312,6 +340,21 @@ expected_stdout_lines:
|
|||
kubectl apply -f ./deploy/python-multiplier.yaml
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
As above, you can wait for the asyncronous Kubernetes deployment with the following:
|
||||
|
||||
<!-- STEP
|
||||
name: "Deploy Kubernetes"
|
||||
expected_stdout_lines:
|
||||
- 'deployment "multiplyapp" successfully rolled out'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl rollout status deploy/multiplyapp
|
||||
```
|
||||
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
Now go to the calculator UI and perform several calculations. Make sure to use all operands. For example, do the following:
|
||||
|
|
|
|||
|
|
@ -149,25 +149,40 @@ cd react-form
|
|||
|
||||
2. Run the React front end app with Dapr:
|
||||
|
||||
<!-- STEP
|
||||
name: Run react build
|
||||
working_dir: ./react-form
|
||||
expected_stdout_lines:
|
||||
expected_stderr_lines:
|
||||
env:
|
||||
CI: "false"
|
||||
-->
|
||||
|
||||
```bash
|
||||
npm run buildclient
|
||||
npm install
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
<!-- STEP
|
||||
name: Run react frontent
|
||||
working_dir: ./react-form
|
||||
expected_stdout_lines:
|
||||
- "✅ You're up and running! Both Dapr and your app logs will appear here."
|
||||
- "== APP == Listening on port 8080!"
|
||||
- "== APP == Publishing: { messageType: 'B', message: 'Message on B' }"
|
||||
- "== APP == Publishing: { messageType: 'C', message: 'Message on C' }"
|
||||
- "✅ Exited Dapr successfully"
|
||||
- "✅ Exited App successfully"
|
||||
expected_stderr_lines:
|
||||
background: true
|
||||
sleep: 60
|
||||
sleep: 10
|
||||
env:
|
||||
CI: "false"
|
||||
-->
|
||||
|
||||
```bash
|
||||
dapr run --app-id react-form --app-port 8080 npm run buildandstart
|
||||
dapr run --app-id react-form --app-port 8080 npm run start
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
|
@ -290,10 +305,34 @@ Now that the Redis store is set up, you can deploy the assets.
|
|||
1. In your CLI window, navigate to the deploy directory
|
||||
2. To deploy the publisher and two subscriber microservices, as well as the redis configuration you set up in the last step, run:
|
||||
|
||||
<!-- STEP
|
||||
name: Deploy to k8s
|
||||
working_dir: deploy
|
||||
expected_stdout_lines:
|
||||
- "deployment.apps/node-subscriber created"
|
||||
- "deployment.apps/python-subscriber created"
|
||||
- "service/react-form created"
|
||||
- "deployment.apps/react-form created"
|
||||
- 'deployment "node-subscriber" successfully rolled out'
|
||||
- 'deployment "python-subscriber" successfully rolled out'
|
||||
- 'deployment "react-form" successfully rolled out'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl apply -f .
|
||||
```
|
||||
|
||||
Kubernetes deployments are asyncronous. This means you'll need to wait for the deployment to complete before moving on to the next steps. You can do so with the following command:
|
||||
|
||||
```bash
|
||||
kubectl rollout status deploy/node-subscriber
|
||||
kubectl rollout status deploy/python-subscriber
|
||||
kubectl rollout status deploy/react-form
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
|
||||
3. To see each pod being provisioned run:
|
||||
|
||||
```bash
|
||||
|
|
@ -312,31 +351,106 @@ This may take a few minutes.
|
|||
|
||||
### Use the app
|
||||
|
||||
1. Copy the external IP from the last step into a browser and observe the same React form that you saw locally.
|
||||
1. Access the web form.
|
||||
|
||||
**For Minikube users**, execute the below command to open `react-form` in a browser
|
||||
There are several different ways to access a Kubernetes service depending on which platform you are using. Port forwarding is one consistent way to access a service, whether it is hosted locally or on a cloud Kubernetes provider like AKS.
|
||||
|
||||
<!-- STEP
|
||||
name: Port forward
|
||||
background: true
|
||||
sleep: 2
|
||||
timeout_seconds: 10
|
||||
expected_return_code:
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl port-forward service/react-form 8000:80
|
||||
```
|
||||
minikube service react-form
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
This will make your service available on http://localhost:8000
|
||||
|
||||
> **Optional**: If you are using a public cloud provider, you can substitue your EXTERNAL-IP address instead of port forwarding. You can find it with:
|
||||
|
||||
```bash
|
||||
kubectl get svc react-form
|
||||
```
|
||||
|
||||
2. Create and submit messages of different types.
|
||||
|
||||
Open a web broswer and navigate to http://localhost:8000 and you see the same form as with the locally hosted example above.
|
||||
|
||||
<!-- STEP
|
||||
name: Curl validation k8s
|
||||
expected_stdout_lines:
|
||||
- "OK"
|
||||
- "OK"
|
||||
- "OK"
|
||||
expected_stderr_lines:
|
||||
-->
|
||||
|
||||
> **Note:** If you are running in an environment without easy access to a web browser, the following curl commands will simulate a browser request to the node server.
|
||||
|
||||
```bash
|
||||
curl -w "\n" -s 'http://localhost:8000/publish' -H 'Content-Type: application/json' --data '{"messageType":"A","message":"Message on A"}'
|
||||
curl -w "\n" -s 'http://localhost:8000/publish' -H 'Content-Type: application/json' --data '{"messageType":"B","message":"Message on B"}'
|
||||
curl -s 'http://localhost:8000/publish' -H 'Content-Type: application/json' --data '{"messageType":"C","message":"Message on C"}'
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
3. To see the logs generated from your subscribers:
|
||||
|
||||
<!-- STEP
|
||||
name: Deploy Node App
|
||||
expected_stdout_lines:
|
||||
- "A: Message on A"
|
||||
- "B: Message on B"
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl logs --selector app=node-subscriber -c node-subscriber
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
<!-- STEP
|
||||
name: Deploy Python App
|
||||
expected_stdout_lines:
|
||||
- 'Received message "Message on A" on topic "A"'
|
||||
- 'Received message "Message on C" on topic "C"'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl logs --selector app=python-subscriber -c python-subscriber
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
4. Note that the Node.js subscriber receives messages of type "A" and "B", while the Python subscriber receives messages of type "A" and "C".
|
||||
|
||||
### Cleanup
|
||||
|
||||
Once you're done, you can spin down your Kubernetes resources by navigating to the `./deploy` directory and running:
|
||||
|
||||
<!-- STEP
|
||||
name: Cleanup
|
||||
working_dir: deploy
|
||||
expected_stdout_lines:
|
||||
- 'deployment.apps "node-subscriber" deleted'
|
||||
- 'deployment.apps "python-subscriber" deleted'
|
||||
- 'service "react-form" deleted'
|
||||
- 'deployment.apps "react-form" deleted'
|
||||
- 'component.dapr.io "pubsub" deleted'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl delete -f .
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
This will spin down each resource defined by the .yaml files in the `deploy` directory, including the state component.
|
||||
|
||||
## How it works
|
||||
|
|
|
|||
|
|
@ -6,7 +6,16 @@ spec:
|
|||
type: pubsub.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: "redisHost"
|
||||
value: "YOUR_REDIS_HOST_HERE"
|
||||
- name: "redisPassword"
|
||||
value: "YOUR_REDIS_PASSWORD_HERE"
|
||||
# These settings will work out of the box if you use `helm install
|
||||
# bitnami/redis`. If you have your own setup, replace
|
||||
# `redis-master:6379` with your own Redis master address, and the
|
||||
# Redis password with your own Secret's name. For more information,
|
||||
# see https://docs.dapr.io/operations/components/component-secrets .
|
||||
- name: redisHost
|
||||
value: redis-master:6379
|
||||
- name: redisPassword
|
||||
secretKeyRef:
|
||||
name: redis
|
||||
key: redis-password
|
||||
auth:
|
||||
secretStore: kubernetes
|
||||
|
|
|
|||
|
|
@ -212,7 +212,11 @@ Once you have a cluster, follow the steps below to deploy Dapr to it. For more d
|
|||
> If you need to deploy to a different namespace, you can use ```-n mynamespace```. See [Deploy Dapr on a Kubernetes cluster](https://docs.dapr.io/operations/hosting/kubernetes/kubernetes-deploy/) for more info.
|
||||
|
||||
```
|
||||
$ dapr init --kubernetes
|
||||
dapr init --kubernetes --wait
|
||||
```
|
||||
|
||||
Sample output:
|
||||
```
|
||||
⌛ Making the jump to hyperspace...
|
||||
ℹ️ Note: To install Dapr using Helm, see here: https://docs.dapr.io/getting-started/install-dapr-kubernetes/#install-with-helm-advanced
|
||||
|
||||
|
|
@ -220,6 +224,8 @@ $ dapr init --kubernetes
|
|||
✅ 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
|
||||
```
|
||||
|
||||
> Without the ```--wait``` flag the Dapr CLI will exit as soon as the kubernetes deployments are created. Kubernetes deployments are asyncronous by default, so we use ```--wait``` here to make sure the dapr control plane is completely deployed and running before continuing.
|
||||
|
||||
### Step 2 - Configure a secret in the secret store
|
||||
|
||||
Dapr can use a number of different secret stores (AWS Secret Manager, Azure Key Vault, GCP Secret Manager, Kubernetes, etc) to retrieve secrets. For this demo, you'll use the [Kubernetes secret store](https://kubernetes.io/docs/concepts/configuration/secret/) (For instructions on other secret stores, please refer to [this documentation](https://docs.dapr.io/developing-applications/building-blocks/secrets/howto-secrets/)).
|
||||
|
|
@ -228,10 +234,19 @@ Dapr can use a number of different secret stores (AWS Secret Manager, Azure Key
|
|||
|
||||
> Note: For Windows make sure the file does not contain an extension as the name of the file becomes the metadata key to retrieve the secret.
|
||||
2. Create the secret in the Kubernetes secret store. Note, the name of the secret here is "mysecret" and will be used in a later step.
|
||||
|
||||
<!-- STEP
|
||||
name: Create secret
|
||||
working_dir: node
|
||||
expected_stdout_lines:
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl create secret generic mysecret --from-file ./mysecret
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
3. You can check that the secret is indeed stored in the Kubernetes secret store by running the command:
|
||||
```
|
||||
kubectl get secret mysecret -o yaml
|
||||
|
|
@ -267,43 +282,66 @@ type: Opaque
|
|||
|
||||
### Step 3 - Deploy the Node.js app with the Dapr sidecar
|
||||
|
||||
```
|
||||
kubectl apply -f ./deploy/node.yaml
|
||||
<!-- STEP
|
||||
name: Deploy to k8s
|
||||
expected_stdout_lines:
|
||||
- "deployment.apps/nodeapp created"
|
||||
- 'deployment "nodeapp" successfully rolled out'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl apply -f deploy/node.yaml
|
||||
```
|
||||
|
||||
This will deploy the Node.js app to Kubernetes.
|
||||
|
||||
You'll also see the container image that is being deployed. If you want to update the code and deploy a new image, see **Next Steps** section.
|
||||
|
||||
This deployment provisions an external IP.
|
||||
Wait until the IP is visible: (may take a few minutes)
|
||||
Kubernetes deployments are asyncronous. This means you'll need to wait for the deployment to complete before moving on to the next steps. You can do so with the following command:
|
||||
|
||||
```bash
|
||||
kubectl rollout status deploy/nodeapp
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
|
||||
There are several different ways to access a Kubernetes service depending on which platform you are using. Port forwarding is one consistent way to access a service, whether it is hosted locally or on a cloud Kubernetes provider like AKS.
|
||||
|
||||
<!-- STEP
|
||||
name: Port forward
|
||||
background: true
|
||||
sleep: 2
|
||||
timeout_seconds: 10
|
||||
expected_return_code:
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl port-forward service/nodeapp 8000:80
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
This will make your service available on http://localhost:8000.
|
||||
|
||||
> **Optional**: If you are using a public cloud provider, you can substitue your EXTERNAL-IP address instead of port forwarding. You can find it with:
|
||||
|
||||
```bash
|
||||
kubectl get svc nodeapp
|
||||
```
|
||||
|
||||
> Note: Minikube users cannot see the external IP. Instead, you can use `minikube service [service_name]` to access loadbalancer without external IP.
|
||||
|
||||
Once you have an external IP, save it.
|
||||
You can also export it to a variable:
|
||||
|
||||
**Linux/MacOS**:
|
||||
|
||||
```
|
||||
export NODE_APP=$(kubectl get svc nodeapp --output 'jsonpath={.status.loadBalancer.ingress[0].ip}')
|
||||
```
|
||||
|
||||
**Windows**:
|
||||
|
||||
```
|
||||
for /f "delims=" %a in ('kubectl get svc nodeapp --output 'jsonpath={.status.loadBalancer.ingress[0].ip}') do @set NODE_APP=%a
|
||||
```
|
||||
|
||||
### Step 4 - Access the secret
|
||||
Make a request to the node app to fetch the secret. You can use the command below:
|
||||
|
||||
<!-- STEP
|
||||
name: Curl test
|
||||
expected_stdout_lines:
|
||||
- "eHl6OTg3Ngo="
|
||||
-->
|
||||
|
||||
```bash
|
||||
curl -k http://localhost:8000/getsecret
|
||||
```
|
||||
curl -k http://$NODE_APP/getsecret
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
The output should be your base64 encoded secret
|
||||
|
||||
### Step 5 - Observe Logs
|
||||
|
|
@ -312,14 +350,23 @@ Now that the node app is running, watch messages come through.
|
|||
|
||||
Get the logs of the Node.js app:
|
||||
|
||||
```
|
||||
<!-- STEP
|
||||
name: Read logs
|
||||
expected_stdout_lines:
|
||||
- 'Node App listening on port 3000!'
|
||||
- 'Fetching URL: http://localhost:3500/v1.0/secrets/kubernetes/mysecret?metadata.namespace=default'
|
||||
- 'Base64 encoded secret is: eHl6OTg3Ngo='
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl logs --selector=app=node -c node
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
If all went well, you should see logs like this:
|
||||
|
||||
```
|
||||
% kubectl logs --selector=app=node -c node
|
||||
Node App listening on port 3000!
|
||||
Fetching URL: http://localhost:3500/v1.0/secrets/kubernetes/mysecret?metadata.namespace=default
|
||||
Base64 encoded secret is: eHl6OTg3Ngo=
|
||||
|
|
@ -331,10 +378,21 @@ In these logs, you can see that the node app is making a request to dapr to fetc
|
|||
|
||||
Once you're done, you can spin down your Kubernetes resources by navigating to the `./deploy` directory and running:
|
||||
|
||||
<!-- STEP
|
||||
name: Cleanup
|
||||
expected_stdout_lines:
|
||||
- 'service "nodeapp" deleted'
|
||||
- 'deployment.apps "nodeapp" deleted'
|
||||
- 'secret "mysecret" deleted'
|
||||
-->
|
||||
|
||||
```bash
|
||||
kubectl delete -f ./deploy/node.yaml
|
||||
kubectl delete secret mysecret
|
||||
```
|
||||
|
||||
<!-- END_STEP -->
|
||||
|
||||
This will spin down the node app.
|
||||
|
||||
### Updating the Node application and deploying in Kubernetes
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
xyz9876
|
||||
Loading…
Reference in New Issue