‫Vereisten voor deze sectie zijn onder meer inzicht in het starten van een container. Vervolgens basisconcepten voor TCP/IP-netwerken,
‫zoals subnetten en IP's en poorten en firewalls.
‫Je hoeft dat niet allemaal te weten, maar het zal het zeker een stuk makkelijker voor
‫je maken om deze sectie, die gericht is op conceptuele
‫dingen, te begrijpen, voordat we in de volgende lezing echt ingaan op een heleboel dingen op de commandoregel.
‫Ik wil je alleen herinneren aan de -p optie op je container run-commando's die de
‫poort op je machine blootlegt.
‫Er is eigenlijk veel meer aan de hand op de achtergrond van Docker-netwerken waar we het over zullen hebben.
‫Docker heeft dit concept van batterijen inbegrepen, maar verwijderbaar, wat in feite betekent dat de standaardinstellingen vrij eenvoudig en gebruikelijk
‫zijn om mee te werken, maar dat je veel van de opties onder de motorkap kunt veranderen.
‫We zullen in deze lezing snel het containerpoort-commando bekijken dat u een snelle uitvoer
‫geeft van welke poorten open zijn voor die container op uw netwerk.
‫Daarna gaan we enkele concepten van Docker-netwerken en virtuele netwerken opsplitsen en hoe
‫pakketten door het netwerk stromen.
‫En we eindigen met een netwerkdiagram dat laat zien hoe containers met elkaar praten en hoe dat
‫verschilt van de -p om ze bloot te stellen aan het fysieke netwerk.
‫Wanneer u daadwerkelijk een container start, maakt u echt op de achtergrond verbinding met
‫een bepaald Docker-netwerk. Standaard is dat het bridge-netwerk, zoals we zo dadelijk zullen bekijken. Vervolgens wordt elk van
‫die netwerken waarmee u verbinding zou maken, daadwerkelijk door een NAT-firewall geleid, wat in feite de
‫Docker-daemon is die het IP-adres van de host configureert op de standaardinterface, zodat uw containers naar
‫internet of naar de rest van uw netwerk en ga dan terug.
‫Maar we hoeven de -p niet echt te gebruiken als we specifieke containers hebben die
‫met elkaar willen praten binnen onze host.
‫Als u bijvoorbeeld een toepassing had met een vervolgserver en PHP Apache-container, zouden die twee containers op hetzelfde netwerk
‫moeten staan en met elkaar kunnen praten zonder hun poorten daadwerkelijk open te stellen voor
‫de rest van uw fysieke netwerk .
‫Als u een andere toepassing had die geen verband hield, laten we zeggen dat u Mongo en Node gebruikte. js, zou je daarvoor een netwerk kunnen maken
‫zodat ze met elkaar kunnen praten zonder de -p te gebruiken om ze aan
‫het netwerk bloot te stellen. Maar ze konden niet echt praten met het andere netwerk
‫waar je misschien een niet-gerelateerde app hebt draaien.
‫Maar het punt is dat zo ongeveer al die instellingen die ik beschreef eigenlijk veranderbaar zijn.
‫En dit levert een goed gezegde op dat Docker graag gebruikt... dat is inclusief batterijen maar verwijderbaar.
‫Je zult tijdens deze cursus zien dat er vaak standaardinstellingen zijn die gewoon uit de doos
‫werken.
‫Je hoeft ze niet eens te specificeren. Je merkt gewoon dat dingen op een soort standaard manier
‫zijn geconfigureerd.
‫Maar veel van deze opties kunnen tijdens runtime worden geconfigureerd of zelfs achteraf worden gewijzigd. En een deel daarvan zullen we hier zien
‫gebeuren als we met de netwerken spelen.
‫Sommige dingen die u daadwerkelijk kunt veranderen, zijn het creëren van meerdere virtuele
‫netwerken, misschien één per app, of verschillende op basis van verschillende beveiligingsvereisten.
‫Je kunt eigenlijk, net als in de fysieke wereld, twee fysieke NIC's op een echte computer hebben. U kunt eigenlijk twee virtuele netwerken
‫op één container hebben aangesloten, of u kunt de container zelfs met geen
‫netwerken laten praten.
‫U kunt elke virtuele netwerkconfiguratie die uit de doos komt overslaan en daadwerkelijk gebruiken
‫--
‫net=host, en u verliest enkele van de voordelen van containerisatie.
‫Maar in sommige gevallen kan het nodig zijn.
‫Later gaan we echt in op Docker-netwerkstuurprogramma's. Er is een heel
‫plug-in-ecosysteem rond Docker dat de mogelijkheden van Docker uitbreidt naar veel tools van derden.
‫Maar in dit geval gaan we kijken naar een aantal verschillende Docker-netwerkstuurprogramma's en hoe ze
‫ons netwerk kunnen veranderen en ons nieuwe mogelijkheden kunnen geven.
‫Dit is echt alleen maar krassen op het oppervlak.
‫Er zijn eigenlijk netwerkconcepten in deze cursus, waar we het
‫hebben over meer geavanceerde onderwerpen van multi-host privénetwerken en concepten zoals subinterfaces enzovoort.
‫Maar laten we ons voor nu eens verdiepen in wat commandoregeldingen.
‫Laten we als
‫snel overzicht eens kijken naar de -p van onze opdrachten voor het uitvoeren van containers... docker-container lopen.
‫Als je je herinnert dat toen we voor het eerst een container draaiden, we de -p gebruikten om poort 80 van onze Nginx bloot te leggen.
‫Dat nam de linkerkant, de hostpoort, en stuurt het verkeer van die poort door naar poort 80 van
‫de container.
‫Als we docker container port webhost hebben gedaan, laat het dit in een mooi, eenvoudig formaat zien welke poorten verkeer
‫naar die container doorsturen van de host naar de container zelf.
‫We hebben het nog niet gehad over het IP-adres van de container.
‫U kunt er dus vanuit gaan dat de container hetzelfde IP-adres gebruikt als de host. Maar standaard is dat niet
‫waar.
‫We kunnen gemakkelijk het Docker-IP van die container krijgen door het te inspecteren en we gaan
‫het format-commando gebruiken, of eigenlijk de optie, waarvan je zult merken dat het een vrij specifiek formaat heeft voor
‫het filteren van inkomende dingen.
‫Je kunt altijd het grep-commando gebruiken dat we eerder gebruikten om je tekstuitvoer eruit te filteren,
‫maar het formaat, het --format, is eigenlijk een beetje schoner en consistent. Je doet twee accolades, en als we eenmaal gewend
‫zijn aan het formaat van het configuratiebestand, weten we dat NetworkSettings. IP-adres is het eigenlijke knooppunt
‫van die JSON-uitvoer waar we naar willen kijken.
‫En dan webhosting. Oeps, dat betekent dat ik het niet goed heb gespeld.
‫I P A d.
‫En dat is niet wat ik verwachtte.
‫Als ik het IP-adres van mijn host zou gebruiken omdat ik mijn Macs op mijn lokale netwerk ken, en als ik
‫een ifconfig op mijn Mac doe, weet ik gewoon dat het IP-adres op mijn thuisnetwerk of een 1 9 2 1 6 8 Subnet.
‫Dat is interessant dat ze niet hetzelfde netwerk zijn.
‫Dus waarom is dat?
‫Eens kijken of het logischer is als ik het uitteken.
‫Als mijn hostbesturingssysteem is verbonden met mijn netwerk... dit is mijn netwerk... fysiek netwerk. Dan is dit
‫de Ethernet-interface op mijn hostcomputer, in mijn geval mijn Mac.
‫Er zit een kleine firewall in die verschillende dingen doet. Het blokkeert al het inkomende verkeer dat van het netwerk binnenkomt,
‫zodat alles standaard wordt geblokkeerd. Ik zou het een firewall noemen. Al het verkeer
‫dat uit mijn containers komt, wordt standaard NATed.
‫Het gedraagt zich als een vrij algemene edge-firewall op een netwerk.
‫Maar er is dit concept van de virtuele netwerken, en standaard zie je
‫een netwerk met de naam bridge of docker0.
‫Wanneer u een nieuwe container start, noemen we deze C1, die container is gekoppeld aan dat netwerk, dat
‫virtuele netwerk en dat virtuele netwerk wordt automatisch gekoppeld aan uw Ethernet-interface op uw host, zodat het
‫eruit kan.
‫In ons geval, toen we die Nginx net lanceerden, gaven we het een -p 80:80. Dat vertelde het hier om poort 80 op mijn
‫Ethernet-interface op mijn Mac te openen en alles dat poort 80 binnenkomt via dat virtuele netwerk
‫door te sturen naar poort 80
‫in die container.
‫Als ik een tweede container maak, wordt deze standaard op hetzelfde bridge-netwerk geplaatst.
‫Die twee containers kunnen vrijelijk heen en weer praten op hun blootgestelde poorten.
‫Tenzij ik de -p specificeer, zal geen verkeer dat in mijn interne netwerken komt hier naar mijn
‫containers gaan.
‫Ik kan eigenlijk meer virtuele netwerken maken en ze noemen zoals ik wil. Ik ga deze net
‫mijn app noemen, laten we zeggen. En laten we zeggen dat ik hier twee containers aansluit... Ik heb MySQL.
‫Toen kreeg ik een Apache.
‫Op MySQL heb ik
‫geen poorten geopend en heb ik nooit een -p opgegeven. Maar op de Apache-versie
‫gaf ik het een -p van 8080:80.
‫Dat zou betekenen dat het hier aan de rechterkant, bij mijn Ethernet-interface op mijn host, gaat luisteren
‫op poort 8080.
‫Zodra er verkeer bij mijn host binnenkomt op poort 8080, wordt het doorgestuurd naar dit nieuwe
‫virtuele netwerk dat ik heb gemaakt en naar die Apache-server op poort 80.
‫Binnen dit virtuele netwerk is de Apache-server vrij om via de luisterpoort met de MySQL-server
‫te praten.
‫Als je denkt aan virtuele netwerken in Docker en waar containers thuishoren, bedenk dan hoe je
‫verschillende containers bij elkaar zou plaatsen omdat ze gerelateerd zijn in hun toepassing.
‫Zoals je kunt zien, zijn deze twee voorbeelden, als ik een container één en een container twee bovenaan
‫had iets anders, als ze niet gaan praten met de services in dit netwerk hieronder, dan zou het logisch zijn
‫om te houden ze op afzonderlijke virtuele netwerken.
‫Als ze ooit met elkaar zouden moeten praten, zouden ze hun gepubliceerde poorten helemaal naar
‫buiten en weer naar binnen moeten gaan.
‫Ter herinnering: op elke interface op uw host kunt u niet op meer dan één poort luisteren voor meerdere containers.
‫U kunt dus niet twee containers laten luisteren op poort 80 op hostniveau.
‫Dat kan er maar één.
‫Als u een andere container probeert te starten, zou deze een foutmelding geven en zeggen dat
‫er al iets anders op die poort staat. Dat is geen beperking van Docker; dat is slechts een beperking van
‫hoe IP-netwerken doorgaans werken.
‫Even een korte samenvatting van dit gedeelte. We hebben eigenlijk veel tijd besteed aan de concepten van Docker-netwerken, inclusief
‫het blootstellen van poorten op je host aan het fysieke netwerk met behulp van de -p. Het idee dat Docker zich concentreert
‫op normale standaardwaarden, waarbij ze het batterijen noemen, inbegrepen maar verwijderbaar.
‫Hoe voor lokale ontwikkeling en testen, je waarschijnlijk gewoon rond kunt komen met de standaardinstellingen, maar alles is veranderlijk.
‫Toen leerden we over de opdracht containerpoort, een snelle manier om te kijken naar de poorten die
‫voor uw specifieke containers worden weergegeven.
‫Vervolgens hebben we de pakketten afgebroken die zich door virtuele netwerken verplaatsen en hoe deze zich verhouden tot
‫andere virtuele netwerken, en hoe ze in en uit uw Docker-machine komen.
‫Dit zijn dus allemaal heel goede concepten om te begrijpen als we in de volgende lezing ingaan op de
‫eigenlijke CLI-dingen.