跳到主要內容

發表文章

目前顯示的是 4月, 2015的文章

GCP Web Console再一異動!

哇~開主機畫面變漂亮了 :D

使用Node.js執行google cloud storage簽章

繼續分享一篇在Node.js執行google cloud storage簽章的小範例程式碼: var gcloud = require('gcloud'); var project_id = 'your-project-id'; var key_path = '/path/to/keyfolder'; var key_name = 'your-project-json-key.json'; var storage = gcloud.storage({   projectId: project_id,   keyFilename: key_path + '/' + key_name }); var bucket = storage.bucket('your-bucket-name'); bucket.file('your-object-name').getSignedUrl({   action: 'read',   expires: Math.round(Date.now() / 1000) + (60 * 5) // 5 minutes. }, function(err, url) {   if(err) console.log('>>>error:' + err);   console.log('read:', url); }); 這邊是透過 gcloud 這個套件,由Google Cloud Platform Team所撰寫的... 其中使用到的service account金鑰封裝方式是json格式的那個... 整個service account的建置操作過程如下: Step1: 建立Service Account 進入頁面:Cloud Console > APIs & auth > Credentials 點選"Create new Client ID"後,選擇Service account Step2: 下載JSON Key 最後,Service account建

Google Cloud Storage Sign URL

在Google Cloud Storage的使用上有數存種取資料的方式,其中有種存取很有趣,稱作Sign URL.... 透過Sign URL,可以指定下載的網址在固定的時間內可以讀取資源 超過該時間,則URL就失效 一般我們用程式來取Sign URL,但是gsutil已經支援Sign URL了唷!這邊就來介紹一下gsutil的Sign URL操作方式... (官方說明: https://cloud.google.com/storage/docs/gsutil/commands/signurl ) gsutil signurl [options] <private-key-file> gs://some-bucket/some-object/ 我們實際操作一下,針對物件位置gs://mitaccp300-dra-asia/10M.dat進行下載簽章: $ gsutil signurl -d 1m -p notasecret /path/to/mykey.p12 gs://mitaccp300-dra-asia/10M.dat 其中參數的意義為: -d: 簽章有效的長度 -p: p12 key的密碼 /path/to/mykey.p12: p12 key的路徑位置 gs://mitaccp300-dra-asia/10M.dat: 需要簽章的物件位置 執行結果如下 URL HTTP Method Expiration Signed URL gs://mitaccp300-dra-asia/10M.dat GET 2015-04-23 23:59:44 https://storage.googleapis.com/mitaccp300-dra-asia/10M.dat?GoogleAccessId=860835453338-ifhbcaql190oimo0ecp3rp5lkggvapq2@developer.gserviceaccount.com&Expires=1429804784&Signature=dplM53lcwE7...xI7WFr7EJTPtMuNzil4%3D 其中紅色部分即是我們可以不透過認證而可以下載的U

HTTP Load Balancer

測試情境 本次的目的是想要證明HTTP load balancer (HLB)在偵測不同地區流量導向的功能是否OK... 由於HLB的backend server限制以instance group為單位加入,而instance group限制僅可以加入同一個zone中的server instance,因此這次我們開兩個zone的機器,並且把機器分別掛在該zone的instance group中,如果到時候從台灣的連線回覆台灣地區主機的資訊,而美國地區連線則由美國地區主機回覆,則代表HLB可以正確分流不同地區的流量,由該地區主機負責...  架構說明 本次的設定架構如下: http-load-balancer (107.178.248.201) ---------->  instance-group-1 / 104.199.154.208 (asia-east-a)                                                               \                                                               \ -------> instance-group-us / 104.154.41.113 (us-central1-a)  其中hlb為本次設定的http-load-balancer名稱,其下設定hlb-fw1附掛一組IP做hlb的入口,並且設定backend service: hlb-bkend-1收容instance-group-1與instance-group-us兩個分別收容來自APAC與US的主機。 上面總表是以整組的方式呈現,部分的元件在該表中已經被隱藏,我們可以在HLB的進入頁面列表出,選擇advance view來顯示HLB的詳細元件.... Forwarding rules - 顯示HLB所attach的入口IP,每個forwarding rule會預設掛載一個target... 選擇target item或是點選Target proxies的頁籤,可以看到該預設proxy的設定,主要會看到proxy跟url map的對應狀況 選擇Backend services頁籤,可以看到以設定的backend service: hlb-

在gcloud使用service account認證

在Google Compute Engine上開立主機時候,有時我們會忘記將將project access permission打開(下面的Project Access),這時候又不想要綁user account到這台主機...  這時候如果透過service account綁定一個專案的話,可以很快速的讓該主機可以再擁有存取專案的權限(補充:須注意,如果使用service account,則該service account將具備專案完整的存取權限喔...) Step1: 建立Service Account,記得選擇JSON Key Step2: 將key複製到主機,在這邊我們的測試機器在GCE上,可以透過gcloud compute copy-files將檔案放到 gcloud compute copy-files ~/Downloads/mitac-cp300-taipei101-91701c7418ca.json peihsinsu@centos6:~ Step3: 使用service account認證gcloud,其中key-file是指定到所下載的JSON Key... $ gcloud auth activate-service-account 28817...mut8@developer.gserviceaccount.com --key-file mykey.json --project my-project-id 當認證成功,執行gcloud指令跟gsutil等等的指令就沒有問題啦 :D