Entwicklung, Bereitstellung und Betrieb von Anwendungen in der Cloud

Amazon Web Services bietet inzwischen zahlreiche Dienste, die über das Bereitstellen von Infrastruktur in der Cloud hinaus auch das Entwickeln und Aktualisieren von Anwendungen erlauben. Der Artikel „In der Pipeline“ in iX 5/2019 stellte die Tools CodeCommit und CodeBuild vor, die zusammen den Continuous-Integration-Teil (CI) einer AWS-basierten DevOps-Pipeline abdecken. Dieser zweite Teil widmet sich dem Betreiben einer automatisierten De­livery-Pipeline (CD) in der Wolke mithilfe von CodeDeploy und CodePipeline.

CodeDeploy: Allseits einsatzbereit

CodeDeploy eignet sich – im Gegensatz etwa zu AWS CloudFormation – nur für die Bereitstellung von Anwendungen, nicht von Infrastruktur. Der Unterschied ist bedeutsam: Weil sich nahezu alles in AWS als Code beschreiben lässt, verschwimmen in der Cloud die klassischen Grenzen. Im Gegensatz zu anderen AWS-Bereitstellungsoptionen kann CodeDeploy Anwendungen allerdings nicht nur auf EC2-Instanzen oder serverlos (auf der AWS Lambda-Plattform) in der Cloud bereitstellen. Sie lassen sich ebenso gut auf lokalen Instanzen im eigenen Rechenzentrum platzieren oder auf virtuellen Servern, die bei anderen Cloud-Providern laufen. Wenn die Bereitstellung auf EC2-Instanzen (Amazon Elastic Com­pute Cloud) oder lokalen Servern erfolgt, muss dort der CodeDeploy-Agent installiert sein. Er ist unabdingbar, weil nur er Zugriff auf den öffentlichen CodeDeploy-­Endpunkt in der AWS-Cloud hat und entsprechende Metriken an den AWS-Service zurückschickt. Das erlaubt wiederum dem AWS-Service, Rückschlüsse zu ziehen, ob Deployments erfolgreich verlaufen sind oder ob es Fehler gab. Diese würden zum Beispiel einen Rollback auslösen. Möchte man also On-Premises-Server von CodeDeploy bespielen lassen, müssen diese Zugriff auf das öffentliche Internet haben.