星期五, 7月 31, 2020

GCP Cloud DNS 建立小記

GCP Cloud DNS 建立小記


因為業務的關係, 在雲端平臺上面, 使用 DNS也是正常的事情 ( 笑 )

之前有使用過 AWS Route 53, 

今天要來寫 GCP Cloud DNS 相關紀事


Cloud DNS 官網 https://cloud.google.com/dns?hl=zh-tw


主要練習兩個部分

  • Public Zone 公開區域

    • 一般大家熟知的 DNS 服務, 透過 Cloud DNS 來提供 公開 DNS 查詢

    • 必須先進行 Domain 的註冊才能設定, 這邊是以 Gandi 為例

  • Private Zone 私人區域

    • 相關服務只針對 GCP 專案的指定網路來進行服務, 沒有對外公開查詢


==== 練習 Public Zone ====


登入 GCP console


點選 網路服務 -- > Cloud DNS



點選 建立區域



輸入名稱 (用來識別)

輸入 DNS 名稱 ( 購買或是註冊的網域名稱 )

點選 建立



這個時候會看到 2 組 Record Set

  • SOA

  • NS



接下來到申請 Domain 的機構, 這邊以 Gandi 為例

將名稱伺服器 ( NS Record ) 改為外部, 指向 Google 提供的 NS Record

點選 儲存



接下來新增其他的 Record 


會到剛剛 GCP Cloud DNS 建立的 Zone


點選 ADD RECORD SET



輸入 名稱 , 選取類型, 輸入相關資訊

點選 建立



觀察相關資訊



接下來進行驗證, 使用 host 指令


> host  -t  ns  sakana.tw


sakana.tw name server ns-cloud-b1.googledomains.com.

sakana.tw name server ns-cloud-b2.googledomains.com.

sakana.tw name server ns-cloud-b3.googledomains.com.

sakana.tw name server ns-cloud-b4.googledomains.com.


> host  www.sakana.tw


www.sakana.tw has address 210.59.244.94


  • 這邊可以觀察到 NS 指向 google, 然後剛剛設定的紀錄也有正常運作



==== 練習 Private Zone ====


登入 GCP Console

切換到 Cloud DNS 服務


點選 建立區域



區域類型: 選取 私人

輸入名稱 (用來識別)

輸入 DNS 名稱 

選項的部分 我選 預設

網路的部分可以選多個 GCP 內的網路

點選 建立


觀察資訊



接下來新增 Record


點選 ADD RECORD SET


輸入 名稱 , 選取類型, 輸入相關資訊

點選 建立


觀察資訊




接下來來進行驗證


在 GCE 建立 VM, 確認網路與剛剛建立的 private zone 相符



開啟 VM 的 SSH 來驗證


觀察 DNS 設定

$ cat   /etc/resolv.conf 


nameserver 169.254.169.254


$ host  www.sakana.tw


www.sakana.tw has address 192.168.200.100


  • 這邊可以觀察到預設的 DNS 就可以解析到剛剛 Private Zone 設定的 www.sakana.tw 對應的 私有 IP


一開始的練習有設定 Public Zone, 現在 GCE 的 VM 如果想要對應到剛剛設定的 public zone 該如何呢?


# cat  /etc/resolv.conf 


#nameserver 169.254.169.254

nameserver  8.8.8.8


  • 嘗試將剛剛的 169.254.169.254 改為 8.8.8.8


再次測試


# host   www.sakana.tw


www.sakana.tw has address 210.59.244.94


  • 這邊可以觀察查詢的回答就不一樣了 :)



這樣的方式針對只有專案特定網路或是多網路, 想法上真的是很方便的做法

然後建立的動作也可以透過 gcloud 指令或是 REST 方式來完成


另外紀錄一下

  • 要刪除 Cloud DNS Zone 的時候, 要先清除底下的所有 Record 才能刪除



又前進一步

~ enjoy it




Reference

星期日, 7月 26, 2020

AWS RDS 使用 Failover Priority 調降 writer 規格小記

AWS RDS 使用 Failover Priority 調降 writer 規格小記


DB: Amazon Aurora MySQL 5.7-compatible ( 5.7.12 )


情境說明:

建立 RDS 的時候可能會有 Writer 與 Reader, 隨着專案時間變長, 需求穩定下來之後, 發現之前規劃的 Writer 規格比實際來的高時, 透過 Failover Priority 的方式將新增的 Reader 或是原有的 Reader 置換爲新的 Writer 達成目的


爲了實驗需求, 先來建立 RDS
登入 AWS console -- > 到 Amazon RDS 服務介面


建立 Amazon RDS 參考自己之前的文章


點選 Create database



選取 DB 類型 / 版本

設定 管理者名稱 / 管理者密碼

其他使用預設值

點選 Create database


建立 DB 完成之後觀察資訊




觀察 Writer 的 Configuration

Failover priority 爲 1



也觀察 Reader 的 Configuration

Failover priority 爲 1



規則是這樣的

Failover priority 數字越小, 將會被優先 Promote 為 writer


等等規劃要建立一個新的 Reader 然後 Size 比較小, 但是要讓他變成 Writer


所以針對 Reader 來進行 Modify

主要是針對 Failover 部分調降 Priority, 這邊實驗的關係, 調整到 tier-15

點選 Continue -- > 點選 Modify DB Instance 使其生效


再次觀察資訊目前 Reader 的 Failover priority 爲 15




接下來建立一台來取代目前的 Writer

點選 Cluster -- > 點選 Actions -- > 點選 Add reader



選取 規格

Settings 的部分從原來的 Writer 取用, 輸入instance名稱

Failover 部分預設沒有指定, 這邊要指定比較高的 Priority

Database options 部分要注意 DB parameter group 是否跟原 writer 一樣

點選 Add reader 建立



建立完成之後觀察資訊

這個時候可以觀察到剛剛建立的 Reader, size 是我們希望的大小



接下來要進行置換作業

點選 Writer -- > 點選 Actions -- > 點選 Failover 



點選 Failover 確認執行



執行完成之後觀察

剛剛建立的 Instance 已經變成 Writer 了



接下來就是把舊的 instance 刪除即可



使用這樣的方式之後就可以方便的調整 RDS instance Writer 的規格了

~ enjoy it

 


Reference:


使用 GCP 服務帳戶金鑰跨專案存取 Cloud Storage 小記

使用 GCP 服務帳戶金鑰跨專案存取 Cloud Storage 小記


不同的雲端平臺, 對帳號或是專案有不同的機制來進行區隔, 一般來說可能是爲了專案的區別或是財務的需求來進行區隔, 以下是個人的想法

  • Azure

    • 使用不同的目錄或是資源群組來進行區隔

  • AWS

    • 使用不同的 AWS ID 來進行區隔

  • GCP

    • 使用不同的專案或是帳單來進行區隔


GCP 在針對不同專案的開發或是執行上, 建立不同的專案會是一個很好的區隔機制, 但是有的時候, 不同的專案可能要存取到共同的資源.


今天要來測試的就是使用服務帳戶金鑰來進行跨專案存取 Cloud Storage 


實驗方式

  • 專案 A

    • 建立 Service Account, 產生金鑰, 設定相關權限 

    • 建立 Cloud Storage 

  • 專案 B

    • 建立 Compute Engine, 並掛載 Project A 的 Service Account, 測試是否可以跨專案寫入


情境



登入 GCP console


==== 在 Project A ====


先建立服務帳戶與金鑰

點選 IAM 與管理 -- > 服務帳戶



點選 建立服務帳戶

輸入 服務帳戶名稱

點選 建立



這邊測試的關係先給予 Storage 管理員 的角色, 實際上的權限, 按照專案的需求來調整

點選 繼續




點選 完成



接下來建立金鑰


點選剛剛建立的服務帳戶動作

點選 建立金鑰


選取金鑰類型

這邊選取 JSON

點選 建立


這個時候會出現儲存金鑰的視窗

將金鑰進行儲存



完成 JSON 金鑰的建立


接下來建立 Cloud Storage


點選 Storage -- > 點選 瀏覽器



點選 建立值區


輸入 名稱 / 選取資料的儲存位置 / 級別 / 存取權

點選 建立


  • 這邊要注意的是, 預設儲存位置是 Multi-region, 如果是實驗目的, 可以選取 Region(單一地區)比較省錢


好的, 目前在 Project A 已經有 Service Account with JSON Key 以及 Cloud Storage Bucket

接下來進行 Project B 的實驗


==== 在 Project B ====


切換到 Project B


首先來建立 Compute Engine

點選 Compute Engine -- > 點選 VM 執行個體



點選 建立



輸入 VM 名稱

選取機器類型

點選 建立



  • 這邊可以觀察到建立 VM 的時候是 Project B 的 default service account


點選剛剛建立的 VM 連接的 SSH 進行連接



在終端機畫面

先觀察帳戶資訊, 目前是預設帳戶



嘗試連接到 Project A 的 Cloud Storage

使用 gsutil  ls  gs://PROJECT_A_BUCKET 



  • AccessDeniedException - 因為沒有 storage.objects.list 權限


將剛剛 Project A 的 Service Account JSON KEY 上傳到 Project B 的 VM

儲存為 project-a.json


啟用 Service account

使用 gcloud auth activate-service-account  --key-file  xxxxx.json



  • Key file 請換成剛剛上傳的 JSON KEY


再次觀察資訊



這個時候會觀察到 Active account 已經調換了


再次進行測試

這個時候就會發現, 可以存取 Project A 的 Cloud Storage Bucket 了




這樣也算是又前進一小步

~ enjoy it



Reference: