ref: https://medium.com/nerd-for-tech/ceph-ansible-deployment-testing-using-vagrant-8205a9f39f2d

本篇文章是一個工具分享文，探討如何使用 Vagrant 來架設一個 ceph 叢集環境來測試與開發。

Ceph 是非常知名的分散式儲存的解決方案，其提供 Object, block 以及 file 等儲存空間供不同需求的應用程式使用
Ceph 本身是由多個不同的組成元件所組成，這也是為什麼會稱 Ceph 叢集的概念，元件包含
1. Monitors(MON)
2. Managers(MGR)
3. Metadata Servers(MDS)
4. Object Storage Devices(OSD)

CNCF 畢業專案 Rook 則是一個將 Ceph 與 Kubernetes 整合的解決方案，其簡化了部署 Ceph 的複雜度，讓使用者可以更輕鬆的透過 Kubernetes 去部署一套 Ceph 叢集環境來測試與開發。
不過並不是所有使用 Ceph 的環境都會搭配使用 Kubernetes，作者觀察到目前網路上至少有七種以上的部署方式，而其中最知名也受歡迎的部署方式就是透過 Ceph-Ansible 來安裝。

本篇文章作者探討如何透過 Ceph-Ansible 來部署 Ceph 叢集。
Ceph-Ansible 內本身就有提供 Vagrant 的設定檔案，透過修改設定檔案就可以很順利的自動架起多個 VM，接者透過 Ansible 將 Ceph 的服務依序安裝上去最後就可以順利的搭起一個 Ceph 叢集環境來測試與開發。

本篇文章基本上要對 Ceph 有理解才會比較有背景去閱讀，對於 Ceph 有興趣的人可以參考看看

ref: https://loft.sh/blog/the-cost-of-managed-kubernetes-a-comparison/

本篇文章探討不同 Cloud Provider kubernetes 服務的差異，作者列舉了四個常見的 kubernetes 服務，包含 GKE, EKS, AKS 以及 DOKS。

這四個 kubernetes 服務所部署的 Kubernetes 叢集都有獲得 CNCF Kubernetes Certification 的認證，不同 Cloud Provider 都有自己的優缺點。
使用 Kubernetes 服務帶來的好處就是使用者通常不太需要去擔心如何處理
1. Kubernetes 核心元件之間的 Certificate (API Server, Controller, Scheduler, Kubelet ...etc)
2. 動態調整 Kubernetes 節點
3. 相較於單純靠社群， Cloud Provider 可以提供更快速且更好的支援(畢竟有付錢給對方)

因此該文章接下來就會針對這四個 Kubernetes 服務來探討一下彼此的差異。

註: 有興趣的話都可以用 Sonobuoy 這個開源專案來檢測自己維護的 Kubernetes 叢集，通過測試就可以把測試報告送到 GitHub 開 Issue 申請認證


GKE
1. Kubernetes 正式公開後一個月就 GKE 就出現了 (08/2015), 是最早的 Kubernetes 服務
2. GKE 會使用 gVisor 專注於安全層級的容器隔離技術來部署服務。
3. 有機會使用針對 Container 最佳化的 OS，有些 cloud provider 只能使用 Ubuntu image 之類的。
4. 服務出現問題時，可以啟動 auto-repair 來修復叢集，一種典型作法就是將一直回報為 NotReady 的 k8s 節點給重建
5. GKE 提供自動升級 Kubernetes 版本的功能，如果不想要的話記得要去關閉這個功能，否則自動升級是有可能讓某些應用程式無法正常運作的。
6. 使用 GKE 的話，要付每小時 $0.1 美元的管理費。如果使用 on-prem 的解決方案 (Anthos) 的話就可以免去這些管理費。

EKS
1. 06/2018 創立
2. 可以使用 Ubuntu Image 或是 AWS 針對 EKS 最佳化的 EKS AMI 來獲得更好的效能。
3. EKS 沒有提供自動升級 Kubernetes 版本的功能，官方有提供大量詳細的文件介紹如何手動升級 Kubernetes 版本
4. 沒有類似 auto-repair 的機制去幫忙監控與修復出問題的 k8s node，因此 EKS 使用者需要自己去監控與維護這些節點。
5. EKS 也是每小時 $0.10 的管理費用。 AWS Outposts/EKS Anywhere 這些 2021 啟動的專案讓你有機會將 EKS 部署到 on-prem 的環境中。

AKS
1. 06/2018 創立
2. AKS 沒有提供任何最佳化的 OS，你只能使用常見的那些 OS image 作為你的 k8s 節點
3. 預設情況不會自動升級 kubernetes 版本，不過 AKS 提供選項去開啟自動升級。Cluster 有四種不同策略(none,patch,stable,rapid)來自動更新你的 k8s 叢集。
4. AKS 預設不會啟動 auto-repair 功能。對於一直持續回報 NotReady 的節點， AKS 會先重起該節點，如果問題無法解決就會砍掉重建節點。
5. AKS 不收管理費
6. Azure 沒有特別提供一個供 on-prem 的 AKS 解決方案，不過透過 ARC 是有機會於 on-prem 的環境運行 AKS.

DOKS(DigitalOcean)
1. 05/2019 創立
2. 有提供 kubernetes 版本自動更新功能，但是只有針對 patch 版本的變化
3. 沒有 auto-repair 的功能
4. 文章撰寫的當下， DOKS 沒有任何文件說明如何於 on-prem 的環境運行 DOKS
5. 不收管理費
6. 相對其他三家來說，底層架構相對便宜，一個 DOKS 最低可以低到每個月 $10 美元。

價錢比較:
1. 假設需要創建一個擁有 20 節點並且有 80vCPU, 320GB RAM 的叢集 (GKE 因為每個節點都是 15GB，所以最後只能湊到 300GB)
2. 每個月為單位去計算價格，AKS/EKS/GKE 都使用其提供的價格計算機來粗估， DOKS 需要手動計算。
3. 價錢評比
a. AKS: $3416
b. EKS: $2928
c. DOKS: $2400
d. GKE: $1747

對文章有興趣的別忘了參閱全文

ref: https://cmdchallenge.com/#/last_lines

今天分享的是一個有趣的 Command Line Interface(CLI) 挑戰，該挑戰主要是基於 Linux bash 的環境有一系列的指令挑戰

挑戰內容基本上都不會太困難，一開始都是非常基礎的 Linux 指令操作，後面會需要使用 grep, sed, awk, find 等不同指令的組合來完成任務。
大部分的題目都會基於一些情境，譬如想要針對 httpd server 底下的 log 進行過濾，計算符合某些內容的行數等等

每道題目除了自行挑戰外也可以看一下別人的解決方案，不過解決方案中有一些是作弊的內容，譬如直接針對題目用 echo 輸出之類的，就滿搞笑的。

我認為這類型的挑戰有兩個值得去玩看看的理由
1. 測試自已是否能夠解決每一個問題，順便看一下自己的解決方式跟別人的比起來如何，有時候會有一些意想不到的指令與用法可以讓整個寫法更為簡潔
2. 如果有面試需求的時候，可以考慮從這邊找一些相關題目，看看面試者對於 shell script 的熟悉度，同時互相討論每個解法的好壞處。

歡迎愛寫 shell script 的人都寫一遍看看

ref: https://jzimnowo.medium.com/harbor-keycloak-and-istio-a-good-dance-troupe-6c3520fb87de

本篇是個經驗分享文，作者想要打造一個基於 Kubernetes namespace 的多租戶 Kubernetes 平台。
該平台主要針對的是團隊內不同的 DevOps team，並且每個 Team 都會有自己的下列資源
1. Harbor: Private Container Registry
2. Keycloak: SSO
3. Istio: Service Mesh.

# Harbor
Harbor 是 CNCF 的畢業專案，專注於提供 private container registry，本身除了有友善的操作介面外，也整合了多項常見功能，譬如
1. 基於 OIDC 的授權認證機制
2. 容器安全性掃描
3. Chartmuseum (未來會被移除)
4. 專案管理

透過 OIDC 與專案的機制，能夠很輕鬆的針對不同專案設定不同權限，譬如屬於群組 A 的只能使用 Project A。
此外每個專案本身也有提供 robot account，該 robot account 的目的則是讓整個工作流程更佳簡潔。

如果要於 Kubernetes 中去抓取這些 Private Container Registry，則必須要透過 ImagePullSecret 的物件來描述登入資訊。
為了避免使用個人帳戶來存取，作者推薦每個專案都要準備兩個 Robot Account，這兩個 Robot Account 都只能針對該專案底下的 container 去存取
所以也不用擔心會去存取到其他 Team 的專案。
第一個 robot account 專注於 Pull Image，主要是讓 Kubernetes 內部可以下載 Image 使用。
第二個 robot account 則是給 CI/CD pipeline 使用，讓 pipeline 有能力將新的 image 給推向 Harbor。


前述所說 Harbor 可以基於 OIDC 來滿足認證的機制，作者於團隊中就使用 Keycloak 這個開源來作為一個 OIDC 提供者(另外一個常見的是 Dex)。
文章中有稍微介紹如何於 Keycloak 中創立一個 Client 的物件，並且於 Harbor 如何設定。
如果團隊有這個需求的可以看一下要如何操作。

文章最後探討使用這三個專案的一些經驗與痛點，有興趣的可以閱讀全文參考

ref: https://dlorenc.medium.com/improving-tofu-with-transparency-da674aa2879d


本篇文章要介紹的是一種名為 TOFU 的認證機制，其全名為 Trust-On-First-Use.

要探討這個機制前，作者先列舉一個情境
假設你人要到火車站去找一個名為 Alice 的人交換手提箱，你要如何於火車站正確的找到 Alice?

# Nothing
最基本的情況就是你看到每個人都詢問，你是不是 Alice，但是任何人都可以說謊假裝自己是 Alice，因此惡意攻擊者跟 Alice
一樣都可以輕鬆回答你「我就是 Alice」，顯而易見這種機制基本上沒有辦法幫助我們找到 Alice，也沒有辦法分辨到底眼前的人是惡意攻擊者還是 Alice。

一種改善的機制就是 PKI (Public Key Infrastructure)，該機制的概念是
1. 有一個第三方服務會發行相關的 ID 證件，該 ID 證件難以偽造 (譬如 Certificate Authorities)
2. 你信賴這個第三方服務

所以你到火車站之後，每遇到一個人就要求對方出示其 ID，並且請第三方服務幫忙驗證這個 ID 證件是否合法，透過這種概念來找到到底誰是 Alice。

這種機制運作起來沒有問題，唯一的問題就是找到一個可信任的第三方服務相對複雜且困難。

有沒有一種相對簡單又有點有效的機制? 就是本篇要探討的 TOFU

假設情境改成，今天需要頻繁的到火車站去找 Alice 交換行李箱，這件事情會重複非常多次。這種情境下，我們可以
記住第一次遇到號稱自己是 Alice 的那個人，接下來每次都找該人交易。
簡單來說就是，相信第一次遇到的人，並且記住該人的狀態與面貌，接下來每次交易都直接尋找上次熟悉的面孔。

網路世界來說，一個非常知名使用 TOFU 的軟體就是 SSH。
SSH 使用者第一次連線到遠方 Server 時會相信自己連接到的是正確的 Server，同時將 Server 本身的指紋資訊給存入到本地快取。
因此接下來每次連接到該 SSH 的時候，就直接比較 Server 的指紋是否一致來確定是否連線。
這個機制聽起來很可怕，不過對於這種「很難預測第一次連線的 Server 是誰的狀態」的情境是滿堪用的，畢竟不容易一開始就被偽裝攻擊。

另外一個使用 TOFU 機制的概念就是 supply-chain security，假設你要透過 Packager Manager 來使用不同版本的 Package
這種情境下系統要如何信任每次抓到的 Package 都是正確的?

透過 TOFU 的機制將每個 Package 的 Hash 值都存放 local，這種情況下就可以去比對第二次，第三次下載的內容是否一致。
不過對於 CI 環境下，要一直維持 local cache 實在不容易，因此 Trust-On-First-Use 就會演化成另外一種 Trust-On-Every-Use.

文章後續還介紹 golang 生態系的 go get 是採用何種機制去信任每次下載的 library，對於這篇文章有興趣的不要錯過

一年一度的鐵人賽又開賽了，這次跟又跟幾個好朋友們組了一個奇怪的戰隊，兩個 DevOps 領域加上三個 AI/ML 領域一起努力的於這30天產出共 150 篇技術好文。

這次鐵人賽想要跟大家分享如何使用 Rancher & Rancher Fleet 來嘗試不同方式 GitOps 解決方式。
Rancher Fleet 相對於現有知名的 Flux/ArgoCD 最特別的我想莫過於其客製化應用程式的方式，其不但同時支援 Helm 與 Kustomize 這兩種格式，更可以讓兩者同時運作來達到最大客製化。
試想一下想要針對一些第三方 Helm Chart 進行客製化但是對方 values 又沒有開放時該怎麼辦，這時候就可以透過 kustomize 透過 patch 的方式來動態加入檔案或是修改欄位。

唯一遺憾的是 Rancher v2.6.0 開賽前一天才正式發布，試玩了一下不是說非常穩定，因此這30篇文章還是會基於 v2.5.9 來介紹。

歡迎舊雨新知有興趣的都可以追蹤，相關文章之後也都會發佈到自己的部落格上
https://ithelp.ithome.com.tw/users/20120317/ironman/4034

ref: https://blog.mozilla.org/en/internet-culture/deep-dives/why-are-hyperlinks-blue/
本篇是一個歷史科普文，幫大家介紹為什麼瀏覽網頁內的超連結會是藍色的？
千萬不要想到超連結就覺得一定是 Netscape，從本文的歷史角度來看 Netscape 連前五都不算呢

作者從 2001 年就開始撰寫網頁，一直以來都沒有去思考為什麼超連結是藍色的，直到朋友某天的詢問才讓頓時傻住
這個自己視為理所當然的東西實際上必定也是某個發明，是什麼時候被決定的？誰決定的？為什麼決定是藍色的？

與同事一起找尋的結果是 Marc Andreessen and Eric Bina 於 01/23/1993
所發佈的 Mosaic(馬賽克) 瀏覽器是第一套提供藍色超連結功能的瀏覽器。

時間點來看的話
1. 1964 Project Xanadu 是第一個嘗試透過實體連結將兩個頁面的系統
2. 1987 第一套瀏覽器 WWW 誕生
3. 1993 第一個使用基於藍色的超連結瀏覽器出現
4. 2016 Google 開始嘗試將超連結顏色改到黑色

研究出這些歷史痕跡後，作者依然對於為什麼是藍色這件事情沒有著落
很多人都說因為對比色的緣故，所以超連結選則藍色。
作者認為 W3C 直到 1994 才出現，所以那之前所謂的標準都還沒有被定義，此外從對比的角度來看，藍色與黑色的對比程度是2.3:1，實際上也不是說多好。

作者後面從不同角度去思考出一個結論
1. Cello/Mosaic 假設它們的設計都受到該年代 UI 設計潮流的影響
2. 該年代是 Windows 3.1 崛起的日子，而 Windows 3.1 也是第一個重度使用藍色作為選擇色的系統（網頁中有展示 windows 3.1 中很多選擇都會呈現藍色)
3. 隨者支援色彩的電腦螢幕普及，Mosaic 也一起受歡迎，使用藍色的超連結逐漸變成一個習慣，因此此後的 IE/Netscape 等也就沿用這個藍色的設計。

對於歷史考古文有興趣的可以詳細閱讀全文

ref: https://lwn.net/Articles/853637/

如果對 SO_REUSEPORT 這個能夠提供網路服務吞吐量的 socket options 不陌生的話，那這篇文章強烈推薦看看。
本篇文章是從討論開啟 SO_REUSEPORT 這個選項會出現的一些行為以及可能可以怎麼做

最直得看的應該是留言區本身，有很多不同層級的討論，大家最愛講的 Google SRE 人也都出來分享自己的經驗了。


正常情況下，每個 TCP Port 只能被一個 process 給使用來聽取封包，但是對於一些網路重度使用的系統來說，就算讓該 process 將連線給分散到其他的 process 去處理，該 process 依然可能是系統的效能瓶頸。
Linux Kernel 3.9 後引入的 SO_REUSEPORT 參數就是為了解決這個效能問題而來的，這個參數允許多個 Process 同時使用一個 TCP Port，每當底層有一條新的連線請求時， Kernel 會從眾多的候選人之一中挑選一個可用來處理。
這種情況下，網路應用程式就可以專心處理連線工作，然後實務上同時執行多個 Process 即可。底層的 Kernel 會幫忙做連線的負載分配。

當眾多候選 process 其中之一掛掉了(可能是 crash，也有可能是有意的重啟)， kernel 會注意到這個候選人要說掰掰，這候選人處理的所有 connection 都會被移除，比較糟糕的是其他待在 Accept-Queue 那些還沒被建立連線的連線請求也會一併被移除。
作者認為 Kernel 應該要有能力可以轉移那些 Accept-queue 中的連線到其他還工作的候選 process 下去處理，這樣使用者/Client 的連線就不會需要處理太多重連的問題。

文章後面都在探討可行的做法以及這個問題可能會導致什麼問題。

留言區滿熱鬧的，譬如說
1. 有人認為 server 重啟的情況實在太少見，有需要為這麽少見的情況導入這麼複雜的修改到 Kernel 中?
a. 有人回答使用 Let's Encrypt 你可能每幾週就要重啟一次。
b. Google SRE 回答其內部因為調整設定的緣由，幾乎無時無刻都需要重啟服務，不過這問題已經從別的層級去處理掉，所以修改 Kernel 對他們的用途不太大。
2. 有人提出 Nginx 本身有 live migration 的功能，可以將 fd 給轉移到其他的 process 去處理。
a. 有人提出這邊談的是 socket/connection 的層級，這些東西都還沒發生到 userspace process 同時也不是 userspace 應用程式可以接觸處理的。
b. 本文探討的是 bind(), accept(), listen() 這類型 function call 之間 kernel 會幫忙做的事情。

有興趣的別忘了閱讀留言區

ref: https://wiki.bash-hackers.org/howto/redirection_tutorial
本篇是個 Linux 相關的教學文，專注於透過視覺化的方式來教學到底 shell 上常常使用的 >, 2>&1 等差異是什麼。
舉例來說，你能不能清楚的說出下列兩種用法的差異，實際上 fd 到底會怎麼運作?
1. > file 2>&1
2. 2>&1 > file

亦或是某些 shell script 常看到 exec 2>log 到底是什麼意思?

本篇文章解釋得非常清除，透過 /dev/pts 這種 pseudo terminal 為起點，將 0(stdin), 1(stdout), 2(stderr) 三個 fd 給視覺化呈現。
基於這個概念開始探討下列不同指令實際上 fd 會有什麼變化

# Simple Redirections
">" 應該是最為簡單也最廣為人知的用法，command > file 的方式將輸入(stdout)給導入檔案(file)。
那加上數字後會有什麼變化呢? 譬如 command 1>file, command 3>file ？

下一個不能不知的就是 pipe 的概念，透過 pipe 能夠組合出各種指令來解決問題，到底 pipe(|) 的過程中這些 fd 是什麼變化?

# More On File Descriptors
另外一個很常被問到的用法就是，有沒有辦法將 stderr 跟 stdout 一起 輸出?
這時候可能就會看到 1>&2 2>&1 等各種答案，那到底這些語法的背後是什麼意思?

非常推薦所有人都仔細閱讀這篇文章重新複習/學習這類型操作的底層變化。

ref: https://medium.com/sailpointtechblog/improving-on-call-engineering-at-sailpoint-35213090c35c

本篇是一個經驗分享文，Sailpoint 想要探討疫情後整個團隊是如何重建並且改善 On-Call 的整個運作模式。
因應 COVID 帶來的職缺變化，愈來愈多的遠端工作者加入到 SailPoint 的團隊中，整個 DevOps Team 的人數也因此整整翻了一倍。

過往的 on-call 流程基本上沒有什麼受到太多重視與關注，並且一直以來都運作的很好，但是隨者團隊人數與專案數量的提升，當前的運作方式只能用堪用來說
因此需要重新審思如何改善，加強整體效率。

SailPoint 之前的 On-Call 是使用 PageDuty 這套服務來處理的，因此團隊想要看看是否這中間還可以有改善的空間
不論是新的流程或是 PageDuty 有什麼功能是團隊還沒有妥善使用的。

Baby Steps with PagerDuty
PageDuty 有個名為 PagerDuty Virtual Summit 的年度盛會，作者團隊決定參加盛會來聽看看有什麼功能是目前沒有好好使用的。
除了 Digital Operations Tier 這個更加智慧甚至提供基於 machine learning 的相關控制功能外，作者團隊還學到了關於 Slack
的新整合功能，有鑒於整個團隊愈來愈趨向遠端協作， Slack 的使用也就變得愈加重要，因此團隊優先的將 Slack 整合該新功能。


Feature Rich Proof of Concept, A Short Story
1. 作者團隊於會後積極的聯繫 PageDuty 的團隊，想要針對各項新功能進行更多的探討與使用，這方面 PageDuty 也很積極的幫忙建立 PoC 環境與回答各種問題，讓團隊可以試用這些新功能
2. 第一個嘗試的功能是針對團隊的 RDS Alert 的智慧處理功能。過往當 DB 出現問題時 Cloud Watch 就會出現高達 60 多個相關 Alert，透過新的智慧功能這些 alerts 會被辨識為一個單一意外，就不會遇到 Alert 洗版的現象
3. 過往 RDS Alert 出現時，每次都要針對那些 Alert 一個一個的去 acknowledge，現在因為全部都統一辨識為單一 Alert，因此 acknowledge 也只需要執行一次，整個效率大幅度上升， on-call 的工程師可以花更多時間去專注解決問題。
4. 下一個嘗試的功能就是全新的儀表板，該儀表板顯示了 alerts 的趨勢變化與相關參數，這些資料讓該團隊每週的 on-call 會議有更多的資料去檢視過去一週的情況，藉此可以找到團隊中比較脆弱容易出事情的服務。

文章中還有兩個章節探討剩下的改善，對於 On-Call 有經驗也有興趣的人別錯過全文。

ref: https://www.infoworld.com/article/3632142/how-docker-broke-in-half.html

這篇文章是作者訪談多位前任/現任的 Docker 員工，Docker 社群貢獻者， Docker 消費者以及市場分析師的相關心得文，目的是想要探討 Docker 商業模式的成功與失敗，到底目前 Docker 商業模式的進展是否有跡可循，以及我們可以從這些歷史決策中學到什麼?

Docker 不是輕量級虛擬化技術的開創者，但是卻是個將 Container 這個技術給推向所有開發者的重要推手，Docker 簡化的整體的操作使得每個開發者都可以輕鬆的享受到 Container 的好處，但是從結果論來說， Docker 還是於 2019 年 11 月給 Mirantis 給收購了
到底 Docker 的商業模式哪一步走錯了，接下來就跟者作者一起去訪談與思考。

[Docker 的誕生之路]
Solomon Hykes(文章很多該人看法) 於 2008 年創辦一間專注提供 Platform as a Serivce 的公司, DotCloud，該公司希望讓開發者可以更簡易的去建置與部署開發的應用程式，該公司的底層技術後來也由 Docker 繼續沿用，當然創辦 Docker 的依然是 Solomon Hykes。
Docker 開源專案誕生之後吸引了全球目光，除了來自各地的使用與開發者外，大型公司如 Microsfot,AWS,IBM 等都也加入，但是就跟其他基於開源專案的軟體公司一樣， Docker 也面臨的商業模式的問題，這種類型的軟體公司到底要如何穩定獲利?
從 2021 往回看，一個很簡短的說法可以說是 Docker 的企業化管理工具 Docker Swarm 還沒有站穩腳步之時就遇到 Kubernetes 這個龐然怪獸，然後 Kubernetes 橫掃時間把所有 Docker Swarm 的市場全面清空，
當然真實版本一定更加複雜得多，絕對不是一句 Kubernetes 就可以概括的

[開源專案的商業化之路總是困難]
Docker 於 2014 年開始認真探討其商業策略，如何將其作為 Container 領頭羊的角色轉變成為一個可以帶來收入的策略，VC 創投的資金讓其有能力收購 Koality 與 Tutum，同年 Docker 也正式宣布第一個商業版本的支援計劃。
這一連串的計算誕生出了許多產品，譬如 Docker Hub 及 Docker Enterprise.
不過可惜的是上述的產品並沒有辦法從企業用戶手中帶來穩定的獲利，大部分的客戶相對於直接購買 Docker 解決方案，更傾向跟已經合作的系統整合商一起合作。

Solomon Hykes 今天夏天跟 infoworld 的一次訪談中提到，Docker 從來沒有推出一套真正的好的商業產品，原因是因為 Docker 並沒有很專注地去處理這塊需求。
Docker 嘗試每個領域都碰一小塊，但是卻發現想要同時維護一個開發者社群又要同時打造一個良好的商業產品是極度困難的， Dockre 花費大量的時間與金錢想要魚與熊掌兼得，但是最後才體會到這件事情幾乎不太可行，Hykes 也認為 Docker 應該要花更多時間去聆聽用戶的需求，而不是自己埋頭苦幹的去打造一個沒有滿足使用者需求的企業產品。

來自 Google 的開發推廣大使 Kelsev Hightower 於今年的訪談中提到，Docker 成功地解決問題，但是卻遇到了瓶頸，舉例來說，Docker 提供工具讓開發者可以 產生 Image, 提供地方儲存 Image，運行 Image 除了這些之外， Docker 還有可以發展的空間嗎?
Hykes 不贊同這個說法，譬如 RedHat 與 Pivotal 都很成功的將 Docker 整合到彼此的 PaaS 產品(OpenShift, Cloud Foundry)，也成功從中獲利，所以 Docker 實際上有很多方式可以去獲利的，只是沒有成功而已。

從結果論來看， Docker 早期的商業夥伴，一家專注於 Travel 的科技公司， Amadeus 於 2015 年正式跟 Docker 分手改而投向 RedHat 的懷抱。
畢竟 RedHat 有提供更多關於 Container 相關的技術支援，畢竟對於一個想要踏入 Container 世界的企業，如何將應用程式容器化是第一步，而接下來則是更為重要的 Container Orchestration 解決方案，很明顯的 Docker 這個戰場上是完全被 Kubernetes 打趴的。

[Kubernetes 的決策]
從結果來看，Docker 拒絕擁抱 Kubernetes 是一個致命的錯誤，Jérôme Petazzoni, Docker 第一位也是目前在位最久的員工分享到， Docker 內部曾經針對 Kubernetes 去探討，認為 Kubernetes 架構過於複雜，而 Docker Swarm 的架構應該使得 Docker Swarm 更為成功。
事實上， Docker 曾經是有機會可以跟 Google 內的 Kubernetes 團隊一起合作發展的，並且有機會去掌握整個 Container 生態系的發展，如果那時候同意這些發展，那 Docker GitHub 底下的第一個專案可能就會是 Kubernetes。

Hykes 承認的說，那個時空背景(2014,2015)下， Docker 公司很難找到一個很好的 Container Orchestration 解決方案來滿足各種各戶的需求，而那時候的 Kubernetes 也很難斬釘截鐵的說就是那個解決方案， 畢竟那時候 Kubernetes 還非常早期，同時期還有很多開源專案，很難料想到
Kubernetes 最後會主宰整個 Container Orchestration 世界。

文章後半段還有非常多的討論，非常推薦大家去看全文，雖然沒有辦法改變歷史，但是從歷史中可以學到非常有趣的東西，特別是當被客戶問到 Docker/Kubernetes 的一些生態問題時，有這些歷史資料的可以讓你講起來更有迷之自信

ref: https://blog.kubecost.com/blog/kubernetes-labels/

本篇文章是一個 Kubernetes Label 介紹文， Kubernetes 的使用者一定都知道 Kubernetes 內的物件很大量依賴 Label 的使用，最基本的用法就是
Deployment 與 Pod 之間是透過 Label 與 LabelSelector 互相溝通的。

Kubernetes 提供兩種不同的方式來為資源打上標記，分別是
1. labels
2. annotations

兩者都是基於 key/value 的方式來設定，不過用途是完全不同。 Label 主要是用來提供辨識的功能，讓使用者可以透過 key/value 的方式來辨識當前的資源，就如同前述提到的 Deployment 與 Pod 的關係。
透過 Label 來標示 Pod，而 Deployment 則透過 LabelSelector 來選擇符合標準的 Pod。

Label 主要有兩大用法
1. Grouping Resource for Queries
2. Bulk Operations.

第一種用法就是前述提到的，將一群資源透過 Label 給標記起來，另外一個則是透過 kubectl 等指令操作時，可以一口氣操作多個資源，譬如
kubectl delete deployment -l environment in (dev,sit)
上述資源可以一口氣將符合 environmnet=dev 以及 environmnet=sit 的 deployment 給一次刪除。

文章中還列舉了其他介紹與學習 Labeling 概念的網站，最後還提到一個使用 Label 上要注意的相關事項
1. 不要將一些會一直改變的資料放到 Label 中
2. 沒有任何理由的話，不要輕易去修改運行資源的 Label 內容
3. Label 本身的設計不是一個 data store，所以不要將一些 Application 的重要資料給存放到 Label 上

對於 Label 這概念想要更深理解的可以參閱全文

ref: https://www.cncf.io/blog/2021/09/01/chaos-mesh-2-0-ga-to-a-chaos-engineering-ecology/

Chaos Mesh 2.0 於 07/23/2021 正式 GA 了，團隊期盼透過這次 2.0 的釋出能夠讓整個 Chaos Engineering 的生態性更加茁壯與蓬勃發展。

Chaos Mesh 一直以來的目標就是讓 Chaos Engineering 能夠更輕易地進入到每個管理者的 Kubernetes 叢集， 2.0 則是這個目標路上的一個重大里程碑，
歷經一年左右的開發與努力， 2.0 主要有三大改進
1. 簡化使用的困難性
Chaos Mesh 透過一套基於 Web 的管理介面 Chaos Dashboard 讓使用者可以輕易地去檢視目前所有的實驗與內容，而 2.0 更是簡化整體操作，
界面更加簡潔同時也可以觀看每個實驗的詳細資訊。
針對不同的雲端業者環境，也支援 AWSChaos/GCPChaos 等不同的環境設定，確保所有的 Kubernetes 測試都能夠更加一致。

2. 強化 Chaos 實驗的自動調度功能
實務上來說，一個單一的實驗沒辦法有效的模擬各種測試環境，因此很多時候都需要人為操作的介入，為了讓這一切更加流暢與自動，Chaos Mesh 過往整合了 Argo Workflow 來協助調度各種實驗。
不過後來團隊發現 Argo Workflow 並不是一個非常適合描述 Chaos 實驗的工具，因此 2.0 版本重新實作了 workflow 的機制，這次的機制是原生支援而不需要仰賴任何第三方解決方案。


3. 支援更多 Injection 的類型
從 2.0 開始， Chaos Mesh 開始支援如 JVMChaos, HTTPChaos 等不同的測試目標。
JVMChaos 用來針對 Java/Kotlin 等使用程式語言撰寫的應用程式，而 HTTPChaos 可以攔截 HTTP 的封包並且竄改內容

此外針對實體機器部分，Chaos Mesh 則是開發了一個名為 Chaosd 的來模擬各種環境問題，譬如砍掉 process, 模擬網路問題，模擬 Disk 問題等

對 Chaos Engineering 有興趣的可以試試看

ref: https://kubernetes.io/blog/2021/09/03/api-server-tracing/
該文章介紹的是 Kubernetes v1.22 所推出的新功能，該功能目前還是屬於 Alpha 階段，這意味要打開該功能則必須要從 Feature flag 下手打開

該功能非常簡單，就是讓 Kubernetes API Server 支援 Tracing 的功能，讓管理者可以透過 Tracing 的工具去檢視 API Server 之間的 Tracing 資料。

分散式系統的環境使得除錯非常困難，每次問題發生時都要針對一個又一個的元件去檢查，找看看每個元件的 log，甚至可能還需要開啟 debug log 的選項才可以
看到更仔細與直接的內容。而 Distributed tracing 就是用來解決這種情境的，而 Kubernetes API Server 又是 Kubernetes 叢集內最重要的核心元件，
因此 Kubernetes 的 SIG Instrumentation 群組目標就是讓各位管理員能夠更輕易地透過 Tracing 去理解當前 API Server 的狀態。

這次的解決方案是基於 OpenTelemetry 的框架去使用的，文章範例中使用 Jaeger 作為 Backend 的 UI 來顯示 API Server 間的 tracing 資料。

從 Observability 的角度來看，能夠透過 Tracing 觀察與監控 Kubernetes 叢集本身的狀況對維運人員來說是一個滿好的工具，不過該功能目前於 v1.22 都還是 Alpha 的版本。
因此對於大部分的使用者來說應該都還是沒有辦法測試該功能，特別是使用 Kubernetes Managed Service 的使用者來說，估計可能還要再等上一段時間才會變得內建支援。

ref: https://medium.com/srivatsan-sridharan/cracking-the-engineering-manager-interview-faqs-94dcfdf38ef

這篇文章是作者分享關於 EM(Engineering Manager) 面試相關的討論文，作者先前已經分享過一系列關於 Engineering Manager 面試的一些經驗
有滿多網友表示之前系列文的分享讓他們有一個方向去準備這類型的面試，而成果也是非常的好。
因此作者寫了最後一篇來分享面試的一些心得與想法

包含下列主題，本文就針對幾個主題進行介紹，對於有興趣的讀者別忘了參閱全文
How important are the technical interviews in the EM interview loop?
Do I need to practice Leetcode to crack the coding rounds?
What if I don’t have relevant experiences to answer situational or experience based questions?
What if I’ve never had to let go of someone from my team?
How much detail should I go into when talking about a situation?
When asked about my weaknesses as a manager, what should I say?
How do I answer the question — what is your management philosophy?
What are some failure modes or traps to watch out for?

How important are the technical interviews in the EM interview loop?
1. 非常重要，雖然大部分情況下 EM 可能沒有太多寫程式的機會，但是沒有技術背景的人是要如何管理一群技術人?
2. 相對於單純寫 Code，技術架構的瞭解更為重要
3. 技術能力與領導經驗哪個更為重要還是要看公司，沒有一定答案，找工作的時後請先好好問一下 recruiter 這些小細節

Do I need to practice Leetcode to crack the coding rounds?
1. 具備 Leetcode medium 等級的能力即可，除非該公司期望 EC 職位的人也必須要從事 IC(Individual Contributor) 或是非常小心創的 Tech Head。不然大部分情況不會遇到太複雜的演算法題目
2. 更多的情況會是詢問如何使用一些基本的資料結構或是解決簡單的演算法問題
3. 主要是判斷你是否有能力將實際的問題轉換為程式碼，是否能夠讀懂,理解與除錯程式碼
4. 忘記 function/語法沒關係，畢竟會面是這個職位的近期程式寫的比較少是可預期的。最重要的還是思路，如何將問題的解法給描述出來

What if I don’t have relevant experiences to answer situational or experience based questions?
1. 這個是非常常見的問題，特別是剛踏入 EM 生涯道路的面試者，本來就很難有太多的範例與經驗去回答這些需要時間累積的問題。
2. 作者推薦誠實的告訴面試官自己這方面經驗不太多，然後可以針對這個範例去探討假如你未來遇到的話，你可能會怎麼面對之類的。

What if I’ve never had to let go of someone from my team?
1. 這是個非常常見的問題，但是就跟前述問題一樣，如果沒有這方面的經驗就誠實以對
2. 可以改從團隊中有人績效不太好為替代方式去探討，講述自己之前的管理哲學與處理方式

ref: https://www.hwchiu.com/ping-implementation.html

本篇文章是難得的自產文章，該文章分享一下自己觀察不同 ping 指令與不同發行版本下的實作方式，主要探討的點是 ICMP 封包是如何產生的。
就我目前認知，目前至少有三種常見方式來設定 ping 指令讓其能夠順利收送 ICMP 封包。
常見的 TCP/UDP 應用程式實際上都是讓 Kernel 幫忙處理底層的 L3/L4 封包，使用者的應用程式則是專注於資料的交換與處理，簡單的說法就是專心處理 L7 資料。
但是 ICMP 封包不同於上述的 TCP/UDP 封包，一種方式就是透過 RAW Socket 的形式自行去拼湊組裝 ICMP 格式，自行處理一切封包的處理。
RAW Socket 本身也不允許每個使用者都能輕易開啟，必須要有相關的權限才可以執行，因此一種 PING 的實作方式就是透過 SetUID 的方式，讓所有能夠執行 ping 指令的使用者會短暫瞬間提權變成 Root 的身份
也因為是 Root 就可以順利的開啟 RAW Socket。
SetUID 強大且方便，簡簡單單就可以讓使用者瞬間變成 Root，但是也因為簡單好像就安全角度來看會覺得不太嚴謹，畢竟我想要的只是一個能夠開啟 RAW Socket 的權限，你去把整個 Root 都送給我。
因此第二種實作方式就是透過 Linux Capability 來達到更細緻化的權限控管，讓任何可以執行 ping 指令的使用者都可以短暫獲得 cap_net_raw 的權限，最終順利的開啟 RAW Socket
而第三種方式則是跳脫的權限的概念，與其透過 RAW Socket 來自行打造 ICMP 封包，不如讓 Linux Kernel 幫忙處理 ICMP 封包，ping 的程式只要跟 Kernel 要求建立一個基於 ICMP 協定的 socket 即可。
透過第三種方式最終可以達到 setuid-less 的架構，ping 的應用程式再也不需要任何的特殊權限，每個使用者都可以順利執行來收送 ICMP 封包。

文章內會針對三種方式進行實驗跟觀察，對 PING 指令有興趣別忘了參考看看

ref: https://www.cncf.io/blog/2021/09/03/kubescape-the-first-open-source-tool-for-running-nsa-and-cisa-kubernetes-hardening-tests/

本篇文章是一個專案介紹文，該專案是個名為 Kubescape 的安全性掃描專案，該專案主要是用來檢驗目標 Kubernetes 是否能夠通過 NSA/CISA 等安全性檢查。

National Security Agency(NSA) 以及 Cybersecurity and Infrastructure Security Agency (CISA) 最近有發佈一個高達 52 頁的安全性指南，
該指南探討如何設立與強化 Kubernetes 叢集的安全性。
https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF

而 Kubescape 專案是一個基於 OPA(OpenPolicyAgent) 引擎的安全性檢查專案，該專案會從 Kubernetes API 取得各類型 Kubernetes 專案的資訊並且針對這些資訊去進行檢查。
檢查是基於上述 NSA/CISA 發布的安全性報告，該檢查的類別包含

1. Non-root containers
2. Immutable container filesystem
3. Building secure container images
4. Privileged containers
5. hostPID, hostIPC privileges
6. hostNetwork access
7. allowedHostPaths field
8. Protecting pod service account tokens
9. Pods in kube-system and kube-public
10. Resource policies
11. Control plane hardening
12. Encrypted secrets
13. Anonymous Requests

有興趣的可以試試看這個專案

ref: https://levelup.gitconnected.com/why-full-time-programmers-are-decreasing-faster-than-ever-ad67d2697bbf

本篇文章是作者的個人發想文，其透過 StackOverflow's 的年度調查觀察到全職工程師的比例正在逐年下降，從 2019 年的 84.20% 到 2021 年的 80.68%。
相反的是今年的統計有高達 11.21％ 的人表達目前自己是 independent contractors/freelancers。

作者認為以下原因導致全職工程師的數量有愈來愈低
軟體工作有逐漸往 印第安/孟加拉/巴基斯坦移動的趨勢
1. Indian Developer 與 US Developer 的薪水差距大概有 5-15 倍
2. 軟體開發是一個可以遠端學習與練習的技能，因此有愈來愈多的公司開出基於短期簽約的工作給印第安/孟加拉等地區的 freelancers。
3. 目前全美大概有 440 萬的工程師，不過估計印度 2023 年就會有高達 520 萬的工程師
4. 印度/南亞會有愈來愈多的簽約工程師

COVID 的全球影響
雖然 COVID 對全球的生態都產生了巨大改變，不過對於工程師來說的影響並沒有其他行業這麼巨大。
根據 Hackreator 的調查，其他行業大概有 20% 的人因為疫情而沒了工作，而工程師大概只有5%不到。
不過要注意的是因為疫情的變化，整個數位產生都有極具的改變，因此也有很多新的職缺因應產業變化而誕生

Freelancers 數量逐漸提高
從 StackOverflow 的調查來看， Freelancers 的數量從 2019 的 9.5% 提升到 2021 的 11.2%。
根據 Upwork's 2017年的調查報告，全美擁有世界最多高達 5800萬的 Freelancers，幾乎佔了全美工作人力的 36%。
Google 本身雇用的 Freelancers 數量甚至也已經超過其全職工作者的數量，大概佔了 54%。

公司想要節省成本。
大部分的公司都不太需要一個長期的全職工作者，很多專案都沒有後期維護與更新的需求，因此相對於雇用長期的全職工作者，雇用短期的 Freelancers 更能夠節省公司
成本。

作者最近才幫某個大公司玩了一個非常非常小的專案，完成該專案後每個月可以獲得 $500 美金的維護費用，作者表示該專案小的幾乎沒有什麼維護需求，就是一個被動收入而已。
文章作者也有分享 LinkedIn 於 2018 分享的文章
該文章中指出
1. 70% 的中小型企業都有與 Freelancers 共事過
2. 參與過的中小型企業中，有 83% 表明這些 Freelancers 的確對公司是有幫助的，而 81% 表明可能會繼續僱用來處理其他專案

預測
作者認為因應遠端工作這一年多的變化，後兩年應該會有愈來愈多的工程師轉為獨立工作者。過往招僱長期全職工作者的一個主要目的就是可以一群人一同於辦公室內激發出高效率的生產模式。
隨者遠端工作逐漸證明 Work From Home 也能夠帶來相對應的高產出，作者認為有不少公司可能會開始考慮雇用 Freelancers 來完成短期專案。

不過作者認為工程師們也不需要太擔心，只要掌握好自己的技能，其實這類型的趨勢不會影響太多。

ref: https://www.hwchiu.com/cncf-tech-radar-multicluster.html

這篇是 CNCF 科技雷達六月份的調查

這次題目為 Multicluster Management，主要想要探討 CNCF 團隊是如何管理多套 Kubernetes 叢集的。

不過 RADAR 團隊將結果分成兩類，分別是 Cluster Deployment 以及 Core Services/Add-ons，前者主要探討如何去管理與部署 Kubernetes Cluster，後者則是探討當前述的 Cluster 搭建完畢後，接下來會部署哪些核心服務來提供更上層的使用者去使用。

結論大概是
1. 多叢集管理目前沒有一個銀色子彈可以一統江山，不同環境與需求都有各自的一片天
2. 社群目前很期待 ClusterAPI 的茁壯發展，希望能夠減少更多客製化的需求與複雜度。
3. 眾多社群工具一起結合來解決問題，特別觀察到 GitOps 最常搭配 Helm 使用，而 Operator 的解決方案也很常透過 GitOps/Helm 的方式給部署到叢集中
4. Operator 真的很棒

詳細內容可以參閱全文

ref: https://vivek-singh.medium.com/system-design-cheat-sheet-318ba2e34723

本篇文章是一個筆記文，紀錄關於 System Design 路上常遇到的架構與元件，譬如
1. LoadBalancer
2. Caches
3. Queues
4. Configuration Service
5. API Gateway
6. Service Mesh
7. CDN
8. Cassandra
9. Snowflake
10. Numbers

每個概念都還會附上一些相關影片與文章，也因為是個筆記內容，因此每個元件的介紹都不會非常詳細，都是小小段落介紹每個元件的最基本概念。
譬如 LoadBalancer 的筆記有
1. L4/L7 兩種的差異
2. AWS 上 ELB/ALB/NLB 的三種差異
3. LB 的演算法， Round Robin,Weighted RR, Least Connection/Response Time/Resource based 等

Caches
1. 實作有 Memcached, Redis 等相關專案
2. 什麼時候會使用 Memcached:
a. 需求簡單，譬如單純 Key/Value 字串，可以輕易地透過調整 cores/threads 來調整效能。
b. Volatile，沒有儲存機制
c. 只有 LRU 的 Cache 演算法
d. Key 最多 250B, Value 最多 1MB
3. 什麼時候使用 Redis
a. 需要儲存 object，而非單純 string
b. 支援多種演算法
c. 支援 data store，可以達到 non-volatile 效果
d. 可以支援 Set/Hash/List/Sorted Set 不同型態

這類型的文章對於踏入 System Design 能夠提供一個簡易的入門介紹，先有哪些類別需要學習，再針對每個類別獨立學習也是一個不錯的學習路徑。

ref: https://faun.pub/kubernetes-is-the-future-of-infrastructure-but-whats-the-future-of-kubernetes-c7446531df51

本篇文章是個 Kubernetes 探討文，作者認為 Kubernetes 的發展已經勢不可擋，想要探討有哪些不同的領域未來能夠跟 Kubernetes 並肩作戰來面對各種不同環境，譬如說
1. Micro VMs
2. Unikernels
3. No/Low-code containerization and orchestration platforms
4. Security improvements on Kubernetes
5. Lightweight Kubernetes distributions
6. Kubernetes for edge and IoT
7. Kubernetes multi-cluster management will be easier using some tools

以下針對這幾個類別簡單摘要

# Micro VMs
作者認為 AWS Firecracker 是目前這個市場上最受歡迎的解決方案，透過以 VM 的形式取代傳統的容器，讓 Kubernetes 的容器能夠有更加安全與隔離的環境，
此外，由 Weaveworks 所推出的 VM 管理專案 Ignite 也是需要注意的，其透過基於 Container 般的管理模式與 GitOps 的更新方式，讓管理者可以更方便地管理這些微 VM
最後提到 slim 這個能夠基於 Dockerfile 產生出 Micro VM 的解決方案，對於這個領域有興趣的都可以參考看看

# Unikernels
不同於 MicroVM 是希望能夠產生一個更精準符合應用的小 VM， Unikernels 更像是 Container 與 VM 的混合體，不同於過往需要與 Host 共享整個 Kernel， Unikernel 會針對每個應用程式準備一個非常小型的 Kernel
該 Kernel 只擁有最基本的運算資源以及運行應用程式所需要的所有依賴函式庫與相關套件。
也因為有這個小 Kernel 的架構，所以 Unikernel 的應用程式跟 Host 可以是完全不同的 OS，畢竟不需要共享 Kernel，此外整體的安全性也會因為非共用 Kernel 而比 Container 更好。

# No/Low-code containerization and orchestration platforms
隨者雲端架構的複雜化，愈來愈多 DevOps/Cloud 工程師探討有沒有辦法讓整個工作流程更加簡單，使用更簡易的方式來設計與管理工作流程。

譬如 ShuttleOps/CloudPlex 等宣稱要達到 no-code 的平台解決方案所述，希望能夠透過拖拉簡易的方式來設計各種 CI/CD 流程。