2017-05-03 4 views
0

Je remplace un site Web existant par un nouveau, par étapes. Du point de vue de l'utilisateur, toutes les URL existantes doivent rester les mêmes, mais certains chemins doivent desservir de nouvelles pages.Utilisation de CloudFront pour diviser le trafic entre les serveurs d'origine - cette configuration est-elle correcte?

J'ai deux serveurs d'origine: l'ancien (www.mysite.com) et le nouveau, EC2 one (www.ec2-loadbalancer.com) - évidemment des URL simulées pour des raisons de confidentialité.

J'ai créé une distribution AWS CloudFront avec un paramètre CNAME de www.mysite.com. Dans cette distribution, j'ai créé deux domaines d'origines:

  • www.mysite.com
  • www.ec2-loadbalancer.com

Dans CloudFront, j'ai configuré certains comportements afin que les chemins comme /foo sont envoyés à mon EC2 origine équilibreur de charge, et tous les autres chemins (par défaut) sont envoyés à www.mysite.com. D'un point de vue DNS, j'ai ajouté un enregistrement CNAME de www.mysite.com qui pointe vers mon domaine hôte Cloudfront (par exemple, foo.cloudfront.net.). L'enregistrement A pour ce domaine pointe vers l'adresse IP du serveur hérité.

J'ai lancé tout cela aujourd'hui et il semble avoir fonctionné, mais je vois des erreurs intermittentes 403 sur le site, et deux heures après avoir fait le changement (il n'y avait pas de "www" CNAME avant, donc TTL shouldn ' t faire une différence), certains navigateurs servent toujours le site de l'IP d'origine (plutôt que celle du CloudFront).

Est-ce que j'ai configuré correctement? Je n'ai pas pu déterminer comment faire cela via l'enregistrement A - qui pointe vers l'adresse IP du serveur hérité, et CloudFront ne me permet pas d'entrer une adresse IP comme origine. Dois-je pointer le CNAME www à l'adresse IP, fait le point d'enregistrement A à CloudFront à la place? Je suis un peu perdu ici. D'un autre côté, tout pourrait être une chose de propagation, mais je me méfie d'avoir vu des erreurs 40x heures après avoir fait le changement.

Répondre

1

Il est dommage que vous ne pouvez pas partager les domaines avec nous pour aider à corriger, mais à tout le moins, dig est votre ami. Par exemple:

$ dig membership.theguardian.com 
... 
;; ANSWER SECTION: 
membership.theguardian.com. 367 IN CNAME i.global-ssl.fastly.net. 
i.global-ssl.fastly.net. 12 IN A 151.101.128.67 
i.global-ssl.fastly.net. 12 IN A 151.101.64.67 
i.global-ssl.fastly.net. 12 IN A 151.101.0.67 
i.global-ssl.fastly.net. 12 IN A 151.101.192.67 

... vous dit que membership.theguardian.com pointe vers Fastly par CNAME. Vous pouvez vérifier avec les serveurs DNS de remplacement, comme Google's DNS sur 8.8.8.8, en faisant ceci:

$ dig @8.8.8.8 membership.theguardian.com 

... afin que vous puissiez voir comment d'autres personnes résolvent vos domaines.

Du point de vue de DNS, j'ai ajouté un enregistrement CNAME de www.mysite.com qui pointe vers mon domaine hôte CloudFront (par exemple. De foo.cloudfront.net.). L'enregistrement A de ce domaine pointe vers l'adresse IP du serveur hérité.

Je suis pas un expert DNS, il est donc possible que je ne suis pas vous comprendre, mais ce son comme il introduit l'ambiguïté? Pour moi, cela ressemble à deux enregistrements différents pour le même domaine www.mysite.com, l'un pointant vers CloudFront, et l'autre vers l'adresse IP de votre ancien serveur. Selon la façon dont cela se résout un navigateur pourrait être envoyé à l'un ou l'autre ?!

  • www.mysite.com doit pointer que à CloudFront. Je voudrais personnellement utiliser un CNAME pour cela. Vous devriez avoir des adresses sans ambiguïté à la fois pour votre serveur hérité et votre EC2 Elastic Load Balancer - je leur donnerais personnellement leurs propres noms de domaine, afin d'éviter toute confusion (par exemple legacy.mysite.com & beta.mysite.com) - et dans CloudFront se référer uniquement à ceux effacer les noms lorsque vous dirigez le trafic (par exemple, en passant le trafic sur www.mysite.com pour accéder au serveur hérité, vous risquez de prêter à confusion).

enter image description here

Bonne chance!

+1

C'était la solution. J'ai enlevé l'enregistrement 'A' et j'ai pointé le' www' CNAME à Cloudfront. Je pense que l'ambiguïté entre ces deux enregistrements était la cause ici car il n'y a plus d'erreurs 40x/50x. Merci Roberto! –

1

Je pense que vous devriez créer un enregistrement A (pour le nom de domaine nommé) avec un alias pointant vers la distribution cloudfront. Cela devrait résoudre le problème.

à savoir Utiliser le nom d'alias au lieu de l'adresse IP et pointer votre domaine vers CloudFront:

enter image description here

+0

Où suggérez-vous que l'enregistrement A devrait pointer? Quelque part dans cette configuration, j'ai besoin de référencer l'adresse IP du serveur hérité ... –

+0

J'ai ajouté une capture d'écran. En utilisant le nom d'alias, vous n'aurez pas besoin de référencer l'adresse IP du serveur. –

+0

Merci - Je ne suis toujours pas clair et je ne suis pas sûr que ce soit correct. Mon nom de domaine n'est pas hébergé sur Route 53, mais même ainsi, ça ne marchera pas, sûrement? Si je crée un enregistrement d'alias pour la distribution CloudFront, alors oui, visiter mon domaine ira là, mais mon serveur d'origine ne pointera plus vers l'adresse IP d'origine (comme l'enregistrement A pour le domaine actuel pointe ici), ? –