# DevOps相關技術
###### tags: `III DevOps`
### 微服務(Microservice)
它是一種分散式系統的做法。傳統的單體式服務(Monolithic)中，通常使用程式模組化的方式將功能進行區隔，但隨著系統增長、功能增加的情況下，會變得越來越難以維護、修復。

**單體式架構**
**微服務架構**

微服務將單體式系統分解為較小的獨立元件(服務)，每個元件都有各自負責的範圍。彼此間藉由通訊協定(最常使用的是HTTP協定)傳遞訊息以達成整體系統的串接。

微服務架構通常會被部署在容器上，且常被描述針對 DevOps 與持續整合/持續交付 (CI/CD) 進行最佳化，在可以頻繁部署小型服務的背景下，就很容易理解為何如此。

### Container 概念

#### 虛擬機器 Virtual Machine
在 Container 的概念尚未開始流行之前，一般而言一個應用程式的執行會是透過虛擬機器（以下簡稱 VM）來進行。為什麼不直接執行應用程式呢？因爲每台主機的環境配置、作業系統都不盡相同，所以當一台主機要直接執行用另外一台主機開發出來的應用程式，很可能會因為環境不一致的關係而失敗。VM 的概念是在將應用程式打包時，除了程式本身，還順便一起打包開發的作業系統，當任何一台主機（Host OS）要執行此應用程式時，就可以在 VM 中先下載裝有此應用程式所需一切資源的作業系統（此稱 Guest OS）， 模擬出一個熟悉的空間給此應用程式，這樣就能確保應用程式的順利執行。

#### 容器 Container
Container 同樣是將應用程式連同其所需環境（相關程式碼、函式庫、環境配置檔）一同打包的技術，但是在 Container 中不需要安裝作業系統就能執行應用程式。所有 Container 共用 Host OS，並建立資源控管機制來分配 Host OS 上的系統資源，因此省去了執行 Guest OS 的時間與心力，而能夠同時做到每個 Container 互相獨立。

#### 容器VS 虛擬機
所以說，VM 的中心是作業系統，而 Container 的中心是應用程式。

Container 的優勢基本上都跟甩掉了大個子 Guest OS 有關：

1. 執行速度快：相比 VM 以分鐘為單位，Container 執行速度可以以秒為單位。
2. 儲存空間小：相比 VM 以 GB 為單位，Container 執行速度以 MB 為單位。
3. 資源更有效運用：免去了執行 Guest OS 的義務，同一台主機上可以裝載的 Container 數量可以是 VM 的好幾倍。

以下是傳統虛擬機器與 Docker 容器所做的比較：

| | Docker 容器 | 傳統 VM |
| --------- | -------- | -------- |
| 虛擬化技術 | 以應用程式為中心 | 以作業系統為中心 |
| 安裝作業系統 | 不需要，故啟動快 | 需要，故啟動慢 |
| 標準化 | 利用 Docker 映像檔便可輕易複製開發環境 | 各家標準不同，作業系統核心也不一樣，移植困難 |
| 對 DevOps 的作用 | Dockerfile 將參數、環境完整的紀錄下來並結合版本控制 CI/CD 工具 | 整合 DevOps 工具相對困難 |

### Docker
它一個容器化技術。創造了一個標準化的 container 製造程序，讓應用程式具有相同的封裝方式、啟動方式、存取方式，不用修改就能在任何支援 Docker 的平臺上執行。
Docker包含了三個主要部份：
#### Docker 映像檔
Docker 映像檔就是一個唯讀的模板。例如：一個映像檔可以包含一個完整的 ubuntu 作業系統環境，裡面僅安裝了 Apache 或使用者需要的其它應用程式。可以用來建立 Docker 容器。
#### Docker 容器
容器是從映像檔建立的執行實例。它可以被啟動、開始、停止、刪除。每個容器都是相互隔離的、保證安全的平台。
#### Docker 倉庫
倉庫是集中存放映像檔檔案的場所。有時候會把倉庫和倉庫註冊伺服器（Registry）混為一談。實際上，倉庫註冊伺服器上往往存放著多個倉庫，每個倉庫中又包含了多個映像檔，每個映像檔有不同的標籤（tag）。

最大的公開倉庫是 Docker Hub，存放了數量龐大的映像檔供使用者下載。

當然，使用者也可以在本地網路內建立一個私有倉庫。當使用者建立了自己的映像檔之後就可以使用 push 命令將它上傳到公有或者私有倉庫，這樣下次在另外一台機器上使用這個映像檔時候，只需要從倉庫上 pull 下來就可以了。

### Kubernetes(K8s)
Kubernetes（又稱 K8s）是一個協助我們自動化部署（automating deployment）、自動擴展（scaling）和管理容器應用程式（containerized applications）的指揮調度（Orchestration）工具

Kubernetes 可以幫我們做到以下幾件事情：
1. 支援多項容器化工具，較常見的為Docker。
2. 同時部署多個 containers 到一台機器上，甚至多台機器。
3. 管理各個 container 的狀態。如果提供某個服務的 container 不小心 crash 了，Kubernetes 會偵測到並重啟這個 container，確保持續提供服務。
4. Kubernetes 可以很容易更新容器版本並 rollback 回之前版本
5. 將一台機器上所有的 containers 轉移到另外一台機器上。
6. 提供機器高度擴張性。Kubernetes cluster 可以從一台機器，延展到多台機器共同運行。
7. 當定義好部屬服務需求，可以很容易因應流量進行 Auto Scaling
8. 自動分配容器相對應的 IP 位址，透過 Service cluster 達到 load balancing 效果


Kubernetes cluster 主要可以分為 Master 和 Node 兩部份，Master 負責指揮調度 Node。在 Kubernetes 世界裡，Node 上的 Pod 是運行調度的最小單位，裡面可以放多個 container（一般以有緊密相關的服務為主，同一個 Pod 共享 IP），也可以只有單個 Container，同一個 Pod 的 container 是一起被調度。

控制面板由幾個元件 (Component) 所組成：
1. Kube API Server
控制面板中用來暴露 Kubernetes API 的元件，讓其他服務可以讀寫 K8S 的資源物件 (Resouce Object)。

2. Kube Schedular
調度器，需要調度軟體、硬體資源的時候就要靠調度器囉。例如：如果新建立的 pod 沒有 node 可以放的時候，調度器就會開啟一個新的 node，來放置剛剛需要建立的 pod。

3. Kube Controller Manager
是一個在背景持續執行的程序 (daemon)，用來調節系統狀態，透過 api-server 可以監視 Cluster 共享的狀態。
4. Cloud Controller Manager
基於 Kube Controller Manager，各個雲平台提供者（Provider）的實作。而每個 Node 則包含：

kubelet — 用來跟 Master 溝通的元件。
kube-proxy — 網路代理，用來反應 K8S 各個 Node 上的網路服務
#### Node
Node 是 K8S 中的一台實體機器、或是雲端上的一台機器，又稱作是工作者。為了管理Pod，每個Node 節點上至少要運行container runtime（比如docker 或者rkt）、kubelet和 kube-proxy 服務。

#### Pod
Pod是可以在Kubernetes 中創建和管理的、最小的可部署的計算單元。負責裝一個或多個多個 Container (容器)。

前述也有提到Container是我們容器化好的應用程式，例如：Node.js應用程式、MySQL服務等等。

以 Pod 來區隔，同一個 Pod 裡面的 Container 能夠在本地端互相的連線，只有需要提供給外部呼叫的 API 才需要暴露出來。