Replies: 3 comments 1 reply
-
|
"production" is an overloaded term so I'll use the term "deployable" (as you deploy to different environments). azd can deploy an aspire application to azure container apps, and aspir8 can deploy an aspire application to Kubernetes (there'll be support for AWS tooling as well). These will be our primary deployment targets for aspire v1. Work is being done to make the runnable outside of the local environment so that it can be deployed (#1003). |
Beta Was this translation helpful? Give feedback.
-
|
Sorry my bad, my english is poor. So, now, the clean way to use this tool, is DO NOT use Am I right to think this way? Thanks!!! |
Beta Was this translation helpful? Give feedback.
-
The orchestrator is for development only. That's why tools like azd and aspire8 "target" orchestrators of their own. The apphost project is never deployed.
The code in AddServiceDefaults isn't tied to the dashboard. This example shows running aspire with the grafana telemetry stack, (loki and tempo for logs and distributed tracing). This example shows how to wire up Prometheus. The service defaults are part of your app code and is a pattern for wiring up cross cutting concerns (like your services). Service discovery, resiliency and health checks have no reliance on the dashboard. If you want to delete the service defaults then feel free to do so 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Now the last piece of the puzzle is complete, you are my hero ! thanks ! |
Beta Was this translation helpful? Give feedback.
-
It provider Dashboard, Service Discovery, Health Check, Telemetry, All of this is usually very useful in a production environment, So I think aspire can use for produdction, but How can it boot the project when production?
The dotnet app can delopy with many ways, such as container, every service has it's own container, then How can aspire boot it?
If it can't use for production, Why services need
AddServiceDefaults?Beta Was this translation helpful? Give feedback.
All reactions