Recently, I wrote a post to share how I migrated a tool called AzUrlShortener. Today, I’ll share how I used the Azure Developer CLI (azd) in the migration. Migrating a tool to new infrastructure can be complicated and require writing shell scripts. But with azd, I was able to provision the resources and deploy the tool without writing scripts or infrastructure as code (IaC) manually. This blog post provides a closer look at how I did that.

In this post, I share some useful tips and lessons I learned while using azd during the migration.

Part of this series:

• Migrating the AzUrlShortener from Azure Static WebApp (SWA) to Azure Container Apps
• Converting a Blazor Web Assembly (WASM) to FluentUI Blazor server
• Azure Developer CLI (azd) in a real-life scenario

Generate the Bicep files

The previous version of AzUrlShortener used ARM templates. After a few years, it was time to rewrite the IaC using something more modern, like Bicep. Because the solution has multiple components (an Azure Function, an API, a website, and a storage account), I expected to write extensive and complex Bicep code. However, I was surprised that azd could generate all the Bicep files for me.

Using the command azd infra synth (currently in preview), I could save the IaC files locally. The Azure Developer CLI uses the manifest from .NET Aspire, to know what is needed and generates several new files in the solution:

infra/                  # Infrastructure as Code (Bicep) files
 ├── main.bicep         # Main deployment module
 └── resources.bicep    # Shared resources across your application's services

Additionally, for each project resource referenced by your AppHost, a containerApp.tmpl.yaml file was created in an infra directory under the AppHost project:

Cloud5mins.ShortenerTools.AppHost/
    └── infra/
        ├── admin.tmpl.yaml
        ├── api.tmpl.yaml
        └── azfunc-light.tmpl.yaml

Now, I could modify these Bicep files (for example, changing scaling or CPU settings for each container). Each time I ran azd up, the IaC was used to deploy the solution.

Note: azd infra synth is currently an alpha feature. You must explicitly enable it by running azd config set alpha.infraSynth on.

Write and rewrite the IaC files

During a migration, we often move the solution piece by piece. In my case, I started by using an existing Azure Table Storage resource. Once the storage account was integrated into the solution, my deployment failed. This issue happened because the storage account wasn’t created by azd, and the Bicep files didn’t know about it. Adding the storage account manually is an option, but it’s prone to human errors. Instead, I used the command azd infra synth --force. This command overwrites existing Bicep files and regenerates them based on the current state of your Azure resources. Git helps to see changes made to the files and resolve any conflicts.

Leave my domain name alone!

One of the final steps was testing the solution with a custom domain name. I ran azd up, added a domain name to the azfunc-light container via the Azure portal, and ran some tests. Everything worked fine, though I found a few small issues to fix. After I quickly fixed those issues, I ran azd up again. But this time, oh no! The domain name was removed. After a short investigation, I found a configuration setting to prevent changing custom domains when deploying Azure Container Apps:

azd config set alpha.aca.persistDomains on

Once this configuration was set, all subsequent deployments kept the custom domain name. Yay! To see all other configuration options, run the command azd config list-alpha.

Continuous Integration and Continuous Deployment (CI/CD)

I used previously the azd pipeline config command, so I knew what to expect. But I’m always amazed at how much time it saves me. The command creates a GitHub Action workflow file (it also works with Azure Pipelines). It also creates secrets in the repository. The workflow uses these secrets to deploy the solution, so no sensitive information is hardcoded in the workflow file.

Conclusion

In this post, I share tips and tricks I learn while using azd to deploy my solution. I really like this CLI tool because it’s always there, ready to help us move to the next step. If you haven’t tried it yet, you should. You can find more information in the azd documentation.

Want to learn more?

This project was deployed into Azure Container Apps. I strongly suggest the repository Get Started .NET on Azure Container Apps, which contains many step-by-step tutorials (with videos) helping you learn to use Azure Container Apps with .NET.