1 votes

Stocker le corps de la requête de l'itinéraire sans toucher au serveur web dans AWS.

Disons que j'ai un site web : mysite.com qui fonctionne sur AWS, servi à partir de quelques instances EC2 derrière un équilibreur de charge d'application. L'équilibreur de charge termine SSL par un certificat ACM.

J'ai besoin d'acheminer les demandes entrantes vers une URL (exemple : mysite.com/{user_id}/something/here/ ) loin de l'équilibreur de charge et les envoyer plutôt à une fonction Lambda (plus précisément, je veux juste capturer le corps de la requête et l'écrire quelque part, puis renvoyer un HTTP 200 ; cela ne doit pas nécessairement être fait via une fonction Lambda).

L'ALB vous permet de router vers différents groupes cibles, mais il semble qu'ils ne puissent contenir que des instances EC2. La documentation indique que "Vous enregistrez les cibles, telles que les instances EC2, avec un groupe cible". sinon peuvent être ajoutées si ce ne sont pas uniquement des instances EC2 ?

Je ne veux pas avoir à faire tourner ma propre instance de haproxy, etc., ni à les acheminer via nginx une fois que les requêtes passent par l'ALB et atteignent les serveurs web, car le but de cet exercice est de réduire les choses que je dois gérer, pas de les augmenter !

Y a-t-il un moyen de contourner ce problème ?

0 votes

D'après un examen de la documentation (je n'ai pas encore utilisé ALB), il semble que vous deviez cibler les instances EC2. Je pense que le moyen le plus simple de le faire est de passer par un proxy comme Nginx. Je me demande si la passerelle API ne pourrait pas jouer un rôle, mais cela signifierait acheminer toutes les demandes à travers elle. Pouvez-vous demander au client d'appeler un point de terminaison différent pour cette requête, un sous-domaine qui est mappé à Lambda ? Si vous modifiez votre question pour donner plus de détails sur votre cas d'utilisation, vous pourriez obtenir de meilleures informations.

0 votes

Ma principale préoccupation est que si je le proxy avec nginx et autres, je dois maintenir cette instance et travailler pour qu'elle reste en place pendant les pics de trafic, et je fais cela pour essayer de réduire la redondance en l'éloignant le plus possible de mes mains. Malheureusement, je ne peux pas non plus modifier les chemins appelés.

0 votes

Quelque chose comme API Gateway qui vous permet d'accéder à un service AWS (DynamoDB, SQS..) me semble parfait, mais je ne vois pas comment l'implémenter dans ma configuration existante, car je dois intercepter une URL allant à l'ALB et l'envoyer uniquement à API Gateway, mais laisser tout le reste passer par l'équilibreur de charge tel que configuré.

2voto

Michael - sqlbot Points 21488

Vous enregistrez les cibles, telles que les instances EC2, avec un groupe de cibles.

http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html

Vous avez fait une observation astucieuse. C'est un choix de mots intéressant... mais, pour l'instant du moins, les instances EC2 sont le seul type de cible.

Une instance EC2 invoquant vos fonctions Lambda ou les envoyant par proxy à API Gateway (avec Nginx ou HAProxy) est une solution raisonnable. Si vous n'êtes pas familier avec l'utilisation d'une instance uniquement en tant que proxy, vous serez probablement surpris de la quantité de trafic que vous pouvez pousser à travers des instances même minuscules lorsque le proxy est tout le travail qu'elles font. (J'ai des instances t2.micro et t2.nano avec HAProxy qui traitent plus d'un million de requêtes par jour sans jamais dépasser 5% de CPU).

Mais, si vous voulez réduire le nombre de choses à gérer, tout garder dans un seul domaine, et arracher certains chemins, vous pouvez utiliser CloudFront devant l'ALB, pour acheminer certains modèles de chemin ailleurs -- comme vers la passerelle API. (Bonus : cette solution vous permet également d'intégrer des actifs statiques provenant de S3 dans votre site. Vous pouvez même acheminer les requêtes vers des serveurs et des services externes à AWS, en faisant correspondre les modèles de chemin). CloudFront est commercialisé comme un CDN, mais il s'agit également d'un proxy inverse infiniment évolutif.

0 votes

Belle réponse ! Pourquoi n'ai-je pas pensé à cela, j'utilise CloudFront !

0 votes

Merci pour vos conseils. J'aime beaucoup l'idée de faire cela avec CloudFront, car il y a moins de gestion, etc. Mais je n'aime pas l'idée de mettre tout mon domaine en avant avec CF et de devoir l'empêcher de mettre en cache des choses non statiques, etc. Je vais donc opter pour le proxy avec nginx/haproxy parce que j'ai plus d'expérience avec lui. Votre autre réponse à serverfault.com/questions/830050/ est probablement très utile aussi !

0 votes

il faut l'empêcher de mettre en cache des éléments non statiques, etc. C'est un point juste, mais c'est assez facile. Si votre serveur d'origine renvoie correctement Cache-Control: ce qui devrait être le cas, CloudFront devrait faire ce qu'il faut. J'utilise généralement le comportement de mise en cache par défaut pour les ressources non mises en cache (transfert des cookies, chaînes de requête, etc.), puis je crée des comportements de mise en cache pour les choses à mettre en cache *.css , *.png , *.js etc. Vous devriez constater que CF rend l'ensemble de votre site plus rapide, même lorsque les ressources ne sont pas mises en cache, grâce aux chemins de transport optimisés qu'il fournit. Mais c'est vous qui décidez :)

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X