Je possède un nom de domaine my-portal.com .
Je souhaite diffuser un site Web statique à partir de my-portal.com/site/a/ .
Je souhaite servir un autre site Web statique à partir de my-portal.com/site/b/ .
Comment puis-je faire cela avec les ressources fournies par AWS?
J'essayais de configurer deux sites Web en tant que deux compartiments S3 distincts avec l'hébergement de site Web statique activé, puis j'ai créé une passerelle API avec les ressources / site / a et / site / b configuré comme proxy HTTP pour les sites Web S3.
Cette configuration a fonctionné correctement dans la plupart des cas. Mais lorsqu'un navigateur tente de charger un fichier binaire (police, image, etc.) à partir de mon site Web statique, la passerelle API ne gère pas correctement ce fichier et répond avec le fichier corrompu (car il se comporte étrangement avec les fichiers binaires).
Quelles sont les autres façons d'obtenir le même résultat?
3 Réponses :
Vous pouvez créer un sous-domaine (a et b) et l'utiliser dans votre site Web
Si vous avez hébergé votre domaine en dehors d'Amazon, vous pouvez utiliser la route 53 ou l'adresse fwd dans CNAME.
Veuillez lire les liens suivants pour plus de détails
Merci. Fondamentalement, la raison pour laquelle je veux que deux sites Web soient sous le même domaine est que je veux partager le WebStorage entre eux. Les avoir sous des sous-domaines briserait cette exigence. Mais merci quand même pour votre réponse.
Vous ne voulez pas utiliser nginx?
"partager le stockage Web" ... qu'est-ce que cela signifie?
@vaquarkhan voulez-vous dire exécuter nginx dans un conteneur Fargate au lieu d'utiliser une passerelle API de niveau supérieur ou d'autres ressources?
@ Michael-sqlbot localStorage et sessionStorage
Ok, je pense avoir trouvé une solution de contournement. Il est possible de configurer des types mime de fichiers binaires dans API Gateway. En utilisant * / *, APIG traite chaque réponse comme un fichier binaire. Cela fonctionne très bien pour html / js / css / images / fonts etc. Mais cela casse l'API JSON le cas échéant. Donc, la seule limitation dans ce cas est de ne pas mélanger l'API JSON avec la statique.
@Girafa oh, oui, bien sûr. Je pensais à AWS et aux composants côté serveur et je ne pouvais pas imaginer à quoi vous faisiez référence, dans ce contexte. Mon erreur. Les deux sont limités à une seule origine, ce qui exclut en effet les sous-domaines.
Heureux que vous ayez résolu le problème, mais si vous ajoutez votre question avec une erreur de compression binaire sur une escapade API ou votre condition pour laquelle vous souhaitez utiliser Http Proxy, vous obtiendrez une réponse correcte. Meilleure pratique, vous pouvez ajouter votre réponse ici et marquer comme correcte pour aider d'autres personnes qui seront confrontées au même problème à l'avenir.
Vous pouvez facilement y parvenir en utilisant AWS CloudFront. Utilisez des comportements pour sélectionner l'origine en fonction du tracé. CloudFront a une intégration intégrée à S3.
Ayant un comportement pointant / site / a / * vers le bucket "A", il transférera toutes les requêtes vers "A / site / a", donc j'aurais besoin d'avoir un dossier "/ site / a" dans mon bucket "A "et" / site / b "dans le bucket" B ". Existe-t-il un moyen de pointer "/ site / a / *" vers la racine du compartiment "A"? Je ne veux pas que mes buckets contiennent ces sous-chemins.
@Girafa pour effectuer cette réécriture de chemin, vous pouvez utiliser un déclencheur Lambda @ Edge Origin Request pour réécrire les chemins à l'arrière de CloudFront avant qu'ils ne soient envoyés aux buckets. L'utilisation conjointe de CloudFront et d'un déclencheur Lambda @ Edge est toujours une solution moins coûteuse que API Gateway.
Cela semble intéressant. Je vais essayer. Je vous remercie
CloudFront permet de configurer plusieurs comportements de cache, en acheminant différents modèles de chemin vers une origine respective:
https://my-portal.com https: // bucket-a. s3-website.amazonaws.com / site / a https://my-portal.com https: // bucket-b. s3-website.amazonaws.com / site / b La seule limitation est que chaque compartiment S3 doit connaître le chemin et fournir la même structure de fichier à l'intérieur. Le bucket du site Web A doit contenir le dossier / site / a , le bucket B doit contenir le dossier / site / b .
Il est possible de surmonter cette limitation en utilisant Lambda @ Edge.
API Gateway permet de configurer les types de fichiers binaires mime. Mais il faut que les requêtes aient l'en-tête Accept compatible avec les types mime configurés.
Ainsi, par exemple, si vous configurez une image / * comme type MIME binaire dans APIG, vos demandes d'images doivent avoir un en-tête Accept avec la valeur image / png , image / jpg ou simplement image / * . Si l'en-tête est manquant ou s'il a une autre valeur, APIG ne traitera pas la réponse comme un fichier binaire.
Le problème ici est que les navigateurs envoient généralement Accept: * / * lorsqu'ils essaient de charger des ressources importées depuis CSS.
Donc, la seule solution à cela serait de configurer * / * comme un type MIME binaire. Cela cassera toutes les réponses non binaires servies par cette passerelle API, comme les réponses JSON.
Ceci est une combinaison des deux approches précédentes. Vous pouvez simplement créer un hébergement de site Web statique distinct et y placer vos fichiers binaires.