кластер docker-compose v3.1asticsearch v6.6.1 «ведомый» не присоединяется к мастеру - PullRequest
Новая
       27

кластер docker-compose v3.1asticsearch v6.6.1 «ведомый» не присоединяется к мастеру

0 голосов
/ 24 июня 2019

У меня есть настройка docker-compose для эластичного поиска на локальном хосте (оба контейнера на этом моем компьютере) с так называемым master, slave. Идея состоит в том, что «раб» присоединяется к «хозяину». Оба контейнера работают (пока) на одном хосте, на моей локальной машине. Проблема: раб не присоединяется к хозяину. (разумеется, планируется запустить производство на нескольких машинах)

Пожалуйста, смотрите следующую часть файла docker-compose, который содержит 2 службы эластичного поиска (другие службы FE, здесь взятые). Идея состоит в том, чтобы использовать ES в качестве индекса для FE, который можно масштабировать следующим образом:

шкала составления докераastic_slave = 3

Результат: все 4 контейнера запущены и работают в соответствии с: Докер PS

Проблема: однако при доступе к работоспособности кластера через

... _cluster / health? Pretty

«мастер» показывает только:

"number_of_nodes": 1, "number_of_data_nodes": 1,

Хорошо - мы не смогли найти работающий пример для этих версий: d-c 3.1 и ES 6.6.1. Итак, идеи для этих настроек: 

    depends_on:
      - elastic
    environment: 
      - cluster.name=docker-cluster
      - "discovery.zen.ping.unicast.hosts=elastic"

были взяты из примеров для d-c v2.

Я пытался "пропустить" одну из этих строк: нет "disabled_on", нет "cluster.name", а не "Discover.zen ..." .. без результатов.

На самом деле, почему они, кажется, не "видят друг друга" автоматически, когда работают в одной внутренней сети "elk"?

Мы также пытались остановить бегущих рабов, а затем, повторив сборку с докером, подумали: возможно, мастер должен быть полностью запущен, чтобы рабы могли его видеть. - тот же результат: все контейнеры работают, но не связаны как кластер.

  • это сценарий, о котором мы думаем (масштабирование подчиненных для индекса), с помощью docker-compose, возможен вообще - с этими текущими версиями?

  • или: какие версии можно использовать?

  • (ну, нам сейчас не интересно переходить на ES 7, достаточно сложно было перейти на 6.6.1)

  • есть ли другой «механизм», не составленный докером, который может запустить такой сценарий, не уверенный в «рое» (устарело?)

Большое спасибо и, пожалуйста, извиняюсь, если решение где-то есть, мы много искали, но req: dc version> 2 (для 2, есть много примеров, которые могут работать или нет, у нас нет пробовал) 

version: '3.1'

services:
  elastic:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.6.1
    container_name: elastic
    networks:    
      - elk
    ports:
      - "9200"
      - "9300"
    expose:
      - "9300"
      - "9200"
    environment:
      - cluster.name=docker-cluster
      - "ES_JAVA_OPTS=-Xms1g -Xmx1g"
      - "http.host=0.0.0.0"
      - "transport.host=127.0.0.1"
      - "xpack.security.enabled=false"
    ulimits:
      memlock:
        soft: -1
        hard: -1

    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9200"]
      interval: 10s
      timeout: 3s
      retries: 1

  elastic_slave:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.6.1
    networks:
      - elk
    depends_on:
      - elastic
    environment: 
      - cluster.name=docker-cluster
      - "discovery.zen.ping.unicast.hosts=elastic"

networks:
   elk:
    driver: bridge

пожалуйста, смотрите часть логов раба. Там написано «0 узлов соединены», начиная с мастера. Важна ли проблема с кешем, я не знаю, поэтому покажите также: 

elastic_slave_1  | [2019-06-24T11:58:11,055][INFO ][o.e.t.TransportService   ] [yhWiQ_5] publish_address {172.21.0.3:9300}, bound_addresses {0.0.0.0:9300}
elastic_slave_1  | [2019-06-24T11:58:11,084][INFO ][o.e.b.BootstrapChecks    ] [yhWiQ_5] bound or publishing to a non-loopback address, enforcing bootstrap checks
elastic_slave_1  | [2019-06-24T11:58:14,187][INFO ][o.e.c.s.MasterService    ] [yhWiQ_5] zen-disco-elected-as-master ([0] nodes joined), reason: new_master {yhWiQ_5}{yhWiQ_5QQ1iUm0blGbkatg}{6DOMrIVVSuiIqQdFgMLDOg}{172.21.0.3}{172.21.0.3:9300}{ml.machine_memory=7741763584, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true}
elastic_slave_1  | [2019-06-24T11:58:14,193][INFO ][o.e.c.s.ClusterApplierService] [yhWiQ_5] new_master {yhWiQ_5}{yhWiQ_5QQ1iUm0blGbkatg}{6DOMrIVVSuiIqQdFgMLDOg}{172.21.0.3}{172.21.0.3:9300}{ml.machine_memory=7741763584, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true}, reason: apply cluster state (from master [master {yhWiQ_5}{yhWiQ_5QQ1iUm0blGbkatg}{6DOMrIVVSuiIqQdFgMLDOg}{172.21.0.3}{172.21.0.3:9300}{ml.machine_memory=7741763584, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true} committed version [1] source [zen-disco-elected-as-master ([0] nodes joined)]])
elastic_slave_1  | [2019-06-24T11:58:14,273][INFO ][o.e.h.n.Netty4HttpServerTransport] [yhWiQ_5] publish_address {172.21.0.3:9200}, bound_addresses {0.0.0.0:9200}
elastic_slave_1  | [2019-06-24T11:58:14,273][INFO ][o.e.n.Node               ] [yhWiQ_5] started
elastic_slave_1  | [2019-06-24T11:58:14,296][WARN ][o.e.x.s.a.s.m.NativeRoleMappingStore] [yhWiQ_5] Failed to clear cache for realms [[]]
elastic_slave_1  | [2019-06-24T11:58:14,380][INFO ][o.e.g.GatewayService     ] [yhWiQ_5] recovered [0] indices into cluster_state
...