Projekte in AWS

Erstellen einer modernen Webanwendung

Bereitstellen einer Webanwendung, Anbinden an eine Datenbank und Analysieren des Benutzerverhaltens

Modul 2: Hosten Ihrer Anwendung auf einem Web-Server

In diesem Modul erstellen Sie einen neuen Mikroservice, der bei AWS Fargate gehostet wird.  

Übersicht

In diesem Modul erstellen Sie einen neuen Mikroservice, der über AWS Fargate gehostet wird, so dass Ihre Mythical Mysfits Website in ein Anwendungs-Backend integriert werden kann.

AWS Fargate ist eine Bereitstellungsoption im Amazon Elastic Container Service (ECS), mit der Sie Container bereitstellen können, ohne irgendwelche Cluster oder Server verwalten zu müssen. Für unser Mythical Mysfits-Backend werden wir Python verwenden und eine Flask-Anwendung in einem Docker-Container hinter einem Network Load Balancer erstellen. Diese werden das Mikroservice-Backend für die Frontend-Website bilden.

Warum haben wir uns für Fargate entschieden?

Wir haben uns hier für Fargate entschieden, weil es eine gute Wahl für den Aufbau langlaufender Prozesse ist, wie z. B. Mikroservice-Backends für Web- und mobile und PaaS-Plattformen. Mit Fargate erhalten Sie die Kontrolle über Container und die Flexibilität zu wählen, wann sie ausgeführt werden, ohne sich Gedanken über die Bereitstellung oder Skalierung von Servern machen zu müssen. Es bietet volle Kontrolle über Netzwerk, Sicherheit und Service-to-Service-Kommunikation und ist nativ in die AWS-Services für Sicherheit, Netzwerk, Zugriffskontrolle, Entwicklerwerkzeuge, Überwachung und Protokollierung integriert.

Neben Fargate haben die Kunden auch die Möglichkeit, AWS Lambda für ihre Datenverarbeitungsaufgaben zu nutzen. Während Lambda die gleichen serverlosen Vorteile wie Fargate bietet, eignet sich Lambda hervorragend für datengesteuerte Anwendungen, die in Echtzeit auf Datenänderungen, Änderungen des Systemzustands oder Aktionen von Benutzern reagieren müssen. Wir werden Lambda in Modul 5 ausführlicher besprechen, da wir es zur Analyse des Kundenverhaltens auf der Website verwenden.

Implementierungsanweisungen

Folgen Sie den untenstehenden Schritt-für-Schritt-Anleitungen, um Ihren AWS Fargate-Service zu erstellen. Da dies ein großes Modul ist, haben wir es in 3 Untermodule unterteilt. In Modul 2a richten Sie eine Kerninfrastruktur ein, um Ihren Service-Einsatz vorzubereiten. In Modul 2b stellen Sie Ihren Dienst über AWS Fargate bereit. Schließlich werden Sie in Modul 2c die automatische Bereitstellung mit Hilfe von AWS Code Services einrichten.

Modul 2A: Aufbau der Kerninfrastruktur

Bevor wir unseren Dienst erstellen können, müssen wir die Kerninfrastrukturumgebung schaffen, die der Dienst nutzen wird, einschließlich der Netzwerkinfrastruktur in Amazon VPC, und die AWS Identity and Access Management-Rollen, die die Berechtigungen definieren, die ECS und unsere Container über den AWS haben werden.

Wir werden dazu AWS CloudFormation verwenden. AWS CloudFormation ist ein Dienst, der programmatisch AWS-Ressourcen zur Verfügung stellen kann, die Sie in JSON- oder YAML-Dateien namens CloudFormation Templates deklarieren, wodurch die gängige beste Methode der Infrastruktur als Code ermöglicht wird.  

  • Wir haben eine CloudFormation-Vorlage zur Erstellung aller notwendigen Netzwerk- und Sicherheitsressourcen in /module-2/cfn/core.yml bereitgestellt. Diese Vorlage wird die folgenden Ressourcen erstellen:

    • Ein Amazon VPC – eine Netzwerkumgebung, die vier Subnetze (zwei öffentliche und zwei private) im privaten IP-Bereich 10.0.0.0/16 sowie alle erforderlichen Routingtabellenkonfigurationen enthält. Die Teilnetze für dieses Netzwerk werden in separaten AWS Availability Zones (AZ) erstellt, um eine hohe Verfügbarkeit über mehrere physische Einrichtungen in einer AWS-Region zu ermöglichen. Erfahren Sie mehr darüber, wie AZs Ihnen helfen können, Hochverfügbarkeit zu erreichen.
    • Zwei NAT Gateways (einer für jedes öffentliche Subnetz): ermöglicht es den Containern, die wir irgendwann in unseren privaten Subnetzen einsetzen werden, mit dem Internet zu kommunizieren, um notwendige Pakete herunterzuladen, usw.
    • Ein DynamoDB VPC-Endpunkt: Unser Mikrodienst-Backend wird schließlich in die Amazon DynamoDB für Persistenz integriert werden (als Teil von Modul 3).
    • Eine Sicherheitsgruppe: Ermöglicht es Ihren Docker-Containern, Datenverkehr auf Port 8080 aus dem Internet über den Network Load Balancer zu empfangen.
    • IAM-Rollen: Identity and Access Management-Rollen werden erstellt. Diese werden während des gesamten Workshops verwendet, um AWS-Services oder Ressourcen, die Sie erstellen, Zugang zu anderen AWS-Services wie DynamoDB, S3, und mehr zu geben.

    Um diese Ressourcen zu erstellen, führen Sie den folgenden Befehl im Cloud9-Terminal aus (es dauert ~10 Minuten, bis der Stack erstellt ist):

    aws cloudformation create-stack --stack-name MythicalMysfitsCoreStack --capabilities CAPABILITY_NAMED_IAM --template-body file://~/environment/aws-modern-application-workshop/module-2/cfn/core.yml

    Sie können den Status Ihrer Stack-Erstellung entweder über die AWS-Konsole oder durch Ausführen des Befehls überprüfen:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack

    Führen Sie den Befehl "describe-stacks" aus, bis Sie den Status "StackStatus": "CREATE_COMPLETE" sehen

    Stack beschreiben

    (zum Vergrößern klicken)

    Wenn Sie diese Antwort erhalten, hat CloudFormation die Bereitstellung aller oben beschriebenen zentralen Netzwerk- und Sicherheitsressourcen abgeschlossen, und Sie können fortfahren. Warten Sie, bis der obige Stapel CREATE_COMPLETE anzeigt, bevor Sie fortfahren.

    Im weiteren Verlauf des Workshops werden Sie Werte aus der Ausgabe dieses Befehls verwenden. Sie können den folgenden Befehl ausführen, um den oben beschriebenen Befehl describe-stacks direkt in eine neue Datei in Ihrer IDE auszugeben, die als cloudformation-core-output.json gespeichert wird:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack > ~/environment/cloudformation-core-output.json

Modul 2B: Bereitstellung eines Dienstes mit AWS Fargate

Als nächstes erstellen Sie ein Docker-Container-Image, das den gesamten Code und die Konfiguration enthält, die für die Ausführung des Mythical Mysfits-Backends als eine mit Flask erstellte Mikroservice-API erforderlich sind. Wir werden das Docker-Container-Image innerhalb von Cloud9 erstellen und es dann an die Amazon Elastic Container Registry weiterleiten, wo es bei der Erstellung unseres Dienstes mit Fargate abgerufen werden kann.

Architekturdiagramm

Browser zum Laden des Balancers zu Fargate
  • A: Ein Docker-Image erstellen

    Der gesamte für die Ausführung unseres Service-Backends erforderliche Code ist im Verzeichnis /module-2/app/ des Repositorys gespeichert, das Sie in Ihre Cloud9-IDE geklont haben. Wenn Sie den Python-Code überprüfen möchten, der Flask zur Erstellung der Service-API verwendet, sehen Sie sich die Datei /module-2/app/service/mythicalMysfitsService.py an.

    Docker ist auf der von Ihnen erstellten Cloud9-IDE bereits installiert. Um das Docker-Image lokal zu erstellen, müssen wir also nur die folgenden beiden Befehle im Cloud9-Terminal ausführen:  

    Wechseln Sie zunächst in das Verzeichnis ~/environment/module-2/app

    cd ~/environment/aws-modern-application-workshop/module-2/app

    Sie können Ihre Konto-ID und die Standardregion aus der Ausgabe der früheren CloudFormation **describe-Stacks erhalten

    Ersetzen Sie im folgenden Befehl REPLACE_ME_ACCOUNT_ID durch Ihre Konto-ID und REPLACE_ME_REGION durch Ihre Standardregion, um das Docker-Image unter Verwendung der Datei Dockerfile, die Docker-Anweisungen enthält, zu erstellen. Der Befehl versieht das Docker-Image unter Verwendung der Option -t mit einem spezifischen Tag-Format, so dass das Imagespäter an den Amazon Elastic Container Registry-Dienst übergeben werden kann.

    Sobald Sie Ihre Konto-ID haben, sind Sie bereit, das Docker-Image zu erstellen:

    docker build . -t REPLACE_ME_AWS_ACCOUNT_ID.dkr.ecr.REPLACE_ME_REGION.amazonaws.com/mythicalmysfits/service:latest

    Sie werden sehen, wie der Docker alle notwendigen Abhängigkeitspakete, die unsere Anwendung benötigt, herunterlädt und installiert und das Tag für das erstellte Image ausgibt. Kopieren Sie das Image-Tag für eine spätere Referenz. Im Folgenden wird das Beispiel-Tag gezeigt: 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    Successfully built 8bxxxxxxxxab
    Successfully tagged 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest
    B: Den Dienst vor Ort testen

    Testen wir unser Image lokal innerhalb der Cloud9, um sicherzustellen, dass alles wie erwartet funktioniert. Kopieren Sie den Image-Tag, der sich aus dem vorherigen Befehl ergab, und führen Sie den folgenden Befehl aus, um den Container "lokal" (d. h. innerhalb Ihrer Cloud9-IDE innerhalb der AWS!) bereitzustellen:

    docker run -p 8080:8080 REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Als Ergebnis sehen Sie, dass Docker meldet, dass Ihr Container lokal verfügbar ist und läuft:

     * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

    Um unseren Dienst mit einer lokalen Anfrage zu testen, werden wir den integrierten Webbrowser innerhalb der Cloud9-IDE öffnen, der zur Vorschau von Anwendungen verwendet werden kann, die auf der IDE-Instanz laufen.

    Um den Vorschau-Webbrowser zu öffnen, wählen Sie Vorschau > Vorschau der laufenden Anwendung in der Cloud9-Menüleiste:

    preview-menu

     

    Dadurch wird ein weiterer Bereich in der IDE geöffnet, in dem der Webbrowser verfügbar sein wird. Fügen Sie /mysfits an das Ende der URI in der Adressleiste des Vorschaubrowsers an und drücken Sie ENTER:

    address-bar

    Bei Erfolg erhalten Sie eine Antwort vom Dienst, die das JSON-Dokument zurückgibt, das unter `/aws-modern-application-workshop/module-2/app/service/mysfits-response.json` gespeichert ist.

    Wenn Sie mit dem Testen des Dienstes fertig sind, können Sie ihn durch Drücken von CTRL-c auf PC oder Mac stoppen.

    C: Verschieben des Docker-Images zum Amazon ECR

    Nach einem erfolgreichen Test unseres Dienstes vor Ort sind wir bereit, ein Container-Image-Repository in der Amazon Elastic Container Registry (Amazon ECR) zu erstellen und unser Image darin zu integrieren. Um das Register zu erstellen, führen Sie den folgenden Befehl aus. Dadurch wird ein neues Repository im standardmäßigen AWS ECR-Register erstellt, das für Ihr Konto erstellt wurde.

    aws ecr create-repository --repository-name mythicalmysfits/service

    Die Antwort auf diesen Befehl enthält zusätzliche Metadaten über das erstellte Repository. Um Container-Images in unser neues Repository zu schieben, müssen wir für unseren Docker-Client Authentifizierungs-Zugangsdaten für das Repository erhalten.

    Führen Sie den folgenden Befehl aus, der einen Anmeldebefehl zurückgibt, um Anmeldeinformationen für unseren Docker-Client abzurufen, und führen Sie ihn dann automatisch aus (einschließlich des vollständigen Befehls einschließlich des $ unten). 'Login erfolgreich' wird gemeldet, wenn der Befehl erfolgreich ist.

    $(aws ecr get-login --no-include-email)

    Als Nächstes schieben Sie das von Ihnen erstellte Image mit dem kopierten Tag von oben in das ECR-Repository. Mit diesem Befehl schiebt Docker Ihr Image und alle davon abhängigen Images an Amazon ECR:

    docker push REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Führen Sie den folgenden Befehl aus, um Ihr neu verschobenes Docker-Image zu sehen, das im ECR-Repository gespeichert ist:

    aws ecr describe-images --repository-name mythicalmysfits/service
  • A: Einen AWS Fargate Cluster erstellen

    Jetzt haben wir ein Image in ECR verfügbar, das wir mit AWS Fargate auf einem Dienst bereitstellen können, der auf Amazon ECS gehostet wird. Derselbe Dienst, den Sie als Teil des letzten Moduls lokal über das Terminal in der Cloud9 getestet haben, wird nun in der Cloud bereitgestellt und hinter einem Network Load Balancer öffentlich verfügbar sein.

    Zunächst werden wir ein Cluster im Amazon Elastic Container Service (ECS) erstellen. Dies stellt den Cluster von "Servern" dar, auf dem Ihre Service-Container bereitgestellt werden. Server sind in Anführungszeichen, weil Sie AWS Fargate benutzen werden. Mit Fargate können Sie festlegen, dass Ihre Container in einem Cluster bereitgestellt werden, ohne dass Sie selbst Server bereitstellen oder verwalten müssen.

    Um einen neuen Cluster in ECS zu erstellen, führen Sie den folgenden Befehl aus:

    aws ecs create-cluster --cluster-name MythicalMysfits-Cluster
    B: Erstellen einer AWS CloudWatch Logs-Gruppe

    Als Nächstes werden wir eine neue Log-Gruppe in AWS CloudWatch Logs erstellen. AWS CloudWatch Logs ist ein Dienst zur Sammlung und Analyse von Logs. Die Logs, die Ihr Container erzeugt, werden automatisch in die AWS CloudWatch Logs als Teil dieser speziellen Gruppe verschoben. Dies ist besonders wichtig bei der Verwendung von AWS Fargate, da Sie keinen Zugriff auf die Server-Infrastruktur haben, auf der Ihre Container laufen.

    Um die neue Log-Gruppe in CloudWatch Logs zu erstellen, führen Sie den folgenden Befehl aus:

    aws logs create-log-group --log-group-name mythicalmysfits-logs
    C: Eine ECS-Aufgabendefinition registrieren

    Nun, da wir einen Cluster erstellt und eine Log-Gruppe definiert haben, in die unsere Container-Logs geschoben werden, sind wir bereit, eine ECS-Aufgabendefinition zu registrieren. Eine Aufgabe in ECS ist ein Satz von Container-Images, die zusammen geplant werden sollten. Eine Aufgabendefinition deklariert diesen Satz von Containern sowie die Ressourcen und die Konfiguration, die diese Container benötigen. Sie werden die AWS CLI verwenden, um eine neue Aufgabendefinition dafür zu erstellen, wie Ihr neues Container-Image in den soeben erstellten ECS-Cluster eingeplant werden soll.

    Es wurde eine JSON-Datei bereitgestellt, die als Eingabe für den CLI-Befehl dient.

    Öfnnen Sie ~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json in der IDE.

    Ersetzen Sie die angegebenen Werte durch die entsprechenden Werte aus Ihren erstellten Ressourcen.

    Diese Werte werden aus der CloudFormation-Antwort gezogen, die Sie zuvor kopiert haben, sowie aus dem Docker-Image-Tag, das Sie zuvor an ECR übergeben haben, z. B.: REPLACE_ME_ACCOUNT_ID.dkr.ecr.us-ost-1.amazonaws.com/mythicalmysfits/service:latest

    Sobald Sie die Werte in task-definition.json ersetzt und gespeichert haben. Führen Sie den folgenden Befehl aus, um eine neue Aufgabendefinition im ECS zu registrieren:

    aws ecs register-task-definition --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json
  • A: Einen Network Load Balancer erstellen

    Nachdem eine neue Aufgabendefinition registriert wurde, sind wir bereit, die erforderliche Infrastruktur in unserem Service-Stack bereitzustellen. Anstatt unseren Dienst direkt dem Internet auszusetzen, werden wir einen Network Load Balancer (NLB) zur Verfügung stellen, der vor unserer Dienstebene sitzt. Dies würde es unserem Frontend-Website-Code ermöglichen, mit einem einzigen DNS-Namen zu kommunizieren, während unser Backend-Service die Möglichkeit hätte, je nach Bedarf oder bei Ausfällen und der Bereitstellung neuer Container elastisch ein- und auszuskalieren.

    Um einen neuen NLB bereitzustellen, führen Sie den folgenden CLI-Befehl im Cloud9-Terminal aus (rufen Sie die SubnetIds aus der von Ihnen gespeicherten CloudFormation-Ausgabe ab):

    aws elbv2 create-load-balancer --name mysfits-nlb --scheme internet-facing --type network --subnets REPLACE_ME_PUBLIC_SUBNET_ONE REPLACE_ME_PUBLIC_SUBNET_TWO > ~/environment/nlb-output.json

    Wenn dieser Befehl erfolgreich abgeschlossen ist, wird in Ihrer IDE eine neue Datei namens nlb-output.json erstellt. In späteren Schritten werden Sie DNSName, VpcId und LoadBalancerArn verwenden.

    B: Erstellen einer Load Balancer-Zielgruppe

    Als Nächstes verwenden Sie die CLI, um eine NLB-Zielgruppe zu erstellen. Eine Zielgruppe ermöglicht es AWS-Ressourcen, sich selbst als Ziel für Anfragen zu registrieren, die der Load Balancer erhält, um sie weiterzuleiten. Unsere Service-Container werden sich automatisch bei diesem Ziel registrieren, so dass sie bei der Bereitstellung Verkehr vom NLB empfangen können. Dieser Befehl enthält einen Wert, der ersetzt werden muss, nämlich Ihre vpc-id, die als Wert in der zuvor gespeicherten MythicalMysfitsCoreStack-Ausgabe zu finden ist, die von CloudFormation zurückgegeben wurde.

    aws elbv2 create-target-group --name MythicalMysfits-TargetGroup --port 8080 --protocol TCP --target-type ip --vpc-id REPLACE_ME_VPC_ID --health-check-interval-seconds 10 --health-check-path / --health-check-protocol HTTP --healthy-threshold-count 3 --unhealthy-threshold-count 3 > ~/environment/target-group-output.json

    Wenn dieser Befehl abgeschlossen ist, wird seine Ausgabe unter target-group-output.json in Ihrer IDE gespeichert. Den Wert TargetGroupArn werden Sie in einem späteren Schritt referenzieren.

    C: Erstellen eines Load Balancer-Listeners

    Als Nächstes verwenden Sie die CLI, um einen Load Balancer-Listener für den NLB zu erstellen. Damit wird der Load Balancer darüber informiert, dass Anfragen, die auf einem bestimmten Port eingehen, an Ziele weitergeleitet werden sollen, die sich für die oben genannte Zielgruppe registriert haben. Achten Sie darauf, die beiden angegebenen Werte durch den entsprechenden ARN aus der Zielgruppe und dem NLB zu ersetzen, den Sie aus den vorherigen Schritten gespeichert haben:

    aws elbv2 create-listener --default-actions TargetGroupArn=REPLACE_ME_NLB_TARGET_GROUP_ARN,Type=forward --load-balancer-arn REPLACE_ME_NLB_ARN --port 80 --protocol TCP
  • A: Erstellen einer serviceverbundenen Rolle für ECS

    Wenn Sie ECS bereits in der Vergangenheit verwendet haben, können Sie diesen Schritt überspringen und zum nächsten Schritt übergehen. Wenn Sie ECS noch nie zuvor verwendet haben, müssen wir eine **serviceverbundene Rolle** im IAM erstellen, die dem ECS-Service selbst die Erlaubnis erteilt, ECS-API-Anfragen innerhalb Ihres Kontos zu stellen. Dies ist erforderlich, da beim Erstellen eines Dienstes in ECS der Dienst APIs innerhalb Ihres Kontos aufruft, um Aktionen wie das Ziehen von Docker-Images, das Erstellen neuer Aufgaben usw. durchzuführen.

    Ohne die Schaffung dieser Rolle würde der ECS-Dienst keine Berechtigungen zur Durchführung der erforderlichen Aktionen erhalten. Um die Rolle zu erstellen, führen Sie den folgenden Befehl im Terminal aus:  

    aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com

    Wenn das obige Ergebnis einen Fehler über die bereits vorhandene Rolle zurückgibt, können Sie diesen ignorieren, da dies darauf hinweisen würde, dass die Rolle in der Vergangenheit automatisch in Ihrem Konto erstellt wurde.

    B: Den Dienst erstellen

    Nachdem der NLB erstellt und konfiguriert ist und der ECS-Dienst die entsprechenden Berechtigungen erteilt hat, sind wir bereit, den eigentlichen ECS **Dienst** zu erstellen, in dem unsere Container laufen und sich beim Load Balancer registrieren, um Verkehr zu empfangen. Wir haben eine JSON-Datei für die CLI-Eingabe eingebunden, die sich unter `~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json` befindet. Diese Datei enthält alle Konfigurationsdetails für den zu erstellenden Dienst, einschließlich der Angabe, dass dieser Dienst mit **AWS Fargate** gestartet werden soll. Das bedeutet, dass Sie keine Server innerhalb des Ziel-Clusters bereitstellen müssen. Die Container, die als Teil der in diesem Dienst verwendeten Aufgabe geplant sind, werden auf einem Cluster ausgeführt, der vollständig von AWS verwaltet wird.

    Öffnen Sie ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json in der IDE und ersetzen Sie die angegebenen Werte von REPLACE_ME. Speichern Sie ihn und führen Sie dann den folgenden Befehl aus, um den Dienst zu erstellen:

    aws ecs create-service --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json
    C: Den Dienst testen

    Kopieren Sie den DNS-Namen, den Sie bei der Erstellung des NLB gespeichert haben, und senden Sie über den Vorschaubrowser in Cloud9 (oder einfach über einen beliebigen Webbrowser, da unser Service diesmal im Internet verfügbar ist) eine Anfrage an den NLB. Versuchen Sie, eine Anfrage an die mysfits Ressource zu senden:

    http://mysfits-nlb-123456789-abc123456.elb.us-east-1.amazonaws.com/mysfits

    Eine Antwort, die dieselbe JSON-Antwort zeigt, die wir zuvor beim lokalen Testen des Docker-Containers in der Cloud9 erhalten haben, bedeutet, dass Ihre Flask-API auf AWS Fargate eingerichtet ist und läuft.

    Hinweis: Dieser Network Load Balancer unterstützt nur HTTP (http://) Anfragen, da keine SSL/TLS-Zertifikate darauf installiert sind. Stellen Sie sicher, dass Sie für dieses Tutorial Anfragen nur über http:// einreichen, https:// Anfragen werden nicht richtig funktionieren.

  • A: Ersetzen des API-Endpunkts

    Als Nächstes müssen wir unsere Website in Ihr neues API-Backend integrieren, anstatt die hartkodierten Daten zu verwenden, die wir zuvor auf S3 hochgeladen haben. Sie müssen die folgende Datei aktualisieren, um die gleiche NLB-URL für API-Aufrufe zu verwenden (geben Sie nicht den /mysfits-Pfad an): /module-2/web/index.html

    Öffnen Sie die Datei in Cloud9 und ersetzen Sie den markierten Bereich unten zwischen den Anführungszeichen durch die NLB-URL:

    before-replace

    Nach dem Einfügen sollte die Linie ähnlich wie unten aussehen:

    after-replace
    B: Hochladen nach S3

    Um diese Datei auf Ihre von S3 gehostete Website hochzuladen, verwenden Sie wieder den Bucket-Namen, der während Modul 1 erstellt wurde, und führen Sie den folgenden Befehl aus:

    aws s3 cp ~/environment/aws-modern-application-workshop/module-2/web/index.html s3://INSERT-YOUR-BUCKET-NAME/index.html

    Öffnen Sie Ihre Website mit der gleichen URL, die am Ende von Modul 1 verwendet wird, um Ihre neue Mythical Mysfits Website zu sehen, die JSON-Daten von Ihrer Flask-API abruft, die in einem Docker-Container läuft, der bei AWS Fargate bereitgestellt wird!

Modul 2C: Automatisierung von Bereitstellungen mit Hilfe von AWS-Code-Diensten

Jetzt, wo Sie einen Dienst eingerichtet haben, denken Sie vielleicht an Code-Änderungen, die Sie an Ihrem Flask-Dienst vornehmen möchten. Es wäre ein Engpass für Ihre Entwicklungsgeschwindigkeit, wenn Sie jedes Mal, wenn Sie eine neue Funktion in Ihren Dienst stellen wollen, dieselben Schritte wie oben beschrieben durchführen müssten. Hier kommen Continuous Integration und Continuous Delivery oder CI/CD ins Spiel!

In diesem Modul erstellen Sie einen vollständig verwalteten CI/CD-Stack, der alle Code-Änderungen, die Sie an Ihrer Code-Basis vornehmen, automatisch an den Dienst weiterleitet, den Sie während des letzten Moduls erstellt haben.

Architekturdiagramm

Aufbau einer dynamischen Website-Architektur – Cloud9, Code-Tools, Fargate
  • A: Einen S3-Bucket für Pipeline-Artefakte erstellen

    Wir werden einen weiteren S3-Bucket erstellen müssen, der zur Speicherung der temporären Artefakte dient, die mitten in unseren CI/CD-Pipeline-Durchführungen entstehen. Wählen Sie einen neuen Bucket-Namen für diese Artefakte und erstellen Sie einen mit dem folgenden CLI-Befehl:

    aws s3 mb s3://REPLACE_ME_CHOOSE_ARTIFACTS_BUCKET_NAME

    Als Nächstes benötigt dieser Bucket eine Bucket-Richtlinie, um Berechtigungen für die darin gespeicherten Daten zu definieren. Aber im Gegensatz zu unserem Website-Bucket, der jedermann zugänglich war, sollte nur unsere CI/CD-Pipeline Zugang zu diesem Bucket haben. Wir haben die für diese Ricktlinie erforderliche JSON-Datei unter ~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json.

    Öffnen Sie diese Datei, und darin müssen Sie mehrere Zeichenfolgen ersetzen, um die ARNs einzuschließen, die zuvor als Teil des MythicalMysfitsCoreStack erstellt wurden, sowie den neu gewählten Bucket-Namen für Ihre CI/CD-Artefakte.

    Sobald Sie diese Datei geändert und gespeichert haben, führen Sie den folgenden Befehl aus, um Ihrer CI/CD-Pipeline Zugriff auf diesen Bucket zu gewähren:

    aws s3api put-bucket-policy --bucket REPLACE_ME_ARTIFACTS_BUCKET_NAME --policy file://~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json
    B: Erstellen eines CodeCommit-Repository

    Sie benötigen einen Ort, an den Sie Ihren Code verschieben und speichern können. Erstellen Sie zu diesem Zweck ein ** AWS CodeCommit-Repository** unter Verwendung der CLI:

    aws codecommit create-repository --repository-name MythicalMysfitsService-Repository
    C: Erstellen eines CodeBuild-Projekts

    Mit einem Repository, in dem unser Code gespeichert wird, und einem S3-Behälter, der für unsere CI/CD-Artefakte verwendet wird, können wir den CI/CD-Stack mit einer Möglichkeit für einen Service-Build erweitern. Dies wird durch die Erstellung eines AWS CodeBuild-Projektes erreicht. Jedes Mal, wenn eine Build-Ausführung ausgelöst wird, stellt AWS CodeBuild automatisch einen Build-Server für unsere Konfiguration bereit und führt die Schritte aus, die erforderlich sind, um unser Docker-Image zu erstellen und eine neue Version davon in das von uns erstellte ECR-Repository zu schieben (und dann den Server herunterzufahren, wenn der Build abgeschlossen ist).

    Die Schritte für unseren Build (die unseren Python-Code paketieren und den Docker-Container bauen/verschieben) sind in der Datei ~/environment/aws-modern-application-workshop/module-2/app/buildspec.yml enthalten. Die Datei buildspec.yml ist das, was Sie erstellen, um CodeBuild anzuweisen, welche Schritte für eine Build-Ausführung innerhalb eines CodeBuild-Projekts erforderlich sind.

    Um das CodeBuild-Projekt zu erstellen, ist eine weitere CLI-Eingabedatei erforderlich, die mit den für Ihre Ressourcen spezifischen Parametern aktualisiert werden muss. Sie finden sie unter ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json. Ersetzen Sie in ähnlicher Weise die Werte innerhalb dieser Datei, wie Sie es zuvor bei der MythicalMysfitsCoreStackOutput getan haben. Führen Sie nach dem Speichern die folgenden Schritte mit der CLI aus, um das Projekt zu erstellen:

    aws codebuild create-project --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json
    D: Erstellen einer CodePipeline-Pipeline

    Schließlich brauchen wir eine Möglichkeit, unser CodeCommit-Repository kontinuierlich mit unserem CodeBuild-Projekt zu integrieren, so dass automatisch Builds erstellt werden, sobald eine Codeänderung in das Repository übertragen wird. Dann brauchen wir eine Möglichkeit, diese neu gebauten Artefakte kontinuierlich an unseren Dienst im ECS zu liefern. AWS CodePipeline ist der Dienst, der diese Aktionen in einer Pipeline zusammenfügt, die Sie als Nächstes erstellen werden.

    Ihre Pipeline in CodePipeline wird genau das tun, was ich oben beschrieben habe. Jedes Mal, wenn eine Codeänderung in Ihr CodeCommit-Repository verschoben wird, liefert CodePipeline den neuesten Code an Ihr AWS CodeBuild-Projekt, so dass ein Build entsteht. Bei erfolgreicher Erstellung durch CodeBuild führt CodePipeline eine Bereitstellung an ECS durch und verwendet dabei das letzte Container-Image, das die CodeBuild-Ausführung in ECR geschoben hat.

    Alle diese Schritte werden in einer JSON-Datei definiert, vorausgesetzt, dass Sie sie als Eingabe in die AWS-CLI verwenden, um die Pipeline zu erstellen. Diese Datei befindet sich unter ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json. Öffnen Sie sie und ersetzen Sie die erforderlichen Attribute darin, und speichern Sie die Datei.

    Erstellen Sie nach dem Speichern eine Pipeline in CodePipeline mit dem folgenden Befehl:

    aws codepipeline create-pipeline --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json
    E: Automatisierten Zugang zum ECR-Imagespeicher ermöglichen

    Wir haben noch einen letzten Schritt vor uns, bevor unsere CI/CD-Pipeline erfolgreich end-to-end ausgeführt werden kann. Wenn Sie eine CI/CD-Pipeline eingerichtet haben, müssen Sie Container-Images nicht mehr manuell in den ECR schieben. CodeBuild wird jetzt neue Images vorantreiben.

    Wir müssen CodeBuild die Erlaubnis erteilen, mit einer ECR-Repository-Richtlinie* Aktionen auf Ihrem Imagearchiv durchzuführen. Das Richtliniendokument muss mit der spezifischen ARN für die CodeBuild-Rolle aktualisiert werden, die durch den MythicalMysfitsCoreStack geschaffen wurde, und das Richtliniendokument befindet sich unter ~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json.

    Aktualisieren und speichern Sie diese Datei und führen Sie dann den folgenden Befehl aus, um die Richtlinie zu erstellen:

    aws ecr set-repository-policy --repository-name mythicalmysfits/service --policy-text file://~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json

    Wenn diese erfolgreich erstellt wurde, verfügen Sie über eine funktionierende End-to-End-CI/CD-Pipeline, um Code-Änderungen automatisch an Ihren Service im ECS zu liefern.

  • A: Verwendung von Git mit AWS CodeCommit

    Um die neue Pipeline zu testen, müssen wir git innerhalb Ihrer Cloud9-IDE konfigurieren und in Ihr CodeCommit-Repository integrieren.

    AWS CodeCommit bietet eine Anmeldedaten-Hilfe für Git, die wir verwenden werden, um die Integration zu erleichtern.

    Führen Sie die folgenden Befehle der Reihe nach auf dem Terminal aus, um git für die Verwendung mit AWS CodeCommit zu konfigurieren (keiner der beiden meldet im Erfolgsfall eine Antwort):

    git config --global user.name "REPLACE_ME_WITH_YOUR_NAME"
    git config --global user.email REPLACE_ME_WITH_YOUR_EMAIL@example.com
    git config --global credential.helper '!aws codecommit credential-helper $@'
    git config --global credential.UseHttpPath true

    Als Nächstes wechseln Sie Verzeichnisse in Ihrer IDE zum Terminal in das Umgebungsverzeichnis:

    cd ~/environment/

    Nun sind wir bereit, unser Repository mit dem folgenden Terminal-Befehl zu klonen:

    git clone https://git-codecommit.REPLACE_REGION.amazonaws.com/v1/repos/MythicalMysfitsService-Repository

    Dies wird uns sagen, dass unser Repository leer ist! Lassen Sie uns das beheben, indem wir die Anwendungsdateien mit dem folgenden Befehl in unser Repository-Verzeichnis kopieren:

    cp -r ~/environment/aws-modern-application-workshop/module-2/app/* ~/environment/MythicalMysfitsService-Repository/
    B: Verschieben einer Code-Änderung

    Jetzt ist der fertige Service-Code, den wir zur Erstellung unseres Fargate-Dienstes in Modul 2 verwendet haben, im lokalen Repository gespeichert, das wir gerade von AWS CodeCommit geklont haben. Lassen Sie uns eine Änderung am Flask-Service vornehmen, bevor wir unsere Änderungen committen, um zu zeigen, dass die von uns erstellte CI/CD-Pipeline funktioniert. Öffnen Sie in Cloud9 die Datei, die unter ~/environment/MythicalMysfitsService-Repository/service/mysfits-response.json gespeichert ist, und ändern Sie das Alter eines der Mysfits auf einen anderen Wert und speichern Sie die Datei.

    Nachdem Sie die Datei gespeichert haben, wechseln Sie die Verzeichnisse in das neue Repository-Verzeichnis:

    cd ~/environment/MythicalMysfitsService-Repository/

    Führen Sie dann die folgenden Git-Befehle aus, um Ihre Code-Änderungen zu verschieben.

    git add .
    git commit -m "I changed the age of one of the mysfits."
    git push

    Nachdem die Änderung in das Repository verschoben wurde, können Sie den CodePipeline-Service in der AWS-Konsole öffnen, um Ihre Änderungen im Verlauf der CI/CD-Pipeline anzuzeigen. Nachdem Sie Ihre Code-Änderung committet haben, dauert es etwa 5 bis 10 Minuten, bis die Änderungen in Ihrem Live-Service, der in Fargate läuft, implementiert sind.

    Während dieser Zeit orchestriert AWS CodePipeline das Auslösen einer Pipeline-Ausführung, wenn die Änderungen in Ihr CodeCommit-Repository eingecheckt wurden, veranlasst Ihr CodeBuild-Projekt, ein neues Build zu initiieren, und ruft das Docker-Image ab, das von CodeBuild an ECR übergeben wurde, und führt eine automatisierte ECS Update Service-Aktion aus, um die vorhandenen Container, die in Ihrem Dienst ausgeführt werden, zu entleeren und durch das neu erstellte Image zu ersetzen. Aktualisieren Sie Ihre Mythical Mysfits Website im Browser, um zu sehen, dass die Änderungen in Kraft getreten sind.

    Sie können den Fortschritt Ihrer Code-Änderung über die CodePipeline-Konsole hier einsehen (keine Maßnahmen erforderlich, beobachten Sie einfach die Automatisierung in Aktion!) AWS CodePipeline

    Damit ist Modul 2 abgeschlossen.

Als Nächstes: Mysfit-Daten speichern