DevOps là gì?

DevOps là gì?

DevOps tăng tốc độ phân phối phần mềm chất lượng cao hơn bằng cách kết hợp và tự động hóa công việc của các nhóm vận hành CNTT và phát triển phần mềm.

Theo định nghĩa, DevOps vạch ra một quy trình phát triển phần mềm và sự thay đổi văn hóa tổ chức nhằm tăng tốc độ cung cấp phần mềm chất lượng cao hơn bằng cách tự động hóa và tích hợp nỗ lực của các nhóm vận hành CNTT và phát triển – hai nhóm theo truyền thống thực hành tách biệt với nhau hoặc theo nhóm.

Trên thực tế, các quy trình và văn hóa DevOps tốt nhất sẽ vượt ra ngoài phạm vi phát triển và vận hành để kết hợp đầu vào từ tất cả các bên liên quan đến ứng dụng - bao gồm kỹ thuật nền tảng và cơ sở hạ tầng, bảo mật, tuân thủ, quản trị, quản lý rủi ro, ngành nghề kinh doanh, người dùng cuối và khách hàng - vào vòng đời phát triển phần mềm.

DevOps đại diện cho trạng thái hiện tại của sự phát triển của các chu kỳ phân phối phần mềm trong hơn 20 năm qua, từ các bản phát hành mã khổng lồ trên toàn ứng dụng cứ sau vài tháng hoặc thậm chí vài năm, đến các bản cập nhật chức năng hoặc tính năng nhỏ hơn lặp đi lặp lại được phát hành thường xuyên hàng ngày hoặc vài lần mỗi ngày.

Cuối cùng, DevOps là về việc đáp ứng nhu cầu ngày càng tăng của người dùng phần mềm về các tính năng mới sáng tạo, thường xuyên cũng như hiệu suất và tính khả dụng không bị gián đoạn.

Cách chúng ta đến với DevOps

Cho đến trước năm 2000, hầu hết phần mềm đã được phát triển và cập nhật bằng phương pháp thác nước “Waterfall methodology”, một cách tiếp cận tuyến tính cho các dự án phát triển quy mô lớn. Các nhóm phát triển phần mềm sẽ dành hàng tháng trời để phát triển các phần lớn mã code mới có tác động đến hầu hết hoặc tất cả ứng dụng. Vì những thay đổi quá lớn nên họ đã dành thêm vài tháng để tích hợp mã code mới đó vào cơ sở mã “code base”.

Tiếp theo, các nhóm đảm bảo chất lượng (QA), bảo mật và vận hành sẽ dành thêm nhiều tháng nữa để kiểm tra mã code. Kết quả là hàng tháng hoặc thậm chí hàng năm giữa các lần phát hành phần mềm và thường cũng có một số bản vá hoặc sửa lỗi quan trọng giữa các lần phát hành. Và cách tiếp cận “vụ nổ lớn” này để cung cấp tính năng thường được đặc trưng bởi các kế hoạch triển khai phức tạp và rủi ro, khó lên lịch khóa liên động với các hệ thống ngược dòng và xuôi dòng, và “hy vọng lớn” của CNTT rằng các yêu cầu kinh doanh đã không thay đổi mạnh mẽ trong những tháng trước sản xuất "đi vào hoạt động."

Để tăng tốc độ phát triển và nâng cao chất lượng, các nhóm phát triển bắt đầu áp dụng các phương pháp phát triển phần mềm linh hoạt, lặp đi lặp lại thay vì tuyến tính và tập trung vào việc thực hiện các bản cập nhật nhỏ hơn, thường xuyên hơn cho cơ sở mã ứng dụng. Đứng đầu trong số các phương pháp này là tích hợp liên tục và phân phối liên tục, hoặc CI/CD (Continuous Integration/ Continuous Delivery). Trong CI/CD, các đoạn mã mới nhỏ hơn được hợp nhất vào cơ sở mã sau mỗi một hoặc hai tuần, sau đó được tự động tích hợp, thử nghiệm và chuẩn bị để triển khai vào môi trường sản xuất. Agile đã phát triển cách tiếp cận “vụ nổ lớn” thành một loạt “cú búng tay nhỏ hơn” cũng chia nhỏ rủi ro.

Các phương pháp phát triển linh hoạt này càng tăng tốc quá trình phát triển và phân phối phần mềm càng hiệu quả thì chúng càng bộc lộ các hoạt động CNTT vẫn còn bế tắc - cung cấp hệ thống, cấu hình, kiểm tra chấp nhận, quản lý, giám sát - như nút cổ chai tiếp theo trong vòng đời phân phối phần mềm.

Vì vậy, DevOps đã phát triển nhanh chóng. Nó đã thêm các quy trình và công cụ mới giúp mở rộng quá trình lặp lại liên tục và tự động hóa CI/CD cho phần còn lại của vòng đời phân phối phần mềm. Và nó đã thực hiện sự hợp tác chặt chẽ giữa phát triển và vận hành ở mọi bước trong quy trình.

Cách DevOps hoạt động: Vòng đời DevOps

Vòng đời DevOps (tiếng Anh là DevOps Lifescycle) (đôi khi được gọi là quy trình phân phối liên tục, khi được mô tả theo kiểu tuyến tính) là một chuỗi các quy trình phát triển tự động, lặp đi lặp lại hoặc quy trình công việc, được thực thi trong vòng đời phát triển lặp đi lặp lại, tự động và lớn hơn được thiết kế để tối ưu hóa việc phân phối nhanh chóng các sản phẩm có chất lượng cao. phần mềm chất lượng. Tên và số lượng quy trình công việc có thể khác nhau tùy thuộc vào người bạn hỏi, nhưng chúng thường tổng hợp thành sáu quy trình sau:

• Lập kế hoạch (hoặc ý tưởng). Trong quy trình làm việc này, các nhóm tìm ra các tính năng và chức năng mới trong bản phát hành tiếp theo, rút ra từ phản hồi ưu tiên của người dùng cuối và nghiên cứu điển hình, cũng như đầu vào từ tất cả các bên liên quan nội bộ. Mục tiêu trong giai đoạn lập kế hoạch là tối đa hóa giá trị kinh doanh của sản phẩm bằng cách tạo ra một bản ghi các tính năng tồn đọng mà khi được phân phối sẽ tạo ra kết quả mong muốn có giá trị.
• Phát triển. Đây là bước lập trình, nơi các nhà phát triển kiểm tra, viết mã và xây dựng các tính năng mới và nâng cao, dựa trên câu chuyện của người dùng và các hạng mục công việc trong hồ sơ tồn đọng. Sự kết hợp của các phương pháp như phát triển dựa trên thử nghiệm (TDD - Test-driven development), lập trình cặp “pair programming” và đánh giá mã ngang hàng “peer code reviews”, trong số những phương pháp khác là phổ biến. Các nhà phát triển thường sử dụng các máy trạm cục bộ của họ để thực hiện “vòng lặp bên trong - inner loop” viết và kiểm tra mã trước khi gửi nó xuống đường ống phân phối liên tục.
• Tích hợp (hoặc Dựng bản, hoặc Tích hợp liên tục và phân phối liên tục (CI/CD). Như đã lưu ý ở trên, trong quy trình công việc này, mã code mới được tích hợp vào cơ sở mã Code Base hiện có, sau đó được kiểm tra và đóng gói thành tệp thực thi để triển khai. Các hoạt động tự động hóa thông thường bao gồm hợp nhất mã thay đổi thành bản sao "chính", kiểm tra mã đó từ kho lưu trữ mã nguồn “source code repository” và tự động biên dịch “compile”, kiểm tra đơn vị “unit test” và đóng gói “packaging” thành tệp thực thi. Thực tiễn tốt nhất là lưu trữ đầu ra của giai đoạn CI trong kho lưu trữ nhị phân, cho Giai đoạn tiếp theo.
• Triển khai (thường được gọi là triển khai liên tục). Tại đây, bản dựng đầu ra thời gian chạy “Runtime Build Output” (từ quá trình Tích hợp) được triển khai sang môi trường thời gian chạy “Runtime environment” - thường là môi trường phát triển nơi các thử nghiệm thời gian chạy được thực hiện về chất lượng, tuân thủ và bảo mật. Nếu tìm thấy lỗi hoặc khiếm khuyết, các nhà phát triển có cơ hội chặn và khắc phục mọi sự cố trước khi bất kỳ người dùng cuối nào nhìn thấy chúng. Thông thường có các môi trường để phát triển, thử nghiệm và sản xuất, với mỗi môi trường yêu cầu các cổng chất lượng ngày càng “nghiêm ngặt hơn”. Một phương pháp hay để triển khai vào môi trường sản xuất thường là triển khai trước tiên cho một nhóm nhỏ người dùng cuối, sau đó mới triển khai cho tất cả người dùng sau khi thiết lập được tính ổn định.
• Hoạt động. Nếu việc nhận các tính năng được phân phối cho môi trường sản xuất được mô tả là "Ngày 1", thì khi các tính năng đang chạy trong sản xuất, hoạt động "Ngày 2" sẽ xảy ra. Theo dõi hiệu suất, hành vi và tính khả dụng của tính năng đảm bảo rằng các tính năng có thể cung cấp giá trị gia tăng cho người dùng cuối. Các hoạt động đảm bảo rằng các tính năng đang chạy trơn tru và không có sự gián đoạn trong dịch vụ - bằng cách đảm bảo mạng, lưu trữ, nền tảng, tính toán và trạng thái bảo mật đều ổn định! Nếu xảy ra sự cố, các hoạt động đảm bảo xác định sự cố, nhân viên thích hợp được cảnh báo, xác định vấn đề và áp dụng các bản sửa lỗi.
• Học tập (đôi khi được gọi là phản hồi liên tục). Đây là hoạt động thu thập phản hồi từ người dùng cuối và khách hàng về các tính năng, chức năng, hiệu suất và giá trị kinh doanh để lấy lại kế hoạch cải tiến và bổ sung các tính năng cho bản phát hành tiếp theo. Điều này cũng sẽ bao gồm bất kỳ mục học tập và tồn đọng nào từ các hoạt động vận hành, có thể trao quyền cho các nhà phát triển chủ động tránh mọi sự cố trong quá khứ có thể xảy ra lần nữa trong tương lai. Đây là điểm diễn ra quá trình “ấp ủ” đến giai đoạn Lập kế hoạch và chúng ta “liên tục cải tiến!”

Có ba luồng công việc liên tục quan trọng khác xảy ra giữa các luồng công việc này:

• Thử nghiệm liên tục “Continuous testing”: Vòng đời DevOps cổ điển bao gồm giai đoạn “thử nghiệm” riêng biệt diễn ra giữa quá trình tích hợp và triển khai. Tuy nhiên, DevOps đã nâng cao sao cho một số yếu tố thử nghiệm có thể xảy ra trong quá trình lập kế hoạch (phát triển theo hướng hành vi “behavior-driven development”), phát triển (thử nghiệm đơn vị “unit testing”, thử nghiệm kết hợp “contract testing”), tích hợp (quét mã tĩnh “static code scans”, quét CVE “CVE scans”, linting), triển khai (smoke testing, thử nghiệm thâm nhập “penetration testing”, thử nghiệm cấu hình “configuration testing”), hoạt động (thử nghiệm hỗn loạn “chaos testing”, thử nghiệm tuân thủ “compliance testing”) và học tập (thử nghiệm A/B “A/B Testing”). Thử nghiệm là một hình thức mạnh mẽ để xác định rủi ro và lỗ hổng, đồng thời tạo cơ hội cho CNTT chấp nhận, giảm thiểu hoặc khắc phục rủi ro.
• Bảo mật “Security”: Trong khi các phương pháp thác nước và triển khai linh hoạt 'xử lý' quy trình bảo mật sau khi phân phối hoặc triển khai, DevOps cố gắng kết hợp bảo mật ngay từ đầu (Lập kế hoạch) - khi các vấn đề bảo mật dễ giải quyết trước nhất và ít tốn kém nhất - và liên tục trong suốt phần còn lại của quá trình phát triển xe đạp. Cách tiếp cận bảo mật này được gọi là dịch chuyển sang trái (sẽ dễ hiểu hơn nếu bạn nhìn vào Hình 1). Một số tổ chức ít thành công hơn khi chuyển sang trái so với những tổ chức khác, dẫn đến sự gia tăng của DevSecOps (xem bên dưới).
• Sự tuân thủ “Compliance”. Việc tuân thủ quy định (quản trị và rủi ro) cũng được giải quyết tốt nhất sớm và trong suốt vòng đời phát triển. Các ngành được quản lý thường được yêu cầu cung cấp một mức độ nhất định về khả năng quan sát, truy xuất nguồn gốc và truy cập về cách các tính năng được phân phối và quản lý trong môi trường hoạt động thời gian chạy của chúng. Điều này đòi hỏi phải lập kế hoạch, phát triển, thử nghiệm và thực thi các chính sách trong quy trình phân phối liên tục và trong môi trường thời gian chạy. Khả năng kiểm toán của các biện pháp tuân thủ là vô cùng quan trọng để chứng minh sự tuân thủ đối với kiểm toán viên bên thứ 3.

Văn hóa DevOps

Nhìn chung, người ta chấp nhận rằng các phương pháp DevOps không thể hoạt động nếu không có cam kết đối với văn hóa DevOps, điều này có thể được tóm tắt là một cách tiếp cận kỹ thuật và tổ chức khác để phát triển phần mềm.

Ở cấp độ tổ chức, DevOps yêu cầu liên tục liên lạc, cộng tác và chia sẻ trách nhiệm giữa tất cả các bên liên quan đến phân phối phần mềm - nhóm phát triển phần mềm và vận hành CNTT, cũng như các nhóm bảo mật, tuân thủ, quản trị, rủi ro và ngành nghề - để đổi mới nhanh chóng và liên tục và xây dựng chất lượng cho phần mềm ngay từ đầu.

Trong hầu hết các trường hợp, cách tốt nhất để thực hiện điều này là chia nhỏ các silo này và tổ chức lại chúng thành các nhóm DevOps tự trị, đa chức năng có thể làm việc trên các dự án mã từ đầu đến cuối - lập kế hoạch cho đến phản hồi - mà không cần chuyển giao hoặc chờ phê duyệt từ, các đội khác. Khi đặt trong bối cảnh phát triển linh hoạt, trách nhiệm giải trình và sự cộng tác được chia sẻ là nền tảng của việc tập trung vào sản phẩm được chia sẻ có kết quả có giá trị.

Ở cấp độ kỹ thuật, DevOps yêu cầu cam kết tự động hóa để giữ cho các dự án di chuyển trong và giữa các quy trình công việc, đồng thời phản hồi và đo lường cho phép các nhóm liên tục tăng tốc chu kỳ cũng như cải thiện hiệu suất và chất lượng phần mềm.

DevOps tools: Xây dựng chuỗi công cụ DevOps

Yêu cầu của DevOps và văn hóa DevOps đặt ưu tiên cao cho công cụ hỗ trợ cộng tác không đồng bộ, tích hợp liền mạch quy trình công việc DevOps và tự động hóa toàn bộ vòng đời DevOps nhiều nhất có thể. Danh mục công cụ DevOps bao gồm:

• Công cụ quản lý dự án - công cụ cho phép các nhóm xây dựng hồ sơ tồn đọng của các câu chuyện của người dùng (yêu cầu) hình thành các dự án mã hóa, chia chúng thành các nhiệm vụ nhỏ hơn và theo dõi các nhiệm vụ cho đến khi hoàn thành. Nhiều hỗ trợ thực hành quản lý dự án linh hoạt, chẳng hạn như Scrum, Lean và Kanban, mà các nhà phát triển mang đến cho DevOps. Các tùy chọn mã nguồn mở phổ biến bao gồm GitHub Issues và Jira.
• Kho lưu trữ mã nguồn cộng tác - môi trường mã hóa được kiểm soát theo phiên bản cho phép nhiều nhà phát triển làm việc trên cùng một cơ sở mã. Các kho lưu trữ mã nên tích hợp với CI/CD, các công cụ kiểm tra và bảo mật để khi mã được cam kết với kho lưu trữ, nó có thể tự động chuyển sang bước tiếp theo. Các kho mã nguồn mở bao gồm GiHub và GitLab.
• Quy trình CI/CD - công cụ tự động kiểm tra mã, xây dựng, thử nghiệm và triển khai. Jenkins là công cụ nguồn mở phổ biến nhất trong danh mục này; nhiều lựa chọn thay thế nguồn mở trước đây, chẳng hạn như CircleCI, hiện chỉ có sẵn ở phiên bản thương mại. Khi nói đến các công cụ triển khai liên tục (CD), Spinnaker đứng giữa ứng dụng và cơ sở hạ tầng dưới dạng các lớp mã. ArgoCD là một lựa chọn nguồn mở phổ biến khác cho Kubernetes native CI/CD.
• Các framework tự động hóa thử nghiệm - bao gồm các công cụ phần mềm, thư viện và các phương pháp hay nhất để tự động hóa các thử nghiệm đơn vị, kết hợp, chức năng, hiệu suất, khả năng sử dụng, thâm nhập và bảo mật. Công cụ tốt nhất trong số này hỗ trợ nhiều ngôn ngữ; một số sử dụng trí tuệ nhân tạo (AI) để tự động cấu hình lại các bài kiểm tra để đáp ứng với các thay đổi mã. Sự mở rộng của các công cụ và khuôn khổ thử nghiệm là rất xa và rộng! Các khung kiểm thử tự động mã nguồn mở phổ biến bao gồm Selenium, Appium, Katalon, Robot Framework và Serenity (trước đây gọi là Thucydides).
• Các công cụ quản lý cấu hình (cơ sở hạ tầng dưới dạng mã) - những công cụ này cho phép các kỹ sư DevOps định cấu hình và cung cấp cơ sở hạ tầng được ghi lại đầy đủ và được lập phiên bản đầy đủ bằng cách thực thi một tập lệnh. Các tùy chọn nguồn mở bao gồm Ansible (Red Hat), Chef, Puppet và Terraform. Kubernetes thực hiện chức năng tương tự đối với các ứng dụng được chứa trong bộ chứa containers (xem 'DevOps và phát triển dựa trên nền tảng đám mây' bên dưới).
• Các công cụ giám sát - những công cụ này giúp các nhóm DevOps xác định và giải quyết các sự cố hệ thống; họ cũng thu thập và phân tích dữ liệu trong thời gian thực để tiết lộ những thay đổi về mã tác động đến hiệu suất của ứng dụng như thế nào. Các công cụ giám sát nguồn mở bao gồm Datadog, Nagios, Prometheus và Splunk.
• Công cụ phản hồi liên tục - công cụ thu thập phản hồi từ người dùng, thông qua bản đồ nhiệt (ghi lại hành động của người dùng trên màn hình), khảo sát hoặc phiếu vấn đề tự phục vụ.

DevOps và phát triển dựa trên đám mây

Đám mây gốc “Cloud-native” là một cách tiếp cận để xây dựng các ứng dụng tận dụng các công nghệ điện toán đám mây nền tảng. Mục tiêu của Đám mây gốc “Cloud-native”  là cho phép phát triển, triển khai, quản lý và hiệu suất ứng dụng nhất quán và tối ưu trên các môi trường công cộng, riêng tư và nhiều đám mây.

Ngày nay, các ứng dụng gốc trên đám mây “Cloud-native applications” thường: 

• Được xây dựng bằng các vi dịch vụ “microservices” - các thành phần có thể triển khai độc lập, được kết hợp lỏng lẻo, có ngăn xếp độc lập của riêng chúng và giao tiếp với nhau thông qua API REST, truyền phát sự kiện hoặc trình trung gian thông báo.
• Được triển khai trong bộ chứa “containers” - đơn vị mã thực thi có chứa tất cả mã, thời gian chạy và phần phụ thuộc của hệ điều hành cần thiết để chạy ứng dụng. (Đối với hầu hết các tổ chức, 'bộ chứa' đồng nghĩa với bộ chứa Docker container, nhưng vẫn tồn tại các loại bộ chứa khác.)
• Được vận hành (ở quy mô lớn) bằng cách sử dụng Kubernetes, một nền tảng điều phối bộ chứa container mã nguồn mở để lập lịch trình và tự động hóa việc triển khai, quản lý và mở rộng quy mô các ứng dụng được chứa trong vùng chứa.

Theo nhiều cách, sự phát triển dựa trên đám mây và DevOps được tạo ra cho nhau.

Ví dụ: việc phát triển và cập nhật vi dịch vụ microservices - nghĩa là phân phối lặp đi lặp lại các đơn vị mã nhỏ đến một cơ sở mã nhỏ - là sự phù hợp hoàn hảo cho các chu kỳ quản lý và phát hành nhanh của DevOps. Và sẽ rất khó để xử lý sự phức tạp của kiến trúc microservices nếu không triển khai và vận hành DevOps. Một cuộc khảo sát gần đây của IBM đối với các nhà phát triển và giám đốc điều hành CNTT cho thấy 78% người dùng vi dịch vụ microservices hiện tại mong muốn tăng thời gian, tiền bạc và công sức họ đã đầu tư vào kiến trúc và 56% người không sử dụng có khả năng sẽ áp dụng vi dịch vụ microservices trong vòng hai năm tới. 

Bằng cách đóng gói và khắc phục vĩnh viễn tất cả các phần phụ thuộc của hệ điều hành, bộ chứa container cho phép CI/CD và các chu kỳ triển khai nhanh chóng, bởi vì tất cả quá trình tích hợp, thử nghiệm và triển khai đều diễn ra trong cùng một môi trường. Và điều phối Kubernetes thực hiện các tác vụ cấu hình liên tục giống nhau cho các ứng dụng được chứa trong bộ chứa như Ansible, Puppet và Chef thực hiện cho các ứng dụng không được chứa.

Hầu hết các nhà cung cấp điện toán đám mây hàng đầu - bao gồm AWS, Google, Microsoft Azure và IBM Cloud - đều cung cấp một số loại giải pháp đường ống DevOps được quản lý.

DevSecOps là gì?

DevSecOps là DevOps liên tục tích hợp và tự động hóa bảo mật trong suốt vòng đời DevOps - từ đầu đến cuối, từ lập kế hoạch thông qua phản hồi và quay lại lập kế hoạch.

Một cách khác để diễn đạt điều này là DevSecOps là thứ mà DevOps được cho là ngay từ đầu. Nhưng hai trong số những thách thức quan trọng ban đầu (và không thể vượt qua trong một thời gian) đối với việc áp dụng DevOps là tích hợp chuyên môn bảo mật vào các nhóm đa chức năng (một vấn đề văn hóa) và triển khai tự động hóa bảo mật vào vòng đời DevOps (một vấn đề kỹ thuật). Bảo mật được coi là "Team of ‘No'" và là nút cổ chai đắt giá trong nhiều hoạt động DevOps.

DevSecOps nổi lên như một nỗ lực cụ thể để tích hợp và tự động hóa bảo mật như dự định ban đầu. Trong DevSecOps, bảo mật là công dân và bên liên quan “hạng nhất” cùng với quá trình phát triển và Hoạt động, đồng thời đưa bảo mật vào quy trình phát triển với trọng tâm là sản phẩm.

DevOps và Kỹ thuật độ tin cậy trực tiếp SRE

Kỹ thuật độ tin cậy trực tiếp (SRE - Site Reliability Engineering) sử dụng các kỹ thuật kỹ thuật phần mềm để tự động hóa các tác vụ vận hành CNTT - ví dụ: quản lý hệ thống sản xuất, quản lý thay đổi, ứng phó sự cố, thậm chí ứng phó khẩn cấp - có thể được quản trị viên hệ thống thực hiện thủ công. SRE tìm cách biến quản trị viên hệ thống cổ điển thành một kỹ sư.

Mục tiêu cuối cùng của SRE tương tự như mục tiêu của DevOps, nhưng cụ thể hơn: SRE nhằm mục đích cân bằng mong muốn của tổ chức về phát triển ứng dụng nhanh chóng với nhu cầu đáp ứng các mức hiệu suất và tính khả dụng được chỉ định trong thỏa thuận cấp độ dịch vụ (SLA) với khách hàng và nhà cung cấp dịch vụ cuối cùng. người dùng.

Các kỹ sư về độ tin cậy của trang web đạt được sự cân bằng này bằng cách xác định mức rủi ro hoạt động có thể chấp nhận được do các ứng dụng gây ra - được gọi là 'ngân sách lỗi' - và bằng cách tự động hóa các hoạt động để đáp ứng mức đó.

Trong nhóm DevOps đa chức năng, SRE có thể đóng vai trò là cầu nối giữa phát triển và vận hành, cung cấp các số liệu và tự động hóa mà nhóm cần để thúc đẩy các thay đổi mã và tính năng mới thông qua hệ thống DevOps nhanh nhất có thể mà không 'vi phạm' các điều khoản của các SLA của tổ chức.

Tìm hiểu thêm về kỹ thuật độ tin cậy của trang

Các giải pháp liên quan

Tham khảo thêm

Nguồn: https://www.ibm.com/topics/containers?lnk=fle