Skip to content
malak.cloud
  • Kontakt
  • O mnie
  • Search Icon

malak.cloud

Cloud Native na co dzień

EventBridge i API Destinations

EventBridge i API Destinations

14 marca 2021

Kilka dni temu AWS umożliwił dodanie do naszego EventBridge subskrybentów, do których zdarzenia będą wysyłane przez zwykły endpoint REST. EventBridge i API Destinations pozwolą na uproszczenie wielu rozwiązań. Tam gdzie do tej pory korzystaliśmy z funkcji Lambda, teraz wystarczy tylko EventBridge i odpowiedni target.
Sprawdziłem jak to działa i pokażę w jaki sposób można wysłać na jakikolwiek endpoint (oczywiście także poza AWS) zdarzenia zarówno z naszych aplikacji jak i samego AWS.

Zdarzenia

Na potrzeby naszego rozwiązania przygotujemy dwie Event rules.

Jedna z nich będzie wywoływana w momencie gdy ktoś np. utworzy bucket w usłudze S3 lub zmieni politykę dla wiaderka.
Tak zwany event pattern będzie wyglądał następująco:

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "source": ["aws.s3"],
  "detail": {
    "eventSource": ["s3.amazonaws.com"],
    "eventName": ["CreateBucket", "PutBucketAcl", "PutBucketPolicy"]
  }
}

 

Druga to już reguła, która będzie obsługiwała nasze zdarzenia, czyli:

{
  "detail-type": ["appliczation-data"],
  "source": ["cloud.malak.app"]
}

 

Endpoint

Wszystkie zdarzenia z tych dwóch reguł będą wysyłane do funkcji Lambda, która będzie wystawiona za pomocą API Gateway.

Sama funkcja zapisze nam po prostu do logów to co wyśle do nas EventBridge.

import json

def lambda_handler(event, context):
    print(json.dumps(event))
    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "OK"
        }),
    }

 

SAM Template

Całość rozwiązania macie dostępne jako template SAM na moim GitHubie. Wystarczy praktycznie wywołać sam deploy i po chwili powinniście mieć gotowy stack CloudFormation z wszystkimi zasobami.

Jednym z nich będzie API Destination w postaci naszego API Gateway, gdzie będą wysyłane zdarzenia z EventBridge.

Sprawdzamy

Na początek przetestujmy naszego stróża S3.

Stwórzmy nowy bucket S3

i sprawdźmy co też znajdziemy z logach funkcji Lambda, która pracuje jako odbiorca danych.

Jak widać wszystko zadziałało i na nasz endpoint EventBeidge wysłał powiadomienie o utworzeniu nowego bucketu. A może bucketa. Nie wnikam… 😉

No to teraz sami wyślijmy coś do naszego event busa i przetestujmy drugą regułę.

Sam event wygląda tak

[
  {
    "Source": "cloud.malak.app",
    "DetailType": "appliczation-data",
    "Detail" : "{\"app\": \"app1\",\"data\": \"Tu jakieś dane z aplikacji\"}"
  }
]

 

i po jego wysłaniu


w logach funkcji widzimy to zdarzenie

Podsumowanie

AWS wprowadza krok po kroku kolejne usługi i rozwiązania, które zdejmują z nas kolejne obowiązki i zmniejszają naszą odpowiedzialność.

Kolejny klocek, za pomocą którego możemy budować nasze rozwiązania CloudNative. Ale nie tylko.

Same API Destinations nie są za darmo

ale za funkcje Lambda, które do tej pory wykonują takie requesty także płacimy. A czas pracy programistów też kosztuje.

Przypominam, że wszystkie źródła macie dostępne tutaj. Zapraszam do przetestowania. Wiecej na temat APi Destinations tutaj.


AWS, CloudNative, DEV
AWS, CloudNative, serverless

Post navigation

PREVIOUS
AWS News – luty 2021
NEXT
AWS News – marzec 2021
Comments are closed.
Cześć. Nazywam się Przemek Malak. Dzięki za wizytę. Mam nadzieję, że to o czym piszę Cię zainteresowało. Jeżeli chcesz ze mną pogadać, najłatwiej będzie przez LinkedIn.

Losowe wpisy

  • Programujemy AWS – Step Functions. Jak prosto połączyć usługi serverless w jedną całość.

    11 marca 2018
  • AWS Lambda i idempotentność

    21 marca 2022
  • Jak przesłać plik do S3 za pomocą API Gateway

    16 listopada 2022
  • AWS Copilot CLI i AWS App Runner

    22 listopada 2021
  • Jak za pomocą funkcji Lambda włączyć i wyłączyć serwer EC2 w AWS

    25 października 2017
  • Apps
  • AWS
  • CloudNative
  • Cookbook
  • Data
  • DEV
  • GCP
  • IoT
  • Istio
  • k8s
  • Security
  • Social
  • GitHub
  • LinkedIn
© 2023   All Rights Reserved.