Archivo

Posts Tagged ‘seguridad elasticsearch’

Seguridad en ElasticSearch: modo cluster – Parte IV

septiembre 16, 2019 1 comentario

En el post anterior ya se ha hablado sobre algunas características avanzadas para la búsqueda de contenidos en ES, ahora es el momento de hablar sobre la configuración necesaria en ES para que funcione en modo cluster. En primer lugar hay que mencionar que cuando se inicia una instancia de ES, lo primero que hace es intentar unirse a un cluster si se han indicado los detalles en dicho cluster en la configuración, en el caso de que no sea así, se entiende que el nodo funcionará en modo “standalone” y en tal caso, creará un cluster en donde es la propia instancia la que funciona como “master”.

Configuración modo “cluster” con múltiples nodos.

La configuración en modo cluster de ES con múltiples nodos es considerada como una configuración para un entorno de producción. Esto significa que en primer lugar, la instancia de ES ya no se ejecutará únicamente en la interfaz de loopback como se ha visto hasta ahora, sino que evidentemente, debe estar disponible y alcanzable por otros nodos/instancias que harán parte del cluster. La configuración de todas las instancias de ES giran en torno al fichero “elasticsearch.yml” para cuestiones concretas de la instancia y otros ficheros como el “jvm.option” y “log4j2.properties”  para asignar valores de configuración a la VM de Java, evidentemente se trata de una labor de vital importancia para el tuning de una máquina virtual y el correcto funcionamiento de la instancia, pero se sale un poco del scope de estos post. Todos estos ficheros, así como el keystore y certificado de la instancia se encuentran en el directorio “config”.

ES normalmente requiere muy poca configuración y prácticamente todos los cambios se pueden realizar en caliente gracias a la API disponible en el motor, excepto la configuración en modo cluster, de hecho, si se ha iniciado una instancia con sus valores por defecto se creará un directorio llamado “data” el cual contiene toda la información de los nodos vinculados al cluster. Si se inicia una instancia de ES con la configuración por defecto y luego, se plantea integrar dicha instancia en un cluster existente, es importante tener en cuenta que no solamente será necesario editar el fichero de configuración como se explicará a continuación, sino que además se debe eliminar el directorio “data” para que la instancia comprenda que ahora no es el “master” de un cluster local, sino que se unirá a un cluster existe. Esto último es importante, ya que en el caso de no hacerlo se producirán errores en el arranque aunque la configuración sea correcta.

Ahora bien, los valores de configuración mínimos que se deben indicar en el fichero de “elasticsearch.yml” son los siguientes:

cluster.name: Nombre que tiene el cluster al que la instancia se unirá.
node.name: Nombre del nodo.
cluster.initial_master_nodes: Se trata de las direcciones IP o nombres de dominio de uno o varios nodos “master” del cluster objetivo.
transport.host: Interfaz de red o dirección IP utilizada internamente por los nodos del cluster para la comunicación. Por ejemplo, esta dirección junto con el puerto indicado en “transport.tcp.port” son utilizados por otros nodos en el cluster para las replicas de shards.
transport.tcp.port: Puerto que se abrirá en la interfaz indicada en “transport.host”.
http.host: Interfaz de red sobre la que se servirá la API rest de la instancia (por defecto es localhost).
http.port: Puerto vinculado a la interfaz indicada con la propiedad “http.host” (por defecto es 9200).
network.host: Interfaz de red a la que se vinculará el servicio de conexión de la instancia. Es decir, la interfaz de red sobre la que otros nodos del cluster se conectarán con la instancia local.
node.master: Valor booleano que indica si la instancia es master o no del cluster.

Esto es lo mínimo que debe de existir en un fichero de configuración de ES para que funcione en modo cluster con otros nodos, sin embargo hay muchas más opciones de configuración que se pueden consultar en la documentación oficial. https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html

Una configuración valida podría ser la siguiente:

Nodo master:

cluster.name: cluster-adastra
node.name: adastra-1
transport.host: 0.0.0.0
http.host: 0.0.0.0
network.host: 0.0.0.0
transport.tcp.port: 9300
node.master: true

Nodo slave1:

cluster.name: cluster-adastra
node.name: slave1-node
discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master.
cluster.initial_master_nodes: [“adastra-1”]
transport.host: 0.0.0.0
http.host: 0.0.0.0
network.host: 0.0.0.0
transport.tcp.port: 9300
node.master: false

Nodo slave2:

cluster.name: cluster-adastra
node.name: slave2-node
discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master.
cluster.initial_master_nodes: [“adastra-1”]
transport.host: 0.0.0.0
http.host: 0.0.0.0
network.host: 0.0.0.0
transport.tcp.port: 9300
node.master: false

Esto se puede ejecutar desde un mismo ordenador con 3 instancias independientes de ES, con máquinas virtuales, contenedores de Docker o máquinas físicas. No obstante aquí no termina la configuración, cuando se utiliza la propiedad “network.host” con un valor distinto de la interfaz de loopback provoca que ES ejecute una serie de comprobaciones sobre el sistema llamadas “bootstrap checks” las cuales se encargan de verificar que el sistema cumple con las especificaciones mínimas para que el nodo funcione correctamente en un entorno productivo y de esta manera reducir los problemas que puedan tener los usuarios al interactuar con nodos configurados “de aquella manera”. La configuración del sistema que se debe de aplicar para cumplir con los requisitos se explica en la documentación oficial: https://www.elastic.co/guide/en/elasticsearch/reference/current/system-config.html

En este apartado la documentación está bien detallada y explica qué se debe hacer a nivel de sistema para que el nodo arranque correctamente y se una a un cluster existente o funcione como master.

Como se puede apreciar en la imagen anterior, cuando existe cualquier tipo de problema en la instancia relacionada con los “bootstrap checks” la instancia simplemente no arranca. Sin embargo es algo fácil de resolver si se siguen las indicaciones que arroja la instancia de ES.

En esta última imagen se puede ver cómo debe de ser una configuración “buena” para el nodo que actuará como master, como se puede ver se han pasado todas las comprobaciones iniciales y posteriormente, se ha elegido al nodo “adastra-1” como master ya que es la forma en la que se ha indicado en la configuración gracias a la propiedad “node.master: true”.

De momento, con lo que se ha visto en éste post en las partes 1 , 2 y 3 es suficiente para comenzar a abordar cuestiones relacionadas con el pestesting y securización sobre instancias de ES.

Un saludo y Happy Hack.
Adastra.

Seguridad en ElasticSearch: búsquedas avanzadas y operaciones sobre índices – Parte III

septiembre 9, 2019 1 comentario

En el post anterior se ha hablado sobre como crear y gestionar índices así como la forma de realizar búsquedas con el endpoint “_search”, lo cual es el punto de entrada para comprender el funcionamiento de ES. Probablemente las características más complejas de este producto están precisamente relacionadas con las búsquedas, ya que como se verá en este post, existen varias maneras de aplicar filtros sobre índices y documentos.

En primer lugar, el endpoint “_search” no solamente admite peticiones GET, también es posible ejecutar una petición POST y en el cuerpo de la petición enviar filtros un poco más específicos que los que se podrían incluir en una petición GET. Por ejemplo:

POST /indice/tipo/_search
{ “query”: { “match”: { “title”: {
“query”: “palabra1 palabra2”,
“operator”: “and”}
}
}

“size”: 2,
“from”: 0,
“_source”: [ “campo1”, “campo2”, “campo3” ],
“highlight”: { “fields” : { “title” : {} } }
}

Se trata de una búsqueda más compleja, en la que se incluye el campo “query” que a su vez admite una estructura muy concreta para realizar la búsqueda. Con “match” se especifican los filtros, que en este caso aplican únicamente al campo “title”, es decir, que todos los documentos que tengan dicho campo serán objeto de búsqueda. Luego, se repite nuevamente el campo “query” pero en esta ocasión será útil para indicar un texto libre. Es posible utilizar operadores como “or” y “and”, de tal manera que dicha operación lógica se aplicará sobre las palabras especificadas en el campo “query”. En el ejemplo anterior, al aplicar el operador “and”, significa que la búsqueda devolverá solamente aquellos documentos que tenga en el campo “title” las palabras “palabra1” y “palabra2”. Luego, se puede apreciar en el cuerpo de la petición otros campos adicionales, tales como “size” y “from”, los cuales permiten devolver resultados en bloques, algo ideal para implementar búsquedas paginadas. Finalmente, los campos “_source” y “highlight” sirven para indicar aquellos campos del documento que devolverá la búsqueda, en este caso “campo1”, “campo2” y “campo3”. Si el documento tiene más campos estos no son incluidos en los resultado de la búsqueda.

El resultado de una búsqueda como la anterior es una estructura en formato JSON que contiene algunos campos interesantes, como por ejemplo “_source” y “score”. En el caso del primero, se trata de la estructura JSON con los resultados de la búsqueda, es decir, todos los documentos que han coincidido con los filtros especificados y el segundo, es el factor de coincidencia y es aquí en donde ES se complica un poco más, ya que ES internamente realiza una serie de calculos para asignar a cada resultado de las búsquedas un valor de coincidencia, esto es un indicativo que permite ubicar cada documento en un orden concreto en el listado de resultados. Pensad por ejemplo en Google, los enlaces a páginas externas que arroja cada búsqueda enseñan en las primeras posiciones aquellos que tienen mejor page rank, aquellos que pueden ser más interesantes para el usuario. ES hace lo mismo partiendo de los filtros que se incluyen en las búsquedas. Por ejemplo, en el caso anterior, cuantas más veces aparezca en un documento las palabras “palabra1” y “palabra2”, el documento tendrá mejor score y por lo tanto aparecerá en mejores posiciones dentro del resultado de la búsqueda. En la documentación oficial de ES podéis ver algunos ejemplos de búsquedas de este tipo para que quede un poco más claro, aunque desafortunadamente en mi opinión, la documentación oficial de ES es una de las más escuetas, poco claras y con más errores que me he encontrado hasta ahora en un producto de software, desafortunadamente es lo que hay y muchas veces toca pegarse con el producto para aprender realmente cómo funciona y ver las cosas que han cambiado, que ya no funcionan o que funcionan de forma diferente entre diferentes versiones. Los siguientes enlaces pueden ser útiles:

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html

Por otro lado, algunos de los campos que se han incluido en el cuerpo de la petición (los más simples) también se pueden incluir como parámetros en la URL del endpoint “_search”, por ejemplo:

GET /_search?size=5
Enseña los 5 primeros resultados de la búsqueda.

GET /_search?size=5&from=5
Enseña los resultados del 5 al 10.

GET /_search?size=5&from=10
Enseña los resultados del 5 al 15.

como se ha explicado anteriormente, ES se encarga ordenar los resultados de las consultas antes devolverlos basándose en el campo “_score”, por lo tanto es común y recomendable utilizar los mecanismos de paginación para evitar problemas de rendimiento en las consultas.

Operaciones sobre índices y documentos.

Es importante conocer la forma en la que ElasticSearch interpreta los documentos almacenados en un índice concreto, ya que es posible que algunos de los campos no contengan la estructura esperada, tal como se ha visto en el post anterior a este, es posible crear documentos que no siguen ninguna estructura referente a los campos. Para ver el “mapeo” que tienen los documentos (parecido a la definición de una tabla en una base de datos relacional) es necesario utilizar el endpoint “_mapping” disponible en el índice.

GET /index/_mapping

A la hora de crear un índice es posible incluir el campo “mappings” y especificar cómo será la estructura de los campos que podrán ser heredados por los documentos creados en el índice, por ejemplo:

PUT my_index

{ “mappings”: { “properties”: {
“campo”: { “type”: “keyword”}
}}}

Es recomendable echarle un vistazo a lo que se explica en la documentación oficial sobre los mapeos en índices: https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-params.html

Los índices pueden estar abiertos o cerrados, lo que significa que es posible trabajar  con ellos para operaciones de lectura/escritura o no. No es posible indexar documentos o realizar búsquedas sobre índices cerrados. Cuando un índice está cerrado, ES no mantiene las estructuras de datos internas para la búsqueda, es decir, los documentos no se indexan y por lo tanto, el consumo de memoria es menor. No obstante, dependiendo del tamaño de los documentos de dicho índice, un índice cerrado puede suponer un consumo considerable de disco duro ya que como resulta evidente, la información de dichos documentos se debe guardar de forma persistentemente en disco en el caso de que el índice se abra nuevamente. Abrir o cerrar un índice es muy sencillo tal como se muestra a continuación. (obviamente, “my_index” corresponde al nombre del índice).

* Abrir un índice: POST /my_index/_open
* Cerrar un índice: POST /my_index/_close

Alias sobre índices.

Una forma rápida y sencilla de obtener todos los índices disponibles en ES es por medio del endpoint “_aliases” el cual devuelve un listado de todos los alias disponibles para cada uno de los índices. Con este endpoint también es posible crear o eliminar alias (etiquetas) sobre los índices creados.

POST /_aliases {
“actions” : [ { “add” : { “index” : “test1”, “alias” : “alias1” } },
{ “remove” : { “index” : “test1”, “alias” : “alias2” } } ] }

En el caso anterior, las acciones utilizadas son “add” y “remove”. Se ha creado un alias el nombre “alias1” sobre el indice “test1” y además, se ha eliminado el alias “alias2” sobre el índice “test1”. Un índice puede tener múltiples “alias” sin que esto afecte a los documentos o estructura del índice.
Probablemente una de las características más potentes de los alias es que permiten crear vistas sobre los índices partiendo de los filtros, por ejemplo:

POST /_aliases {
“actions” : [ {“add” : {“index” : “test1”, “alias” : “alias2”,
“filter” : { “term” : { “campo” : “valor” } } } } ] }

Como se puede apreciar, se ha creado un alias con nombre “alias2” sobre el índice “test1”. Cuando se intente consultar dicho alias, ES aplicará el filtro indicado en el campo “filter” y devolverá los documentos que coincidan con la búsqueda. Esto en el mundo de las bases de datos relacionales es similar a las vistas, lo cual simplifica mucho las consultas que se pueden realizar contra un índice concreto. Para consultar el alias, se accede directamente al endpoint “_search”, por ejemplo:

GET /alias1/_search
GET /alias2/_search

Al realizar una petición como la anterior ES se encargará de buscar dicho alias, ver el índice al que apunta y si hay algún filtro, aplicarlo.

Los alias también se pueden utilizar como vistas de escritura, es decir, una forma de simplificar la creación de documentos con el atributo “is_write_index”.

POST /_aliases
{ “actions” : [
{ “add” : {“index” : “test”, “alias” : “alias1”, “is_write_index” : true } }
]}

Como se puede apreciar, para crear un alias en modo escritura, basta simplemente con incluir el campo “is_write_index” con el valor “true” a la hora de crearlo. Para utilizar el índice en modo de escritura se podrá realizar una petición POST o PUT de la siguiente forma.

PUT /alias1/_doc/1
{
“campo”: “valor”
}

En donde “_doc” es un endpoint que le permite a ES saber que se intenta acceder a la estructura de documentos que se encuentran almacenados en el índice al que apunta el alias “alias1”, luego en el cuerpo de la petición viene el JSON con el documento propiamente dicho.

Consultas interesantes en ES

Antes de finalizar este post, es conveniente conocer algunos de los endpoints disponibles en el producto para realizar consultas directas sobre el estado del nodo o cluster. Para ello existen varios endpoints interesantes que son muy sencillos y aportan información valiosa. Por ejemplo:

GET /_cat/master?v
GET /_cat/nodes?v
GET /_cat/indices?v
GET /_cat/plugins?v
GET /_cat/shards?v
GET /_cat/health?v
GET /_cat/master?help
GET /_nodes/node1,node2
GET /_nodes/process
GET /_nodes/_all/process
GET /_nodes/node1,node2/jvm,process
GET /_nodes/plugins
GET /_nodes/stats/indices
GET /_nodes/stats/os,process
GET /_nodes/192.168.1.101/stats/process
GET /_nodes/usage
GET /_nodes/nodeId1,nodeId2/usage
GET /_nodes/hot_threads

Son peticiones fáciles de entender y que permiten extraer información relevante sobre una instancia de ES en ejecución, de hecho, complementos como “cerebro”, “elasticsearch-HQ” o el propio Kibana hacen uso de estos endpoints de forma directa para enseñar la información en un formato amigable para el usuario.

En el próximo artículo de la serie se hablará sobre configuración de una instancia de ES y algunas consideraciones de seguridad que se entenderán mucho mejor después de haber leído la parte 1 y la parte 2 de la serie.

Un saludo y Happy Hack.
Adastra.

Seguridad en ElasticSearch: Indices y búsquedas – Parte II

agosto 25, 2019 3 comentarios

En la primera parte de esta serie se han explicado las características funcionales incluidas en ES y los diferentes mecanismos de instalación. Ahora es el momento de comprender cómo funciona ES a la hora de crear índices, tipos y documentos, así como los endpoints disponibles en la API Rest para realizar búsquedas. La API Rest de ES es extensa y compleja, por lo tanto en estos posts solo se intentará cubrir las cuestiones relacionadas con la forma de realizar búsquedas, configuración de nodos/clusters, así como algunos complementos y medidas que pueden ayudar a mejorar la seguridad de una instancia de ES.

En primer lugar, hay que tener en cuenta que ES es bastante parecido a otros gestores de bases de datos no relacionales como MongoDB, especialmente en el sentido de que no hay una estructura fija. Esto significa que a diferencia de una base de datos relacional con tablas, las cuales están compuestas por un conjunto de columnas con restricciones en tipos de datos, relaciones con otras tablas (claves foráneas), longitudes, campos obligatorios, etc. En ES este tipo de estructuras y jerarquías a la hora de almacenar información son un poco diferentes. Para que esta idea quede clara, se expone el siguiente ejemplo:
En una base de datos relacional, se podría crear una tabla de usuarios, la cual estará compuesta por campos tales como: “nombre”, ”edad”, “genero”, “rol” y “fechaNacimiento”. A la hora de realizar una inserción de un registro en dicha tabla, se debe incluir como mínimo, un valor para todos aquellos campos que sean obligatorios y no se podría crear un registro que tenga un campo que no se encuentre definido en la tabla, es decir, no se podría crear un registro que incluya un campo llamado “direccionUsuario” dado que este campo no está en la definición de la tabla. Esto, en el mundo de ES no es así, ya que cada registro que es conocido como un document almacenado en un index y type concretos, no necesariamente tiene una estructura de campos fija, de hecho, se trata simplemente de estructuras JSON que pueden tener “cualquier cosa”, incluso elementos con múltiples valores como arrays, comportamiento que podría servir para crear relaciones de composición entre diferentes bloques de información, tal como se pretende hacer con las claves foráneas en una base de datos relacional. Los documentos en ES, desde el punto de vista técnico pueden estar compuestos por estructuras de datos no homogéneas, aunque evidentemente a la hora de diseñar un sistema es altamente recomendable definir una estructura base que será utilizada para la creación de registros en un nodo o cluster de ES. Dicho esto, es el momento de ver cómo crear índices, tipos y documentos.

¿Cómo crear registros en una instancia o cluster de ES?

Como se ha explicado en el post anterior a éste, para interactuar con una instancia o cluster de ES es necesario utilizar la API Rest que se encuentra disponible en cualquier nodo en ejecución. Se puede utilizar cualquier cliente HTTP para realizar peticiones contra dicha API Rest, desde CURL, wget, Postman hasta un objeto HttpConnection en Java o la librería “requests” de Python. El cliente empleado no es tan importante como conocer los endpoints disponibles y cómo se deben invocar de forma correcta. Probablemente la creación de índices es la labor más importante en ES y también, de las más sencillas tal como se puede apreciar en la siguiente imagen:

Utilizando Postman se ha creado un índice llamado “articulos”, con un tipo llamado “noticia” y un documento con identificador “2019001”. Si se quisiera comparar esta estructura con algo más familiar, como una base de datos relacional, “articulos” sería un esquema en la base de datos, “noticia” una tabla y “2019001” la clave primaria del registro insertado y luego, la estructura JSON que viaja en el cuerpo de la petición contiene los valores del registro propiamente dicho, cada uno en el campo que le corresponde. Sencillo, no?

Bien, esto es la operación de inserción pero también se puede gestionar el índice, tipos y documentos con operaciones CRUD (Create, Read, Update, Delete) tal como se puede apreciar a continuación.

Operación de lectura: Petición HTTP GET: http://ES_IP:ES_PORT/index/type/id

Operación de actualización: Petición HTTP POST: http://ES_IP:ES_PORT/index/type/id

Operación de borrado: Petición HTTP DELETE: http://ES_IP:ES_PORT/index/type/id

Gestionar índices en ES no es una labor compleja pero si vital para el correcto funcionamiento del sistema, ya que evidentemente es “el core” de la información y sobre los cuales trabajan otros endpoints de la API Rest disponibles en ES. Ahora que se ha visto cómo crear, obtener, actualizar y eliminar índices en ES, es el momento de hablar de búsquedas sobre estás estructuras de datos.

¿Cómo realizar búsquedas en ES?

Nuevamente es necesario utilizar la API Rest para realizar búsquedas contra ES. Dado que ES al igual que Lucene, se han creado precisamente para realizar búsquedas rápidas y potentes, no es de extrañar que ésta sea también una de sus características más complejas y difíciles de controlar. En este post solamente se explicará el proceso de búsquedas simples con el endpoint “_search”. En el próximo se hablará sobre la ejecución de búsquedas más complejas con múltiples filtros, paginación, acceso a mapeos, etc.

En primer lugar, el endpoint “_search” se pude utilizar directamente contra todos los índices disponibles en ES o contra uno concreto, nuevamente se puede utilizar Postman o cualquier cliente HTTP para realizar peticiones como las siguientes:

http://ES_HOST:ES_PORT/_search

Búsqueda sobre todos los índices disponibles en ES.

http://ES_HOST:ES_PORT/articulos/_search

Búsqueda sobre todos los documentos disponibles en el índice “articulos”.

http://ES_HOST:ES_PORT/articulos,negocios/_search

Búsqueda sobre todos los documentos disponibles en los índices “articulos” y “negocios”.

http://ES_HOST:ES_PORT/a*,n*/_search

Búsqueda sobre todos los documentos disponibles en los índices que empiezan por “a” y “n”.

http://ES_HOST:ES_PORT/articulos/noticia/_search

Búsqueda sobre todos los documentos disponibles en el índice “articulo” y tipo “noticia”.

http://ES_HOST:ES_PORT/_all/noticia,test/_search

Búsqueda sobre todos los documentos disponibles en todos los índices que tengan los tipos “noticia” y “test”.

http://ES_HOST:ES_PORT/articulos/noticia/_search?q=constitución

Búsqueda sobre todos los documentos disponibles en el índice “articulo” y tipo “noticia” aquellos cuyos en los que al menos un campo tenga la palabra “constitución”, o que se asemeje (esto se verá en el siguiente post).

Se trata de algunas de las peticiones más simples que se pueden ejecutar con ES y el endpoint “_search”, teniendo en cuenta que ahora mismo solamente se aplican filtros sobre índices y tipos, aún no se ha visto cómo filtrar por campos o paginar y además, las búsquedas anteriores se pueden hacer simplemente utilizando método HTTP GET. Como se verá en el siguiente post, esto se puede complicar bastante más dada la flexibilidad del motor de búsqueda y su potencia a la hora realizar consultas rápidas sobre volúmenes grandes de información.

Un saludo y Happy Hack.

Adastra.

Seguridad en ElasticSearch: Introducción – Parte I

agosto 23, 2019 3 comentarios

ElasticSearch se ha convertido poco a poco en una solución muy utilizada para el procesamiento de grandes volúmenes de datos. Está pensado principalmente para que las búsquedas sean rápidas y altamente personalizables, un modelo perfecto para la implementación de soluciones basadas en Big Data. ElasticSearch (ES) es un producto que cuenta con una API Rest muy completa para gestionar los índices y documentos, además cuenta con un sistema de complementos que permite extender sus funcionalidades. A pesar de ser un producto que lleva en el mercado varios años y que se ha posicionado muy bien, la seguridad en las instancias de ES a día de hoy es un tema delicado y en muchas ocasiones no es tan sencillo de configurar. Las instancias de ES por defecto no tienen ningún mecanismo de protección a “miradas indiscretas” y la cosa empeora aún más cuando múltiples instancias de ES funcionan en modo “cluster”. No obstante, antes de empezar a explicar estás cuestiones es importante entender el funcionamiento de ES, un poco de historia y sus características principales. Ese será el objetivo de éste post.

ElasticSearch un motor de búsqueda orientado a documentos, basado en Apache Lucene. Mantenido por su desarrollador principal hasta la creación de Elasticsearch.com (http://elasticsearch.com/) en 2012. Actualmente se encuentra bajo desarrollo y mejora continua por dicha empresa, bajo licencia OpenSource Apache 2.

Sus características fundamentales son las siguientes:

  • Orientado a documentos: JSON’s, Basado en Apache Lucene.
  • No se utilizan esquemas como en una base de datos relacional, de hecho, ES puede ser considerado como un motor de base de datos no relacional.
  • Distribuido: Escala dinámicamente y permite la integración de múltiples instancias. Los datos se encuentran replicados en cada nodo por medio de shards primarios y copias, evitando de esta forma la perdida de información en el caso de que un nodo se corrompa o exista un fallo en disco.
  • Multi-Tenant: Permite operar sobre múltiples índices a la vez
  • Centrado en API’s: Expone todas sus funcionalidades vía APIs REST
  • Búsquedas estructuradas y no estructuradas: Permite el uso de varios tipos de filtros, llegando a un nivel de granularidad en las búsquedas bastante preciso, pero también complejo.
  • Agregaciones / facetas: Permite la definición de características comunes en conjuntos de datos (documentos ES). Similar a las funciones de agregación disponibles en SQL estándar
  • Soportado por múltiples lenguajes de programación: Al tener una API Rest que permite la gestión de todas las características del sistema, es fácil crear clientes en prácticamente cualquier lenguaje de programación.
  • Elastic Search se compone de dos capas que se encuentran completamente desacopladas y tienen su propia gestión independiente:
    • Sistema distribuido: Implementa las funciones de gestión necesarias para los nodos de un cluster y el mantenimiento de sus datos. Los objetivos de esta capa se centran en el desempeño, la escalabilidad, alta disponibilidad y la tolerancia a fallos gracias al sistema de shards.
    • Motor de búsqueda: Proporciona las funcionalidades de indexación y búsqueda de documentos.

Una vez entendidas sus características principales, merece la pena mencionar la terminología básica para que luego sea más fácil de entender lo que se explicará en los próximos posts.

Cluster: Se trata de un conjunto de instancias de ES que comparten mismo nombre de cluster (propiedad cluster.name). No obstante, un cluster puede estar compuesto por un único nodo. Cuando se inicia una instancia de ES, si no se ha indicado las direcciones IP o hostnames correspondientes al conjunto de instancias “maestro”. También hay que tener en cuenta que cuando se inicia una instancia de ES por primera vez, si no se indica en la configuración la ubicación de los nodos master, es la propia instancia la que actuará como master en los próximos reinicios de la instancia, en tales casos es necesario volver a instalar y configurar la instancia desde cero tal como se verá en un próximo post.

NOTA: Al parecer en ES no creen en el lenguaje inclusivo ni son “100% feminist compliant” ya que usan términos como maestro y esclavo, espero que alguna/algune/alguni no se sienta ofendida/ofendide/ofendidi.

Nodo: Se refiere simplemente a una instancia de ES en ejecución.

Índices: Se trata de una colección de varios documentos (estructuras JSON), que no necesariamente tienen una estructura común. Comparable a los esquemas de una base de datos relacional.

Tipos: Colección de varios documentos de similar estructura. Comparable a tablas de bases de datos

Shard: Espacio de almacenamiento físico de cada uno de los documentos de un índice. También se le suele llamar “Shard Primario” para distinguir entre el “shard” principal y las replicas que se generan en otros nodos del cluster.

Replica: Copia de un shard que permite la replicación de la información. Gracias a este mecanismo ES cumple con los requisitos de alta disponibilidad y tolerancia a fallos. Por defecto, las replicas de un shard no se almacenan en el mismo nodo si hay un entorno de cluster.

Bien, teniendo claros estos términos y considerando que el objetivo de estos posts es que se puedan poner en práctica, lo primero es saber cómo instalar una instancia de ES, que tal como se podrá ver a continuación es bastante sencillo.

Instalación de ES

La instalación de una instancia de ES es un proceso muy simple y no requiere demasiado esfuerzo. Básicamente hay 3 alternativas: 1. instalarlo como servicio del sistema con los típicos gestores de paquetes en sistemas basados en Debian (apt-get) o RedHat (yum). 2. Utilizar una imagen de docker preparada o con Elastic Cloud (https://www.elastic.co/es/cloud/elasticsearch-service/signup). 3. Descargar el fichero tar.gz del sitio oficial, descomprimir y ejecutar el binario correspondiente (https://www.elastic.co/es/downloads/elasticsearch).

Cualquiera de las 3 alternativas es valida, no obstante, como ocurre con muchos otros productos de software que se pueden instalar desde código fuente (tercera opción), en mi opinión es mucho más cómodo, fácil de gestionar (no se instala un servicio systemd directamente en el SO), más fácil de configurar ya que todos los ficheros y binarios están en la misma ruta donde se ha descomprimido y lo mejor, se puede abrir el fichero de configuración ubicado en el directorio “config” y realizar los cambios que sean oportunos. En mi opinión, es mejor seguir la tercera alternativa para entender como funciona el sistema y luego plantarse incluirlo como un servicio en un entorno de producción.

Una vez descargado y descomprimido el fichero “tar.gz” basta con dirigirse al directorio “bin” y desde una terminal ejecutar el comando “elasticsearch”. Con esto, ya tenemos una instancia de ES con los valores de configuración por defecto y todo preparado para empezar a almacenar información.

Cuando se inicia una instancia de ES se podrán ver muchas trazas indicando que el nodo se encuentra levantado y como se verá un otro post, cada nodo puede estar en uno de tres posibles estados “RED”, “YELLOW”, “GREEN”. Los estados simplemente indican cómo se encuentran los shards para los índices que se han creado en la instancia. Por otro lado, también se puede ver que el servicio de ES por defecto se vincula únicamente a la interfaz de red local en el puerto 9200. Para comprobar que se encuentra correctamente instalado, basta simplemente con abrir un navegador web y lanzar una petición HTTP GET contra dicho puerto en local.

Partiendo de una instancia en ejecución, lo siguiente es comenzar a crear índices y comprobar el funcionamiento de ES. Partiendo de este conocimiento sobre el sistema, es posible comenzar a hablar de seguridad y tanto buenas como malas prácticas de configuración. Serán cosas que se verán en próximos posts.

Un saludo y Happy Hack.

Adastra.

A %d blogueros les gusta esto: