[GCP] Cloud Run 六個實作: 解析麻雀雖小五臟俱全 | Cloud Run is Small but Complete

前言


Serverless(無伺服器)具有易用且快速的特性,讓使用者享managed好處,而不需要理會基礎設施的配置,就能快速的建立應用程式,這點是大家都知道的。

但一般的Serverless也有其限制,包括Runtime支援不足或是遭特定廠商綁住等缺點,這些缺點卻是容器的優點,因容器更具有靈活性與可移植性,而Google的Cloud Run則是結合兩者,讓使用者可以在無伺服器平臺上執行容器。本篇分享 Cloud Run 一點實作的經驗跟心得,如果要我用一句來形容Cloud Run,我會說「麻雀雖小五臟俱全」,那麼究竟有那五臟呢?

1. Serverless + Container


問題 / 前言

  • 過去一般使用Serverless服務時,常會碰到程式語言、程式版本僅有固定版本
    或是套件不匹配等情況

  • Cloud Run的出現,可以解決原生serverless,對於以上程式與套件的限制
    官方是這樣描述Cloud Run features

    Any language, any library, any binary

作法 / 實做

  • 透過docker build,建立自已的docker image
  • 運行自已的docker image,部署至Cloud Run
    此時,可以享用google managed platform托管服務,完完全全不理管後台的維護,只需要管好每次的新的docker build 版本

從下面的示意圖可以看出幾點

  • 來源可以從自已project Cloud Build

  • developer 可以從Trigger動作,或是由 internet 直接操作Cloud Run

    Untitled.png

Steps1.

1
# 建立一個docker build 測試用的image
2
student_00_44cb0fa3b714@cloudshell:$ docker build . --tag=test1
3
4
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 .

dockerfile 內容

Untitled1.png

Steps2. docker build 完成

Untitled2.png

  • 有docker build, 也有gcloud build阿阿阿

    Untitled3.png

  • 驗證剛剛build image

    Untitled4.png

Steps3. Deploy Container To Cloud Run

1
# 部署cloud run
2
gcloud run deploy --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --platform managed

Untitled5.png

結果

  • 檢視剛剛生出來的Cloud Run
1
# list out current microservice
2
gcloud run services list
  • 一個名為monolith microservice就是剛剛所建立的

    Untitled6.png

驗證 Service

  • 取得 URL

  • 驗證 microservice 是否works

    Untitled7.png

可以看到網頁的結果
Welcome to the Fancy Store!

Untitled8.png

2. 流量管理:原生功能,不用基於外部Load Balance


問題 / 前言

  • 如果是使用一般的GCE,都需要搭配Load Balance才能達到流量管理
  • 使用Cloud Run 則不用,因為它內建了”流量管理”

作法 / 實做

step1. 點選 Actions: traffic 進行流量的管理

Untitled9.png

step2. 輸入期望的traffic 百分比

分流設定: 0001-duk: 20%

Untitled10.png

step3. 使用Apache ab tool 進行測試

  • 目標皆為monolith-cjsbhbijjq-de.a.run.app
  • 但實際上會流量會分到二隻microservice 001-duk, 002-zey
1
# Apache ab stressking
2
ab -n 10000 -c 10 $WEB

Untitled11.png

結果

打開monitoring檢視

  • 0001-duk, 0002-zey 皆有流量進入

    Untitled12.png

3. Cloud Run 像是更 Free 版的 Cloud Functions


問題 / 前言

  • 一般的Serverless也有其限制,包括Runtime支援不足,這些缺點卻是容器的優點,因為容器更具有靈活性與可移植性,Cloud Run則是“結合兩者”,讓使用者可以在無伺服器平臺上執行容器
  • Cloud Run 適用於任何程式語言,也不會綁死在某雲端平台

作法 / 實做

  • 透過docker build, gcloud build的image都可以當作 Cloud Run的runtime的bases

step1. docker build

  • 將image,存放在cloud shell之中

Untitled2.png

step2. gcloud build

  • 將image,存放在gcr.io,它是GCP Container Registry位置

    Untitled3.png

結果

  • Cloud Run 的好處,就是可以選自已build image
  • 其中gcr.io/qwiklabs-gcp-02-7ef52e609d63/helloworld,是即是GCP Container Registry位置
  • 部署Cloud Run指令為 gcloud beta run deploy,再加上image位置
  • Service名稱和位置是在部署中再補上
1
# gcr.io path
2
gcr.io/qwiklabs-gcp-02-7ef52e609d63/helloworld
3
4
# cloud run
5
gcloud beta run deploy --image gcr.io/qwiklabs-gcp-02-7ef52e609d63/helloworld
6
7
# 需外額外的參數
8
--platform managed \
9
--region us-central1 \
10
--allow-unauthenticated
  • hello-v1 service 已成功部署

  • gcloud run 運行時需要提供以下資訊

    • Service 名稱和位置

    • Unauthenticated 是否允許非驗驗證模式的存取

      Untitled13.png

4. Cloud Functions 可以綁自已的domain


問題 / 前言

  • Cloud Run 提供的full managed 服務可以直接產出URL,供連線測試

  • 但有很多情境會需要使用自已的domain

    e.g. CDN情境就是CNAME也讓CDN幫忙托管,因此流量就可以先經由CDN加速,再到Cloud Run Service

作法 / 實做

step1. 在原本的URL 旁邊點選Manage custom domains

Untitled14.png

step2. 輸入domain名字,以joehuang.nctu.me 為例

Untitled15.png

step3. 驗證domain

  • 小弟使用的免費交通大學二級的DNS nctu.me.,因此沒有在清單之中
    (e.g Godday 之類大牌的DNS, 是可以直接以帳密登入做驗證服務)

  • 因為沒有在清單之中
    選擇 other 做驗證,驗證方法有二新增TXT, CNAME 二種

    • a. 新增TXT
      Add the TXT record below to the DNS configuration for joehuang.nctu.me.

      Untitled16.png

  • b. 新增 CNAME

    Untitled17.png

step4. 確認domain 是否驗證成功

Untitled18.png

step5. 增加hello-run-v1joehuang.nctu.me 這個網域

Untitled15.png

step6. 驗證DNS 同步

a. dig

  • 使用dig, 第一要確認的是status 是否為NOERROR

  • 再確認, [ghs.googlehosted.com](http://ghs.googlehosted.com) ,有沒有解析出 IP(216.58.200.51)

    Untitled19.png

b. DNSCHECKER

  • 如果覺得本機dig,會有cache影響

  • 可以選用DNSCHECKER,去除本機cahce的影響
    結果在各國DNS都可以解析到hello-run-v1.oehuang.nctu.me

    Untitled20.png

c. 檢視Cloud Run: DNS Records

  • 可以看到hello-run-v1 已經有被ghs.googlehosted.com托管

    Untitled21.png

結果

5. Cloud Run 還有跟 GAE 一樣的”版本切換” 比 Cloud Functions 有更多的彈性


問題 / 前言

Cloud Run承習Cloud App Engine (GAE) 二個特性
Cloud Run 還有跟 GAE 一樣的版本切換、流量管理功能,因此在管理上比 Cloud Functions 有更多的彈性

  • 應用程式版本設定

    輕鬆託管應用程式的各種不同版本,讓user不費吹灰之力即可建立開發、測試、準備和實際工作環境

  • 流量拆分

    將連入要求導向不同的應用程式版本、快速執行 A/B 測試,並以漸進方式發布功能

作法 / 實做

  • 直接部署新版,比方說新上版服務,或是改了新的dockerfile
  • 可以直接用更版過的image

step1. 直接餵新的image

Container image URL 餵更版過的image, 可以部署在相同的managed service

  • 優勢一:可以延用endpoint,不會作任何的更動
  • 優勢二:直接100% 切換至新版的service

Untitled23.png

結果

  • 延用endpoint,直接100% 切換流量至新版的microservice

  • 如此就很方便developer做 A/B 測試

    Untitled24.png

6. 支援混雲合 Anthos環境


問題 / 前言

  • 原生的Cloud Run 也有其限制,CPU 2核心、memroy上限是2GB

  • 如果想要保留移植性,並解決運算資源的限制,要怎麼做呢?

    答案就是啟用Anthos,它是Google混合雲的solution

  • 讓Cloud Run原本部署為full managed,增加了多雲的選擇

    多雲可以是

    • 是雲上的Google Kubernetes Engine (GKE)
    • 更可以是地端的Anthos (GKE on-prem)

作法 / 實做

二個步驟

  • 第一host 端:也就是Google Kubernetes Engine(GKE),**啟用Anthos**
  • 第二deploy端:Cloud Run上的設定,選擇部署在Anthos

step1. 雲上的GKE:GKE的設定

  • GKE 環境中,啟用Cloud Run for Anthos即可

    Untitled25.png

step2. Cloud Run

  • 環境部署:選擇現有的GKE環境,依圖示有偵測到run-gke2-us-central1-a 這個cluster有啟用Anthos (Cloud Run for Anthos)
  • docker image:選用demo hello

Untitled26.png

  • 在選定啟用 Anthos GKE環境後,再選用demo hello image

Untitled27.png

結果

  • 思考一下,原本是以上面的實驗都是managed全托管的服務
  • 但現在,郤可以在其它你選擇的kubernetes環境,是不是很酷!

檢視一下hello app workload

  • Cloud Run 成功部署一個 application GKE run-gke2-us-central1-a cluster

    Untitled28.png

References


  1. Deploy Your Website on Cloud Run
    [https://www.qwiklabs.com/focuses/10445?catalog_rank={"rank"%3A1%2C"num_filters"%3A0%2C"has_search"%3Atrue}&parent=catalog&search_id=5043953]