跳到主要內容

發表文章

目前顯示的是 四月, 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建立好的畫面如下:


在Service account下會有產生p12 key與js…

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: 需要簽章的物件位置
執行結果如下
URLHTTP MethodExpirationSigned URL gs://mitaccp300-dra-asia/10M.datGET2015-04-23 23:59:44https://storage.googleapis.com/mitaccp300-dra-asia/10M.dat?GoogleAccessId=860835453338-ifhbcaql190oimo0ecp3rp5lkggvapq2@developer.gserviceaccount.com&Expires=1429804784&Signature=dplM53lcwE7...xI7WFr7EJTPtMuNzil4%3D
其中紅色部分即是我們可以不透過認證而可以下載的URL.. 直接把網址貼到瀏覽器即可以在不通過驗證的情況下存取該物件,這樣,資料的安全性部分就更有保障了!
除了下載簽章,gsutil也直接支援了…

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-bkend-1,我們可…

在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