Plattformautomatisierung und DevOps für den API Management-Zielzonenbeschleuniger
Dieser Artikel bietet Designüberlegungen und -empfehlungen für die Plattformautomatisierung und DevOps im Azure API Management Zielzonen-Beschleuniger. Mit der Plattformautomatisierung und DevOps können Sie Ihren Ansatz für die Umgebungsbereitstellung mit Infrastructure-as-Code-Optionen modernisieren.
Weitere Informationen zum Entwurfsbereich für die Plattformautomatisierung und DevOps.
Überlegungen zum Entwurf
- Jedes API-Team kann Updates von einem eigenen Entwickler-Repository in eine eigene API Management-Entwicklungsinstanz übertragen.
- Was bedeutet das aus einer Netzwerkplanungsperspektive?
- Was ist mit anderen Nichtproduktionsumgebungen (z. B. Qualitätssicherung oder Staging)?
- Überlegen Sie, wie Produkte und andere Entitäten verwaltet oder versioniert werden sollen, insbesondere, wenn mehrere Teams dieselben Produkte verwenden.
- Berücksichtigen Sie die Teststrategie für APIs und Richtlinien.
Entwurfsempfehlungen
- Ein zentrales Team (z. B. ein API Management-Administratorteam) verwaltet die API Management-Produktionsumgebung.
- API Management-Konfigurationen werden als Resource Manager-Vorlagen oder gleichwertige Bicep- oder Terraform-Vorlagen dargestellt, und eine Infrastruktur-as-Code-Denkweise sollte übernommen werden.
- Das API Management-Administratorteam veröffentlicht Konfigurationsänderungen an der API Management-Produktionsumgebung aus einem Git-Repository (Herausgeber-Repository), dessen Owner das API Management-Administratorteam ist.
- Jedes einzelne API-Team kann das Herausgeber-Repository verzweigen, um ein eigenes Entwickler-Repository zu verwenden.
- Jedes Team kann API Management APIOps oder die API Management-Erweiterung für Visual Studio Code verwenden, um die relevanten Artefakte aus der API Management-Entwicklungsinstanz zu extrahieren. Diese Artefakte basieren auf Azure Resource Manager und sollten an das Git-Repository des API-Teams committet werden.
Hinweis
Verwenden Sie nicht die API Management Git-Integration.
- Dienstvorlagen und freigegebene Vorlagen sollten sich in separaten Repositories befinden.
- Änderungen an Artefakten sollten an den extrahierten Artefakten vorgenommen und dann nach Git committet werden. Sie sollten in einer Entwicklungsumgebung bereitgestellt werden.
- Um die zentralisierten Umgebungen (Staging, Produktion usw.) zu fördern, können API-Teams einen Pull Request (PR) übermitteln, um ihre Änderungen am Herausgeber-Repository zusammenzuführen.
- Das API Management-Administratorteam validiert den PR.
- Im Idealfall werden die meisten Validierungen als Teil der Übermittlung eines PR automatisiert.
- Die Infrastructure-as-Code-Vorlagen sollten sich in einem anderen Repository befinden – und in einer Bereitstellungspipeline bereitgestellt werden.
- Trennen der Bereitstellung der Infrastruktur von der Anwendungsbereitstellung. Die Kerninfrastruktur ändert sich weniger häufig als Anwendungen. Behandeln Sie jeden Bereitstellungstyp als separaten Flow und separate Pipeline.
- Nachdem Änderungen erfolgreich genehmigt und zusammengeführt wurden, kann das API Management-Administratorteam die Änderungen in der zentral verwalteten Umgebung (Staging, Produktion) in Abstimmung mit vereinbarten API-Teamplänen bereitstellen.
Erwägungen zur Unternehmensebene
Die folgenden Annahmen wurden bei der Entwicklung des API Management-Zielzonenbeschleunigers einbezogen:
- Verwenden von Infrastructure-as-Code-Bicep-Dateien zum Bereitstellen API Management-Infrastruktur und Back-Ends.
- Bereitstellung von Infrastrukturvorlagen mithilfe von Pipelines.