El descubrimiento de servicios no puede obtener una definición adecuada sin el reconocimiento de una red informática existente. Una red informática establece los protocolos de comunicación necesarios para que los dispositivos de red compartan los recursos disponibles a través de sus nodos de red. Este intercambio de recursos involucra tanto dispositivos de red como servicios predefinidos en esa red.
La solución para el descubrimiento o detección automática de estos dispositivos y servicios de red en una red informática es una definición viable de descubrimiento de servicios. Para que se complete el descubrimiento de servicios en una red informática configurada, necesitará la asistencia de un protocolo de red llamado Protocolo de descubrimiento de servicios (SDP). Con estos protocolos, los usuarios y administradores de red no tienen que depender de sus habilidades de configuración de red para que las cosas funcionen.
Dado que el descubrimiento de servicios se comunica con agentes de software en una red informática, sus protocolos de comunicación deben adherirse a un lenguaje de red común para evitar la intervención continua del usuario cada vez que se necesita la ejecución de un paso crítico.
Conceptualización del descubrimiento de servicios en un entorno de producción
Tradicionalmente, el desarrollo de aplicaciones tomaba un enfoque monolítico. Este enfoque se refactorizó más tarde al hacer que existiera una sola aplicación como pequeñas piezas sincronizadas que trabajan hacia un objetivo común. Este concepto define la utilidad de los microservicios en los que los componentes separados trabajan hacia un único objetivo de aplicación. Las aplicaciones SaaS o empresariales son una preferencia para este enfoque de desarrollo de aplicaciones.
Una aplicación definida por componentes pequeños facilita la eliminación de errores e identifica y reemplaza un componente de la aplicación que no es completamente funcional. Debido a que estos componentes son destructibles, implementar dichos componentes en un entorno de producción los vincula con un servicio de red que se identifica con las ubicaciones de los componentes y otros servicios adjuntos a ellos.
Esta configuración automática de instancias de servicio para componentes de aplicaciones de producción desglosa la definición de detección de servicios.
Herramientas populares de descubrimiento de servicios de código abierto para Linux
La evolución de la arquitectura de microservicios y su contribución al desarrollo de aplicaciones modernas ha hecho que el descubrimiento de servicios sea imprescindible. Cuando se implementa un nuevo componente de la aplicación, el descubrimiento del servicio elimina cualquier latencia entre la aplicación y otros puntos finales del servicio. Si considera la posibilidad de facilitar alguna funcionalidad de descubrimiento de servicios a través de microservicios, debe familiarizarse con estas herramientas de código abierto.
Cónsul
Además de cumplir con el objetivo de descubrimiento de servicios, Consul es una herramienta eficaz para monitorear y configurar los ajustes de producción de una red. Crea un almacén de datos peer-to-peer y clústeres dinámicos a través de la biblioteca de Serf. Por este motivo, esta herramienta de descubrimiento de servicios está muy distribuida.
Consul se presenta como un almacén de valores clave para configurar y gestionar un entorno de producción. Serf existe como un protocolo de chismes que administra de manera efectiva cosas como la detección de fallas en los clústeres creados. Un protocolo de consenso maneja la coherencia del sistema en este entorno de producción a través de Raft.
Características principales del cónsul
- Siempre que exista una interfaz de aplicación como MySQL, DNS o HTTP; los servicios pueden registrarse fácil y automáticamente. También es fácil de detectar y encapsular otros servicios externos necesarios para la correcta funcionalidad del entorno de red de configuración.
- Esta herramienta tiene un amplio soporte para la configuración de DNS. Hace que el proceso de integración de DNS sea perfecto.
- Siempre que un clúster de configuración tenga problemas de salud, Consul realizará de manera efectiva una verificación de salud en este clúster y registrará los resultados del diagnóstico en un registro enviado al operador de red correspondiente.
- La función de almacenamiento de clave/valor de Consul es eficaz para marcar funciones y realizar configuraciones dinámicas.
- Esta herramienta funciona con API HTTP para almacenar y recuperar datos de clave/valor definidos y confinados dentro de un almacén de clave/valor distribuido.
Configuración del clúster de Consul
Esta guía tendrá una idea práctica sobre cómo lograr el descubrimiento de servicios a través de un clúster de Consul mediante el uso de múltiples nodos.
Requisitos previos
- Esta configuración será más productiva si tiene acceso a tres servidores Linux.
- Los tres servidores deben tener algunos puertos específicos abiertos. Son 8300 para TCP, 8301 para TCP y UDP, 8302 para TCP y UDP, 8400 para TCP, 8500 para TCP y 8600 para TCP y UDP. Dependiendo de los servidores que esté utilizando, por ejemplo, AWS, GCP o Azure, su firewall y las etiquetas de los grupos de seguridad deben configurarse correctamente para que los puertos mencionados puedan comunicarse fácilmente.
Configuración del clúster de cónsul
Dado que estamos utilizando tres servidores, implementaremos un clúster Consul de tres nodos. Podemos dar a estos nodos los nombres cónsul-1, cónsul-2 y cónsul-3. Los siguientes pasos nos llevarán a un clúster Consul en pleno funcionamiento.
Instalación y configuración de Consul en los tres nodos definidos
Los pasos uno a tres se aplican a todos los nodos Consul definidos.
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
sudo apt-get update && sudo apt-get install consul
Paso 2: Se deben crear los siguientes directorios. Preste atención a las rutas de los directorios.
sudo mkdir -p /etc/consul.d/scripts sudo mkdir /var/consul
Paso 3: De los tres servidores, elija uno y ejecute el siguiente comando en su terminal para crear su secreto de Cónsul. El secreto generado debe guardarse en un archivo de texto.
consul keygen
Paso 4: Los tres servidores deben tener el siguiente archivo de configuración. Créalo como se muestra a continuación.
sudo vi /etc/consul.d/config.json
Rellene el archivo config.json creado anteriormente con los siguientes datos. En este archivo, el valor "cifrar" debe reemplazarse con el valor secreto de Consul que generó en el paso 3. Además, el valor "start_join" debe contener las direcciones IP respectivas de los tres servidores que eligió usar.
{
"bootstrap_expect": 3,
"client_addr": "0.0.0.0",
"datacenter": "Us-Central",
"data_dir": "/var/consul",
"domain": "consul",
"enable_script_checks": true,
"dns_config": {
"enable_truncate": true,
"only_passing": true
},
"enable_syslog": true,
"encrypt": "generated_Consul_key_value",
"leave_on_terminate": true,
"log_level": "INFO",
"rejoin_after_leave": true,
"server": true,
"start_join": [
"server-1_IP",
"server-2_IP",
"server-3_IP"
],
"ui": true
} Creación del servicio Cónsul
Todos nuestros tres nodos o servidores deben pasar por los siguientes pasos.
sudo vi /etc/systemd/system/consul.service
Después de crear el archivo, rellénelo con los siguientes datos.
[Unit] Description=Consul Startup process After=network.target [Service] Type=simple ExecStart=/bin/bash -c '/usr/local/bin/consul agent -config-dir /etc/consul.d/' TimeoutStartSec=0 [Install] WantedBy=default.target
sudo systemctl daemon-reload
Arranque e inicio del clúster
Para iniciar el servicio Consul en el primer servidor o consul-1, ejecute el siguiente comando en su terminal.
sudo systemctl start consul
Para iniciar el servicio Consul en los otros dos servidores, consul-2 y consul-3, debe ejecutar el mismo comando en sus respectivos terminales del sistema operativo.
sudo systemctl start consul
En cada uno de los tres servidores, podrá observar sus respectivos estados de clúster ejecutando el siguiente comando en cada uno de sus terminales.
/usr/local/bin/consul members
Para saber si la configuración de su clúster Consul fue un éxito, el resultado que recibe al ejecutar el comando anterior debe tener algunas similitudes con el siguiente.
[fosslinux@consul-1 ~]$ /usr/local/bin/consul members Node Address Status Type Build Protocol DC Segment consul-1 10.128.0.7:8301 alive server 1.2.0 2 us-central <all> consul-2 10.128.0.8:8301 alive server 1.2.0 2 us-central <all> consul-3 10.128.0.9:8301 alive server 1.2.0 2 us-central <all>
Acceso a la interfaz de usuario de Cónsul
Si su versión de Consul instalada es 1.20 o posterior, está empaquetada con un componente de interfaz de usuario de Consul incorporado. Esta interfaz de usuario de Consul está basada en la web y acceder a ella en su navegador requiere que cumpla con la siguiente regla de sintaxis de URL.
http://<your-consul-server-IP-address>:8500/ui
Un ejemplo de implementación de la regla de sintaxis de URL anterior será algo similar a lo siguiente:
http://46.129.162.98:8500/ui
Practicidad de Cónsul
La desventaja de usar Consul es cuando se trata de las complejidades inherentes de los sistemas distribuidos configurados con él. Este problema es general y depende de la arquitectura de estos sistemas. No tiene nada que ver con el aspecto de desempeño del Cónsul.
Otra ventaja de trabajar con Consul es que tiene todas las bibliotecas necesarias, por lo que no es necesario que los usuarios definan y utilicen bibliotecas de terceros. Podemos comparar la conceptualización de Consul con el OSS Sidecar de Netflix. Aquí, los clientes que no son de Zookeeper siguen siendo detectables, ya que pueden registrarse en el sistema.
La importancia de la herramienta de descubrimiento de servicios Consul ha atraído a empresas de renombre como SendGrid, Percolate, DigitalOcean, Outbrain y EverythingMe.
Etc.
La herramienta de descubrimiento de servicios Etcd ofrece una funcionalidad de almacenamiento de claves/valores similar a la descrita en Consul y Zookeeper. Solía ser un componente clave de CoreOS antes del estado de obsolescencia del sistema operativo. El lenguaje de programación Go fue clave en su desarrollo. También utiliza Raft como un medio para gestionar protocolos de consenso.
Es rápido y confiable en la provisión de API basadas en JSON y HTTP. Esta disposición funcional se complementa aún más con consultas y notificaciones push. En un entorno práctico, el clúster definido o creado albergará cinco o siete nodos. Además del descubrimiento de servicios, las arquitecturas de microservicios que implementan Etcd en sus contenedores también se beneficiarán del registro de estos servicios.
Bajo el registro del servicio, Etcd maneja la escritura del par clave-valor necesario. Bajo el descubrimiento de servicios, Etcd maneja la lectura del par clave-valor creado.
Para que otras aplicaciones creadas se comuniquen con Etcd, deben adherirse a un protocolo de proyecto confd. Este protocolo crea archivos de configuración estáticos a partir de la información almacenada de Etcd. En este entorno, es responsabilidad de los clientes administrar cualquier falla de conexión viable y crear una reconexión a través de otras instancias de servicio viables.
Las empresas de alto perfil que tienen Etcd en su currículum incluyen CloudGear, Headspace, Red Hat, Kubernetes, Apptus, Zenreach, Cloud Foundry y Google. El creciente apoyo de la comunidad de Etcd está mejorando la experiencia de los desarrolladores en la plataforma de esta herramienta de descubrimiento de servicios.
Configuración de Etcd
La capacidad de Etcd para almacenar y recuperar configuraciones no es su única característica principal como almacén de clave-valor de código abierto. Los clústeres de Etcd creados tienen problemas mínimos de fallas de nodos debido a su alta disponibilidad. Los clientes recuperan sus valores almacenados a través de REST/gRPC.
Requisitos
Los siguientes requisitos harán que su experiencia en la configuración del clúster de Etcd sea más fructífera.
- Tener acceso a tres servidores Linux funcionales
- Sus tres opciones de servidor deben configurarse con nombres de host válidos.
- Para una comunicación eficaz entre pares y solicitudes de clientes, los puertos 2380 y 2379 en sus servidores deben estar habilitados desde las reglas de firewall del sistema.
Configuración del clúster de Etcd en su máquina Linux
La configuración del clúster de Etcd no debería causarle dolores de cabeza, ya que es relativamente sencilla, especialmente con el enfoque de arranque estático. Para que pueda arrancar con éxito con este enfoque, debe memorizar las direcciones IP de su nodo. Esta guía de configuración cubrirá todos los pasos que podría necesitar para crear con éxito clústeres de servidores Linux, ya que se trata de una configuración de varios nodos.
Para que etcd se ejecute como un servicio, también necesitaremos configurar archivos systemd. El siguiente es solo un ejemplo de la relación de nombre de host a dirección IP mencionada que usaremos en esta guía de configuración.
etcd-1 : 10.128.0.7 etcd-2 : 10.128.0.8 etcd-3 : 10.128.0.9
Si tiene el privilegio administrativo necesario, puede cambiar los nombres de host de sus servidores para reflejar sus preferencias personalizables.
Es hora de continuar con la configuración del clúster etcd.
Los tres nodos
Los siguientes pasos sucesivos se aplican a los tres nodos de servidor.
cd /usr/local/src
sudo wget "https://github.com/coreos/etcd/releases/download/v3.3.9/etcd-v3.3.9-linux-amd64.tar.gz"
Paso 3: En este paso, descomprimiremos el binario etcd descargado.
sudo tar -xvf etcd-v3.3.9-linux-amd64.tar.gz
sudo mv etcd-v3.3.9-linux-amd64/etcd* /usr/local/bin/
sudo mkdir -p /etc/etcd /var/lib/etcd groupadd -f -g 1501 etcd useradd -c "etcd user" -d /var/lib/etcd -s /bin/false -g etcd -u 1501 etcd chown -R etcd:etcd /var/lib/etcd
Paso 6: Asegúrese de tener privilegios de usuario raíz mientras realiza las siguientes acciones.
ETCD_HOST_IP=$(ip addr show eth0 | grep "inet\b" | awk '{print $2}' | cut -d/ -f1)
ETCD_NAME=$(hostname -s) La secuencia de comandos anterior establece dos variables de entorno. La primera variable de entorno obtiene la dirección IP del servidor y la segunda asocia esa dirección IP con un nombre de host.
Etcd ahora necesita un archivo de servicio systemd.
cat << EOF > /lib/systemd/system/etcd.service
Después de crear este archivo de servicio, rellénelo para que se vea similar al siguiente.
[Unit]
Description=etcd service
Documentation=https://github.com/etcd-io/etcd
[Service]
User=etcd
Type=notify
ExecStart=/usr/local/bin/etcd \\
--name ${ETCD_NAME} \\
--data-dir /var/lib/etcd \\
--initial-advertise-peer-urls http://${ETCD_HOST_IP}:2380 \\
--listen-peer-urls http://${ETCD_HOST_IP}:2380 \\
--listen-client-urls http://${ETCD_HOST_IP}:2379,http://127.0.0.1:2379 \\
--advertise-client-urls http://${ETCD_HOST_IP}:2379 \\
--initial-cluster-token etcd-cluster-1 \\
--initial-cluster etcd-1=http://10.142.0.7:2380,etcd-2=http://10.142.0.8:2380,etcd-3=http://10.142.0.9:2380 \\
--initial-cluster-state new \\
--heartbeat-interval 1000 \\
--election-timeout 5000
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF La parte "-listen-client-urls" de este archivo debe reemplazarse con las tres IP del servidor utilizadas. Dependiendo de los servidores de configuración, los valores de “–name”, “–listen-peer-urls”, “–initial-advertise-peer-urls” y “–listen-client-urls” serán diferentes. En cuanto a las variables ETCD_HOST_IP y ETCD_NAME, sus valores de entrada son automatizados y reemplazados por el sistema.
Clúster etcd de arranque
Las configuraciones anteriores de los pasos 1 a 6 deben aplicarse a los tres servidores. Posteriormente, el siguiente paso será iniciar y habilitar el servicio etcd que acabamos de crear. Este esfuerzo debe aplicarse a los tres nodos. El servidor 1 asumirá la funcionalidad de un nodo de arranque. Una vez que el servicio etcd esté en funcionamiento, seleccionará automáticamente un nodo como líder. Por lo tanto, no tiene que preocuparse por participar en la configuración de este nodo líder.
systemctl daemon-reload systemctl enable etcd systemctl start etcd.service systemctl status -l etcd.service
Verificación del estado del clúster de Etcd
La utilidad etcdctl que extrajimos anteriormente después de descargar el binario etcd es responsable de iniciar la interacción con el clúster etcd. Los tres nodos deben tener esta utilidad en el directorio /usr/local/bin.
Las siguientes comprobaciones del sistema se aplican a todos los nodos del clúster y no se limitan a uno específico. La primera verificación es determinar el estado de salud de su clúster.
etcdctl cluster-health
También puede verificar y verificar el estado de membresía de un nodo de clúster para determinar si tiene el estado de liderazgo.
etcdctl member list
De forma predeterminada, accederá explícitamente a las funcionalidades de etcd v2 a través de etcdctl. Es su asociación por defecto. Si desea acceder a etcd v3 y sus funcionalidades, utilizar la variable “ETCDCTL_API=3” es una opción viable. Para implementar esta variable, configúrela como una variable de entorno. Alternativamente, puede pasar la variable cada vez que use el comando etcdctl.
Intente crear y verificar los siguientes pares clave-valor.
ETCDCTL_API=3 etcdctl put name5 apple ETCDCTL_API=3 etcdctl put name6 banana ETCDCTL_API=3 etcdctl put name7 orange ETCDCTL_API=3 etcdctl put name8 mango
Para acceder al valor de name7, ejecute el siguiente comando.
ETCDCTL_API=3 etcdctl get name7
Mediante el uso de rangos y prefijos, es posible enumerar todas las claves como se muestra a continuación:
ETCDCTL_API=3 etcdctl get name5 name8 # lists range name5 to name8 ETCDCTL_API=3 etcdctl get --prefix name # lists all keys with name prefix
Guardián Apache
Este servicio se puede describir como centralizado, distribuido y consistente. El lenguaje de programación Java es el responsable de su creación. Apache Zookeeper puede gestionar eficazmente los cambios de clúster a través del protocolo Zab. Su función anterior era mantener los componentes del clúster de software en el mundo de Apache Hadoop.
Aquí, el almacenamiento de datos está en un árbol, dentro de un sistema de archivos o en un espacio de nombres jerárquico. Cuando un cliente se conecta a esta red, los nodos seguirán existiendo. Por otro lado, cuando se produce la desconexión de la red o hay algún problema con la red configurada, los nodos desaparecen. Cuando ocurre un problema con la falla de la red o el equilibrio de carga, depende de los clientes resolverlo. Cuando Apache Zookeeper registra un nuevo servicio, los clientes reciben notificaciones relacionadas con estos servicios.
La consistencia del sistema Zookeeper no lo protege de posibles fallas del sistema. Algunas plataformas pueden tener problemas para registrar los servicios necesarios o incluso tener errores al implementar las funciones de servicio de lectura y escritura. Por otro lado, Apache Zookeeper continúa siendo una aplicación robusta y establecida con un amplio soporte de biblioteca que beneficia a su vibrante comunidad de usuarios y a sus crecientes clientes.
Las empresas de alto perfil que se asocian con Apache Zookeeper incluyen Apache Software Foundation, Luxoft, Solr, Reddit, Rackspace, Spero Solutions, F5 Networks, Cloudera, eBay y Yahoo!
Configuración de Apache Zookeeper
Apache Zookeeper es perfecto para manejar varias cargas de trabajo distribuidas debido a su adaptación funcional como herramienta de coordinación distribuida.
Requisitos previos
- Necesita tres máquinas virtuales (VM). La cantidad de máquinas virtuales a usar puede ser superior a 3, pero esa cantidad debe ser impar para el clúster de alta disponibilidad.
- Los puertos 2181, 2888 y 3888 deben habilitarse a través de las IPtables del sistema del servidor para que las conexiones entrantes de las VM se realicen a través de estos puertos. Estos puertos son responsables de la comunicación de Apache Zookeeper.
Las personas que trabajan con proveedores de la nube como AWS deben tener puntos finales o grupos de seguridad habilitados para que Apache Zookeeper funcione con estos puertos.
La instalación y configuración de Apache Zookeeper
Las tres máquinas virtuales deberían beneficiarse de los siguientes pasos:
sudo yum -y update
sudo yum -y install java-1.7.0-openjdk
Paso 3: Utilice el comando "wget" para descargar Zookeeper.
wget http://mirror.fibergrid.in/apache/zookeeper/zookeeper-3.5.2-alpha/zookeeper-3.5.2-alpha.tar.gz
sudo tar -xf zookeeper-3.5.2-alpha.tar.gz -C /opt/
cd /opt
sudo mv zookeeper-* zookeeper
Paso 6: Dentro del directorio /opt/zookeeper/conf, necesitaremos trabajar con un archivo llamado zoo.cfg. Cree este archivo y rellénelo con los siguientes datos de configuración.
tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 initLimit=5 syncLimit=2 server.1=<ZooKeeper_IP/hostname>:2888:3888 server.2=<ZooKeeper_iP/hostname>:2888:3888 server.3=<ZooKeeper_iP/hostname>:2888:3888
Sus tres servidores de Zookeeper están representados por el Servidor 1, el servidor 2 y el servidor 3. La variable "ZooKeeper_IP" debe reemplazarse con las direcciones IP de sus tres servidores o los nombres de host resolubles de estas direcciones IP identificables.
Paso 7: El archivo zoo.cfg que creamos y completamos apunta a un directorio de datos llamado lib, que también contiene otro directorio llamado zookeeper. Necesitamos crear este directorio ya que aún no existe.
sudo mkdir /var/lib/zookeeper
Paso 8: Dentro del directorio creado anteriormente, cree un archivo myid.
sudo touch /var/lib/zookeeper/myid
Paso 9: Este archivo myid contendrá números únicos para identificar cada servidor Apache Zookeeper.
Para el servidor Zookeeper 1
sudo sh -c "echo '5' > /var/lib/zookeeper/myid"
Para el servidor Zookeeper 2
sudo sh -c "echo '6' > /var/lib/zookeeper/myid"
Para el servidor Zookeeper 3
sudo sh -c "echo '7' > /var/lib/zookeeper/myid"
Configuraciones del servicio Apache Zookeeper
Para iniciar y detener Zookeeper, necesitaremos utilizar scripts. Sin embargo, ejecutar estos scripts como un servicio ayuda a administrarlos mejor. Tendremos que abrir el archivo zkServer.sh.
sudo vi /opt/zookeeper/bin/zkServer.sh
El archivo abierto debajo de “#!/usr/bin/env” lo llena con los siguientes datos.
# description: Zookeeper Start Stop Restart # processname: zookeeper # chkconfig: 244 30 80
En el mismo archivo zkServer.sh, rastree el "#use POSTIX interface, symlink..." en vivo. Reemplace y sustituya las variables que suceden a esa línea con estos valores.
ZOOSH=`readlink $0` ZOOBIN=`dirname $ZOOSH` ZOOBINDIR=`cd $ZOOBIN; pwd` ZOO_LOG_DIR=`echo $ZOOBIN`
El servicio Zookeeper ahora necesita un enlace simbólico.
sudo ln -s /opt/zookeeper/bin/zkServer.sh /etc/init.d/zookeeper
El menú de inicio debe adaptarse a Zookeeper.
sudo chkconfig zookeeper on
Los tres servidores deben reiniciarse con el siguiente comando. Ejecútelo en sus respectivos terminales.
sudo init 6
Una vez que los servidores se hayan reiniciado, administrarlos será sencillo a través de las siguientes secuencias de comandos.
sudo service zookeeper status sudo service zookeeper stop sudo service zookeeper start sudo service zookeeper restart
Cuando se ejecuta el comando para verificar el estado de Zookeeper, la salida del terminal debe ser similar a la siguiente.
/bin/java ZooKeeper JMX enabled by default Using config: /opt/zookeeper/bin/../conf/zoo.cfg Client port found: 2181. Client address: localhost. Mode: leader
A uno de los tres servidores se le asigna el modo líder y los otros dos conservan el modo seguidor.
Nota final
El descubrimiento de servicios tiene dos objetivos importantes:alta disponibilidad y detección de fallas. Con más funcionalidades en espera, una implementación de infraestructura no puede estar completa sin reconocer y configurar herramientas de descubrimiento de servicios como Consul, Etcd y Apache Zookeeper. Estas herramientas son de código abierto y fundamentalmente efectivas en sus funcionalidades de prestación de servicios. Por lo tanto, no se topará con ningún muro al intentar probar o implementar un mecanismo simple de detección de servicios en sus sistemas Linux.