如果你跟我一樣，是 kubectl 愛好者，對於其他操作介面譬如 k9s 等都不習慣的人，那我認為一定要來瞭解一下 kubectl plugin 的用法

1. kubectl plugin 本身的設計使得大家非常容易的擴充，並不需要修改 kubectl 的任何原始碼或是重新編譯。相反的只需要準備相關的執行檔案，並且依據特定規則命名即可
2. krew 是一套管理 kubectl plugin 的套件，能夠幫你整理目前官方收集的 plugin 並且提供指令讓你去安裝與刪除
3. 本文列出了幾個作者認為好用的指令，譬如 whoami，可以讓你知道你當前透過 KUBECONFIG 連接到遠方 cluster 時是以什麼樣的身份被認證
4. access-matrix 幫你列出目前系統中 RBAC 的相關權限，用一個比較易閱讀的方式呈現
5. neat 是一個清除工具，可以幫忙將 kubectl get pods xxx -o yaml 中那些由 controller 所添加的資源給移除，讓你得到一個乾淨的輸出
6. node-shell 是個非常好用的工具，可以幫你掛載一個 shell 到任意的 k8s node 之中，讓你透過該 shell 來操作該節點

除了這些之外，我認為 ksniff 也是個滿有趣的工具，可以幫忙運行 tcpdump 來錄製封包

如果有興趣的可以直接到 krew 的官方文件去看看目前收錄的 plugin 有哪些，然後可以都玩看看來找到一些對自己工作有幫助的指令

https://www.padok.fr/en/blog/kubectl-plugins

今天這篇是一個 Operator 的介紹文，該文分成三大部分，分別是 What, Why 以及 How

如果你本身對於 Operator 的概念還不是很熟悉的，會非常推薦閱讀這篇文章，幫助你從頭瞭解到底什麼是 Operator，其背後的實作原理以及我們可以透過 Opeator 做什麼事情，對於維運團隊能夠帶來什麼好處

# What
1. Operator 這個詞是由 CoreOS 工程師於 2016 提出的，目的是希望簡化應用程式的管理，特別是 Stateful 類型的
2. Operator 背後是一個 Controller，該 Controller 會根據當前應用程式的狀態而自動地進行一系列的處理，譬如創建，刪除，管理等各式各樣資源，當然這些操作都是基於 Kubernetes API 完成
3. 根據目前官方 (kubernetes.io) 的說明，要理解 Operator 就會需要理解兩個概念，分別是 CRD (Custom Resource Definition) 以及 Control-Loop
4. CRD 提供一個方式讓開發者能夠定義屬於自己的 resource，包含了 apiversion, kind 等欄位。舉例來說，你可以自己定義一個跟 Pod 幾乎完全一樣的資源，然後擴充或是減少一些欄位

# Why
1. Kubernetes 內建的機制與資源對於是非常適合於無狀態應用程式(Stateless)的，這些資源足夠滿足無狀態應用程式的需求，譬如自動擴展數量，提供流量的負載平衡
2. 但是當 Kubernetes 的應用場景愈來愈多， Stateful 應用程式的需求就出現了，這時候原生的機制就稍嫌不足，使用起來不夠順暢。
3. 透過 Operator 的概念 (CRD + Control-Loop)，使用 CRD 來定義你的資源狀態，並且透過 Controller 來幫你維護你的運作邏輯，譬如什麼時候該產生/刪除 Pod，什麼時候該創立/刪除其他資源，這些邏輯的實現都隱藏到 Controller 之中，但是同時也透過 CRD 提供一些介面參數讓開發者與維運者有能力對其進行一些調整

# How
1. 如何撰寫一個 Operator，有一些現成的工具可以幫忙，譬如 Kudo, Operator SDK, Kubebuilder 等
2. 有興趣觀看這些工具的介紹與使用，可以看全文

# Operator 的必要性

1. 2020 北美 Kubecon 上有非常多關於 Operator 的討論，作者特別提出由 HashiCorp 所分享的議程 Stop Writing Operators ，並且針對幾點來討論
2. 如果你的自動化是一個每個月執行10分鐘這種工作，那花上數週來維護與撰寫這種自動化其實非常不值得
3. 實際上開發一個 Operator 會遇到滿多問題，即使你使用 Kubebuilder 等這類型工具也還是會有很多小問題
4. 如果能的話，作者覺得有時候寫一些醜陋的 shell script 會比客製化各式各樣的 operator 還來得好。

https://medium.com/swlh/kubernetes-operator-for-beginners-what-why-how-21b23f0cb9b1

#小編

【矽谷牛的耕田筆記 - 時間軸 】正式上線！！

https://technologynoteniu.github.io/timeline/

最近收到來自粉絲的來信反應說耕田筆記更新太快來不及跟上更新的進度，經過了解我們發現 Facebook 粉絲頁的其實對於單純只想看技術文章的觀眾不夠友善，非常難回去查過去曾經看過的貼文，此外上面有太多東西會讓觀眾分心的內容。

這這些背景下，我們決定提供一個乾淨的耕田筆記時間軸，讓大家可以專注於技術內容。目前這個網站對行動裝置訪問也是友好的。

此外我們也有提供按照主題分類的文件型網站，收錄了過去所有貼文。

【矽谷牛的耕田筆記 - 主題分類 】https://technologynoteniu.github.io/awesome-notes/

這邊跟大家分享一下一個 GitHub 於 2021 的小更動

2020/08/13 之後， GitHub 將停止所有基於密碼的操作授權，這邊來談一下相關的影響及改動

# 改變內容
1. GitHub 將要使用 Token-based 的方式來取代原本密碼的認證系統，但是要注意的是這邊指的是相關應用程式的整合，你原生網頁登入都還是使用你的密碼


# 影響層面
1. CLI 方面你如果是使用 HTTPS 這個方式搭配帳號密碼來存取 GitHub
2. 任何第三方應用程式如果是基於帳號密碼來連動 GitHub 的，全部都會失效

# 不被影響的使用情境
1. 如果你本身已經有開啟兩階段 (2FA)認證，那你其實已經被要求使用 Token 或是 SSH 的方式來認證
2. 如果你是 GitHub App 的維護者，因為 GitHub App 本身就不支援密碼的認證，所以你不會受到影響
3. GitHub 企業版本用戶，對於地端自架環境不影響


# 時程
1. 2021/06/30 - 2021/07/28
這個階段是鼓勵所有受到影響的用戶與App趕緊進行修正以避免下個階段直接遇到不相容的問題，因此會暫時的要求所有操作都要使用 Git/SSH 來授權。
3. 2021/08/13
這個階段開始，所有 Git 相關操作都要基於 Token/SSH 兩種方式

# 該怎麼做
1. 對於開發人員來說，如果你本來有使用密碼來授權任何 GitHub 相關的操作，請立刻改為使用 Personal Access Token 或是 SSH key 的方式
2. 對於系統整合人員來說，請參閱 Authorizing OAuth Apps 相關的操作來修改


原文連結:
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/

今天這篇文章來分享 knative 這套 Kubernetes 內的 serverless 解決方案
該文章分成幾個部分
1. 什麼是 Serverless, 帶來的好處是什麼
2. 什麼是 knative，該專案的特色有什麼
3. 透過實際範例，安裝 knative 到你的 kubernetes cluster 中，並且透過一個簡單的 golang 應用程式來展示 knative 是如何運作的

作者認為 serverless 最大的好處就是可以讓開發者專心寫程式，不需要考慮太多底層的架構，譬如說什麼是 Kubernetes，如果要部署我寫的程式，我應該怎麼做
Knative 該專案基於 Kubernetes而開發，希望能夠提供簡單且靈活的 serverless 解決方案。

採用 Knative 的話，開發者可以專心寫程式，並且使用一行指令去部署你的程式到 Kubernetes 中， Knative 會幫你把剩下的事情完成，譬如創建相關的 Deployment/Service/Ingress 這些資源。

Knative 收到相關創建請求時，本身並不會馬上創建相關資源，反而是等到該應用程式第一次被呼叫時，才會開始創建相關資源，同時也能夠根據當前的流量而自動調整需要的 instance 數量。藉由這個機制可以提供更好的資源管理


對於該專案有興趣的，記得點選下列連結觀看全文來瞭解更多

https://medium.com/better-programming/go-serverless-on-kubernetes-with-knative-b3aff3dbdffa

今天這篇文章要探討的是關於 Kubernetes 內應用程式版本的一些議題。
Kubernetes 提供一個平台供開發者與維運者去安裝各式各樣的應用來滿足各種不同的工作，然而這些應用程式本身都由不同的組織或公司維護，且都有屬於自己的版本發行。

對於維運人員來說，要將這些應用程式安裝到 Kubernetes 內也有眾多選擇，不論是 Helm, Kustomize, Jsonnet 甚至是原生 Yaml，這也意味者一個 Kubernetes 叢集內，可能同時使用多套工具來安裝應用程式

作者的公司遇到的問題就是，我要怎麼知道目前哪些應用程式有新的版本可以更新? 有沒有一個類似 Maven 或是 Scala Steward 之類的工具，可以幫忙檢查所有使用軟體的版本狀態是否有新版需要更新。

作者沒有看到一個適合於 Kubernetes 內的解決方案，但是找到了一個名為 nvchecker (new version chekcer) 的開源專案，並且嘗試使用該開源專案來解決版本更新問題

對於使用 Helm 的應用程式來說，我們可以透過 helm repo 的方式來觀察最新版本，這部分簡單。
但是對於其他的安裝方式，有些可能只能觀察 Github/GitLab 的頁面，或是相關的 Tag 來知道最新的 image 有哪些。

作者於文中示範如何使用 nvcheckr 來檢查不同軟體的最新版本，並且輸出可更新的選項讓管理員人知道有哪些需要處理。

對該議題有興趣的可以點選下列連結觀看全文
https://medium.com/bigdatarepublic/software-versioning-on-kubernetes-806a48480832

本篇文章是由一個微軟的工程師所分享的，如何視覺化團隊中 GitOps 的運作過程。

文章前半段描述與介紹微軟的開源專案 Bedrock，該專案重新包裝了 Flux 這套 GitOps 的工具，並且根據過往的實戰經驗重新調整而成的最佳實戰組合包

後半段作者開始介紹如何使用這套工具來搭建一個簡單的 GitOps 流程，並且介紹一個由微軟開發的視覺化工具，希望透過這套視覺化工具來解答下列問題


- 誰是這次修改的作者
- 哪個服務
- 哪個環境
- 哪個Branch
- CI/CD 的日誌
- 誰同意這次的部署
- 什麼時間發生的

針對 Flux 這套 GitOps 的工具，也會想要知道
- Flux 是否同步成功
- 叢集中的應用程式狀態是否如 Git Repo 內文件所描述的一致
- 有沒有任何 Pod 失敗
- 有沒有規模擴大的需求？
- 節點的狀態

為了解決這些問題，微軟開發了 Spektate 這套開源專案，這些內容都可以於 Bedrock 這套大補包內找到


原文: https://samiyaakhtar.medium.com/gitops-observability-visualizing-the-journey-of-a-container-5f6ef1f3c9d2

今天這篇文章是個基礎介紹文，跟大家介紹一下 Kubernetes 裡面的 Job，不同於 Pod 這種屬於 daemon 的運算資源， Kubernetes 提供了 Job 以及 CronJob 這種一次性的運算資源。 

Job 以及 CronJob 差異就是什麼時候該執行，Job 就如同其他資源一樣，創建到 Kubernetes 內後就會開始執行，而 CronJob 則是可以制定一個時間點，去定期反覆的執行

雖說 Job 是一次性的工作流程，但是對於 Kubernetes 來說，最小的工作資源就是 Pod，所有更高階的抽象資源都是基於 Pod 配上不同的 Controller 來完成。
Job 的設計也是如此，最終運行勢必是叫起一個 Pod 來幫忙運行，但是 Job 則會期望該 Pod 最後可以進入 Completed 的狀態。

什麼情況下我們可能會使用 Job 而非其他資源如 deployment/daemonset/statefulset ?
譬如說一個 AI 的模型訓練，一次物件的偵測 甚至是一些系統資源的檢查與清除，這類型的工作都可以考慮用 Job。而那些 Server 類型需要長時間存活的服務則應該使用其他高階類型的資源來部署。

原文算是非常清楚的介紹 Job 的使用，包含了諸如 backofflimit, parallelism, activedeadlineseconds 等參數的含義，並且也有透過實際的範例來展示怎麼使用。

如果對於 Job 這種物件不熟系的，可以參考一下原文來學習一下怎麼使用
https://levelup.gitconnected.com/understanding-jobs-in-kubernetes-541614ccd796

文章開頭借用了日文的 Poka-Yokes 來分享有哪一些準則或是技巧可以讓你打造一個具 Mistake-Proof 的 Terraform 程式。

文章內列舉了四個準則，這邊簡單列舉了一下每個準則的概念，詳細資訊可以閱讀全文

# Rule 1: Use Terraform Modules to abstract specific pieces of infrastructure into logical groupings
1. 針對需求與架構去拆分你的 Terraform Module，舉例來說，創建一個名為 ECS Service 的 Module，而該 Modules 內其實會創建如 ECS, autoscaling target, metrics 等諸多資源。也正式這些資源相互合作才真正的搭建出 ECS 的服務
2. 上層的應用接下來都會以 ECS 服務為考量去使用，本身不需要去考慮太多底層創建的資源，透過變數的方式來讓不同的呼叫者有不同的 EC 服務


# Rule 2: Use Terraform Data calls to provide information
1. 人類其實很容易犯錯，特別是一些反覆執行的工作。但是電腦非常擅長這類型的工作
2. 相對於要求使用者或是開發者維護各類資源的 ID 或是資訊，更好的做法是利用 Terraform 內的 data 功能，主動地從遠方抓取這些資訊，並且搭配 filter 來過濾不必要的資訊。


# Rule 3: Be Smart About Where Interpolation and Concatenation Happens
- 創建應用時，很容易透過 Copy/Paste 等方式來創建相關資源，這時候就要特別注意資源的名稱是否有重複，是否忘了修改
- 透過變數的方式幫資源命名，但是要注意如果你今天想要修改命名的規則，每個有用到該資源的檔案都要去修改
- 有使用 Module 的話，可以考慮於 Module 呼叫時去組合相關名稱，而不是 Module 內組合。

# Rule 4: Implement State Locking for Ease of Deployments
- Lock 非常重要，透過 lock 機制我們可以避免同時有多個更新造成狀態不一致


有興趣的可以點選連結來觀看全文
原文: https://medium.com/capital-one-tech/terraform-poka-yokes-writing-effective-scalable-dynamic-and-error-resistant-terraform-dcbd6a0ada6a

本篇文章是個入門介紹文，主要探討 Liveness 以及 Readiness 這兩個非常實用且重要的觀念。
由於這兩個元件並不是一個基本 Pod 所要的基本元素，所以如果沒有特別研究與使用時，可能也不清楚原來還有這兩種不同的探針可以幫忙我們更友善與彈性的去管理 Pod，準確來說更是 Container 的行為。

過往我們在運行一些應用程式的時候，可能都會有所謂的暖身期，應用程式起來到真正可以提供服務中間會有一些初始化的過程要跑，可能需要幾秒，甚至到一分鐘都有可能。

但是當應用程式給容器化後，對於最上層的管理平台來說，如果我今天只用 Continaer 是否叫起來 當作該應用程式的狀態，實際上遠遠不夠的，就如同上述提到的，會有一些初始化等暖身時間需要等待，而這兩個探針就是從不同角度去幫忙輔助，讓 Kubernetes 有更多方式去判別到底當前 Container 是否已經準備就緒，是否可以認定已經是運行狀態甚至可以接受網路流量

如果對這兩個概念還不熟的，可以參考原文搭配一些範例學習一下

https://devops4solutions.medium.com/kubernetes-pod-health-check-liveness-and-readiness-probe-1118a265c193

今天這篇文章是作者過去三年多來維護 kubernetes 叢集下的經驗談，作為一個每天維護 400 台以上機器，超過 20 多個 Kubernetes 叢集的管理人員，要如何有效率的去控管與查看不同叢集，不同 namespace 則是一個值得注意的議題

作為一個 kubectl 工具愛好者，作者整理了自己使用的四個小技巧來幫助自己每天有效率的去管理多個 kubernetes 叢集。

1. 善用其他 log 工具來同時監控多個 pod
如果常用 kubectl logs 的人不知道有沒有過下列經驗，(1)每次要觀看特定一個 pod 的時候都要用滑鼠去複製貼上那些充滿亂數的名稱，(2)想要同時監控多個 Pod，也許這些 Pod 也不屬於同樣的 deployment，(3) 有時候根本記不得這些 pod 有哪些 label 可以用，所以還是採用最預設的參數使用

如果有這些問題的可以考慮使用看看一些針對 log 的解決方案，不論是本篇文章提到的 kubetail, 或是其他的方案如 stern, kail 等，都可以嘗試使用看看

2. 提供一個動態方式去修改預設的 namespace 而不是每次指令都要一直不停的輸入 "-n"
當今天已經很明確接下來的指令操作都會固定於某個 namespace 內來管理時，可以直接切換預設的 namespace，這樣操作上可以很下一些時間，同時也可以避免中間有任何指令不小心忘了輸入 namespace 導致不預期的操作

3. 修改 shell 讓其顯示必要資訊
這也是我非常推崇且自己一直都有使用的方式，透過修改 shell prompt 的方式讓其告知當前使用的 context 以及 namespace 是誰

如果你本身有管理多個 Cloud Provider 帳戶的，我認為也可以透過這種方式來幫忙提醒自己

4. 將常用的指令透過 alias 的方式給縮寫
透過此方式可以減少打字的時間，同時指令愈長，不小心打錯的機會也就愈高

整體而言就是，想盡辦法讓自己工作更有效率，能省則省，同時也要尋找一些機制降低錯誤發生率。

https://medium.com/better-programming/4-simple-kubernetes-terminal-customizations-to-boost-your-productivity-deda60a19924

「I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it. Frank B. Gilbreth Sr.」

如果可以，誰不想更輕鬆的完成工作

今天分享的這篇文章是作者從自己過去的工作經驗擷取出來一些關於自動化的思維，畢竟人本來就不擅長反覆執行工作，還容易因為粗心，恍神等造成差錯。這是電腦相反，其非常適合處理這種枯燥且反覆的工作。

作者認為作為一個開發者，我們必須要先理解與釐清，日常生活中，到底有哪些事項與流程是有機會自動化的，有機會讓電腦幫我們完成。

文章內，作者分享了四個他覺得值得自動化處理的流程，當然這些只是冰山一角，做重要的還是自己能否從中擷取有用的知識與概念，並且套用到自己的團隊與日常生活中，透過這些自動化的處理，讓自己能夠更專心的處理更重要的工作，而這些重複且瑣碎的事項就讓電腦來幫忙吧

作者列舉了四個自動化的範例，詳細內容可以參考全文
1. Code Style Checks
2. Automation on GitHub
3. Localization Integration
4. Deployment Pipeline


https://medium.com/dev-genius/4-automation-ideas-for-developers-5e0985fd83b9

本篇文章探討的是 Terraform 12.20 所推出的兩個新功能， can() 以及 try()，來聊聊這兩個新功能對於開發者來說能夠帶來什麼樣的效益

can 這個功能主要是用在變數的簡單測試，譬如幫你確認變數的數值是否符合預期，這邊也可以搭配 regex 這種正規表達式的方式來幫你驗證輸入值是否符合規範。

try 這個功能目前使用起來跟大家寫程式所習慣的 try/catch 有點類似， try 之中要傳入一系列的參數，然後 try 會回傳第一個沒有發生錯誤的參數。因此如果今天有一些資料處理比較複雜的部分，可以考慮使用 try 來幫忙驗證。
舉例來說，今天需要透過 yamldecode/jsondecode 的方式來處理一些動態資料，我們可以撰寫類似下列的程式碼

locals {
  raw_value = yamldecode(file("${path.module}/example.yaml"))
  normalized_value = {
    name   = tostring(try(local.raw_value.name, null))
    groups = try(local.raw_value.groups, [])
  }
}

來幫忙判斷到底該資料有沒有成功抓取並且解析，此外我們也可以透過 try 的方式來達到一些變數的兼容性。
譬如說我希望當某個變數是字串時，回傳一個長度是一的陣列，當變數是一個陣列時，直接回傳一個陣列。 參考用法如下

locals {
  example = try(
    [tostring(var.example)],
    tolist(var.example),
  )
}


點選下列文章或是官方文件來學習更多！

https://levelup.gitconnected.com/using-terraforms-try-can-and-input-validation-eb45037af2b2

今天這篇文章要探討的是如何透過 helmfile 這個專案來管理你的 helm charts，你如果目前是採用 helm charts 來管理 kubernetes 內的應用程式，同時單純使用 helm charts 覺得卡卡的，想要探索更多不同的管理工具，那非常推薦來研究看看 helmfile

# 可能問題
過往使用 Helm 來管理應用程式時，你會需要使用 helm 這個指令來進行管理，不論是安裝，解除，升版，降版，甚至是傳遞不同的參數，這一系列的操作都需要透過 helm 的指令來安裝。
當今天目標叢集內有多個應用程式都需要透過 helm 來處理時，你會怎麼做？

一種可能的做法就是撰寫相關的 script，把所有會用到的 helm 指令都包進來，接下來於 CI/CD 的過程中去呼叫這個 script 來處理

那有沒有一個現成的工具，可以更優雅的幫忙處理這個問題，甚至透過這個方式讓我們也可以採用 Infrastructure as Code 的方式來部署與管理 Helm Charts.

如果你對於這個議題有興趣，可以快速的看看下列原文，原文中用一個簡單的範例去示範如何使用 helmfile 來安裝與管理多個 helm charts.

https://medium.com/swlh/how-to-declaratively-run-helm-charts-using-helmfile-ac78572e6088

今天這篇文章探討的是 Git 的 pre-commit hook 系統，透過這種 pre-commit 的系統，能夠幫助開發者與本地開發時，先行進行一些處理，避免什麼問題都要丟到遠方的 CI/CD pipeline 去檢查。畢竟程式碼更新，觸發 CI/CD 流程，等待結果告知，這部分有時候都要花上數分鐘，往往就是檢查到一個格式錯誤，譬如拼字錯誤，多一個空白，格式錯誤等。

如果今天可以將一些常用的檢查給複製一份到本地端去執行，這樣開發者可以更快地找出錯誤，同時也可以節省很多等待的時間，因此本篇文章就要針對 git pre-commit hook 來介紹。

本篇文章要介紹的並不是直接使用 git 的 pre-commit hook，而是要使用 python 的套件 git pre-commit hook，其龐大的生態系可以幫助使用者輕鬆的使用常見的 yaml 格式來管理 git 本身的 pre-commit hook。舉例來說，可以於專案底下放置一個有下列內容的檔案

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.2.0
    hooks:
    -   id: trailing-whitespace
    -   id: end-of-file-fixer
    -   id: check-yaml
    -   id: check-added-large-files

透過 python 的 pre-commit hook 系統，會將其中描述的四個功能 (trailing-whitespace....check-added-large-files)實際的程式碼給轉換並且安裝到 .git/hooks/pre-commit 底下。

同時透過這種框架，開發者也可以自行開發屬於自己的 pre-commit hook並整合到該 yaml 檔案之中。整個使用的方式非常簡單

1. 透過 python 的方式安裝 git pre-commit 
2. 準備一個名為 .pre-commit-config.yaml 的檔案，並且描述你希望使用的 hook
3. 透過 pre-commit install 的方式將該 yaml 的內容轉換為真正 git 所使用的內容
4. 可以開始透過 git commit 來幫助你進行本地檢查囉

如果對於提升本地開發效率有興趣的人，不要錯過研究看看 git pre-commit 這種機制，不論是直接撰寫 git 或是透過這種 python 的 git pre-commit 框架，只要能夠幫忙解決相關問題，提升效率就會是一個值得研究的方法。
更多的 hook 參考以及該框架介紹，請點選下列全文來觀賞囉
https://towardsdatascience.com/pre-commit-hooks-you-must-know-ff247f5feb7e

今天這篇文章是一個 Jenkins Container 的特殊玩法，作者使用五個連續的 Jenkins Job 來打造一個測試應用程式的環境，期望透過這種機制來打造出一個符合不同程式語言的流水線。

第一個 Job 會先嘗試抓取遠方的程式碼，譬如 GitHub Repo 遠方的 code.
第二個 Job 會根據該專案的程式語言呼叫起不同的 Container 來運行測試環境
第三個 Job 則會根據前述的環境來進行測試，根據結果來判別本次的修改是否正確
後面兩個 Job 主要偏向監控以及通知用的，如果本次修改導致測試失敗，會將 log 訊息以及相關資訊傳送給 admin 告知有工作失敗

註:我個人是覺得與其這樣弄，不然專心讓每個 job 對應一個程式語言，然後使用 Jenkins Job Builder (JJB)來管理這些 Job，這樣每個 Job 的工作也明確也專一，維護起來也方便。
不過文章就是多看也不錯，也許用不到，不過至少可以知道會有人這樣弄，也可以從中反思這樣的優缺點。

https://medium.com/@fmirikar5119/deploying-applications-with-jenkins-container-34fd0348282f

今天這篇文章是一個入門介紹文，跟大家介紹一下 Secret 這個物件。與 ConfigMap 一樣， Secret 也是 Kubernetes 內建的一個特別儲存單元，用法完全與 ConfigMap 類似，但是最大的差異在於其本身的內容必須要透過 base64 進行編碼以及該物件本身會放在 tmpfs 而非真正的檔案系統下。
但是也就是這個編碼以及 Secret 這個名詞很容易讓人搞混，以為把所有的東西都放到 Secret 就安全無誤，實際使用上才會發現這並沒有很安全。
因此本篇介紹完會探討 Secret 的使用方式，以及實務上可以怎麼使用

1. 透過 yaml 這種 declarative 的方式來描述 secret 的內容，這種格式下也有多種用法
a. [removed] tls, docker-registry。
如果你有使用過 imagePullSecrets 這種類型來存取非公開的 contaienr registry 的話，就會需要使用 docker-registry 這種類型來存放相關的存取資訊。

由於上面提到的 base64 都是編碼，並非加密，因此如果有任何加密的需求，請一定要考慮使用不同的解決方案，譬如 Vault, Sealed Secrets, Helm Secrets 等不同的解決方案，千萬不要把 secrets 的內容直接編碼就放到公開的 git repo 上，這樣是完全沒有安全性可言的。


如果對於 secrets 這個物件還不太熟的，可以參考這篇文章看看各種基本用法

https://medium.com/better-programming/how-to-use-kubernetes-secrets-for-storing-sensitive-config-data-f3c5e7d11c15

容器的蓬勃發展使得現在大部分的開發者都一定聽過 docker 甚至是 container 這類型的名詞，但是對於維運人員來說這完全不夠，他們更在意的是如果要將這些容器化的應用程式給部署到生產環境上，要如何面對千變萬化的環境並且能夠處理得妥妥穩穩的。

為了解決這個問題，勢必要有一套容器協同合作方案，能夠處理至少下列四個功能
1. Scheduling: 決定哪些 container 要運行到哪個節點
2. Management: 容器的生命週期該怎麼管理
3. Service Discovery: 不同的容器服務要如何存取彼此
4. Load Balancing: 透過負載平衡的方式來轉發各式各樣的流量

過去百家爭鳴的時代已經慢慢消退，2021 的這天，我想 Kubernetes 是所有人想到這個問題的第一直覺反應。

本篇文章是 2018 年底的文章，作者想要描述到底一個容器協同方案應該長什麼樣子，要提供什麼樣的功能，也許最後其實作與使用方式與 Kubernetes 不盡相同，但是其背後的目的都是一致，希望能夠提供的解決方案讓大家開心的使用容器化的應用程式來面對各式各樣的部署環境。

本篇文章中，作者採用了 Nomad 以及 Consul 來描述這兩個開源解決方案如何組合出一個容器協同平臺，同時簡介了一下這個架構的樣貌以及特色。
透過這兩個解決方案至少達成了 scheduling, service discovery, load balancing 等基本需求

也許現在的你都在使用 Kubernetes 來完成每日所需，但是看看這些不同解決方案的設計與樣貌，也可以幫自己補充一些廣度的知識，讓你可以理解到底這些開源軟體之間的差異

https://medium.com/@obenaus.thomas/how-a-production-ready-container-orchestration-system-could-look-like-6f92b81a3319

Rancher 於 2020 十二月份推出了一個全新的開源專案， Harvester，這個專案主打的目標不同於以往，是個非常特別的領域，所謂的超融合架構 (Hyperconverged Infrastrucuture)。

Harvester 是一個基於 Kubernetes 架構的解決方案，其本身也整合其他開源軟體來提供虛擬化以及儲存這些 HCI(超融合架構) 的基本需求，同時透過其抽象化的介面，讓使用者不太需要理解 kubernetes 也能夠使用這套 Harvester 。

Harvester 底層技術包含了 Kubernetes, KubeVirt 以及 Longhorn, 透過這些的整合來達到上述的虛擬化 (VM+容器)，儲存系統管理。

# 特色
1. Harvester 透過 Multus 這套 CNI 來達成多個 CNI 組合，藉此讓 K8s 裡面的 Pod 都有可以多個網路介面
2. 透過 Longhorn 來達到 scale out 的儲存需求
3. 透過 Kubevirt 來達到 VM 的生命週期管理
4. 透過 MinIO 來管理 VM Image

整套解決方案最後也整合 Rancher 本身的介面，讓你可以透過 K8s 這技術同時管理容器＋虛擬機，如果你過往有玩過 HCI 這個議題的，我認為你可以參考一下，看一下這套解決方案到底怎麼玩，跟過去的經驗有什麼不同

https://rancher.com/blog/2020/announcing-harvester-open-source-hyperconverged-infrastructure-software

#SDN閒談

今天來簡單跟大家科普聊聊所謂的 SDN(Software-Defined Networks) 軟體定義網路的簡單概念，到底其代表什麼，以及在什麼情況下我們需要去理或使用它

SDN 一詞的發展最早可以追朔到 2008 年由 Nick 教授所發表的論文，該論文中設計了一種嶄新的網路協定，稱為 Openflow, 期望透過 Openflow 這種協定來定義該如何傳輸風封包，簡單的說就是「看到什麼樣的內容/標頭，就做什麼事情」。

SDN 的重大核心概念就是透過「軟體」去「定義」你的「網路行為」，系統中會有一個控制器，該控制器透過一種集中化的方式以上帝視角去窺視整個網路拓墣，並基於此架構下去進行網路封包傳輸的設計，譬如「我想要讓符合特定規則的封包可以通過，請幫我設定網路裝置A,B,C,D 來符合我需求」

發展了多個年頭後， Openflow 實際使用上遇到瓶頸，對於純軟體概念來說， OpenFlow 可以使用，但是要將這個精神給套用到硬體交換機上來達到又快速，又彈性的功能時就會遇到挑戰，因此後續又有新的技術誕生，P4(Programming Protocol-Independent Packet Processors)，透過這套技術漂亮的解決過往 Openflow 太過制式化的問題。

SDN 的領域中，也有很多的相關開源專案，從常見的 OpenVswitch, ONOS, OpenDaylight 到 Stratum, SONIC 等都從不同面向來搭建出這樣的網路架構

但是，我自己認為 SDN 就是一個精神，你可以談廣義的 SDN，也可以談狹義的 SDN，有些人會認為 2008 以後所談的概念與技術才有資格稱為 SDN，也有人認為只要我能夠用軟體去控制這些封包傳輸，我就是 SDN，譬如我自己寫一套軟體去大量控管多節點的 iptables 來實現多節點的防火牆設計。
這種情況下，說是「軟體定義網路」也通，只是要如何解讀就是每個人信仰的不同罷了，其實沒有必要爭論誰才是正統，
SDN 就如同 DevOps, CI/CD 等概念一樣，都有一個參考的文化與概念，但是並沒有一定的實作方式，結果論來說就是，整個網路架構如何打造，對於開發者，對於維運者如何使用而已。

從我自己的角度出發，去看待這個產業反而最大的一個議題是，要同時找到會寫程式也有網路概念的人真的很難。
過往仰賴廠商解決方案的人，可能非常熟稔各自的操作模式，譬如各式各樣的 CLI 操作介面。
然而當這一切生態系被打破時，任何人都能夠透過撰寫程式來控管，用你習慣的程式語言來控制整個網路功能，譬如決定什麼樣的封包從哪個網孔出去，修改什麼樣標頭內容，又或是要如何解讀這些封包。要同時擁有寫程式以及網路概念就變得非常困難。

這邊的網路並不是單純大家熟悉的 TCP/IP 而已，實際上有非常多的概念與面向，譬如 Segment Routing, BGP/OSPF, VXLAN/GRE/GTP, VLAN/QINQ, MLAG/Bonding，甚至更複雜的 Broadband (OLT, ONU..), Mobile Core (LTE/5G)... 等 

如果你對於 SDN 這個概念有興趣，非常推薦由 Open Networking Foundation (開放網路基金會) CTO 與他人一同撰寫的電子書，從系統化的角度帶你認識 SDN 的發展，從過去到未來

https://sdn.systemsapproach.org/index.html

今天不聊科技，來聊聊日常工作中的優先度選擇。
作者認為每當你對一件事情說 Yes，其實你就是對其他的事情說 No，因為我們時間有限，不可能每件事情都想要盡善盡美，而那些被你自動說 NO 的事情，其實有些可能反而能夠為你帶來更大的效益。

整篇文章都圍繞於機會成本的概念，探討到底什麼是機會成本，其中顯性機會成本以及隱性機會成本的差異是什麼。

就我個人來看，其實日常工作中也是充滿各種選擇，舉例來說，今天要有一個新的專案要開發，你要負責對其處理 CI/CD 等相關工作，你會怎麼安排自己的 Task ? 這些彼此間的優先順序會怎麼選擇？

也許你腦中會想到有下列的事情要完成

1. 打通 CI/CD 流水線
2. 完善 CI 系統，增加各種檢查，譬如 unit test, linter 或是其他種類
3. 完善 CD 系統，自動上版本，自動更新

但是仔細看會發現，其實(3)這點真的一開始就可以辦到嗎? 需不需要一個手動部署的版本先撐住? 然後根據這些結果再跟(2)去比較，到底開發團隊一開始需要什麼?

其實時間有限的情況下，我們往往都需要進行選擇，困難的是這些選擇永遠都沒有一個標準答案，不同團隊不同環境下，相同選項都會有不同答案。

我個人也滿認同作者提到的概念，時間有限，將精力與時間放到更具有價值的開發與工作上，那些可以展現你個人價值與光芒的工作，未來可能都會是你職涯的推手。
更多的工作團隊中，你的價值是自己帶出來的，而不是別人指派給你的，因此我認為如果你有機會獨當一面去處理一系列的工作，如何展現出你的價值就是一個值得訓練也值得培養的能力與議題

原文：
https://dariusforoux.medium.com/say-no-anything-thats-not-a-priority-9ed70064d0b6