尋找Google的創新

嫌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如何使用專案角色認證來給予權限... 首先，我們需要到要請求存取的專案中，找出一些專案的資訊... 包含專案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存取權限，也無法...

在GCP專案中，發現多樂個"Edit labels"，可以提供專案上添加label 而Label的設定設，直接提供key, value欄位供選擇 這是個滿有趣而且滿有用的設定方式 通常對專案多到一個不行的管理人員，有致勝的幫助！ 經過選擇幾個專案，然後添加name的label後 上方的filter提供透過label來過濾的方式，讓專案列表頓時間乾淨了許多！ 未來的Google雲端專案管理上，如果善用labels，真的可以達到很清楚的管理 大資料的世界裡面，爆多專案看來也不是問題了唷！

在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 buke...

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 v...

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