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

2017/02/11 09:53:00
Table of Content
Categories
Tags

About

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學

    • 著作

  • 個人著作：SRE實踐與開發平台指南
  • 共同著作：軟體測試實務 (2023)
  • 譯著：分散式系統設計 (2019)

    • 演講

  • 演講錄影 @ Youtube
  • 探索職涯、複利人生 - AWS Career Exploration Day 2023
  • 個人著作 SRE 書友見面會
  • 軟體測試實務 - 新書發表會
  • 探索職涯、成就未來 - AWS Career Exploration Day 2022
  • 從理想、到現實的距離，開啟品味軟體測試之路
  • 91APP 在 AWS 上的 SRE 實踐之路
  • 在矩陣型組織裡，如何有效管理 AWS 的成本結構與系統架構
  • 災難演練 @ AWS 實戰分享
  • 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
  • 聊聊軟體交付的濫觴 談產出物管理
  • 從緊急事件 談 SRE 應變能力的培養
  • 邁向 API 經濟 - API Gateway 導入之旅
  • Monitoring Tools 大亂鬥 - AWS CloudWatch
  • Ops as Code using Serverless
  • 淺談系統監控與 CloudWatch 的應用

    • Facebook

    Complete Think

    AWS Certifications

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
    • ▲ TOP ▲