做爲一個操做系統,CoreOS 採用了高度精簡的系統內核及外圍定製,將許多本來須要複雜人工操做或者第三方軟件支持的功能在操做系統級別進行了實現,同時剔除了其餘對於服務器系統非核心的軟件,好比GUI和包管理器。git
CoreOS 集羣的架設比架設一個傳統服務器集羣更加容易。一方面由於 CoreOS 使用了 Cloud-init 自動化了集羣信息的配置,另外一方面則是受益於 etcd 分佈式存儲實現的消息分發和服務器自發現機制。這些便利性正是 CoreOS 系統設計充分爲集羣架構考慮帶來的效率提高。github
CoreOS 的安裝方法和傳統 Linux 系統有很大的不一樣。鑑因而基礎教程,在這一篇中,咱們會使用官方的Vagrant鏡像一步一步的構建CoreOS的VirtualBox虛擬機集羣。本文使用了Linux/Mac做爲測試環境,Vagrant從1.6版已經支持Windows,但須要安裝Putty做爲登陸工具,略有不一樣,具體使用方法見連接。 windows
須要順帶說明一點,比較仔細的使用者可能已經發現官方提供的鏡像中有一個是「 ISO鏡像文件」,然而這個鏡像實際上只是一個 Live CD,也就免安裝的試用鏡像,直接使用這個ISO啓動的系統是不具有服務自發現和分佈式消息分發的能力的。經過ISO鏡像安裝集羣的方式咱們會放到專題篇的內容裏面詳述。好,如今進入正題吧。瀏覽器
正如系列的第一篇所提到的,Cloud-init 一般依賴於具體平臺的實現定製,將其直接在物理機上使用並非主流的使用方法。對於這種安裝方法, 官方有一篇文檔提供了詳細的步驟,這裏再也不進行詳細討論。服務器
首先來看一下 CoreOS 原生支持的平臺。截止到目前,最新版本的CoreOS v540已經支持的平臺以下圖。架構
能夠看到除去安裝到本地的 Bare Metal,其他基本是針對主流的雲服務平臺定製的版本。這裏的定製主要是 Cloud-init 等啓動服務的配置,那麼如何知道 CoreOS 已經支持自動化的集羣部署的平臺有哪些呢?咱們能夠從 CoreOS 源代碼的 coreos-base 目錄裏獲得答案。curl
這些 oem 開頭的目錄就是平臺定製的實現。其中每一個目錄中的 files/cloud-config.yml 文件,就是 Cloud-init 的配置文件。在每一種平臺安裝 CoreOS 的方式各有不一樣,能夠從官方網站相應的頁面找到相應步驟。這裏咱們選擇其中的 Vagrant 做爲演示的目標平臺。分佈式
使用 Vagrant 創建 CoreOS 集羣能夠說是最簡單且經濟的方式了,使用本地虛擬機構建,特別適合快速驗證 CoreOS 的功能。工具
須要準備的東西,包括一臺鏈接到互聯網的 Mac 或者桌面 Linux 電腦,安裝好 Git、VirtualBox 和 Vagrant。測試
經過 Git 下載官方的 Vagrant 倉庫:
git clone https://github.com/coreos/coreos-vagrant.git
下載完成後,咱們接下來配置 CoreOS 集羣。
爲了使用集羣服務器的自發現功能,咱們須要一個能用來惟一標識一個集羣並提供集羣信息的地址。CoreOS 官方提供了這個服務,固然咱們也可使用本身搭建的私有集羣標識服務器。鑑於搭建私有標識服務器屬於比較進階的內容,咱們會在這個系列的後續文章詳述。
經過瀏覽器或命令行 curl 訪問地址 https://discovery.etcd.io/new能夠獲得一個新的集羣標識 URL(若是是在Windows下,能夠直接使用瀏覽器訪問這個URL地址),這個 URL 會在配置 user-data 時候使用到。
curl https://discovery.etcd.io/new
進入 coreos-vagrant 目錄,將 user-data.sample 和 config.rb.sample 兩個文件各備份一份,並去掉 .sample 後綴。獲得 user-data 和 config.rb 文件。
首先修改 user-data 文件,它將做爲啓動的配置文件提供給 CoreOS 操做系統。值得一提的是,在這個配置中,可使用兩個變量 $private_ipv4 和 $public_ipv4,它們會在實際運行的時候被自動替換爲主機的真實外網 IP 和內網 IP 地址。
這裏咱們須要作的只是將其中 discovery所在行前面的註釋符合「#」去掉,而後替換它的值爲咱們剛剛得到的集羣標識 URL 地址。簡單來講,全部使用了同一個標識 URL 的主機實例都會在 CoreOS 啓動時自動加入到同一個集羣中,這就實現了無需人工干預的集羣服務器自發現。
#cloud-config
coreos:
etcd:
# generate a new token for each unique cluster from https://discovery.etcd.io/new
# WARNING: replace each time you 'vagrant destroy'
discovery: <集羣標識URL地址>
addr: $public_ipv4:4001
peer-addr: $public_ipv4:7001
... ...
而後修改 config.rb 文件,這裏包含了 Vagrant 虛擬機的配置。經過這個文件實際上能夠覆寫任何 Vagrantfile 裏的參數,可是目前咱們只須要關注 $num_instances 和 $update_channel 這兩個參數的值。
$num_instances 表示將啓動的 CoreOS 集羣中須要包含主機實例的數量;
$update_channel 表示啓動的 CoreOS 實例使用的升級通道,能夠是 ‘stable’,’beta’ 或 ‘alpha’。
$num_instances=3
$update_channel='stable'
CoreOS 沒有跨越式的版本發佈,而是使用與 Arch Linux 相似的平滑的滾動升級,確保用戶任什麼時候候下載到的版本都是最新發布的系統鏡像,而且從根本上解決了服務器系統在運行幾年後,因爲沒法平滑升級而被迫從新安裝的狀況。此外 CoreOS 提供了 Stable、Beta 和 Alpha 三種升級通道,用於知足不一樣用戶對系統新特性和穩定性的平衡。關於升級通道的切換,可參考官方的文檔。
啓動集羣,執行:
vagrant up
查看集羣運行狀態,全部的集羣實例都已經啓動。
vagrant up
Current machine states:
core-01 running (virtualbox)
core-02 running (virtualbox)
core-03 running (virtualbox)
此時,在 CoreOS 集羣的內部正發生着許多故事,集羣的實例之間經過自發現服務,相互認識了對方並創建了聯繫。它們具有了在集羣中任意一個實例節點控制整個集羣的能力。是的,一個功能完備的 CoreOS 服務器集羣已經徹底運行起來了。
進一步,咱們將會進入啓動完成的 CoreOS 實例中,繼續探索其中的奧祕。