This lesson starts the work in Azure. In K2 you built the Kladde and delivered it to Azure once with azd, and module 3.0 showed, without Azure, what it stands on there: Linux, the network, DNS, TLS and proxies. Now you learn to run it in Azure securely and affordably. This module lays the ground that everything else stands on:
| Lesson | What comes out of it |
|---|---|
| 3.1.1 Azure at a glance | a subscription for the Kladde, a chosen and justified region |
| 3.1.2 Costs first | a cost estimate in docs/costs.md, a budget with alerts |
| 3.1.3 Order in Azure | a naming scheme, the resource group rg-kladde-dev with tags |
| 3.1.4 Who may do what | a group with read access, a table of permissions |
| 3.1.5 Rules for everyone | policies “EU only” and “inherit tag” |
| 3.1.6 Azure from the command line | an inventory script in the repository |
In this lesson you get the overview: what kinds of cloud there are, who takes care of what in Azure, how Azure is spread across the world and which tools you work with. At the end you choose the region the Kladde runs in from now on, and write down why.
Where the Kladde stands
At the end of K2, the Kladde is a web application with contacts, public appointment booking, tenders from the TED interface, sign-in
with Entra ID and two languages. You delivered it to Azure Container Apps with Aspire and azd. azd created the infrastructure for it
itself, in memory, without it being in the repository. From module 3.0 it brings two things along:
it demonstrably shuts down cleanly on SIGTERM, and docs/netz.md holds an address plan and rules for a later network of its own.
That's enough for a first start. For operations, though, a lot is missing:
- Nobody knows exactly what the Kladde costs per month, and nobody is warned when it gets more expensive.
- The resources have names that azd assigned, and no tags that show what they belong to.
- Only one person has permissions, namely you, and with all of them.
- Nothing stops anyone from creating a database in a region outside the EU.
This module cleans that up before infrastructure as code goes into the repository in module 3.2.