ref: https://blog.argoproj.io/argo-workflows-2021-survey-results-d6fa890030ee
這篇是由 Argo 官方所發表的統計文章,該文章主要是探討 Argo Workflows 的使用,總共有效的問券有 60 份
你是誰
1. 32% DevOps Engineer
2. 26% Software Engineer
3. 15% Architect
4. 9% Data Engineer
使用案例(前六大項)
1. Infrastructure Automation
2. Data Processing
3. CI/CD
4. Batch Processing
5. Machine Learning
6. ETL
由於問券內容中大部分都是 DevOps 相關職缺,所以答案會偏向 Infrastructure, CI/CD 也是不太意外。
最受歡迎的功能(按照名次排序)
1. Workflow Template
2. CronWorkflows
3. API
4. Prometheus Metrics
5. Workflow Archive
6. Golang/Java/Python Clients
7. SSO
8. WebHooks
9. Workflow Reports
10. Node Offloading
11. Memoization
12. Semaphores/Mutexes
Argo 官方對於這個評比是有點經驗,本以為會更多人使用(6)與(12),不過這些功能實際上的釋出也是相對新。
規模
1. 大部分的使用者一天會運行 10~100 個左右的 workflows
2. 有三個使用者每天會運行 1000 個以上的 workflows
3. 大部分使用者每個 workflow 運行的 pod 數量範圍為 10~100
4. 有兩個使用者每個 workflow 運行的 pod 數量超過 10,000
導入生產環境的困境
1. 有七個人表示習慣使用 Python,所以使用 YAML 語法相對困難
2. 有三個人表示需要去熟悉 Cloud-native/Container 的相關用法與概念
為什麼使用 Argo Workflows
1. 28 個人表示因為其是 Cloud Native/Kubernetes 相關專案
2. 有六個人表示 Argo Workflow 是目前最好用的 workflow 專案
3. 有五個人表示輕量與容易上手
4. 有五個人表示與 Argo CD 可以輕鬆整合無煩惱
對 Argo Workflow 有興趣的人可以參考這個專案,其還可以組合出符合 DGA 拓墣的關係圖,讓你的 job 組合變化多端
ci/cd導入 在 純靠北工程師 Facebook 的精選貼文
#純靠北工程師55w
----------
DevOps最重要的是人,是文化,是組織!
你以為導入了CI/CD就叫做DevOps嗎?
整個公司都勾心鬥角,每個人都想建立自己的流程,好在大老闆面前說嘴。
難道你以為用了AWS DevOps,我們公司所有問題都可以被解決了嗎?
幹,不可能啦,一群白痴,還敢說產業經驗超過20年咧,笑死,我重新組個3-5年經驗的工程師團隊,就能幹翻你們了啦!
----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層!
👉 https://discord.gg/tPhnrs2
----------
💖 全平台留言、文章詳細內容
👉 https://init.engineer/cards/show/6692
ci/cd導入 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
ref: https://itnext.io/helm-3-secrets-management-4f23041f05c3
Secret Management 的議題一直以來都是 CI/CD 流程中不可忽似的一部分,本篇文章作者不同於以往採用常見的解決方案(Hashicorp Vault, Helm Secret, SealedSecret),反而是使用 Helm 內建的 AES 加解密功能來實作 Heml Chart 資料的加解密需求。
作者認為一個良好的機密管理解決方案需要能夠為其團隊提供三個基本需求
1) 所有的機密資訊都要能夠存放到版本控制系統中(Git...etc)
2) 所有被上傳到 Chartmuseum 的 Helm Chart Package 都不能有任何 k8s secret 物件,要放的只能有加密後結果。反之使用者要使用時也必須要有能力去解密
3) 單一工具管理,以作者來說會希望能夠都使用 Helm 這個工具來處理,愈少的工具意味者依賴性愈少,同時在維護與管理上要花的心力也更少。
作者首先列舉了兩個現存的專案,分別是 Helm Secrets 以及 Hashicorp Vault 並且針對這兩者進行了簡單的介紹,並且舉出為什麼這兩個專案並不適合作者團隊的需求與使用情境。
作者最後開始認真研究 Helm 本身有什麼內建的加解密功能可以使用,最後發現 encryptAES 以及 descryptAWS 這兩個內建函式可以使用,譬如
value: encryptAES "secretkey" {{ .Values.valueToEncrypt }}
value: {{ .Values.valueToDecrypt }} | decryptAES "secretkey"
有了基本的概念與用法後,作者透過 shell script 實作一層 wrapper 來簡化整個處理流程。
最後將這些資訊也導入到 CI/CD 流程中來幫忙進行解密的相關動作,讓 CD 可以順利的將目標 Secret 給送到 Kubernetes 中。
個人心得: 採用加解密的系統個人還是喜歡採用 SealedSecret 的設計理念,將解密的時間點延後到 Kubernetes 內而並非 CI/CD 系統上,主要是 CI/CD 的 pipeline 要是沒有仔細設計其實很多人會不小心把過程命令給輸出的,這樣的話加解密的過程,使用的 Key 等都有可能會洩漏出去。
ci/cd導入 在 DevOps 的日常、如何在微服務系統上導入CI/CD - YouTube 的必吃
Tell U MOPCON or More - MOPCON 志工分享(DevOps、CI/CD)時間:9/25(六) 15 ... ... <看更多>
ci/cd導入 在 DevSecOps - CI/CD 如何加入資安? - 白帽觀點 - Facebook 的必吃
資安觀點#CICD #DevSecOps】 CI/CD 如何加入資安你知道怎麼把資安導入CI/CD 中嗎❓ 你知道還有哪些好用工具可以幫助我們呢❓ 之前已經大致介紹了DevSecOps, ... ... <看更多>
ci/cd導入 在 [心得] CI 的使用注意事項- 看板Soft_Job 的必吃
這篇來聊 CI (Continuous integration) 的導入須知,
什麼是 CI ,中文常見是翻"持續整合"。
(也有人是 CI / CD 持續整合/持續交付 並稱,
我以下都只說 CI,但涵蓋是 CI/CD。)
雖然是一個常見而且通用的概念,
我個人覺得因為名字不太好懂,很多人還是一知半解。
DevOps 很大一部分的工作會跟這題有關,
這個詞的發展就我接觸的順序早 DevOps 不少。
這十年來有些詞彙的發展先後不一,
都是根據當時的市場跟分工需求,定義上有些混亂。
--------
CI 最基本的概念,至少包含,
把一個專案從 source code ,到他真的上服務,
這一段 flow 中間的自動化。
換言之, checkout 自動,build 自動,
local(nightly) release 自動,deploy 自動。
很多人對這題可能認知的只有build專案的服務。
雖然最早 CI 其實是搭配 test ,因為持續發布持續測試,
所以在每個版本可以迅速找到"假設"被破壞的地方回饋。
不過國內撰寫測試風氣不發達,
真的做到測試能涵蓋到確保安全的地方,就我所見不多。
但即使如此,build 仍然是過版失誤中,相當常見的主因,
諸如 build 錯版本,丟錯版本,丟錯地方,下錯環境參數等等。
CI 在 build 自動化的優點在於,
只要設定好一個已經變化不大的 build process 。
剩下的要出錯的機率很低,
因為機器基本上都是 step by step process。
一般來說,做好 CI 有幾個好處:
1. build 版不用倚賴特定工程師的腦內思維,把工程師的中斷減少(不會被叫去過版或buil
2. 設定即文件,而且是活的文件
3. 為測試整合打好基礎
4. 減少測試環境的過版負擔
5. 能夠提供水平角色(pm/qa) 自動存取最新 build 的資料,
包括 web / app / 各類執行檔。
有些專案甚至是每天對外發 nightly version ,
就是個典型 CI 流程的特徵。
----------
目前圈內常見的 CI 手段,
最基本的大概是定期跑排程,一些 batchjob 勉勉強強就算數了。
其他常見工具包括 jenkins (前身為 hudson),Travis CI ,
travis CI 的優點是跟 github 無縫整合。
可能還有一些其他的,我自己是比較習慣用 jenkins 。
也不是他特別好還是怎樣,從早期就一直用到現在懶得改,
另外是步驟都可以 shell base ,
換言之你能用指令做到的就能用他做,我是用的很習慣。
另外 azure devop 也有提供 pipeline & release,
可以做對應的事情,不過 azure 封裝的比較多,
用起來我自己是覺得跟 jenkins 風格大異其趣。
--------
導入時的第一個問題,build 的環境處理:
當你裝好 jenkins ,他就是個 web server ,
然後你可以使用該台 server 上的環境進行建置。
也可以建多台 slave ,到別台機器上去建置。
(比方說某些有平台相依的,ex. mac vs windows)
建置時有些工具需要分開安裝,
如 build android 需要 android sdk ,
build .net framework 需要 msbuild。
dotnet core 需要 dotnet core runtime 。
除了像 azure pipeline 有提供線上能 build 的機器(要收錢),
其他大部分都是得自己搞定。
另外要留意一件事情是為了隔離性,
CI 的執行使用者通常不是我們進入操作的高權限帳號,
一開始的各類設定,檔案權限處理,通常會花一點力氣。
---------
第二個常碰到的問題,在於不熟悉指令建置的 input output 。
比方說微軟體系的 msbuild ,多數人可能用過 vs 的發布工具,
但對 msbuild 怎麼用不熟。
其實能用 vs 做到的都能用 msbuild 做到,
但有時需要鑽過茫茫複雜設定海。
另外就是 build 出來的 package 在哪,有時候需要找,
有些專案設定甚至會影響 build 的結果。
要留意跟團隊溝通有變化時要更新對應的 build 設定。
像是 android 有些人會改 gradle 設定檔,加入檔名的變化,
這個設定如果 build 那邊沒考慮到就會事倍功半。
---------
第三個常碰到的問題,在於權限管理的模型設定,
有些地方是採取集中建置的策略,
有些地方是讓工程師各自建置的策略。
其中特別需要的部分,
是把測試環境跟建置環境的權限分開。
另外設定檔的保存,不要讓沒有權限的人,
存取到超過他權限的設定檔也是重要課題之一。
-----------
第四題跟第三題有點重疊,在於各類環境設定的處理。
目前主流有幾派,一個是設定在 os 的環境變數。
(台灣我是非常少看到有專案這樣做)
一個是獨立保管設定檔,
但保管在哪這點目前無標準化,就我看到大家都是各做各的。
如找個 private blob (or s3) 放之類的,
也有人是交給 ansible 之類的發布作業接手。
-----------
常見的問題還包括討厭的跨專案間的相依問題,
比方說某專案需要某建置工具的 A 版本,
另一個專案需要某建置工具的 B 版本。
有時候會需要費心去處理版本的 bin 指定跟環境安裝。
----------
最後因為每次建置,大多數預設的情況,
我們會保留 workspaces 跟 output file 。
所以如果專案 build 出來的東西不幸比較肥,
那可能會常常把伺服器的空間塞爆,
這裡的空間管理就會是問題。
常見做法是直接接到外部的 file service 做保存。
----------
CI 有時候大家會開始設定 trigger ,可能 A 專案建置完之後,要跟著整套建完上測試之類的。
當單一建置時間太常,團隊人又多時,有可能會導致建置服務的塞車。
我們可能也要留意設定上,設定是不是適當的,
舉例,每次都需要 clone 整個專案嗎?
還是只需要取最新版就好。
每次都要重裝相依性套件嗎?(ex. maven , npm , nuget )
能不能 local cache ,或是內部有個 cache service,
有些設定在 build 時,會需要稍微調校來加快效能。
總之,很多人覺得自動化建置,等於再久也沒關係,
實務經驗來說,我覺得還是得追求建置速度,
快速反應,快速前進。
還有一些相對比較不多人關心的問題,
build fail 的處理要怎麼安排,這些就是有空再說了。
我個人會建議,有機會的話,多瞭解一些發布流程如何自動化,
dotnet 工程師看看 msbuild 跟 dotnet(core) .
android 玩一玩 ./gradlew assembleRelease
signapk 怎麼指令化操作
ios 玩一玩 xcode
對自己手邊專案的掌握跟理解都會比較上升。
有時候也可以幫自己省下不少時間,
省下多一點的時間,不管是要混要認真,
還是要在週末上網寫廢文,都會比較有時間。(笑)
-----
Sent from JPTT on my Google Pixel 3 XL.
--
I have a dream, it's silly but beautiful.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.167.67.203 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1598230146.A.8A1.html
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:28:58
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:29:19
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:29:34
是說幾個朋友在FB說, 覺得 CI 跟 build 還是有差,
欸 我覺得原則上同意, 因為 build 只是基礎的一環.
至於有了自動 build 是不是就能達到持續整合的精神,
比方說雖然有 build server 但還是每個月 build 一次.
那樣就不能說有持續整合的精神.
這我同意啦
只是說論述總有遠近, 要講到持續整合這個架構,
能進入的人又少太多了. XDDD
(啊是說你們自己來回啊. = =)
※ 編輯: TonyQ (210.61.209.201 臺灣), 08/24/2020 14:15:18
... <看更多>