Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Kontinuierliche Bereitstellung von CNF Dieser Schritt besteht aus einer Abfolge von Schritten, die wiederholt ausgeführt werden, um Änderungen bereitzustellen, die Teil von container/configuration Änderungen sind, die zu Upgrades führen. Die kontinuierliche Bereitstellung von CNF wird über Pipelines automatisiert und ist anwendungsspezifisch. AWS verwendet Standard-Helm-Charts, um spezifische zu aktualisieren. CNFs In der Code-Pipeline wird der Status der Anwendungsupdates vor und nach der Aktualisierung überprüft. Die aktualisierte CI/CD Pipeline ist auch in ein Testautomatisierungs-Framework integriert, um automatisierte Tests durchzuführen. Diese Abstraktion ermöglicht eine saubere Bereitstellung von Netzwerkfunktionen. Continuous Delivery and Deployment von CNF lassen sich grob in die folgenden Kategorien einteilen: + **Anwendungsupgrades** — Bei den meisten Anwendungsupgrades handelt es sich um Änderungen innerhalb der Kuberbetes-Anwendung. PODs Diese Updates können automatisch über die Code-Pipeline angewendet werden. Die meisten CNFs unterstützen direkte Upgrades, indem sie mehrere PODs Anwendungsinstanzen bereitstellen. Mehrere Instanzen ermöglichen einen schrittweisen Upgrade-Ansatz. Nicht alle POD-Änderungen der Anwendung unterstützen das Helm-Upgrade. Pipelines berücksichtigen diese Variationen und verwenden Helm nach install/delete Bedarf. + **Größere Upgrades — Bei** größeren Upgrades handelt es sich in erster Linie um Änderungen des Datenbankschemas. Diese Änderung kann nicht angewendet werden, ohne dass es zu Ausfallzeiten kommt. Der Standardansatz für diese Änderungen besteht darin, die Anwendung zu löschen und die entsprechenden Pods neu zu erstellen. Während des Vorgangs ist die Anwendung möglicherweise nicht verfügbar. Die folgenden Tools werden für Upgrades verwendet: + CloudFormationMit [**AWS**](https://aws.amazon.com/cloudformation/) können Kunden alle Infrastrukturressourcen in JSON- oder YAML-Vorlagen beschreiben und bereitstellen. CloudFormation bietet einen leistungsstarken Erweiterungsmechanismus durch Lambda-gestützte benutzerdefinierte Ressourcen. Kunden können AWS CloudFormation über AWS-Ressourcen hinausgehen und die erforderlichen Ressourcen in anderen Umgebungen bereitstellen, z. B. lokale Ressourcen in Hybridumgebungen. AWS CDK bietet Entwicklern die Möglichkeit, Code mit vertrauten Programmiersprachen auf höherer Ebene wie Python,, TypeScript JavaScript, Java und C\# zu erstellen und den Code dann in ein niedrigeres CloudFormation JSON-Format zu kompilieren, das dann bereitgestellt werden kann. + **BlueGreen Bereitstellung** — AWS unterstützt blue/green und empfiehlt Bereitstellungen auf kanarischer Basis sowohl in Test- als auch in Produktionsumgebungen. [ Blue/green Bereitstellungen](https://aws.amazon.com/quickstart/architecture/blue-green-deployment/) ermöglichen es Kunden, eine neue Anwendungsversion in einer geschlossenen Umgebung zu testen. Sie bieten eine einfache und elegante Methode, um den Produktionsdatenverkehr umzuschalten. [ Bereitstellungen auf den Kanarischen Inseln](https://wa.aws.amazon.com/wat.concept.canary-deployment.en.html) erweitern dieses Konzept, indem sie es ermöglichen, die grüne Umgebung außerhalb der Produktion mit einem kleinen Teil des Produktionsverkehrs zu testen, um alle Probleme aufzudecken, die durch den Produktionsverkehr verursacht werden. Die neue Anwendungsversion wird sowohl mit internem simuliertem Testdatenverkehr als auch mit geringen Mengen an Produktionsdatenverkehr getestet, was den Benutzern Sicherheit gibt, bevor sie auf den Produktionsdatenverkehr umsteigen. Der Produktionsdatenverkehr wird schrittweise erhöht, bis die Umstellung abgeschlossen ist. Die Implementierung umfasst gewichtete DNS- und gewichtete ELB-Zielgruppen. + Die **Automatisierung** kann durch die Konfiguration AWS CodePipeline mit den Bereitstellungsphasen blue/green und den einzelnen Bereitstellungsphasen erreicht werden. Die Genehmigungsphase kann zunächst während der Bereitstellung manuell gesteuert werden, sollte später jedoch vollständig automatisiert werden. In den Testumgebungen empfiehlt es sich, vor der Bereitstellung in der Produktion immer mit einer Rollback-Aktion zu testen, um die Vorwärts- und Rückwärtskompatibilität zu überprüfen. Die blue/green Bereitstellung auf Clustern mit Service Mesh hängt von der Unterstützung ab, die von der Endanwendung und dem Routing-Gateway für das Service Mesh bereitgestellt wird, um einen reibungslosen Übergang zu gewährleisten. + [**AWS Systems Manager**](https://aws.amazon.com/systems-manager/) bietet eine einheitliche Benutzeroberfläche, sodass Sie Betriebsdaten von mehreren AWS-Services anzeigen können, die von Netzwerkfunktionen verwendet werden, die von CI/CD bereitgestellt werden. Mit Systems Manager können Sie betriebliche Aufgaben AWS ressourcenübergreifend automatisieren. ![Ein Diagramm, das die Bereitstellung auf Canary darstellt.](http://docs.aws.amazon.com/de_de/whitepapers/latest/cicd_for_5g_networks_on_aws/images/cicd_5g10.png) *Einsatz auf Canary*