Posts

終於到了倒數第二篇文章了，今天來介紹雲端付費相關的計畫，透過一些小技巧，可以減少在雲端上的很多開銷哦！ 首先要介紹的是 Google Cloud Pricing Calculator，透過計算機，我們可以快速的估計機器的相關成本。 Compute Instances 的 VM，在啟動一段時間後，如果 CPU 使用率或 Memory 使用率一直很低，Google Cloud Console 上也會有建議，可以依照建議修改自己的機器配置。VM 的計價方式也有一些優惠，如果 30 天內持續租用，可以獲得較多的優惠！而如果是批次性運算的程式，沒有非常大的即時性需求，也可以試著採用 Preemptible VM instances。 儲存相關的話，VM 的硬碟是可以在開機狀態下進行擴展的，所以不需要一開始就開的非常大，可以減少不少的開銷。也可以比較標準硬碟與兩種 SSD 的方案，是否真的有這些需求。Cloud Storage 若要存放長期，極少存取的備份檔案，可以優先的採用 Nearline 或 Coldline 、 Archive 等方式。 我們也可以結合 Cloud 的 Monitoring 相關服務隨時監控各種服務的狀態，如有閒置或不合適的情形發生，就即時的進行處理。

在網路世界中，安全永遠是最最重要的事情，而雲端安全當然也不例外。任何的安全問題都來自於人為的疏忽，部分雲端上面會遇到的安全問題，在地端的機器上也會遇到，例如常見的 OWASP TOP 10 上的網路攻擊，或是 DDoS 等。除了這種面對駭客的攻擊之外，我們也要注意公司內的意外內賊部分，如這則新聞，三立電視的離職員工透過 Tor 返回原公司的 AWS 帳號中刪除檔案。 今天我主要會介紹的是 Google Cloud 的管理層面，有哪些可以注意的地方，這邊會介紹人、機器與網路三個層面。 人 人的問題為例，最最重要的就是 IAM 相關的管理，身為一個雲端的管理者需要使用資料夾的方式管理公司內的各個部分，並且掌握「保持最低權限」的原則，盡量的讓使用者在可以順利做事情的最低權限，特別注意 Owner 與 Editor 的權限不能無止盡的發。而當公司人員掉離部門或離開公司後，應該要立刻修改它的 IAM Rule。 機器 機器相關的問題，一樣回到 IAM 上，我們需要確保每台機器的 Services Account 權限是否合宜，是否有可能使用者或惡意的攻擊者從低權限的機器，藉由 Services Account 的 Rule 而橫向移動到其他抬高權限的機器之中。如果是自己管理的作業系統，需要確認作業系統是否有安全性的更新需要進行修補。而部屬的程式上的安全則暫時不在今天雲端的討論範圍內，可以參考我隔壁棚的滲透測試文章。 網路 網路層面的安全其實一樣基於「最低權限」的原則，一台不需要聯外的伺服器就不要給它 Public 的 IP，而需要對外的服務也需要透過防火牆來限制 Port Forwarding；可以透過 Google Cloud 的 Load Balancing 進行 DDoS 的檢測，並透過 Cloud CDN 或 Cloudflare 等 CDN 服務進行防禦。Google Cloud 也有提供 Cloud Armor 與 WAF 等服務保障網路層面的安全。

其實這次就已經有一個鐵人賽組別完全是 DevOps 了，如果對於這個領域想要比較深入的了解，可以去看該組大大們的文章。我在這邊只打算輕鬆的介紹一下 DevOps 的概念。DevOps 是 Development 跟 Operations 的組合詞，重點是透過一系列的 pipeline 完成自動化的軟體開發與維運，可以簡單的交付軟體與變更架構。 講到 DevOps，首先一定要提到的就是 Continuous Integration 、 Continuous Delivery (CI/CD) ，持續性整合與部屬。簡單來講，就是將程式碼的 Deploy 流程給自動化。而 CI ，持續整合，主要是透過自動化的 Build 程式，確保不會產生環境版本不一致的問題；程式也可以透過 Unit Test 的方式自動化的檢察功能是否正確。CD 持續部屬，則是自動化的將程式碼給 Deploy 到實際環境中，確保每次的更新都可以很順暢。 以 Google Cloud 為例，我們可以將程式碼統一上傳至 Cloud Source Repositories 進行管理。接著，我們可以使用 Cloud Build 對程式碼進行編譯，或包裝成 Docker 的 Image。透過 Build Trigger 追蹤 Repositories 是否有更改，如果有任何的更動就自動化的觸發 Cloud Build。最終， Build 出來的 Container 可以儲存在 Container Registry 中。 在 DevOps 的環境中，我們也可以透過 Jenkins 等程式進行自動化的建置，Jenkins 也可以在 Google Cloud 的 Marketplace 直接的進行安裝，而管理的過程，我們也可以透過 Google Kubernetes Engine 進行管理。蒐集 Log 的部分，也可以透過 ELK (Elasticsearch、Logstash、Kibana) 進行有效率的資料蒐集與視覺化。 ...

在前幾天的 App Engine 與 K8S 中，或許我已經大致的提過 Micro Services ，今天來試著更詳細的介紹 Micro Services 的概念。 Micro Services 不限於任何的程式語言，無論 Python、Node.JS 或 Go 都有辦法實現，它最大的特色就是「模組化」，把一個大程式給切割成一塊一塊的模組，方便維護與管理，當面對一個非常龐大的系統時， Micro Services 也可以快速的定位發生的問題。 與 Micro Services 相對的是 Monolithic application 單體式應用程式，也就是將所有的功能全部寫在一起，這種方式以連接角度而言，設計會比較單純與簡單，開發時程上也會比較快。但當整個系統日益增大，則維護上會較為困難。 相較於單體式程式，微服務還有另外一個特色是可以快速的將任何一個模組進行擴展，假設我們有一個銷售網站，而微服務切分了物品的展示前端，與實際購買，處理訂單的後端。在雙 11 等活動時，假設我們已知大多數的客戶已經將需購買的商品加至購物車，這種情形下，我們就可以單純的透過 K8S 的 Scaling 相關設定，設定擴展銷售後端的模組，而不需要連同前端一起進行擴展，減少租用機器的費用。 微服務最大的特點就是每個服務應該獨立自主，因此服務間最好需要有獨立的資料庫，服務間唯一的溝通方式是透過 API (最常見的是透過 RESTful) 進行交互。 12 Factor App Design 基於 Micro Services 設計的 SaaS 最佳實踐方式，目前最有名的是 The 12-Factor App ，關於相關的介紹可以參考去年 Miles 大大的鐵人賽文章。簡單來說，我們的開發過程可以遵守 12 Factor 的方式，有效的開發方便移植、擴展的程式。而這 12 Factor 依序是： Codebase- 使用版本管理系統，例如 Git。 Dependencies- 使用套件管理系統，例如 pip、npm。 Config- 不要將 API Key 等機密資料放至於程式碼字串中。 Backing services- 資料庫，快取等資源可藉由 URL API 訪問。 Build, release, run- 嚴格分離程式碼的 Build 與 Run 階段。 Processes- 一個程式可分為一個或多個 Process，每個 Process 應為 stateless。 Port binding- 透過 Port binding 方式讓程式可以聯外。 Concurrency- 透過 Process Model 進行水平擴展。 Disposability- 快速啟動，追求穩定性，並可以優雅的關機。 Dev/prod parity- 保持開發與部屬的環境一致。 Logs- 將 Log 透過 event Stream 輸出。 Admin processes- 將維護與管理視為一次性的任務。

今天來介紹雲端的管理，常常出現的三個名詞，在先前的文章中，我應該也有使用過了一部分。這三個名詞長的很像，而背後的意義卻有滿多的差異，都算是滿重要，滿常用的的名詞哦！這些算是服務級別的術語，描述服務常見需要衡量的指標。 Service Level Indicators , SLI SLI 被稱為服務級別指標，我們可以理解成它是我們需要衡量一個服務的哪些指標。例如一個服務的網路吞吐量，延遲時間與錯誤率等。在 SLI 中，我們只需要訂出，我們需要衡量哪些東西就好，而剩下的則是交由 SLO 進行規範。 Service Level Objectives , SLO SLO 被稱為服務級別目標，通常是提供服務者需要明確定義給客戶的量化指標。這邊我們就可以定義 SLI 必須要符合的規定 Range，例如我們要求一個網頁在台灣地區的回應時間必須小於 10 毫秒，等明確的定義。 Service Level Agreements , SLA SLA 則是服務的級別協定，通常是服務商與客戶之間正式需要簽的合約，保障系統的穩定性。而服務商如果沒有達到指定的 SLA 則可以被客戶要求賠償，而 SLA 會涵蓋的內容相對而言最具有限制性。 我們以 Google Cloud Storage SLA 網頁上提到的，來觀察它的 SLI 、 SLO 以及 SLA 分別是什麼。例如 Standard storage 的 Monthly Uptime Percentage >= 99.95，這就算是一個 SLA 的規定。而它們的也有在下文題到，如果沒有達到指定的 SLO 會給予賠償等。

對於初學者來說，自動化的部屬真的是一件非常累人的事情，從雲端架構開始就有一大堆東西要學，再加上昨天提到的 IaC，如果真的要講應該也可以寫成 30 天分的教材QQ。如果我們只是一個非常非常淺的初學者，有沒有什麼方法可以快速的自動化部屬服務到 GCP 中呢？當然有的，這就是 Marketplace。 我們可以很簡單的把 Marketplace 想像成 App Store 或 Play 商店，我們想要的服務，有很大的機會都不需要自己重造輪子。舉例來說，我們假設需要架設一個 WordPress CMS 的 Blog，如果透過 Compute Engine，可能會需要先設定系統，安裝 PHP 、 MySQL，再來安裝 WordPress。而如果希望資料庫分離的話，雖然可以透過 Cloud SQL 來處理 MySQL 的部分，不過依然需要處理很多底層的東西QQ。 在 Marketplace 之中，我們可以一鍵的部屬別人設定好的安裝檔，大多數都是透過 Deploy Manager 建置的完整腳本，如上述的 Wordpress，我們可以快速的依照它人設定好的腳本來進行部屬，常見的 MongoDB、ELK 等資料庫也都可以快速的在 Marketplace 中進行部屬。 Marketplace 中，也有包含了 SaaS 等相關服務的方案可以選擇，部分的方案是需要付費的，使用與購買前也需要特別注意哦！

昨天介紹的 Deployment Manager 可以透過 GUI 與 Command Line 的方式管理資源，算是 GCP 中自己專有的功能。而 Google 也支援了 IaC 的常見軟體，例如 Terraform、Chef、Puppet、Ansible、Packer 等。 IaC (Infrastructure as code)，基礎架構即代碼，指的是透過程式碼來對各種基礎設備進行管理與配置，而上述的這些軟體也不僅適用於 GCP 中，可以基本上將相同的代碼做些微的修改，套用到其它的雲端服務商，例如 AWS 與 Azure 等，在不同服務商間轉換設備相對而言會非常的方便。 透過 IaC，可以減少繁複的操作一模一樣的事情，也可以批次化大量的管理設備，對於 DevOps 等環節而言會方便非常多。 以 Terraform 為例，通常我們會使用 YAML 檔案設定各種部屬的基礎設備資訊。但例如 VPC 與防火牆 Rule，這些 IP 位置則比較像是一個變數，這種時候我們可以透過 Jinja 的 Template Engine 進行設定。

從今天開始的內容，會相對比較簡單一點點，我們來介紹一些自動化的部屬方式。假設說，我們設定好了一系列的 Instance 、 VPC 架構 、 防火牆規則等相關的服務，未來一個方案需要重新利用時，就可以透過 Deploy Manager 與明後天會介紹到的 IaC 等方式進行快速的部屬。 我們部屬 Google Cloud 的服務，通常會使用 Cloud Console、Cloud Shell 或 SDK，在還沒有學習到 Deployment Manager 前，如果我有自動化需要部屬大量的設備，通常我會直接把需要部屬的內容寫成 Bash 的 Shell Script ，並透過 Cloud Shell 執行，這種方式很暴力，但很有用 XDD。 Deployment Manager 屬於 Infrastructure Automation Tool，可以透過 GUI 的介面，在 Cloud Console 對於不同的資源在部屬前進行規劃，也可以將各種資源們建立成模板，方便重複使用。Deploy Manager 背後使用了各種 GCP 底層的 API 進行設計，基本上可以支援所有 GCP 的服務部屬。

Load Balancer (負載平衡器) 與 Auto Scaling 都算是雲端設備中非常重要的一部分，負載平衡器可以將流量分散到多台不同的機器，而這些服務對外只需要一個 IP 即可。透過 Load Balancer ， 我們可以增加資料的可用性與穩定性，並且可以透過 Auto Scaling 的方式自動增減在 Load Balancer 後的伺服器數量。 在 GCP 中， Load Balancer 被分為兩種，Global 與 Regional。Global 的 Load Balancer 有 HTTP(S)、SSL Proxy 與 TCP Proxy，在全球的使用者可以使用相同的 IP ，存取到就近國家的主機，減少傳輸的延遲；Regional 的 Load Balancer 則有 Internal 與 Network Load Balancer，Internal Load Balancer 基於 Google 開發的 SDN Andromeda進行實作，而 Network Load Balancer 則使用 Maglev 的分散式系統進行實作。 Instance Template / Group 在開始講 Load Balancer 之前，我們需要先了解 Instances Group，在假設我們 Load Balancer 背後每一台機器都是一樣的前提下，我們會需要建立很多台內容完全一樣的 Compute Engine VM Instances，這種狀況下，我們就可以使用 Compute Engine 中的 Instance Template，作為 Load Balancer 未來開啟的模板。Instance Template 就像是一個 VM 的模板，他的建立方式與建立 Instances 將近完全一樣，設定 VM 的 Image、Startup Script 等。 ...

今天來與各位介紹雲端的 互連網路(Interconnect) 與 對等互聯(Peering) 相關服務。Interconnect 與 Peering 最大的差別在於，Peering 屬於 OSI 第 3 層的連接，而 Interconnect 屬於 OSI 第 2 層的連接。而他們又再分為了 Direct Peering、Carrier Peering、Dedicated Interconnect、Partner Interconnect。 對等互連 Peering 直接對等互連 (Direct Peering) 可以在自己的連結上透過 BGP 來切換與 Google 的連線，可以讓自己的企業區域網路直接的連接上 Google 的邊際網路。 電信業者互連 (Carrier Peering)，透過電信業者作為中介，進行連接。 互連網路 專屬互聯 (Dedicated Interconnect)，提供了直接連線到 Google 的專用網路。可以選擇 10 GBps 或 100 GBps 的專線連接上 Google。也可以使用支援 RFC1918 的 IP Address 進行連線。 合作夥伴互聯 (Partner Interconnect)，如同電信業者互連，可以藉由電信業者、Google的合作夥伴進行連線。 比較 關於這些連接方式的詳細比較，可以參考下圖： (圖片來源：Connecting to Google Cloud: your networking options explained https://cloud.google.com/blog/products/networking/google-cloud-network-connectivity-options-explained)