---
tags: DevOps, Development, Software,
---
# DevOps 相關工具模組研究 - Rancher

## 介紹

## 環境建議
Docker 1.6.0+
RAM 1GB+
SSD

## 主要功用

### 更好且更方便的管理
1. Rancher 自行維護的 Kubernetes 版本，Rancher Kubernetes Engine(RKE)
2. 各大公有雲所提供的 Kubernetes 服務，如 AKS, EKS 以及 GKE
3. 任何使用者自己創建的 Kubernetes 叢集

### 方便人員權限管理

#### IT Admin
1. IT Team 對於公司內的環境會有比較不同的需求，譬如帳號認證授權，安全政策等
2. IT 直接將 Rancher 與團隊內的身份機制整合，可以讓每個不同的 Kubernetes 都擁有不同的存取權限，譬如 QA Team 的人只擁有 QA 叢集的完全存取權限，而 Dev Team 的人可以存取 Dev 叢集，DevOps Team 的人則可以對所有叢集都有權限。
3. 可以直接於 Rancher 本身設定相關的安全政策，這些安全政策會直接套用到所有託管的 Kubernetes 叢集內。
4. Rancher 其實也有實作 Terraform 的介面，所以 IT Team 是可以直接透過 Terraform 使用 Infrastructure as Code 的概念來維護 Rancher，這樣就可以很簡單與快速的維護與創建各種叢集。
5. GitOps 的方式簡化了部署流程，使用者只需要更新 Git Repo 就可以順利更新自己的應用程式，甚至本身對於 Kubernetes 底層不太熟悉都能夠順利部署進去

#### DevOps Teams
1. DevOps Team 使用 IT Team 設定好的身份帳號來存取相關 Kubernetes 叢集
2. Rancher 也提供 KUBECONFIG 供使用者透過 kubectl/helm 等工具使用，也可以將此資訊整合到 CI/CD 流程來達成自動部署。
3. Rancher 也提供應用程式部署的相關機制讓使用者可以方便地管理 Kubernetes 上的應用
4. Rancher 整合的 Monitoring/Logging/Alert 功能讓使用者用起來很簡單。
5. Rancher Fleet 使用 GitOps 的方式簡化了部署流程，使用者只需要更新 Git Repo 就可以順利更新自己的應用程式，甚至本身對於 Kubernetes 底層不太熟悉都能夠順利部署進去

### 不用的原因
1. 雲端環境直接採用 Kubernetes 服務，如 EKS/AKS/GKE
2. 直接尋找系統整合商購買 Kubernetes 服務
3. 沒有地端(On-premises)環境需求
4. 公司不太想要使用開源專案，希望專案都要有人員提供技術服務

## Rancher的演變

原先大家使用 k8s，但因應大量的管理而衍生出了 Rancher v1，在 v1 的時候提供了不同 container 的管理，包含了 cattle、swarm、k8s 等，但也因為趨勢大家目前傾向全用 k8s ，所以到 v2 時只支援 k8s

## 建置

###### tags: `DevOps` `Development` `Software`