跳到主要內容

發表文章

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

簡單的script搭配gsutil做備份

嫌cloud storage rsync每次要scan並checksum整個folder太慢嗎... 可以使用find這個指令搭配mtime或mmin的參數(可以參考:http://blog.wu-boy.com/2009/01/linuxfreebsd-find-%E6%8C%87%E4%BB%A4%E7%94%A8%E6%B3%95%E6%95%99%E5%AD%B8/) 這樣可以直接找出異動的檔案 然後搭配shell做檔案的列表
ex: 找今天內變更的資料做備份
for name in `find . -mtime -1 ` ; do
# do gsutil to cloud storage gsutil cp $name gs://your-bucket-name/
done
這樣就可以簡單的備份差異到cloud storage上唷!

Cloud Storage權限存取的奧妙

今天介紹一下Cloud Storage如何使用專案角色認證來給予權限... 首先,我們需要到要請求存取的專案中,找出一些專案的資訊... 包含專案ID與專案的Role ID,這兩個直可以對應在Bucket權限設定中的Project與Group兩個Entity上,簡單的設定說明如下:
讀取專案ID,然後複製下來...

在權限授與的地方,可以用文字owners-, editors-, viewers-等字眼,後面加上project id作為授與權限的對象,再給予Access的權限對應,即可將bucket授與對象專案的相對角色相關權限。 \

例如,給予project 288********的所有editor角色具備write的權限,則可以使用
ENTITY = project NAME = 288******** ACCESS = Writer
這樣的一組設定來完成
另外,如果透過專案的Role ID來做權限授與的話,也可以達到相似的效果,這邊可以在Storage的setting頁面找到這個專案的對應role id



這邊可以直接複製role id直接貼到NAME欄位,然後ENTITY選擇Group,在給予對應的Access權限...



在存完檔案之後,重新瀏覽後,可以發現該設定會被轉換成專案的對應權限...


透過這樣的設定,我們可以簡單的讓專案之間彼此可以互相傳遞資料,而不用特別去auth個人的帳戶給執行主機,也可以避免一些存取上的風險 :D

最後,可能有人會想到使用vm instance的service account來做權限授與... 下面是一個GCE instance,目前開放auth使用instance內建的service account (有掛active那組)


而在另一個專案的bucket給予這個instance內建的account權限之後:
經測試可以正常存取該bucket


但如果使用A專案所建立的Service Account去認證Cloud SDK(參考這邊),則最後無法去存取已經授與權限的Service Account....




結論:
1. 我們可以使用project與role的權限授與方式來給予其他專案存取此專案Bucket的權限 2. Service Account會跟隨專案,即使其他專案給予這個Service Account存取權限,也無法跨專案存取Bucket
以上,給大家參考

GCP專案介面,有趣的新改變...

在GCP專案中,發現多樂個"Edit labels",可以提供專案上添加label而Label的設定設,直接提供key, value欄位供選擇 這是個滿有趣而且滿有用的設定方式 通常對專案多到一個不行的管理人員,有致勝的幫助!



經過選擇幾個專案,然後添加name的label後 上方的filter提供透過label來過濾的方式,讓專案列表頓時間乾淨了許多!


未來的Google雲端專案管理上,如果善用labels,真的可以達到很清楚的管理 大資料的世界裡面,爆多專案看來也不是問題了唷!

Cloud APP上傳檔案與下載策略

在Cloud APP上傳檔案與下載時,因為顧及到主機Scale out時候檔案存放位置會影響到Scale out出來的主機如何存取新上傳的檔案,在雲端,透過Cloud Storage是一個不錯的解決方案...
Node.js跟許多語言在file upload的處理方式有點不同,以Express為例,我們可以透過app.use()來導入其他的模組作為控管檔案上傳的部分,而我最常使用的是multr這個模組... 這次透過一些改寫,希望基於multr讓上傳、下載的動作直接結合Cloud Storage來作為存取的位置。
下面這是整個上傳與下載的示意圖:


上圖分成兩個部分: 上傳的部分,無論如何直接將一份副本複製到Cloud Storage下載的部分,主要依循幾個策略:如果本地端有檔案,則直接使用本地端檔案回覆如果本地端無檔案,系統直接到Cloud Storage拉檔案承上,如果使用者允許cache,可以在拉完Cloud Storage檔案後,在存放一個副本在本地端,之後就可以支援從本地端存取功能 上面所述,因為效能關係,可能會開啟cache的功能,如果上傳的檔案名稱不是唯一,則可能重複上傳後再本地端會有舊資料問題,為了避免這個問題,在設定檔中可以指定上傳時候不維持原檔名,這樣每次上傳會以重新編碼檔名,讓每一個物件名稱不會重複。
安裝npm install express-gcs-uploader --save 設定Step1: 與Cloud Storage認證部分設定var gcsuplder = require('express-gcs-uploader'); gcsuplder.auth({ rootdir: __dirname, //設定專案目錄位置,在這邊是為了對應uploads目錄用 upload_url: '/uploads', //上傳檔案的資料夾 download_url: '/download', //檔案下載的路由 cdn_url: 'http://your.bucket.com.tw', //option: 如果GCS設定為public或是website buket,則可以直接由此位置提供服務 keep_filename: true, //option: 是否保留原…

使用SNMP監控Linux CPU並整合Google Cloud Monitor

Google Cloud Monitor是什麼 Google Cloud Monitor簡單的說是Cloud Monitor API與StackDriver服務的總和。Google透過Cloud Monitor提供所有Google Cloud上的一些操作記錄以及讓開發者可以自訂自己的Monitor來在同一個平台上監控。 下面展示的是透過SNMP來蒐集主機的CPU資訊,並且透過Google Cloud Monitor來蒐集這些資訊,呈現在StackDriver的Dashboard上。 SNMP CPU資訊設定 如前面SNMP章節所建,我們可以在snmpd.conf中加入CPU load average的設定,讓SNMP可以讀到CPU的資訊。 # vim /etc/snmp/snmpd.conf (skip) 1 minute Load: .1.3.6.1.4.1.2021.10.1.3.1 5 minute Load: .1.3.6.1.4.1.2021.10.1.3.2 15 minute Load: .1.3.6.1.4.1.2021.10.1.3.3 (skip) 修改完成後,請restart snmp daemon已更新執行狀態。 Create monitor to metrics script 在轉入資料到Cloud Monitor中的部分,需要透過一些程式來進行,下面是欲透過fluentd exec模組來塞資料進到Cloud Monitor的程式片段,目的是從fluentd exec收到欲轉入到Cloud Monitor的資料,並且將資料輸入到Cloud Monitor... 接收到的資料範例: {"name":"UCD-SNMP-MIB::laLoad.1","value":0.0} {"name":"UCD-SNMP-MIB::laLoad.2","value":0.0} {"name":"UCD-SNMP-MIB::laLoad.3","value":0.0} test.js的部分: //file: test.js var fs = require('fs'…

GCE can specify root disk size when boot, now!

忙太久,沒發現,GCE現在可以在開機器的時候指定root disk大小了唷!