AWS-CodeDeploy-Häufig gestellte Fragen

AWS CodeDeploy ist ein Service, der die Codebereitstellung für beliebige Instances, einschließlich Amazon EC2- und lokale Instances, automatisiert. Mit AWS CodeDeploy können Sie leichter schnell neue Funktionen freigeben, besser Ausfallzeiten während der Bereitstellung vermeiden und komplexe Aktualisierungen Ihrer Anwendungen einfacher handhaben. Sie können AWS CodeDeploy zur Automatisierung von Bereitstellungen verwenden, was fehleranfällige manuelle Operationen überflüssig macht. Der Service skaliert mit Ihrer Infrastruktur, sodass Sie problemlos Code für eine oder Tausende von Instances bereitstellen können.

AWS CodeDeploy ist für Entwickler und Administratoren konzipiert, die Anwendungen für beliebige Instances, einschließlich Amazon EC2- und lokale Instances, bereitstellen müssen. Es ist flexibel und kann von jedem verwendet werden, der auf seinen Instances Software aktualisieren oder Scripts ausführen möchte.

AWS CodeDeploy kann zur Bereitstellung jedes Anwendungstyps verwendet werden. Wenn Sie AWS CodeDeploy verwenden möchten, legen Sie für jede Instance fest, welche Dateien kopiert und welche Scripts während der Bereitstellung ausgeführt werden sollen. AWS CodeDeploy ist programmiersprachen- und architekturunabhängig. Sie können also Scripts für jede benutzerdefinierte Bereitstellungslogik verwenden.

AWS CodeDeploy unterstützt eine Vielzahl von Betriebssystemen. AWS CodeDeploy bietet auf Amazon Linux, Red Hat Enterprise Linux, Ubuntu Server und Microsoft Windows Server getestete Agenten. Wenn Sie andere Betriebssysteme verwenden möchten, ist der AWS CodeDeploy Agent hier als Open-Source-Software verfügbar. Weitere Informationen zur Betriebssystemunterstützung finden Sie in der AWS CodeDeploy-Dokumentation.

Ja. AWS CodeDeploy funktioniert mit einer Reihe von Konfigurationsmanagement-Systemen, Continuous Integration- und Continuous Deployment-Systemen sowie Source-Control-Systemen. Weitere Informationen finden Sie auf der Seite Produktintegrationen.

AWS CodeDeploy ist ein Baukasten-Service, der Entwicklern helfen soll, Software auf beliebigen Instances, einschließlich Amazon EC2- und lokalen Instances, bereitzustellen und zu aktualisieren. AWS Elastic Beanstalk und AWS OpsWorks sind End-to-End-Anwendungsverwaltungslösungen.

Ja. AWS CodeDeploy unterstützt jede Instanz, die den CodeDeploy-Agenten installieren und eine Verbindung zu öffentlichen AWS-Endpunkten herstellen kann.

Eine Anwendung ist eine Software- und Konfigurationssammlung, die für eine Gruppe von Instances bereitgestellt werden soll. Normalerweise wird auf Instances in der Gruppe dieselbe Software ausgeführt. Wenn Sie beispielsweise ein großes verteiltes System haben, wird die Webebene wahrscheinlich eine Anwendung bilden und die Datenebene eine andere.

Eine Revision ist eine bestimmte Version von bereitstellbarem Inhalt, wie Quellcode, Post-Build-Artefakten, Webseiten, ausführbaren Dateien und Bereitstellungsskripten, zusammen mit einer AppSpec-Datei. Der AWS CodeDeploy-Agent kann auf eine Revision aus GitHub oder einem Amazon S3-Bucket zugreifen.

Eine Bereitstellungsgruppe ist die AWS CodeDeploy-Entität zum Gruppieren von EC2-Instances oder AWS Lambda-Funktionen in einer CodeDeploy-Bereitstellung. Für EC2-Bereitstellungen ist eine Bereitstellungsgruppe eine Gruppe von Instances, die einer Anwendung zugeordnet sind, die Ziel einer Bereitstellung ist. Sie können Instances zu einer Bereitstellungsgruppe hinzufügen, indem Sie einen Tag, einen Auto Scaling-Gruppenamen oder beides festlegen. Bei einer AWS Lambda-Bereitstellung legt eine Bereitstellungsgruppe dagegen einen AWS CodeDeploy-Konfigurationssatz für künftige serverlose Lambda-Bereitstellungen für die Gruppe fest, beispielsweise deren Alarme und Rollbacks.

Sie können mehrere Bereitstellungsgruppen für eine Anwendung definieren, etwa Staging und Produktion. Informationen zu Tags finden Sie unter Arbeiten mit Amazon EC2-Tags in der Konsole. Weitere Informationen zur Bereitstellung in Auto Scaling-Gruppen finden Sie unter Auto Scaling-Integration.

Eine Bereitstellungskonfiguration legt für eine Bereitstellungsgruppe fest, wie eine Bereitstellung ausgeführt wird, auch wie Fehler bei der Bereitstellung gehandhabt werden. Mit einer Bereitstellungskonfiguration können Sie Bereitstellungen für Bereitstellungsgruppen mit mehreren Instances ohne Ausfallzeit bewerkstelligen. Wenn für Ihre Anwendung beispielsweise mindestens 50 % der Instances in einer Bereitstellungsgruppe einsatzbereit sein und Datenverkehrsanforderungen erfüllen müssen, so können Sie das in Ihrer Bereitstellungskonfiguration festlegen, damit die Bereitstellung keine Ausfallzeit verursacht. Wurde weder der Bereitstellung noch der Bereitstellungsgruppe eine Bereitstellungskonfiguration zugeordnet, so stellt AWS CodeDeploy standardmäßig immer jeweils für eine Instance bereit.  Weitere Informationen zur Bereitstellungskonfiguration finden Sie unter Instance Health.

Für eine Bereitstellung müssen Sie drei Parameter festlegen:

1. Revision: legt fest, was bereitgestellt wird.
2. Bereitstellungsgruppe: legt fest, wo die Bereitstellung erfolgt.
3. Bereitstellungskonfiguration: ein optionaler Parameter, der festlegt, wie die Bereitstellung erfolgt.

Eine AppSpec-Datei ist eine Konfigurationsdatei, die festlegt, welche Dateien kopiert und welche Scripts ausgeführt werden sollen. Die AppSpec-Datei verwendet das YAML-Format, und Sie fügen sie in das Stammverzeichnis Ihrer Revision ein. Die AppSpec-Datei wird durch den AWS CodeDeploy-Agenten verwendet und besteht aus zwei Abschnitten. Der Abschnitt "Files" legt die Quelldateien, die bei Ihrer Revision kopiert werden, sowie den Zielordner auf jeder Instance fest. Der Abschnitt "Hooks" legt den Speicherort (als relativen Pfad ausgehend vom Stamm des Revision-Pakets) der Scripts fest, die während jeder Phase der Bereitstellung ausgeführt werden. Jede Bereitstellungsphase wird "Ereignis im Bereitstellungslebenszyklus" genannt. Im Folgenden finden Sie eine Beispiels-AppSpec-Datei. Weitere Informationen zu einer AppSpec-Datei, einschließlich aller Optionen, die angegeben werden können, finden Sie unter AppSpec-Dateireferenz.

BS: Linux

Dateien: 

# Sie können eine oder mehrere Zuordnungen im Dateibereich angeben.

  - Quelle: /

    Ziel: /var/www/html/WordPress

Hooks:

 # In den Lebenszyklus-Hooks-Abschnitten können Sie Bereitstellungsskripte angeben.

ApplicationStop: 

# Schritt 1: Apache und MySQL anhalten, falls ausgeführt.

    - Ort: helper_scripts/stop_server.sh

BeforeInstall: 

# Schritt 2: Apache und MySQL installieren.

# Sie können ein oder mehrere Skripts pro Bereitstellungslebenszyklusereignis angeben.

    - Ort: deploy_hooks/puppet-apply-apache.sh

    - Ort: deploy_hooks/puppet-apply-mysql.sh 

 AfterInstall: 

# Schritt 3: Berechtigungen festlegen.

    - Ort: deploy_hooks /change_permissions.sh

      timeout: 30

      runas: root

# Schritt 4: Den Server starten.

    - Ort: helper_scripts/start_server.sh

      timeout: 30

      runas: root

Eine Bereitstellung durchläuft eine Reihe vordefinierter Phasen, die "Ereignisse im Bereitstellungslebenszyklus" genannt werden. Ein Ereignis in einem Bereitstellungslebenszyklus bietet Ihnen eine Gelegenheit, Code als Teil der Bereitstellung auszuführen. In der folgenden Tabelle sind verschiedene derzeit unterstützte Ereignisse im Bereitstellungslebenszyklus in der Reihenfolge ihrer Ausführung aufgelistet. Außerdem finden Sie dort einige Beispiele, wann deren Verwendung zu empfehlen ist.

Ereignis im Bereitstellungslebenszyklus:

• ApplicationStop

  • Das ist das erste Ereignis im Bereitstellungslebenszyklus, das sogar noch vor dem Herunterladen der Revision eintritt. Die für dieses Ereignis im Bereitstellungslebenszyklus verwendete AppSpec-Datei und die Scripts stammen aus der letzten erfolgreich bereitgestellten Revision.  

    Sie können das Ereignis "ApplicationStop" im Bereitstellungslebenszyklus verwenden, wenn Sie die Anwendung ordnungsgemäß anhalten oder zur Vorbereitung einer Bereitstellung derzeit installierte Pakete entfernen möchten.

• DownloadBundle

  • Während dieses Ereignisses im Bereitstellungslebenszyklus kopiert der Agent die Revisionsdateien an einen temporären Speicherort in der Instance. Dieses Ereignis im Bereitstellungslebenszyklus ist für den Agenten reserviert und kann nicht für die Ausführung von Benutzerscripts verwendet werden.

• BeforeInstall

  • Sie können das Ereignis "BeforeInstall" im Bereitstellungslebenszyklus verwenden, um Aufgaben, etwa die Entschlüsselung von Dateien, vorzuinstallieren und ein Backup der aktuellen Version zu erstellen.

• Install

  • Während dieses Ereignisses im Bereitstellungslebenszyklus kopiert der Agent die Revisionsdateien vom temporären Speicherort in den endgültigen Zielordner. Dieses Ereignis im Bereitstellungslebenszyklus ist für den Agenten reserviert und kann nicht für die Ausführung von Benutzerscripts verwendet werden.

• AfterInstall

  • Sie können das Ereignis "AfterInstall" im Bereitstellungslebenszyklus für Aufgaben wie das Konfigurieren Ihrer Anwendung oder das Ändern der Dateiberechtigungen verwenden.

• ApplicationStart

  • Normalerweise verwendet man das Ereignis "ApplicationStart" im Bereitstellungslebenszyklus für den Neustart der Services, die während "ApplicationStop" angehalten wurden.

• ValidateService

  • "ValidateService" ist das letzte Ereignis im Bereitstellungslebenszyklus und bietet Gelegenheit, zu überprüfen, ob die Bereitstellung erfolgreich abgeschlossen wurde.

Sie können sich bei der AWS Management Console anmelden und mit der Nutzung von AWS CodeDeploy beginnen. Einen schnellen Überblick über den Service finden Sie unter Erste Schritte, der eine schrittweise Anleitung enthält.

Die Amazon EC2-Instance muss mit einem IAM-Instance-Profil verknüpft sein und sollte ein unterstütztes Betriebssystem ausführen. Weitere Informationen finden Sie unter Verwenden einer vorhandenen Amazon EC2-Instance.

Die folgende Grafik zeigt die üblichen Schritte während einer Bereitstellung. Das Erstellen einer Anwendung und einer Bereitstellungsgruppe (eine Erläuterung dieser Begriffe finden Sie im Abschnitt Konzepte) sind in der Regel einmalige Einrichtungsaufgaben pro Anwendung. Die regelmäßigen Aktionen sind das Hochladen einer Revision und deren Bereitstellung. Eine ausführliche Erklärung, einschließlich schrittweiser Anleitungen für jede dieser Aufgaben, finden Sie unter Bereitstellungen.

Sie können über die AWS-Managementkonsole, die AWS-Befehlszeilenschnittstelle (AWS CLI), die AWS-SDKs und die AWS CodeDeploy-APIs auf AWS CodeDeploy zugreifen.

Sie müssen Ihren Code nicht ändern. Sie fügen einfach eine Konfigurationsdatei (eine sogenannte AppSpec-Datei) in das Stammverzeichnis Ihres Revisionspakets ein, die die zu kopierenden Dateien und die auszuführenden Skripte angibt.

Wenn Sie GitHub verwenden, können Sie eine Revision im ZIP-, TAR- oder TAR.GZ-Format von Ihrem Repository direkt für Instances bereitstellen. Bei anderen Source-Control-Systemen können Sie die Revision im ZIP-, TAR- oder TAR.GZ-Format zusammenstellen, auf einen Amazon S3-Bucket hochladen und bei der Bereitstellung den Speicherort in Amazon S3 festlegen. Benötigt Ihre Anwendung einen Build-Schritt, so vergewissern Sie sich, dass das GitHub-Repository oder der Amazon S3-Bucket die Postbuild-Elemente enthält. Weitere Informationen zur Verwendung von GitHub mit AWS CodeDeploy finden Sie auf unserer Seite mit Produktintegrationen. Weitere Informationen zur Verwendung von Amazon S3 zum Speichern von Revisionen finden Sie unter Push a Revision.

Sie können Ihr Konfigurationsmanagement-Tool von jedem Hook eines Ereignisses im Bereitstellungslebenszyklus in der AppSpec-Datei aufrufen. Wenn Sie beispielsweise ein Chef-Rezept haben, das als Teil einer Bereitstellung ausgeführt werden soll, so können Sie es im entsprechenden Hook des Ereignisses im Bereitstellungslebenszyklus in der AppSpec-Datei angeben. Außerdem können Sie Ihr Konfigurationsmanagement-System nutzen, um den AWS CodeDeploy-Agenten auf Instances zu installieren. Beispiele, die die Verwendung von AWS CodeDeploy mit Konfigurationsmanagementsystemen wie Chef, Puppet, Ansible und Saltstack veranschaulichen, finden Sie auf unserer Seite mit Produktintegrationen.

Ja. Sie können AWS CodeDeploy in Ihre Continuous Integration- und Continuous Deployment-Systeme integrieren, indem Sie mit der AWS-Befehlszeile oder AWS SDKs die öffentlichen APIs aufrufen. Auf unserer Produktintegrationsseite finden Sie vorgefertigte Integrationen und Beispiele.

Stellen Sie für die Bereitstellungsgruppe Ihre neueste Revision bereit, damit die neu hinzugefügten Instances Ihre Anwendung erhalten. AWS CodeDeploy stellt nur für Instances, die als Teil einer Auto Scaling-Gruppe gestartet werden, automatisch die neueste Revision bereit, nicht für andere neu hinzugefügte Amazon EC2-Instances.

Sie können einer Auto Scaling-Gruppe eine Bereitstellungsgruppe zuordnen, um sicherzustellen, dass neu in Betrieb genommene Instances immer die neueste Version Ihrer Anwendung erhalten. Jedes Mal, wenn eine neue Amazon EC2-Instance für diese Auto Scaling-Gruppe gestartet wird, wird sie zuerst in den Status "Pending" gesetzt und eine Bereitstellung der neuesten erfolgreichen Revision für diese Bereitstellungsgruppe auf dieser Amazon EC2-Instance ausgelöst. Ist die Bereitstellung erfolgreich fertiggestellt, so wird der Status der Amazon EC2-Instance auf "InService" geändert. Wenn diese Bereitstellung fehlschlägt, wird die Amazon EC2-Instance beendet, eine neue Amazon EC2-Instance mit dem Status "Pending" gestartet und eine Bereitstellung für die neu gestartete EC2-Instance ausgelöst. Weitere Informationen zu Lebenszyklusereignissen von Auto Scaling-Gruppeninstanzen finden Sie unter Auto Scaling Group Lifecycle.

Sie können den Status einer Bereitstellung mithilfe der AWS-Managementkonsole, der AWS-Befehlszeilenschnittstelle (AWS CLI), der AWS-SDKs und der AWS CodeDeploy-APIs verfolgen. Sie können den Gesamtstatus einer Bereitstellung einsehen und tiefer nachforschen, um den Status jeder Instance und den Status jedes Bereitstellungslebenszyklusereignisses für die Instance anzuzeigen. Sie können auch die Protokolleinträge zu jedem Fehler einsehen, sodass Sie Probleme bei der Bereitstellung einfach debuggen können, ohne sich bei Ihrer Instance anzumelden.

Ja. Wenn Sie eine im Gang befindliche Bereitstellung stoppen, weist der AWS CodeDeploy-Service den Agenten auf jeder Instance an, die Ausführung weiterer Scripts einzustellen. Um Ihre Anwendung wieder in einen konsistenten Zustand zu bringen, können Sie entweder die Revision erneut bereitstellen oder eine andere Revision bereitstellen.

Wenn Sie ein Rollback Ihrer Anwendung auf eine frühere Revision durchführen möchten, müssen Sie lediglich diese Revision bereitstellen. AWS CodeDeploy verfolgt die für die aktuelle Revision kopierten Dateien und entfernt diese vor dem Start der neuen Bereitstellung. Es besteht also kein Unterschied zwischen erneuter Bereitstellung und Rollback. Sie müssen jedoch sicherstellen, dass die älteren Revisionen für ein Rollback verfügbar sind.

Ja. Sie können einen Amazon S3-Bucket mit Versioning verwenden und die Versions-ID angeben, um die Revision eindeutig zu identifizieren.

Informationen zu den Servicelimits finden Sie unter Limits. Um Ihre Servicelimits zu erhöhen, reichen Sie eine Anfrage über das AWS Support Center ein.

Ja. Zum Abrufen eines Verlaufs aller Aufrufe der AWS CodeDeploy-API, die für Ihr Konto erfolgt sind, müssen Sie lediglich AWS CloudTrail in der AWS-Managementkonsole aktivieren.

Sie können Benachrichtigungen für Ereignisse erstellen, die sich auf Ihre Bereitstellungen auswirken. Benachrichtigungen werden in Form von Amazon SNS-Benachrichtigungen gesendet. Jede Benachrichtigung enthält eine Statusmeldung sowie einen Link zu den Ressourcen, deren Ereignis diese Benachrichtigung ausgelöst hat. Für Benachrichtigungen fallen keine zusätzlichen Kosten an. Möglicherweise werden Ihnen aber andere AWS-Services in Rechnung gestellt, die von Benachrichtigungen genutzt werden, beispielsweise Amazon SNS. Informationen zu den ersten Schritten mit Benachrichtigungen finden Sie in der Benutzeranleitung für Benachrichtigungen. Darüber hinaus können Kunden, die AWS Chatbot verwenden, Benachrichtigungen so konfigurieren, dass sie an ihre Slack-Kanäle oder Amazon Chime-Chatrooms gesendet werden. Weitere Informationen finden Sie hier.

Ja. Der auf Amazon EC2-Instances installierte AWS CodeDeploy-Agent muss jedoch auf die öffentlichen AWS CodeDeploy- und Amazon S3-Service-Endpunkte zugreifen können. Weitere Informationen finden Sie unter AWS CodeDeploy-Endpunkte und Amazon S3-Endpunkte.

Ja. AWS CodeDeploy unterstützt Berechtigungen auf Ressourcenebene. Sie können für jede AWS CodeDeploy-Ressource festlegen, welcher Benutzer Zugriff hat und auf welche Aktionen. Beispielsweise können Sie eine IAM-Richtlinie festlegen, damit ein Benutzer eine bestimmte Anwendung bereitstellen, aber Revisionen nur für andere Anwendungen auflisten kann. Sie können daher verhindern, dass Benutzer unabsichtlich Änderungen an der falschen Anwendung vornehmen. Weitere Informationen zur Verwendung von IAM mit AWS CodeDeploy finden Sie unter Referenz zu Zugriffsberechtigungen.

Einzelheiten zur Verfügbarkeit von CodeDeploy nach Regionen finden Sie unter Regionale Produkte und Dienste.

AWS CodeDeploy führt Bereitstellungen für AWS-Ressourcen in derselben Region durch. Wenn Sie eine Anwendung in mehreren Regionen bereitstellen möchten, definieren Sie die Anwendung in Ihren Zielregionen, kopieren Sie das Anwendungspaket in jeder Region auf einen Amazon S3-Bucket und starten Sie die Bereitstellungen mittels eines entweder seriellen oder parallelen Rollout in diesen Regionen.

Es fallen keine zusätzlichen Gebühren für Codebereitstellungen für Amazon EC2-Instances über AWS CodeDeploy an. Sie bezahlen für jede Aktualisierung einer lokalen Instance mithilfe von AWS CodeDeploy 0,02 USD. Weitere Informationen finden Sie auf der Seite mit den Preisen.