139 期 - 共用系統核心資源，玩轉 Windows Server 容器

by Wang Wei-Jen on 星期二, 8月 29, 2017

網管人雜誌

本文刊載於 網管人雜誌第 139 期 - 2017 年 8 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。



文章目錄

前言
Windows 容器類型
Windows 容器運作環境需求
實戰架設 Windows Server 容器環境
          下載及安裝 Docker 運作環境
          下載 Windows Server 基礎容器映像檔
          部署第 1 個 Windows Server 容器 - Hello World
          部署第 2 個 Windows Server 容器 - IIS
客製化 Windows Server 容器
          重新建立新的容器映像檔
          推送容器映像檔至 Docker Hub
          測試客製化的 IIS 容器
結語





前言

在 2013 年時，有家名為 dotCloud 提供 SaaS 服務的公司，在該公司內有項名稱為 Docker 的業餘專案，它是使用 Google 的 Go 語言進行實作。後來，dotCloud 公司讓此專案加入 Linux 基金會並在 GitHub 進行推廣及維護，此專案迅速受到廣大開發人員的喜愛同時也讓 DevOps 議題捲起更大的浪潮，甚至 dotCloud 公司後來直接改名公司名稱為 Docker Inc。

Docker 容器管理技術如此受歡迎的主要原因之一，在於過去最困擾開發人員與維運人員的部分便是快速建立完備的開發環境，舉例來說，當開發人員需要某些開發環境時，企業或組織的維運人員便依需求建立 VM 虛擬主機、安裝作業系統、組態設定網路環境……等，接著再交由開發人員安裝相關應用程式或載入函式庫……等，此時才準備好整個開發環境，而 Docker 的出現剛好能夠解決這個困擾已久的問題。
Docker 容器管理技術，已經在 DockerCon 2017 大會上由 Docker 創辦人兼技術長 Solomon Hykes 發佈說明，從今天開始 GitHub 上原有 Docker 專案的程式碼、運作元件……等，都屬於新的開放原始碼專案「Moby」。

事實上，「容器」（Container）技術早已出現許久，而 Docker 則是讓容器管理這項工作任務便得容易操作及管理。一開始，Docker 容器管理技術普遍只能運作在 Linux 環境中，而微軟自從新任執行長 Satya 上任並大力擁抱開放原始碼之後，也在新一代的 Windows Server 2016 雲端作業系統中與 Docker 公司合作，打造出在 Windows Server 2016 作業系統中原生執行 Docker 引擎的容器管理環境。

雖然，在 Windows Server 2016 作業系統中已經成功打造 Docker 容器管理環境，但是整個 Docker 容器管理實作技術與 Linux 作業系統環境是完全不同的。簡單來說，Linux 容器映像檔並無法運作在Windows Server Container 容器環境內，而 Windows 容器映像檔也無法運作在 Linux Container 容器環境中，根本原因是採用「不同 API」（Windows API vs Linux API）的運作環境，那麼我們來看看有哪些根本上的不同：

Linux 容器環境
  • Control Group： 控制群組，針對共享資源進行隔離並管控硬體資源的使用，例如，記憶體、檔案快取、CPU、磁碟 I/O……等資源使用率的管理。
  • Namespaces： 命名空間，確保每個容器都有單獨的命名空間，讓容器之間的運作互相隔離不受任何影響。
  • AUFS： 檔案系統，不同容器之間可以共享相同基礎的檔案系統層，實現分層功能並將不同目錄掛載到同一個虛擬檔案系統中。


Windows 容器環境
  • Job Objects： 類似 Linux 容器環境中的控制群組機制。
  • Object Namespace、Process Table、Networking： 類似 Linux 容器環境中的命名空間機制。
  • Compute Service： 作業系統層級的運算服務層。
  • NTFS： 檔案系統，每個運作的容器各自擁有 1 份 NTFS 分區表，搭配虛擬區塊儲存裝置建立容器多層式檔案系統，接著再利用 Symlink 機制把不同層級的檔案對應到 Host 環境檔案系統內的實際檔案，以便減少虛擬區塊儲存裝置所占用的儲存空間。

圖 1、Linux 與 Windows 容器環境運作架構示意圖
圖片來源： Docker and Microsoft - Windows Server 2016 Technical Deep Dive
在 DockerCon 2017 大會上，同時發佈「LinuxKit」這個全容器化的 Linux 技術環境，希望打破不同作業系統平台（Windows 與 Linux）、虛擬化環境（VMware、KVM……等）、雲端環境（Google Cloud、AWS、Azure、Bluemix……等）、硬體（Intel 處理器、ARM 處理器、桌上型主機、筆記型電腦、伺服器、IoT 裝置……等），皆能建立 Docker 容器管理環境。

此外在 Docker 版本的部分在 2017 年也有重大改變，從 2017 年 3 月開始 Docker 採用新的版本以及版本命名規則。首先，Docker EE（Enterprise Edition）取代舊有的 Docker CS（Commercially Supported）版本，而 Docker 開放原始碼版本重新命名為 Docker CE（Community Edition）。至於版本命名規則與 Ubuntu 的命名規則類似，將以西元的「年 . 月」的方式命名，例如，v17.03、v17.06、v17.09……等。

圖 2、Docker 版本命名規則示意圖
圖片來源： Docker Blog - Announcing Docker Enterprise Edition





Windows 容器類型

在 Windows 容器環境中，包含 2 種不同的容器類型或稱「執行階段」（Runtimes），分別是「Windows Server 容器」（Windows Server Container）以及「Hyper-V 容器」（Hyper-V Container）：

  • Windows Server 容器： 透過程序和命名空間隔離技術提供應用程式隔離功能，讓運作於 Windows Server 容器環境中的容器能夠共用系統核心資源，這樣的運作方式與 Linux 容器環境類似。
  • Hyper-V 容器： 享有獨立系統核心資源，採用經過最佳化程序的 VM 虛擬主機執行容器環境，有效擴充原有 Windows Server 容器所提供的隔離環境。值得注意的是，執行 Hyper-V 容器的 VM 虛擬主機並非傳統的 Hyper-V VM 虛擬主機，而是運作 Windows Server 容器的特殊 VM 虛擬主機，並且具備獨立的系統核心、Guest 運算服務、基礎系統執行程序……等。
圖 3、Windows Server 容器與 Hyper-V 容器運作架構示意圖
圖片來源： TechNet Wiki - Windows Containers vs. Hyper-V Containers in Windows Server 2016





Windows 容器運作環境需求 

在 Windows 容器環境需求方面，採用 Windows Server 2016 雲端作業系統建立 Windows 容器環境時，不管採用的是 GUI 圖形介面版本、Server Core 文字介面版本，甚至是最精簡的 Nano Server 版本都同時支援「Windows Server 容器及 Hyper-V 容器」。

但是，倘若採用 Windows 10 桌面端作業系統欲建立 Windows 容器環境時，並不支援建立 Windows Server 容器運作環境，而是僅支援建立「Hyper-V 容器」運作環境，並且只有採用 Windows 10 專業版及企業版，並且安裝及啟用 Hyper-V 角色才提供建立 Hyper-V 容器運作環境。

此外，在 Windows 容器運作環境中具備 2 種容器映像檔，分別是 Windows Server Core 及 Nano Server 容器映像檔，然而並非所有作業系統版本都同時支援運作這 2 種容器映像檔。在下列表格當中，分別條列作業系統版本支援的 Windows 容器類型以及容器映像檔：

作業系統版本
Windows Server 容器
Hyper-V 容器
Windows Server 2016 GUI 圖形介面
Server Core / Nano Server
Server Core / Nano Server
Windows Server 2016 Server Core
Server Core / Nano Server
Server Core / Nano Server
Windows Server 2016 Nano Server
僅支援 Nano Server
Server Core / Nano Server
Windows 10 專業版/企業版
不支援
Server Core / Nano Server

值得注意的是，倘若管理人員希望在 Hyper-V 虛擬化平台中的 VM 虛擬主機，能夠同時運作 Windows Server 容器環境及 Hyper-V 容器環境的話，因為先前已經說明 Hyper-V 容器環境是運作特殊的 VM 虛擬主機，所以上層的這台 VM 虛擬主機必須啟用「巢狀式虛擬化」（Nested Virtualization）功能才行。

簡單來說，管理人員必須確保 Hyper-V 虛擬化平台符合運作巢狀式虛擬化機制，以便將「虛擬化擴充功能」（Virtualization Extensions）也就是底層硬體輔助虛擬化技術，傳遞給 Hyper-V 虛擬化平台上運作的 VM 虛擬主機當中的客體作業系統，達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
有關 Hyper-V 虛擬化平台建構巢狀式虛擬化環境的詳細資訊，請參考本刊雜誌第 133 期專題報導「實作 Hyper-V 巢狀虛擬化，測試研發效率大提升」。

圖 4、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖
圖片來源： Virtualization Blog - Windows Insider Preview： Nested Virtualization





實戰架設 Windows Server 容器環境

下載及安裝 Docker 運作環境

首先，我們透過 OneGet Provider 機制，安裝 PowerShell 的 Docker 模組以便稍後 Windows Server 能夠運作 Docker 運作環境。請開啟 PowerShell 命令視窗，並鍵入「Install-Module -Name DockerMsftProvider -Repository PSGallery -Force」指令，系統便會自動由 PowerShell Gallery 中，下載及安裝 Docker-Microsoft PackageManagement，執行下載及安裝指令後，當 PowerShell 視窗出現「需要 NuGet 提供者才能繼續」的詢問訊息時，請按下「Y 鍵」以便繼續安裝程序。
Docker 運作環境，是由「Docker 引擎」（Docker Engine）及「Docker 用戶端」（Docker Client）所組成。

接著，請鍵入「Install-Package -Name docker -ProviderName DockerMsftProvider -Force」指令，使用 PackageManagement 中的 PowreShell 模組安裝最新版本的 Docker 運作環境，當安裝程序完成後系統會提示你應該要重新啟動主機，以便 Windows Server 當中的 Docker 運作環境能夠套用生效，請鍵入「Restart-Computer -Force」指令重新啟動 Windows Server 主機。

圖 5、為 Windows Server 安裝 Docker 運作環境

當 Windows Server 主機重新啟動後，查詢 Windows Server 主機網路連線的部分，會發現多出「vEthernet（HNS Internal NIC）」的虛擬網路卡，並且 IP 位址為「172.x.x.x / 255.255.240.0」（本文實作環境 IP 為 172.27.144.1）。這個虛擬網路卡便是屆時 Docker 運作環境中容器虛擬網路的部分，後續我們再進行詳細說明。

圖 6、負責 Docker 運作環境中容器的虛擬網路

當 Windows Server 下載及安裝 Docker 運作環境後，便可以透過基礎操作指令來了解 Docker 運作環境的相關資訊，舉例來說，管理人員可以鍵入「docker info」指令，系統便會詳細顯示目前 Windows Server 主機的 Docker 運作環境資訊，包含運作中的容器數量、暫停狀態的容器數量、停止狀態的容器數量、容器虛擬網路類型、容器主機記憶體容量……等。倘若，希望查詢目前 Windows Server 主機的 Docker 版本資訊時，只要鍵入「docker version」指令即可，如操作結果所示本文實作環境中 Docker 引擎及 Docker 用戶端版本為「17.03.1-ee-3」。

圖 7、查詢 Windows Server 主機的 Docker 運作環境版本資訊



下載 Windows Server 基礎容器映像檔

在 Windows Server 的容器運作環境中，有 2 種不同類型的基礎容器映像檔分別是 Windows Server Core 及 Nano Server。倘若，管理人員希望下載 Windows Server Core 容器映像檔，只要開啟 PowerShell 指令視窗後鍵入「docker pull microsoft/windowsservercore」指令即可，若是希望下載 Nano Server 容器映像檔，只要開啟 PowerShell 指令視窗後鍵入「docker pull microsoft/nanoserver」指令即可。

圖 8、下載 Windows Server Core 及 Naon Server 容器映像檔

事實上，當鍵入上述 2 行指令後，本地端的 Windows Server 主機便會至 Docker Hub 網站，下載由 Windows 官方建立的 Windows Server Core 及 Nano Server 容器映像檔，因此管理人員並不用擔心下載到被加入惡意程式的容器映像檔。

那麼，這 2 個下載的 Windows Server Core 及 Nano Server 容器映像檔將會佔用多少空間呢 ？此時，管理人員只要鍵入「docker images」指令即可查看，在本文實作環境中可以看到 Windows Server Core 容器映像檔為「10.2GB」，而 Nano Server 容器映像檔則是「1.02GB」。

圖 9、查詢 Windows Server Core 及 Naon Server 容器映像檔佔用空間大小



部署第 1 個 Windows Server 容器 - Hello World

至此，Windows Server 容器運作環境已經準備完畢，管理人員可以直接從 Docker Hub 下載預先建立好的 Hello World 範例容器，以便部署及執行簡單的 Hello World 應用程式。請在開啟的 PowerShell 指令視窗中，鍵入「docker run hello-world:nanoserver」指令即可。由於，我們剛才已經先行下載好 Windows Nano Server 容器映像檔，所以不用再次下載 Nano Server 容器映像檔，因此你會發現執行這個 Hello World 容器的速度非常快速。

圖 10、部署及執行第 1 個 Windows Server 容器



部署第 2 個 Windows Server 容器 - IIS

在剛才的練習中，我們已經順利運作第 1 個 Windows Server 容器。接著，我們實作練習第 2 個最常使用的 Windows Server 容器「IIS 網頁伺服器」，請鍵入「docker run -d --name MyIIS -p 80：80 microsoft/iis」指令即可，此行指令中「-d」參數表示此執行的 IIS 容器在背景運作，而「--name MyIIS」則是給予此 IIS 容器的名稱，至於「-p 80：80」則表示將 Windows Server 主機的 Port 80，與執行運作的 IIS 容器 Port 80 進行對應的動作。

由於此 IIS 容器會使用 Windows Server Core 容器映像檔為作業系統基底，所以 Windows Server 主機若沒有 Windows Server Core 容器映像檔的話，便會需要花費額外的下載及安裝時間。在本文實作環境中，我們已經於剛才下載好 Windows Server Core 容器映像檔所以無須等待重下載及安裝時間，部署及執行 IIS 容器的動作完成後可以看到，此 IIS 容器佔用的空間大小為 10.5GB，也就是相較於 Windows Server Core 容器映像檔，加上 300MB 相關組態設定檔案。
事實上，倘若管理人員希望運作 Hyper-V 容器的話，只要加上「--isolation=hyperv」參數即可，當然前提是 Windows Server 主機已安裝及啟用 Hyper-V 角色。

圖 11、下載及執行基於 Windows Server Core 運作環境的 IIS 容器

在開始與剛才執行的 IIS 容器進行互動之前，管理人員可以先執行「docker ps」指令，查詢目前運作中的容器資訊，從執行結果可以看到目前 Windows Server 主機上運作的容器只有 1 個（透過 docker info 指令也能查詢容器運作狀態數量），並且可以看到容器 ID、容器映像檔、執行指令、容器建立時間、運作狀態、連接埠對應、容器名稱……等。

確認 IIS 容器仍持續運作中，接著執行「docker exec -i MyIIS cmd」指令進入 IIS 容器內執行互動作業，成功進行 IIS 容器互動模式後可以看到指令視窗中的提示字元，由原本的 PowerShell 變成命令提示字元。首先，請執行「del C：\inetpub\wwwroot\iisstart.htm」指令，刪除 IIS 容器內預設的歡迎頁面，然後執行「echo "This IIS Welcome page from Windows Server Container" > C： \inetpub\wwwroot\index.html」指令，將自訂字串訊息寫入 IIS 容器內的 IIS 歡迎頁面中。最後，便可以執行 exit 指令離開 IIS 容器互動模式回到 Windows Server 容器主機。

圖 12、進入 IIS 容器互動模式並自訂 IIS 歡迎頁面內容

完成 IIS 容器互動模式並自訂 IIS 歡迎頁面內容的動作後，請先確認 Windows Server 容器主機的防火牆規則中，是否已經允許 TCP Port 80 的網路流量能夠通過防火牆，接著請使用「別台主機」透過瀏覽器連接至 Windows Server 容器主機的 IP 位址，本文實作環境中 Windows Server 容器主機的 IP 位址為「http: //10.10.75.69」。此時，應該可以順利看到剛才我們所自訂的 IIS 歡迎頁面內容。
請注意，由於 Windows Server 容器虛擬網路 NAT 網路環境的關係，必須以「別台」主機透過瀏覽器才能確認能否瀏覽由 IIS 容器所提供的 IIS 歡迎頁面。倘若，從 Windows Server 容器主機採用「本機」的方式直接開啟瀏覽器，嘗試瀏覽由 IIS 容器所提供的 IIS 歡迎頁面時，將會發現是無法順利瀏覽的。

圖 13、順利看到剛才我們所自訂的 IIS 歡迎頁面內容

倘若，管理人員希望「停止」IIS 容器時，只要執行「docker stop < 容器名稱或容器 ID>」即可，後續希望再將 IIS 容器「啟動」時也只要執行「docker start < 容器名稱或容器 ID>」即可，若是希望「重新啟動」IIS 容器時請執行「docker restart < 容器名稱或容器 ID>」即可。
請注意，當容器的運作狀態為停止時透過「docker ps」指令是無法查詢到容器資訊的。此時，請執行「docker ps -a」便可以查詢到所有運作狀態的容器。

圖 14、針對容器進行停止、啟動、重新啟動等基本操作





客製化 Windows Server 容器

在剛才的實作練習中，我們都是執行官方預先提供的範例容器或下載及執行容器後再進行修改，接著我們將實作練習客製化 Windows Server 容器，依據企業及組織的運作需求自行打造符合內部運作環境的容器。



重新建立新的容器映像檔

以剛才我們所練習的 IIS 容器為例，請先執行「docker stop MyIIS」指令將 IIS 容器停止運作，使用「docker ps -a」指令確認 IIS 容器的運作狀態為「Exited」表示已經停止運作後，執行「docker commit MyIIS weithenn/myiis」指令，將剛才我們已經修改過內容的 IIS 容器，重新建立成新的容器映像檔並且客製化名稱為「weithenn/myiis」，重新建立容器映像檔的動作執行完成後，可以使用「docker images」指令進行確認。

圖 15、重新建立新的 IIS 容器映像檔並且客製化名稱為 weithenn/myiis



推送容器映像檔至 Docker Hub

重新建立 IIS 容器映像檔的動作執行完成後，我們可以將這個客製化的 IIS 容器映像檔推送至 Docker Hub，以便後續我們不管在哪一台 Windows Server 容器主機上需要使用此客製化 IIS 容器時，便能夠透過網際網路連線從 Docker Hub 網站下載後使用。

當然，管理人員必須先至 Docker Hub 網站註冊帳戶以便產生 Repositories 容器存放庫。確認 Docker Hub 帳戶註冊且運作無誤後，請回到 Windows Server 容器主機上執行「docker login」指令進行登入 Docker Hub 網站的動作，成功登入 Docker Hub 網站後執行「docker push weithenn/myiis」指令，將剛才重新建立 IIS 容器映像檔上傳至 Docker Hub 網站上。
請注意，預設情況下上傳至 Docker Hub 網站的容器映像檔為「公開」（Public），也就是公開給網際網路上的任何人下載使用，倘若管理人員希望這個容器為「私人」（Private）使用的話，請記得至 Docker Hub 網站針對此容器進行權限調整。
圖 16、上傳客製化的 IIS 容器映像檔至 Docker Hub 網站



測試客製化的 IIS 容器

順利將客製化後的 IIS 容器映像檔上傳至 Docker Hub 網站後，接著我們便可以測試是否能夠隨時由 Docker Hub 網站上，下載我們所客製化後的 IIS 容器映像檔並且執行部署的動作。首先，請執行「docker rmi weithenn/myiis」指令，將 Windows Server 容器主機中原有的 weithenn/myiis 容器映像檔刪除，並執行「docker images」指令再次確認 weithenn/myiis 容器映像檔是否已經刪除成功。

圖 17、將客製化的 IIS 容器映像檔刪除

確認已經 Windows Server 容器主機中原有的 weithenn/myiis 容器映像檔已經刪除後，便可以執行「docker pull weithenn/myiis」指令，讓 Windows Server 容器主機至 Docker Hub 下載剛才所上傳的 weithenn/myiis 容器映像檔，下載完成後便可以執行「docker run -d -p 80： 80 weithenn/myiis」指令，部署客製化過的 weithenn/myiis 容器映像檔，並執行「docker ps」指令確認 weithenn/myiis 容器是否運作中。

圖 18、至 Docker Hub 下載剛才所上傳的 weithenn/myiis 容器映像檔並進行部署作業





結語

透過本文的說明及實作練習，管理人員應該能夠體會到透過 Windows 容器技術，能夠以 Windows Server 容器提供類似 Linux 的容器環境，倘若需要更佳的容器隔離安全性的話則部署 Hyper-V 容器即可。同時，結合 Docker 容器管理技術，相信可以幫助企業及組織降低維運成本，同時也能降低資料中心維運人員的管理負擔。

[站長著作] 微軟 S2D 軟體定義儲存技術實戰

by Wang Wei-Jen on 星期一, 8月 21, 2017

[天瓏 - 新書預購特價 7.8 折]💪

即日起，天瓏書局針對本書推出預購特價 7.8 折活動，有興趣的朋友可以參考看看。😁



書籍簡介

還在為了規劃儲存設備規模大小而苦惱嗎？
實作微軟 S2D 軟體定義儲存技術，一次整合運算及儲存資源

Microsoft S2D 軟體定義儲存技術，最小運作規模只要 2 台 S2D 叢集節點主機，即可建構出不輸中階儲存設備的 IOPS 儲存效能，並且 S2D 單一叢集最大規模 16 台及高達 600 萬 IOPS 儲存效能。同時，整合 S2D HCI 超融合部署架構，能夠一次解決 VM 虛擬主機和 Container 容器及其他工作負載，在運算及儲存資源方面整合的煩惱。


軟體定義資料中心（Software Defined Data Center，SDDC）

根據 Gartner 的研究結果顯示，過往 IT 人員所熟知及打造 Mode 1 的現代化資料中心（Data Center Modernization）所遭遇的挑戰，主要在於管理及打造企業或組織中有關運算資源、儲存資源、網路資源、硬體設備、虛擬化技術⋯⋯等虛實整合。

隨著企業及組織朝向商業數位化模式不斷發展，知名的市調機構 Gartner 所屬分析師在 2015 下半年期間，針對 100 位企業及組織中負責領導IT基礎架構的主管調查結果顯示，有 2/3 以上的企業及組織開始建構及整合 Mode 2 的敏捷式 IT 基礎架構（Infrastructure Agility）。

所謂「基礎架構敏捷化」（Infrastructure Agility），便是著重於IT基礎架構中「Mode 2」的部分也就是因應商業數位化的需求，這些範圍包括：

  • 將敏捷（Agility）最佳實務概念，充分導入至現代化資料中心的IT基礎架構當中，讓工 作流程及技術人員能夠快速因應現在新興的商業數位化需求。
  • 深入了解各項使用案例、決策考量、微服務（Micro-Service）、容器引擎⋯⋯等最佳實務 概念。
  • 將單純的虛擬化運作環境，發展成軟體定義（Software-Defined）的基礎架構以達成敏捷 的目的，也就是打造「軟體定義資料中心」（Software-Defined Data Center，SDDC）。
  • 充份利用彈性的雲端基礎架構部署新世代應用程式（Next-Generation Applications）。 
  • 建構邊緣資料中心（Edge Data Center）平台，以便因應商業數位化及 IoT 物聯網。 
  • 加強巨量資料分析、Web 應用程式、IoT 物聯網⋯⋯等部署作業，以便因應現代化行動至 上的商務模式。

簡單來說，不管是 Mode 1 的現代化資料中心或是新興 Mode 2 的基礎架構敏捷化，在企業或組織的資料中心內硬體資源的組成，不外乎就是「CPU、記憶體、儲存、網路」等 4 大硬體資源，而這 4 大硬體資源又可以簡單劃分為3大類也就是運算、儲存、網路。

那麼，接下來我們來看看 Mode 2 基礎架構敏捷化定義中，透過軟體定義（Software-Defined）的運作概念，如何將「運算、儲存、網路」等硬體資源，轉換成 SDC 軟體定義運算、SDS 軟體定義儲存、SDN 軟體定義網路，幫助企業及組織打造成快速因應商業數位化需求的強大IT 基礎架構，最終達成 SDDC 軟體定義資料中心的目標。

軟體定義運算（Software Defined Compute，SDC）

軟體定義運算（Software Defined Compute，SDC），與 SDS 軟體定義儲存及 SDN 軟體定義網路技術相較之下，為基礎架構硬體資源當中最為成熟的技術。事實上，許多企業及組織在建構軟體定義式的IT基礎架構時，最先投入的便是 SDC 軟體定義運算的部分。

然而，談到 SDC 軟體定義運算便無法不談到 x86 伺服器虛擬化（x86 Server Virtualization） 技術，在 x86 伺服器虛擬化技術尚未風行前，企業及組織的應用程式及營運服務便直接運作在 x86 硬體伺服器上，這樣的運作架構雖然讓應用程式及營運服務，可以直接獨佔整台 x86 硬體伺服器所有硬體資源，所以能夠提供良好的工作負載能力。但是，卻容易產生「供應商鎖定」（Vendor Lock-in）的情況，舉例來說，倘若原本的應用程式及營運服務運作於 Dell 硬體伺服器上，但是該台 x86 硬體伺服器發生故障損壞事件時，需要將其上的應用系統或營運服務遷移至它牌硬體伺服器時（例如：HPE 或 Lenovo）是非常困難的。

事實上，談到虛擬化技術一般 IT 管理人員通常都會聯想到 VM 虛擬主機，然而這個情況從 2013 年 Docker 的出現而發生重大的改變。其實，Docker 並非是「容器」（Container）技術，而是一項用來管理及調度容器環境的技術，讓 IT 管理人員能夠不用費心處理容器的管理作業，便能達到輕量級作業系統虛擬化解決方案的目的。

微軟官方也在 Windows Server 2016 雲端作業系統中，與 Docker 合作推出 Windows Server Container 及 Hyper-V Container 技術，讓 Hyper-V 虛擬化平台成為同時運作 VM 虛擬主機及 Container 容器的最佳運作環境，輕鬆幫助管理人員達成 Bimodal IT 的雙重 IT 基礎架構，幫助企業及組織在傳統及新興架構之間找到最佳平衡點。

軟體定義儲存（Software Defined Storage，SDS）

軟體定義儲存（Software Defined Storage，SDS），為企業及組織帶來儲存資源的潛在好處，便是能夠提升靈活性並降低整體維運成本。因此，企業及組織的 CXO 們應尋找及確認能夠更好提供「總體擁有成本」（Total Cost of Ownership，TCO）的 SDS 軟體定義儲存解決方案，同時選擇的 SDS 解決方案必須具備效率及可擴充性等特性，以便因應不斷增加的資料量並且能夠擺脫儲存設備的硬體限制。

目前，在 SDS 軟體定義儲存解決方案市場中尚未有明確的市場領導者出現。雖然，SDS 軟體定義儲存解決方案具備可程式性及自動化等好處，但是仍須考量對於「運算」及「網路」所造成的影響。同時，所建立的 SDS 儲存資源必須要能夠融入 IT 基礎架構中而非再以孤島的方式運作。

在微軟新世代 Windows Server 2016 雲端作業系統當中，SDS 軟體定義儲存技術是由 Windows Server 2012 R2 當中的 Storage Spaces 技術演化而來，在 Windows Server vNext 開發時期稱為 Storage Spaces Shared Nothing，在 Windows Server 2016 的正式名稱則為 S2D（Storage Spaces Direct）。

軟體定義網路（Software Defined Network，SDN）

根據 CIO 的調查結果顯示，有 86% 的企業及組織 CIO 正計畫將內部資料中心及基礎架構進入 Bimodal IT 環境（相較於往年增加 20%），透過將過去 3 層式網路架構遷移至 Spine- Leaf 網路架構讓整體網路環境簡單化，並結合軟體定義網路（Software Defined Network，SDN）技術， 以 SDN Network Control Plane 來管理 Mode 2 的資料中心， 以便因應東-西（East-West）向的網路流量，並採用模組化架構以便輕鬆進行自動化部署，同時結合 Ansible、Puppet、Chef 等自動化組態設定工具，讓企業及組織的網路架構更適合 DevOps 環境，並往基礎架構即程式碼（Infrastructure as Code）的方向進前。

微軟新世代 Windows Server 2016 雲端作業系統當中，「軟體定義網路」（Software Defined Network，SDN）技術內的重要角色「網路控制器」（Network Controller），以及透過 SDN 技術管理「網路功能虛擬化」（Network Functions Virtualization，NFV）運作環境， 進而幫助企業或組織在資料中心內建構網路虛擬化環境。



網路購書





本書導讀

本書共有 7 個章節，由一開始簡介 SDDC 軟體定義資料中心願景開始，一路從 S2D 簡介及運作環境需求、S2D 底層運作架構、規劃設計最佳化 S2D 運作架構、實戰 S2D 環境建置、IOPS 效能測試、S2D 維運管理免煩惱。




第 1 章、SDDC 軟體定義資料中心

了解 SDDC 願景中重要的組成元件，包括 SDC 軟體定義運算、SDS 軟體定義儲存、SDN 軟體定義網路。

1.1 SDDC 軟體定義資料中心
1.2 軟體定義運算（SDC）
          1.2.1 x86 虛擬化技術
          1.2.2 全虛擬化技術
          1.2.3 半虛擬化技術
          1.2.4 CPU 硬體輔助虛擬化
          1.2.5 容器技術
          1.2.6 Microsoft SDC 軟體定義運算技術
          1.2.7 伺服器虛擬化技術市場趨勢
          1.2.8 基礎建設的重要性
1.3 軟體定義儲存（SDS）
          1.3.1 Microsoft SDS 軟體定義儲存技術
1.4 軟體定義網路（SDN）
          1.4.1 Microsoft SDN 軟體定義網路技術

圖 1-1、Mode 1 現代化資料中心示意圖
圖片來源： Gartner 官網 – Data Center Modernization and Consolidation Key Initiative Overview



第 2 章、S2D 簡介及運作環境需求

深入剖析 S2D 部署模式 HCI 超融合式與融合式運作架構的差別，以及建構 S2D 環境時應該採用 RAID 還是 HBA、採用 SSD 或 HDD、採用一般 TCP/IP 或 RDMA、採用 NTFS 或 ReFS 檔案系統等議題。

2.1 S2D 運作架構及部署模式
          2.1.1 超融合式架構（Hyper-Converged）
          2.1.2 融合式架構（Converged）
2.2 Windows Server 2016 版本
          2.2.1 Windows Server 2016 軟體授權
          2.2.2 Windows Server 2016 標準版
          2.2.3 Windows Server 2016 資料中心版
2.3 如何配置硬體元件
          2.3.1 Microsoft HCL 硬體相容性
          2.3.2 採用 HBA 控制器或 RAID 卡？
          2.3.3 採用 DAS / JBOD / NAS / SAN 儲存設備？
          2.3.4 採用 SSD 固態硬碟或 HDD 機械式硬碟？
          2.3.5 採用 TCP/IP 乙太網路或 RDMA？
          2.3.6 採用 NTFS 或 ReFS 檔案系統？

圖 2-20、啟用 RDMA 特色功能，可提升 2 倍的 IOPS 儲存效能
圖片來源： Channel 9 – DiscoverStorage Spaces Direct, the ultimate software-defined storage for Hyper-V（BRK3088）



第 3 章、S2D 運作架構

深入剖析 S2D 底層運作架構元件，例如：SSB 軟體式儲存匯流排、SSB 頻寬管理機制、SBC 儲存匯流排快取機制、Storage Pool、ReFS Real-Time Tiering、SMB Direct、RoCE、iWARP、Infiniband、SMB MultiChannel 等技術內容。

3.1 S2D 儲存堆疊運作架構
          3.1.1 SSB（Software Storage Bus）
          3.1.2 SBC（Storage Bus Cache）
          3.1.3 Storage Pool
          3.1.4 ReFS Real-Time Tiering
3.2 SMB 3
          3.2.1 SMB Direct（RDMA）
          3.2.2 RoCE
          3.2.3 iWARP
          3.2.4 Infiniband
3.3 SMB 多重通道
3.4 容錯及儲存效率
          3.4.1 鏡像（Mirror）
          3.4.2 同位（Parity）
          3.4.3 混合式復原（Mixed Resiliency）

圖 3-10、Hybrid 儲存架構資料快取示意圖
圖片來源： Microsoft Docs – Understanding the cache in Storage Spaces Direct



第 4 章、S2D 規劃設計

一步一步帶領你挑選 CPU 處理器、記憶體、NVMe 快閃儲存、SSD 固態硬碟、HBA 硬碟控制器、RDMA 網路卡、10GbE 網路交換器、了解 SSD 與 HDD 比例原則、S2D 叢集 大/中/小 型運作規模等最佳配置建議。

4.1 S2D 運作規模大小及限制
4.2 如何挑選實體伺服器硬體元件
          4.2.1 如何挑選 CPU 處理器
          4.2.2 如何挑選 RAM 規格
          4.2.3 如何挑選 SSD 固態硬碟
          4.2.4 SSD 與 HDD 如何搭配及比例原則
          4.2.5 如何挑選 HBA 硬碟控制器
          4.2.6 如何挑選 RDMA 網路卡
          4.2.7 如何挑選網路交換器
4.3 實體伺服器環境及數量建議
          4.3.1 小型運作規模
          4.3.2 中型運作規模
          4.3.3 大型運作規模

圖 4-19、Hybrid 儲存架構配置示意圖
圖片來源： Microsoft Docs – Choosing drives for Storage Spaces Direct



第 5 章、S2D 安裝及設定

手把手帶領你建構 S2D 運作環境，包括安裝 Windows Server 2016、設定 10GbE 網路交換器、啟用 DCB/PFC 特色功能、啟用 SMB Direct（RDMA）、啟用 SMB QoS 原則、建立 SET ( Switch Embedded Teaming )、檢查 RDMA 運作狀態、檢查 SMB MultiChannel 運作狀態、建立 S2D 叢集、啟用 Storage Spaces Direct 機制、建立三向鏡像磁碟區、建立雙同位磁碟區、建立雙向鏡像磁碟區、建立單同位磁碟區、建立混合式復原磁碟區、部署 VM 虛擬主機、Storage Pool 最佳化等最佳化組態配置。

5.1 安裝 Windows Server 2016 作業系統
          5.1.1 系統基礎設定
          5.1.2 安裝相關角色及功能
5.2 設定 10GbE 網路交換器
          5.2.1 啟用 DCB / PFC 功能
5.3 啟用 SMB Direct（RDMA）功能
          5.3.1 啟用 SMB 網路 QoS 原則
          5.3.2 建立 SET 網路卡小組
          5.3.3 檢查 RDMA 運作狀態
5.4 建構 S2D 軟體定義儲存環境
          5.4.1 加入網域
          5.4.2 確保已安裝最新安全性更新
          5.4.3 檢查 SMB Direct 及 SMB MultiChannel 運作狀態
          5.4.4 執行容錯移轉叢集檢查工具
          5.4.5 建立容錯移轉叢集
          5.4.6 設定容錯移轉叢集仲裁機制
          5.4.7 啟用 Storage Spaces Direct 機制
          5.4.8 建立三向鏡像磁碟區
          5.4.9 建立雙同位磁碟區
          5.4.10 建立雙向鏡像磁碟區
          5.4.11 建立單同位磁碟區
          5.4.12 建立混合式磁碟區
5.5 部署 VM 虛擬主機
5.6 Storage Pool 最佳化

圖 5-119、在 S2D 叢集中建立 5 種不同「容錯機制 / 儲存效率 / 容錯網域」需求的磁碟區



第 6 章、S2D 效能測試

從了解 IOPS 儲存效能的估算開始，慢慢深入如何進行 IOPS 儲存效能測試，並透過開源工具 VMFleet 進行 S2D 環境 IOPS 儲存效能測試。

6.1 什麼是 IOPS？
6.2 儲存效能測試基礎概念
6.3 VMFleet 效能測試工具
6.4 IOPS 效能測試

圖 6-41、採用「三向鏡像」在壓測情境 2 時 S2D 叢集的儲存效能表現



第 7 章、S2D 維運管理

深入了解 S2D 如何因應各式各樣硬體故障事件、如何查詢 S2D 運作健康狀態、S2D 叢集節點主機如何進入維護模式、如何整合 CAU 叢集感知更新機制安裝微軟最新安全性更新、實戰水平擴充 S2D 叢集運作規模（2台 → 3台 → 4台）、實戰擴充 CSVFS 磁碟區空間等維運管理議題。

7.1 S2D 如何因應硬體故障事件
          7.1.1 發生 1 個錯誤網域時
          7.1.2 發生 2 個錯誤網域時
          7.1.3 發生 3 個錯誤網域時
7.2 S2D 健康狀態
7.3 S2D 維護模式
          7.3.1 S2D 叢集節點主機進入維護模式
          7.3.2 S2D 叢集節點主機離開維護模式
          7.3.3 CAU 叢集感知更新
7.4 水平擴充 S2D 叢集運作規模
          7.4.1 擴充 S2D 叢集規模（2 台 → 3 台）
          7.4.2 擴充 S2D 叢集規模（3 台 → 4 台）
7.5 擴充 CSVFS 磁碟區空間

圖 7-6、發生 2 個錯誤網域時，S2D 叢集仍然能夠正常運作資料仍可持續存取
圖片來源： Microsoft Docs - Fault tolerance and storage efficiency in Storage Spaces Direct



附錄、S2D 解決方案

最後，我們進一步介紹市場上各家硬體伺服器供應商的 S2D 解決方案。（供應商名稱以英文字母順序排序）。

A.1 簡介 S2D 解決方案
A.2 Dell EMC – S2D 解決方案
A.3 Fujitsu – S2D 解決方案
A.4 HPE – S2D 解決方案
A.5 Intel – S2D 解決方案
A.6 Lenovo – S2D 解決方案
A.7 QCT – S2D 解決方案
A.8 Supermicro – S2D 解決方案

圖 A-1、支援 S2D 軟體定義儲存技術硬體伺服器清單
圖片來源： Channel 9 – Discover Storage Spaces Direct, the ultimate software-defined storage for Hyper-V (BRK3088)

[站長開講] DevOpsDays Taipei 2017

by Wang Wei-Jen on 星期日, 8月 06, 2017

活動簡介

Devopsdays 是全球性的技術系列盛會，由各地城市組織、發起自己的 Devopsdays，探討包含軟體開發、IT架構維運，以及兩者之間交互的議題。常見的議程包括了自動化、測試、資訊安全以及組織文化。

DevOpsDays Taipei 在 2017 年 9 月首次舉行，透過在地社群 Agile Community TW、DevOps Taiwan 以及 IT 媒體 iThome 聯手之下，邀集台灣在 DevOps 領域的技術專家，共同推動 DevOps 這波技術與文化的轉型運動，與世界脈動接軌。



活動資訊




活動內容




138 期 - VMware 自家容器作業系統實戰 Photon OS 基礎安裝

by Wang Wei-Jen on 星期二, 8月 01, 2017

網管人雜誌

本文刊載於 網管人雜誌第 138 期 - 2017 年 7 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。



文章目錄

前言
Photon 硬體需求及部署方式
安裝 Photon OS 容器平台
基礎操作
SSH 遠端管理
Docker 容器管理服務
          執行第 1 個容器 Hello-World
          執行第 2 個容器 Nginx 網頁伺服器
結語





前言

根據知名市調機構 Gartner 的研究報告顯示，在 2016 年時企業及組織普遍已經超過 80 % 的工作負載都運作在 VM 虛擬主機當中，同時預估在 2018 年時企業及組織當中將會有 50 % 的工作負載運作在「容器」（Container）當中，並且在 2020 年時不管是企業及組織內部的私有雲，或者是雲端服務業者所提供的公有雲 IaaS 服務當中，大多數的容器將會運作在 VM 虛擬主機當中。

有鑑於此 VMware 官方在 2015 年 4 月時，正式發佈 Photon OS 及 Project Lightwave 這 2 項開放原始碼專案，並放到知名的開放原始碼專案平台 GitHub 上讓管理人員方便下載，接著在 2016 年 10 月於 VMworld 歐洲大會上正式發佈 VMware Photon Platform，希望能夠幫助企業及組織更容易打造「雲端原生應用程式」（Cloud Native Applications）的運作環境。

圖 1、VMware Photon Platform 運作架構示意圖
圖片來源： VMware Blog - VMware Photon Platform：The Private Cloud for Developers

透過 VMware Photon Platform 運作架構，所打造的企業級雲端基礎架構平台並非只是單純僅運作容器服務而已。事實上，透過 VMware Photon Platform 中的 Photon Controller 運作元件，可以讓 IT 管理人員達到以分鐘等級建立數千個容器執行不同的工作負載或服務，至於 Project Lightwqave 則是在 VMware Photon Platform 運作架構中，負責處理 SSO 單一登入、驗證、授權及憑證……等功能。倘若，企業或組織的管理人員已經習慣使用 Kubernetes 調度工具，來管理企業及組織當中容器環境的話，那麼 VMware Photon Platform 也完全支援並能輕鬆整合。

圖 2、Project Lightwqave 運作架構示意圖
圖片來源： VMware vSphere Blog - Project Lightwave Now Available

本文，將著重在 VMware Photon Platform 運作架構中的基礎元件 Photon OS，它是一個輕量型的 Linux 容器執行環境，也就是大家所熟知的「容器作業系統」（Container OS）。或許，有讀者會納悶為何市面上已經有許多容器作業系統，而 VMware 官方還要自行額外打造自家的 Photon OS 容器平台，主要原因在於市面上的容器作業系統並非針對 VMware 虛擬化基礎架構最佳化而設計，同時在容器運作環境的安全性及網路設計普遍不足，因此為了因應現代化「微服務」（MicroServices）的運作架構，所以才著手打造及整合並最佳化運作於 VMware 虛擬化基礎架構的 Photon OS 容器平台。

圖 3、在 VMware 虛擬化基礎架構環境中運作容器環境示意圖
圖片來源： VMware Blog - VMware Cloud-Native Apps（CNA）Technology Primer





Photon 硬體需求及部署方式

首先，Photon OS 輕量級的容器作業系統，所需要的硬體資源需求非常低只需「2 vCPU、384 MB 記憶體、20 GB 硬碟空間」即可運作。在 Photon OS 的 GitHub 頁面中可以看到，提供下列 4 種不同的封裝格式方便 IT 管理人員部署 Photon OS 容器平台。

  • ISO 映像檔： 下載 ISO 映像檔後，建立 VM 虛擬主機並全新安裝 Photon OS 容器平台。
  • OVA： 透過 OVA 直接將已經封裝好的 Photon OS Minimal 版本容器平台，部署至 VMware 虛擬化平台，例如，vSphere ESXi、Workstation 12…… 等（支援虛擬硬體版本 10、11 的 VM 虛擬主機）。
  • Amazon AMI： 將 Photon OS 容器平台進行封裝，以便 IT 管理人員在 Amazon EC2 公有雲環境中部署及運作 Photon OS 容器平台。
  • Google GCE： 將 Photon OS 容器平台進行封裝，以便 IT 管理人員在 Google Compute Engine 公有雲環境中部署及運作 Photon OS 容器平台。
  • Microsoft Azure： 目前尚未支援，但 VMware 官方表示很快便會將 Photon OS 容器平台進行封裝，以便 IT 管理人員在 Microsoft Azure 公有雲環境中部署及運作 Photon OS 容器平台。





安裝 Photon OS 容器平台

在本文實作環境中，我們採用下載 Photon OS 的 ISO 映像檔，以及 VMware WorkStation 虛擬化測試環境來安裝及測試 Photon OS 容器平台。在建立運作 Photon OS 的 VM 虛擬主機過程中，必須注意的是在選擇客體作業系統版本時，請選擇至「Linux」選項然後在 Version 下拉式選單中，選擇至「VMware Photon 64-bit」項目即可。
倘若，在 Version 下拉式選單中沒有 VMware Photon 64-bit 項目可以選擇的話，請改為選擇「Other Linux 3.x kernel 64-bit」項目。

圖 4、選擇安裝 Photon OS 容器平台的客體作業系統版本

如果，採用的是 VMware vSphere ESXi 虛擬化平台時，那麼在建立運作 Photon OS 的 VM 虛擬主機過程中，請在 Select Compatibility 頁面於下拉式選單中選至「ESXi 6.0 and later」項目，在 Select a guest OS 頁面於下拉式選單中分別選至「Linux、Other 3.x Linux（64-bit）」項目即可。
支援運作 Photon OS 容器平台的 VMware vSphere ESXi 虛擬化平台版本為 5.5、6.0、6.5。

圖 5、在 VMware vSphere ESXi 虛擬化平台建立用於 Photon OS 的 VM 虛擬主機類型

安裝 Photon OS 容器平台的過程非常簡單，只要 3 個步驟即可安裝完成分別是選擇安裝選項、組態設定 Photon OS 容器平台的主機名稱、設定 Root 管理者帳戶的密碼即可。有關 Photon OS 容器平台安裝選項的部分，有下列 4 種安裝選項可供選擇：

  • Photon Minimal： 最輕量的「容器主機執行階段」（Container Host Runtime）運作環境，具備最高運作效能及安全性的容器平台版本。
  • Photon Full： 包含額外的相關套件以方便建立及打包應用程式在容器環境中運作，適合一開始使用 Photon OS 容器平台進行驗證及測試的版本。
  • Photon OSTree Host： 將會建立 Photon OS 執行個體，並且從 RPM-OSTree Server 下載相關套件及程式庫，同時後續在運作上將交由 OSTree Server 進行集中管理。
  • Photon OSTree Server： 將會建立「存放庫」（Repository）同時負責管理 OSTree 主機群，負責企業及組織內的容器生命週期管理及企業級規模擴充的工作任務。

圖 6、Photon OS 容器平台共有 4 種安裝選項可供選擇

在本文實作環境中選擇「Photon Full」安裝選項，大約 2 分鐘便完成 Photon OS 容器平台的安裝程序，然後按下任意鍵系統便會自動重新啟動。雖然，Photon OS 容器平台的基底也是 Linux 作業系統，但是 Photon OS 容器平台除了是 VMware 官方專為 vSphere 虛擬化環境進行最佳化之外，同時還移除 Linux 核心中不必要的部分，以及與 vSphere Hypervisor 重複的核心快取部分，以便提升 Photon OS 容器平台整體的運作效能，所以管理人員應該會發現 Photon OS 容器平台開機非常快速。

圖 7、Photon OS 容器平台開機畫面





基礎操作

當 Photon OS 容器平台開機完成後，會看到像 Linux 作業系統的 Console 文字登入訊息，請鍵入管理者帳號「root」以及剛才在安裝程序中，組態設定 Root 管理者帳戶的密碼後便可以順利登入 Photon OS 容器平台。

查詢系統資訊
順利登入後，我們可以使用指令「uname -a」查看 Photon OS 容器平台使用的 Linux 核心版本，接著使用「cat /etc/photon-release」指令查看 Photon OS 容器平台版本及組建編號，或者使用「hostnamectl」指令直接查詢系統相關資訊。

圖 8、查看 Photon OS 容器平台系統資訊

在本文實作環境中，Photon OS 容器平台是運作在 VM 虛擬主機內，對於稍有 vSphere 虛擬化運作環境管理經驗的 IT 管理人員來說，運作在 vSphere 虛擬化環境的 VM 虛擬主機，首先應確認 VMware Tools 服務是否正確運作，以便確保在 vSphere 虛擬化環境中的 VM 虛擬主機，在虛擬硬體及效能層面能夠以最佳化的方式運作。請鍵入「systemctl status vmtoolsd」指令，即可確認 Photon OS 容器平台中的 VMware Tools 服務是否順利運作。

圖 9、確認 Photon OS 容器平台中的 VMware Tools 服務是否順利運作

網路組態設定
預設情況下，Photon OS 容器平台開機後便會啟動 DHCP Client 機制，嘗試尋找區域網路中是否有 DHCP 伺服器可以配發 IP 位址，倘若你需要關閉 DHCP Client 自動尋找 IP 位址的機制。請將「/etc/systemd/network/10-dhcp-en.network」檔案內容中，在 Network 區塊下把「DHCP = yes」組態設定值改為「DHCP = no」後存檔離開即可。

在實務應用上，管理人員通常會為 Photon OS 容器平台組態設定固定 IP 位址。首先，請透過「networkctl」指令，確認目前的 Photon OS 容器平台共有哪些網路介面，同時這些網路介面的連線狀態為何。在本文實作環境中，管理人員為 Photon OS 容器平台配置 1 片虛擬網路卡，所以可以看到指令的輸出結果中有「eth0」網路卡，並且運作狀態為「routable、configured」，稍後我們將會針對 eth0 網路卡組態設定固定 IP 位址。

圖 10、指令結果顯示 Photon OS 容器平台配置 1 片網路卡

接著，可以直接將原本的 DHCP Client 組態設定檔，從「10-dhcp-en.network」重新命名為「10-static-en.network」，在 Match 區塊中使用「Name=eth0」指定 eth0 網路卡的組態設定檔，接著在 Network 區塊下組態設定 Photon OS 容器平台網路資訊：

  • DHCP=no： 停止啟用 DHCP Client 功能，避免 Photon OS 容器平台嘗試自動尋找區域網路中的 DHCP 伺服器配發 IP 位址。
  • Address=10.10.75.31/24： 指定 Photon OS 容器平台採用「10.10.75.31」固定 IP 位址，並且採用「/24」CIDR 的網路遮罩的語法進行組態設定。
  • Gateway=10.10.75.254： 指定 Photon OS 容器平台的預設閘道為「10.10.75.254」。
  • Domains=weithenn.org： 指定 Photon OS 容器平台採用的網域名稱及 DNS 搜尋尾碼。
  • NTP=clock.stdtime.gov.tw： 指定 Photon OS 容器平台所要採用的 NTP 時間校對伺服器。倘若，需要指定多筆 NTP 時間校對伺服器的話，請以「空白」隔開即可。

上述只是列舉常用網路組態設定參數，詳細資訊請參考 systemd.network 的 Man Pages 資訊。

接著，請修改「/etc/resolv.conf」組態設定檔內容，指定 Photon OS 容器平台所要採用的 DNS 伺服器 IP 位址即可。在本文實作環境中，指定的 DNS 伺服器為「nameserver 168.95.1.1」及「nameserver 8.8.8.8」。

最後，便可以使用「systemctl restart systemd-networkd」指令，重新啟動 Photon OS 容器平台的網路服務，然後就可以使用「ipa」及「iproute」指令，確認剛才所設定的固定 IP 位址及預設閘道資訊是否正確。

圖 11、確認 Photon OS 容器平台固定 IP 位址及預設閘道組態設定是否正確

使用「systemctl status systemd-networkd -l」指令，確認 Photon OS 容器平台網路服務運作狀態，以及使用「systemctl status systemd-timesyncd -l」指令，確認 Photon OS 容器平台 NTP 時間校對服務運作狀態。

圖 12、確認 Photon OS 容器平台網路服務及 NTP 時間校對服務運作狀態





SSH 遠端管理

在實務管理上，管理人員不可能會直接在 Photon OS 容器平台的 Console 畫面操作，通常都會透過 SSH 遠端登入進行維運管理的動作。然而，管理人員若安裝好 Photon OS 容器平台，並且組態設定好固定 IP 位址等網路資訊後，可能會發現雖然可以 SSH 遠端連線至 Photon OS 容器平台，但是卻無法使用 Root 管理者帳號登入，主要原因在於 Photon OS 容器平台的預設安全性設定所致。

首先，在預設情況下 Photon OS 容器平台的防火牆規則中，在安裝流程完畢後便會自動啟用並僅允許 SSH（TCP Port 22）能夠放行，然而對於 Linux 作業系統稍有管理經驗的管理人員便知，這是主機 SSH 遠端連線組態設定檔中不允許 Root 管理者帳戶遠端登入所致，而非防火牆規則未開啟所導致的問題。

倘若，管理人員希望能夠採用 Root 管理者帳號遠端登入 Photon OS 容器平台，請修改 SSH 組態設定檔「/etc/ssh/sshd_config」內容，將預設值從「PermitRootLogin no」修改為「PermitRootLogin yes」即可，也就是允許 Root 管理者帳號可以遠端登入 Photon OS 容器平台，接著再重新啟動 SSH 系統服務即可套用生效。
請注意!! 直接開啟允許 Root 管理者帳號遠端登入管理，將為 Photon OS 容器平台帶來一定程度的安全性風險。再次提醒，管理任何作業系統的基本資安觀念，便是不該直接開放最高權限管理者帳號能夠遠端登入，而是應該建立具備同等權限或剛好需要進行維運權限的使用者帳號後，才進行開放遠端登入的動作。

圖 13、組態設定讓 Photon OS 容器平台可透過 Root 管理者帳號遠端登入進行管理





Docker 容器管理服務

對於 RHEL / CentOS 等 Linux 作業系統稍有維運經驗的管理人員來說，應該會覺得 Photon OS 容器平台的維運管理非常類似。同時，從 RHEL 7 / CentOS 7 版本開始，管理系統服務的方式已經從傳統的 Runlevel（/etc/rc.d/init.d），改為新一代的 systemd（/etc/systemd/system）的方式進行系統服務的維運管理。

那麼在 Photon OS 容器平台中，管理人員只要使用「systemctl start docker」指令便可以啟動 Docker 容器管理服務，接著使用「systemctl enable docker」指令組態設定 Photon OS 容器平台，在每次開機或重新啟動後都能夠自動啟動 Docker 容器管理服務，最後便可以使用「systemctl status docker」指令來確認 Docker 容器管理服務的執行狀態、PID……等資訊。

圖 14、啟動 Docker 容器管理服務並確認執行狀態、PID……等資訊

接著，便可以透過「docker info」指令查詢 Docker 容器管理服務的運作資訊，例如，目前有多少容器執行中 / 暫停中 / 停止中、目前有多少容器映像檔、Docker Server 的版本、Docker 使用的虛擬網路、核心版本、Docker 容器管理服務的根目錄……等資訊。或是使用「docker version」指令，查詢目前使用的 Docker Client 及 Docker Server 版本以及使用的 API 及 Go 語言版本資訊。

圖 15、查詢 Docker 容器管理服務的運作資訊及使用版本資訊



執行第 1 個容器 Hello-World

至此，我們已經安裝好 Photon OS 容器平台並組態設定好網路資訊，同時也順利啟用 Docker 容器管理服務。那麼，我們開始來使用 Docker 容器管理技術建立第 1 個容器吧，我們將透過 Docker 容器環境執行並列出字串「Hello-World」。

請鍵入「docker run hello-world」指令，稍後便會看到系統列出「Hello from Docker !」的字串以及相關文字資訊。事實上，我們可以看到從執行指令後，在第 1 行系統顯示的資訊中（Unable to find image 'hello-world:latest' locally），說明目前系統發現目前在本機 Docker 映像檔存放庫中並沒有「Hello-World」這個 Docker 映像檔，所以系統就透過預設的系統設定連線至網際網路的 Docker Hub 公開映像檔存放庫，下載 Hello-World 這個容器映像檔（此時將自動執行「docker pull」的動作），最後執行列出字串的動作。

圖 16、建立及執行第 1 個容器 Hello-World

接著，可以透過「docker images」指令，查看目前 Photon OS 容器平台中 Docker 映像檔資訊。此外，管理人員可以再次執行「docker info」指令查詢，這次便會發現 Containers 欄位的變化「0 -> 1」，表示目前 Photon OS 容器平台中有 1 個容器，以及 Stopped 欄位的變化「0 -> 1」表示目前狀態為停止的容器為 1 個，和 Images 欄位的變化「0 -> 1」表示目前共有 1 個 Docker 容器映像檔。同時，預設下載的 Docker 容器映像檔，將會存放在 Docker 根目錄「/var/lib/docker」當中。
為何我們執行 Hello-World 容器後狀態不是 Running 而是 Stopped？ 因為，Hello-World 這個容器的生命週期就是執行完列印字串 Hello-World 的動作後便結束，所以順利列印出字串後便進入 Stopped 狀態。

圖 17、查詢 Photon OS 容器平台中 Docker 映像檔資訊



執行第 2 個容器 Nginx 網頁伺服器

經過簡單的容器執行操作熱身後，接著實作在實務 Docker 容器環境當中常會使用到的 Nginx 網頁伺服器。值得注意的是，因為在本文實作環境中採用「Photon Full」安裝選項，所以在預設情況下已經自動啟動 httpd 系統服務並佔用 TCP Port 80，必須要把 httpd 系統服務停止並且停用自動啟動機制，以避免與稍後我們所要實作的 Nginx 網頁伺服器容器環境發生 Listen Port 衝突的情況。

首先，我們執行「netstat -tunpl | grep ":80"」指令後可以看到，系統確實已經啟動 httpd 系統服務並佔用 TCP Port 80，所以請執行「systemctl stop httpd」指令停止 httpd 系統服務，此時 httpd 系統服務已經停止並釋放 TCP Port 80 的使用權。

接著，執行「systemctl disable httpd」指令，將 httpd 系統服務在開機或重新啟動時會自動啟動的機制關閉，以避免跟 Nginx 網頁伺服器容器發生 Listen Port 衝突的情況，然後執行「systemctl list-unit-files --type service | grep httpd」指令，確認停用 httpd 系統服務的動作是否套用生效。

圖 18、停止及停用 httpd 系統服務，以避免跟 Nginx 網頁伺服器容器環境發生衝突的情況

確認停止及停用 httpd 系統服務之後，便可以鍵入「docker run -d -p 80:80 vmwarecna/nginx」指令，執行下載及執行 Nginx 網頁伺服器容器環境的動作，同樣的可以看到目前 Photon OS 容器平台並沒有 Nginx 網頁伺服器容器映像檔，所以仍自動透過預設的系統設定連線至網際網路的 Docker Hub 公開映像檔存放庫，下載 vmwarecna 下的 nginx 容器映像檔並執行它。

完成下載及執行 Nginx 網頁伺服器容器環境的動作後，首先我們執行「docker images」指令可以看到，目前 Photon OS 容器平台列出的 Docker 容器映像檔清單中，多出了 vmwarecna/nginx 項目並且佔用的儲存空間為 93.48 MB。

然後，請執行「docker ps」指令後可以看到，在 PORTS 欄位有顯示「0.0.0.0:80 -> 80/tcp」的資訊，這表示當外部連線請求送至 Photon OS 容器平台後，將會透過 Docker 容器虛擬網路環境的 Bridge 機制，轉導向連線請求至 Nginx 網頁伺服器容器的 TCP Port 80。

圖 19、下載並執行 Nginx 網頁伺服器容器環境

然而，管理人員可能會發現開啟瀏覽器，嘗試連結 Photon OS 容器平台的 TCP Port 80 時，卻無法看到應該看到的 Nginx 網頁伺服器的歡迎頁面。主要原因在於，預設情況下 Photon OS 容器平台的 IPTables 防火牆規則，僅允許放行 TCP Port 22 的流量其餘則未開放並全部阻擋，所以才無法看到 Nginx 網頁伺服器的歡迎頁面。

圖 20、IPTables 防火牆封包進出、轉送、狀態等運作架構示意圖

因此，在本文實作環境中我們開放允許 TCP Port 80 的流量通過 IPTables 防火牆，以及在實務上常會用來判斷 Photon OS 容器平台是否 ping 回應的 ICMP 通訊協定。請修改「/etc/systemd/scripts/iptables」IPTables 防火牆組態設定檔，在允許放行 SSH 流量通過的防火牆規則下方，加上如下 2 行允許放行 TCP Port 80 及 ICMP 通訊協定的 IPTables 防火牆規則後存檔離開。
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

最後，執行「systemctl restart iptables」指令重新啟動 IPTables 防火牆系統服務後，新的 IPTables 防火牆規則便套用生效。此時，便可以使用「systemctl status iptables」指令確認重新啟動後，IPTables 防火牆系統服務是否正常運作中，以及使用「iptables -L」指令列出目前 IPTables 防火牆規則，便可以看到允許放行 TCP Port 80 及 ICMP 通訊協定的 IPTables 防火牆規則已經套用生效。

圖 21、放行 TCP Port 80 及 ICMP 通訊協定並確認 IPTables 防火牆規則已經套用生效

確認 IPTables 防火牆允許 TCP Port 80 流量通過後，此時便可以開啟瀏覽器再次確認能否看到 Nginx 網頁伺服器的歡迎頁面，結果當然是沒有問題可以順利看到 Nginx 網頁伺服器歡迎頁面。

圖 22、確認是否能夠順利看到 Nginx 網頁伺服器歡迎頁面





結語

透過本文的說明及實作相信讀者已經了解，針對 VMware 虛擬化運作環境最佳化的 Photon OS 容器平台，不管是在建立、執行、管理容器都非常簡單易用，確實可以協助企業及組織在將工作負載邁向微服務的路上更加輕鬆。
訂閱： 文章 (Atom)