2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day28 - 總結! (2) Elastic Beanstalk的建立 今日的主題是Elastic Beanstalk的建立 快速利用15分鐘的影片來跟大家複習Elastic Beanstalk建立有哪些要注意的地方 以及哪些地方可以快速省略帶過 有些可能是看文件速度比較慢 所以使用影片帶大家最做一次可以快上許多 這是第一天份 後面兩天會是以Elastic Beanstalk調整以及Devops調整為主 全篇好讀版
2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure
Day28 - 常用服務 5.Redis(3) 在上篇建立環境的畫面當中 其實建立的部分跟 MYSQL的部分很雷同 差異性主要是在定價層與可用性區域 可以點選(檢視完整定價詳細資料) 可得到詳細的說明 基本上是依照您所需要的叢集、可靠度、連線數、快取區域大小四個依序來做選擇 1. 如果需要建立叢集與做資料持續性那就直接從『P進階』開始選起 2. 如果需要可靠度那就直接看『P進階』『C標準』 3. 再來是連線數的不同就可以直接看是要看哪個規格 4. 最後是看上列三項選到的規格快取大小夠不夠用 如果確認完規格 就可以點選建立來開始服務了
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day27 - 總結(1) 與其說是總結倒不如說是把整個流程快速的串過一遍 就像Kubernetes之餘container Elastic Beanstalk 對於 EC2 也是相同的概念 他是一個很棒的自動化部署環境 只是跟Kubernetes一樣他需要很多的時間來去了解與熟悉 但是好險他是基於比較多人懂的EC2 不像現在很多接到的需求是希望能協助上Kubernetes 但是客戶連container都不了解 但是Elastic Beanstalk概念就比較好理解 因為他就是把大家常用的web服務建置自動化 在進而結合Devops的概念 如果要了解自動化跟Devops的概念 其實非常建議大家來看一本故事書 『鳳凰專案』 如果讀完這本書 或許你可以得到一些該如何開始的想法 Day28-30 會以影片的方式把這20多天來的純理論 直接建置一遍 讓不喜歡看理論的人也可以快速的將這些東西上手
2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure
Day27 - 常用服務 5.Redis(2) 在AZURE中要怎要找到Redis這個服務並建立? 這服務算是database的服務 但是可能是相對冷門 所以用點的基本上點不到 如果點下方圖片的路徑還是會看不到 所以直接點選查看全部來收尋會比較快 鍵入 Redis Cache 就可以找到了 點選進入之後可以看到介紹 繼續點選建立就可以開始建立Redis了 建立的畫面如下
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day26 - AWS Devops(9) 實際建置 06-2 Step 4 Add deploy stage 這邊可以看到他可以部署到的地方有不少 這邊我通常來說都是選擇Elastic Beanstalk 因為我很常幫客戶建立Elastic Beanstalk 但是如AWS CodeDeploy也是蠻常見的 因為他很常用來設置在EC2或者是混合雲上 如果是對Amazon Elastic Container Service 也可以嘗試做部署 Step 5 Review 最後的環境確認 如果確認沒問題就可以點選 Create pipeline來進行建立 確認結果 再點選Create pipeline之後會進到下個頁面 這時就會開始自動化的進行確認即部署了
2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure
Day26 - 常用服務 5.Radis(1) Redis是目前中大型服務很常見的快取系統 但由於Redis在台灣早期並不常見 台灣在Redis懂自建且會維護的少之又少 但是如果是在雲端上PASS化的Redis就很適合大眾做使用 只需要點一點就可以快速建立一個有HA且可靠的Radis服務 Azure Radis 官方網站 如果要學習Redis技術 推薦去中國的redis論壇看 論壇連結 台灣在這段技術上面落後中國不少 不過也是跟市場規模有關 但是如果在雲端或者是國際市場達到一定規模 redis是不可少的工具
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day25 - AWS Devops(8) 實際建置 06-1 在建立AWS Codecommit 之後 只需要使用aws codepipeline就可以快速將服務串接起來 依樣回到新版的畫面 點選「Create pipeline」即可開始建立 Step 1中 只需要填入Pipeline name就可以直接點選Next進到下一步 Step 2 Add source stage 點選來源在這邊就是選擇AWS Codecommit 並選擇哪個GIT跟分支 Step 3 Add build stage 看需求基本上如果初學者我建議先跳過選「Skip」
2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure
Day25 - 常用服務 4.mysql與postgresql(4) 06 如果是AZURE SQL Database for PostgreSQL建立的畫面如下 其實跟SQL Database for MySQL是沒有啥不同的 跟MySQL依樣填好就點選建立 07 在建立完畢之後進入 AZURE SQL Database for PostgreSQL 你會發現這邊的設定跟Mysql一樣沒啥太多的不同 主要的差異會在「伺服器參數」上因為資料庫的類型不同有所差異 (這句根本是廢話) 同樣的您也可以在連線安全性設定好ip之後直接拿工具來連入
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day24 - AWS Devops(7) 實際建置 05 AWS Codecommit 操作方式 這個如果要說篇幅實在有點長 建議可以參考此連結的GIT教學 Git官方教學 如果讀完了Git官方教學代表你對GIT操作有一定程度的瞭解了 那就可以來看 AWS Codecommit官方的介紹文件 連線方式可以參考上篇文章的位置 來進行連線 需特別注意的是MAC用戶 只能用SSH連線 http問題很多 連線方式可以參考 在 Linux, macOS, or Unix 上對 AWS CodeCommit 儲存庫建立 SSH 連線的設定步驟 在有基礎連線之後 接下來就是各種GIT軟體的挑選了 種類真的很多 基本上看公司大多數開發者的習慣配合比較不會有問題
2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure
Day24 - 常用服務 4.mysql與postgresql(3) 03 建立完成後的畫面 04 在設定面上面來說其實沒什麼特別 主要要注意的地方是「連線安全性」 他預設是不給任何IP進行聯入的 如果要連入就需要新增IP 這邊新增ip基本上比較笨一點 但是勝在簡單易懂 另外有ssl加密的需求話可以啟動 但是台灣跑單幫的程式設計師好像很不流行寫加密 如果要啟動的話 要確認程式設計師有沒有要幫你改程式 05 另外要注意的是「伺服器參數」 這邊需要注意的是在auzre上面能調整的參數就這些 所以如果沒有可以選擇的話 那就是不能調整
2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰
Day23 - AWS Devops(6) 實際建置 實際建置上會以 AWS CodeCommit + AWS CodePipeline 進而部署在Elastic Beanstalk 01 首先就來看整個的建置過程 由於最近介面改成新版所以有些東西位置都大改了，跟原本的介面差蠻多的 02 點選 Create repository 03 填寫Repository name後就可以點選Create建立專屬的Git庫 04 這樣就建立完成了 這時候就可以看到要如何連結的方式 建議都是以SSH為主 全篇好讀版
2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure
Day23 - 常用服務 4.mysql與postgresql(2) 在AZURE中建立SQL Database for mysql與SQL Database for mysql不是一件困難的事情 01 依序點選建立資源 --> Database --> 選擇資料庫 這邊要注意的是有人可能會問說 MariaDB 為何要打XX 這時候要說一件非常重要的事情 微軟預覽的東西 穩定度很差 除非系統完全不重要 不然不建議放置在預覽的服務當中 02 假設以SQL Database for mysql 為例 這邊就直接直覺的填入就不會有問題 比較特別的是要點入定價層中 定價層主要是在效能上的不同他的調整幾乎無中斷時間 所以建議是開小規格慢慢評估拉大就好 備選備援選項這邊就比較有趣 官方介紹網頁 這邊主要的差異是在於說可不可以在其他的機房回覆的差別