Open main menu

Changes

Centralized logging in swarm

2,102 bytes added, 15:42, 30 September 2018
→‎Telepítés
==Telepítés=Produkciós beállítások===Ha kivesszük a '''discovery.type=single-node ''' paramétert, és ezen felül még a '''network.host ''' paramétert is beállítjuk, az ES produkciós üzemmódban fog elindulni. Produkciós indulás közben sokkal szigorúbban ellenőrzi a kötelező beállításokat. Ebből a legfontosabb host operációs rendszernek (jelen esetben a boot2docker) a '''vm.max_map_count''' beállítása, amit fel kell emelni minimum '''262144'''-ra. Ha ez kevesebb, az adott node nem fog elindulni.
<pre>
docker-machine ssh mg0
</pre>
 ==Egy lehetséges megoldás==Mivel minden master és data node-nak saját perzisztencia store-ra van szüksége nem tehetjük meg simán egy darab swarm service-ként elindítjuk a cluster-t és aztán felskálázzuk (docker swarm scale). Tehát az világos, hogy minden data és manager node-ot külön service-ként kell definiálni. Viszont az ingress overlay hálózatra csak egy service-hez tudjuk a 9200-as portot definiálni. (feltéve, ha el akarjuk érni kívülről). Szerencsére a koordinációs node-oknak (amik nem végeznek se master, de data se Ingest tevékenységet, kizárólag a kliensek kéréseit rout-olják a megfelelő node-okhoz) nem kell hogy legyen mentett data mappája, így ezeket létre tudjuk hozzon több elemű swarm service-ként, mint Elasticsearch belépési pont, és akkor a swarm ingress hálózat még meg is oldja a load-balancing-ot.  ===Közös konfigurációs fájl===A közös konfigurációs fájlba felvesszük az összes cluster tag végpontját '''discovery.zen.ping.unicast.hosts''' paraméterben. A listában minden egyes sor egy swarm service neve, amit a swarm DNS felold konténer IP címére. Egyedül a '''elasticsearch_coord''' lesz több konténerből álló szolgáltatás, amik rá lesznek kötve az ingress hálózatra is, ezek lesznek az ES cluster belépési pontjai. Szerencsére a zen discovery képes olyan DNS válaszokat is kezelni, amik több végpontot adnak vissza. <br>Az alábbi fájlt fel fogjuk csatolni az összes service-be NFS megosztással. <br>/usr/share/elasticsearch/config/elastic'''elasticsearc.yml'''
<syntaxhighlight lang="C++">
cluster.name: "my-cluster"
network.host: 0.0.0.0
# minimum_master_nodes need to be explicitly set when bound on a public IP# set to 1 to allow single node clusters# Details: https://github.com/elastic/elasticsearch/pull/17288discovery.zen.minimum_master_nodes: 12
discovery.zen.ping.unicast.hosts: elasticsearch - elasticsearch_coord - elasticsearch1 - elasticsearch2 - elasticsearch3
</syntaxhighlight>
Az alábbi megoldással több gond is van: összes ES node a közös elk nevű overlay hálózaton tud majd közvetlen kommunikálni egymással.    ===Coordinating node-ok===* Csak az első A Coordinating node van rákötve az ingress hálózatra, ez az egyetlen bejárata a ES cluster-nek, mivel nem egy darab okat több elemű swarm service tagjai az ES -ként fogjuk létrehozni. Ezek a node-ok (ez mondjuk nem nagy gond, kell elé tenni egy nginx load balancert)* Nem tudom hogy fel lehet e sorolni lesznek a '''discoveryES cluster belépési pontjai.zenEgyedül ebben a swarm service-ben lesz több mint egy konténer.ping.unicast.hosts''' paramétert Data mappát nem iscsatolunk fel hozzá. Mivel több Ahhoz hogy coordinating node esetén itt az összes -ként viselkedjen egy node-nak az összes többi swarm service (host) nevét fel kéne sorolni. A config-ban biztos meg lehet adni többetbe kell állítani, hogy se nem data, se nem master és mivel mindegyik ES se nem ingest tevékenységet nem végezhet. Ehhez létrehozhattunk volna egy külön konfigurációs fájlt a coordinating node-hoz ugyan azt oknak, mi most itt beírtuk környezeti változóba. 3 példányt kértünk belőle. Az ingress hálózaton a config NSF mappát csatoljuk föl, ez megadható lenne 9200 -as porton érhetjük majd el a elasticsearch.yml konfigurációs fájlbancoordinating node-okat bármelyik swarm node IP címén.
<syntaxhighlight lang="C++">
version: '3'services: elasticsearchelasticsearch_coord:
image: docker.elastic.co/elasticsearch/elasticsearch:6.4.0
ports:
volumes:
- "es-conf:/usr/share/elasticsearch/config"
- "es-data1:/usr/share/elasticsearch/data" environment: - discoverynode.zen.ping.unicast.hostsdata=elasticsearch2false - clusternode.namemaster=my-clusterfalse - node.name=node1# - bootstrap.memory_lock=true - http.cors.enabled=true - http.cors.allow-originingest=*false
deploy:
replicas: 2
restart_policy:
condition: on-failure
elasticsearch2</syntaxhighlight> ===További node-ok definiálása===Mivel most nem akarunk hatalmas cluster-t építeni, három további node-ot fogunk a cluster-hez adni, amik már mind a három szerepkörben benne lesznek (master, data és ingest). Mivel a master és az adat node-oknak már saját data mappára van szüksége, minden node-ot egy külön swarm service-ként fogunk definiálni saját volume plugin megosztással a perzisztens store-ban. Így bárhol is hozza létre őket a swarm, mindig ugyan azt a data mappát fogják megkapni. <syntaxhighlight lang="C++"> elasticsearch1,2,3:
image: docker.elastic.co/elasticsearch/elasticsearch:6.4.0
ports:
- "9200:9200"
networks:
- elk
volumes:
- "es-conf:/usr/share/elasticsearch/config"
- "es-data2data1,2,3:/usr/share/elasticsearch/data"
environment:
- discovery.zen.ping.unicast.hosts=elasticsearch - cluster.name=my-cluster - node.name=node2# - bootstrap.memory_lock=true - http.cors.enabled=true - http.cors.allow-origin=*node1,2,3
deploy:
replicas: 1
restart_policy:
condition: on-failure
resources</syntaxhighlight>A fenti compose blokkot háromszor kell a compose fájlba rakni a megfelelő sorszámmal a service, node és volume megosztás nevében (1,2,3)  ==Teljes compose fájl== {{warning|Nincs még frissítve...}} <syntaxhighlight lang="C++">version:'3' reservationsservices: memory: 500m ....
networks:
Retrieved from "http://wiki.berki.org/index.php/Special:MobileDiff/2587"