Container hóa trong DevOps là gì?

Hình ảnh: Shutterstock

Phần mềm là tổng hợp các bộ phận của nó, và container hóa là quá trình đưa các phần quan trọng nhất của ứng dụng lại với nhau thành một gói gọn gàng. Bằng cách container hóa, các nhà phát triển sẽ đóng gói mã chương trình, công cụ chạy, công cụ, thư viện và cài đặt vào một "container" di động. Theo cách đó, phần mềm cần ít tài nguyên hơn để chạy và dễ triển khai hơn nhiều trong các môi trường mới. 

Tim Hynes, một kỹ sư phần mềm tại công ty quản lý dữ liệu đám mây Rubrik , đã định nghĩa container hóa theo cách này khi nói chuyện với Built In vào năm 2020: “Container là một cách đóng gói ứng dụng để dễ dàng tải ứng dụng và chạy ứng dụng trong bất kỳ môi trường nào. Vì vậy, rất nhiều sự phức tạp trong việc cài đặt và cấu hình ứng dụng đã được loại bỏ. Container cho phép nhà phát triển trừu tượng hóa tất cả những điều đó và tạo ra một gói rất đơn giản, dễ sử dụng.”

Container hóa trong DevOps là gì?

Lần đầu tiên xuất hiện dưới dạng “cgroups” trong Linux Kernel vào năm 2008, container đã trở nên phổ biến hơn bao giờ hết khi Docker Engine ra mắt vào năm 2013. Do đó, “containerizing” và “Dockerizing” thường được sử dụng thay thế cho nhau.

Trên bề mặt, việc đóng gói phần mềm là một quá trình tương đối đơn giản: một "tệp chứa" có thông tin của phần mềm được chuyển đổi thành một hình ảnh chứa nhẹ, trở thành một container thực sự khi chạy thông qua một công cụ chạy. Bất kỳ hình ảnh hoặc công cụ nào do Sáng kiến ​​​​đóng gói mở quản lý sẽ hoạt động với bất kỳ hình ảnh hoặc công cụ nào khác được xây dựng bằng cùng một tiêu chuẩn.

Nhưng tại sao lại có container và chúng có tác dụng gì?

Một cách để xem container là xem nó như một bước nữa trong hành trình công nghệ đám mây .

Trước khi công nghệ ảo hóa và đám mây ra đời, phần mềm thường chạy trên các máy vật lý riêng lẻ. Mỗi máy có hệ điều hành riêng, thường dẫn đến chương trình bị hỏng và thời gian chết khi các nhà phát triển cố gắng triển khai phần mềm được viết trên hệ thống Windows trên máy chạy hệ thống Linux, ví dụ. Việc cố gắng xây dựng môi trường thử nghiệm mô phỏng hoàn hảo môi trường sản xuất rất tốn thời gian, vì vậy các nhà phát triển cần một cách tốt hơn.

Máy ảo hoặc môi trường điện toán ảo chạy trên phần cứng vật lý với sự trợ giúp của một phần mềm gọi là hypervisor , cung cấp cách tốt hơn. Phần mềm chạy trên máy ảo được đóng gói với hệ điều hành khách riêng, giúp giảm khả năng bị hỏng do không tương thích với hệ điều hành máy chủ.

Sau đó, mọi người tìm ra cách kết hợp và chia sẻ tài nguyên giữa các máy ảo và đám mây ra đời.

Nhưng máy ảo vẫn còn một số vấn đề: Chạy tất cả các hệ điều hành khách đó chiếm rất nhiều tài nguyên máy tính. Đó là lúc container phát huy tác dụng.

Container không đi kèm với hệ điều hành khách của riêng chúng. Thay vào đó, chúng sử dụng phần mềm được gọi là công cụ thời gian chạy để chia sẻ hệ điều hành máy chủ của bất kỳ máy nào chúng đang chạy. Điều đó giúp tăng hiệu quả của máy chủ và thời gian khởi động nhanh hơn — hầu hết các hình ảnh container có kích thước hàng chục MB , trong khi VM thường cần từ bốn đến tám GB để chạy tốt.

Tính di động vô song đó đã biến container thành vũ khí bí mật của các công ty công nghệ đám mây và ngày càng trở thành vũ khí của các đối tác lớn hơn của họ .

Các ứng dụng được chứa trong container dẫn đến sự bùng nổ của các dịch vụ vi mô và Kubernetes

Trước khi có container, các nhà phát triển phần lớn xây dựng phần mềm độc lập với các thành phần đan xen. Nói cách khác, các tính năng và chức năng của chương trình chia sẻ một giao diện người dùng lớn , mã back-end và cơ sở dữ liệu.

Container giúp việc xây dựng phần mềm với kiến ​​trúc hướng dịch vụ, như microservices , dễ dàng hơn nhiều . Mỗi phần logic kinh doanh — hoặc dịch vụ — có thể được đóng gói và bảo trì riêng biệt, cùng với giao diện và cơ sở dữ liệu của nó. Các microservices khác nhau giao tiếp với nhau thông qua một giao diện được chia sẻ như API hoặc giao diện REST.

Với microservices, các nhà phát triển có thể điều chỉnh một thành phần mà không lo làm hỏng các thành phần khác, giúp dễ sửa lỗi hơn và phản hồi nhanh hơn với các điều kiện thị trường. Microservices cũng cải thiện bảo mật, vì mã bị xâm phạm trong một thành phần ít có khả năng mở cửa hậu cho các thành phần khác.

Container và microservice là hai trong số những thuật ngữ công nghệ quan trọng nhất của cloud-native . Thuật ngữ thứ ba là orchestration hoặc cụ thể hơn là Kubernetes : một nền tảng orchestration giúp các tổ chức tận dụng tối đa container của họ.

Container không phụ thuộc vào cơ sở hạ tầng — các phụ thuộc của chúng đã được tách biệt khỏi cơ sở hạ tầng của chúng. Điều đó có nghĩa là chúng có thể chạy trong các môi trường khác nhau mà không bị hỏng. Các tổ chức gốc đám mây bắt đầu tận dụng tính di động đó, chuyển các container giữa các môi trường điện toán khác nhau để mở rộng hiệu quả, tối ưu hóa tài nguyên điện toán và phản hồi với những thay đổi về lưu lượng truy cập.

Thông qua giao diện người dùng, Kubernetes cung cấp khả năng hiển thị chưa từng có vào hệ sinh thái container. Nó cũng hoàn toàn là mã nguồn mở, giúp các tổ chức áp dụng container mà không bị khóa chặt với các nhà cung cấp độc quyền. Cuối cùng, nó hỗ trợ quá trình chuyển đổi rộng rãi sang DevOps , giúp tăng cường sự nhanh nhẹn bằng cách kết hợp phát triển và bảo trì hệ thống phần mềm.

Hynes chia sẻ với Built In rằng: “Với cách mọi thứ đang diễn ra và cách hỗ trợ ứng dụng hoạt động hiện nay, tôi nghĩ ngày càng có nhiều kỹ sư được kỳ vọng sẽ chịu trách nhiệm cho mã của họ chạy hàng ngày”.

Container đã trả lời câu hỏi: "Làm thế nào để chúng ta có thể đóng gói phần mềm với mọi thứ cần thiết để triển khai liền mạch?" Kubernetes — cũng như các hệ thống điều phối khác như Helm — đã trả lời một câu hỏi khác: "Làm thế nào để chúng ta có thể hiểu đơn giản các yêu cầu, khả năng kết nối và bảo mật của phần mềm để nó có thể tương tác liền mạch với các dịch vụ của bên thứ ba?"

Hynes nói thêm : "Các công nghệ dạng lưới dịch vụ xuất hiện xung quanh các container thực sự giúp đóng gói các yêu cầu khác mà ứng dụng có, không chỉ giới hạn ở những thứ như thư viện mã".

Container hóa trong điện toán đám mây

Hynes cho biết trong khoảng 15 năm trở lại đây, phát triển phần mềm đã tập trung chủ yếu vào việc cải thiện tính ổn định hoặc tránh mã bị hỏng và thời gian chết. Phát triển theo hướng thử nghiệm và các nguyên tắc nhanh nhẹn khác, như YAGNI , đã giúp phần mềm trở nên đơn giản, dễ thích ứng và ổn định. Nhưng tính ổn định đó phải trả giá.

Hynes cho biết: “Một điều bị mất đi khi tạo ra sự ổn định đó là khả năng mở rộng quy mô nhanh chóng và thay đổi các bộ phận của ứng dụng, xoay chuyển những gì công ty làm và giải quyết các xu hướng thị trường”.

Khả năng mở rộng nhanh và xoay trục nhanh là những gì mà cái gọi là công nghệ đám mây gốc được biết đến. Thông thường, container là yếu tố nền tảng của những gì chúng ta muốn nói khi chúng ta nói "đám mây gốc".

Hynes cho biết: “Tôi nghĩ rằng [Container và đám mây gốc] chắc chắn là đồng nghĩa trong tâm trí mọi người”.

Nhưng nhiều ứng dụng được xây dựng để chạy trong môi trường đám mây không sử dụng container, ông nói thêm. Một đám mây công cộng có thể lưu trữ một ứng dụng đơn khối dễ dàng như một tập hợp các dịch vụ vi mô. Hơn nữa, container có thể chạy trong hầu hết mọi môi trường điện toán. Cho dù các nhà phát triển muốn chạy phần mềm được chứa trong container thông qua máy vật lý tại chỗ, máy ảo riêng hay đám mây công cộng phụ thuộc vào nhu cầu bảo mật, khả năng mở rộng và quản lý cơ sở hạ tầng của họ.

Ưu điểm và nhược điểm của việc đóng container

Trong một cuộc khảo sát năm 2021 của Cloud Native Computing Foundation, 93 phần trăm số người được hỏi cho biết họ đã sử dụng hoặc có kế hoạch sử dụng container trong sản xuất.

Nhưng nếu container mang lại nhiều lợi thế về khả năng di động, khả năng mở rộng và khả năng phản hồi, tại sao không phải mọi tổ chức đều sử dụng container cho phần mềm của mình?

Một lý do là tốc độ tiến bộ công nghệ. Container chưa phổ biến trong thời gian dài như vậy. Trong một khoảng thời gian tương đối ngắn, các nhà lãnh đạo trong nhiều ngành công nghiệp cũng phải tập trung vào các dịch vụ đám mây công cộng, DevOps , điện toán biên , trí tuệ nhân tạo và các cải tiến khác. Đôi khi, rất khó để theo kịp.

Hynes nhận thấy động lực này khi anh giúp khách hàng của Rubrik điều hướng quá trình chuyển đổi sang đám mây và DevOps.

"Khách hàng khá khó theo dõi những gì đang diễn ra, tình hình hiện tại và so sánh với một năm trước chẳng hạn", ông nói. "Đây chắc chắn là một thách thức đối với khách hàng, đặc biệt là khi họ không tham gia vào lĩnh vực phát triển ứng dụng ".

Một lý do khác khiến các công ty tránh sử dụng container là việc sử dụng phần mềm cũ không dễ dàng như việc bật công tắc .

Hynes cho biết các tổ chức lớn thường dựa vào các hệ thống phần mềm thúc đẩy doanh thu đã 10, 15 hoặc 20 năm tuổi. Các cơ sở dữ liệu phụ trợ khổng lồ của họ có thể đang chạy trên các công cụ cơ sở dữ liệu đã tồn tại trong nhiều thập kỷ và các giao diện người dùng thường không được động đến trong nhiều năm.

“Họ chỉ duy trì nó trong nhiều năm, thay vì đầu tư mạnh vào nó, bởi vì họ thực sự không muốn phá vỡ nó,” ông giải thích.

Đối với những công ty như vậy, việc chuyển đổi sang container mang lại rủi ro lớn mà không có lợi ích rõ ràng. Các hệ thống cũ ổn định và mọi người đều biết cách sử dụng chúng. Tại sao lại làm hỏng một điều tốt?, suy nghĩ đó diễn ra.

Và suy nghĩ đó thường đúng. Ngay cả khi quá trình chuyển đổi diễn ra suôn sẻ, một vài giờ ngừng hoạt động đối với một hệ thống quan trọng của một công ty lớn có thể tốn hàng triệu đô la. Và các công ty lâu đời có thể không có nhân viên có kỹ năng quản lý môi trường container quét.

Thay vào đó, Hynes cho biết các công ty trong tình huống đó nên chuyển sang cái mà Gartner gọi là CNTT hai phương thức , trong đó một số nhóm duy trì các ứng dụng ổn định, dài hạn chịu trách nhiệm cho phần lớn doanh thu và các nhóm khác tập trung vào phát triển sản phẩm sáng tạo, gốc đám mây.

Containerization 201: Những quan niệm sai lầm phổ biến về ứng dụng containerized

Số lượng nhà phát triển có container trong sản xuất đã tăng vọt trong những năm gần đây . Ở một số khu vực, mức độ phổ biến của container đã vượt xa giáo dục và đào tạo xung quanh chúng. Sau đây là một số huyền thoại phổ biến về container cần được phá bỏ:

CONTAINER ĐỂ XÂY DỰNG CÁC ỨNG DỤNG MỚI

Brian Gracely, giám đốc chiến lược sản phẩm cấp cao của Red Hat, đã chia sẻ với Built In vào năm 2020 rằng chỉ vì một ứng dụng đã tồn tại không có nghĩa là nó không thể hoặc không nên được chứa trong container . Những lời bàn tán ban đầu về container khiến nhiều người tin rằng công nghệ này chỉ dành cho các nhà phát triển xây dựng ứng dụng đám mây gốc từ đầu. Nhưng điều đó hoàn toàn không đúng.

Gracely cho biết: “Trong vài năm qua, chúng tôi đã xây dựng nhiều khả năng cho phép bạn sử dụng một ứng dụng hiện có và sử dụng container để thực sự có được nhiều lợi ích bổ sung từ ứng dụng đó”. “Chúng tôi thấy mọi người sử dụng container như một phần của chiến lược hiện đại hóa thực sự rộng lớn. Trong một số trường hợp, đó là để giúp các hệ thống đã 10 hoặc 20 năm tuổi”.

“Chúng tôi thấy mọi người sử dụng container như một phần của chiến lược hiện đại hóa thực sự rộng lớn. Trong một số trường hợp, nó giúp ích cho các hệ thống đã 10 hoặc 20 năm tuổi.”

Nhưng hiện đại hóa cần có công sức — và không ai thích khi các hệ thống hoạt động hoàn hảo bắt đầu có cảm giác như nợ kỹ thuật, Gracely nói thêm. Điều đó nói rằng, các ứng dụng tồn tại trong nhiều năm thường tồn tại vì chúng quan trọng — và để chúng trì trệ không có lợi cho bất kỳ ai. Ông cho biết, chìa khóa cho các công ty như Red Hat là giúp khách hàng phân biệt giữa công nghệ mới thực sự hữu ích và công nghệ mới vì lợi ích của công nghệ. Các container thường rơi vào loại đầu tiên đó.

“Chúng tôi luôn muốn nhắc nhở mọi người, như: 'Đừng cảm thấy tệ khi không muốn nói về [các ứng dụng cũ], nhưng chúng là những ứng dụng quan trọng nhất đối với doanh nghiệp của bạn. Chúng tôi cần đảm bảo rằng chúng tôi giúp bạn giảm chi phí cho chúng hoặc hiện đại hóa chúng và giúp chúng hoạt động tốt hơn'", ông nói. "Chúng tôi không chỉ say mê những tiêu đề về thứ mới nhất sáng bóng".

HỆ THỐNG CONTAINER LÀM MỌI VIỆC TRỞ NÊN DỄ DÀNG HƠN

Quản lý container bằng Kubernetes hoặc hệ thống khác không phải là điều dễ dàng. Ngay cả các nhà phát triển giàu kinh nghiệm cũng bị nhầm lẫn và việc học cần có thời gian.

Đó là lý do tại sao các nhà phát triển có kỹ năng về Kubernetes lại có nhu cầu cao như vậy. Tính đến cuối năm 2020, chỉ có 15.000 người nhận được chứng chỉ Kubernetes từ CNCF. (“Nhân tiện, đó chỉ là những người đã vượt qua kỳ thi,” tổng giám đốc CNCF Priyanka Sharma nói với tôi. “Đó là một kỳ thi khó và không phải là trắc nghiệm.”)

Đối với các nhóm cần một giải pháp đơn giản để quản lý hệ thống container của riêng mình, hãy xem qua các công cụ như Istio và Tanzu .

CONTAINER CHỈ DÀNH CHO CÁC ỨNG DỤNG KHÔNG CÓ TRẠNG THÁI

Khi thời gian chạy container của Docker lần đầu tiên xuất hiện, kỳ vọng chung là container chỉ hữu ích cho các ứng dụng không trạng thái , không lưu trữ dữ liệu từ giao dịch máy chủ-máy khách này sang giao dịch máy khách khác.

Hynes cho biết một số người vẫn liên kết container với các ứng dụng không trạng thái. Nhưng nhờ những tiến bộ trong công nghệ container, giờ đây có thể tạo các ứng dụng có trạng thái, được chứa trong container để lưu trữ dữ liệu liên tục .

“Các ứng dụng hoàn toàn có thể di động, nhưng dữ liệu thì không.”

Giám đốc quản lý sản phẩm cấp cao của NetApp, McClain Buggle, chia sẻ với Built In rằng: "Với công nghệ container, điều thực sự thú vị là cách bạn liên kết hai thứ đó lại với nhau, cách bạn có thể khiến dữ liệu di động như ứng dụng".

NetApp là một nhà cung cấp các mặt phẳng dữ liệu di động mà khách hàng có thể truy cập và sắp xếp thông qua Kubernetes. Điều đó có nghĩa là dữ liệu của ứng dụng có thể theo dõi khi nó di chuyển qua các môi trường điện toán khác nhau trong đám mây công cộng, chẳng hạn.

Buggle cho biết: "Application orchestration là một cách gọi sai. Các ứng dụng hoàn toàn có thể di động, nhưng dữ liệu thì không. Vì vậy, sự tiến hóa mà chúng ta đang thấy là bạn thực sự có thể làm cho một ứng dụng có trạng thái có thể di động nếu bạn cũng có thể làm cho mặt phẳng dữ liệu có thể di động".

5 Ví dụ về Ứng dụng Container

Những công ty nào hiện đang triển khai container và triển khai như thế nào? Vào thời điểm này, một bản tóm tắt toàn diện về các ứng dụng được chứa trong container sẽ đủ lớn để có một khu vực quốc hội riêng. Nhưng một ví dụ về cách một số người áp dụng sớm đáng chú ý triển khai container minh họa lý do tại sao công nghệ này lại có tính chuyển đổi như vậy và tại sao — hơn năm năm sau khi sự phấn khích về container lần đầu tiên tăng lên — nó tiếp tục phát triển rộng rãi hơn.

SPOTIFY

Spotify đã nhận ra giá trị của container từ rất sớm. Nền tảng phát trực tuyến âm thanh bắt đầu sử dụng container vào năm 2013, khi Docker còn mới và thậm chí đã xây dựng hệ thống điều phối nội bộ của riêng mình, được gọi là Helios. (Công ty đã mã nguồn mở Helios một ngày trước khi Kubernetes được công bố, kỹ sư phần mềm Spotify Matt Brown nói với Google Tech Cloud . Spotify bắt đầu chuyển sang Kubernetes ngay sau đó.)

Kỹ sư về độ tin cậy của trang web James Wen cho biết vào năm 2019 , sự thay đổi này đã rút ngắn thời gian cần thiết để có được máy chủ hoạt động cho một dịch vụ mới từ một giờ xuống còn vài phút hoặc vài giây và cải thiện gấp ba lần khả năng sử dụng CPU. Gần đây hơn, Spotify đã phát triển và mã nguồn mở Backstage , một cổng thông tin dành cho nhà phát triển bao gồm hệ thống giám sát Kubernetes.

TỜ NEW YORK TIMES

Tờ New York Times , một đơn vị áp dụng container sớm khác, cũng chứng kiến ​​thời gian triển khai giảm mạnh sau khi chuyển từ máy ảo cổ điển sang Docker. Tony Li, một kỹ sư nhân viên tại tờ báo, cho biết vào năm 2018 , khoảng hai năm sau khi tờ Times quyết định chuyển từ trung tâm dữ liệu riêng sang đám mây và chuyển sang công nghệ đám mây gốc, thời gian trước đây mất tới

ĐỆM

Các ứng dụng mạng xã hội khác nhau có tỷ lệ khung hình ảnh khác nhau, nghĩa là các nền tảng lập lịch xã hội như Buffer phải thay đổi kích thước hình ảnh nhất định để phù hợp với nhiều kênh khác nhau được liên kết với tài khoản của người dùng.

Sau khi Buffer bắt đầu tăng số lượng ứng dụng chạy trên Docker vào năm 2016, tính năng thay đổi kích thước của nó là một trong những dịch vụ đầu tiên mà công ty xây dựng hoàn toàn bằng hệ thống điều phối vùng chứa hiện đại. Việc chứa ứng dụng cho phép triển khai liên tục, điều này sẽ nhanh chóng trở thành tiền đề trong DevOps. “[Chúng tôi] có thể phát hiện lỗi và sửa chúng, đồng thời triển khai chúng cực nhanh. Ngay khi ai đó sửa [lỗi], lỗi sẽ được xóa bỏ”, Dan Farrelly, giám đốc công nghệ tại Buffer, cho biết khoảng một năm sau khi quá trình di chuyển bắt đầu thực sự.

KHOẢNG TRÍNH VUÔNG

Squarespace bắt đầu di chuyển từ máy ảo sang container vào khoảng năm 2016. Nền tảng lưu trữ trang web này cũng đang gặp phải tình trạng thiếu hụt tài nguyên máy tính giống như những nền tảng khác trong kỷ nguyên máy ảo. Các nhà phát triển đã dành nhiều thời gian để cung cấp máy móc bất cứ khi nào một dịch vụ mới sẵn sàng đưa vào sản xuất hoặc khi một dịch vụ hiện có cần được mở rộng quy mô, kỹ sư phần mềm chính của Squarespace Kevin Lynch đã nói với CNCF vào năm 2018 .

Lynch cho biết sự thay đổi này cho phép các nhà phát triển cung cấp dịch vụ mà không cần bất kỳ sự tham gia nào của kỹ thuật đảm bảo độ tin cậy của trang web và giảm thời gian triển khai tới 85 phần trăm.

GIỚI THIỆU

GitLab đã mô tả việc áp dụng Kubernetes là một trong những “ động lực lớn nhất ” thúc đẩy tăng trưởng dài hạn cho doanh nghiệp của mình, cùng với hình thức làm việc từ xa và mã nguồn mở (điều này không có gì ngạc nhiên, vì GitLab và Kubernetes đều là hệ thống nền tảng trong bộ công cụ DevOps ).

Vào năm 2020, giám đốc cơ sở hạ tầng nền tảng của GitLab, Marin Jankovski đã chia sẻ một số con số về cách di chuyển từ máy ảo truyền thống sang container đã tác động đến quy mô cơ sở hạ tầng, hiệu suất và tốc độ triển khai của công ty. Tóm lại, các ứng dụng đang chạy nhanh hơn trên ít máy hơn. Khối lượng công việc chạy trên ba nút, giảm từ 10 nút; các đơn vị xử lý nhanh hơn gấp ba lần; và tốc độ triển khai nhanh hơn 1,5 lần, Jankovski đã viết.