To nie jest całkiem odpowiedzi na swoje oryginalne pytanie, ale może być alternatywnym sposobem na osiągnięcie swoich celów.
Po pierwsze, współdzielenie dystrybucji CF między wszystkimi środowiskami (w tym prod) niesie ze sobą ryzyko - kiedy trzeba przetestować zmianę konfiguracji CF, konieczne będzie zmodyfikowanie produktu prod CF dist z nieprzetestowanymi zmianami, które mogą mieć znaczące konsekwencje .
Po drugie, chociaż jest wspaniale, jeśli można przetestować całe środowisko na wszystkich etapach rurociągu CI/CD, nie zawsze jest to możliwe (a CF jest szczególnie niekorzystny) - więc chodzi o znalezienie równowagi między krótkimi cyklami sprzężenia zwrotnego i dokładność testowania.
Rozwiązaniem jest zwykle wprowadzenie dodatkowych etapów do rurociągu, gdzie wczesne stadia dają szybką opinię na temat najczęstszych problemów, a późniejsze etapy dają wolniej opinię na mniej częstych problemów.
W twoim przypadku, sugeruję: Wdrożenia
- Branch nie rozmieścić CF - Testy kierować API bramy bezpośrednio wdrożeń
- Master/domyślne NIE rozmieścić CF - do 'pomostowym' środowiska - badania ukierunkowane na dystrybucję inscenizacja CF
- powodzeniem przetestowany uwolnienia do środowiska „pomostowym” promowane są do produkcji
wprowadzając środowiska pomostowego, można dostać ra pid opinie na temat budowania oddziałów, ale nadal masz możliwość przetestowania rzeczy za pamięci podręcznej przed wejściem do prod.
Jeśli wprowadzasz zmiany w konfiguracji CF, możesz spowodować, że skrypt wdrażania zdecyduje się dynamicznie włączyć opcję CF do wdrożenia w oddziale z pewnym wyzwalaczem (być może obecność słowa "cloudfront" w nazwie oddziału - chociaż może to bądź trochę "magiczny" dla niektórych!) i możesz przetestować te zmiany na gałęzi przed połączeniem się z masterem w celu przetestowania w inscenizacji.
Jeśli białej listy nagłówka Host, powinien przejść przez nagłówek hosta do pochodzenia jako 'Host' (to znaczy nie jako' X-Przekazano-Host'). Czy możesz opublikować faktyczny błąd, który otrzymujesz? Czy to tylko 500 bez treści, czy jest tam komunikat o treści lub błędzie? Warto również przejrzeć dzienniki Cloudwatch dla bramy API, aby uzyskać bardziej szczegółowy komunikat o błędzie. –
@ChrisSimon przekazując nagłówek hosta pierwotnego żądania jako 'Host:' spowodowałoby, że żądanie nigdy nie dotarło do bramy API, która oczekuje pojedynczej, przypisanej wartości w 'Host' - więc nie byłoby tam generowanych dzienników.Pytanie tutaj brzmi: jak przekazać wiele wartości hosta żądania (wieloznacznego) do jednego celu, bez utraty śladu oryginalnej nazwy hosta, wysyłając go jako * alternatywny * nagłówek, taki jak "X-Forwarded-Host", utworzony automatycznie przez CloudFront . –
@ Michael-sqlbot dokładnie to, czego chcę (czy wiesz, czy jest to możliwe?!). Potrafię również potwierdzić, że otrzymałem 403 od CloudFront (BŁĄD, żądanie nie może zostać spełnione. Złe żądanie) i ta bramka API nigdy nie zostanie trafiony (i nie generuje żadnych dzienników w CloudWatch ... ale działa, gdy bezpośrednio trafisz w API, a nie przez CloudFront). –