‫Los requisitos para esta sección incluyen comprender cómo iniciar un contenedor. Luego, conceptos básicos de redes TCP
‫/ IP, como subredes e IP y puertos y firewalls.
‫No tiene que saber todo eso, pero definitivamente le será mucho más fácil comprender esta
‫sección que se centra en cosas conceptuales, antes de
‫que realmente entremos en un montón de cosas de la línea de comandos en la próxima conferencia.
‫Solo quiero recordarle la opción -p en sus comandos de ejecución de contenedor que expone
‫el puerto en su máquina.
‫De hecho, hay muchas más cosas en el fondo de las redes de Docker de las que hablaremos.
‫Docker tiene este concepto de baterías incluidas pero extraíbles, lo que básicamente significa que los valores predeterminados son bastante
‫fáciles y comunes para trabajar, pero que puede cambiar muchas de las opciones debajo del capó.
‫En esta conferencia revisaremos rápidamente el comando del puerto del contenedor que le brinda una
‫salida rápida de qué puertos están abiertos para ese contenedor en su red.
‫Luego, vamos a desglosar algunos de los conceptos de redes Docker y redes virtuales y
‫cómo fluyen los paquetes por la red.
‫Y terminaremos con un diagrama de red que muestra cómo los contenedores se comunican entre sí
‫y cómo es diferente de la p de exponerlos a la red física.
‫Cuando realmente inicia un contenedor, realmente está en segundo plano conectándose a una red
‫Docker en particular. De forma predeterminada, esa es la red de puente, como veremos en un minuto. Luego, cada una de esas
‫redes a las que se conectaría enrutará en realidad a través de un firewall NAT, que en realidad es
‫el demonio Docker que configura la dirección IP del host en su interfaz predeterminada para que sus contenedores
‫puedan salir a Internet o al resto de su red y luego volver.
‫Pero en realidad no necesitamos usar -p cuando tenemos contenedores específicos que desean comunicarse
‫entre nosotros dentro de nuestro host.
‫Por ejemplo, si tenía una aplicación que tenía un servidor secuela y un contenedor PHP Apache, esos dos contenedores deberían estar
‫en la misma red y ser capaces de comunicarse entre sí sin tener que abrir sus
‫puertos al resto de su red física. .
‫Si tenía otra aplicación que no estaba relacionada, supongamos que estaba usando Mongo y Node. js, podrías crear una red para
‫eso para que puedan hablar entre ellos sin usar -p para
‫exponerlos a la red. Pero en realidad no podían hablar con la otra red
‫donde podría tener una aplicación no relacionada ejecutándose.
‫Pero la cuestión es que casi todas esas configuraciones que describí son realmente cambiables.
‫Y esto trae un buen dicho que a Docker le gusta usar ... eso son baterías incluidas pero extraíbles.
‫Verá que a lo largo de este curso muchas veces hay valores predeterminados que simplemente funcionan de
‫manera predeterminada.
‫Ni siquiera tiene que especificarlos. Solo se da cuenta de que las cosas están configuradas de
‫una manera estándar.
‫Pero muchas de estas opciones son configurables en tiempo de ejecución o incluso cambiables después del hecho. Y veremos que algo de eso tiene lugar
‫aquí cuando jugamos con las redes.
‫Algunas de las cosas que realmente puede cambiar sería crear múltiples redes virtuales, tal
‫vez una por aplicación, o diferentes según los diferentes requisitos de seguridad.
‫En realidad, al igual que en el mundo físico, puede tener dos NIC físicas en una computadora real. En realidad, puede tener dos redes
‫virtuales conectadas a un contenedor, o puede hacer que el contenedor no hable
‫con ninguna red.
‫Puede omitir cualquiera de las configuraciones de red virtual que salen de la caja y realmente
‫usar
‫- net = host, y perderá algunos de los beneficios de contenedorización.
‫Pero en algunos casos puede ser requerido.
‫Más tarde, en realidad vamos a entrar en los controladores de red de Docker. Existe todo este ecosistema de
‫complementos alrededor de Docker que extiende las capacidades de Docker a muchas herramientas de terceros.
‫Pero en este caso vamos a ver un par de controladores de red Docker diferentes
‫y cómo podrían cambiar nuestra red y darnos nuevas habilidades.
‫Esto realmente solo está rascando la superficie.
‫En realidad, hay conceptos de redes a lo largo de este curso donde
‫hablaremos sobre temas más avanzados de redes privadas de múltiples hosts y conceptos como subinterfaces, etc.
‫Pero por ahora, profundicemos en algunas cosas de la línea de comandos.
‫Como una revisión
‫rápida, veamos el -p de nuestros comandos de ejecución de contenedores ... Docker contenedor ejecutar.
‫Si recuerda la primera vez que ejecutamos un contenedor, usamos -p para exponer el puerto 80 de nuestro Nginx.
‫Eso tomó el lado izquierdo, que es el puerto host, y reenvía el tráfico desde ese puerto al puerto
‫80 del contenedor.
‫Si hicimos el host web del puerto del contenedor de Docker, en realidad muestra esto en un formato agradable y fácil qué puertos
‫están reenviando el tráfico a ese contenedor desde el host al contenedor mismo.
‫No hemos hablado de la dirección IP del contenedor.
‫Por lo tanto, puede suponer que el contenedor está utilizando la misma IP que el host. Pero por defecto, eso no es
‫cierto.
‫Podemos obtener fácilmente la Docker IP de ese contenedor inspeccionándolo y vamos a usar el
‫comando de formato, o la opción realmente, que notará que en realidad tiene un formato bastante específico sobre
‫cómo filtrar las cosas entrantes.
‫Siempre puede usar el comando grep que usamos anteriormente para filtrar su salida de texto, pero
‫el formato, el formato, en realidad es un poco más limpio y consistente. Haces dos llaves, y luego, una vez que nos
‫acostumbramos a conocer el formato del archivo de configuración, sabemos que NetworkSettings. Dirección IP es el nodo
‫real de esa salida JSON que queremos ver.
‫Y luego webhost. Vaya, eso significa que no lo deletreé bien.
‫I P A d d.
‫Y eso no es lo que esperaba.
‫Si iba a usar la IP de mi host porque conozco mis Mac en mi red local, y si hago una configuración
‫if en mi Mac, solo sé que la dirección IP está en mi red doméstica o un 1 9 2 1 6 8 subred.
‫Es interesante que no sean la misma red.
‫Entonces, ¿por qué es eso?
‫Veamos si tiene más sentido si lo saco.
‫Si mi sistema operativo host está conectado a mi red ... esta es mi red ... red física Entonces esta es la
‫interfaz Ethernet en mi máquina host, en mi caso es mi Mac.
‫Hay un pequeño firewall allí que hace varias cosas. Bloquea todo el tráfico entrante que ingresa desde la red para que
‫todo esté bloqueado de manera predeterminada. Yo lo llamaría un firewall. Todo el tráfico
‫que salga de mis contenedores tendrá NAT de forma predeterminada.
‫Actúa como un firewall perimetral bastante común en una red.
‫Pero existe este concepto de redes virtuales y, de forma predeterminada, verá
‫una red llamada bridge o docker0.
‫Cuando inicie un nuevo contenedor, lo llamaremos C1, ese contenedor está conectado a esa red, esa red virtual,
‫y esa red virtual se conecta automáticamente a su interfaz Ethernet en su host para que
‫pueda salir.
‫En nuestro caso, cuando acabamos de lanzar ese Nginx, le dimos un -p 80:80. Eso le indicó que abriera el puerto 80 en
‫mi interfaz Ethernet en mi Mac y reenvíe cualquier cosa que entre al puerto 80 a través
‫de esa red virtual al puerto 80
‫en ese contenedor.
‫Por defecto, cuando creo un segundo contenedor, se coloca en la misma red de puente.
‫Esos dos contenedores pueden hablar libremente de un lado a otro en sus puertos expuestos.
‫A menos que especifique el -p, ningún tráfico que ingrese a mis redes internas aquí va a llegar a
‫mis contenedores.
‫De hecho, puedo crear más redes virtuales y llamarlas como quiero. Voy a llamar a
‫esta red mi aplicación, digamos. Y digamos que conecto dos contenedores aquí ... Tengo MySQL
‫Entonces obtuve un Apache.
‫En MySQL, no
‫abrí ningún puerto, y nunca especifiqué un -p. Pero en el de
‫Apache, le di un -p de 8080: 80.
‫Eso significaría que aquí a la derecha, en mi interfaz Ethernet en mi host, comenzará a escuchar en
‫el puerto 8080.
‫Tan pronto como el tráfico llegue a mi host en el puerto 8080, lo encaminará hacia esta
‫nueva red virtual que creé y hacia ese servidor Apache en el puerto 80.
‫Dentro de esta red virtual, el servidor Apache es libre de hablar con el servidor MySQL a través de su
‫puerto de escucha.
‫Cuando piense en las redes virtuales en Docker y en dónde pertenecen los contenedores, piense en cómo
‫colocaría diferentes contenedores cerca uno del otro porque están relacionados en su aplicación.
‫Como puede ver, estos dos ejemplos, si tuviera un contenedor uno y un contenedor dos de
‫alto rango, algo diferente, si no van a hablar con los servicios de esta red a continuación,
‫tendría sentido mantener ellos en redes virtuales separadas.
‫Si alguna vez tuvieran que hablar entre ellos, tendrían que pasar por sus
‫puertos publicados y volver a entrar.
‫Como recordatorio, en cualquier interfaz en su host, no puede escuchar en más de un puerto para múltiples contenedores.
‫Por lo tanto, no puede tener dos contenedores escuchando en el puerto 80 en el nivel de host.
‫Solo uno puede hacer eso.
‫Si intenta iniciar otro contenedor, en realidad se producirá un error y dirá que
‫ya hay algo más en ese puerto. Esa no es una limitación de Docker; eso es solo una limitación de
‫cómo funciona la red IP.
‫Solo un resumen rápido de esta sección. De hecho, dedicamos mucho tiempo a los conceptos de las redes de
‫Docker, incluida la exposición de los puertos de su host a la red física utilizando -p. La idea de Docker se centra
‫en valores predeterminados sanos donde lo llaman baterías incluidas pero extraíbles.
‫En cuanto a los desarrolladores y las pruebas locales, es probable que pueda seguir con los valores predeterminados, pero todo es modificable.
‫Luego aprendimos sobre el comando del puerto del contenedor, que es una forma rápida de ver los
‫puertos expuestos para sus contenedores particulares.
‫Luego desglosamos los paquetes que se mueven alrededor de las redes virtuales y cómo se relacionan con otras
‫redes virtuales, y cómo entran y salen de su máquina Docker.
‫Por lo tanto, estos son conceptos realmente buenos para entender a medida que nos adentramos en las cosas reales de CLI en la
‫próxima conferencia.