Robię API HTTP w AWS. Większość moich logiki jest obsługiwana w funkcjach Lambda. Używam terraform do opisania i wdrażania mojej infrastruktury. Do tej pory idzie dobrze.

Mam pojedynczy projekt, który ma lambdas dla operacji crud

GET /journal
POST /journal
GET /journal/{id}
PUT /journal/{id}
DELETE /journal/{id}

Kodeks i infrastruktura są obecnie wewnątrz Monorpo.

Teraz czas na dodanie punktów końcowych dla zagnieżdżonych zasobów

Na przykład...

/journals/{id}/sentence/{id} 

I

/journals/{id}/sentence/{id}/correction

Naprawdę chcę, aby kodeks i terrafforma na te zasoby są w osobnym projekcie, ponieważ będzie bardzo, bardzo duży.

Naprawdę walczę, aby dowiedzieć się, jak zrobić zasoby dla bramki API, która istnieje w wielu oddzielnie wdrożonych projektach.

Chcę uniknąć eksportowania Arns do zasobów API-Gateway i używając ich w innych projektach, ponieważ nie sądzę, aby stworzyć zależności między oddzielnymi wdrażaniem.

Naprawdę doceniłbym słuchanie jakichkolwiek rangi na temat tego, jak można to zarządzać, ponieważ jestem pewien, że wielu ludzi stanęło w obliczu tego problemu.

Czy można korzystać z Route53 do trasy wszystkich połączeń API w dziedzinie do wielu oddzielnych bram API? Jeśli jest to możliwe, to ułatwia życie. Naprawdę walczę o znalezienie dokumentacji lub literatury, która wyjaśnia coś poza tworzeniem interfejsu API z pojedynczymi punktami końcowymi zasobami.

Edytuj: Miałem jeden inny pomysł, że może wszystkie moje projekty Lambda mogły być całkowicie ignoranta z bramki API i po prostu mają swoje arns eksportowane jako wyjścia. Wtedy mogłem mieć całkowicie oddzielny projekt, który określa całą API-Gateway i tworzy integracje LAMBDA, które po prostu korzystają z funkcji Arns eksportowane przez funkcję w innych projektach. Uniemożliwiłoby to każdemu projektowi Lambda wymaga odwoływania się do API_Gateway_Resource odpowiedniego zasobu nadrzędnego. Mam ochotę jednak nie być dobrym pomysłem.

0
apostrophedottilde 10 październik 2020, 00:35

1 odpowiedź

Najlepsza odpowiedź

Chcę uniknąć eksportowania Arns do zasobów API-Gateway i używając ich w innych projektach, ponieważ nie sądzę, aby stworzyć zależności między oddzielnymi wdrażaniem.

Nie jestem pewien co do tego stwierdzenia. Niezależnie od sposobu, w jaki się pójdziesz, będziesz mieć zależności między projektem, który tworzy API GW i projekt Lambda Sub.

Do tej pory zrozumiałem, w jakim kierunku powinieneś stworzyć tę zależność:

  • Eksportuj APIGW i ponownie użyj go w projekcie Lambda
  • Eksportuj Lambdę i ponownie użyć go w projekcie apigw

Myślę, że ma sens, że Lambda zostanie uznany za niezależny element infrastruktury w projekcie Terraform i nie tworzyć żadnego rodzaju zasobów związanych z APIGW. Przede wszystkim, ponieważ w takim przypadku stwarza już silną ukrytą zależność i ograniczenie w stosowaniu Twojego Lambda. A po drugie możesz myśleć w ten sposób: co jeśli twój projekt będzie coraz więcej i musisz dodać więcej i więcej Lambdas do interfejsu API. W takim scenariuszu prawdopodobnie nie chcesz tworzyć za każdym razem, gdy nowe metody / zasoby i prawdopodobnie wygodniej jest używać czegoś takiego jak for_each w terraforku i napisać kod jeden raz i automatycznie tworzy nowe integracje, gdy dodawasz nową lambdę .

Stąd uniknąłbym pierwszego wyboru i przejść do drugiej opcji, która jest czyszczeniem z punktu stoiska architektonicznego. Wszystko, co zajmuje się API GW, pozostaje w tym samym projekcie. Twoje zmiany wskazują na właściwy kierunek. Możesz mieć jedną repo dla "infrastruktury" (zadzwoń do tego, co chcesz), a jeden dla "lambda". Możesz wyprowadzić Lambda Arns jako listę (lub niestandardową mapę z innymi kluczowymi parametrami) i użyj zdalnego stanu z projektu APIGW do pętli przez Lambda i utwórz potrzebny zasób w jednym miejscu za pomocą For_each.

Na przykład użyj zdalnego stanu z projektu APIGW:

data "terraform_remote_state" "lambda" {
  backend = "s3"
  config = {
    bucket = "my-bucket"
    key    = "my/key/state/for/lambda"
    region = "region"
  }
}

I użyj takich wyjść:

resource "aws_api_gateway_integration" "lambda" {
  for_each = data.terraform_remote_state.lambda.outputs.lambdas
  ...
  uri = each.value
}

Czy można korzystać z Route53 do trasy wszystkich połączeń API w dziedzinie do wielu oddzielnych bram API? Jeśli jest to możliwe, to ułatwia życie. .

Przepraszam, nie jestem pewien, że zrozumiem ten punkt, ale nadal będę próbował szczegółowo szczegółowo szczegółowo. Brama API "Link" zapewnia zadzwonić do interfejsu API to tylko DNS. Kiedy tworzysz interfejs API, za kulisami AWS tworzy dystrybucję w cloudfront dla Ciebie w regionie US-East-1. Nie masz dostępu do niej przez konsolę, ponieważ jest zarządzany przez AWS. Gdy mapujesz API do nazwy domeny, faktycznie mapujesz domenę do rozkładu Cloudfront Twojego API. Po dodaniu metod lub zasobów do interfejsu API (to jest to, co robisz ze swoim Lambda), za każdym razem, gdy za każdym razem nie tworzysz nowych API.

1
halfer 22 październik 2020, 20:46