部署一個具備DB與AP的應用程式 - 以Yourls服務部署為例

作者： -

接下來以建置mysql資料庫以及一個連線該資料庫的應用部署來觀察GKE在網路層的變化，我們參考kubernetes的mysql服務建立的方式(文章：https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/)，其中我們需要先建立mysql所需要用到的disk空間，可以透過下面指令來建置：

gcloud compute disks create --size=20GB mysql-disk

然後，透過mysql.yaml來設定mysql與相關掛載的設定...

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  gcePersistentDisk:
    pdName: mysql-disk
    fsType: ext4
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
    - port: 3306
  selector:
    app: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: mysql
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
          # Use secret in real usage
        - name: MYSQL_ROOT_PASSWORD
          value: 1qaz2wsx
        - name: MYSQL_DATABASE
          value: yourls
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

上面的設定中，用到PV(Persistent Volume)與PVC(Persistent Volume Claim)來設定給MySQL Pod使用，再將MySQL服務以Service Expose出來... 我們可以用下面指令將服務建立起來...

$ kubectl --namespace production create -f mysql.yaml
persistentvolume "mysql-pv" created
service "mysql" created
persistentvolumeclaim "mysql-pv-claim" created
deployment "mysql" created

接下來，需要建立yourls的服務(yourls是一個開源短網址服務，可提供短網址的對應功能，並且有相對應的管理與統計工具，相當不錯唷！)，這邊省略yourls的Dockerfile建置步驟(其中我們把DB的一些相關設定與nginx上的一些設定都直接封裝在image中)，並假設我們將docker image已經上傳到gcr.io的image registry。

下面是yourls的yaml檔案，我們透過與MySQL資料庫一樣的動作，掛載一個空間給yourls存放qrcode的圖片資料，整個yourls-service.yaml設定如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: yourls-pv
spec:
  capacity:
    storage: 40Gi
  accessModes:
    - ReadWriteOnce
  gcePersistentDisk:
    pdName: yourls-disk
    fsType: ext4
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: yourls-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 40Gi
---
apiVersion: v1
kind: Service
metadata:
  name: yourls-server
  labels:
    app: yourls-server
spec:
  ports:
  - port: 80
    targetPort: 80
  type: LoadBalancer
  selector:
    app: yourls-server
  sessionAffinity: ClientIP
  loadBalancerIP: 123.123.123.123
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: yourls-server
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: yourls-server
    spec:
      containers:
      - name: yourls-server
        image: gcr.io/your-project-id/yourl:v1.0
        ports:
        - containerPort: 80
        volumeMounts:
        - name: yourls-persistent-storage
          mountPath: /var/www/html/data
      volumes:
      - name: yourls-persistent-storage
        persistentVolumeClaim:
          claimName: yourls-pv-claim

yaml中有一段指定了loadBalancerIP，這部分可以結合GCP上的外部靜態IP，讓未來與DNS的結合可以更加方便。

完成yaml檔後，可以透過下面指令來建立yourls server...

$ kubectl --namespace production create -f yourls-service.yaml
persistentvolume "yourls-pv" created
persistentvolumeclaim "yourls-pv-claim" created
service "yourls-server" created
deployment "yourls-server" created

建立完成後，我們可以到network下的firewall再確認過，會發現firewall上已經針對yourls的port 80開放了，這樣我們就可以使用http來連線yourls服務了 ：）


除了firewall的設定，GKE也在建立service的同時，幫我們把Load Balancer建立起來了... 由於GKE上的service對應到GCP的服務上是TCP Load Balancer，我們可以在Network中的Load Balancer上看到下面的設定...


其中紅色的驚嘆號是因為在GCP的TCP Load Balancer中可以指定Health Check，但也可以不用指定，而在預設的狀況下，GKE開啟servce之後，所建立的TCP Load Balancer是沒有加上Health Check的... 但這不影響GKE上service的運作，我們仍是可以使用80 port連線yourls…

最後，如果打算讓服務可以全球化佈局，讓GKE的服務串通多個資料中心的話(GCP的HTTP Load Balancer提供了Global IP，可以透過Anycast的方式提供更穩健的連線品質)，則可以的透過HTTL Load Balancer來提供服務，而對應到Kubernetes的部分，則是Ingress這個服務。下面是Ingress的yaml設定檔...

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: yourls-server-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "ip-ingress-yourls"
spec:
  backend:
    serviceName: yourls-server
    servicePort: 80

其中，上面的Ingress yaml檔案中，我們透過annotation來指定Ingress的靜態IP位置... 然後可以透過下面的指令來將Ingress建立起來。

$ kubectl --namespace production create -f ingress.yaml
ingress "yourls-server-ingress" created

建立好Ingress之後，我們可以回來看看Network中的Firewall，這邊可以看firewall中多了一個設定開通了35.191.0.0/16的網段，這主要是開通讓healthcheck服務可以連線到pod，以監控服務運作正常的...


除了firewall，Ingress對應到的是HTTP Load Balancer，因此，接下來，我們來看HTTP Load Balancer中的設定... 在這邊，GKE幫Ingress設定上了Health Check(我們可以從GCE的介面中看到新增加的Heath Check)，然後會帶入HTTP Load Balancer中的一些基本設定，詳細狀況如下：


如果一切都沒問題，則yourls的服務就可以在該IP的80 port提供服務了！

留言

張貼留言

這個網誌中的熱門文章

透過Cloud Shell輕鬆呼叫Google API

作者： -
圖片
我們知道Google有提供API Explore的工具，讓所有Google的API都可以快速的在API Explore上瀏覽API的呼叫與結果，讓開發上非常方便....  下面介紹透過Google的Cloud SDK工具來進行API的呼叫作業... 話說，懶得安裝的話，可以直接使用Cloud Shell喲～ 透過安裝的話，通常透過下面幾個動作即可完成安裝與認證... 安裝Google Cloud SDK…   curl https://sdk.cloud.google.com | bash   認證 Cloud SDK…   gcloud auth login   幫Google的SDK工具設定application default login...   gcloud auth application-default login   如果跟我一樣懶得安裝，可以透過Cloud SDK... 首先，開啟Cloud Shell，進入可以執行的畫面... 在Cloud Shell中，由於內建所安裝的Cloud SDK已經載入了使用者的權限，因此可以方便的呼叫相關的SDK與取得Token... 取得 access token…   gcloud auth application- default print-access-token   接著，我們可以選定一個所要呼叫的Google API進行呼叫 ….，這邊以Google BigQuery為例，可以呼叫 /bigquery/v2/projects/:projectid/datasets 來取得API的結果... 呼叫的內容中，需要在Header處加上Authorization的Bearer token，即是上面取得的access token...   $ curl -H "Authorization:Bearer `gcloud auth application-default print-access-token`" https: // www.googleapis.com/bigquery/v2/projects/mitac-simonsu-2017/datasets { "kind" : "bigquery#datasetList" , "
閱讀完整內容

[how-to] 在 GCP 上設定 HTTPS Load Balancer

作者： -
圖片
GCP 推出 HTTP Load Balancer 也已經一陣子了，其中類似 anycast 的特性讓後端的 backend server 可以跨不同 region 之外，也可以根據流量的來源跑到最適合的 backend group 上。 但是好用的東西總是缺一味，就是 SSL 的支援。Google 雖然有實作了 HTTPS Load Balancer 但一直都在 alpha stage，僅開放邀請測試，所以也都是一整個看的到吃不到的情況 .. 日前終於收到 Google 的邀請，終於來試看看到底怎麼設定 HTTPS Load Balancer .. 其實非常簡單 ..... 首先請選擇 HTTP Load Balancing 功能，選擇 New load balancer，輸入名稱 完成輸入之後，我們來增加新的 forwarding rule 重點在這裡，如果您的帳號/專案有被加入到這個功能的白名單 (whitelisted) 內，你就可以在 Protocol 那邊看到「HTTPS」，而當你選擇「HTTPS」後，你會看到下方多了一個「Certificate」的下拉式選單，然後選擇「Create a new certificate」 這邊就是新增憑證資訊的頁面，你可以選擇上傳或是貼上憑證的內容。 其中「Public key certificate」是 CA 所簽發給你的憑證，Certificate chain 就是 CA 給你的中繼憑證 (Intermediate certificate)，然後 Private Key 不意外的就是貼入你申請這個憑證所使用的私鑰。 一旦你的填入憑證是有效的，右方將會出現這個憑證的相關資訊，例如 hostname，有效期限 ... 等等。  建立完 forwarding rule 之後，這個 Load Balancer 就完成一半了！這時候你可以直接點那個連結，或是用 curl 檢查 SSL 是否順利掛上你剛剛上傳的憑證。 但因為你現在是用 IP 連，如果用 chrome 連線會得到憑證無效的訊息，因為 IP 跟 hostname 對不上的關係。 或是你也可以進到 advanced view，看剛剛建立的 lb 跟 forwarding rules
閱讀完整內容

GCP的Billing Export與分析(一) - 透過BigQuery查詢與分析GCP帳務資料

作者： -
圖片
GCP提供雲端服務平台之相關產品，在計價上，GCP提供Billing檔案的匯出，從GCP web console設定，可匯出至BigQuery、Cloud Storage與PubSub幾個目的儲存體，本次跟大家介紹BigQuery的匯出部分，並藉由BigQuery的查詢呈現您想要的報表。 GCP Billing export to Bigquery 在您的Billing Account的設定頁面中，可以透過下面的介紹設定好Billing Data的匯出動作... 首先，進入Google Cloud Billing頁面後，可以在BigQuery export的項目中設定匯出Billing資料至某個您具備權限的project下的BigQuery dataset中... 設定完成後，BigQuery就會多一個dataset並且自動產生一個table，該table的名稱規則為：gcp_billing_export_$billing_account_id 原則上設定完後，Billing的資料會等約2個工作天才會完整的進來，如果沒看到全部的資料，請不要擔心＾＾ 建立報表 下面是透過BigQuery來取得某個期間的每日各項目加總(日期自行修改)的查詢語句。結合上述的專案帳務資料的匯出，可以得到所指定日期內每一天的所有項目費用紀錄，可以讓您方便了解每項資源在每天的使用上，在各專案中的比重約為多少... SQL: SELECT  t0.product ,strftime_utc_usec(t0.start_time, '%Y%m%d' ) as date ,                   round ( SUM (t0.cost), 6 ) AS cost_total FROM ( SELECT * FROM [ your-project-id :daily_billing.gcp_billing_export_$billing_account_id]              WHERE _PARTITIONTIME >= TIMESTAMP ( '20170401' )              AND  _PARTITIONTIME &
閱讀完整內容