GCPUG Taiwan

Database一直是每一項服務需要特別花心思的地方，通常將資料庫服務委託給Google CloudSQL是最簡單不過的，不過，如果希望能夠保有對資料庫的完整操控權，則自建Database是最快的選擇... 而Google Cloud Launcher服務即有DB Cluster的建置，在此以Percona Cluster為例，透過Cloud Launcher簡單的建置Percona MySQL Cluster… Percona是分支自MySQL的資料庫，相較於原生MySQL，Percona原生提供了更多的資料庫工具，讓使用者可以更快速的建置自己的MySQL應用... 首先，我們先到Cloud Lancher ( https://console.cloud.google.com/launcher ) 搜尋”Percona”關鍵字，然後進入Percona的說明頁面之後點選LAUNCH ON COMPUTE ENGINE... 依照GCP上的建議，Percona Cluster 預設啟動的機器不能小於三台，我們可以指定資料庫的zone位置，也可以依照需求指定更多的主機數量... 選好機器的zone和數量後，只要點選Deploy，就可以開始進入開通cluster的動作... 建立完成後可以在”Deployment Manager”裡，看到您剛剛建立的Percona，裡面會有每一台機器的說明、DB的password、相關說明文件等資料 由於Cloud Launcher是以Appliance的方式提供服務，也就是會使用Compute Engine來建置，因此我們會看到剛剛所開立起來的三台機器... 在Percona的Cluster機制下，所有的主機都是可以讀寫的狀態... 因此，接下來我們可以使用SSH進入機器內檢視，登入後，執行mysql指令連線所建立的資料庫，若執行成功就能開始使用... 為了求證cluster的運作，以下進行幾個簡單測試.. 1.每一台DB資料是否會同步? 答案是會~ 在第一台建立一個Database，其他二台會自動sync，如附圖 2.關掉一台，其他台能不能正常運作? Step1. Shutdown最後一台機器，在percono1新

概念 NAT(或稱Bastion主機)的架構在自建機房中常常可以見到，我們也可以將該架構在雲端環境上建置來使用... 而Google雲端的環境中，可以透過network與routing的方式搭配來建置一個具有HA(High Availability)的NAT環境，讓NAT不是單點提供服務... 下面是架構的簡單描述： 建置過程 設定網路與防火牆基本規則 首先，建議使用自建Network，好處是可以自訂內部的路由與相關防火牆規則，且可以避免影響其他主機。 gcloud compute networks create kankan-ha-nat \     --mode legacy \     --range 10.10.10.0/24     為了可以測試狀態，我們允許port 22的ssh連線，因此建立允許 tcp 22 port 連線的防火牆規則... gcloud compute firewall-rules create kankan-ha-nat- allow -ssh \ --allow tcp:22 --network kankan-ha-nat 在NAT server的建置上，我們需要讓內外部連線可以透通，因此將tcp:1-65535, udp:1-65535, icmp等協定打開，讓內部的網段( 10.10.10.0/24) 可以透過NAT server來連線外部網路。 gcloud compute firewall-rules create kankan-ha-nat- allow -internal \ --allow tcp:1-65535,udp:1-65535,icmp \ --source-ranges 10.10.10.0/24 --network kankan-ha-nat 建立NAT server 然後我們將NAT server建立起來： gcloud compute instances create nat-gateway-asia-east1-a --network kankan-ha-nat --can-ip-forward \ --zone asia-east1-a \ --image-family debian-8 \ --image-project debian-cloud \ --tags nat 為

某些時候，我們會需要透過DNS的方式來對應外部服務的domain name位置，而某些應用中，這些domain name可能在不同的環境會對應到不同的地方，此時，我們在傳統作業方式會透過/etc/hosts的編輯方式來讓該主機可以對應到外部服務位置.... 而在K8S中，從1.7之後的版本開始支援hosts的複寫功能... 首先，我們需要先知道對應的DNS與IP有哪些，然後可以透過hostAliases這個spec來描述ip與hostname的對應，下面是個簡單的範例，以nginx的主機為例，如果掛載hostAliases的話，則可以預期在主機內可以觀察到/etc/hosts內有所希望複寫的功能... hosts . yaml apiVersion : v1 kind : Pod metadata:  name : hostaliases - pod spec:  hostAliases:   - ip : "127.0.0.1"    hostnames:     - "foo.local"     - "bar.local"   - ip : "10.1.2.3"    hostnames:     - "foo.remote"     - "bar.remote"  containers:   - name : cat - hosts    image : nginx 接著我們可以把上面的hosts.yaml檔案透過create建立起來... # kubectl create -f hosts.yaml pod "hostaliases-pod" created 最後，我們可以實際登入pod中檢視內部的/etc/hosts的對應狀況... # kubectl exec -it hostaliases-pod bash root@hostaliases - pod :/# root@hostaliases - pod : /# cat / etc / hosts # Kubernetes-managed hosts file. 127.0 . 0.1 localho

Google CloudSQL提供高品質的資料服務，但在使用之前，一般大家會問到該怎麼把資料庫搬到CloudSQL的環境，CloudSQL提供透過 Cloud Storage來做 import/export，如果再資料量不是很大的狀況下，直接針對資料庫做 export 然後存放到 Cloud Storage後，再 import 到 CloudSQL 的速度還滿快的... 但是如果需要做到持續同步資料，則我們會需要一些規劃與工具來持續同步您的資料。 AWS DMS在資料轉移上是一個不錯的選擇，透過簡單的設定流程，可以快速的備份你的資料從一個Database到另一個Database，這裡以MySQL與CloudSQL為例，給大家參考： 建立步驟如下: Step1 建立Replication Instances Step2 Replication Instances建好之後會給一組IP address，將這組IP加入你的DB network DMS:    另外，GCE需要加入DMS的IP: Cloud SQL 加入DMS的IP: Step3 建立source、target的Endpoints Step 4 建立Tasks 指定從哪一個source到哪一個target，要 migrate哪個database哪些table。 建立完成後，若沒有錯誤資料就會開始備份... 情境測試: 1.測試Table內有特殊設定的欄位 有sequence的Table 結果: 轉到Cloud sql上，設定會不見，要再自己加入 有fk的Table 結果: 轉到Cloud sql上，設定會不見，要再自己加入 有timestamp的Table 結果: 轉到Cloud sql上，設定會不見，要再自己加入 2.轉10000筆& 100000筆的時間差?   如果是直接從DMS上做Migrate existing data，5分鐘內資料就會sync到目的端；若是用Replicate data changes only，一筆一筆sync時間就會拉的比較長。 3.當schema相同，加入異動資