【編者的話】CoreOS是一款OS，但它是一款面向云的輕量級OS。CoreOS是以Linux系統為基礎，為了建設數據中心的需要，而從Linux底層進行了內核裁減。cloud-config、etcd都是CoreOS離不開的話題，它們對CoreOS的作用何在呢？讓我們一起來學習吧。

這是關于深入淺出CoreOS的第二篇文章。在我上一篇文章中，主要闡述了CoreOS與其他Linux系統之間的不同、CoreOS的自動更新機制、發布渠道和集群發現的原理等。這篇文章中，我主要介紹一下cloud-config和etcd，文章最后會談一些常見的集群架構。

### Cloud-Config ###

Cloud-Config允許用戶以聲明的方式自定義各種級別的系統項目，例如網絡配置，用戶賬戶，systemd units（這將在下一篇文章中敘述）。Cloud-Config起源于Ubuntu，但在CoreOS中做了一些簡單的修改。

在每一個CoreOS集群的核心，都有CoreOS-Cloudinit，我們用cloud-config文件來做初始化配置操作，在系統啟動或者運行時用于配置系統。

什么是cloud-config?

Cloud-config是用 YAML 格式編寫，規定使用空格和換行來限制列表、關聯數組和值。這是關鍵性的格式化配置，所以在cloud-config部署到一個節點之前，必須使用CoreOS提供的 在線工具進行驗證 。一個cloud-config文件必須使用#cloud-config開頭，后續可以跟一個或多個關鍵字組成的關聯數組。

下面是一些經常用到的關鍵字：

• CoreOS:
  處理CoreOS的一些比如更新策略、etcd2,、fleet、flannel、units等的細節
• write_files:
  使用命令在本地文件系統定義一系列文件
• ssh-authorized-keys
  添加可以驗證核心用戶的ssh公鑰

下面是一個cloud-config的例子：

#cloud-config

hostname: core-01
coreos:
update:
reboot-strategy: off
etcd2:
name: core-01
initial-advertise-peer-urls: http://127.0.0.1:2380
initial-cluster-token: core-01_etcd
initial-cluster: core-01=http://127.0.0.1:2380
initial-cluster-state: new
listen-peer-urls: http://0.0.0.0:2380,http://0.0.0.0:7001
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
advertise-client-urls:  http://0.0.0.0:2379,http://0.0.0.0:4001
units:

name: etcd2.service
command: start

name: fleet.service
command: start

name: docker-tcp.socket
command: start
enable: true
content: |
[Unit]
Description=Docker Socket for the API



[Socket]

ListenStream=2375

BindIPv6Only=both

Service=docker.service



[Install]

WantedBy=sockets.target



name: docker.service
command: start
drop-ins:

name: 50-insecure-registry.conf
content: |
[Unit]
[Service]
Environment=DOCKER_OPTS='--insecure-registry="0.0.0.0/0"'




write-files:

path: /etc/conf.d/nfs

permissions: '0644'
content: |
OPTS_RPC_MOUNTD=""
ssh_authorized_keys:

ssh-rsa 121313dqx1e123e12… user@my_mac</pre>
 想了解更過關于cloud-config的配置參數，請參考 文檔說明 。 
ETCD2.X
Etcd是一個開源的分布式鍵值對存儲系統，專門為集群之間提供可靠的共享數據服務。
Etcd運行在每一個etcd集群的中央服務機器上（不用擔心，隨后我們會詳細講述此處），可以兼容機器運行的失敗，甚至是中心機器運行失敗（此時其他機器會替代中心機器）
 系統使用 Raft一致性算法 將數據的復制分發到etcd的節點。一致性是容錯分布式系統的一個基本的要求，一致性也包含很多服務上的數據一致。這樣一旦系統得出結論，這就是最終的結論了。 
Deis使用etcd來存儲數據，Kubernates同樣也在使用etcd存儲數據。
優化etcd集群的大小
Etcd集群的推薦3個、5個或者7個成員。盡管更大的集群可以提供更好的容錯能力，但是它的寫操作性能會不斷降低，因為此時數據需要被復制到更多的機器上。常規上，集群中使用3或者5個成員就足夠滿足系統需求了。推薦集群中的成員數量是奇數個的，奇數個成員的集群不會更改大部分的需求數量，但可以通過增加額外的成員從而增加系統的容錯能力。
下面的實踐中我們對比一下偶數個成員和奇數個成員的不同：
  
正如表中描述，增加額外一個成員擴充集群的大小到奇數成員數量是值得的。
在網絡分區中，集群奇數成員可以保證在網絡分區結束后總還會有大部分可以操作的集群。
 更多關于etcd的內容，請參考etcd的 文檔說明 。 
下面是一個中央服務器的etcd設置：
#cloud-config



coreos:
etcd2:
generate a new token for each unique cluster from https://discovery.etcd.io/new
discovery: https://discovery.etcd.io/60887e46255f4efew37077ccf12b5f06a54a
initial-advertise-peer-urls: http://$private_ipv4:2380
listen on both the official ports and the legacy ports
legacy ports can be omitted if your application doesn't depend on them
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
listen-peer-urls: http://$private_ipv4:2380,http://$private_ipv4:7001
data-dir: /var/lib/etcd2</pre> 
 
 https://discovery.etcd.io/new?size=3 已經定義使用，因此在初始化etcd是必須滿足是3個成員的集群。 

代理模式
當你為提供一個中央服務而啟動一個隔離的etcd集群，worker機器就需要連接到etcd集群，并把自己作為一個集群成員注冊進去，這樣就可以接收部署集群 fleet units，獲取操作系統的更新等等。
運行在每一個工作節點最容易的方式是通過代理，而不是啟動etcd本地服務。運行etcd作為代理允許你網絡上的etcd容易被發現，因為它可以作為本機服務運行在每一臺機器上。在這個模式下，etcd作為一個反向代理主動向etcd節點發送客戶端請求。由于etcd代理不能參與etcd的一致性復制，所以它既增加了還原力，也不減少集群的寫操作。
需要通信的etcd服務可以連接到本機。
Etcd目前支持兩種代理模式：readwrite和readonly。
默認的代理模式是readwrite，可以提供對集群的讀寫請求操作。
通過集群成員列表，代理可以周期性的輪轉到每個成員，這樣可以表面將所有的流量轉發給一個成員。
下面是一個設置代理的例子：
#cloud-config

coreos:
etcd2:
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
advertise-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
discovery: https://discovery.etcd.io/60887e46255f4efew37077ccf12b5f06a54a
proxy: on</pre> 
 
通過下面URL，這些經由本地的客戶端連接訪問etcd中央服務：

https://discovery.etcd.io/60887e46255f4efew37077ccf12b5f06a54a
 
 
 關于更多etcd代理的介紹可以 參考文檔 。 

集群架構
根據集群的大小和集群的使用場景，下面有幾條共同的集群架構準則是必須遵守的。
我們強烈建議設置固定數量的機器運行etcd中央集群服務，再分離出一個單獨固定數量的機器專門用于分布式應用控制，例如Deis，kubernetes，Mesos，OpenStack等。
分離出這些服務到固定數量的機器，可以確保它們能跨數據中心和可用區域分配，設置的靜態網絡允許簡單啟動。
如果你擔心依賴發現服務，這種設計可以消除你的后顧之憂。
然后就可以設置你的worker機器連接到中央服務。在這種設置中，你可以放大或者縮小你的機器從而滿足你的需求，再也不用擔心超多集群的額定人數。
 想獲得通過cloud-config文件配置設計不同集群的架構的更多信息， 請參考文檔 。 
下面我們一起看幾個例子：
筆記本上的Docker開發環境
如果你在本地開發，但是計劃在生產環境運行容器，本地環境將幫助你獲取鏡像。
在本地筆記本上很容易就可以運行Docker命令，從而操作VMware或者VituralBox中的CoreOS VM。
下面是一個CoreOS VM開發環境：
  
一個容易開發測試的集群
下面的CoreOS集群開發測試被充分利用：
  
這種設置對運行你的開發環境，測試環境，裸機環境或者云虛擬主機都十分有用。
如果你是第一次使用CoreOS，你會經常調整你的cloud-config文件，需要啟動，重啟甚至重裝好多機器。
這樣不用通過生成新的發現URL和重啟etcd，很容易就可以開啟一個etcd節點。通過這種方式，你就可以根據你的需求從etcd節點自由地引導更多的機器。
fleet, locksmith, 和 etcdctl的所有功能照常工作，但是通過etcd代理連接集群，而不是使用本地etcd實例。因為etcd只通過代理模式訪問所有的機器，你的CPU和RAM會減少一些壓力。
現在設置的這種環境具有最佳的性能。
一個CoreOS生產集群分為中央服務部分和worker部分
  
將集群劃分為中央服務和worker利于生產環境。對于大的集群，我們推薦要有三到四臺機器運行中央服務。這樣設置完成后，就可以在worker部門增加任意多的機器完成任務。每一個worker機器通過本地etcd代理使用在中央機器的分布式etcd集群。Fleet通過使用機器元數據和全局fleet units引導中央服務和worker機器上的jobs。我們將在下一篇文章中敘述這些。
 注意：如果你有Deis，Kubernetes，或者需要專門機器的其他服務，不要把這些服務放到etcd集群機器中。相反專門使用固定數量的機器完成。我們推薦使用etcd集群奇跡運行其他任何etcd服務。 
總結
這篇文章中我們講到：
 
  
Cloud-config配置文件

  
為什么建議etcd集群的機器數量為奇數

  
代理模式運行etcd

  
一些etcd集群的常規設置

 
在下一篇文章中我們就會更詳細地學習一下sytemd和fleet
 原文鏈接： CoreOS Overview, Part Two （翻譯：張亞龍） 
 </div>