Seit Lektion 3.2.5 liefert die Kladde mit azd aus, und zwar ihre eigene Infrastruktur aus infra/: azd stellt main.bicep bereit und rollt danach die
Images aus. Der AppHost liefert dabei nur noch die Projekte und die Vorlage der Container App web. In 3.2.5 stand auch ein Absatz über den zweiten
Weg, aspire deploy, und warum die Kladde bei azd bleibt. Diese Lektion geht den zweiten Weg einmal ganz, vergleicht, was dabei entsteht, und
schreibt die Entscheidung so auf, dass sie in einem Jahr noch jemand versteht.
Was beim Veröffentlichen aus dem Modell wird
Beim Veröffentlichen läuft der AppHost nicht, er beschreibt. Was dabei herauskommt, bestimmt die Umgebung, in die das Modell ausgeliefert wird:
| Umgebung im AppHost | Paket | heraus kommt |
|---|---|---|
AddAzureContainerAppEnvironment("cae") |
Aspire.Hosting.Azure.AppContainers |
Bicep: Container-Apps-Umgebung, Registry, Identitäten, Rollen, je Projekt eine Container App |
AddDockerComposeEnvironment("compose") |
Aspire.Hosting.Docker |
docker-compose.yaml und eine .env mit den offenen Werten |
| Kubernetes, App Service | weitere Aspire.Hosting.…-Pakete |
Manifeste oder Bicep für diese Ziele |
Seit Aspire 9.4 muss die Umgebung im AppHost stehen (3.2.5). Die frühere Art, mit eigenen „Publishern“ zu veröffentlichen, gibt es nicht mehr.
Zwei Befehle der Aspire-CLI führen ins Veröffentlichen. aspire publish schreibt die Dateien in einen Ordner, standardmäßig aspire-output, und
lässt offene Werte offen; ein anderes Werkzeug oder ein Mensch wendet sie später an. aspire deploy erzeugt dasselbe, setzt die Werte ein und
liefert direkt aus. Beide Befehle (und aspire do) zeigt aspire --help in Version 13.6.5 mit dem Zusatz „Vorschau“. Einschalten müssen Sie sie
nicht, sie sind da; der Zusatz heißt, dass sich ihr Verhalten zwischen Versionen noch ändern kann.