In lesson 2.9.5, the Kladde was in Azure once before: with contacts, appointments and sign-in, for an afternoon. Since then, nine milestones have been added, and with them parts that behave differently in Azure than on your own machine: visitors who stand behind an ingress, mails with links that need a public address, an import that’s meant to run at night while the Kladde may be asleep.

The tenth milestone brings the finished Kladde to Azure and records how to operate it. The code changes little; most of it is checking, deciding and writing down.

Pull request Branch Brings Where in this lesson
1 feature/m10-visitor-behind-ingress the test that the rate limiter behind the ingress counts per visitor “Pull request 1”
2 feature/m10-public-address the public address from the Container Apps environment variables “Pull request 2” and exercise 1
3 feature/m10-apphost the folder for mails in Azure, the decision about scaling “Pull request 3”
4 docs/m10-operations the “Operations” section in the README, checked by a second person exercises 2 and 3

Where the Kladde stands

After lesson 2.9.5 and milestones 1 to 9, the solutions have this:

  • The AppHost from lesson 2.9.5 describes a Container Apps environment, Azure SQL Database with a local container, the migration service as a job, the web app with at least 0 and at most 1 replica, and Entra’s client secret as a parameter for delivery only.
  • /health checks the connection to the database and is open (lesson 2.9.2).
  • In Container Apps, Aspire sets ASPNETCORE_FORWARDEDHEADERS_ENABLED=true and turns on autoConfigureDataProtection (lesson 2.9.5).
  • The test suite is complete (milestone 9), and all tests run in every pull request.

If your files, classes or folders have other names, keep yours and carry the steps over.