I. Introducción
Recientemente, estoy estudiando la implementación de múltiples máquinas de Hyperledger Fabric. Debido a que los contenedores de la ventana acoplable se distribuyen en varias máquinas, generalmente existen las siguientes soluciones para resolver los problemas de comunicación entre ellos:
- K8s, aunque k8s también puede resolver este problema, k8s se usa principalmente para alta confiabilidad, la configuración es más complicada y la curva de aprendizaje es relativamente empinada.
- red superpuesta. Docker proporciona una red de superposición nativa, que puede tratar varias máquinas como la misma red, y los contenedores dentro de la red pueden usar directamente la comunicación de nombres (con resolución y reenvío de dns internos). Generalmente utiliza cónsul como base de datos subyacente. Pero debido a que tiene requisitos para el kernel de Linux (superiores a 3.16), y en el proceso de prueba real, varias máquinas no pudieron comunicarse por razones desconocidas, así que tuve que rendirme. (Las conjeturas personales no pueden evitar un solo punto de falla).
- Personalice un servidor de nombres de dominio para una red de área local (porque Hyperledger generalmente se implementa en una red de área local o máquina virtual). También es la forma más fácil de configurar varios servidores DNS para evitar puntos únicos de falla.
- La resolución de nombres de dominio se proporciona en el archivo de configuración de docker-compse, porque es fija y no se puede aumentar ni disminuir, por lo que no es recomendable.
- Docker Swarm y otros métodos.
Este artículo integra dnsmasq
artículos relacionados en Internet y estudia el uso y andyshinn/dnsmasq
despliegue de servicios de resolución de nombres de dominio en una red de área local. Probado por separado para los sistemas operativos Mac y Centos 7.3, y probado algunos detalles.
Dos, que es dnsmasq
Entonces, ¿qué es dnsmasq, como se describe en su documento (actualizado el 2020-04-5):
dnsmasq es un servidor DNS, TFTP, PXE, publicidad de enrutador y servidor DHCP ligero. Está destinado a proporcionar un servicio de DNS y DHCP acoplado a una LAN.
Entonces, ¿qué significa esta oración? Vamos a buscarla en Google para traducirla:
dnsmasq es un DNS, TFTP, PXE, publicidad de enrutador y servidor DHCP livianos. Tiene como objetivo proporcionar servicios DNS y DHCP acoplados a la red de área local.
Se puede ver que no solo puede proporcionar el servicio DNS, sino también el servicio DHCP Por supuesto, aquí solo necesitamos el servicio DNS.
Tres, las ventajas de dnsmasq
Aquí resumo personalmente algunas de las ventajas de dnsmasq para operaciones tontas:
- Ligero, el tamaño de la imagen es de solo 6 M
- Viene con
vi
yping
herramientas para la prueba fácil - En Mac OS, cargará el archivo / etc / hosts de la máquina host de forma predeterminada, no se necesita ningún montaje adicional
- En Mac OS, rastreará / etc / hosts y se actualizará automáticamente. Puede agregar una nueva resolución de nombre de dominio al / etc / hosts de la máquina host en cualquier momento, y luego estará bien.
- Hay una variedad de OPCIONES para elegir al inicio, y también puede configurarlo después del inicio para satisfacer diferentes necesidades.
Eso sí, tiene muchas ventajas, aquí está su documento de dirección de documento DNSMASQ , puedes leerlo si te interesa.
Cuarto, implemente el servicio DNS
Aquí usamos Docker en lugar de un archivo binario ejecutable para la implementación dnsmasq
.
4.1, extraer dnsmasq
Aquí tiramos andyshinn/dnsmasq
. Aunque el documento sugiere agregar etiquetas, simplemente lo tiramos directamente latest
.
docker pull andyshinn/dnsmasq
4.2, obtenga la IP local
Ejecutar ifconfig
, el sistema Mac tiene una salida similar a la siguiente:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether f0:18:98:2b:a8:1c
inet6 fe80::488:3af:3961:e19c%en0 prefixlen 64 secured scopeid 0x6
inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
inet6 240e:fe:1630:4800:1c0d:41b0:55ce:1427 prefixlen 64 autoconf secured
inet6 240e:fe:1630:4800:a0ea:b052:8ca:bb4b prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
Se puede ver que la IP local es 192.168.1.3
, por supuesto, si está ejecutando en una máquina Mac, también puede encontrar la IP local directamente en la conexión de red.
Hay una salida similar a la siguiente en el sistema Centos:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.202 netmask 255.255.255.0 broadcast 192.168.0.255
ether a2:f3:78:ba:0e:ae txqueuelen 1000 (Ethernet)
RX packets 3257 bytes 385345 (376.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 243 bytes 24432 (23.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Se puede ver que la IP local es 192.168.0.202
.
4.3, inicie dnsmasq
Por razones desconocidas, el rendimiento del sistema operativo Centos y el sistema operativo Mac OS es inconsistente. La siguiente es una introducción por entorno:
4.3.1, sistema Mac OS
Utilice el siguiente comando para iniciar dnsmasq:
docker run -d --restart=always --name dns-server -p 53:53/tcp -p 53:53/udp --cap-add=NET_ADMIN andyshinn/dnsmasq --log-facility=-
docker ps -a
Obtendrá un resultado similar aquí:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
82012eee8714 andyshinn/dnsmasq "dnsmasq -k --log-fa…" 7 seconds ago Up 6 seconds 0.0.0.0:53->53/tcp, 0.0.0.0:53->53/udp dns-server
Esto muestra que nuestro servidor dns se ha iniciado correctamente. Echemos un vistazo a su registro:
docker logs dns-server
Obtendrá un resultado similar aquí:
dnsmasq[1]: started, version 2.81 cachesize 150
dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile
dnsmasq[1]: reading /etc/resolv.conf
dnsmasq[1]: using nameserver 192.168.65.1#53
dnsmasq[1]: read /etc/hosts - 7 addresses
Aquí dnsmasq también tendrá el servidor de resolución de nombres de dominio de nivel superior, aquí está 192.168.65.1, no nos importa, porque aplicamos principalmente a la resolución de nombres de dominio en la ventana acoplable. Esto significa read /etc/hosts - 7 addresses
que etc/hosts
hay siete registros en su contenedor (tenga en cuenta que esta no es la máquina host), y estos siete son generados automáticamente por el sistema. Vamos a ver:
correr:
docker exec -it dns-server /bin/sh
/# cat /etc/hosts
Obtendrá resultados similares:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2 82012eee8714
Salgamos del contenedor primero:
/# exit
4.3.2, sistema Centos
Después de la prueba, por razones desconocidas, aunque no usamos --no-host
parámetros, no podemos /etc/hosts
analizarlo directamente desde la máquina host . Por lo tanto, en comparación con el comando de inicio en Mac OS, debe agregar manualmente un directorio addn-hosts a la configuración.
1. Primero configure el servidor dns externo:
mkdir /usr/share/dnsmasq
cd /usr/share/dnsmasq
vim resolv.conf
# 写入下列阿里云的DNS
nameserver 223.5.5.5
nameserver 223.6.6.6
2. Configure las reglas de resolución local:
Todavía en el directorio / usr / share / dnsmasq:
vim myhosts
# 这里配置自定义解析
127.0.0.1 dns-server1
3. Inicie el servidor dns:
Nota: Después de la prueba, a veces es necesario agregar la dirección IP local en el puerto designado en el entorno de centos, y otras veces no es necesario. La razón aún no se comprende. Para evitar problemas, la dirección IP de la máquina se agrega de manera uniforme.
docker run -d --restart=always --name dns-server1 -p 192.168.0.202:53:53/tcp -p 192.168.0.202:53:53/udp -v /usr/share/dnsmasq:/etc/dnsmasq --cap-add=NET_ADMIN andyshinn/dnsmasq --log-facility=-
docker ps -a
Obtendrá un resultado similar aquí:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ad32ccbe7e06 andyshinn/dnsmasq "dnsmasq -k --log-fa…" 5 seconds ago Up 3 seconds 0.0.0.0:53->53/tcp, 0.0.0.0:53->53/udp dns-server1
Esto muestra que nuestro servidor dns se ha iniciado correctamente. Echemos un vistazo a su registro:
docker logs dns-server1
Obtendrá un resultado similar aquí:
dnsmasq[1]: started, version 2.81 cachesize 150
dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile
dnsmasq[1]: reading /etc/resolv.conf
dnsmasq[1]: using nameserver 8.8.8.8#53
dnsmasq[1]: using nameserver 4.4.4.4#53
dnsmasq[1]: read /etc/hosts - 7 addresses
Tenga en cuenta que esto es diferente del sistema Mac, y su servidor de nombres es un valor común. Pero no es la dirección del servidor de nombres de dominio de Alibaba Cloud que configuramos, porque nuestra configuración de dnsmasq no ha cambiado.
4. Ingrese al contenedor para modificar la configuración
docker exec -it dns-server1 /bin/sh
Debido a que hemos realizado el mapeo de directorios, podemos ver los dos archivos que acabamos de editar en el contenedor:
/ # cd /etc/dnsmasq
/etc/dnsmasq # ls
myhosts resolv.conf
/etc/dnsmasq #
Cambio de configuracion:
vi /etc/dnsmasq.conf
# 修改下述两个配置
resolv-file=/etc/dnsmasq/resolv.conf
addn-hosts=/etc/dnsmasq/myhosts
/# exit
Las sugerencias vim
se pueden /
buscar utilizando las teclas.
5. Reinicie el dns-server1
servicio:
docker restart dns-server1
Cinco, prueba
5.1, extraiga la imagen de prueba
Usamos la busybox
duplicación para las pruebas porque contiene ping
herramientas y solo tiene un tamaño de 1.23M.
Extrae la última versiónbusybox
docker pull busybox
5.2, prueba de ejecución de la ventana acoplable
Podemos usar la ventana acoplable para ejecutar --dns=IP_ADDRESS
agregar servidores DNS al contenedor /etc/resolv.conf
en.
Ejecute el siguiente comando:
docker run --name dns-client -it --dns=192.168.0.202 busybox /bin/sh
/ # cat /etc/resolv.conf
Ingresará al contenedor y mostrará la dirección del servidor de nombres DNS:
nameserver 192.168.0.202
Luego ejecute en el contenedor:
/ # ping peer0.test.example.com
ping: bad address 'peer0.test.example.com'
A partir de los resultados, no podemos analizarlo peer0.test.example.com
.
Abra una nueva terminal y ejecute el siguiente comando para agregar peer0.test.example.com
el análisis en el directorio de análisis de la máquina host :
-
Si es un
centos
sistema operativo, además de/usr/share/dnsmasq/myhosts
agregar registros a la máquina host , también es necesario indicar al servidor dns que vuelva a cargar:echo '127.0.0.1 peer0.test.example.com' >> /usr/share/dnsmasq/myhosts docker kill -s HUP dns-server1
-
Si es un sistema Mac, simplemente agréguelo directamente
/etc/hosts
, peroecho
el método de uso le indicará que no hay permiso ysudo
no funcionará, solo:sudo vim /etc/hosts
Luego seleccione
E
(presione laE
tecla), agregue manualmente al final127.0.0.1 peer0.test.example.com
, y finalmente guarde y salga.
Seguimos busybox
corriendo en el contenedor:
/ # ping peer0.test.example.com
Tiene ping
éxito después de poco tiempo y ctrl + c
se interrumpe cuando hay un mensaje de respuesta . Hay una salida similar a la siguiente:
PING peer0.test.example.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.067 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.093 ms
64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.095 ms
^C
--- peer0.test.example.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.067/0.085/0.095 ms
Por supuesto, también podemos agregar algunas pruebas de reglas de análisis local más.
5.3, prueba de docker-compose
busybox
Luego ejecute en el contenedor para exit
salir del contenedor:
A continuación, retire el busybox
contenedor ahora mismo :
docker rm dns-client
docker ps -a
Como puede ver, actualmente solo existe dns-server1
este contenedor.
Creemos un archivo de configuración de docker-compose docker-compose-dns-client.yaml
como archivo de configuración.
vim docker-compose-dns-client.yaml
El contenido es el siguiente:
# docker-compose-dns-client.yaml
version: '2'
volumes:
dns-client:
networks:
test:
services:
dns-client:
container_name: dns-client
image: busybox:latest
command: tail -f /dev/null
dns:
- 192.168.0.202
networks:
- test
Aquí es donde command: tail -f /dev/null
se ejecutará la función después de que se haya iniciado el contenedor; de lo contrario, la busybox
imagen se cerrará.
Ejecutamos el siguiente comando para iniciar el contenedor:
docker-compose -f ./docker-compose-dns-client.yaml up -d 2>&1
docker ps -a
Como puede ver, nuestro cliente de prueba dns-client
ya se está ejecutando.
Luego ingresamos al contenedor para probar:
docker exec -it dns-client /bin/sh
Nota: Aquí miramos el servidor DNS del contenedor:
/ # cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0
Nota: Puede ver que nameserver
el valor aquí no es la dirección IP local, sino la dirección del servidor DNS interno predeterminado de la ventana acoplable. Esto lo vi en una publicación en la que alguien sugirió que el tipo de red debería configurarse en modo puente en el archivo de configuración de docker-compose, para network_mode: "bridge"
que se convierta en la IP local. Pero debido a que el tipo de red docker-compose es el modo puente por defecto, y alguien respondió más tarde que este DNS proxy
valor ** ** no se puede cambiar (debería ser que la red interna no se puede resolver después del cambio), simplemente dejamos que este nameserver
valor 127.0.0.11
sea.
Después de la prueba, se descubre que no es necesario establecer network_mode
este nameserver
valor, simplemente déjelo ser el valor predeterminado.
Probemos el anterior peer0.test.example.com
, y también lo ctrl + c
interrumpiremos después de obtener la respuesta. Después de una breve espera, el resultado es el siguiente:
/ # ping peer0.test.example.com
PING peer0.test.example.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.069 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.119 ms
64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.095 ms
64 bytes from 127.0.0.1: seq=3 ttl=64 time=0.089 ms
^C
--- peer0.test.example.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.069/0.093/0.119 ms
Probemos otro nombre de dominio peer1.test.example.com
que no existe :
/ # ping peer1.test.example.com
ping: bad address 'peer1.test.example.com'
Se le indicará que no se puede encontrar el nombre.
Después de agregar las reglas de análisis de acuerdo con el método anterior, probamos:
/ # ping peer1.test.example.com
PING peer1.test.example.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.072 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.084 ms
64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.091 ms
^C
--- peer1.test.example.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.072/0.082/0.091 ms
/ #
Como puede ver, ahora se puede analizar correctamente peer1.test.example.com
.
5.4, prueba de LAN
Cambiemos a otra máquina para la prueba de resolución de nombres de dominio.
En 192.168.0.204
efectuar en la máquina docker run
de prueba:
docker run --name dns-client -it --dns=192.168.0.202 busybox /bin/sh
Nota: Debido a que el entorno es diferente, aunque es posible ingresar al contenedor en algunos casos, existen los siguientes consejos:
WARNING: IPv4 forwarding is disabled. Networking will not work.
Esto significa que el reenvío de IPv4 no está habilitado y la red no funcionará. Por lo tanto, ejecutamos para / # exit
salir del contenedor y luego ejecutamos el siguiente comando para eliminar el contenedor de prueba justo ahora y abrir la configuración de reenvío del kernel:
docker stop $(docker ps -a -q) && docker rm $(docker ps -a -q)
vim /etc/sysctl.conf
net.ipv4.ip_forward=1
sysctl -p
Vuelva a docker run
probar:
docker run --name dns-client -it --dns=192.168.0.202 busybox /bin/sh
/ # ping peer0.test.example.com
PING peer0.test.example.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.070 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.091 ms
64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.089 ms
64 bytes from 127.0.0.1: seq=3 ttl=64 time=0.084 ms
^C
--- peer0.test.example.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.070/0.083/0.091 ms
5.5, prueba de servidor dns redundante
5.5.1, implementar un nuevo servidor dns
Siga los pasos para implementar el servicio dns 192.168.0.203
para volver a implementar un dns-server2
contenedor en la máquina .
5.5.2, agregue nuevos dns en la prueba docker-compose
# docker-compose-dns-client.yaml
version: '2'
volumes:
dns-client:
networks:
test:
services:
dns-client:
container_name: dns-client
image: busybox:latest
command: tail -f /dev/null
dns:
- 192.168.0.202
- 192.168.0.203
networks:
- test
5.5.3, prueba normal
192.168.0.204
Realice la prueba de docker-compose con dns recién agregados en la máquina:
docker-compose -f ./docker-compose-dns-client.yaml up -d 2>&1
docker ps -a
docker exec -it dns-client /bin/sh
/ # ping peer0.test.example.com
PING peer0.test.example.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.064 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.061 ms
^C
--- peer0.test.example.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.061/0.062/0.064 ms
5.5.4, cerrardns-server1
202
Ejecutar en la máquina systemctl stop docker
, 204
y luego ping
la prueba de la máquina :
/ # ping peer0.test.example.com
PING peer0.test.example.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.066 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.093 ms
64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.072 ms
64 bytes from 127.0.0.1: seq=3 ttl=64 time=0.101 ms
64 bytes from 127.0.0.1: seq=4 ttl=64 time=0.101 ms
^C
--- peer0.test.example.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.066/0.086/0.101 ms
5.5.5, cerrardns-server2
-
202
Corriendo en la máquinasystemctl start docker
-
203
Corriendo en la máquinasystemctl stop docker
-
204
ping
Prueba en la máquina/ # ping peer0.test.example.com PING peer0.test.example.com (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.068 ms 64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.100 ms 64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.104 ms 64 bytes from 127.0.0.1: seq=3 ttl=64 time=0.093 ms 64 bytes from 127.0.0.1: seq=4 ttl=64 time=0.109 ms 64 bytes from 127.0.0.1: seq=5 ttl=64 time=0.103 ms ^C --- peer0.test.example.com ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 0.068/0.096/0.109 ms
Puede verse en la prueba que se ha logrado el efecto de redundancia. 203
Ejecute en la máquina para systemctl start docker
comenzar de nuevo dns-server2
.
5.6, prueba de firewall predeterminada de centos
En el entorno de Centos, el firewall predeterminado es firewall, verifique, detenga e inicie el estado del firewall
firewall-cmd --state
systemctl stop firewalld.service
systemctl start firewalld.service
Después de la prueba, abrir o cerrar el firewall no afecta la resolución del dns, pero las operaciones de apertura o cierre pueden afectarlo docker
. Si hay un problema en este momento, reinicie la ventana acoplable (tenga en cuenta que no debe reiniciar el contenedor). El comando es systemctl restart docker
.
Seis, resumen
Como software de servidor dns liviano, dnsmasq es bastante conveniente de usar en Mac OS, pero es un poco problemático de usar en Centos. Dado que la red de área local es generalmente una máquina virtual, es decir, Linux, debe prestar atención a los siguientes puntos al usarla (sistema Centos):
- El reenvío de IPV4 debe estar activado.
- Al iniciar dnsmasq, agregue la IP local al puerto especificado y realice la asignación del directorio (archivo) de resolución de dns.
- Después de iniciar dnsmasq, se requieren el servidor dns de nivel superior y configuraciones de resolución de hosts adicionales.
- Al actualizar las reglas de análisis de DSN, simplemente actualice el servidor donde se encuentra el
/usr/share/dnsmasq/myhosts
archivo dns , si es necesario actualizar más de un servidor, la actualización está completa para enviar una señaldocker kill -s HUP <container_name>
de recarga.
Debido al tiempo limitado y la capacidad personal, no leí el documento dnsmasq, pero escribí este artículo basándome en mi propia realidad refiriéndome a varios artículos en Internet. Invitamos a todos a dejar un mensaje para corregir el problema y presentar sugerencias de mejora.