Zum Inhalt

Phase 2 - Analyzing the infrastructure of the monolithic application

Coffeshop

  1. Stellen Sie sicher, dass die monolithische Webanwendung über das Internet zugänglich ist.

  2. Navigieren Sie zur Amazon EC2-Konsole.

  3. Kopieren Sie die öffentliche IPv4-Adresse der MonolithicAppServer-Instanz und laden Sie sie in einen neuen Browser-Tab.

Achtung: http:// nicht https://

alt text

alt text

Suppliers

  1. Wählen Sie Lieferantenliste. Beachten Sie, dass der URL-Pfad /suppliers enthält.

  2. Fügen Sie einen neuen Lieferanten hinzu. Beachten Sie auf der Seite, auf der Sie einen neuen Lieferanten hinzufügen, dass der URL-Pfad /supplier-add enthält. Füllen Sie alle Felder aus, um einen Lieferanteneintrag zu erstellen.

  3. Bearbeiten Sie einen Eintrag. Beachten Sie, dass auf der Seite, auf der Sie einen Lieferanteneintrag bearbeiten, der URL-Pfad nun „supplier-update/1“ enthält. Ändern Sie den Datensatz auf irgendeine Weise und speichern Sie die Änderung. Beachten Sie, dass die Änderung im Datensatz gespeichert wurde.

alt text

alt text

Monolithic
  1. Verwenden Sie EC2 Instance Connect, um eine Verbindung zur MonolithicAppServer-Instanz herzustellen. alt text

  2. Analysieren Sie, wie die Anwendung ausgeführt wird

    • Führen Sie in der Terminalsitzung den folgenden Befehl aus:

        sudo lsof -i :80

    • Führen Sie als Nächstes den folgenden Befehl aus: 
    ps -ef | head -1; ps -ef | grep node

    alt text

  3. Führen Sie die folgenden Befehle aus, um die Anwendungsstruktur zu analysieren:

cd ~/resources/codebase_partner
ls
  1. Verbinden Sie einen MySQL-Client mit der RDS-Datenbank, in der die Knotenanwendung Daten speichert.

  • Suchen und kopieren Sie den Endpunkt der RDS-Datenbank, die in der Laborumgebung ausgeführt wird 
dbEndpoint=$(sudo cat ~/resources/codebase_partner/app/config/config.js | grep 'APP_DB_HOST' | cut -d '"' -f2)


 echo $dbEndpoint

nmap -Pn $dbEndpoint

alt text

Phase 3: Erstellen einer Entwicklungsumgebung und Einchecken des Codes in ein Git-Repository

Überblick

In Phase 3 wird eine Entwicklungsumgebung mit AWS Cloud9 erstellt. Anschließend wird der Anwendungscode in ein Git-kompatibles Repository (AWS CodeCommit) eingecheckt.

Aufgabe 3.1: Erstellen einer AWS Cloud9 IDE

  1. Erstelle eine neue Cloud9-Instanz mit dem Namen MicroservicesIDE.
  2. Wähle eine EC2-Instanz vom Typ t3.small mit Amazon Linux 2.
  3. Die Instanz sollte SSH-Verbindungen unterstützen und im LabVPC in Public Subnet1 laufen.

Aufgabe 3.2: Anwendungscode in die IDE kopieren

  1. Lade die labsuser.pem-Datei von der AWS-Details-Seite auf deinen lokalen Rechner herunter.

  2. Lade die .pem-Datei in die Cloud9-IDE hoch und setze die richtigen Berechtigungen:

    chmod 400 ~/environment/labsuser.pem

  3. Erstelle ein Verzeichnis temp in der Cloud9-Instanz:

    mkdir ~/environment/temp

  4. Finde die private IPv4-Adresse der MonolithicAppServer-Instanz in der EC2-Konsole heraus.

  5. Kopiere den Anwendungscode vom MonolithicAppServer in das temp-Verzeichnis der Cloud9-Instanz:

    scp -r -i ~/environment/labsuser.pem ubuntu@$appServerPrivIp:/home/ubuntu/resources/codebase_partner/* ~/environment/temp/

  6. Überprüfe im Dateibrowser der Cloud9-IDE, dass die Dateien im temp-Verzeichnis verfügbar sind.

Aufgabe 3.3: Erstellen von Arbeitsverzeichnissen für Microservices

  1. Erstelle im Verzeichnis microservices zwei neue Verzeichnisse namens customer und employee.
  2. Kopiere den Quellcode des monolithischen Projekts in jedes Verzeichnis und lösche anschließend das temp-Verzeichnis.
  3. Überprüfe die Verzeichnisstruktur in der Cloud9-IDE, um sicherzustellen, dass die Dateien korrekt organisiert sind.

Aufgabe 3.4: Git-Repository erstellen und Code in CodeCommit pushen

  1. Erstelle ein neues Repository in CodeCommit mit dem Namen microservices.

  2. Initialisiere das Git-Repository in deinem Cloud9-Verzeichnis microservices und pushe den Code:

    cd ~/environment/microservices
git init
git branch -m dev
git add .
git commit -m 'two unmodified copies of the application code'
git remote add origin https://git-codecommit.us-east-1.amazonaws.com/v1/repos/microservices
git push -u origin dev

    Erklärung: Hier wurde das Verzeichnis microservices als Git-Repository initialisiert. Es wurde ein dev-Branch erstellt, alle Dateien hinzugefügt und committet. Anschließend wurde das CodeCommit-Repository als Remote-Repository (origin) hinzugefügt und die Änderungen im dev-Branch gepusht.

  3. Konfiguriere deinen Git-Client mit Benutzername und E-Mail-Adresse:

    git config --global user.name "Dein Benutzername"
git config --global user.email "Deine Emailadresse"

  4. Öffne die CodeCommit-Konsole und überprüfe, ob der Code im microservices-Repository vorhanden ist.

Phase 4: Konfiguration der Anwendung als zwei Microservices und Testen in Docker-Containern

In dieser Phase werden die beiden Kopien des monolithischen Anwendungs-Startercodes so angepasst, dass die Anwendung in zwei separate Microservices unterteilt wird. Dann wird, zum Testen, die Anwendung in Docker-Containern auf der gleichen EC2-Instanz ausgeführt, die den AWS Cloud9 IDE hostet. Du wirst diese IDE verwenden, um die Docker-Images zu erstellen und die Docker-Container zu starten.

Task 4.1: Anpassen der Sicherheitsgruppeneinstellungen der AWS Cloud9-Instanz

In dieser Phase des Projekts verwendest du die AWS Cloud9-Instanz als Testumgebung. Du wirst Docker-Container auf der Instanz ausführen, um die Microservices zu testen, die du erstellen wirst. Damit du über das Internet auf die Container zugreifen kannst, musst du die Ports öffnen, auf denen die Container ausgeführt werden.

  • Ändere die Sicherheitsgruppe der AWS Cloud9 EC2-Instanz, um eingehenden Netzwerkverkehr auf den TCP-Ports 8080 und 8081 zuzulassen.

Task 4.2: Ändern des Quellcodes des Kunden-Microservices

In dieser Aufgabe wirst du den Quellcode des Kunden-Microservices bearbeiten. Der Ausgangscode ist eine exakte Kopie der monolithischen Anwendung. Daher enthält der Code noch Funktionen, die vom Mitarbeiter-Microservice übernommen werden und die du nicht im Kunden-Microservice haben möchtest. Insbesondere sollen Kunden keine Lieferanten hinzufügen, bearbeiten oder löschen können, daher entfernst du diese Funktionen.

  • Bearbeite die Datei customer/app/controller/supplier.controller.js so, dass nur noch die folgenden Funktionen übrig bleiben:
const Supplier = require("../models/supplier.model.js");
const {body, validationResult} = require("express-validator");

exports.findAll = (req, res) => {
    Supplier.getAll((err, data) => {
        if (err)
            res.render("500", {message: "Es gab ein Problem bei der Abrufung der Liste der Lieferanten"});
        else res.render("supplier-list-all", {suppliers: data});
    });
};

exports.findOne = (req, res) => {
    Supplier.findById(req.params.id, (err, data) => {
        if (err) {
            if (err.kind === "not_found") {
                res.status(404).send({
                    message: `Lieferant mit der ID ${req.params.id} nicht gefunden.`
                });
            } else {
                res.render("500", {message: `Fehler beim Abrufen des Lieferanten mit der ID ${req.params.id}`});
            }
        } else res.render("supplier-update", {supplier: data});
    });
};

Task 4.3: Erstellen des Dockerfiles für den Kunden-Microservice und Starten eines Testcontainers

  • Erstelle ein Dockerfile im Verzeichnis customer mit folgendem Inhalt:

    FROM node:11-alpine
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY . .
RUN npm install
EXPOSE 8080
CMD ["npm", "run", "start"]

  • Baue das Docker-Image für den Kunden-Microservice:

    docker build --tag customer .

  • Überprüfe, ob das Docker-Image erstellt wurde, indem du folgenden Befehl ausführst:

    docker images

  • Starte einen Docker-Container, der den Kunden-Microservice auf Port 8080 ausführt:

    dbEndpoint=$(cat ~/environment/microservices/customer/app/config/config.js | grep 'APP_DB_HOST' | cut -d '"' -f2)
echo $dbEndpoint
docker run -d --name customer_1 -p 8080:8080 -e APP_DB_HOST="$dbEndpoint" customer

  • Überprüfe, ob der Kunden-Microservice wie erwartet läuft, indem du die folgende URL im Browser aufrufst:

    http://<cloud-9-public-IPv4-address>:8080

  • Bestätige, dass die Lieferanteneinträge korrekt angezeigt werden und dass die Schaltflächen "Add a new supplier" sowie "edit" entfernt wurden.

  • Kommiere die Änderungen in das CodeCommit-Repository.

Task 4.4: Ändern des Quellcodes des Mitarbeiter-Microservices

  • Bearbeite den Quellcode des Mitarbeiter-Microservices, um sicherzustellen, dass Mitarbeiter Lieferanten hinzufügen, bearbeiten und löschen können, während Kunden nur Leserechte haben.

  • Ändere in der Datei employee/app/controller/supplier.controller.js die Redirects, um /admin hinzuzufügen.

  • Ändere in employee/index.js die Pfade für app.get und app.post zu /admin.

  • Ändere in den Dateien employee/views/supplier-add.html und employee/views/supplier-update.html den Aktionspfad zu /admin.

  • Ändere in employee/views/nav.html die Links wie folgt:

  • Zeile 3: Ändere "Monolithic Coffee suppliers" zu "Manage coffee suppliers".

  • Zeile 7: Ändere den Link zu:

    <a class="nav-link" href="/admin/suppliers">Administrator home</a>

  • Füge nach Zeile 8 diesen Link hinzu:

    <a class="nav-link" href="/">Customer home</a>

Task 4.5: Erstellen des Dockerfiles für den Mitarbeiter-Microservice und Starten eines Testcontainers

  • Erstelle das Dockerfile für den Mitarbeiter-Microservice, indem du das Dockerfile des Kunden-Microservices duplizierst und die Portnummer in EXPOSE auf 8081 änderst.

  • Baue das Docker-Image für den Mitarbeiter-Microservice:

    docker build --tag employee .

  • Starte einen Docker-Container mit dem Mitarbeiter-Microservice:

    docker run -d --name employee_1 -p 8081:8081 -e APP_DB_HOST="$dbEndpoint" employee

  • Überprüfe, ob der Mitarbeiter-Microservice wie erwartet läuft, indem du die URL aufrufst:

    http://<cloud-9-public-IPv4-address>:8081/admin/suppliers

  • Teste das Hinzufügen, Bearbeiten und Löschen von Lieferanten.

Task 4.6: Ändern der Portnummer für den Mitarbeiter-Microservice und Neuaufbau des Docker-Images

  • **Bearbeite die Dateien employee/index.js und employee/Dockerfile,** um den Port von8081auf8080` zu ändern.

  • Baue das Docker-Image für den Mitarbeiter-Microservice erneut:

    docker build --tag employee .

Task 4.7: Änderungen in CodeCommit einchecken

  • Überprüfe die Änderungen im Quellcode und kommitte diese in CodeCommit:

    git commit -m "Updated employee and customer microservices"
git push

Phase 5: Erstellen von ECR-Repositories, einem ECS-Cluster, Task-Definitionen und AppSpec-Dateien

Zu diesem Zeitpunkt hast du bereits zahlreiche Anforderungen erfolgreich umgesetzt. Du hast die monolithische Anwendung in zwei Microservices unterteilt, die als Docker-Container laufen können. Du hast ebenfalls überprüft, dass die Container die benötigten Anwendungsaktionen wie das Hinzufügen, Bearbeiten und Löschen von Einträgen in der Datenbank unterstützen. Die Microservices-Architektur nutzt weiterhin Amazon RDS zur Speicherung der Kaffee-Lieferanteneinträge.

Deine Arbeit ist jedoch noch nicht abgeschlossen. Es gibt weitere Anforderungen, die umgesetzt werden müssen. Die Container können zwar auf der AWS Cloud9-Instanz ausgeführt werden, aber das ist keine skalierbare Bereitstellungsarchitektur. Du benötigst die Möglichkeit, die Anzahl der Container für jeden Microservice je nach Bedarf hoch- und herunterzuskalieren. Zudem benötigst du einen Load Balancer, um den Traffic an den entsprechenden Microservice weiterzuleiten. Schließlich soll der Quellcode jedes Microservices einfach unabhängig voneinander aktualisiert und in die Produktion übernommen werden können. In den verbleibenden Phasen des Projekts wirst du diese Anforderungen umsetzen.

Task 5.1: Erstellen von ECR-Repositories und Hochladen der Docker-Images

In dieser Phase lädst du die neuesten Docker-Images der beiden Microservices in separate Amazon ECR-Repositories hoch.

Schritte:

  1. Docker-Client autorisieren: 

    account_id=$(aws sts get-caller-identity |grep Account|cut -d '"' -f4)
echo $account_id
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $account_id.dkr.ecr.us-east-1.amazonaws.com
    Eine Nachricht im Ausgabebereich zeigt an, dass der Login erfolgreich war.

  2. Erstellen der ECR-Repositories:

    • Erstelle ein separates privates ECR-Repository für jeden Microservice.
    • Benenne das erste Repository als customer.
    • Benenne das zweite Repository als employee.

  3. Berechtigungen für das Repository setzen:

    • Setze die Berechtigungen für das customer ECR-Repository gemäß der folgenden JSON-Richtlinie: 
      {
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "ecr:*"
    }
  ]
}
    • Wiederhole diesen Schritt für das employee ECR-Repository.

  4. Taggen der Docker-Images:

    • Tagge die Docker-Images mit deinem eindeutigen account_id: 
      account_id=$(aws sts get-caller-identity |grep Account|cut -d '"' -f4)
docker tag customer:latest $account_id.dkr.ecr.us-east-1.amazonaws.com/customer:latest
docker tag employee:latest $account_id.dkr.ecr.us-east-1.amazonaws.com/employee:latest

  5. Docker-Images überprüfen:

    • Überprüfe, ob die Images korrekt getaggt wurden: 
      docker images

  6. Hochladen der Docker-Images in Amazon ECR:

    • Lade die Docker-Images mit den folgenden Befehlen hoch: 
      docker push $account_id.dkr.ecr.us-east-1.amazonaws.com/customer:latest
docker push $account_id.dkr.ecr.us-east-1.amazonaws.com/employee:latest

    Überprüfe, ob die Images erfolgreich hochgeladen wurden, indem du die Ausgaben der Befehle überprüfst.

Task 5.2: Erstellen eines ECS-Clusters

In dieser Aufgabe erstellst du einen Amazon ECS-Cluster.

Schritte:

  1. Erstellen eines serverlosen AWS Fargate-Clusters:

    • Erstelle einen Fargate-Cluster mit dem Namen microservices-serverlesscluster.
    • Stelle sicher, dass der Cluster so konfiguriert ist, dass er LabVPC, PublicSubnet1 und PublicSubnet2 verwendet (entferne alle anderen Subnetze). Wähle NICHT Amazon EC2-Instanzen oder ECS Anywhere.

  2. CloudFormation Stack überprüfen:

    • Nachdem der Cluster erstellt wurde, wähle „View in CloudFormation“ im Banner oben und warte, bis der Stack den Status „CREATE_COMPLETE“ erreicht, bevor du mit der nächsten Aufgabe fortfährst.

Task 5.3: Erstellen eines CodeCommit-Repositories für Bereitstellungsdateien

In dieser Aufgabe erstellst du ein weiteres CodeCommit-Repository, in dem die Task-Definitionen und AppSpec-Dateien für jede Microservice gespeichert werden.

Schritte:

  1. Erstelle ein neues CodeCommit-Repository:

    • Benenne das Repository als deployment.

  2. Erstelle ein neues Verzeichnis namens deployment:

    • Initialisiere das Verzeichnis als Git-Repository mit einem dev-Branch.

Task 5.4: Erstellen von Task-Definitionen für jeden Microservice und Registrierung bei Amazon ECS

In dieser Aufgabe erstellst du Task-Definitionen für jeden Microservice und registrierst diese bei Amazon ECS.

Schritte:

  1. Erstelle die Datei taskdef-customer.json im Verzeichnis deployment und füge die folgende JSON-Code ein: 

    {
  "containerDefinitions": [
    {
      "name": "customer",
      "image": "customer",
      "environment": [
        {
          "name": "APP_DB_HOST",
          "value": "<RDS-ENDPOINT>"
        }
      ],
      "essential": true,
      "portMappings": [
        {
          "hostPort": 8080,
          "protocol": "tcp",
          "containerPort": 8080
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-create-group": "true",
          "awslogs-group": "awslogs-capstone",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "awslogs-capstone"
        }
      }
    }
  ],
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::<ACCOUNT-ID>:role/PipelineRole",
  "family": "customer-microservice"
}

    • Ersetze <ACCOUNT-ID> und <RDS-ENDPOINT> mit den tatsächlichen Werten.

  2. Task-Definition für den Kunden-Microservice registrieren: 

    aws ecs register-task-definition --cli-input-json "file:///home/ec2-user/environment/deployment/taskdef-customer.json"

  3. Erstelle die Datei taskdef-employee.json und ersetze alle Vorkommen von customer durch employee. Registriere die Task-Definition für den Mitarbeiter-Microservice auf die gleiche Weise.

Task 5.5: Erstellen der AppSpec-Dateien für CodeDeploy

In dieser Aufgabe erstellst du AppSpec-Dateien für den CodeDeploy-Prozess jedes Microservices.

Schritte:

  1. Erstelle die Datei appspec-customer.yaml im Verzeichnis deployment: 

    version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: <TASK_DEFINITION>
        LoadBalancerInfo:
          ContainerName: "customer"
          ContainerPort: 8080

  2. Erstelle die Datei appspec-employee.yaml mit ähnlichem Inhalt, aber ersetze customer durch employee.

Task 5.6: Dateien aktualisieren und in CodeCommit einchecken

In dieser Aufgabe wirst du die Task-Definitionsdateien aktualisieren und alle vier Dateien ins CodeCommit-Repository hochladen.

Schritte:

  1. Bearbeite taskdef-customer.json und taskdef-employee.json:

    • Ändere die image-Zeilen auf: 
      "image": "<IMAGE1_NAME>"

  2. Push die Änderungen in das CodeCommit-Repository: 

    git add .
git commit -m "Updated ECS task definitions and AppSpec files"
git push

Damit hast du die Task-Definitionen und AppSpec-Dateien in CodeCommit hochgeladen, um sie später in der CI/CD-Pipeline zu verwenden.

Phase 6: Erstellen von Zielgruppen und einem Application Load Balancer

In dieser Phase wirst du einen Application Load Balancer (ALB) erstellen, der eine URL als Endpunkt bereitstellt. Diese URL dient als HTTPS-Eingangspunkt für Kunden und Mitarbeiter, um auf deine Anwendung über einen Webbrowser zuzugreifen. Der Load Balancer wird über Listener verfügen, die Routing- und Zugriffsregeln definieren, welche Zielgruppe von laufenden Containern der Benutzeranforderung zugeordnet wird.

Task 6.1: Erstellen von vier Zielgruppen

In dieser Aufgabe wirst du vier Zielgruppen erstellen – zwei für jeden Microservice. Da du eine Blue/Green-Deployment-Strategie konfigurieren wirst, benötigt CodeDeploy zwei Zielgruppen für jede Deployment-Gruppe.

Hinweis:
Blue/Green ist eine Deployment-Strategie, bei der zwei separate, aber identische Umgebungen erstellt werden. Eine Umgebung (blau) führt die aktuelle Anwendungsversion aus, und eine Umgebung (grün) führt die neue Anwendungsversion aus. Weitere Informationen findest du im Blue/Green Deployments in the Overview of Deployment Options on AWS Whitepaper.

Schritte:

  1. Erstelle die erste Zielgruppe für den Customer Microservice:

  2. Navigiere zur Amazon EC2-Konsole.

  3. Wähle im Navigationsbereich "Target Groups" aus.
  4. Wähle „Create target group“ und konfiguriere Folgendes:
    • Zieltyp: Wähle „IP addresses“.
    • Zielgruppenname: „customer-tg-one“
    • Protokoll: Wähle „HTTP“.
    • Port: 8080
    • VPC: Wähle „LabVPC“.
    • Health-Check-Pfad: Gib „/“ ein.
  5. Klicke auf „Next“.

  6. Auf der Seite „Register targets“ akzeptiere die Standardoptionen (registriere keine Ziele) und wähle „Create target group“.

  7. Erstelle die zweite Zielgruppe für den Customer Microservice:

  8. Wiederhole die gleichen Schritte wie bei der ersten Zielgruppe, aber ändere den Zielgruppennamen zu „customer-tg-two“.

  9. Erstelle eine Zielgruppe für den Employee Microservice:

  10. Verwende die gleichen Einstellungen wie bei den anderen Zielgruppen, aber ändere den Zielgruppennamen zu „employee-tg-one“ und den Health-Check-Pfad zu „/admin/suppliers“.

  11. Erstelle eine zweite Zielgruppe für den Employee Microservice:

  12. Wiederhole die gleichen Schritte wie bei der ersten Zielgruppe für den Employee Microservice, aber ändere den Zielgruppennamen zu „employee-tg-two“ und den Health-Check-Pfad zu „/admin/suppliers“.

Wichtiger Hinweis:

Überprüfe sorgfältig den Namen und die Portnummer jeder Zielgruppe. Jede Zielgruppe sollte eindeutig benannt und mit den entsprechenden Pfaden konfiguriert sein.

Task 6.2: Erstellen einer Sicherheitsgruppe, eines Application Load Balancers und Konfigurieren von Regeln zum Routen des Traffics

In dieser Aufgabe wirst du einen Application Load Balancer erstellen. Du wirst auch zwei Listener für den Load Balancer definieren: einen auf Port 80 und einen auf Port 8080. Für jeden Listener wirst du anschließend pfadbasiertes Routing konfigurieren, sodass der Traffic je nach URL zu der richtigen Zielgruppe weitergeleitet wird.

Schritte:

  1. Erstelle eine neue EC2-Sicherheitsgruppe namens „microservices-sg“
  2. Diese Sicherheitsgruppe wird im LabVPC verwendet.

  3. Füge eingehende Regeln hinzu, die TCP-Traffic von jeder IPv4-Adresse auf den Ports 80 und 8080 erlauben.

  4. Erstelle einen Application Load Balancer (ALB):

  5. Navigiere zur Amazon EC2-Konsole und wähle „Load Balancers“.
  6. Klicke auf „Create Load Balancer“ und wähle „Application Load Balancer“.
  7. Gib ihm den Namen „microservicesLB“.
  8. Stelle ihn auf "internet facing" für IPv4-Adressen ein.
  9. Wähle „LabVPC“, „Public Subnet1“, „Public Subnet2“ und die Sicherheitsgruppe „microservices-sg“.

  10. Konfiguriere zwei Listener:

    • Der erste Listener hört auf HTTP:80 und leitet den Traffic standardmäßig an die Zielgruppe „customer-tg-two“ weiter.
    • Der zweite Listener hört auf HTTP:8080 und leitet den Traffic standardmäßig an die Zielgruppe „customer-tg-one“ weiter.

  11. Füge eine zweite Regel für den HTTP:80 Listener hinzu:

  12. Definiere folgende Logik für diese neue Regel:

    • Wenn der Pfad „/admin/*“ ist, leite den Traffic an die Zielgruppe „employee-tg-two“ weiter.

  13. Füge eine zweite Regel für den HTTP:8080 Listener hinzu:

  14. Definiere folgende Logik für diese neue Regel:
    • Wenn der Pfad „/admin/*“ ist, leite den Traffic an die Zielgruppe „employee-tg-one“ weiter.

Wichtiger Hinweis:

Überprüfe, dass die Regeln und der Traffic-Routing korrekt eingerichtet sind, um sicherzustellen, dass der Traffic je nach URL zu den richtigen Zielgruppen (Customer oder Employee) weitergeleitet wird.

Dies sind die Schritte, um Zielgruppen und einen Load Balancer zu erstellen, die für den Blue/Green-Deployment-Prozess konfiguriert sind.

Phase 7: Erstellen von zwei Amazon ECS-Services

In dieser Phase wirst du für jeden Microservice einen Service in Amazon ECS erstellen. Obwohl beide Microservices auch in einem einzigen ECS-Service bereitgestellt werden könnten, wird es für dieses Projekt einfacher sein, die Microservices unabhängig zu verwalten, wenn jeder Microservice in seinem eigenen ECS-Service bereitgestellt wird.

Task 7.1: Erstellen des ECS-Services für den Customer Microservice

  1. Erstelle eine neue Datei in AWS Cloud9:

  2. Erstelle eine Datei mit dem Namen create-customer-microservice-tg-two.json im Deployment-Verzeichnis.

  3. Füge den folgenden JSON-Code in die Datei ein:

{
    "taskDefinition": "customer-microservice:REVISION-NUMBER",
    "cluster": "microservices-serverlesscluster",
    "loadBalancers": [
        {
            "targetGroupArn": "MICROSERVICE-TG-TWO-ARN",
            "containerName": "customer",
            "containerPort": 8080
        }
    ],
    "desiredCount": 1,
    "launchType": "FARGATE",
    "schedulingStrategy": "REPLICA",
    "deploymentController": {
        "type": "CODE_DEPLOY"
    },
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                "PUBLIC-SUBNET-1-ID",
                "PUBLIC-SUBNET-2-ID"
            ],
            "securityGroups": [
                "SECURITY-GROUP-ID"
            ],
            "assignPublicIp": "ENABLED"
        }
    }
}

Bearbeite die Datei create-customer-microservice-tg-two.json:

  1. Ersetze REVISION-NUMBER mit der Nummer der neuesten Revision der Task-Definition des Customer Microservices, die bei Amazon ECS registriert ist.
  2. Wenn dies das erste Mal ist, dass du diesen Schritt machst, sollte die Revisionsnummer 1 sein.

  3. Falls du diesen Schritt wiederholst, finde die neueste Revisionsnummer in der Amazon ECS-Konsole, indem du „Task Definitions“ auswählst und dann „customer-microservice“ wählst.

  4. Ersetze MICROSERVICE-TG-TWO-ARN mit dem tatsächlichen ARN der Zielgruppe customer-tg-two.

  5. Ersetze PUBLIC-SUBNET-1-ID mit der tatsächlichen Subnet-ID von Public Subnet1.

  6. Ersetze PUBLIC-SUBNET-2-ID mit der tatsächlichen Subnet-ID von Public Subnet2.

  7. Ersetze SECURITY-GROUP-ID mit der tatsächlichen Sicherheitsgruppen-ID von microservices-sg.

  8. Speichere die Änderungen.

Erstelle den ECS-Service für den Customer Microservice:

Führe die folgenden Befehle aus:

cd ~/environment/deployment
aws ecs create-service --service-name customer-microservice --cli-input-json file://create-customer-microservice-tg-two.json

Fehlerbehebung:

Wenn du diesen Schritt wiederholst und der ECS-Service bereits erstellt wurde, erhältst du möglicherweise einen Fehler, dass die Service-Erstellung nicht idempotent ist. Um diesen Fehler zu beheben:

  1. Lösche den Service gezwungenermaßen aus der Amazon ECS-Konsole.
  2. Warte, bis der Service vollständig entladen ist.
  3. Führe dann die Befehle erneut aus.

Task 7.2: Erstellen des ECS-Services für den Employee Microservice

  1. Erstelle einen ECS-Service für den Employee Microservice:

  2. Kopiere die JSON-Datei, die du für den Customer Microservice erstellt hast, und benenne sie in create-employee-microservice-tg-two.json um. Speichere sie im gleichen Verzeichnis.

  3. Ändere die Datei create-employee-microservice-tg-two.json:

  4. Auf Zeile 2 ändere „customer-microservice“ zu „employee-microservice“ und aktualisiere auch die Revisionsnummer.
  5. Auf Zeile 6 gib den ARN der Zielgruppe employee-tg-two ein.
    • Tipp: Ändere nicht nur „customer“ zu „employee“ auf dieser Zeile. Der ARN ist in anderen Bereichen ebenfalls einzigartig.

  6. Auf Zeile 7 ändere „customer“ zu „employee“.

  7. Speichere die Änderungen.

Erstelle den ECS-Service für den Employee Microservice:

Führe den entsprechenden AWS CLI-Befehl aus, um den Service in Amazon ECS zu erstellen.

Hinweis:

  • Wenn du zur Amazon ECS-Konsole gehst und die Services im Cluster ansiehst, könnte dort „0/1 Task running“ angezeigt werden. Dies ist zu erwarten, da du die Task-Sets für diese Services noch nicht gestartet hast.

Phase 8: Konfigurieren von CodeDeploy und CodePipeline

Nachdem du den Application Load Balancer, die Zielgruppen und die Amazon ECS-Dienste definiert hast, die die Infrastruktur für die Bereitstellung deiner Microservices ausmachen, ist der nächste Schritt, die CI/CD-Pipeline zu definieren, um die Anwendung bereitzustellen.

Das folgende Diagramm veranschaulicht die Rolle der Pipeline in der Lösung, die du aufbaust.

Diagrammbeschreibung:
Die Pipeline wird durch Updates in CodeCommit ausgelöst, wo du die ECS-Task-Definitionsdateien und die CodeDeploy-AppSpec-Dateien gespeichert hast. Die Pipeline kann auch durch Updates einer der Docker-Image-Dateien ausgelöst werden, die du in Amazon ECR gespeichert hast. Bei der Ausführung ruft die Pipeline den CodeDeploy-Dienst auf, um die Updates bereitzustellen. CodeDeploy führt die notwendigen Schritte aus, um die Updates auf die grüne Umgebung zu deployen. Sobald keine Fehler auftreten, wird der neue Task-Set den alten Task-Set ersetzen.

Task 8.1: Erstellen einer CodeDeploy-Anwendung und Deployment-Gruppen

Eine CodeDeploy-Anwendung ist eine Sammlung von Deployment-Gruppen und Revisionen. Eine Deployment-Gruppe gibt den Amazon ECS-Dienst, den Load Balancer, optional einen Test-Listener und zwei Zielgruppen an. Sie spezifiziert, wann der Verkehr zum neuen Task-Set umgeleitet wird und wann das ursprüngliche Task-Set und die Amazon ECS-Anwendung nach einem erfolgreichen Deployment beendet werden.

  1. CodeDeploy-Anwendung erstellen:
  2. Gehe zur CodeDeploy-Konsole und erstelle eine CodeDeploy-Anwendung mit dem Namen microservices, die Amazon ECS als Compute-Plattform verwendet.

Wichtig: Erstelle noch keine Deployment-Gruppe. Dies wird im nächsten Schritt erledigt.

  1. Erstelle eine CodeDeploy Deployment-Gruppe für den Customer Microservice:
  2. Auf der Detailseite der Anwendung „microservices“, wähle den Tab „Deployment groups“.
  3. Wähle „Create deployment group“ und konfiguriere die folgenden Einstellungen:
    • Deployment group name: microservices-customer
    • Service role: Wähle die ARN für DeployRole.
    • ECS cluster name: Wähle microservices-serverlesscluster.
    • ECS service name: Wähle customer-microservice.
    • Load balancer: Wähle microservicesLB.
    • Production listener port: Wähle HTTP:80.
    • Test listener port: Wähle HTTP:8080.
    • Target group 1 name: Wähle customer-tg-two.
    • Target group 2 name: Wähle customer-tg-one.
    • Traffic rerouting: Wähle „Reroute traffic immediately“.
    • Deployment configuration: Wähle CodeDeployDefault.ECSAllAtOnce.
    • Original revision termination: Setze auf „Days: 0, Hours: 0, Minutes: 5“.

  4. Klicke auf „Create deployment group“.

  5. Erstelle eine CodeDeploy Deployment-Gruppe für den Employee Microservice:

  6. Wiederhole die gleichen Schritte wie für den Customer Microservice, aber mit folgenden Änderungen:
    • Deployment group name: microservices-employee
    • ECS service name: Wähle employee-microservice.
    • Target group 1 name: Wähle employee-tg-two.
    • Target group 2 name: Wähle employee-tg-one.

Task 8.2: Erstellen einer Pipeline für den Customer Microservice

In dieser Aufgabe erstellst du eine Pipeline, um den Customer Microservice zu aktualisieren. Beim Erstellen der Pipeline konfigurierst du CodeCommit als Quelle und CodeDeploy als Dienst für die Bereitstellung. Danach wirst du die Pipeline bearbeiten, um Amazon ECR als zweite Quelle hinzuzufügen.

Mit einem Amazon ECS Blue/Green Deployment, das du in dieser Aufgabe definierst, bereitest du einen neuen Satz von Containern vor, auf denen CodeDeploy die neueste Version deiner Anwendung installiert. Anschließend leitet CodeDeploy den Traffic des Load Balancers von den bestehenden Containern (die die vorherige Version ausführen) auf den neuen Satz um, der die neueste Version ausführt. Nach der Umleitung kann der alte Satz an Containern beendet werden.

  1. Pipeline für den Customer Microservice erstellen:
  2. Gehe zur CodePipeline-Konsole und erstelle eine Pipeline mit den folgenden Einstellungen:
    • Pipeline name: update-customer-microservice
    • Service role: Wähle die ARN für PipelineRole.
    • Source provider: Wähle AWS CodeCommit.
    • Repository name: Wähle deployment.
    • Branch name: Wähle dev.
    • Deploy provider: Wähle Amazon ECS (Blue/Green).
    • AWS CodeDeploy application name: microservices.
    • AWS CodeDeploy deployment group: microservices-customer.
    • Amazon ECS task definition:
    • Setze ein SourceArtifact mit dem Wert taskdef-customer.json.
    • AWS CodeDeploy AppSpec file:
    • Setze ein SourceArtifact mit dem Wert appspec-customer.yaml.
    • Dynamically update task definition image: Lass dieses Feld vorerst leer.

  3. Nach dem Erstellen der Pipeline wird sie sofort ausgeführt und fehlschlagen. Ignoriere das und fahre fort.

  4. Pipeline bearbeiten, um eine zweite Quelle hinzuzufügen:

  5. Gehe zum „Edit: Source“ Abschnitt und wähle „Edit stage“.

  6. Füge eine Aktion hinzu:

    • Action name: Image
    • Action provider: Amazon ECR
    • Repository name: customer
    • Image tag: latest
    • Output artifacts: image-customer.

  7. Deploy-Aktion der Pipeline bearbeiten:

  8. Bearbeite die Deploy-Aktion der Pipeline und füge ein Eingabeartifact hinzu:
    • Unter der „Deploy Amazon ECS (Blue/Green)“-Karte, klicke auf das Bearbeitungs-Symbol.
    • Unter Input artifacts, wähle „Add“ und dann image-customer.
    • Unter „Dynamically update task definition image“, wähle „image-customer“ für den Input Artifact mit den Bilddetails.
    • Gib als Platzhaltertext in der Task-Definition IMAGE1_NAME ein.

Task 8.3: Testen der CI/CD-Pipeline für den Customer Microservice

In dieser Aufgabe testest du, ob die CI/CD-Pipeline für den Customer Microservice wie beabsichtigt funktioniert.

  1. Launch einer Bereitstellung des Customer Microservice auf Amazon ECS:
  2. Navigiere zur CodePipeline-Konsole.
  3. Wähle die Pipeline update-customer-microservice aus.
  4. Klicke auf „Release change“, um die aktuelle Pipeline-Konfiguration zu testen.

  5. Warte, bis beide Source-Aufgaben den Status „Succeeded“ anzeigen.

  6. CodeDeploy-Details überprüfen:

  7. Klicke auf den „Details“-Link im Deploy-Bereich.
  8. Eine CodeDeploy-Seite öffnet sich, wo du den Fortschritt der Bereitstellung verfolgen kannst.

  9. Überprüfe, ob alle Deployment-Lifecycle-Events erfolgreich abgeschlossen wurden.

  10. Microservice im Browser testen:

  11. Füge den DNS-Namen des microservicesLB Load Balancers in einen neuen Tab ein und lade die Seite.
  12. Wenn die Seite nicht auf Port 80 geladen wird, versuche es auf Port 8080.

Task 8.4: Erstellen einer Pipeline für den Employee Microservice

Erstelle eine Pipeline für den Employee Microservice mit den folgenden Spezifikationen:

  1. Pipeline erstellen:
  2. Pipeline name: update-employee-microservice
  3. Role ARN: PipelineRole
  4. Source provider: AWS CodeCommit
  5. Repository name: deployment
  6. Branch name: dev
  7. Deploy provider: Amazon ECS (Blue/Green)
  8. AWS CodeDeploy application name: microservices
  9. AWS CodeDeploy deployment group: microservices-employee
  10. Amazon ECS task definition: SourceArtifact (Pfad: taskdef-employee.json)

  11. AWS CodeDeploy AppSpec file: SourceArtifact (Pfad: appspec-employee.yaml)

  12. Zweite Quelle hinzufügen: Füge eine Aktion für Amazon ECR hinzu:

  13. Action name: Image
  14. Action provider: Amazon ECR
  15. Repository name: employee
  16. Image tag: latest

  17. Output artifacts: image-employee.

  18. Deploy-Aktion bearbeiten:

  19. Füge ein weiteres Eingabeartifact hinzu und wähle image-employee.
  20. Unter „Dynamically update task definition image“, wähle image-employee.

Task 8.5: Testen der CI/CD-Pipeline für den Employee Microservice

Teste die Pipeline für den Employee Microservice, indem du eine Bereitstellung auf Amazon ECS durchführst. Verwende die Funktion „Release change“, um die Pipeline zu testen.

  1. Fortschritt in CodeDeploy überwachen: Warte, bis alle Deployment-Lifecycle-Events erfolgreich

Phase 9: Anpassen des Microservice-Codes, um eine Pipeline erneut auszuführen

In dieser Phase wirst du die Vorteile der Microservices-Architektur und der CI/CD-Pipeline, die du aufgebaut hast, erleben. Du beginnst damit, die Listener-Regeln des Load Balancers zu ändern, die mit dem Employee-Microservice verbunden sind. Danach wirst du den Quellcode des Employee-Microservices anpassen, ein neues Docker-Image erstellen und dieses Image in Amazon ECR hochladen. Dies wird die Pipeline auslösen und das Produktionsdeployment aktualisieren. Du wirst auch die Anzahl der Container skalieren, die den Customer-Microservice unterstützen.

Task 9.1: Zugang zum Employee-Microservice einschränken

In dieser Aufgabe wirst du den Zugang zum Employee-Microservice nur auf bestimmte IP-Adressen beschränken. Dadurch können nur Benutzer, die von dieser IP-Adresse aus auf die Anwendung zugreifen, die Seiten anzeigen sowie Lieferanten-Einträge bearbeiten oder löschen.

Schritte:

  1. Überprüfen, dass alle Zielgruppen noch mit dem Application Load Balancer verbunden sind:

  2. Gehe in die Amazon EC2-Konsole und überprüfe, ob alle vier Zielgruppen noch mit dem Load Balancer verbunden sind. Wenn nötig, assoziiere die Zielgruppen neu.

  3. Finde deine öffentliche IPv4-Adresse:

  4. Du kannst eine Webseite wie What is my IP verwenden, um deine öffentliche IP-Adresse zu finden.

  5. Regeln für den HTTP:80 Listener bearbeiten:

  6. Für die Regel, die aktuell mit "IF Path is /admin/*" versehen ist, füge eine zweite Bedingung hinzu, die den Benutzer nur dann zu den Zielgruppen weiterleitet, wenn die Quell-IP der Anfrage deiner IP-Adresse entspricht.

  7. Beispiel: Setze als Quelle deine öffentliche IPv4-Adresse und füge /32 hinzu, z.B. 203.0.113.0/32.

  8. Regeln für den HTTP:8080 Listener bearbeiten:

  9. Bearbeite die Regeln genauso wie beim HTTP:80 Listener, um den Zugang zu den Employee-Zielgruppen nur für deine IP-Adresse zu beschränken.

Task 9.2: UI für den Employee-Microservice anpassen und aktualisiertes Image in Amazon ECR pushen

In dieser Aufgabe wirst du den Employee-Microservice anpassen.

Schritte:

  1. Bearbeite die employee/views/nav.html Datei:

  2. Ändere in Zeile 1 navbar-dark bg-dark zu navbar-light bg-light.

  3. Generiere ein neues Docker-Image und tagge es:

bash docker rm -f employee_1 cd ~/environment/microservices/employee docker build --tag employee . dbEndpoint=$(cat ~/environment/microservices/employee/app/config/config.js | grep 'APP_DB_HOST' | cut -d '"' -f2) echo $dbEndpoint account_id=$(aws sts get-caller-identity | grep Account | cut -d '"' -f4) echo $account_id docker tag employee:latest $account_id.dkr.ecr.us-east-1.amazonaws.com/employee:latest

Push das aktualisierte Docker-Image in Amazon ECR:

Melde dich an und pushe das neue Image:

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $account_id.dkr.ecr.us-east-1.amazonaws.com
docker push $account_id.dkr.ecr.us-east-1.amazonaws.com/employee:latest

Überprüfe, ob die Ausgabe ähnlich wie folgt aussieht, um sicherzustellen, dass das Image erfolgreich gepusht wurde:

b20e9725db21: Pushed 
715b0f96c609: Pushed 
44141cf9260f: Layer already exists

Task 9.3: Bestätigen, dass die Employee-Pipeline ausgeführt wurde und der Microservice aktualisiert wurde

  • Gehe in die CodePipeline-Konsole und überprüfe die Details der update-employee-microservice Pipeline. Du solltest sehen, dass die Pipeline ausgelöst wurde, nachdem das Docker-Image in Amazon ECR hochgeladen wurde.

  • Gehe in die CodeDeploy-Konsole, um den Status der Bereitstellung zu überprüfen.

Task 9.4: Zugang zum Employee-Microservice testen

Schritte:

  1. Teste den Zugang zum Employee-Microservice über die URLs:

  2. Gehe zu http://<alb-endpoint>/admin/suppliers und http://<alb-endpoint>:8080/admin/suppliers von dem Gerät aus, das du für dieses Projekt benutzt hast. Ersetze <alb-endpoint> mit dem DNS-Namen des microservicesLB Load Balancers.

  3. Überprüfe die Änderungen in der Benutzeroberfläche:

  4. Der Banner mit dem Seitentitel sollte jetzt eine helle Farbe haben, da du die nav.html geändert hast. Seiten, die vom Customer-Microservice gehostet werden, sollten weiterhin den dunklen Banner haben.

  5. Teste den Zugang von einem anderen Gerät:

  6. Wenn du das gleiche Gerät nicht verwenden kannst, versuche es mit einem anderen Netzwerk (z. B. deinem Handy über das mobile Netz). Du solltest eine 404-Fehlerseite erhalten, die bestätigt, dass der Zugang von anderen IP-Adressen nicht funktioniert.

  7. Fehlerbehebung:

  8. Falls das Update nicht wie erwartet funktioniert, kannst du die Bereitstellung in der CodeDeploy-Konsole abbrechen und auf die vorherige Version zurücksetzen.

Task 9.5: Skalierung des Customer-Microservices

In dieser Aufgabe wirst du die Anzahl der Container, die den Customer-Microservice unterstützen, erhöhen, ohne dass die update-customer-microservice-Pipeline ausgeführt wird.

Schritte:

  1. Skaliere den Customer-Service in Amazon ECS:

```bash aws ecs update-service --cluster microservices-serverlesscluster --service customer-microservice --desired-count 3

Überprüfe die Skalierung in der Amazon ECS-Konsole:

  • Du solltest sehen, dass der customer-microservice nun 3 Container hat, die laufen, anstatt nur einem. Dies zeigt, wie du Microservices unabhängig voneinander skalieren kannst.

  • Beachte, dass der employee-microservice eventuell 2/1 Aufgaben zeigt, da eine neue Task-Satz bereitgestellt wurde, aber der alte Task-Satz während der ersten 5 Minuten noch aktiv ist.