2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day15 - Elastic Beanstalk 操作說明(12) 17 今天主要來說 Health 與 Monitoring Health 主要是來顯示主機狀態，但是如果部署出問題他會是一個很關鍵的功能。 因為可以從這邊得知道部署失敗的主機的狀況 以利排除問題 我這邊遇到的問題其實蠻多元的 通常都是客製化的YAML寫錯 這時候就可以利用這功能快速排除問題 Monitoring 這邊可以監控的東西包括EB健康度、響應時間、連線數、CPU、網路資訊 這些都可以在這邊看到 但是如果要監控記憶體 需要另外客製化將它存放到cloudwatch中在拉成報表
2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure
Day15 - 常用服務 3.Web service-(7) 建置流程 06 今天來談『app service 方案』的功能上最關鍵的相應增加以及相應放大 很多人會問說 這功能不是在『app service』上嗎？ 這也沒錯 但是『app service』中看到的相應增加以及相應放大其實是連結到『app service 方案』 因為這兩個功能是硬體層 如果您的『app service 方案』上有10個『app service』 只要更改其中一個的相應增加所有的設定就會一並更改 所以直接從『app service 方案』上面改才是正途 相應增加 (App Service 方案) 這邊用來修改主機大小以及附加功能 這邊要注意的是類型別選越高越好 會非常貴 基本上使用服務就是夠用就好 如果有時候需要比較大的資源用相應放大就好 相應放大
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 - Everything on Azure - LAMP系統營運者 on Azure
Day14 - 常用服務 3.Web service-(6) 建置流程 05 在app server 方案中能調整的東西不多 主要是可以得知不同的資訊 APP 這功能很單純就是顯示有多少的app server附加在您的app server上 以功能上很簡單 但是在IT的角度上又是不可缺少的 檔案系統儲存體 在這邊很可以說很簡單的就只是看硬碟剩下多少空間 但是這邊暗藏了一個巧思 各家雲端在思考這類的產品時 似乎都沒考慮到open source的族群 通常決大部分的open source對於本機資料夾的共用問題 導致上到雲端服務時還是只能保留舊結構而不是讓他可以自動擴展 在app server中 不管是您擴展到幾台主機他的硬碟都是直接掛載同一個儲存空間 所以不需要額外考慮open source的相容性 直接丟上去就對了
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 - Everything on Azure - LAMP系統營運者 on Azure
Day13 - 常用服務 3.Web service-(5) 建置流程 03.07 如果選擇好之後就可以直接建立 建立大約需要10多分鐘 建立完成之後畫面如下 可以發現我們有個 AppService 與 AppService方案 就如同前幾篇所說的這是硬體跟web server上的不同 再來就可以進入開始設定了 04 首先先來看AppService方案 一進到AppService方案您就看可以看到關鍵的監控指標 1. CPU 2. 記憶體 3. 網路傳入 4. 網路傳出 名字翻譯上跟我列出的不同，但是意思有到就好 有關硬體的關鍵數值都可以在這邊看到並調整硬體的規模
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 - Everything on Azure - LAMP系統營運者 on Azure
Day12 - 常用服務 3.Web service-(4) 建置流程 01 點選建立服務並尋找Web APP 02 點選『ＷebAPP』開始建立Web 應用程式 03 依序輸入關鍵參數 03.01 應用程式名稱，這是這個Web應用程式的名字同時也是設定測試URL的地方 03.02 訂用帳號跟資源群組這個就依照訂閱方式選擇 03.03 OS，這個參數您可以看到有windows或者是linux，這就看您的作業習慣來操作 他的設定上面有很大的落差，如果您是linux的管理者因該不會誤選到windows 03.04 跳過發布中的Docker基本上我們都會選擇代碼 如果要講Docker篇幅會超級長 03.05 App Service 方案與地區 這邊一定要點近來選擇地區或者是您現有要使用的方案 不然開出來的環境基本上一定會是在美國 03.06 如果您在3.4那邊選擇發佈 則選單中可以選澤您主要要職型的程式類型 這邊有個重點 您在上方圖片看到的.net是linux用的，
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 - Everything on Azure - LAMP系統營運者 on Azure
Day11 - 常用服務 3.Web service-(3) 必須了解的前期知識 AppService 與 AppService方案 的差異 在之前只稍微提到了兩個的差異 但是他們兩個各自代表著不同的東西但又息息相關的東西 一 AppService方案 代表 -> 硬體 AppService 代表 -> web服務(IIS or Apache) 二 這代表著AppService一定需要放置在一組的AppService方案中 但是一組的AppService方案上面可以放置很多的AppService 三 關於web服務的調整找AppService 關於硬體大小的調整找AppService方案 四 AppService可以隨時更換所屬的AppService方案 只需付出1分鐘不到的中斷段時間 五 AppService方案中 如果是數量上與同系列的機器大小調整不會發生中斷之狀況 只有AppService方案方案中系列的修改才會牽扯到中斷的狀態 六 雖然他是伺服器組 但是他可以有固定的IP組 七 他不可以附加到 虛擬網路之中並獲得內部IP 他不
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 - Everything on Azure - LAMP系統營運者 on Azure
Day10 - 常用服務 3.Web service-(2) 關鍵成本計算方式 1. 計費單位是以App service Plan為單位而不是App service 2. 我可以很多個網站共享同一個App service Plan的資源 在這張圖中可以看到 我開了一個方案 但是有兩個app service 雖然在這個方式來說其實對於linux工程師來說 都是很容易設定的 但是在AZURE我們可以將設定的工作減少 而且主機的擴展定不用靠自己來做 自動擴展是內建的功能 只要利用這些功能就可以簡單地提高資源利用率