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.
Project Tye
Project Tye 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, Project Tye can be used. With a single command, it can build & run your application locally.
tye runIt uses a YAML config file (tye.yaml in the root directory) to describe the relevant services and how to start them, what ports to use etc (Tye can also just assign ports itself).
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, Tye will do that for you.
Tye can try and figure out the health & liveness probes itself, but it is better to explicitly specify them.
Tye also provides a convenient dashboard so you can see all the microservices, their status, restart count & logs.
Finally, you can run the following command so Tye will detect file changes, automatically rebuild & re-run any services that change (so you can make incremental changes to the apps and see the changes live without having to restart all services).
tye run --watchAzure 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 upThe 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.