‫I requisiti per questa sezione comprendono la comprensione di come avviare un contenitore. Quindi concetti di rete TCP /
‫IP di base, come sottoreti e IP, porte e firewall.
‫Non devi sapere tutto questo, ma sicuramente ti renderà molto più facile capire
‫questa sezione che è focalizzata su argomenti concettuali, prima
‫di entrare effettivamente in una serie di argomenti da linea di comando nella prossima lezione.
‫Voglio solo ricordarti dell'opzione -p sui comandi di esecuzione del contenitore che espone
‫la porta sul tuo computer.
‫In realtà c'è molto di più sullo sfondo della rete Docker di cui parleremo.
‫Docker ha questo concetto di batterie incluse ma rimovibili che in pratica significa che i valori predefiniti sono abbastanza
‫facili e comuni da utilizzare, ma che è possibile modificare molte delle opzioni sotto il cofano.
‫Verificheremo rapidamente in questa lezione il comando della porta del contenitore che ti dà un
‫rapido output di quali porte sono aperte per quel contenitore sulla tua rete.
‫Quindi analizzeremo alcuni concetti di networking Docker e reti virtuali e come
‫i pacchetti circolano nella rete.
‫E finiremo con un diagramma di rete che mostra come i contenitori parlano tra loro e
‫in che modo è diverso dal -p di esporli sulla rete fisica.
‫Quando in realtà si avvia un contenitore, ci si trova davvero sullo sfondo che si collega a
‫una particolare rete Docker. Per impostazione predefinita, questa è la rete bridge, poiché verificheremo tra un minuto. Quindi ciascuna di quelle reti
‫a cui ci si connetterà effettivamente uscirà attraverso un firewall NAT, che è in realtà il daemon
‫Docker che configura l'indirizzo IP dell'host sulla sua interfaccia predefinita in modo che i contenitori possano uscire
‫su Internet o sul resto del tuo rete e poi tornare indietro.
‫Ma in realtà non abbiamo bisogno di usare -p quando abbiamo contenitori specifici che vogliono parlare
‫tra di loro all'interno del nostro host.
‫Ad esempio, se disponi di un'applicazione con un server sequel e un contenitore Apache PHP, questi due contenitori devono trovarsi
‫sulla stessa rete e sono in grado di comunicare tra loro senza aprire effettivamente le
‫loro porte al resto della rete fisica .
‫Se avessi un'altra applicazione non correlata, diciamo che stavo usando Mongo e Node. js, potresti creare una rete in
‫modo che potessero parlare tra loro senza usare -p per
‫esporli alla rete. Ma non potevano effettivamente parlare con l'altra rete in cui si
‫potrebbe avere una app non correlata in esecuzione.
‫Ma il fatto è che quasi tutte quelle impostazioni che ho descritto sono in realtà modificabili.
‫E questo porta un buon detto che Docker ama usare ... quello è batterie incluse ma rimovibili.
‫Durante questo corso vedrai che un sacco di volte ci sono dei default che funzionano appena fuori
‫dagli schemi.
‫Non devi nemmeno specificarli. Hai appena notato che le cose sono configurate in una sorta
‫di modo standard.
‫Ma molte di queste opzioni sono configurabili in fase di runtime o anche modificabili dopo il fatto. E vedremo che alcuni di questi si svolgono
‫qui quando giochiamo con le reti.
‫Alcune delle cose che puoi effettivamente cambiare sarebbero la creazione di più reti virtuali,
‫forse una per app o diverse in base a diversi requisiti di sicurezza.
‫In realtà, proprio come nel mondo fisico, puoi avere due NIC fisiche su un vero computer. In realtà è possibile avere due
‫reti virtuali connesse a un contenitore, oppure è possibile che il contenitore comunichi
‫senza alcuna rete.
‫Puoi saltare qualsiasi configurazione di rete virtuale che esce dalla scatola e in realtà
‫usa
‫net = host e perderai alcuni dei vantaggi della containerizzazione.
‫Ma in alcuni casi potrebbe essere richiesto.
‫Più tardi, stiamo per entrare nei driver di rete Docker. C'è questo intero ecosistema di
‫plugin attorno a Docker che estende le funzionalità di Docker a molti strumenti di terze parti.
‫Ma in questo caso esamineremo un paio di diversi driver di rete Docker e come
‫potrebbero cambiare il nostro networking e darci nuove abilità.
‫Questo è davvero solo grattando la superficie.
‫In questo corso ci sono in realtà concetti di networking in cui
‫parleremo di argomenti più avanzati di reti private multi-host e concetti come sub-interfacce e così via.
‫Ma per ora, tuffiamoci in qualche cosa da linea di comando.
‫Come una rapida
‫recensione, diamo un'occhiata al -p del nostro contenitore che esegue i comandi ... contenitore docker eseguito.
‫Se ricordi quando abbiamo lanciato un container per la prima volta, abbiamo usato -p per esporre la porta 80 del nostro Nginx.
‫Quello prese il lato sinistro, che è la porta host, e inoltra il traffico da quella porta alla porta
‫80 del container.
‫Se facessimo il port webhost della porta docker, questo in realtà mostra questo in un formato semplice e intuitivo che le
‫porte stanno inoltrando il traffico verso quel container dall'host al container stesso.
‫Non abbiamo parlato dell'indirizzo IP del contenitore.
‫Quindi si potrebbe presumere che il contenitore stia utilizzando lo stesso IP dell'host. Ma per impostazione predefinita, non è
‫vero.
‫Possiamo facilmente ottenere l'IP Docker di quel container ispezionandolo e useremo il comando format,
‫o l'opzione, in realtà, che noterete che in realtà ha un formato abbastanza specifico per filtrare
‫le cose in arrivo.
‫Puoi sempre usare il comando grep che abbiamo usato in precedenza per filtrare il tuo output di testo,
‫ma il formato, il -format, è in realtà un po 'più pulito e coerente. Fai due parentesi graffe e poi, una volta che ci
‫siamo abituati a conoscere il formato del file di configurazione, sappiamo che NetworkSettings. Indirizzo IP è il nodo
‫effettivo di quell'output JSON che vogliamo esaminare.
‫E poi il webhost. Oops, questo significa che non ho scritto correttamente.
‫I P A d d.
‫E non è quello che mi aspettavo.
‫Se dovessi usare l'IP del mio host perché conosco i miei Mac sulla mia rete locale, e se faccio un ifconfig
‫sul mio Mac, so solo che l'indirizzo IP è sulla mia rete domestica o su un 1 9 2 1 6 8 sottorete.
‫È interessante che non siano la stessa rete.
‫Allora, perché è quello?
‫Vediamo se avrà più senso se lo estraggo.
‫Se il mio sistema operativo host è connesso alla mia rete ... questa è la mia rete ... rete fisica. Quindi questa è l'interfaccia
‫Ethernet sulla mia macchina host, nel mio caso è il mio Mac.
‫C'è un piccolo firewall in là che fa molte cose. Blocca tutto il traffico in ingresso proveniente dalla rete in modo che
‫tutto sia bloccato per impostazione predefinita. Lo chiamerei un firewall. Per impostazione predefinita,
‫tutto il traffico che esce dai miei contenitori sarà NATED.
‫Funziona come un firewall di bordo piuttosto comune su una rete.
‫Ma c'è questo concetto delle reti virtuali e, per impostazione predefinita, vedrai
‫una rete chiamata bridge o docker0.
‫Quando avvii un nuovo contenitore, lo chiameremo C1, quel contenitore è collegato a quella rete, quella
‫rete virtuale e quella rete virtuale viene automaticamente collegata all'interfaccia Ethernet dell'host in modo che
‫possa uscire.
‫Nel nostro caso, quando abbiamo lanciato quel Nginx, gli abbiamo dato un -p 80:80. L'ho detto qui per aprire la porta 80 sulla
‫mia interfaccia Ethernet sul mio Mac e inoltrare qualsiasi cosa entri nella porta 80 attraverso
‫quella rete virtuale alla porta 80
‫in quel contenitore.
‫Per impostazione predefinita, quando creo un secondo contenitore, viene inserito nella stessa rete bridge.
‫Questi due contenitori possono parlare liberamente avanti e indietro sulle porte esposte.
‫A meno che non specifichino il parametro -p, nessun traffico proveniente dalle mie reti interne arriverà ai
‫miei contenitori.
‫Posso effettivamente creare più reti virtuali e chiamarle come voglio. Io chiamerò questa
‫rete la mia app, diciamo. E diciamo che connetto due contenitori qui ... Ho ottenuto MySQL.
‫Poi ho ricevuto un Apache.
‫Su MySQL, non ho
‫aperto nessuna porta e non ho mai specificato un -p. Ma su Apache,
‫ho dato un -p di 8080: 80.
‫Ciò significherebbe qui sulla destra, alla mia interfaccia Ethernet sul mio host, inizierà ad ascoltare
‫sulla porta 8080.
‫Non appena il traffico arriva al mio host sulla porta 8080, lo indirizzerà verso il basso verso questa
‫nuova rete virtuale che ho creato e su quel server Apache sulla porta 80.
‫All'interno di questa rete virtuale, il server Apache è libero di parlare con il server MySQL sulla sua porta
‫di ascolto.
‫Quando pensi alle reti virtuali in Docker e a quali contenitori appartengono, pensa a come mettere
‫diversi contenitori in prossimità l'uno dell'altro perché sono correlati nella loro applicazione.
‫Come puoi vedere, questi due esempi, se avessi un container uno e un container due in
‫alto, qualcosa di diverso, se non hanno intenzione di parlare ai servizi di questa rete in basso, allora
‫avrebbe senso tenere li su reti virtuali separate.
‫Se dovessero mai parlare tra loro, dovrebbero passare attraverso i loro porti pubblicati fino
‫in fondo e di nuovo dentro.
‫Come promemoria, su qualsiasi interfaccia sul tuo host, non puoi ascoltare su più di una porta per più contenitori.
‫Pertanto, non è possibile avere due contenitori in ascolto sulla porta 80 a livello di host.
‫Solo uno può farlo.
‫Se si tenta di avviare un altro contenitore, si verificherebbe effettivamente l'errore e si
‫affermerà che c'è già qualcos'altro su quella porta. Questa non è una limitazione Docker; questo è solo un limite di come funziona
‫in genere la rete IP.
‫Solo un breve riepilogo su questa sezione. Abbiamo dedicato molto tempo ai concetti di networking Docker,
‫inclusa l'esposizione delle porte sul tuo host alla rete fisica usando -p. L'idea di Docker si concentra su
‫impostazioni predefinite sane in cui lo chiamano batterie incluse ma rimovibili.
‫Per quanto riguarda gli sviluppatori e i test locali, è probabile che tu riesca a cavartela con i valori predefiniti, ma tutto è modificabile.
‫Poi abbiamo imparato a conoscere il comando port container che è un modo rapido per guardare le
‫porte esposte per i vostri contenitori particolari.
‫Quindi abbiamo interrotto i pacchetti spostandoci attorno alle reti virtuali e in che modo queste si riferiscono ad
‫altre reti virtuali e come entrano ed escono dalla vostra macchina Docker.
‫Quindi, questi sono davvero dei buoni concetti da capire mentre passiamo alle cose reali della CLI nella prossima
‫lezione.