真ㄉ有可能在 30 天內搞懂 Cloud ㄇ ?__?

今天來與各位介紹雲端的 互連網路(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)

Cloud VPN Cloud VPN 可以將自己本地的網路直接的連接到 GCP 的 VPC 網路之中，透過 IPSec 協議進行加密，可以保護資料在網路上傳輸的安全性。 Cloud VPN 屬於由 Google 託管的服務，提供了 99.9% 的 SLA，並支援 Side to Site 的 VPN、靜態路由、動態路由、IKEv1 與 IKEv2 的密碼等功能。 在建立 Cloud VPN 前，我們需要建立本地端的 VPN Gateway 、 雲端的 VPN Gateway 以及兩個 VPN Tunnel， Cloud VPN 的 Gateway 屬於一個 Regional 的資源，因此需要使用一個 external IP 。 本地端的 VPN Gateway 可以是硬體的主機，也可以是軟體的 VPN 服務，安裝在本地或其他雲端伺服器中。 目前 Cloud VPN 的最大傳輸單位 (MTU) 為 1460 Bytes。 Cloud Router Cloud VPN 支援靜態以及動態路由，如果需要使用動態路由，則需要開啟 Cloud Routers 的功能。 Cloud Routers 支援透過 BGP (Border Gateway Protocol) 管理 Cloud VPN Tunnel 的路由。 ...

今天我們來介紹雲端的監控， Cloud Operations Suite 。這個服務以前被稱做 Stackdriver 。雲端的監控總共可以分為，Monitoring、Logging、Error Reporting、Tracing 以及 Debugging。 這些監控相關的程式 (Agent) 支援跨平台，除了 GCP 之外，也可以安裝在 AWS 或是自己的主機上面，這些服務皆有免費額度可以使用。 Monitoring 伺服器的監控是一件非常重要的事情，這是 SRE (Site Reliability Engineering) 最重要的工作。 Monitoring 支援了各種的指標，包含平台、系統、應用程式，可以將圖表、警報顯示於儀表板 (Dashboards) 中。 Logging Cloud Logging 提供分析 GCP 以及 AWS 上的各種事件，Logging 包含了 紀錄的儲存、使用者介面 (Log Viewer) 以及 API，可以透過程式化的方式管理 Log。 與 Monitoring 一樣，我們也可以透過腳本將 Agent 安裝在自己的伺服器中，監控伺服器的網路流量、IP 來源等資訊。如果我們想要 Query 大量的 Logging 資料，也可以使用 BigQuery 等程式來達成。 Error Reporting Error Reporting 可以統計、分析在雲端服務中的各種錯誤，提供了錯誤的通知、儀表板等功能。支援 App Engine 、 Apps Script 、 Compute Engine 、 Cloud Functions 、 Cloud Run 、 GKE 、 Amazon EC2 等平台。當我們使用以上的平台，部屬過程與運行過程發生任何的錯誤，都可以在 Error Reporting 中找到相應的 Log。 ...

Cloud Run 是這次要介紹的最後一種部屬服務方式。它是一種基於 Container 的 Serverless 服務。比起 Google Kubernetes Engine，使用者不需要自己的管理 K8s 的服務。 Cloud Run 背後使用了開源的 Knative 服務，使用者可以直接的使用 Cloud Run 管理自己的 Container。除此之外，它最大的特色是，使用者也可以將 Cloud Run 的服務，搬回自家的 Kubernetes Engine 上進行執行，連接上自己的 VPC。 在使用 Cloud Run 之前，使用者必須先將自己的 Container 上傳至 Cloud Container Registry 中。 Cloud Run 與 Kubernetes Engine 都可以結合一整套的 Google 服務的生態系，達到 DevOps 的功能。舉例來說，我們最終的目標是要部屬一個由 Python 的服務，將程式寫完後，我們可以將程式推送到 Cloud Source Repositories 中，並串接 Cloud Build 的 Trigger，將 Docker 給 Build 起來後，放置於 Container Registry 中，再提供 Cloud Run 進行執行。 Cloud Application Deployment 比較 這幾天，我們總共介紹了 5 種不同，可以部屬自己程式的服務，分別是 Compute Engine、Kubernetes Engine 、 Cloud Run 、 Cloud Functions、 App Engine 。 ...

Cloud Function 是一款 Serverless 的服務，使用者不需要管理伺服器。Google 官方說，它是一種 FaaS (Function as a Services，函式即服務)，它可以透過透過 HTTP 的 API 來基於事件做出相對應的動作。在 AWS 上，最相似的功能是 Lambda。 目前 Cloud Functions 是透過 Node.js 的 JavaScript 進行編寫，並運行在 GCP 中。 Cloud Functions 最主要可以區分成兩個重點 Event (事件) 與 Trigger (觸發)，Event 可以是 HTTP 的 Webhook，Cloud Storage、Cloud Pub/Sub 、 Cloud FireStore 等方式，我們可以收取、訂閱指定的 Event，並設定當 Event 發生後，需要做的事情 (Trigger) 是什麼。 舉例來說，我們如果希望透過 Cloud Storage 建立一個線上的相簿，而相簿通常除了完整尺寸的原圖之外，為了減緩頻寬、加快載入速度，通常會採用縮圖預覽的格式。我們就可以透過 Cloud Functions 來建立一個 Event ，設計為 「當 Cloud Storage 上傳了新的圖片」，則觸發 Trigger 「透過 Function 自動產出一張壓縮尺寸後的縮圖，存放進 Cloud Storage 中」。 ...

今天要來介紹 Google Cloud 中的 App Engine，App Engine 是一款 PaaS 的服務，可以超簡單的進行部屬與維護，使用者也可以專注於開發程式，而不需要煩惱任何關於底層架構的問題。 PaaS 適合用於可擴展的網路應用程式、行動服務的後端等，例如 Chatbot 、輕量化的 API 等服務都很適合可以部屬在 App Engine 上。 App Engine 提供了許多內建的 API，例如 NoSQL 資料存儲、記憶體快取、負載平衡、應用程式 Log 紀錄、身分驗證 API 等。藉由 Security Scanner 的功能， App Engine 可以自動化的掃描與偵測程式的漏洞，提醒開發者進行修補。 App Engine 會透過使用者的流量，自動化的擴展程式後端的伺服器，使用者只需要將程式碼上傳至 App Engine 的管理後臺即可，剩下的問題全部都由 Google Cloud 進行處理。目前，常見的開發環境例如 Eclipse、IntelliJ、Maven、Git、Jenkins、PyCharm 等程式都支援部屬 App Engine 的服務。 App Engine 目前有兩種環境，分別為 Standard 與 Flexible。 Standard Environment 標準的環境可以簡單的部屬使用者的 APP，支援 Autoscale 等功能，相較於 Flexible 便宜不少。它有每天的免費額度可以使用。在標準的環境中，有提供幾個常見的 runtime 供大家使用，包含了 Java、Python、Go 與 PHP。 在使用 App Engine 時，必須符合一定的 Sandbox 規範，例如不可將檔案寫到本地的硬碟中，需要透過資料庫的形式儲存資料；每一個 Requests 最長的 Timeout 為 60 秒；對於安裝第三方的程式、Library 也有限制。因此需要基於 App Engine 的 SDK 進行開發。 ...

昨天簡介完了 Docker 的容器相關內容，今天我們要來介紹的是 Kubernetes (K8S)，其實 K8S 可以介紹的內容真的非常非常非常多，相信隔壁棚 DevOps 也有許多文章，光是 K8S 就可以介紹完整的 30 天。 Kubernetes，念做(哭ㄅㄋㄟ體死)，它在希臘語中，代表的是舵手，駕駛員的意思；做為 Docker 的管理工具，感覺也有一種管理的味道存在(?)。 Kubernets 是由 Joe Beda、Brendan Burns 和 Craig McLuckie 共同創立，而目前主要的維護是由 Google 的工程師負責。而 Kubernets 又難念，又難寫，連外國人都這麼認為，所以就簡稱為 K8s，8是因為 ubernete 剛好有 8 個字。 Kubernetes Kubernetes 可以是為一個高層次的 Docker 抽象化管理器，在最高層級中，Kubernetes 可以透過一系列的 API 對於 Cluster 中的 Node 、 Container 進行管理。 在主從式架構中，我們可以將一個 Cluster 中的內容歸類為兩種元件，Master 與 Node， Master 負責進行控制與管理 Nodes；而 Nodes 則負責執行 Container 的內容。在 Google Cloud 中，每一個 Node 代表了一台 Compute Engine 的 Instances。 GKE Google Kubernetes Engine 簡稱 GKE，是由 Google 管理的的 K8s 引擎，支援 Google Cloud 上各種不同規格的 Compute Engine instances。 ...

我們都知道，Compute Engine 屬於 IaaS ， 而 App Engine 等服務屬於 PaaS，在 PaaS 底下，使用者大多不需要處理系統底層的問題。 但有些時候，我們會希望可以同時擁有 IaaS 與 PaaS 的優點，可以設定部分底層的資源，又希望可以透過雲端平台幫我們自動化的管理，這個時候，就可以使用 Kubernetes (K8S) 的服務，關於 K8S 相關的內容預計將於明天介紹，今天會介紹 K8S 底層的東東： Container。 虛擬化容器與 VM (虛擬機) 非常類似，但是原理上有所差異。通常， VM 會模擬整個電腦硬體、CPU，包含指令集等所有的內容，因此 VM 最被大家詬病的問題就是，需要浪費非常多的系統資源。在 CPU 層面，需要模擬整個電腦硬體，而在儲存層面，也需要安裝整套的作業系統。 容器的虛擬化則是將作業系統層進行虛擬化，與當前在運行的作業系統共用資源，省去了虛擬化硬體的部分，可以達到非常的輕量化。我們可以將自己的服務打包在容器中，未來在搬移時，僅需要將容器移植到其他台電腦，即可快速的部屬各種不同的服務。 Docker 雖然說，Container 的技術不僅只於 Docker，但目前來說，Docker 算是最知名，最通用的一款 Container 技術。 以 Docker 為例，如果我們需要建立一個 Docker 的容器，需要一個 Dockerfile ，定義我們容器中各種參數，例如需要繼承哪一套的 image，並且需要在自己的容器中執行哪些的參數；掛載的檔案；網路連線等。 每一個容器中，可以安裝多個程式，例如 Apache 、 MySQL 、 Python 等，不過根據 Docker 官方的建議，最好每一個容器僅安裝一套的服務，可以稱為 (Micorservices) 微服務。 我們可以在地端，自己的電腦中建立好一套完整的服務，並將 Docker 的各種服務部屬到 Compute Engine 的 Instances 上。 ...

前幾天總共介紹了4種不同的儲存方式，今天要來介紹最後一種： Cloud FireStore。 Firestore 跟 Bigtable 一樣，是一種非關聯式的 NoSQL 資料庫。相較於 Bigtable ， 它適合儲存相對較小的資料，且價格便宜非常多，也有每天的免費扣打可以使用。 Firestore 是一種 Serverless 的服務，可以簡化儲存、查詢跟各種同步相關的使用需求，主要提供給行動裝置、網頁以及物聯網裝置使用，它也無縫的整合了 Firebase 的驗證機制。 Firestore 支援資料庫的 ACID，保障資料的可靠性。 Atomicity 原子姓一個事務的所有操作，不可分割，不可約簡。 如果過程中發生錯誤，必須還原 (Rollback) 回事務開始前的狀況Consistency 一致性- 在事務的開始前與結束後，確保完整性沒有被破壞。Isolation 事務隔離- 允許同時發起多個事務進行讀寫與修改，藉由隔離可以防止事務交叉執行導致資料的不一致。Durability 持久性- 事務結束後，對於資料的修改就是永久的，故障也不會丟失。 Firestore 會自動的進行 Multi-region 的複製，保障資料的完整性，由於 Server 是完全由 Google 管理，因此對於複雜的 NoSQL Query，也不會降低效能。 目前的 Cloud Firestore 有兩種模式，分別是 Datastore Mode 與 Native Mode。 Datastore Mode向下相容於 Datastore 的 ApplicationNative mode- 更強健的 Storage layer 基於 Collection 以及 document 的 data model 支援 Mobile 以及 Web 的客戶端函式庫 Storage 總結 這幾天總共介紹了 Cloud Storage 、 Cloud SQL 、 Cloud Spanner 、 Cloud Big Table 、 Cloud Firestore 等不同的資料儲存方式，那我們要怎麼樣選擇最適合自己的儲存方案呢？ ...

雲端大桌子，是一種 NoSQL 的資料庫，可以支援 TB 等級的應用，且支援 HBase 的 API，可使用於大數據、 Hadoop 等環境之中。 NoSQL 講到 NoSQL 就要回來重新提一下什麼是 SQL ， SQL 就像一張桌子表格，我們每次的新增都會依照表格的固定 Column 來新增 Row，每一條的 Row 都要依照著 Column (Table schema )的欄位來填寫。 很多情況下，我們新增的資料不見得每次都會把每個 Column 給填滿，這種情形下就會成為稀疏矩陣的感覺，造成資源的浪費。而 NoSQL 正是基於這種想法，提出的非結構化資料儲存系統。 適用環境 Cloud Bigtable 擅長處理批次的 MapReduce 等操作，以及 Stream 的處理/分析，以及機器學習等。在實際的場合底下，Bigtable 適合以下幾種資料 銷售資料例如購買紀錄 使用者偏好金融資料- 交易紀錄 股票價格 貨幣匯率物聯網資料- 各種感測器資料 記錄檔案 分析報告時間序列資料- 例如 CPU 以及 Memory 的使用率等 Bigtable 的最大特色 特色大 ： 資料可以支援超過 1 TB 快 ： 高吞吐量 NoSQL ： 非關聯資料庫適用資料- 時間序列 大數據 機器學習