‫Os requisitos para esta seção incluem entender como iniciar um contêiner. Em seguida, conceitos básicos de rede
‫TCP / IP, como sub-redes e IPs e portas e firewalls.
‫Você não tem que saber tudo isso, mas definitivamente tornará muito mais fácil para
‫você entender esta seção que é focada em coisas
‫conceituais, antes de realmente entrar em um monte de coisas da linha de comando na próxima aula.
‫Eu só quero lembrá-lo sobre a opção -p em seus comandos de contêiner que expõe
‫a porta em sua máquina.
‫Na verdade, há muito mais acontecendo no segundo plano da rede Docker sobre a qual falaremos.
‫O Docker tem esse conceito de baterias incluídas, mas removível, o que basicamente significa que os padrões são muito fáceis
‫e comuns de se trabalhar, mas que você pode mudar muitas das opções sob o capô.
‫Nós veremos rapidamente nesta palestra o comando container port que lhe dá uma saída
‫rápida de quais portas estão abertas para aquele container em sua rede.
‫Em seguida, vamos detalhar alguns dos conceitos de rede e redes virtuais do Docker e
‫como os pacotes fluem pela rede.
‫E terminaremos com um diagrama de rede mostrando como os contêineres conversam entre si e
‫como isso é diferente do -p de expô-los à rede física.
‫Quando você realmente inicia um contêiner, você está realmente em segundo plano se conectando a
‫uma rede Docker específica. Por padrão, essa é a rede de ponte, como veremos em um minuto. Em seguida, cada uma dessas
‫redes às quais você se conectaria realmente será direcionada por um firewall NAT, que é na verdade o
‫daemon do Docker que configura o endereço IP do host em sua interface padrão para que seus contêineres
‫possam acessar a Internet ou o restante de seu rede e depois voltar.
‫Mas, na verdade, não precisamos usar o -p quando temos contêineres específicos querendo falar um
‫com o outro dentro de nosso host.
‫Por exemplo, se você tivesse um aplicativo que tivesse um servidor sequela e um contêiner PHP Apache, esses dois contêineres
‫deveriam estar na mesma rede e eles poderiam se comunicar sem realmente abrir suas portas
‫até o resto de sua rede física. .
‫Se você tivesse outro aplicativo não relacionado, digamos que estava usando o Mongo e o Node. js, você poderia criar uma rede para
‫que eles pudessem conversar um com o outro sem usar o -p
‫para expô-los à rede. Mas eles não conseguiram falar com a outra rede onde você
‫pode ter um aplicativo não relacionado em execução.
‫Mas o fato é que praticamente todas as configurações que descrevi são realmente mutáveis.
‫E isso traz um bom ditado que o Docker gosta de usar ... isto é baterias incluídas mas removíveis.
‫Você verá que ao longo deste curso muitas vezes existem padrões que simplesmente funcionam fora da
‫caixa.
‫Você nem precisa especificá-los. Você apenas percebe que as coisas estão configuradas de uma
‫maneira padrão.
‫Mas muitas dessas opções são configuráveis em tempo de execução ou até mesmo alteráveis após o fato. E vamos ver alguns dos que acontecem
‫aqui quando brincamos com as redes.
‫Algumas das coisas que você pode realmente mudar seria criar várias redes virtuais, talvez
‫uma por aplicativo, ou diferentes, com base em diferentes requisitos de segurança.
‫Você pode, na verdade, assim como no mundo físico, ter duas NICs físicas em um computador real. Na verdade, você pode ter duas
‫redes virtuais conectadas a um contêiner ou pode realmente fazer com que o contêiner não
‫converse com nenhuma rede.
‫Você pode pular qualquer configuração de rede virtual que sai da caixa e realmente usar
‫-
‫net = host, e você perderá alguns dos benefícios de conteinerização.
‫Mas, em alguns casos, pode ser necessário.
‫Mais tarde, na verdade, entraremos nos drivers de rede do Docker. Existe todo esse ecossistema de
‫plugins em torno do Docker que estende os recursos do Docker para muitas ferramentas de terceiros.
‫Mas neste caso, vamos examinar alguns drivers diferentes de rede do Docker e como eles
‫podem mudar nossa rede e nos dar novas habilidades.
‫Isso é apenas arranhar a superfície.
‫Na verdade, existem conceitos de rede ao longo deste curso, nos quais falaremos sobre
‫tópicos mais avançados de redes privadas de vários hosts e conceitos como subinterfaces e assim por diante.
‫Mas por enquanto, vamos nos aprofundar em algumas coisas da linha de comando.
‫Como uma rápida
‫revisão, vamos olhar para o -p do nosso container executando comandos ... contêiner do contêiner executado.
‫Se você se lembra de quando executamos um contêiner pela primeira vez, usamos o -p para expor a porta 80 de nosso Nginx.
‫Isso levou o lado esquerdo, que é a porta do host, e encaminha o tráfego dessa porta para a porta
‫80 do contêiner.
‫Se nós fizéssemos o webhost da porta contêiner do docker, ele mostraria isso em um formato simples e fácil, no qual as portas
‫estão encaminhando o tráfego para esse contêiner do host para o próprio contêiner.
‫Não falamos sobre o endereço IP do contêiner.
‫Então, você pode apenas supor que o contêiner está usando o mesmo IP que o host. Mas, por padrão, isso não é
‫verdade.
‫Podemos facilmente obter o IP do Docker desse contêiner, inspecionando-o e vamos usar o
‫comando format, ou a opção realmente, que você notará na verdade tem um formato bastante específico para
‫filtrar o material recebido.
‫Você sempre pode usar o comando grep que usamos anteriormente para filtrar a saída de texto, mas
‫o formato, o --format, é na verdade um pouco mais limpo e consistente. Você faz duas chaves, e depois que nos acostumamos
‫a conhecer o formato do arquivo de configuração, sabemos que NetworkSettings. IP Adress é o nó
‫real da saída JSON que queremos ver.
‫E então webhost. Oops, isso significa que não escrevi direito.
‫Eu P A d d.
‫E isso não é o que eu esperava.
‫Se eu fosse usar o IP do meu host porque eu conheço meus Macs na minha rede local, e se eu fizer
‫um ifconfig no meu Mac, eu apenas sei que o endereço IP está na minha rede doméstica ou 1 9 2 1 6 8 sub-rede.
‫Isso é interessante que eles não são da mesma rede.
‫Então, por que isso?
‫Vamos ver se fará mais sentido se eu desenhá-lo.
‫Se meu sistema operacional host estiver conectado à minha rede ... esta é minha rede ... rede física. Então esta é a
‫interface Ethernet na minha máquina host, no meu caso é o meu Mac.
‫Há um pequeno firewall lá que faz várias coisas. Ele bloqueia todo o tráfego de entrada vindo da rede para que
‫tudo seja bloqueado por padrão. Eu chamaria isso de firewall. Qualquer tráfego
‫proveniente dos meus contêineres será NATed por padrão.
‫Está agindo como um firewall de borda bastante comum em uma rede.
‫Mas há esse conceito de redes virtuais e, por padrão, você verá
‫uma rede chamada bridge ou docker0.
‫Quando você inicia um novo contêiner, vamos chamá-lo de C1, esse contêiner é anexado a essa rede, essa rede
‫virtual e essa rede virtual é automaticamente conectada à sua interface Ethernet em seu host para que ele
‫possa sair.
‫No nosso caso, quando acabamos de lançar o Nginx, nós demos um -p 80:80. Isso disse aqui para abrir a porta 80 na
‫minha interface Ethernet no meu Mac e encaminhar qualquer coisa que entra na porta 80 através
‫dessa rede virtual para a porta
‫80 naquele contêiner.
‫Por padrão, quando eu crio um segundo contêiner, ele é colocado na mesma rede de ponte.
‫Esses dois contêineres podem falar livremente para frente e para trás em suas portas expostas.
‫A menos que eu especifique o -p, nenhum tráfego entrando em minhas redes internas aqui vai chegar aos
‫meus contêineres.
‫Na verdade, posso criar mais redes virtuais e chamá-las do que quero. Eu vou chamar isso
‫de net meu aplicativo, digamos. E digamos que eu conecte dois contêineres aqui ... Eu tenho o MySQL.
‫Então eu peguei um Apache.
‫No MySQL, eu não
‫abri nenhuma porta e nunca especifiquei um -p. Mas no Apache,
‫eu dei um -p de 8080: 80.
‫Isso significaria aqui à direita, na minha interface Ethernet no meu host, ele vai começar a escutar
‫na porta 8080.
‫Assim que o tráfego chegar ao meu host na porta 8080, ele será encaminhado para essa
‫nova rede virtual que criei e para esse servidor Apache na porta 80.
‫Dentro desta rede virtual, o servidor Apache está livre para conversar com o servidor MySQL pela sua porta
‫de escuta.
‫Quando você pensa em redes virtuais no Docker e onde os contêineres pertencem, pense em como você colocaria
‫contêineres diferentes próximos uns dos outros porque eles estão relacionados em sua aplicação.
‫Como você pode ver, esses dois exemplos, se eu tivesse um contêiner um e um contêiner
‫dois no topo colocariam algo diferente, se eles não estivessem falando com os serviços nessa rede abaixo, então
‫faria sentido manter -los em redes virtuais separadas.
‫Se eles tivessem que conversar um com o outro, teriam que passar pelos portos
‫publicados até o final e voltar.
‫Como lembrete, em qualquer interface do seu host, você não pode ouvir em mais de uma porta para vários contêineres.
‫Portanto, você não pode ter dois contêineres ouvindo na porta 80 no nível do host.
‫Apenas um pode fazer isso.
‫Se você tentar iniciar outro contêiner, ele realmente errará e informará
‫que já existe algo nessa porta. Isso não é uma limitação do Docker; isso é apenas uma limitação de como
‫a rede IP normalmente funciona.
‫Apenas uma rápida recapitulação nesta seção. Na verdade, gastamos muito tempo com os conceitos de rede do
‫Docker, incluindo a exposição de portas em seu host à rede física usando o -p. A ideia do Docker se concentrar
‫em padrões sãos onde eles chamam de baterias incluídas, mas removíveis.
‫Como para dev local e testando, você provavelmente só pode adquirir com os padrões, mas tudo é variável.
‫Então, aprendemos sobre o comando de porta do contêiner, que é uma maneira rápida de examinar as
‫portas expostas para seus contêineres específicos.
‫Em seguida, dividimos os pacotes em torno de redes virtuais e como elas se relacionam com outras redes
‫virtuais e como elas entram e saem da sua máquina Docker.
‫Então, estes são todos conceitos realmente bons para entender, enquanto nós entramos no material real do CLI na próxima
‫palestra.