Jak korzystać z AWS CloudFront i API Gateway obok tej samej domeny?

9

Umieszczam te statyczne zasoby mojej witryny na S3 i konfiguruję CloudFront do ich dystrybucji. Zawierają one w zasadzie treść, której użytkownicy potrzebowaliby do każdego żądania GET w mojej witrynie, do istniejących ścieżek, czyli z błędem.

Mam też kilka żądań POST, które muszę obsłużyć. Przesyłanie formularzy, wysyłanie e-maili, powiadomień, interakcja z bazą danych.

Jak mogę skonfigurować Lambda (lub API Gateway) obok CloudFront dla tej samej domeny, aby CloudFront obsługiwał żądania GET, a API API obsługuje żądania z treścią lub żądaniami POST. Czy mogę to zrobić w jakiś sposób według indywidualnego adresu URL?

Costa
źródło

Odpowiedzi:

2

Prowadzę wiele aplikacji internetowych dokładnie według twojego projektu i wyodrębniłem gofaas , edukacyjną aplikację Go i Lambda, aby udostępnić techniki.

Potrzebujesz dwóch oddzielnych domen, np. www.gofaas.netDla S3 + CloudFront i api.gofaas.netdla API Gateway + Lambda.

Następnie możesz pozwolić swojej witrynie statycznej na interakcję z interfejsem API za pomocą konfiguracji interfejsu API CORS bramy API i niektórych skryptów JavaScript:

fetch(`https://api.gofaas.net/work`, {
    method: "POST",
    mode: "cors",
    headers: {
        "Accept": "application/json",
        ...
    },
    body: JSON.stringify(...)
})
    .then(function(response) {
        return response.json();
    })
    .then(function (json) {
        // use response
    })
    .catch(function (err) {
        console.log("fetch error", err);
    });

Oto kilka wskazówek, jak to wszystko skonfigurować:

Statyczne strony internetowe z S3, CloudFront i ACM

Zabezpieczenia API z Lambda, API Gateway, CORS i JWT

Noah Zoschke
źródło
Testowanie strony zawsze staje się tutaj interesujące. Trudno jest replikować lokalnie infrastrukturę AWS, aby można było przeprowadzać testy integracji lokalnie. Używam trasy zamiast subdomeny. To pomaga w części testowania. Eliminuje również wyzwania CORS. Następnie brama API staje się źródłem dla CloudFront dla tej trasy.
Costa
6

Możesz utworzyć funkcję lambda, skonfigurować bramę API, a następnie skonfigurować CloudFront, aby przekazywał określone ścieżki (np. / Rest / *) do bramy API i obsługiwał wszystko inne z segmentu S3.

Oto pełna instrukcja pokazująca, jak to zrobić: https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/

Grodriguez
źródło
2

Z punktu widzenia połączenia „coś” musi odpowiadać na twoje żądania (GET, POST, PUT, wszystko). Przede wszystkim masz połączenie TCP i „coś” musi upewnić się, że rozumie warstwę 7 i ma sens w bajtach wysyłanych przez klienta. Tylko w tym momencie można obsługiwać żądania GET inaczej niż żądania POST lub jeden adres URL niż inny adres URL. W końcu potrzebujesz usługi, która jest w stanie zrozumieć i przekierować HTTP. Są w stanie to zrobić: CloudFront ELB / ALB API Gateway (ograniczenie pojawia się później)

API Gateway korzysta z CloudFront wewnętrznie (bez możliwości faktycznej konfiguracji czegokolwiek na poziomie CloudFront) - oznacza to, że nie ma sposobu, aby uruchomić CloudFront i API Gateway obok siebie, ponieważ w końcu oznaczałoby to uruchomienie CloudFront z CloudFront ramię w ramię.

CloudFront daje Ci możliwość wyboru różnych źródeł na podstawie wzorców - ale możesz tylko wybrać S3 lub ELB / ALB jako źródło - nie funkcje Lambda (oprócz funkcji Lambda @ Edge).

ALB / ELB może wykorzystywać tylko instancje EC2 jako backend - nie ma tutaj Lambda ani S3.

Jedyne sposoby, które mogę wymyślić, które mogłyby zrobić to, co chcesz zrobić, to:

  • Korzystasz z API Gateway i kierujesz konkretną ścieżkę „zasobu” do funkcji Lambda, która robi rodzaj odwrotnego proxy dla S3 (więc przesyłając statyczne zasoby przez lambda) - pamiętaj o kosztach dla Lambda tutaj!
  • Możesz zrobić to samo, ale zamiast przesyłać strumieniowo zasób przez Lambda, po prostu wygeneruj podpisany adres URL w Lambda i przekieruj bezpośrednio do S3 w celu wyświetlenia (może to być bardziej opłacalne)
  • Używanie różnych subdomen dla zasobów niż reszty aplikacji - jest to bardzo powszechny wzorzec, ponieważ można łatwo podzielić na poziomie DNS i używać różnych usług dla różnych przypadków użycia (CloudFront dla zasobów i API Gateway dla niestatycznych Części)

Moje połączenie byłoby ostatnią opcją - ale oznacza to, że musisz skierować klientów / przeglądarki do osobnej subdomeny dla wszystkich zasobów statycznych (lub wszystkich żądań POST).

Wygląda na to, że chcesz przyjrzeć się technologiom takim jak AngularJS lub React, aby zbudować w przeglądarce aplikację opartą na interfejsie API. Dzięki takiemu podejściu uruchamiasz prawdziwy interfejs API, który obsługuje wszystkie „dynamiczne” żądania za pomocą interfejsu API Gateway i dostarcza samą aplikację z S3 jako zasób statyczny. Może spojrzenie na te może pomóc ci znaleźć drogę - nawet jeśli ich nie używasz, to wzór architektoniczny, w jaki sposób budować takie rzeczy, jest tym, o co prosisz imho.

Osterjour
źródło
2

Mam taką samą konfigurację. Zasoby statyczne w S3, funkcje Lambda obsługiwane przez bramę API i mają tę samą nazwę domeny.

Korzystam z bramy API, która już korzysta z CloudFront i udostępnia niektóre z jego funkcji, takich jak buforowanie. Następnie konfiguruję identyfikatory URI, które są mapowane na zasoby statyczne. W API Gateway zasób może być funkcją Lambda, funkcją AWS, próbą lub innym adresem URL. Mam je wskazać na moje adresy URL S3.

Identyfikatory URI można również ustawić, aby wyświetlały podścieżki, np /assets/*.

Prathan Thananart
źródło
Więc częścią, która sprawia mi problemy, jest wdrożenie interfejsu API. W twoim przypadku zwykle wdraża się bez ścieżki wiodącej /assets/*. Muszę usunąć wdrożenie i kliknąć prawym przyciskiem myszy /assets/*ścieżkę i wdrożyć stamtąd.
Costa
1
Powinienem zagłębić się w narzędzia wiersza poleceń i uczyć się, jak tworzyć i edytować api i lambda.
Costa