AWS-CodeDeploy-Häufig gestellte Fragen

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 spezielle Version eines bereitstellungsfähigen Inhalts, etwa Quellcode, Postbuild-Artefakte, Webseiten, ausführbare Dateien und Bereitstellungsscripts, die mit einer AppSpec-Datei bereitgestellt wird. 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 im Abschnitt Arbeiten mit Amazon EC2-Tags in der Konsole. Weitere Informationen zur Bereitstellung für Auto Scaling-Gruppen finden Sie im Abschnitt 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 Konfiguration von Bereitstellungen finden Sie im Abschnitt Instance-Status.

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. 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 AppSpec-Dateien, einschließlich aller Optionen, die festgelegt werden können, finden Sie in der Referenz zu AppSpec-Dateien.

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 Benutzer-Scripts 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 Benutzer-Scripts 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-Managementkonsole anmelden und sofort mit der Verwendung von AWS CodeDeploy beginnen. Einen Überblick über den Service finden Sie im Abschnitt Erste Schritte. Sie finden dort auch ein Schritt-für-Schritt-Tutorial.

Die Amazon EC2-Instance muss einem IAM-Instance-Profil zugeordnet sein und sollte unter einem unterstützten Betriebssystem laufen. Weitere Informationen finden Sie im Abschnitt Verwendung einer bestehenden Amazon EC2-Instance.

Die folgende Grafik zeigt die üblichen Schritte während einer Bereitstellung. Beim Erstellen einer Anwendungs- und Bereitstellungsgruppe (diese Begriffe werden im Abschnitt Konzepte erläutert) handelt es sich um Einrichtungsaufgaben, die normalerweise nur einmal pro Anwendung durchgeführt werden. Die regelmäßigen Aktionen sind das Hochladen einer Revision und deren Bereitstellung. Eine detaillierte Erläuterung mit Schritt-für-Schritt-Anweisungen für jede dieser Aufgaben finden Sie im Abschnitt Bereitstellungen.

Sie können über die AWS-Managementkonsole, die AWS Command Line Interface (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 sog. AppSpec-Datei) zum Stammverzeichnis Ihres Revisionspakets hinzu, die festlegt, welche Dateien kopiert und welche Scripts ausgeführt werden sollen.

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 für die Speicherung von Revisionen finden Sie im Abschnitt Übertragen einer 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 zur Illustration der Verwendung von AWS CodeDeploy mit Konfigurationsmanagement-Systemen wie Chef, Puppet, Ansible und Saltstack 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. Vorgefertigte Integrationen und Beispiele finden Sie auf unserer Seite mit Produktintegrationen.

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 Ereignissen im Lebenszyklus von Instances mit Auto Scaling-Gruppen finden Sie im Abschnitt Auto-Scaling-Gruppe-Lebenszyklus.

Sie können über die AWS-Managementkonsole, die AWS Command Line Interface (AWS CLI), die AWS SDKs und die AWS CodeDeploy-APIs den Status einer Bereitstellung nachverfolgen. 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 Service-Limits finden Sie im Abschnitt Limits. Wenn Sie Ihre Service-Limits anheben möchten, senden Sie Ihre Anfrage an das AWS Support-Center.

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 Management Console aktivieren.

Sie können Benachrichtigungen für Ereignisse erstellen, die sich auf Ihre Bereitstellungen auswirken. Benachrichtigungen erfolgen in Form von Amazon-SNS-Benachrichtigungen. 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 im Benutzerhandbuch für Benachrichtigungen. Zusätzlich können Nutzer von AWS Chatbot Benachrichtigungen konfigurieren, die an ihre Slack-Channels 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 in den Abschnitten 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 in der Referenz zu Zugriffsberechtigungen.

Weitere Informationen zur Verfügbarkeit von CodeDeploy nach Regionen finden Sie im Abschnitt Regionale Produkte und Services.

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 Preisangaben.