Einführung
Die Auftragsabwicklung benötigt neu aufgegebene Bestellungen, während Abrechnungs- und Stornierungsereignisse an andere Stellen gehören. Du leitest passende Ereignisse an eine Warteschlange weiter und prüfst, welche Nachrichten tatsächlich ankommen.
Schließe zuerst Aufträge mit SQS senden und verarbeiten und Einen Bucket mit einer Ressourcenrichtlinie schützen ab. Diese unabhängige VM stellt eigenen CLI-Zugriff und Referenzdaten bereit; frühere Warteschlangen und Zugangsdaten werden nicht wiederverwendet.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Cloud Practitioner (CLF-C02) · Aufgabe 3.8: EventBridge-Ereignisabgleich, Ziele und Zustellautorisierung.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: EventBridge-Ereignisabgleich, Ziele und Zustellautorisierung.
- Developer – Associate (DVA-C02) · Aufgabe 1.1: EventBridge-Ereignisabgleich, Ziele und Zustellautorisierung.
- CloudOps Engineer – Associate (SOA-C03) · Aufgabe 1.2: EventBridge-Ereignisabgleich, Ziele und Zustellautorisierung.
- DevOps Engineer – Professional (DOP-C02) · Aufgabe 4.3: Grundlagenübung: EventBridge-Ereignisabgleich, Ziele und Zustellautorisierung.
- Data Engineer – Associate (DEA-C01) · Aufgabe 3.1: Grundlagenübung: EventBridge-Ereignisabgleich, Ziele und Zustellautorisierung.
Einen Bus und eine Zielwarteschlange vorbereiten
Erstelle in diesem Schritt die unabhängigen Orte, an denen Ereignisse eintreffen und passende Arbeit auf einen Verbraucher wartet.
Verwende AWS View neben Terminal, um die CLI-Abfragen mit den tatsächlichen Ressourcen und Ergebnissen dieses Labs zu vergleichen. Erhalte die bereitgestellten Referenzdaten.
Amazon EventBridge leitet Ereignisse weiter, die beschreiben, was geschehen ist. Ein Bus empfängt Ereignisse, eine Regel gleicht Felder ab, und ein Ziel empfängt passende Ereignisse. Ein eigener Bus trennt die Ereignisse dieser Anwendung vom Standardbus. Eine SQS-Warteschlange hält Zustellungen vor, bis ein Verbraucher sie verarbeitet. Beginne im Projektverzeichnis. Shellzuweisungen speichern Kennungen, die von der CLI zurückgegeben werden; --query wählt das benötigte Feld aus, und --output text macht es für den nächsten Befehl verwendbar.
cd /home/labex/project
BUS_NAME=labex-ev01-bus
RULE_NAME=labex-ev01-orders
aws events create-event-bus --name "$BUS_NAME"
QUEUE_URL=$(aws sqs create-queue \
--queue-name labex-ev01-jobs \
--query QueueUrl \
--output text)
QUEUE_ARN=$(aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names QueueArn \
--query Attributes.QueueArn \
--output text)
Die Busantwort enthält seine ARN, und QUEUE_URL bezeichnet die Warteschlange für Nachrichtenoperationen. Die Warteschlangen-ARN bezeichnet sie in einem Ziel oder einer Berechtigungsrichtlinie. Diese Kennungen dienen unterschiedlichen Zwecken.
Untersuche beide leeren Ressourcen:
aws events list-rules --event-bus-name "$BUS_NAME"
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Es gibt noch keine Regeln, und die Warteschlange enthält keine verfügbaren oder in Bearbeitung befindlichen Nachrichten. AWS View zeigt deinen eigenen Bus und die leere Warteschlange. Führe die Vorbereitungsprüfung aus.
Bestellungen abgleichen und eine Regel autorisieren
Verbinde in diesem Schritt eine passende Regel mit der Warteschlange und autorisiere nur die Zustellungen dieser Regel.
Eine passende Regel wählt das Ereignis aus; die Berechtigung für die Quellregel in der Warteschlange erlaubt separat dessen Zustellung.
Ein Ereignismuster ist ein Filter über Ereignisfelder. source nennt den Produzenten, während detail-type die Ereigniskategorie nennt. Jedes Array unten listet akzeptierte Werte auf. Ein Here-Dokument schreibt das wörtliche JSON zwischen den Markierungen JSON; die Anführungszeichen um die Markierung verhindern Shellersetzung. file:// weist die CLI an, diese Datei zu lesen.
cat > order-pattern.json <<'JSON'
{"source":["labex.orders"],"detail-type":["OrderPlaced"]}
JSON
RULE_ARN=$(aws events put-rule \
--name "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--event-pattern file://order-pattern.json \
--state ENABLED \
--query RuleArn \
--output text)
Die Regel ist aktiviert, aber eine Übereinstimmung allein autorisiert keine Zustellung. Die Ressourcenrichtlinie der Warteschlange muss dem EventBridge-Dienst das Senden erlauben, begrenzt durch aws:SourceArn auf diese Regel. Schreibe eine gewöhnliche JSON-Richtlinie; die Shell setzt deine Warteschlangen- und Regel-ARNs ein.
cat > queue-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "$QUEUE_ARN",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "$RULE_ARN"
}
}
}
]
}
EOF
jq -n --rawfile policy queue-policy.json '{Policy:$policy}' > queue-attributes.json
aws sqs set-queue-attributes \
--queue-url "$QUEUE_URL" \
--attributes file://queue-attributes.json
Die Attribut-API speichert die Richtlinie als JSON-Zeichenfolge, daher liest --rawfile dieses Dokument in das Attribut Policy ein. Die Berechtigung umfasst eine Warteschlange und eine Ursprungsregel.
Ein Ziel ist der Empfänger der Regel. Seine ID ermöglicht dir, diese Verbindung später zu aktualisieren oder zu entfernen:
cat > targets.json <<EOF
[
{
"Id": "order-queue",
"Arn": "$QUEUE_ARN"
}
]
EOF
aws events put-targets \
--rule "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--targets file://targets.json
aws events describe-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"
aws events list-targets-by-rule --rule "$RULE_NAME" --event-bus-name "$BUS_NAME"
FailedEntryCount ist für die Zielkonfiguration null, die beschriebene Regel hat das vorgesehene Muster, und die Ziel-ARN entspricht deiner Warteschlange. AWS View zeigt jetzt die Regel und ihr Warteschlangenziel. Es gibt weiterhin kein Ereignis zur Zustellung. Führe die Verbindungsprüfung aus.
Abgleich- und Zustellgrenzen nachweisen
Veröffentliche in diesem Schritt passende und unbeteiligte Ereignisse und teste dann einen Fehler der Quellberechtigung, ohne eine neue Warteschlangennachricht hinzuzufügen.
Ein EventBridge-Ereignis hat Routingfelder und eine detail-Nutzlast. Die API PutEvents akzeptiert Detail als JSON-codierte Zeichenfolge. Schreibe drei lesbare Einträge: eine aufgegebene Bestellung, ein Abrechnungsereignis und eine Stornierung. jq wandelt jedes Detail-Objekt in die von der API benötigte Zeichenfolge um.
cat > event-inputs.json <<EOF
[
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderPlaced",
"Detail": {
"id": "route-order",
"quantity": 2
}
},
{
"EventBusName": "$BUS_NAME",
"Source": "labex.billing",
"DetailType": "OrderPlaced",
"Detail": {
"id": "billing-event",
"quantity": 9
}
},
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderCancelled",
"Detail": {
"id": "cancelled-event",
"quantity": 1
}
}
]
EOF
jq 'map(.Detail |= tojson)' event-inputs.json > events.json
aws events put-events --entries file://events.json
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Die Veröffentlichungsantwort meldet null fehlgeschlagene Einträge und eine Ereignis-ID für jeden angenommenen Eintrag. Nur route-order passt auf beide Felder, daher enthält die Warteschlange eine verfügbare Nachricht. AWS View zeigt ihren vollständigen Ereignisumschlag: Quelle, Detailtyp, Konto, Region und Detail.
Lies den tatsächlichen, für den Verbraucher sichtbaren Inhalt. Der Empfang verbirgt eine Nachricht normalerweise für ihre Sichtbarkeitsfrist; --visibility-timeout 0 macht sie nach dieser Untersuchung sofort wieder sichtbar. Die Abfrage gibt nur ihre ID und ihren Inhalt aus und hält die Empfangskennung aus der Anzeige heraus. Diese Untersuchung schließt keine Geschäftsverarbeitung ab und bestätigt die Nachricht nicht.
fromjson macht jeden JSON-Inhalt lesbar und behält dabei seine SQS-Nachrichten-ID bei. Es ändert nur die angezeigte Ausgabe.
aws sqs receive-message \
--queue-url "$QUEUE_URL" \
--max-number-of-messages 10 \
--visibility-timeout 0 \
--output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'
Der Inhalt hat detail.id gleich route-order und detail.quantity gleich 2. Die Abrechnungs- und Stornierungseinträge haben diese Warteschlange nicht erreicht.
Das Beispiel unten zeigt die aktivierte passende Regel, ihr Warteschlangenziel und das tatsächliche vollständige Bestellereignis einschließlich Konto und Region.
Richte jetzt die Warteschlangenrichtlinie auf eine andere Quell-ARN, während Regel und Ziel aktiviert bleiben:
jq --arg wrong "${RULE_ARN}-other" '.Statement[0].Condition.ArnEquals["aws:SourceArn"]=$wrong' queue-policy.json > wrong-source-policy.json
jq -n --rawfile policy wrong-source-policy.json '{Policy:$policy}' > wrong-source-attributes.json
aws sqs set-queue-attributes \
--queue-url "$QUEUE_URL" \
--attributes file://wrong-source-attributes.json
cat > event-inputs.json <<EOF
[
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderPlaced",
"Detail": {
"id": "denied-order",
"quantity": 4
}
}
]
EOF
jq 'map(.Detail |= tojson)' event-inputs.json > denied-event.json
aws events put-events --entries file://denied-event.json
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
EventBridge nimmt dieses Ereignis an, aber der Regel fehlt die erforderliche Warteschlangenberechtigung. Die ursprüngliche Nachricht bleibt das einzige Ereignis in der Warteschlange; denied-order fehlt. Unterscheide bei der Diagnose einer Pipeline die Ereignisannahme von der Zielzustellung. Diese Übung untersucht keine Zustellwiederholungen.
Stelle die vorgesehene Berechtigung wieder her und untersuche erneut:
aws sqs set-queue-attributes \
--queue-url "$QUEUE_URL" \
--attributes file://queue-attributes.json
aws sqs receive-message \
--queue-url "$QUEUE_URL" \
--max-number-of-messages 10 \
--visibility-timeout 0 \
--output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'
Nur das ursprüngliche route-order ist vorhanden. Die korrigierte Richtlinie autorisiert nachfolgende Zustellungen; dieses Lab hängt nicht davon ab, dass ein früher verweigertes Ereignis erneut versucht wird. Führe die Routingprüfung aus.
Die Ereignispipeline entfernen
Entferne in diesem Schritt dein Ziel, deine Regel, deinen eigenen Bus und die temporäre Warteschlange und erhalte dabei unbeteiligte Ressourcen.
Entferne das Ziel, bevor du seine Regel löschst. Lösche dann den eigenen Bus und die Warteschlange. Das Löschen der Warteschlange verwirft das fiktive Ereignis, das zur Routinguntersuchung aufbewahrt wurde; für dieses wurde kein Geschäftsergebnis behauptet.
aws events remove-targets \
--rule "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--ids order-queue
aws events delete-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"
aws events delete-event-bus --name "$BUS_NAME"
aws sqs delete-queue --queue-url "$QUEUE_URL"
Erfolgreiche reine Leseabfragen belegen, was erhalten bleibt:
aws events list-event-buses
aws events list-rules --event-bus-name default
aws sqs list-queues
aws dynamodb scan --table-name labex-ev01-reference --query Items
Nur der Standardbus bleibt erhalten, seine Regelliste ist leer, Warteschlangen-URLs fehlen, und das Referenzelement enthält keep unchanged. Authentifizierungs- oder Netzwerkfehler belegen keine Löschung. AWS View zeigt die leeren Listen eigener Ressourcen und die erhaltene Referenz.
Entferne die gewöhnlichen Dateien, die du erstellt hast:
rm -f event-inputs.json order-pattern.json queue-policy.json queue-attributes.json targets.json events.json wrong-source-policy.json wrong-source-attributes.json denied-event.json
Führe die Bereinigungsprüfung aus, bevor du die VM beendest.
Zusammenfassung
Du hast einen eigenen EventBridge-Bus erstellt, Ereignisse zur Bestellaufgabe abgeglichen und ein Warteschlangenziel mit einer genauen Berechtigung für die Quellregel verbunden. Tatsächliche Warteschlangeninhalte zeigten, welche Ereignisse den Verbraucher erreichten, und der Test mit verweigerter Quelle trennte Ereignisannahme von Zustellung. Du hast eigene Ressourcen entfernt und dabei Standardbus und Referenzdaten erhalten.
Die nächste Einheit formt einen Ereignisumschlag in die kleinere Nutzlast um, die ein Warteschlangenverbraucher benötigt.
