Ubuntu16.04
Docker 1.9
Elasticsearch 2.4
假設現在就一臺服務器，我們要用這臺服務器來部署一個ES的集群，那么好的解決辦法便是Docker了，我們可以利用Docker啟動兩個容器，在兩個容器內各部署一個ElasticSearch，總而組成一個2個節點的ES集群
Linux下Docker的部署：http://blog.csdn.net/gamer_gyt/article/details/52769294
終端安裝Docker：http://bbs.csdn.net/topics/392063910
我的Docker專欄：http://blog.csdn.net/column/details/13159.html
眾所周知，Docker使用了Linux的Namespaces技術來進行資源隔離，如PID Namespace隔離進程，Mount Namespace隔離文件系統，Network Namespace隔離網絡等。一個Network Namespace提供了一份獨立的網絡環境，包括網卡、路由、Iptable規則等都與其他的Network Namespace隔離。一個Docker容器一般會分配一個獨立的Network Namespace。但如果啟動容器的時候使用host模式，那么這個容器將不會獲得一個獨立的Network Namespace，而是和宿主機共用一個Network Namespace。容器將不會虛擬出自己的網卡，配置自己的IP等，而是使用宿主機的IP和端口。
例如，我們在10.10.101.105/24的機器上用host模式啟動一個含有web應用的Docker容器，監聽tcp80端口。當我們在容器中執行任何類似ifconfig命令查看網絡環境時，看到的都是宿主機上的信息。而外界訪問容器中的應用，則直接使用10.10.101.105:80即可，不用任何NAT轉換，就如直接跑在宿主機中一樣。但是，容器的其他方面，如文件系統、進程列表等還是和宿主機隔離的。
在理解了host模式后，這個模式也就好理解了。這個模式指定新創建的容器和已經存在的一個容器共享一個Network Namespace，而不是和宿主機共享。新創建的容器不會創建自己的網卡，配置自己的IP，而是和一個指定的容器共享IP、端口范圍等。同樣，兩個容器除了網絡方面，其他的如文件系統、進程列表等還是隔離的。兩個容器的進程可以通過lo網卡設備通信。
這個模式和前兩個不同。在這種模式下，Docker容器擁有自己的Network Namespace，但是，并不為Docker容器進行任何網絡配置。也就是說，這個Docker容器沒有網卡、IP、路由等信息。需要我們自己為Docker容器添加網卡、配置IP等。
bridge模式是Docker默認的網絡設置，此模式會為每一個容器分配Network Namespace、設置IP等，并將一個主機上的Docker容器連接到一個虛擬網橋上
組播配置示例如下，單播配置在下邊，使用時只需替換加幾行配置即可
sudo docker pull ubuntu
啟動容器，進入容器內安裝基本環境vim，Java，和elasticsearch
sudo docker run -it -d –name esc1 ubuntu:latest
sudo docker exec -it esc1 /bin/bash
apt-get install vim
apt install openjdk-8-jre
然后安裝es，下載安裝包 點擊下載
將其拷貝到docker內，安裝
dpkg -i elasticsearch-2.4.0.deb
至此基本環境已經準備的差不多了，然后便是退出容器，stop 容器，然后進行commit 保存成兩個容器
sudo docker commit esc1 es1:1.0
sudo docker commit esc1 es2:1.0
后查看鏡像如圖所示：
分別啟動兩個容器
sudo docker run -it -d -p 9201:9201 -p 9301:9301 -p 5001:5001 -p 5602:5602 –name esc1 es1:1.0
sudo docker run -it -d -p 9200:9200 -p 9300:9300 -p 5000:5000 -p 5601:5601 –name esc2 es2:1.0
進入兩個容器進行配置elasticsearch.ymal文件
esc1：
esc2：
cluster.name：集群名字，配置必須一樣
node.name：每個節點的名字，不能一樣
node.master： true 代表可以被選舉為主節點，false代表不能被選舉為主節點（這里我們設置esc2為主節點）
ndoe.data：代表是否可以存儲數據
network.host：表示訪問的ip，0.0.0.0表示可以以IP訪問或者localhost，127.0.0.1
network.port：訪問的端口
啟動Elasticsearch
service elasticsearch start
細心的朋友會發現容器的啟動端口轉發端口不一致，這是因為，這里啟動Docker容器默認采用的橋接，和主機共享端口了，所以兩者端口不能一致，要不然會重復
啟動完es集群，瀏覽器輸入 https:192.168.1.250:9200/_plugin/head
（這里我安裝了head插件，插件安裝，參考之前的一篇文章，里邊有講到：http://blog.csdn.net/gamer_gyt/article/details/52654263）
logstash 2.4版本 點擊下載
更多版本：https://www.elastic.co/downloads/past-releases
dpkg -i logstash-all-plugins-2.4.0_all.deb
然后進入配置文件目錄
cd /etc/logstash/conf.d
vim rsyscon.conf
添加以下內容
啟動logstash
service logstash start
編輯rsyslog的配置文件：
vim /etc/rsyslog.conf
后添加
重啟rsyslog服務
service rsyslog restart
ssh 本地，產生日志
ssh localhost
這個時候觀察elasticsearch界面：
以上的集群是采用組播的方式來構建的，組播就是通過在你的網絡中發送UDP的ping請求以發現節點，其它Elasticsearch會收到這些ping請求并且進行響應，這樣隨后就會形成一個集群。
多播對于開發環境是很好的，你不需要做什么事情，打開一些節點，他們自然的會發現對方形成一個集群。
正是因為這種易用性，你在生產環境中必須禁掉它。否在你得到的結果就是一個節點意外的加入到了你的生產環境，因為他們收到了一個錯誤的組播信號。對于組播本身并沒有錯。組播會導致一些愚蠢的問題，并且導致集群變的脆弱(例如：一個網絡工程師正在搗鼓網絡，而沒有告訴你，你會發現所有的節點突然發現不了對方了）。
在生產環境中，建議使用單播代替組播，也就是說為Elasticsearch提供一些它應該去嘗試連接的節點列表。一旦這個節點聯系到組播列表中的一員，它就會得到整個集群所有節點的狀態，然后它會聯系master節點，并加入集群。
這意味著你的單播列表不需要包含你的集群中的所有節點，它只需要包含足夠一個新節點聯系上其中一個并且說上話就ok了。
ES 是一個 P2P 類型(使用 gossip 協議)的分布式系統，除了集群狀態管理以外，其他所有的請求都可以發送到集群內任意一臺節點上，這個節點可以自己找到需要轉發給哪些節點，并且直接跟這些節點通信。
所以，從網絡架構及服務配置上來說，構建集群所需要的配置極其簡單。在 Elasticsearch 2.0 之前，無阻礙的網絡下，所有配置了相同 cluster.name 的節點都自動歸屬到一個集群中。
2.0 版本之后，基于安全的考慮，Elasticsearch 稍作了調整，避免開發環境過于隨便造成的麻煩。
ES 從 2.0 版本開始，默認的自動發現方式改為了單播(unicast)方式。配置里提供幾臺節點的地址，ES 將其視作 gossip router 角色，借以完成集群的發現。由于這只是 ES 內一個很小的功能，所以 gossip router 角色并不需要單獨配置，每個 ES 節點都可以擔任。所以，采用單播方式的集群，各節點都配置相同的幾個節點列表作為 router 即可。
此外，考慮到節點有時候因為高負載，慢 GC 等原因可能會有偶爾沒及時響應 ping 包的可能，一般建議稍微加大 Fault Detection 的超時時間。
同樣基于安全考慮做的變更還有監聽的主機名。現在默認只監聽本地 lo 網卡上。所以正式環境上需要修改配置為監聽具體的網卡。
上面的配置中，兩個 timeout 可能會讓人有所迷惑。這里的 fd 是 fault detection 的縮寫。也就是說：
discovery.zen.ping.timeout 參數僅在加入或者選舉 master 主節點的時候才起作用；
discovery.zen.fd.ping_timeout 參數則在穩定運行的集群中，master 檢測所有節點，以及節點檢測 master 是否暢通時長期有用。
既然是長期有用，自然還有運行間隔和重試的配置，也可以根據實際情況調整：
以上展示為組播方式，單播配置相對來說只需要在配置文件里加幾行即可
esc1：
esc2：
PS：我這里嘗試了很多次，增加了
這三個屬性之后集群并不能啟動，所以這里只設置了discovery.zen.ping.unicast.hosts屬性
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
