Bonjour, tout le monde, et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons parler du DNS hybride.
Dans les grandes organisations, l'un des modèles d'architecture courants que vous verrez est
basé sur une configuration hybride.
Ainsi, une partie de l'infrastructure peut se trouver dans un autre centre de données
sur site, dans Azure, etc.
Lorsque vous disposez d'une configuration hybride, l'un des défis à relever est lié à la résolution globale du DNS.
Et c'est un sujet que nous allons aborder dans la vidéo d'aujourd'hui.
Maintenant, avant de comprendre les choses en détail, révisons les bases liées à la zone d'hébergement
privée d'un point de vue général.
La zone privée hébergée contient l'enregistrement qui spécifie comment vous voulez acheminer le trafic dans un VPC
Amazon.
Par exemple, disons que vous avez une zone hébergée privée et qu'il y a un certain ensemble d'enregistrements
et deux EPC.
Maintenant, par défaut, ces VPC ne seront pas en mesure d'effectuer la résolution basée sur ces enregistrements.
Ce que vous devez faire, c'est associer le VPC à une zone hébergée privée et ce n'est qu'après cette association
que les ressources du VPC seront en mesure d'effectuer la résolution.
Maintenant, à ce stade, puisque le VPC numéro deux n'est pas associé, la CE, deux instances dans ce VPC ne seront
pas en mesure de résoudre les enregistrements de cette zone hébergée privée spécifique.
Maintenant, laissez-moi aussi vous montrer rapidement.
A ce stade, j'ai donc une zone hébergée privée appelée demo dot internal.
Le type que vous voyez est privé maintenant associé à cette zone.
Si je modifie rapidement la zone, vous avez une option relative à l'association d'un VPC à cette zone.
Et à ce stade, vous voyez qu'il n'y a qu'un seul VPC qui est associé.
Vous avez également la possibilité d'associer plusieurs ensembles de VPC à cette zone de manière à ce que tous
les enregistrements qui font partie de cette zone soient résolvables par les ressources associées
au VPC.
Maintenant, il est très important de se rappeler que la Route 53 ne répond pas aux requêtes qui
ne proviennent pas du VPC.
Par exemple, disons que vous avez une zone hébergée privée et que vous avez un VPC numéro un qui est associé
à cette zone, et il y a également un VPC numéro deux, et il y a un peering entre ces deux VPC.
Ainsi, l'instance easy two dans VPC two pourra communiquer avec l'instance EC, two dans VPC
one et vice versa.
Maintenant, puisque le VPC 1 a accès à la zone hébergée privée, on suppose que les ressources du VPC 2, par le biais de cette
connexion d'échange de trafic, seront également en mesure de résoudre les enregistrements qui font partie de la zone
hébergée privée.
Or, ce n'est pas le cas.
Donc si un easy two du VPC numéro deux envoie la requête pour cet enregistrement spécifique.
Par exemple, 01. point de démonstration interne à l'adresse VPC numéro un plus deux.
Il ne pourra pas être résolu.
Alors allons-y et examinons rapidement cette question.
Maintenant, comme pour cette architecture spécifique, j'ai déjà l'infrastructure en place.
Ainsi, dans le compte numéro un, j'ai une instance easy to qui fonctionne et j'ai une autre instance
easy two qui fonctionne dans le compte numéro deux et les deux VPC dans lesquels l'EC two fonctionne,
ces VPC sont apparus.
Par exemple, si nous regardons la connexion de peering, vous voyez qu'il y a un peering entre le compte
numéro un et le compte numéro deux VPC.
Et comme dans ce diagramme, il y a une zone privée hébergée qui est associée au VPC numéro
un.
Laissez-moi aussi vous montrer.
Donc si vous regardez l'association, elle est associée à l'un des VPC, que nous appelons
VPC numéro un.
Maintenant, depuis le terminal, je suis déjà connecté à ces deux instances EC.
Ainsi, la première instance de EC two a une IP de 1077 zero 172.
Maintenant si vous voyez que vous avez 1077 zero 172 et le second a une IP de 1 7231 et si vous regardez par
ici vous avez 1 7231.
Donc, avant de continuer, vérifions d'abord si la connectivité est bien présente.
Donc, à partir du compte numéro deux, EC deux, je vais aller de l'avant et je vais faire un ping sur l'EC deux associé
au compte numéro un.
Et comme prévu, à ce stade, la connectivité ping est bien là.
Maintenant, à ce stade, le deuxième point est très important où nous discutions de l'adresse VPC plus deux.
C'est donc l'adresse liée à la résolution globale.
Donc, en général, laissez-moi vous montrer rapidement si nous allons à la conf de résultat de l'ETSI.
Vous avez le plus à aborder.
Ainsi, si le CIDR du VPC est 1070 700 16, le serveur de noms sera 1077 0. 2.
Très bien.
Maintenant si vous faites une recherche sur disons, google. com sur cette adresse, 1077 0. 2 Encore une fois, si vous ne le mentionnez pas, je prendrai
cela par défaut.
Mais pour éviter toute confusion, je l'ajoute ici.
Vous voyez, la résolution fonctionne parfaitement bien.
De même, si vous essayez la résolution associée au domaine de la zone hébergée privée, essayons-la.
Je vais dire 01. démo point interne.
Et vous voyez, la résolution fonctionne aussi parfaitement bien.
Maintenant, puisqu'il y a déjà une connectivité entre VPC un et VPC deux, on suppose que l'instance dans
le VPC deux, si cette instance envoie également cette requête DNS spécifique sur cette adresse plus deux, la résolution
fonctionnera.
Cependant, nous venons d'apprendre qu'il s'agit de quelque chose qui n'est pas pris en charge, alors essayons-le.
Donc si je lance exactement la même commande ici, vous voyez, nous n'obtenons pas vraiment de réponse ici.
Et à ce stade, nous avons reçu un message indiquant qu'aucun serveur n'a pu être atteint.
C'est donc ce que signifie le premier pointeur où nous disons que la Route 53 ne répondra pas aux
requêtes qui ne proviennent pas du VPC.
Maintenant, à ce stade, nous avons discuté du peering VPC.
Cependant, il peut s'agir de n'importe quel type de montage.
Par exemple, si nous discutons de l'architecture hybride où vous avez un VPC un et vous avez un on
premise et il y a une connectivité soit via VPN et connexion directe, même dans ces cas, si les ressources
dans on premise essaie de se connecter au VPC un plus deux adresses IP pour la résolution, ce genre de configuration
n'est pas supporté.
Étant donné que de nombreuses organisations utilisent activement ce type de configuration, la question est de savoir
quelle est la solution probable pour la faire fonctionner.
Et l'une des solutions probables ici est d'introduire un serveur DNS.
Ainsi, si vous examinez cette architecture probable spécifique, vous commencerez par héberger
le serveur DNS personnalisé dans le VPC.
C'est donc une instance facile à mettre en place.
Ensuite, le système sur site envoie les requêtes au serveur DNS personnalisé.
Ainsi, à partir d'une installation, au lieu d'envoyer le message à l'adresse IP plus deux, vous l'envoyez à l'adresse IP de
ce serveur DNS personnalisé.
Maintenant, ce serveur DNS personnalisé transmettra la requête au résolveur Route 53 approprié.
Et à partir de là, quelle que soit la réponse que ce serveur DNS personnalisé recevra, il transmettra la réponse
au serveur sur site.
Et c'est l'une des architectures très courantes que vous verrez généralement dans les organisations.
Ça marche plutôt bien.
Toutefois, ce type d'architecture présente certains défis.
La première est que le client doit gérer le serveur DNS personnalisé, donc tout ce qui concerne la haute disponibilité,
la sécurité, l'optimisation de l'évolutivité devient la responsabilité du client.
Si, pour une raison quelconque, l'instance EC2 liée au serveur DNS personnalisé tombe en panne, l'ensemble
de la résolution DNS cessera de fonctionner, ce qui affectera l'ensemble de l'application.
Et c'est l'une des raisons pour lesquelles elle a introduit les points d'extrémité du résolveur root 53 qui nous permettent de
communiquer avec les hôtes ou domaines privés depuis l'extérieur du VPC.
Donc ici, au lieu du serveur DNS personnalisé, nous introduisons le point de terminaison du résolveur.
Et l'avantage de ce point final de résolution est qu'il prend en charge toute l'infrastructure ici.
Vous n'avez donc pas vraiment à vous soucier de la haute disponibilité, de l'optimisation de la sécurité, etc. Laissez-nous nous en occuper.
Tout ce que vous avez à faire est de créer un point de terminaison de résolveur et d'envoyer la requête à l'adresse IP
associée à ce point de terminaison et toute votre configuration DNS est faite pour vous.
Et aujourd'hui, la plupart des organisations passent de l'approche du serveur DNS personnalisé
dont nous avons parlé à celle du point final du résolveur.
Là encore, les fonctionnalités du point de terminaison du résolveur offrent une grande souplesse.
Nous en parlerons dans la vidéo appropriée.
Cependant, d'un point de vue architectural, j'espère que vous avez une idée des solutions associées
à une configuration hybride.
C'est ainsi que se termine la vidéo d'aujourd'hui.