Ce n'est pas tout à fait une réponse à votre question originale, mais cela pourrait être une façon alternative d'atteindre vos objectifs. Tout d'abord, le partage d'une distribution CF entre tous les environnements (y compris prod) comporte des risques. Lorsque vous devez tester une modification de la configuration CF, vous modifiez nécessairement la CFD dist avec des modifications non testées qui pourraient avoir des conséquences importantes . Deuxièmement, s'il est merveilleux de pouvoir tester l'ensemble de l'environnement à tous les stades d'un pipeline CI/CD, ce n'est pas toujours possible (et CF est particulièrement mauvais pour cela). Il s'agit donc de trouver un équilibre entre de courts cycles de feedback et rigueur des tests.
La solution consiste généralement à introduire des étapes supplémentaires dans votre pipeline, où les premiers stades donnent une rétroaction rapide sur les problèmes les plus courants, et les étapes ultérieures donnent un retour plus lent sur les problèmes moins fréquents.
Dans votre cas, je vous suggère:
- déploiements de succursales ne se déploient pas CF - les tests ciblent la passerelle API directement
- Maître/déploiements par défaut ne déployer des CF - à un environnement « mise en scène » - les tests visent la distribution des CF mise en scène
- testé avec succès les rejets dans l'environnement « mise en scène » sont promus à la production
en introduisant l'environnement de mise en scène, vous obtenez ra Pid feedback sur les builds de branches, mais vous avez toujours la possibilité de tester des choses derrière le cache avant d'entrer dans prod. Si vous apportez des modifications à la configuration CF, vous pouvez faire en sorte que votre script de déploiement décide de manière dynamique d'inclure CF dans le déploiement de branche à partir de certains déclencheurs (peut-être la présence du mot cloudfront dans le nom de la branche). être un peu "magique" pour certains!) et vous pourriez tester ces changements sur la branche avant de fusionner en master pour tester en staging.
Si vous mettez en liste blanche l'en-tête Host, il doit transmettre l'en-tête Host à l'origine en tant que 'Host' (c'est-à-dire pas en tant que' X-Forwarded-Host'). Pouvez-vous publier l'erreur réelle que vous recevez? Est-ce juste un 500 sans contenu, ou y a-t-il un corps ou un message d'erreur? Il peut également être intéressant de consulter les journaux Cloudwatch pour la passerelle API pour un message d'erreur plus détaillé. –
@ChrisSimon passant l'en-tête d'hôte de la demande d'origine en tant que 'Host:' aboutirait à ce que la requête n'arrive jamais à API Gateway, qui attend une seule valeur assignée dans 'Host' - donc il n'y aurait pas de logs générés.La question est de savoir comment canaliser plusieurs valeurs d'hôte de requête (caractère générique) jusqu'à une cible, sans perdre la trace du nom d'hôte d'origine, en l'envoyant comme en-tête * alternate *, comme 'X-Forwarded-Host', créé automatiquement par CloudFront . –
@ Michael-sqlbot précisément ce que je veux (savez-vous si c'est possible?!) .En outre, je peux confirmer que je reçois un 403 à partir de CloudFront (ERREUR La demande n'a pas pu être satisfaite. ne se fait jamais toucher (et ne génère aucun journal dans CloudWatch ... mais il le fait si vous frappez l'API directement, sans passer par CloudFront). –