Allgemeines
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.
F: Für wen ist AWS CodeDeploy gedacht?
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. Für andere Betriebssysteme ist der AWS CodeDeploy-Agent hier als Open Source-Software verfügbar. Weitere Informationen zur Betriebssystemunterstützung finden Sie in der Dokumentation zu AWS CodeDeploy.
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 unserer Seite mit 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.
F: Unterstützt AWS CodeDeploy lokale Instances?
Ja. AWS CodeDeploy unterstützt alle Instances, die den CodeDeploy-Agenten installieren und sich mit öffentlichen Endpunkten von AWS verbinden können.
Konzepte
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-Elemente, 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.
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:
- Revision: legt fest, was bereitgestellt wird.
- Bereitstellungsgruppe: legt fest, wo die Bereitstellung erfolgt.
- Bereitstellungskonfiguration: ein optionaler Parameter, der festlegt, wie die Bereitstellung erfolgt.
F: Was ist eine AppSpec-Datei?
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.
version: 0.0
os: linux
files:
# You can specify one or more mappings in the files section.
- source: /
destination: /var/www/html/WordPress
hooks:
# The lifecycle hooks sections allows you to specify deployment scripts.
ApplicationStop:
# Step 1: Stop Apache and MySQL if running.
- location: helper_scripts/stop_server.sh
BeforeInstall:
# Step 2: Install Apache and MySQL.
# You can specify one or more scripts per deployment lifecycle event.
- location: deploy_hooks/puppet-apply-apache.sh
- location: deploy_hooks/puppet-apply-mysql.sh
AfterInstall:
# Step 3: Set permissions.
- location: deploy_hooks /change_permissions.sh
timeout: 30
runas: root
# Step 4: Start the server.
- location: helper_scripts/start_server.sh
timeout: 30
runas: root
F: Was sind Ereignisse im Lebenszyklus der Bereitstellung?
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 | Beschreibung |
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. |
Erste Schritte
F: Was sind die ersten Schritte mit AWS CodeDeploy?
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.
Verwendung von AWS CodeDeploy
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-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 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-Lebenszyklus.
Den Status einer Bereitstellung können Sie über die AWS-Managementkonsole, die AWS-Befehlszeilenschnittstelle (AWS CLI), die AWS SDKs und die AWS CodeDeploy-APIs nachverfolgen. Hier sehen Sie auch den Gesamtstatus einer Bereitstellung mit detaillierten Informationen zum Status der einzelnen Instances sowie der Ereignisse im Bereitstellungslebenszyklus jeder Instance. 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.
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 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.
Sicherheit
F: Kann ich AWS CodeDeploy zur Bereitstellung einer Anwendung für Amazon EC2-Instances verwenden, die in einer Amazon Virtual Private Cloud (VPC) ausgeführt werden?
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.
F: Kann ich AWS Identity and Access Management (IAM) zum Verwalten des Zugriffs auf AWS CodeDeploy verwenden?
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.
Regionen
F: Welche Regionen unterstützt AWS CodeDeploy?
Weitere Informationen zur Verfügbarkeit von CodeDeploy nach Regionen finden Sie im Abschnitt Regionale Produkte und Services.
Fakturierung
F: Wie viel kostet AWS CodeDeploy?
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 der Preisübersicht.
AWS CodeDeploy – Produktintegrationen