In Lektion 2.9.5 war die Kladde schon einmal in Azure: mit Kontakten, Terminen und der Anmeldung, für einen Nachmittag. Seitdem sind neun Meilensteine dazugekommen, und mit ihnen Teile, die sich in Azure anders verhalten als auf dem eigenen Rechner: Besucher, die hinter einem Ingress stehen, Mails mit Links, die eine öffentliche Adresse brauchen, ein Import, der nachts laufen soll, während die Kladde vielleicht schläft.

Der zehnte Meilenstein bringt die fertige Kladde nach Azure und hält fest, wie man sie betreibt. Der Code ändert sich dabei wenig; das meiste ist Prüfen, Entscheiden und Aufschreiben.

Pull Request Branch Bringt Wo in dieser Lektion
1 feature/m10-visitor-behind-ingress der Test, dass die Ratenbegrenzung hinter dem Ingress je Besucher zählt „Pull Request 1“
2 feature/m10-public-address die öffentliche Adresse aus den Umgebungsvariablen von Container Apps „Pull Request 2“ und Übung 1
3 feature/m10-apphost der Ordner für Mails in Azure, die Entscheidung zum Skalieren „Pull Request 3“
4 docs/m10-operations der Abschnitt „Betrieb“ in der README, geprüft von einer zweiten Person Übungen 2 und 3

Wo die Kladde steht

Nach Lektion 2.9.5 und den Meilensteinen 1 bis 9 gilt in den Lösungen:

  • Der AppHost aus Lektion 2.9.5 beschreibt eine Container-Apps-Umgebung, Azure SQL Database mit lokalem Container, den Migrationsdienst als Job, die Web-App mit mindestens 0 und höchstens 1 Replik und das Client-Geheimnis von Entra als Parameter nur für die Auslieferung.
  • /health prüft die Verbindung zur Datenbank und ist offen (Lektion 2.9.2).
  • Aspire setzt in Container Apps ASPNETCORE_FORWARDEDHEADERS_ENABLED=true und schaltet autoConfigureDataProtection ein (Lektion 2.9.5).
  • Die Testsuite ist vollständig (Meilenstein 9), und alle Tests laufen in jedem Pull Request.

Heißen Ihre Dateien, Klassen oder Ordner anders, behalten Sie Ihre Namen und übertragen Sie die Schritte.