黑皮考町

前言 這年頭要部署一個網站再也不用像十年前這麼地麻煩了, 這也驗證了科技始終來自於人性, 複雜的操作流程最終還是會被簡化成簡單的步驟 現在使用 Google Cloud Storage (簡稱 GCS) 的服務即可以用來快速地部署網頁 Step 1. 建立網頁 以下使用 React 建立的網頁來進行示範 $ npx create-react-app my-app $ cd my-app $ npm run build Step 2. 在 GCS 上建立 storage bucket  在 GCS 上建立一個放置網頁的空間 # gsutil mb gs://[BUCKET_NAME]/ $ gsutil mb gs://mywebapp777/ Step 3. 上傳檔案 將網頁上傳到 mywebapp777 的 bucket 內  # gsutil cp [OBJECT_LOCATION] gs://[DESTINATION_BUCKET_NAME]/ $ gsutil cp -r * gs://mywebapp777/ Step 4. 公開 預設是私有的, 若想讓他人可以存取, 必須將 bucket 內的檔案都公開 # gsutil iam ch allUsers:objectViewer gs:/[BUCKET_NAME] $ gsutil iam ch allUsers:objectViewer gs:/mywebappp777 Step 5. 設定 index page 設定首頁 # gsutil web set -m [INDEX_PAGE] -e [ERROR_PAGE] gs://[BUCKET_NAME] $ gsutil web set -m index.html -e 404.html gs://mywebappp777 Step 6 設定 Load Balancer 建立一個新的 Load Balancer 選擇 Http(s) Load Balancing 選擇 From Internet to my VMs 建立一個 Load Balancer 首先, 替 Load Balancer 命名,  接下來在 Bac...

前言 開發者可以將測試以及部署的腳本定義在 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...

前言 Docker 目前提供以下網路模式, None, Bridge, Host None 除了  loopback interface (127.0.0.1) 之外無其他網路介面, 所以無法存取外部網路 andy_lai@cloudshell:~$ docker run -it --network=none ubuntu:14.04 /bin/bash Digest: sha256:ffc76f71dd8be8c9e222d420dc96901a07b61616689a44c7b3ef6a10b7213de4 root@71aa5f112c7e:/# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Host 使用和宿主機 (Host) 一樣的網路設定, 效能會比較好, 但仍不建議使用, 需要考慮網路安全性的問題, 除此之外也會使失去容器隔離的好處  Bridge Docker 預設會在宿主機 (Host) 上建立一個 docker0 的網路介面, 容器可以透過這網路介面跟外界溝通, 也可以透過這介面作容器間的溝通, 事實上 docker0 扮演著一個虛擬的網路橋接器,  當以 Bridge 的網路模式建立新的容器的時候 andy_lai@cloudshell:~$ docker run -it -p 8080:8080 my-docker docker0 會被接上虛擬網卡 veth3cc413e and...

前言 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