อยากจะพัฒนา Application ให้รองรับความยืดหยุ่นตาม Workload ของงาน และยังรองรับการใช้ทรัพยากรร่วมกันอีกด้วย ต้องทำอย่างไรดี ? 🤔
.
ในวันนี้แอดมินจะพาทุกคนมาทำความรู้จักกับ การพัฒนา Application ด้วยรูปแบบ Cloud Native จะเป็นอย่างไรนั้น ไปดูกันนน !!
.
อ้างอิงจาก Cloud Native Computing Foundation (CNCF) ได้เขียนไว้ว่า Cloud Native นั้นจะมีแนวคิดและเทคโนโลยี ที่จะช่วยให้เราสามารถสร้างและรันระบบโดยที่ Scale ได้ง่ายขึ้นและอีกทั้งรองรับ Environment ต่าง ๆ ได้ง่ายขึ้น ไม่ว่าจะเป็น Public, Private, Hybrid Cloud หรืออาจจะเป็น On-premise ก็ได้
.
ซึ่งแนวคิดนี้ทำให้
🔸 ระบบเป็นอิสระจากกัน (Loosely Coupled)
🔸 จัดการได้ง่าย (Manageble)
🔸 ดูการทำงานได้ (Observable)
🔸 Recovery จากความผิดพลาดต่าง ๆ ได้ (Resilient)
.
✨ Cloud Native คือ รูปแบบของการพัฒนา Application ให้รองรับการประมวลผลแบบ Cloud Computing เพื่อให้ Application นั้นมีความยืดหยุ่นตาม Workload ของงาน และยังรองรับการใช้ทรัพยากรร่วมกันอีกด้วย
.
คุณสมบัติหลักที่จำเป็นต้องมีของ Cloud Native มีอยู่ 3 อย่างด้วยกัน คือ
.
1. Application ต้องถูกออกแบบด้วยแนวคิดของ Microservice - เป็นแนวคิดในการแยกระบบงาน ออกมาเป็น Service ย่อย ๆ ลงมา ที่เป็นอิสระต่อกันให้ได้มากที่สุด แล้วค่อยแบ่งหน้าที่ให้แต่ละฝ่ายดูแลในแต่ละส่วน ทำให้สามารถพัฒนา Application แบบ Parallel เพื่อเพิ่มความเร็วในการพัฒนานั่นเอง
.
2. Application ต้องทำงานภายใต้เทคโนโลยี Container - เป็นการจำลองสภาพแวดล้อมการทำงานของ Application ที่ใช้ทรัพยากรน้อยกว่าการทำงานบน Virtual Machine เสียอีก มีการรองรับการใช้งานร่วมกับ Services อื่น ๆ อีกมากมาย
.
3. Application ต้องถูกพัฒนาด้วยแนวคิดแบบ DevOps - เป็นแนวคิดที่ครอบคลุมส่วนการทำงานหลัก ๆ ด้วยกัน เช่น การทำงานเป็นทีม (Culture), เครื่องมือที่ใช้ทำงาน (Technology), กระบวนการทำงาน (Process)
.
ซึ่งระบบของ Cloud Native นั้นจำเป็นต้องมีคุณสมบัติเหล่านี้ และประโยชน์ของ Cloud Native นั้นมี่อยู่หลายอย่างด้วยกันเช่น
.
🔹 ตัว Application นั้นใช้ทรัพยากรน้อยลงกว่าเดิม (เนื่องจากใช้ตัว Container)
🔹 ทำให้การพัฒนา Application นั้นทำได้รวดเร็วขึ้น
🔹 ลดความเสี่ยงที่จะทำให้ระบบล่มจากสาเหตุที่คาดเดาไม่ได้ (Resiliency)
🔹 รองรับความยืดหยุ่นในการจัดการ Workload (On Demand Workload)
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
#cloudnative #BorntoDev
「devops container」的推薦目錄:
- 關於devops container 在 BorntoDev Facebook 的最佳貼文
- 關於devops container 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
- 關於devops container 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於devops container 在 【DevOps 恩物】Container 好壞參半一個平台提升69% 效能 的評價
- 關於devops container 在 azure-devops-docs/container-phases.md at main - GitHub 的評價
- 關於devops container 在 Azure DevOps container jobs: Publish step (sometimes) run in ... 的評價
- 關於devops container 在 Continuous Delivery with Windows Containers and Azure ... 的評價
devops container 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
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 如何設定。
如果團隊有這個需求的可以看一下要如何操作。
文章最後探討使用這三個專案的一些經驗與痛點,有興趣的可以閱讀全文參考
devops container 在 矽谷牛的耕田筆記 Facebook 的精選貼文
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 組合變化多端
devops container 在 azure-devops-docs/container-phases.md at main - GitHub 的推薦與評價
You can't have nested containers. Containers aren't supported when an agent is already running inside a container. ::: moniker range="> azure-devops-2019" If ... ... <看更多>
devops container 在 Azure DevOps container jobs: Publish step (sometimes) run in ... 的推薦與評價
... <看更多>
devops container 在 【DevOps 恩物】Container 好壞參半一個平台提升69% 效能 的推薦與評價
VMware Tanzu® 為企業提供Consistent 及Scalable 的Operations,透過Mission Control™ 同時管理On Premises 及Multi-Cloud 的Kubernetes 平台。 ... <看更多>