Các thùng chứa Linux (LXC) trên Red Hat / CentOS EL6 - lxc-tạo so với libvirt?


13

Thật khó khăn khi cố gắng ở trong những ân sủng của Red Hat và vẫn có kế hoạch cho tuổi thọ hệ thống ...

Tôi đã là người đề xuất Linux Container (LXC) trong hơn một năm. Cài đặt ban đầu của tôi dựa trên thông tin lượm lặt được từ các hướng dẫn trực tuyến, như cái nàycái này . Điều này tập trung vào lxc-create, lxc-start|stoplxc-destroycác lệnh và sửa đổi các mẫu OpenVZ hiện có .

Điều này hoạt động tốt và đang hạnh phúc chạy trong sản xuất. Tuy nhiên, tôi đang đưa ra một số hệ thống bổ sung và quyết định kiểm tra tài liệu hiện tại của Red Hat liên quan đến các container trong EL6. Tôi đã ngạc nhiên khi thấy lập trường chính thức của họ về điều này.

Trong RHEL 6 có cung cấp các công cụ LXC cần thiết để sử dụng Bộ chứa Linux không? , Red Hat mô tả LXC là Bản xem trước công nghệ đề xuất sử dụng libvirt để quản lý việc tạo và quản lý các thùng chứa .

Tuy nhiên, Oracle ủng hộ một kỹ thuật container hóa hoàn toàn khác trong Linux không thể phá vỡ của nó.

Dường như có một số chức năng bị thiếu trong phương thức libvirt, nhưng cách tiếp cận ban đầu của tôi với các lệnh lxc- * là một chút của quy trình thủ công ... Tôi hoàn toàn không thể nói đúng hay phương tiện "được chấp nhận" trong việc quản lý container trên EL6 .

  • Sự khôn ngoan thông thường liên quan đến các hệ thống giống như LXC và RHEL ngày nay là gì?
  • Làm thế nào là bạn thực hiện chúng trong tổ chức của bạn?
  • Có bất kỳ lợi thế cho một cách tiếp cận so với (các) phương pháp khác không?
  • Những cái này có thể cùng tồn tại?

1
libvirttrình điều khiển container LXC và chỉ điều khiển nó, nó không phải là giải pháp ảo hóa / container hóa mỗi se.
Cristian Ciupitu

Câu trả lời:


7

Sự khôn ngoan thông thường liên quan đến các hệ thống giống như LXC và RHEL ngày nay là gì?

Cá nhân, tôi thấy các thiết lập hiện tại hơi thiếu. LXC dường như đi đầu hơn - chắc chắn được duy trì nhiều hơn.

Làm thế nào bạn thực hiện chúng?

Về mặt cung cấp nó như là một tùy chọn ảo hóa thì tôi không. Tôi thấy các thiết lập công nghệ hiện tại thiếu.

  • Không có không gian tên người dùng.
  • Một số điểm nhất định không nhận biết không gian tên (cgroups, selinux)
  • Các giá trị trong / Proc là các hệ thống toàn cầu gây hiểu lầm không tính đến việc phân vùng tài nguyên trong các không gian tên.
  • Phá vỡ kiểm toán.

Tuy nhiên, tôi thấy nó thực sự là một công cụ tuyệt vời để ngăn chặn mức độ ứng dụng. Chúng tôi sử dụng không gian tên và nhóm trực tiếp để chứa tài nguyên mạng và IPC cho các ứng dụng web do người dùng điều hành. Chúng tôi cung cấp giao diện riêng để kiểm soát nó. Trong RHEL7 tôi đang xem xét chuyển chức năng này sang libvirt-lxcphiên bản mới hơn củalibvirt hỗ trợ khái niệm ACL của người dùng.

Để ảo hóa về mặt hệ thống được khởi tạo hoàn toàn, tôi đang chờ đợi một chút những gì được cung cấp trong RHEL7, nhưng thành thật mà nói, tôi cảm thấy chúng ta chỉ có thể thấy một giải pháp đủ tốt khi chúng tôi phát hành phiên bản nhỏ sau của RHEL7 và sau đó có lẽ chỉ trên một trạng thái xem trước công nghệ.

Hãy để mắt đến systemd-nspawnmột cái gì đó cho tôi biết trong 18 tháng tới hoặc có thể nó là công cụ tốt nhất để thực hiện ảo hóa đầy đủ linux, có thể là các tác giả systemd làm cho nó rõ ràng không an toàn ngay bây giờ! Tôi sẽ không ngạc nhiên nếu cuối cùng libvirtgiọt libvirt-lxcvà chỉ cung cấp một trình bao bọc xung quanh systemd-nspawnvới các lát hệ thống được xác định.

Ngoài ra, hãy cảnh giác với nhiều cuộc thảo luận trong 6 tháng qua liên quan đến việc triển khai lại các nhóm như một giao diện lập trình hạt nhân thay vì giao diện hệ thống tập tin (có lẽ sử dụng netlink hoặc một cái gì đó, chưa được kiểm tra) vì vậy systemd sẽ rất nóng trên đuôi nhận được quyền đó rất nhanh.

Có bất kỳ lợi thế cho một phương pháp so với phương pháp khác?

Tôi nghĩ rằng tùy chọn LXC (không phải libvirt-lxc) được duy trì tốt hơn. Đọc xong libvirt-lxcmã nguồn, nó cảm thấy vội vã. LXC truyền thống chắc chắn có các tính năng mới hơn mà đã được thử nghiệm tốt hơn. Cả hai đều yêu cầu mức độ tương thích bởi hệ thống init được chạy trong chúng, nhưng tôi nghi ngờ rằng bạn sẽ thấy LXC hơi "chìa khóa trao tay" hơn một chút so vớilibvirt-lxc tùy chọn đặc biệt liên quan đến việc phát hành các bản phân phối.

Những cái này có thể cùng tồn tại?

Chắc chắn, hãy nhớ rằng đối với tất cả ý định và mục đích, cả hai đều đang làm điều tương tự. Tổ chức không gian tên, nhóm và điểm gắn kết. Tất cả các nguyên thủy được xử lý bởi chính hạt nhân. Cả hai lxctriển khai chỉ cung cấp một cơ chế để can thiệp vào các tùy chọn kernel có sẵn.


9

Red Hat đang thực hiện một cú đẩy container lớn . Họ đang xây dựng một sản phẩm hoàn toàn mới, Máy chủ nguyên tử Red Hat Enterprise Linux , xung quanh nó.

Đối với một cách tiếp cận ít triệt để hơn, hãy xem Hướng dẫn quản lý tài nguyên beta và bộ chứa Linux của RHEL7 ; bạn sẽ nhận thấy nó đẩy libvirt-lxc và không đề cập đến các công cụ lxc.


1
Cảm ơn vì điều đó. Máy chủ nguyên tử RHEL có vẻ phụ thuộc nhiều vào Docker.io . Điều đó chỉ ra rằng Docker và các công cụ liên quan là con đường đúng đắn phía trước?
ewwhite

Red Hat chắc chắn đang đầu tư rất nhiều vào docker, nhưng họ cũng là nhà phát triển chính của libvirt-lxc. Tôi sẽ xem xét các khả năng mà mỗi người cung cấp và xem cái nào phù hợp hơn với nhu cầu của bạn.
tọa

1
Có @ewwhite Tài liệu Redhat sau đây đề cập chính xác rằng: access.redhat.com/articles/1365153
Susinthiran

1

Các tệp thực thi lxc- * được đóng gói trong gói lxc trong EPEL . Tuy nhiên, đây là bản phát hành "hỗ trợ dài hạn" cũ. Bạn thậm chí không có tùy chọn "-f" trong lxc-ls. Tôi chỉ cần cài đặt Ubuntu cho máy chủ LXC của tôi.

Cách RHEL để quản lý LXC dường như thông qua libvirt-lxc nhưng dường như không được chấp nhận .

Lưu ý rằng Ubuntu đang hỗ trợ nhiều phát triển lxc / lxd mới trong khi Redhat đang tập trung vào KVM và docker.


Câu hỏi liên quan đến RHEL 6, sự phản đối là viết tắt của RHEL 7 «Các gói libvirt-lxc sau đây không được dùng nữa bắt đầu với Red Hat Enterprise Linux 7.1:» vì vậy có thể được sử dụng
taharqa
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.