‫La configuration requise pour cette section comprend la compréhension du démarrage d’un conteneur. Ensuite, les concepts réseau de base TCP /
‫IP, tels que les sous-réseaux et les adresses IP, les ports et les pare-feu.
‫Vous n'avez pas besoin de savoir tout cela, mais cela vous facilitera certainement la compréhension
‫de cette section, qui est centrée sur les concepts,
‫avant que nous ne passions vraiment à quelques éléments de ligne de commande dans la prochaine conférence.
‫Je tiens simplement à vous rappeler l'option -p de vos commandes d'exécution de conteneur, qui expose
‫le port de votre ordinateur.
‫Nous allons parler de beaucoup plus en arrière-plan de la mise en réseau Docker.
‫Docker a ce concept de piles inclus mais amovible, ce qui signifie essentiellement que les valeurs par défaut
‫sont assez faciles et courantes, mais que vous pouvez changer beaucoup d'options sous le capot.
‫Nous verrons rapidement dans cette leçon la commande de port de conteneur qui vous donne
‫un aperçu rapide des ports ouverts pour ce conteneur sur votre réseau.
‫Ensuite, nous allons détailler certains concepts de réseau Docker et de réseaux virtuels, ainsi que la manière
‫dont les paquets circulent dans le réseau.
‫Et nous terminerons avec un diagramme de réseau montrant comment les conteneurs parlent entre eux et
‫en quoi cela diffère du -p de les exposer sur le réseau physique.
‫Lorsque vous démarrez un conteneur, vous êtes vraiment en arrière-plan lorsque vous vous connectez à
‫un réseau Docker particulier. Par défaut, il s’agit du réseau pont, comme nous le verrons dans une minute. Ensuite, chacun de ces réseaux
‫auxquels vous souhaitez vous connecter achemine via un pare-feu NAT, qui est en fait le démon Docker
‫configurant l'adresse IP de l'hôte sur son interface par défaut afin que vos conteneurs puissent se connecter
‫à Internet ou au reste de votre système. réseau et ensuite revenir.
‫Mais nous n’avons pas besoin d’utiliser le -p lorsque des conteneurs spécifiques souhaitent communiquer
‫entre eux au sein de notre hôte.
‫Par exemple, si vous avez une application avec un serveur séquentiel et un conteneur Apache PHP, ces deux conteneurs doivent se
‫trouver sur le même réseau et ils doivent pouvoir se parler sans ouvrir réellement leurs
‫ports au reste de votre réseau physique. .
‫Si vous aviez une autre application qui n’était pas liée, disons qu’elle utilisait Mongo et Node. js, vous pouvez créer un réseau pour
‫cela afin qu’ils puissent se parler sans utiliser le -p pour
‫les exposer au réseau. Mais ils ne pouvaient pas réellement parler à l’autre réseau sur
‫lequel une application non liée est en cours d’exécution.
‫Mais le fait est que presque tous les paramètres que j'ai décrits sont réellement modifiables.
‫Et cela nous amène à un bon dicton que Docker aime utiliser ... c'est des piles incluses mais amovibles.
‫Vous verrez que tout au long de ce cours, il y a souvent des valeurs par défaut qui
‫fonctionnent simplement.
‫Vous n'êtes même pas obligé de les spécifier. Vous remarquez simplement que les choses sont configurées de
‫manière standard.
‫Mais bon nombre de ces options sont configurables au moment de l'exécution ou même modifiables après coup. Et nous en verrons une partie lorsque
‫nous jouerons avec les réseaux.
‫Certaines des choses que vous pouvez réellement changer sont la création de plusieurs réseaux virtuels,
‫peut-être un par application, ou différents basés sur des exigences de sécurité différentes.
‫Vous pouvez réellement, comme dans le monde physique, avoir deux cartes réseau physiques sur un ordinateur réel. En fait, vous pouvez avoir deux
‫réseaux virtuels connectés à un conteneur, ou bien le conteneur ne peut communiquer
‫avec aucun réseau.
‫Vous pouvez ignorer toutes les configurations de réseau virtuel qui sortent de la boîte et utiliser
‫réellement -
‫net = host. Vous perdrez ainsi certains des avantages de la conteneurisation.
‫Mais dans certains cas, cela peut être nécessaire.
‫Plus tard, nous allons entrer dans les pilotes de réseau Docker. L’ensemble de l’écosystème de
‫plug-ins autour de Docker étend les capacités de Docker à de nombreux outils tiers.
‫Mais dans ce cas, nous allons examiner quelques pilotes de réseau Docker différents et voir comment
‫ils pourraient changer notre réseau et nous donner de nouvelles capacités.
‫C'est vraiment juste gratter la surface.
‫Tout au long de ce cours, nous aborderons des concepts de mise en réseau dans lesquels
‫nous aborderons des sujets plus avancés de mise en réseau privée multi-hôtes et des concepts tels que les sous-interfaces, etc.
‫Mais pour l'instant, penchons-nous sur des éléments en ligne de commande.
‫En résumé,
‫regardons le -p de nos commandes en cours d'exécution du conteneur ... conteneur docker exécuter.
‫Si vous vous rappelez la première fois que nous avons exécuté un conteneur, nous avons utilisé le -p pour exposer le port 80 de notre Nginx.
‫Cela a pris le côté gauche, qui est le port hôte, et transfère le trafic de ce port dans le port
‫80 du conteneur.
‫Si nous avons hébergé Webhost, il montre en fait, dans un format facile et agréable, quels ports transfèrent
‫le trafic à ce conteneur de l'hôte au conteneur lui-même.
‫Nous n'avons pas parlé de l'adresse IP du conteneur.
‫Vous pouvez donc supposer que le conteneur utilise la même adresse IP que l'hôte. Mais par défaut, ce n'est pas
‫vrai.
‫Nous pouvons facilement obtenir l'adresse IP Docker de ce conteneur en l'inspectant et nous allons
‫utiliser la commande de format, ou l'option vraiment, qui, vous remarquerez en fait, a un format assez spécifique
‫pour filtrer les éléments entrants.
‫Vous pouvez toujours utiliser la commande grep que nous avons utilisée précédemment pour filtrer votre sortie texte, mais
‫le format, le --format, est en fait un peu plus propre et cohérent. Vous faites deux accolades, puis une fois que nous nous
‫sommes habitués à connaître le format du fichier de configuration, nous connaissons NetworkSettings. Adresse IP est le noeud réel
‫de la sortie JSON que nous souhaitons examiner.
‫Et puis webhost. Oups, ça veut dire que je n'ai pas bien épelé.
‫I P A d d.
‫Et ce n'est pas ce à quoi je m'attendais.
‫Si j'allais utiliser l'adresse IP de mon hôte parce que je connais mes Mac sur mon réseau local et si je fais un
‫ifconfig sur mon Mac, je sais simplement que l'adresse IP se trouve sur mon réseau domestique ou sur un 1 9 2 1 6 8 sous-réseau.
‫C'est intéressant, ils ne sont pas le même réseau.
‫Alors pourquoi ça?
‫Voyons si cela aura plus de sens si je le dessine.
‫Si mon système d'exploitation hôte est connecté à mon réseau ... c'est mon réseau ... réseau physique. Ensuite, il s’agit de
‫l’interface Ethernet de mon ordinateur hôte. Dans mon cas, c’est mon Mac.
‫Il y a un petit pare-feu qui fait plusieurs choses. Il bloque tout le trafic entrant provenant du réseau afin que
‫tout soit bloqué par défaut. Je l'appellerais un pare-feu. Tout le trafic
‫sortant de mes conteneurs sera traité par défaut avec NAT.
‫Il agit comme un pare-feu périphérique assez commun sur un réseau.
‫Mais il y a ce concept des réseaux virtuels, et par défaut, vous
‫verrez un réseau appelé bridge ou docker0.
‫Lorsque vous démarrez un nouveau conteneur, nous l'appelons C1, ce conteneur est lié à ce réseau, ce réseau virtuel,
‫et ce réseau virtuel est automatiquement connecté à votre interface Ethernet sur votre hôte afin qu'il puisse
‫être extrait.
‫Dans notre cas, lorsque nous venons de lancer Nginx, nous lui avons donné un -p 80:80. Cela nous a incité à ouvrir le port 80 sur
‫mon interface Ethernet sur mon Mac et à transférer tout élément entrant dans le port 80 via
‫ce réseau virtuel vers le port 80
‫de ce conteneur.
‫Par défaut, lorsque je crée un deuxième conteneur, il est placé sur le même réseau de ponts.
‫Ces deux conteneurs peuvent parler librement entre leurs ports exposés.
‫À moins que je ne spécifie l'option -p, aucun trafic entrant dans mes réseaux internes ne parviendra à
‫mes conteneurs.
‫Je peux réellement créer plus de réseaux virtuels et les appeler comme je veux. Je vais appeler
‫celui-ci mon application, disons. Et disons que je connecte deux conteneurs ici ... J'ai MySQL.
‫Puis j'ai eu un Apache.
‫Sur MySQL, je n’ai
‫ouvert aucun port, et n’ai jamais spécifié un -p. Mais sur Apache, je
‫lui ai donné un -p de 8080: 80.
‫Cela signifierait que ici à droite, à mon interface Ethernet sur mon hôte, il va commencer à écouter
‫sur le port 8080.
‫Dès que le trafic arrive sur mon hôte sur le port 8080, il va le rediriger vers ce
‫nouveau réseau virtuel que j'ai créé et sur ce serveur Apache sur le port 80.
‫À l'intérieur de ce réseau virtuel, le serveur Apache est libre de communiquer avec le serveur MySQL via son
‫port d'écoute.
‫Lorsque vous pensez aux réseaux virtuels dans Docker et à la place des conteneurs, réfléchissez à la manière de placer
‫différents conteneurs à proximité les uns des autres, car ils sont liés dans leur application.
‫Comme vous pouvez le constater, ces deux exemples, si j’avais un conteneur un et un conteneur deux
‫en haut, quelque chose de différent, s’ils ne parlent pas aux services de ce réseau, il serait alors logique
‫de garder les sur des réseaux virtuels distincts.
‫S'ils devaient se parler, ils devraient parcourir tous
‫les ports publiés.
‫Pour rappel, sur toute interface de votre hôte, vous ne pouvez pas écouter sur plusieurs ports pour plusieurs conteneurs.
‫Ainsi, vous ne pouvez pas avoir deux conteneurs écoutant sur le port 80 au niveau de l'hôte.
‫Un seul peut le faire.
‫Si vous essayez de démarrer un autre conteneur, cela signifierait qu'il y a
‫déjà quelque chose d'autre sur ce port. Ce n'est pas une limitation de Docker; c'est simplement une limitation du fonctionnement
‫typique des réseaux IP.
‫Juste un bref récapitulatif sur cette section. En fait, nous avons passé beaucoup de temps sur les concepts de
‫réseau Docker, notamment l'exposition des ports de votre hôte au réseau physique à l'aide de l'option -p. L'idée de Docker se concentrant sur des
‫défauts sains où ils appellent cela des piles incluses mais amovibles.
‫Pour le développement et les tests locaux, vous pouvez probablement vous en tirer avec les valeurs par défaut, mais tout est modifiable.
‫Nous avons ensuite découvert la commande container port qui constitue un moyen rapide d’examiner les
‫ports exposés pour vos conteneurs particuliers.
‫Ensuite, nous avons décomposé les paquets se déplaçant sur les réseaux virtuels et leur relation avec les autres
‫réseaux virtuels, et leur entrée et sortie de votre ordinateur Docker.
‫Donc, ce sont tous de très bons concepts à comprendre lorsque nous abordons le sujet de la CLI lors de la
‫prochaine conférence.