AWS Elastic Beanstalk & Devops 網站維運實戰

Day04 - Elastic Beanstalk 操作說明(1)

在三天的概述後再來就是要進入到正式的操作說明

01

登入AWS帳號

02

選擇region(地區),基本上依照個專案還有網站需求的不同而選擇不同的地區

額外說明
  1. 您可能在AWS官方網站上面看到還有中國的機房,但是因為中國的政治控制因素,所以如果要用中國結點的話需要在中國AWS另外開立中國專用帳號
  2. AWS 全球基礎設施 官方的說明中有提到AWS 網路節點,網路節點他代表的是AWS Cloudfront(CDN)所提供服務的節點

03

選擇地區之後點選 Compute 中的 Elastic Beanstalk

04

進入到Elastic Beanstalk後會看到起始畫面,點選[Get Started]開始建立服務

05

在Create a web app這部驟當中可分為四個區塊來說明

  1. [Application name]決定你的應用名稱,同時也決定你未來Elastic Beanstalk測試用的URL名稱
  2. [Platform]選擇程式執行所需的語言,如果需要多種程式語言的執行環境就需要客製化處理。
  3. [Application code]上傳您的程式碼或者是使用範例程式
  4. 在Day02有說到需不需要使用到Application Load Balancer的情況,如果不需要直接點選[Create application],如果需要Application Load Balancer則點選[Configure more options]進行進一步的設定
PS:在操作說明上面會以Application Load Balancer作為後續設定的說明

Day05 – Elastic Beanstalk 操作說明(2)

06

點選[Configure more options]進行進階的設定

07

三個紅筐依序說明

07.01

第一個匡

Configuration presets他預設是Free Tier eligible來設定

如果您不希望花到錢就使用預設

但是如果是正式環境就不用管這邊

07.02

第二個匡

這邊要注意的是規格類型,基本上他預設都是以最新版本為主,但如果是要比較舊的版本可以點選[Change platform configuration]進行修改,像是預設為PHP7.2 但是可能需要PHP 5.5的狀況

07.03

第三個匡

需注意兩點

  1. Network:如果沒有設定會直接放置於default中,如果要自定義網路設定的需要在此階段就決定放置於哪個VPC中,建議後無法修改
  2. Capacity與Load balancer:Capacity預設為 single instance而不是Load balancer,如果要設定特定的Load balancer類型須在此階段就直接轉換成Load balancer,並進到Load balancer選單當中決定Load balancer類型。這邊的設定是一但建立後就不能修改,所以要預先決定

Day06 - Elastic Beanstalk 操作說明(3)

07.04

基礎調整後畫面如下

基本上只有調整Capacity與Load balancer

08

建立完成後進到Elastic Beanstalk的畫面如下

成功建立的Elastic Beanstalk因該是綠色的。

對於Elastic Beanstalk狀態的顏色如下連結有完整的說明

運作狀態顏色和狀態

PS:有一種連結中沒提到的狀態,當刪除完成的Elastic Beanstalk它會變成淺灰色,這時候他會保留數小時並不會直接消失如上圖中左邊的方格。

09

點選建立完成的EB可以進入到以下畫面

上方可以看到 Environment ID 與 URL

Environment ID:如果您如果想更進階使用CLI來操作這是一個關鍵,反之可能完全無用。

URL:這個是您佈建環境預覽用的URL您可以點選並驗證程式是否正確

下方則是概觀,您可以初步的瞭解到環境資訊以及您環境的即時狀況

左方的各個分頁則是Elastic Beanstalk的參數,在後面依序進行介紹

Day07 - Elastic Beanstalk 操作說明(4)

10

程式上碼的上傳

Elastic Beanstalk 建立之後首先會遇到的第一個問題,程式碼怎樣上傳與怎樣打包。

在還沒結合Devops時我們可以將程式碼打包上傳

從Running Version進入後點選壓縮的檔案進行上傳,支援ZIP或WAR

這邊有個重點是打包的方式

常常有人打包上傳後失敗

原因是因為解壓縮之後是否會產生資料夾

如果要不產生資料夾的最簡單方式

直接進入資料夾底層然後選取底層文件進行壓縮

假設我現在要有個資料夾叫 test

資料夾內有兩個檔案 index.html 與 logo.png

通常大家的習慣是點選資料夾來壓縮

但是這樣上傳之後

http://ElasticBeanstalkURL/index.html 這樣會跳出404

http://ElasticBeanstalkURL/test/index.html 這樣才會顯示出index頁面

這是一個使用Elastic Beanstalk常見的錯誤

不要犯這個錯

在程式碼上傳基本上不會出錯

Day08 - Elastic Beanstalk 操作說明(5)

11

談到了程式碼的上傳就不得不先優先提到 Rolling updates and deployments (滾動環境資訊更新) ,這個功能關係到了您網站在更新時是否會影響USER的使用!

一般來說更新程式的狀況是需要停機的

但是這個狀況在雲端的狀況已經變了

既然我隨時可以要到更多的主機

那何不直接將主機整個更新好之後將舊主機直接替換下來

這樣我的使用者幾乎不會感受到影響

點選 Rolling updates and deployments 下方的 Modify進入編輯畫面

Rolling updates and deployments 說明連結

重點在於 Rolling Updates(滾動更新) 與 Rolling Deployments(滾動部署)兩個的差異

滾動更新指的是在N台以上的主機時每次抽取1~N台來更新

滾動部署則是新安裝好之後將救的主機替換掉

如何更新就取決於對效能的附載多少

如果是7*24的高附載建議是以滾動部署為主

Rolling updates and deployments (滾動環境資訊更新) 這功能是因該最優先啟動的

Day09 - Elastic Beanstalk 操作說明(6)

12

說完了程式更新再來就要來看兩個息息相關的項目

Capacity 與 Load balancer

基本上重點在於capacity,而Load balancer就是做各種附載平衡之用

capacity主要包含著三部分

  1. Auto Scaling Group
  2. Scaling triggers
  3. Time-based Scaling


Auto Scaling Group 是基礎設定 主機附加在哪個網路區域以及主機數量最低及最高的數量

Scaling triggers 依照設定的附載種類來增減主機

Time-based Scaling 排程來修改主機數量最低及最高的數量

基本上這三個部分設定好之後就可以完成自動擴展的設定了

Day10 - Elastic Beanstalk 操作說明(7)

13

Capacity 與 Load balancer 這些服務其實都是建置在一個最關鍵的服務

AWS EC2

在Elastic Beanstalk中他的分類為Instances

點選「Modify」之後進到下方的頁面

其中最重要的是Instance type

這個是掌管你這個Elastic Beanstalk使用的規格

如果您把它點開可以看到非常多的規格

相對應的規格可以參考這個連結:Amazon EC2 執行個體類型

這邊要繼續宣導一個觀念

規格不是越大越好

是可以維持服務且使用率可以維持最少70-80%的使用率是相對較好的

配合著Capacity與Load balancer在需求多的時候要更多的主機

而在人少時也可以釋放主機避免不必要的費用

另外還有一個關係到效能的參數為Root volume (boot device)

建議最少都是使用General Purpose SSD且空間50G以上這樣

在初期運作比較不會出問題

如果您的程式是比較吃IO效能的

您也可以參考連結來選擇您要的類型及大小 Amazon EBS 磁碟區類型

Day11 - Elastic Beanstalk 操作說明(8)

14

Software

這個欄位關係到您效能的調教

Container Options 這個不多說,因為會您環境的語言不同而有不同的參數

主要是這邊有很多關係到log儲存的項目

S3 log storage 與 Instance log streaming to CloudWatch Logs

如果只是單純要儲存

Day12 - Elastic Beanstalk 操作說明(9)

15

Monitoring 與 Security

Monitoring 顧名思義是監控

但是這個要設定在傳統上是頗麻煩的

但是如果是Elastic Beanstalk要監控的話其實蠻簡單的

點入Monitoring之後可見下圖的畫面

這邊看以多加選擇來監控您所有主機的狀態

在監控上除了記憶體之外都監控的到

如果要多加記憶體需額外在環境上再加以設定留置後面說明

比較特別的是說『Health event streaming to CloudWatch Logs』可以將Elastic Beanstalk的狀況也以log的方式存放

當然這對排除故障沒有特別幫助

但是對於長期需要監控環境的人來說是可以長久做記錄追蹤的

Security 當然就是安全性設定

這邊來說如果您的程式碼需要呼叫AWS 的其他服務

這邊可以讓您以role來設定權限

也可以讓您對您的EC2有可以進去的方式『EC2 key pair』

Day13 - Elastic Beanstalk 操作說明(10)

15

Managed updates

Managed updates

這個功能有有內有很多很有趣的地方

這裡面其實分成三個部分

  1. Minor update
  2. patch update
  3. Instance replacement

Minor update

這個比較單純就是環境需不需要定時的更新到最新版本,基本上傳統的IT人員都不會啟動這個以避免更新之後有程式碼不相容之情況。

patch update

這個就是必開的部分,避免已知漏洞沒補到造成資安問題

Instance replacement

這個功能我幾年以來都認為他是一個沒啥用的功能

直到這幾個月才學習到一個名詞叫做『生命週期』

告訴我這個需求的客戶只告訴了我一句話

沒有攻擊不破的主機

但是如果我每天都換新主機

這樣他要駭入我的主機當作跳板也會很辛苦

這可以避免很多不必要的麻煩

同時也可以減低很多被拿去攻擊別人的風險

Day14 - Elastic Beanstalk 操作說明(11)

16

Configuration 這個也差不多說完了

接下來維運的關鍵功能 Logs

這個功能可以將現有的主機的 log 撈出讓您下載

這是一個很棒的功能

可以讓您快速得到您的訪問紀錄

但是如果您有設定生命週期

或者說你有自動擴展跟縮小過

會發現漏掉很多log

主因是他只能撈出現有主機的log

如果主機已經終止了

這個log就會同步離你而去

但是這無損這個功能的方便

如果要有完整的LOG

就要到 Configuration 中的 software

啟用 S3 log storage 與 Instance log streaming to CloudWatch Logs

Day15 - Elastic Beanstalk 操作說明(12)

17

今天主要來說 Health 與 Monitoring

Health

主要是來顯示主機狀態,但是如果部署出問題他會是一個很關鍵的功能。

因為可以從這邊得知道部署失敗的主機的狀況

以利排除問題

我這邊遇到的問題其實蠻多元的

通常都是客製化的YAML寫錯

這時候就可以利用這功能快速排除問題

Monitoring

這邊可以監控的東西包括EB健康度、響應時間、連線數、CPU、網路資訊

這些都可以在這邊看到

但是如果要監控記憶體

需要另外客製化將它存放到cloudwatch中在拉成報表

Day16 - Elastic Beanstalk 操作說明(13)

18

今天主要來說 Alarms 與 Managed Updates

Alarms

這個功能其實就是設定參數來發出告警訊息

但是因為Elastic Beanstalk是集合式服務所以在設定上是需要集體的設定

個別的主機設定上設定可能因為主機的汰換所以可能間控告警失效

如果要設定告警基本上還是在這邊設定會是比較好的

Managed Updates

這個功能其實就是列表Configuration中的Managed updates還有主機手動汰換更新的紀錄

這邊可以看到您的歷史更新紀錄以及主機的替換歷史

這是補足相關主機汰換歷史的地方

而這邊有一點需要注意的是如果是Configuration的Rolling updates and deployments汰換下來的主機這邊也看得到記錄!

Day17 - Elastic Beanstalk 操作說明(14)

19

今天主要來說 Events 與 Tags 並來為 Elastic Beanstalk 做個總結

Events

這邊是記錄各種Elastic Beanstalk有狀態變動時的紀錄

比如現在出現嚴重的4XX,新的Code部署失敗等等的問題

是用來最快速的問題查修之用

Tags

以Tag來說他是個很重要的服務 尤其是在於這個整合式服務。

如果沒有tag很容易在環境複雜的狀態之下 如果我有多台獨立的EC2與Elastic Beanstalk

是有可能操作機器的時候有錯誤的

加個Tag可以讓您可以快速辨識各個服務當中哪些是屬於哪個Elastic Beanstalk

總結

今天很剛好去拜訪一個用Elastic Beanstalk用不少的客戶(每月$3K以上)

再談她們新需求的時候

他們說出的點很值得維運人員來參考

客戶的IT:這個系統我希望他放在EB上,對我這邊的維運起來比較方便,我要抓log不用使用文字介面點一下就有,還要等你們的工程師去撈資料出來給我,實在是很不方便。還有如果不用EB整套系統自己建你有辦法如期完成自動擴展且監控跟自動化要完全嗎?

在對於高手上來說Elastic Beanstalk真的是一個綁手綁腳的服務

限制很多又要了解他整體機制

自己建立可能還比較快

但是對於90%的維運人員來說

他們沒辦法去維運太大的架構

這時候Elastic Beanstalk就會是個很方便的選項。

完整度有時候真的不是絕對的,對於維運層面來說,可以維運的系統才是好系統。

Elastic Beanstalk在這個方面來說是個非常強的解決方案