Resource Provisioning and DevOps


DevOps Taiwan Group 看到有人分享這篇文章:Microservice Prerequisites,其中的重點有三:

  • Rapid Provisioning
  • Basic Monitoring
  • Rapid Application Deployment

剛好最近工作上這些事都有關係,整理關於第一個 Rapid Provisioning 的心得。

Updated 2023/07/19: 本文收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市


語意

首先關於 *Provision- 字面上的意思:

  • Google Translate (v.): 供給 … 看不懂
  • Wikipedia, 中文: 服務開通,是一個電信行業的技術詞彙,它是指為了向用戶提供(新)服務的準備和安裝一個網絡的處理過程。 還是看不懂
  • Google 關鍵字 “AWS provisioning“: 可以找到很多相關的東西,不過 ….

看完之後應該很多人跟我一樣,還是搞不懂到底啥是 Provisioning

剛好最近在規劃 microservice 整個的開發流程的 pipeline,就是包含開發、測試、部署、監控、維運 … 等,後面幾個就是現在 DevOps 很常提到的部分,也會對應到一堆工具鍊。不過其實我發現,上述的階段,都少了一個很重要的東西:就是 把機器建好、把相關服務之間的關係配置好,像是 ELB / Auto Scaling / AMI / Route53 / VPC ... 等要準備好。

除了 microservice 之外,我也在幫公司弄災難還原計畫,也是規劃一堆事,要 RTO / RPO、哪一些服務要先 ready、要估多少預算、要跟哪一些 Team co-work .. 但是真的要執行前,除了基本的 infrastructure (Network / AD) 要弄好之外,就是 把機器建好、相關服務之間的關係配置好,像是 ELB / Auto Scaling / AMI / Route53 / VPC ... 等要準備好。

Q1: 為什麼會花時間在建立資源上?

因為要確立每次的環境都是乾淨、正確、資源隨時可以被刪除 (不養寵物) 的!

  • 同時不斷的『重構』架構,不是只有程式要重構,架構也要可以被重構。
  • 重構架構的過程,要不斷的釐清楚角色之間的關係、權責、權限,為什麼要如此設計?有沒有更好的方法?
  • 確立環境重建的流程,有信心隨時可以建立新的環境,給不同的目的。就像要不斷重構 Class,然後建立出來的 Object 才能有效跑邏輯。

Q2: 那用 Docker 就好啦!

容器化要考量以下兩個前提:

  • 如果 Production 還是會跑在 EC2 / VM 上,要考慮 infrastructure,包含 VPC / Subnet / Security Group / IAM Role 等相關安全性 Policy,這些不能上了線才來想。如果要使用 Auto Scaling
  • 除非上線規劃就是要容器化,那就同時想好如何部署、動態資源發現、監控、還原 … 等

光是建立 EC2 ,然後要放在對的位置 (我們有 VPC / Subnet / Security Group 使用的規範),用 AWS Console 是很慢的,用 Script 寫 CLI 會不容易管理,所以一個月前我就用 python + AWS SDK 刻了一個簡單的建立 EC2 工具,設計的重點在於:

  • Configurable
  • Reusable
  • 可進 git 版控
  • 可以符合 VPC / Subnet / Security Group 的管理規範

這個工具目前在內部用來大量建立 EC2,同時透過 EC2 的 userdata 可以快速配置好常用的工具,像是 Join AD、AWS SSM、CodeDeploy、Log 蒐集以及監控工具。

Updated 2017/11/29: AWS 後來也提供類似的功能,叫做 Launch Templates


定義

幾天前看到有人分享這篇文章:Microservice Prerequisites,看到第一點 Rapid Provisioning 完全符合我最近正在做的事情,我也終於釐清 Provisioning 到底是啥,最後整理出我自己的定義:

Provisioning 是 cloud computing 普及後出現的階段性任務,簡單說:「開機器」就是 provisioning。但現在一套系統通常不會只有「開一台機器」這麼單純,AWS 上常看到 VPC, Security Group, Subnet, ELB, S3, ASG, CloudFront, Route53, Redis, SES, SNS, CloudWatch … 等一堆要「準備好」、「串聯」, 然後才是輪到開發出來的應用程式的「部署」。這類的事情都可以自動化,也仰賴自動化。常見的工具 AWS 以 CloudFormation 最完整,不過我覺的適合全新的案子,既有的系統用 cli or sdk 會比較適合。

Deployment (部署) 是把開發好的應用程式 (.NET, Java 的 war, jar file) 放到 Application Server,把應用程式的 config (DB connection / Thirdparty API Key),然後讓他可以上線服務。

Provisioning 是部署之前,要準備好的相關資源以及設定,像是常見的 Route53 + ELB + ASG / Launch Config + AMI 的組合。

以傳統的 IT 單位來說,Provisioning 就是:開發單位下需求給 IT ,IT 進行設備採購 + 列管 + 把機器放到機房 + 把網路設定好 + 作業系統裝好 + 帳號設定好 + 預先安裝好管理工具,前面這段都是 Provisioning,最後給使用單位,使用單位自己去裝自己要用的東西。

updated: 2017/11/04: 因緣際會之下,這篇文章被朋友分享到社群: DevOps Taiwan ,從事電信產業的朋友說其實 Provisioning 這個字用在電信也是行之有年的,而且概念上也大概如我提到的想法。經過這次的分享與討論,受益良多!

回到 Microservice Prerequisites 提到的 Rapid Provisioning,意思就是要能快速提供資源的配置,翻譯成 AWS 上的說法:快速建 EC2。

類似的工具很多,像是 CloudFormation, Terraform, Chef, Ansible, Puppet, Dockerfile …. How to Provision an EC2 Instance 這篇針對 EC2 的 Provisioning 有很完整的工具比較與說明,把相關工具鍊都比較出來了,看是要全自動的『自排』還是半自動的『手排』的,都可以做選擇。

這些工具有些只考慮到 VM,或者 Application,有些會包含 Infrastructure, Network … 就看需求是什麼。

Provisioning 很重要?

DevOps 現在很流行,新職務 DevOps Engineer 就因此出現,他的首要工作任務是什麼?部署?建立 Jenkins Job?串 CI / CD?都不是,首要的技能是 Provisioning!而且是快速的、自動的 Provisioning!

AWS 定義的 DevOps Engineer, 其中就提到 “Two or more years’ experience provisioning, operating, and managing AWS environments”

快速 Provisioning 對開發流程有什麼意義?現在流行的 DevOps Pipeline 常見有以下幾個主要的 Stage

更多參閱: Software Development Lifecycle (2017/09/14)

這些 Stages 我用 list 排列 (non-ordered),表示沒有 先後關係,他們可以同步進行。

但是,我認為還少了一些:

  • Provisioning:環境建置、資源管理、預算控管、重構系統架構
  • Collaboration:包含 Source Control、Project Management、CI/CD Pipeline … 等

其中 Provisioning 的產出,或者說,幾乎會被每一個 Stages 依賴。

常見的案例:

  • 要建置一套環境給新客戶使用
  • 舊環境要做作業系統升級
  • 新環境要做架構性的測試
  • 功能性測試、整合性測試、回歸測試 … 等
  • 效能性測試:壓力、穩定、可靠 … 等. 或者要量測最佳數據
  • 架構重整

如果開發過程裡很難做上面的事、或者做不動,那系統到一定程度之後,會很更難動,最後就是影響整個 Business 的成長性。

所以歸納 Provisioning 的幾個重要性:

  • 架構重構,不斷的改善
  • 能提供完整且乾性的環境,給測試、開發、新產品試用 (Sandbox) … 等
  • 減少資安問題
  • 減少維運成本
  • 企業的成長不會受限,長得大!

所以 Provisioning 很重要?回到一開始文章提到的三點:

  • Rapid Provisioning
  • Basic Monitoring
  • Rapid Application Deployment

對我來說,要把 DevOps 最好,能夠快速變化,第一件事情就是 Provisioning 要做好,後面兩件事情都要建立在此前提,同時可以跟著自動化。

我最近在做的事情就是希望把 Microservice 整個環境建置 + 監控 + 部署可以全部自動化,快速地建立一套完整的環境,然後才有辦法到 Blue-Green Deployment。

另外就是現在很流行 Microservice,基本的實踐方式就是 Container。Container 都在強調什麼快? 『快速建置環境』,快速建置環境就是 Provisioning!Container 用的名稱叫做 Orchestration,搞得很偉大!然後才會有所謂的部署、配置、然後才談得上監控、維運等。

Orchestration 是音樂專有名詞:管弦樂編曲。在音樂學院是一門課,叫做配器法。 IT 圈很喜歡引用其他領域的名詞作譬喻。

工具篇

講了那麼多道理、想法,工程師最在乎啥工具最好用!?

我用過的有 CloudFormation、Ansible、Terraform … 用過的想法是,沒有一個可以滿足所有的需求,因為不同的 “階層 (Layer)” 適合用不同的工具。

  • Anisble:
    • 適合部署應用程式,也可以做 Provisioning
    • module 命名有點亂,使用上有些雷, debug 要花一點時間
    • 沒有考慮實際應用的場景,像是 security group 只能建立,無法更新。
    • 功能不完整,像是 Auto Scaling 不支援 Scaling Policy,看來需要自幹 ….
  • CloudFormation:
    • 適合:建立 AWS Infrastructure, Service 的 Provisioning,像是建立新的 VPC, 建立整個完整的 Service Stack, 包含 RDS, ELB, ASG, … 等介接
    • 不適合:安裝應用程式,像是執行 EC2 建立後的 userdata,理由是把 script 嵌入 yaml or json 很蠢、很噁心. 搞不懂為啥 AWS 為啥會這麼沒有設計概念,做出這麼爛的設計 …..
  • Terraform:
    • 可以建立完整的 Infrastructure,但是狀態要記得進版控.
    • 是自己定義的 DSL,格式比較複雜 (相對於 Ansible)
  • CodeDeploy: 為啥會提這個?他跟 Ansible 一樣都是作部署用途,不適合做 Provisioning,再次強調:Deployment and Provisioning 是兩件事。

其他像是 Chef、Puppet 我還沒試過,從文件看起來都比較 focus on deployment。Container 生態圈的 K8S, ECS 就先不提,概念上就不太一樣。


後話

以前用 M$ Windows 的年代,幾乎每一年都會重灌自己的電腦,整個重新安裝的流程可以算非常熟悉,重罐後系統也很乾淨,這大概是微軟一個很大的貢獻吧:養成 Provisioning 系統的習慣 XDD

當然不是自己的電腦,在開發工作上,一直以來也都是有 “Provisioning” 的概念,不管是開發工作、後來設計的 Test Framework,都是可以很快速地重建整個環境,帶 QA Team,環境建置這件事情更是基本功、JD 的第一條,不管是功能性的測試、還是壓力測試、還是要給新客戶的 Sandbox … 都是當天馬上就能給,我們甚至開發出類似 ansible 概念的部署工具。

所以其實我一直覺得,『環境建置』是基本功,特別是 Software Developer and SQA ,第一件事情都是要能夠自己獨立把環境建構起來,我在 前一個工作 找人的時候,第一個開出的工作內容就是『環境建置』,而實際的操作,也是 onboard 的前兩週做教育訓練,讓新人都可以獨立把環境建置起來,那時候訓練的內容包含:

  • Server: 七種角色
  • Database: 包含 HA, Master to Master
  • DNS 設定
  • APP 的配置
  • Embedded 的配置

這裡面橫跨三種領域:APP (iOS / Android)、Cloud Server (Live Streaming)、Embedded System (IPCam、Sensor)。

基本的概念就是要看到整個系統的全貌,測試的人看不到系統的全貌是在測心酸的嗎?這件事情對我來講,一直是基本功,不管對自己、還是帶團隊。

經過這樣的上述的訓練,不管是功能、整合性、效能、提供新客戶測試環境、甚至是工廠量產導入 (NPI)、量測最佳效能數據都可以做到。

量測最佳效能數據是:要量測在不受干擾之下,各個節點的最佳傳輸效能。當時為了測試 APP -> Server -> Embedded System 三端各個點的時間差數據,另外建置整套的測試環境,同時隔絕 Wi-Fi 的干擾因素,找到最佳的傳輸 Latency 與 Throughput.

工廠導入 (NPI) 同樣是建制整套完整的環境,提供整個生產環境可以做快速的驗證,最後達到 OQC 與生產流程最佳化的需求。

往往老闆都會求快,東西能動就上,但是卻忘了,『快』的本質是建立在精準、清楚的架構、完整驗證 等基本功之上,而且真正的快不是只有開發快而已,而是『精準』掌握市場動向,一刀斃命、一針見血,這才是快,否則就只是煙霧彈。

跟練琴一樣,速度 是建立在正確且扎實的技巧之上。聽起來很快,但卻很糊的聲音是上不了檯面的。

補充 (2017/12/12)

我把『環境建置速度與完整性』當成是軟體開發流程成熟度的指標。

環境建置完整性 = 具備可測性 = 品質的 Baseline = 清楚的架構
環境建置的速度 = 快速交付與驗證 = 自動化測試的基礎

在一個沒有清楚 Baseline 測出來的結果,我都是打問號的。


延伸閱讀

站內延伸

參考資料



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲