黑皮考町

  How to use a Google Cloud Persistent Disk (PD) as a Persistent Volume (PV) in Kubernetes 什麼是 Persistent Volume（PV） Persistent Volume（PV）是 Kubernetes 中用來管理儲存資源的抽象化物件。系統管理員可以透過 PV 來管理集群中的實體儲存媒體。 要怎麼使用 Persistent Volume （PV） 要使用 Persistent Volume（PV），首先需要宣告 Persistent Volume Claim（PVC），並透過 PVC 來要求儲存空間。一旦 PVC 被宣告，Kubernetes 就會根據 PVC 中指定的條件尋找適合的 PV 來滿足 Pod 的需求，並將 PV 掛載到 Pod 中。 在 Google Cloud 的公有雲服務裡提供了一種叫做 Cloud Persistent Disk 的服務，它是一種持久性的存儲解決方案，可供 Kubernetes 中的應用程式使用。若想要在 Kubernetes 中使用 Cloud Persistent Disk 作為 Persistent Volume（PV），可參考以下作法： 方法一 Static Provisioning： 在 GCP 上建立 Cloud Persistent Disk（PD）： bash gcloud compute disks create my-disk --size=10GB --zone=us-central1-a 建立 PersistentVolume (PV) YAML： yaml apiVersion: v1 kind: PersistentVolume metadata: name: my-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain gcePersistentDisk: pdName: my-disk fsType: ext4 建立 PersistentVolumeClaim (PVC) YAML： yaml...

  前言  當 Javascript 在存取資源的時候, 瀏覽器會禁止非同源的請求, 除非 Server 上有 CORS  設定讓瀏覽器知道哪些請求是可以允許被發送的 如何在 既有 Cloud Storage Bucket 上加入 CORS 設定 (以下使用 Terraform  來做設定) 假設 Cloud Storage 上有個非 Terraform 建立的 Bucket    首先, 建立資源描述 resource "google_storage_bucket" "andytest123" {   name          = "andytest123"   location      = "US" } Step 2. 把既有的資源設定從雲上讀下來 terraform import google_storage_bucket.image-store andy-prj/andytest123 Step 3. 補上 CORS 設定 resource "google_storage_bucket" "andytest123" {   name          = "andytest123"   location      = "US"   cors {     origin          = ["http://localhost:3000",     "https://web-stage.uc.r.appspot.com",     "https://web.uc.r.appspot.com"     ]     method          = ["GET"]     response_header = ["*"]     max_age_sec...

  前言 在這個資訊爆炸的時代, 資料的產生速度飛快, 面對這些海量的資訊, 若以傳統的方法做資料分析或是分析前的資料處理(Extract Load Transform, ETL), 勢必會面臨到硬體資源不足(記憶體不夠)或是資料處理速度太慢的問題 記憶體不夠時, 將虛擬機做垂直擴展 scaling up 就能夠暫時解決, 但若要加快資料處理的速度, 就會需要一個分散式的資料處理引擎 Spark 或是 Cloud Dataflow, 透過動態的水平擴展 Scaling out 的方式來增加資料處理的 worker 去消化大量資訊 Apache Beam 2016 年時 Google 開源出一套分散式資料處理框架, 定義在 Spark, Flink 以及 Cloud Dataflow 等等分散式資料處理引擎的上層, 讓開發者可以輕鬆地設計資料處理的 pipeline 並運行在分散式的環境裡 它有以下的優點 開源 背後社群龐大, 容易找到資源 移植性 同一個資料處理邏輯可以跑在各大分散式資料處理引擎上 (Flink, Spark, Dataflow...) 擴充性 除了使用 built-in 的 I/O Connector 之外, 開發者也可以自由地實作客製化版本的 Connector 模組 Cloud Dataflow Google 完全託管式的(Fully Managed) 分散式資料處理引擎, No-Ops 的服務特色強調不需要額外的維運人員來維護底層的基礎設施 Dataflow 的上層主要是運行 Apache Beam 的程式碼, 並支援在 Runtime 時動態的彈性擴充底層的運算資源, 因此使用 Dataflow 的開發人員可以更專注地開發資料處理的邏輯以及 pipeline 的設計 開始寫 Apache Beam 程式 Step 1. 建立實驗環境 為了簡化說明, 接下來的示範會跑在 Jupyter Notebook 的環境裡 因此首先會需要在 GCP 上用 Dataflow 的 Notebook 功能建立一個可以跑 Jupyter Notebook 的環境 建立完成後選擇 Open Jupyterlab 進入筆記本 接下來 Step 2. & Step 3. 的程式碼可以直接複製貼到筆記本上執行 Step 2. import 必須的套件 ...

前言 開發者可以將測試以及部署的腳本定義在 cloudbuild.yaml 的設定檔中, 讓 Cloud Build 照著腳本去執行指令 # Build the module. steps: - name: 'gcr.io/cloud-builders/gcloud' args: [ 'run', 'deploy', 'myapp', '--set-env-vars', 'SERVICE_ENV=stage', '--image', 'gcr.io/build-prj/myapp', '--platform', 'managed', '--region', 'us-central1' ] 但預設 Cloud Build 的服務帳號只擁有當下專案的權限, 若想要做到跨專案部署應用程式的話, 就需要授予 Cloud Build 的服務帳號在另一個專案下的部署權限 本篇文章將會簡單的介紹如何跨專案部署服務 假設我們有兩個 Project, 一個是 Build Project 用來放 Source Code 以及跑 Cloud Build, 另一個是 App Project 用來部署服務 (如下示意圖) 要實作這個機制, 首先 授予部署權限 需要授予在 Build Project (8750547431)下的 Cloud Build 的服務帳號能在 App Project (2498738606)下部署的相關權限 (如下) Service Account User Cloud Run Admin APP_PRJ=app-prj BUILD_PRJ_NUM=8750547431 # Cloud Run Admin: can deploy Cloud Run Service gcloud projects add-iam-policy-binding $APP_PRJ \ --member serviceAccount...

前言 GCP 的 Cloud Build 是個非常好用的 DevOps 工具, 對於使用 Cloud Source Repository 的開發者來說,  不需要繁複的設定,  就能快速的建立 CI/CD Pipeline, 使推送到 Cloud Source Repository 的交付能自動觸發 Cloud Build 的事件執行測試與部署  除此之外無伺服器的平台, 不需要額外管理 CI/CD 的伺服器, 也不避擔心 Scale 的問題,  這也是許多開發者選擇 Cloud Build 的原因之一 以下就簡單的帶各位了解如何在 Cloud Build 上建立 Pipeline 跑 CI/CD 的流程 首先, 建立 Pipeline 腳本 由於 Cloud Build 是基於容器的服務, 腳本上的指令都必須跑在容器的環境內, 所以在建立腳本的時候, 需要特別地指定執行環境的容器映像( 即 Builder 的映像), 如下 - name: 'gcr.io/cloud-builders/docker'   args: ['build', '-t', 'gcr.io/myproject/myapp', '.'] 目前 GCP 上已經內建了幾個常用的容器映像讓開發者使用, 所以想要實作 CI/CD 的 Pipeline 並不一定需要自己建立 Builder 的映像檔 預設所有要被執行的腳本都需要被定義在 cloudbuild.yaml 的檔案裡 內容如下 steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/myproject/myapp', '.'] - name: 'gcr.io/cloud-builders/docker'   args: ['push', 'gcr.io/myproject/myapp'] - name: 'gcr.io/cloud-buil...

前言 Google App Engine (GAE) 提供了非常方便的環境讓開發者可以輕鬆地部署服務, 除此之外還有許多有用的功能族繁不及備載... 但若如果部署在 GAE 上的服務發生異常時, 我們該如何去追蹤問題呢？ 以下簡單介紹一下幾個 GCP 上好用的服務幫助我們可以快速的縮小問題的範圍 Cloud Trace Cloud Logging Cloud Trace 這個服務可以讓我們快速的找到效能上的瓶頸是來源自哪隻 API 可以看出問題可能出在 /v1/interest/ads_pref 這隻API 上, 並且發生時間可能在  17:40 分左右 Cloud Logging 知道效能的瓶頸是源自於某隻 API 之後, 接下來可以用 Log Viewer 來看程式是否有拋出任何異常的訊息 在 Query Builder 下查詢語法來找出可能的線索 resource.type="gae_app" resource.labels.module_id="My-Service" textPayload:"exec bulk" timestamp >= "2020-05-15T17:40:00+08:00" AND timestamp <= "2020-05-15T17:43:00+08:00" 這個語法會找出 My-Service 這隻服務在 2020-05-15 這天17:40~17:43 產生含有 exec bulk 這段訊息的 log  以下是其他查詢可以用的運算子 =           # equal !=          # not equal > < >= <=   # numeric ordering :           # "has" matches any substring in the log entry field =~    ...

當我們想要建立 Cloud Run 的容器映像時, 可以使用 gcloud builds submit gcloud builds submit --tag gcr.io/andy-prj/my-service --project $PROJECT 若執行的過程中若出現以下的錯誤訊息時 Creating temporary tarball archive of 124 file(s) totalling 570.2 KiB before compression. Uploading tarball of [.] to [gs://andy-prj_cloudbuild/source/3422.582116-0fd81c021c243d892201dfd08ce1550.tgz] Created [https://cloudbuild.googleapis.com/v1/projects/andy-prj/builds/46712e03-3a15-403f-8be1-b1f1a238d02e]. Logs are available at [https://console.cloud.google.com/cloud-build/builds/ 46712e03-3a15-403f-8be1-b1f1a238d02e ?project=182871]. ERROR: (gcloud.builds.submit) HTTPError 403: <?xml version='1.0' encoding='UTF-8'?><Error><Code> AccessDenied </Code><Message> Access denied .</Message><Details>deploy-cloud@andy-prj.iam.gserviceaccount.com does not have storage.objects.get access to the Google Cloud Storage object .</Details></Error> 表示需要我們缺少存取 GCS 裡物件的權限 要解決這個問題...

當我們想要在 Cloud Run 部署新的服務的時候, 可以使用 gcloud run deploy  gcloud run deploy bi-cronjob \ --image gcr.io/$PROJECT/bi-cronjob \ --platform managed \ --no-allow-unauthenticated \ --region us-central1 \ --project $PROJECT \ --set-env-vars SERVICE_ENV=$RUNMODE \ --memory 1G 若部署的過程中出現以下的錯誤訊息時 Deploying container to Cloud Run service [my-service] in project [andy-prj] region [us-central1] X Deploying...   . Creating Revision...   . Routing traffic... Deployment failed ERROR: (gcloud.run.deploy) PERMISSION_DENIED: Permission   'iam.serviceaccounts.actAs' denied on service account  compute@developer.gserviceaccount.com (or it may not exist). 表示需要 Service Account User 的權限才能完成部署的動作 要解決這個問題, 可以到 IAM 的頁面下加入此權限 或是使用 gcloud 的指令來提昇權限 gcloud projects add-iam-policy-binding <PROJECT_ID> \ --member=serviceAccount:<SERVICE_ACCOUNT_ID>@<PROJECT_ID>.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountUser

前言 Cloud Scheduler 有個進階的功能, 可以設定當排程被觸發的時候, 必須先取得指定的 IAM 身份, 才能去打指定的 Cloud Run 或是 Cloud Function 上的服務 整體的流程大致如下圖 Cloud Scheduler 發出 POST 請求取得 Token Cloud IAM 回傳 Token Cloud Scheduler 帶著 Token 打去打 Cloud Run 上的服務 最後 Cloud Run 根據 Token 是否擁有 Cloud Run Invoker 的權限來決定是否要執行這個請求 %3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%222%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3Baspect%3Dfixed%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22206%22%20y%3D%22197.5%22%20width%3D%2219%22%20height%3D%2219%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E 若部署完後在 Log 頁面出現 PERMISSION_DENIED 的話該如何處理??? {   "jobName": "projects/cloud-833005/locations/us-central1/jobs/sync_usr",   "targetType": "HTTP",   "url": "https://ukrjq-uc.a.run.app/api/job/load",   ...