「除了在東京以外,也要在美西建一座一模一樣的機房喔!」
「這應該很~~簡單吧,照著原本的東西點一點,拉一拉就好了啊」

「大概要忙上半年,準備上線最少再三個月,接著踩一堆雷後一年後上線,時間久了後兩邊狀態越來越不一致,整天陷在改東改西的日子裡,最後走向毀滅」,某工程師內心這麼碎念著…同時也悄悄地打開 LinkedIn,思考著自己的下一步...

Infrastructure-as-code(IaC) 在雲端運算出來後的幾年後開始被廣氾討論,各新創公司也紛紛在創業初期選擇了公有雲(如AWS, GCP)做為平台,在沒有老舊系統的包袱之下,朝 IaC 這條正確的道路前進。甚至連一些穩定的大型企業也漸漸捨棄行之有年的實體機房(on-premise data center),投入 AWS/GCP 的懷抱,開始評估並導入 IaC

然而,新創公司求快速,大企業求穩定,願意在初期就紮實地走在 IaC 的道路上其實不容易,究竟它有什麼樣吸引人的地方?讓大企業與小公司都願意為他投入資源?

KKStream 在一開始就決定走向雲端,而且,也願意採用 IaC 來建置所有的雲端資源。

說 Data Center 是一間公司的命脈絕對一點也不為過,舉凡伺服器,資料庫,原始碼,通通都存放在這裡。看看電影裡面要偷取重要資料,是不是都會潛入一座充滿電腦主機的地方呢?就知道它的重要性了。

在這十年之間,Data Center 建置的變化與管理之大,也不亞於其他蓬勃發展的技術,個人以下粗略地將 Data Center 分成三個不同時期:

農業時期

我們在黑暗中尋求光明

企業在某個風水寶地,租用一個實體的機房,有著森嚴的門禁與不斷電系統,穩定的政局與便宜的水電費,並雇用一群專家來管理這上百台、上千台的機器。包含每一個伺服器配置、資料庫設定、網路路由、Load Balancer、系統升級、甚至到硬體的更換,都由手動或是搭配一些難以維護的 script 去操作,可能也需要透過 SSH 登入 production 的機器來升級。

在這樣的時代,付出大量的金錢(機房租金/人力),深怕忽然停電,或是配置錯誤,甚至機房因為某些原因爆炸(?)。任何的變更都是緩慢且難以復原,每一次的變更都要經過層層審核,拖慢了產品迭代的速度。

工業時期

“工人智慧”引領全球

雲端服務興起後,世界變得不同,人們開始擁抱像是 AWS 或是 GCP 這樣的服務,透過 Web Console 或是 CLI ,建置一套完整的 Infrastructure 變得極快,且大幅度減輕了維護的成本與迭代的時間,不過這些操作仍然是由「人」去操作,只要是由人去做的事,就會有出問題的可能,因為也許是因為時間關係,忘記當初是怎麼做的了,也或許是「換人」了,每個人的習慣不同,做法不同,都會造成結果不同。

舉例來說,我可能花了一個月幫團隊建立好所有的 infrastructure,其中包含了 testing/staging/production 的環境,過了幾個月後,有東西需要修改,我必需透過 Web Console 或是 CLI 去操作三次,甚至幾個月後,如果需要把整個環境從東京搬到美西,因為每個元件都可能是層層交錯的關係,我必需要極度小心,只要有一個地方出錯,很有可能整個系統就動不了。

對於短期的且有時效性的專案,這已經足夠,但是如果是想要長期發展的專案呢?很明顯還是不夠完美。

科技時期

科技始終來自於墮性

科技時代導入了 Infrastructure-as-code 的觀念,從原先由「人」透過 Web UI 或是 CLI 來操作的思維,取而代之的以寫 code 的概念去管理/建立/維護你的 infrastructure(見下圖),由「人」決定邏輯,讓「機器」幫你自動化幫你做事,這帶來了以下幾點好處:

  • 速度與可靠性,所有的建置都是全自動化的,這比透過 UI/CLI 操作來的更加快速與可靠。
  • infrastructure 的 source code 是可以被 version control tool 所管理 (如 git),這代表任何的改變都有跡可尋,也可以讓大家 review ,如果發生問題,也有辨法快速 roll-back。
  • 因為所有的 infrastructure 都變成 code 了,可以輕易重覆使用這些 code (就像把重覆的功能抽出來一樣變成一個 function 一樣),並且如果要 deploy 到不同的環境或是不同的地理位置也都沒問題。
  • 有順序地新增與刪除資源,把資源的相依性定義好後,這些資源會完全按照 code 裡面定義的順序去新增,就算是移除也一樣。
  • testing/staging/production 環境會長得幾乎一模一樣,這對開發和維運人員來講,是作夢也不敢想的事情!
  • 最重要的 — 它讓工程師的生活變得很開心,手動做重覆的事情是很枯燥,而且又很容易出錯,如果能自動化做到這些事情,何樂而不為?

對我來說,只有握有 code ,就握有整個 infrastructure。

Infrastructure as Code work flow

實務上的挑戰

若是已經在工業時代的專案,該怎麼進入科技時代呢?

理想上,導入 IaC 可以解決許多由「人」造成的問題,但是實務上卻碰到了一些難題,例如:

- 我的服務已經在線上跑的安安穩穩,一秒鐘幾百萬上下,雖然手動有點麻煩,IaC很好我也知道,但能不動就不動。

這是最常見的問題,還記得在某堂 AWS 訓練課程裡,講師提到的一句話:

Do the Right Thing in the First Time

一開始不做,之後會很累,能在專案開始時就同時導入 IaC 是再好也不過了,但總會因為某些原因而沒有這樣做。然而,最佳解也許還是「不要再拖了」,越不開始做,之後就越不會做,埋下的坑就越大,也是累到以後的自己,所以還是長痛不如短痛,只要能開始,就不嫌晚。

- 沒有人力/資源去做這件事情

其實所有的專案都有一樣的問題,只是看大家夠不夠重視,如果重視的話,自然有辨法排進 schedule 中,能做的就是讓大家知道這件事的重要性與必需性,當大家開始重視而漸漸變成一股風氣,想不做也不行了!

- 學習曲線過高

比起手動操作 Web Console/CLI,寫 infrastructure-as-code 的確讓不少人怯步,其主因在於每做一次改變,都要等待數分鐘(有時甚至要到十分鐘左右)才知道結果是否正確,對於剛開始學習的人會是一件非常消磨耐心也焦燥的任務,在沒有人帶的情況下,常常一整天就在 trial-and-error 過去了,什麼事也沒做到…這讓我回想起幾年前接觸 IaC 的慘痛回憶。

不過,這確實是一項值得的投資,若是團隊內有人可以問,有 code 可以抄的話,學習曲線就變得平緩許多。

經驗分享

在 KKStream中,我接觸到的第一個專案就是處在工業時代,所有的服務已經上線,但是環境都是手動建立的,包含 testing/staging/production 皆是。

為了往後大家的生活品質著想,第一件事就是把它推進科技時代,在用 IaC 重新建立好環境後,使用 Route53 分配權重,在兩套系統並行的情況下,確認新環境沒有問題後大膽切換過去,最後在沒有產生 downtime 的狀況下,成功地轉移成功!前後大約花了兩個月的時間。

此後,專案中所有的 infrastructure 就如下圖一樣,透過 code 去建置全部的資源。這也是 KKStream 中第一個,但不是最後一個採用 IaC 的專案。

在 KKStream 的專案中採用 CloudFormation 建置所有資源
Infrastructure-as-code 有哪些工具可以用

目前兩大 IaC 的工具為 AWS CloudFormationHashiCorp Terraform,前者為 AWS 官方工具,同時支援 JSON 與 YAML 的格式,與 AWS 其他服務整合良好且快速,線上資源豐富,官方文件詳細。後者為知名公司 HasiCorp 推出的工具,除了支援 AWS 外,也支援 GCP ,有著易讀易上手的優點。

各有各的優缺點與擁護者,在 Goole 上也有不少比較文可以參考。

在進入 infrastructure-as-code 的世界後,有哪些注意事項?
  • 手動操作是包著糖衣的魔鬼,千萬遠離它,當一切都自動化就緒後,一個看似平凡或是偷懶的手動介入,都有可能造成不可預期的結果,如果已經全自動化,就照著自動化的流程操作吧!
  • 落實 CI/CD,infrastructure-as-code 之所以強大,在於他用管理 code 的方式對待 infrastructure,因此,將 IaC 與 CI/CD 做結合,才能發揮 100% 的威力。
  • 減少 hard code,就像一般寫 code 一樣,沒有人會覺得 hard code 是件好事,在寫 infrastructure 的 code 時也一樣,相關的參數都抽出來變成可調整的而不是寫死。

最後,不論是 CloudFormation 或是 Terraform,能進入科技時代的就是好東西。