2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day18 - AWS DevOps(1) 01 如果要粗略的了解AWS DevOps 可以大約看一下下列的連結 DevOps 與 AWS 這邊來說最重要的一點就是這張圖片 這邊包含了持續部署的相關服務 但是您可能會很感覺整個說明的很模糊 實際上的流程如果是以這張網路上找到的圖可能是比較好的流程 以生產作業來說 整個流程就是 生產(產生程式碼) -> 測試(測試程式碼是否合乎規格與需求) -> 正式組裝(Deploy) -> 出產(服務運作) 如果把它全講可能又是一年的鐵人賽了 基本上介紹必要的東西 做最基礎的DevOps這才是跨入這領域最重要的一步
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
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整套
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day16 - Elastic Beanstalk 操作說明(13) 18 今天主要來說 Alarms 與 Managed Updates Alarms 這個功能其實就是設定參數來發出告警訊息 但是因為Elastic Beanstalk是集合式服務所以在設定上是需要集體的設定 個別的主機設定上設定可能因為主機的汰換所以可能間控告警失效 如果要設定告警基本上還是在這邊設定會是比較好的 Managed Updates 這個功能其實就是列表Configuration中的Managed updates還有主機手動汰換更新的紀錄 這邊可以看到您的歷史更新紀錄以及主機的替換歷史 這是補足相關主機汰換歷史的地方 而這邊有一點需要注意的是如果是Configuration的Rolling updates and deployments汰換下來的主機這邊也看得到記錄！
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day15 - Elastic Beanstalk 操作說明(12) 17 今天主要來說 Health 與 Monitoring Health 主要是來顯示主機狀態，但是如果部署出問題他會是一個很關鍵的功能。 因為可以從這邊得知道部署失敗的主機的狀況 以利排除問題 我這邊遇到的問題其實蠻多元的 通常都是客製化的YAML寫錯 這時候就可以利用這功能快速排除問題 Monitoring 這邊可以監控的東西包括EB健康度、響應時間、連線數、CPU、網路資訊 這些都可以在這邊看到 但是如果要監控記憶體 需要另外客製化將它存放到cloudwatch中在拉成報表
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day14 - Elastic Beanstalk 操作說明(11) 16 Configuration 這個也差不多說完了 接下來維運的關鍵功能 Logs 這個功能可以將現有的主機的 log 撈出讓您下載 這是一個很棒的功能 可以讓您快速得到您的訪問紀錄 但是如果您有設定生命週期 或者說你有自動擴展跟縮小過 會發現漏掉很多log 主因是他只能撈出現有主機的log 如果主機已經終止了 這個log就會同步離你而去 但是這無損這個功能的方便 如果要有完整的LOG 就要到 Configuration 中的 software 啟用 S3 log storage 與 Instance log streaming to CloudWatch Logs
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
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 這個功能我幾年以來都認為他是一個沒啥用的功能 直到這幾個月才學習到一個名詞叫做『生命週期』 告訴我這個需求的客戶只告訴了我一句話 沒有攻擊不破的主機 但是如果我每天都換新主機 這樣他要駭入我的主機當作跳板也會很辛苦 這可以避免很多不必要的麻煩 同時也可以減低很多被拿去攻擊別人的風險
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
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』
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day11 - Elastic Beanstalk 操作說明(8) 14 Software 這個欄位關係到您效能與log服務 所以他是很重要的 Container Options 這個不多說，因為會您環境的語言不同而有不同的參數 主要是這邊有很多關係到LOG儲存的項目 S3 log storage 與 Instance log streaming to CloudWatch Logs 這兩個服務有 1 如果只是單純要儲存選擇S3 log storage 他就只是把LOG定期去存放到S3當中 但是因為他不會隨著你服務的關閉或出問題而消失 所以非常建議一定要開這個 2 如果需要有即時分析查詢的介面則是用Instance log streaming to CloudWatch Logs 使用CloudWatch Logs主要是方便而且可以配合AWS的一些LOG分析服務來進行一些更進階的分析 如果您想分析你的服務人流分析 這是一個可以進行實作的開頭服務
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
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效能的 您也可以參考連結來選擇
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
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 排程來修改主機數量最低及最高的數量 基本上這三個部分設定好之後就可以完成自動擴展的設定了
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day08 - Elastic Beanstalk 操作說明(5) 11 談到了程式碼的上傳就不得不先優先提到 Rolling updates and deployments (滾動環境資訊更新) ，這個功能關係到了您網站在更新時是否會影響USER的使用！ 一般來說更新程式的狀況是需要停機的 但是這個狀況在雲端的狀況已經變了 既然我隨時可以要到更多的主機 那何不直接將主機整個更新好之後將舊主機直接替換下來 這樣我的使用者幾乎不會感受到影響 點選 Rolling updates and deployments 下方的 Modify進入編輯畫面 Rolling updates and deployments 說明連結 重點在於 Rolling Updates(滾動更新) 與 Rolling Deployments(滾動部署)兩個的差異 滾動更新指的是在Ｎ台以上的主機時每次抽取1～N台來更新 滾動部署則是新安裝好之後將救的主機替換掉 如何更新就取決於對效能的附載多少 如果是7*24的高附載建議是以滾動部署為主 Rolling updates and deploy
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
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常見的錯誤 不要犯這個錯 在程式碼上傳基本上不會出錯