How to enhance your chatbot so it can retrieve data from multiple data sources & orchestrate its own plan with C# Semantic Kernel, planner & Azure OpenAI – part 4 (local development & deployment details)

In the previous post, I detailed how the demo app runs. In this post, let’s talk about some of the techniques & technologies I used to make the demo easy to deploy & run.

Here is the link to the GitHub repo.

NOTE: This has been updated to change from Project Tye (which is no longer under active development) to .NET Aspire.

.NET Aspire

.NET Aspire is an open-source project that makes it easy to stand up a microservice-based application locally.

It is easy to run any individual API or web app, such as running dotnet run or npm start.

However, when you have a bunch of services, sidecars, etc, it becomes a pain to do this. You could write a shell script to stand them all up, but that is tedious and error-prone.

Instead, .NET Aspire can be used. With a single command, it can build & run your application locally.

dotnet run --project .\semantic-kernel-sleeping-bag.AppHost\semantic-kernel-sleeping-bag.AppHost.csproj

It uses a special project (the AppHost project) to define the dependencies between application components and instantiate them.

This is especially useful when you are using sidecar patterns like Dapr to abstract services from each other. You would have to individually run each dapr run command for each service to stand up each sidecar. Instead, .NET Aspire will do that for you.

.NET Aspire also provides a convenient dashboard so you can see all the microservices, their status, restart count & logs.

Azure Developer CLI

Infrastructure as Code tools make it much easier to deploy Azure infrastructure in a repeatable and consistent way. Tools such as Azure Bicep & Terraform can define & deploy the infrastructure of an application.

However, these tools are less useful for building & deploying applications on top of this infrastructure.

The Azure Developer CLI provides the link between deploying the infrastructure, building the applications & deploying the applications.

With a single command, all of the steps are bundled together and run in order.

azd up

The Developer CLI uses a YAML config file (azure.yaml in the root directory) to describe the relevant services & how they should be deployed.

How this works for Azure Container Apps

With services like Azure App Service, you would deploy the infrastructure first, then deploy the web app on top of it (via ZIP deploy).

However, Azure Container Apps are different in that they require a Docker image in order to stand up the service. However, we won’t have the container images ready at the time the Bicep deployment files are run (since the Bicep files also deploy the Container Registry that the Docker images reside in).

To start, the Developer CLI builds all of the required Docker images locally. These are tagged with the name of the service (from the azure.yaml file).

Then the Developer CLI deploys the Container Apps with a “helloworld” image to start with. It also tags the resources with the name of the service that will run in them. These are the same names in the azure.yaml file.

The CLI then goes back, uploads the Docker images to the Container Registry, and redeploys the Container Apps with the new container image (based upon the tag the Container App is tagged with).

Thanks to the excellent example of how to do this from the Developer CLI team.

React app dynamic API URL

Check out the following blog post to see how I did this.

Leave a Reply

Your email address will not be published. Required fields are marked *