Skip to content

使用 Cloud Build 搭配 Helm 改善雲端部署

  • Ops

管理 Kubernetes 的服務時常有一些困擾:

  1. 須根據環境 (staging, production…) 去套用不同的設定及環境變數,整合不易
  2. secret 常是手動新增,如 cloudsql-proxy 的憑證,時間久了常忘記該 secret 是幹麻用的,及整個服務重新部署也會卡在這個手動步驟

使用 Helm 可以幫助我們管理這些部署檔案:

  1. 一鍵部署、移除
  2. 可根據不同的環境採用不同變數,有幾種可行的作法
  3. 可根據彈性的判斷式生成設定檔
  4. chart 的版本控制 (Release)

準備事項:

  1. 有個叢集
  2. Client 端安裝 Helm , Server 端安裝 Tiller
    image
  3. 叢集有 RBAC ,可以關閉 RBAC ,或給 Tiller 權限:
    • helm init預設使用的服務帳戶是default
    • 叢集的default服務帳戶綁定cluster-admin叢集角色

Helm 有提供 dependency 的功能,可以透過以下指令來部署全部的 subchart:

但這裡會有一個問題,即部署時沒辦法指定 subchart 要吃哪個 value file ,因若你的 chart 參數是分成values.prod.yamlvalues.staging.yaml,一旦 chart 打包成 package ,package 在使用時只能吃 values.yaml

下個版本可能提供相對應的作法,請參考相關 issue

透過 Cloud Build 部署

透過helm create建立並設定完 chart 後,希望能在 Cloud Build 的流程透過 helm 部署,這邊選用 cloud-builer-community 提供的helm映像檔

  1. Build 該映像檔並推至專案的 Container Registry
  2. 參考 example 來新增流程,如helm installhelm upgrade
  3. 若 RBAC 是啟用的狀態,須要給 Cloud Build 操作叢集的權限
    • Cloud Build 的服務帳戶綁定roles/container.admin角色及cluster-admin叢集角色,請參考相關指令
      image

IP Addressing

  • Ops
tags: ccna

IP Addressing

  • layer 3 logical address assigned by an administrator(MAC built in NIC)
  • used to identify specific devices on a network
  • every device on the internet has a unique IP Address

Street Analogy

  • network address portion
    • identifies a specific network
    • routers route traffic via routing tables, is based on network address(Network ID), not ip address
  • host address portion
    • identifies a specific endpoint on a network
    • we can use a protocal such as ARP to find the host

Ipv4

  • connectionless protocal: no sessions formd when transmitted, no status info
  • packets treated independently
    • may take different paths: load balancing, bandwidth, hopcount
  • hierarchical addressing sturture
  • best effort delivery
  • format
    • 32 bit with 4 octets
    • like DHL or FedEx routing parcel based on an address

Classes

  • Unicast Traffic
    • A
      • start with binary 0
      • range from 0(00000000).0.0.0 to 127(01111111).255.255.255
      • exceptions:
        • 127 is reserved for loopback: 127.0.0.1
        • 0 network is reserved for default network: 0.1.1.1
      • actual range from 1.0.0.0 to 126.255.255.255
      • portions
        • first 1 octets: Networks
        • last 3 octests: Hosts
    • B
      • start with binary 10
      • range from 128(10000000).0.0.0 to 191(10111111).255.255.255
      • portions
        • first 2 octets: Networks
        • last 2 octests: Hosts
    • C
      • start with binary 110
      • range from 192(11000000).0.0.0 to 223(11011111).255.255.255
      • portions
        • first 3 octets: Networks
        • last 1 octests: Hosts
  • Multicast
    • D
      • start with binary 111
  • reserved for other purposes
    • E
      • start with binary 1111

These classes replaced by Classless Inter-Domain Routing(CIDR) in 1993

Read More »IP Addressing

OSI Model

  • Ops
tags: ccna

OSI Model

  • By International Organization of Standard

Benefits

  • Standard and INTEROPERABILITY
  • Split development/role: hide developer from lower layer
  • Quicker development

Layers

You need to remember both the name and the layer number

  • Layer7: Application
  • Layer6: Presentation
  • Layer5: Session
  • Layer4: Transport
  • Layer3: Network
  • Layer2: DataLink
  • Layer1: Physical

Trick: All People Sleeping Through Networking Don’t Pass

Network Engineer: Focus on 1, 2, 3, 4 Layers
Web Developer: Focus on 5, 6, 7 Layers

Read More »OSI Model

序列 – Python Sequence

  • Python

Sequence

必須足以下條件:

  • 物件的集合
  • countable
  • zero based indexing (__getitem__)
  • 為什麼 index 要從0開始?
    • 0 based: 0 <= n < len(s)
    • 1 based: 1 <= n < len(s) + 1 Upper bound 用小於的原因是計算長度時不須再+1
  • 有序(positional ordering)
    • 舉例來說 list 和 set 都是物件的容器,但 list 可以被排序, set 不行,因此 list 是 Sequence Type 而 set 不是

特性:

  • Homogeneous vs Heterogeneous 同質即序列的物件型態必須是相同的
  • Iterable vs non iterable 可以迭代的容器不一定是序列,如set
  • Mutable vs Immutable Mutable sequence can be modified. 要注意的是在操作新序列的時候更動到原本的序列(in-place),如 reverse()

以 list 為例,這幾個操作皆為原地算法(inplace):

  • l.clear()
  • l.append()
  • l.pop()
  • l.extend()
  • l.insert()
  • l +=
  • l *=
  • l[somesliceobj] = 若是 concat(+)、repetition(*)、slicing 都是關聯至新的物件參考

要注意的是,容器序列(儲存物件參考)的 concat 和 repetition 有可能只是儲存多個相同物件的參考

Read More »序列 – Python Sequence

Docker Swarm 進階實戰 (2)

  • Ops
tags: docker, devops

Docker Swarm進階實戰(2)

Service Logs

  • 是container logs的聚集
  • 可以印出全部tasks或單一task
  • 如果你沒有log system,這可能是唯一troubleshooting的方式
  • 沒有storage,、不支援log搜尋或轉送至其他系統
  • 如果你有設定--log-driver,也就是其他logging方式,此指令就抓不到任何logs

除非你是小型swarm或測試階段,才使用一般的service logs,長期還是需要其他log storage的解決方案

範例指令

印出時不被截斷

只取最近50筆

Linux跟Mac可以透過grep做簡單的篩選

Windows透過findstr

Docker Events

  • Docker engine或Swarm產生的操作(Action)紀錄
  • 紀錄service/node/secret/config/network等的新增修改刪除動作
  • 支援搜尋及formatting
  • 分兩種scope,分別是swarm level跟local level(單一node)
  • event存在實體記憶體,最多只能存1000筆,所以當node數量很多時,event就不堪用了,還是需要額外的logging system

範例指令 顯示local events,如果node是manager,會顯示swarm events

--since

--filter

Swarm Configs

可以在Swarm的Raft Database儲存字串或檔案,並mapping容器中,適合的應用場景為:

  • nginx設定或更改proxy config
  • 設定或更改資料庫config等 這樣可以取代bind mount(將資料儲存在硬碟),存在Raft能提高可用性 swarm config跟secret有異曲同工之妙,可以透過指令來新增刪除config files,要注意的是:
  • config是immutable,不能修改只能replace
  • 若有任何service使用到該config,要先移除service才能移除config
  • 如果是隱私資料一樣用secret來存

範例指令

用特定config來建立一個service

新增新的config來取代舊的,並更新有用到該config的service

stack file,3.3之後才支援config

Docker Swarm 進階實戰 (1)

  • Ops
tags: docker, devops

Docker Swarm進階實戰(1)

容器的更新

在不移除及重啟容器的情況下更新,從以下指令選項可以知道,container update旨在控制和限縮該容器的資源

另外要清楚的是我們透過docker run執行一個容器,其狀態就只有RunningShotdown兩種,如果出了差錯,此容器不會也不該有任何操作可以重新建立自己

Service的更新

  1. 再來看service update的選項,很明顯比容器更還多出許多操作,因為swarm service存在的目的就是要能在不影響服務的情況下取代(replace)、重建recreate容器

  2. swarm mode也是利用這種方式,逐一取代service底下執行的容器,達到滾動更新

  3. docker service的指令並非直接告訴系統去新增或刪除容器,而是新增了一連串的工作到佇列中,整個處理的流程帶有scale、rollback、failure mitigation等功能

  4. service更新的目標是limit downtime,也就是控制停機時間

  5. stack deploy會觸發service更新

  6. service更新會對nodes做rebalancing

Read More »Docker Swarm 進階實戰 (1)