- Bài viết lần theo lịch sử của việc triển khai máy chủ và bài toán cô lập tiến trình, đồng thời làm nổi bật việc FreeBSD jails đã hiện thực hóa khái niệm container hiện đại sớm hơn ngành công nghiệp 10 năm
- Được giới thiệu trong FreeBSD 4.0 vào năm 2000, jails mở rộng
chroot để cung cấp cô lập hoàn toàn hệ thống tệp, mạng và tiến trình như một tính năng native của kernel
- Linux đã đi tới container qua LXC năm 2008 và Docker năm 2013, nhưng trong quá trình đó đã tích lũy các lớp trừu tượng phức tạp như namespace, cgroups, OCI
- Điều Docker giải quyết rất tốt là bài toán đóng gói và phân phối ứng dụng (shipping), còn jails tuy rất mạnh về cô lập nhưng điểm yếu là thiếu một tiêu chuẩn phân phối native
- Phần tiếp theo sẽ đề cập tới cách xây dựng hạ tầng dựa trên jails, ZFS snapshots, provisioning bằng Ansible và các phương pháp vận hành thực tế
Vấn đề của việc triển khai máy chủ thời kỳ đầu
- Vài chục năm trước, cách tiêu chuẩn để triển khai thứ gì đó lên máy chủ là sao chép tệp thủ công qua FTP bằng Total Commander, FileZilla, FAR Manager..., còn người dùng nâng cao thì dùng
scp hoặc rsync, nhưng về bản chất đều như nhau
- Với các dự án do một người làm, sai sót chưa phải vấn đề lớn, nhưng khi quản lý hàng chục dự án khách hàng thì điều đó trở nên chí mạng
- Trong cấu hình backend phổ biến, nhiều website cùng chia sẻ một instance Apache web server và có cùng vòng đời; nếu Apache sập thì tất cả cùng sập
- Khi lưu lượng tăng đột biến, một site có thể ngốn hết tài nguyên, khiến các site khác trên cùng máy chủ âm thầm nghẹt thở
- Các quản trị viên hệ thống đã thử tự động hóa bằng shell script, nhưng không tồn tại phương pháp tiêu chuẩn cho versioning hay rollback, nên thường dùng quy ước thêm số tăng dần hoặc timestamp vào tên thư mục dự án
Hai vấn đề cốt lõi cần giải quyết
- Triển khai (Deployment): cần một giải pháp phổ quát để phân phối ổn định, ngăn lỗi con người, triển khai versioning và rollback, đồng thời bao phủ mọi trường hợp kinh doanh
- Cô lập tiến trình (Process Isolation): cần bảo vệ ứng dụng và hệ thống khỏi ảnh hưởng lẫn nhau, ngăn việc yêu cầu của một ứng dụng âm thầm làm hỏng ứng dụng khác, đồng thời giải quyết xung đột phụ thuộc
- Những nỗ lực giải quyết bài toán triển khai đã tiến hóa thành pipeline CI/CD hiện đại, tiêu chuẩn đóng gói và hệ thống quản lý phiên bản, nhưng lịch sử của bài toán cô lập thì tương đối ít được biết đến hơn
Từ chroot đến máy ảo
chroot, được Bell UNIX đưa ra năm 1979, cung cấp cho tiến trình một góc nhìn cô lập của hệ thống tệp, khiến nó không thể truy cập ra ngoài cây thư mục con; đây là một ý tưởng nguyên thủy nhưng hữu ích
- Giới hạn: nó chỉ cô lập hệ thống tệp; vẫn có thể can thiệp vào mạng, các tiến trình khác và tài nguyên hệ thống, đồng thời cũng có thể thoát ra
- Câu trả lời enterprise thực thụ đầu tiên là máy ảo (VM), được VMware đưa vào dòng chính từ cuối thập niên 1990
- VM cung cấp môi trường OS được cô lập hoàn toàn cho từng ứng dụng, nhưng vì mỗi VM đều chứa một OS đầy đủ nên phải trả giá bằng overhead đáng kể và thời gian khởi động tính bằng phút
Sự ra đời của FreeBSD Jails
- Năm 2000, một cuộc cách mạng thầm lặng đã diễn ra không phải trên Windows Server hay Linux mà là FreeBSD
- FreeBSD khác Linux ở cấp độ nền tảng: Linux chỉ cung cấp kernel, còn userland GNU, hệ sinh thái package và các lựa chọn theo từng distro được ghép lại với nhau; ngược lại, FreeBSD phát triển, quản lý phiên bản và kiểm thử kernel, userland, công cụ cơ bản và thư viện như một OS hoàn chỉnh duy nhất
- Giải pháp được xây dựng trên nền tảng nhất quán đó là jails, do Poul-Henning Kamp và Robert Watson giới thiệu và được tích hợp như tính năng native của kernel trong FreeBSD 4.0 (tháng 3/2000)
- Mỗi jail có góc nhìn hệ thống tệp, ngăn xếp mạng và không gian tiến trình riêng, và không nhìn thấy hệ thống host
- Vì cùng chia sẻ host kernel, nó đạt được overhead gần như bằng 0 và thời gian khởi động gần như tức thì
- FreeBSD đã đạt được trong production một hiện thực hóa thực dụng của thứ ngày nay ta gọi là container, sớm hơn ngành công nghiệp 10 năm
Dòng thời gian của công nghệ cô lập
- Lộ trình tiến hóa thực tế của bài toán cô lập là: máy chủ chia sẻ không có cô lập → máy ảo nặng nhưng được cô lập → container nhẹ nhưng vẫn được cô lập
- FreeBSD đã đạt tới giai đoạn thứ ba vào năm 2000, Linux đạt được điều đó với LXC năm 2008, còn Docker xuất hiện vào năm 2013
- Khi Docker được ca ngợi là cuộc cách mạng, FreeBSD jails đã trưởng thành và được kiểm chứng thực chiến suốt 13 năm
Vì sao Linux chiến thắng
- Ưu thế kỹ thuật không đảm bảo chiến thắng trong cuộc chiến hệ sinh thái
- Linux chiến thắng nhờ ra quyết định nhanh, hiệu ứng lan truyền của giấy phép GPL và sự hậu thuẫn enterprise mạnh mẽ từ Red Hat và IBM
- Sau đó Google, Facebook và Amazon phát triển các công cụ cho trung tâm dữ liệu quy mô lớn, từ đó định hình hướng đi cho toàn ngành
- Linux đã chuyển mình từ "OS miễn phí cho những người không mua nổi giấy phép thương mại" thành "lựa chọn duy nhất cho máy chủ"
Độ phức tạp của hệ sinh thái container Linux
- Để giải quyết bài toán cô lập và triển khai, các kỹ sư Linux đã xây dựng các kernel primitive như namespace, cgroups, seccomp, rồi chồng lên đó các lớp trừu tượng phức tạp như LXC (2008) → OCI/runc (2015) → Docker/Podman (2013/2018) → Docker Hub
- Kết quả là hình thành một mớ hỗn độn được thiết kế quá mức với các lớp trừu tượng rò rỉ (leaky abstractions) cho hạ tầng đám mây phụ thuộc nhà cung cấp
- Ngày nay, để vận hành ứng dụng trong hệ thống quy mô lớn, việc container hóa bằng Docker rồi orchestration bằng Kubernetes đã trở thành mặc định ngầm định, không còn được xem là một trong nhiều lựa chọn mà là điều hiển nhiên
Đóng góp của Docker và điểm yếu của Jails
- Điều Docker giải quyết tốt là bài toán shipping: đóng gói ứng dụng cùng toàn bộ phụ thuộc, phân phối qua registry và chạy nhất quán trên bất kỳ máy nào, qua đó cung cấp một tiêu chuẩn phổ quát
- Định dạng image OCI đã trở thành tiêu chuẩn thực tế của ngành
- Jails giải quyết xuất sắc bài toán cô lập, nhưng thiếu giải pháp native cho shipping, và đây là nguyên nhân chính khiến hệ sinh thái jails có vẻ kém trưởng thành hơn so với hệ sinh thái Docker
- Cộng đồng cũng nhận ra khoảng trống này, và một số công cụ như cbsd, bastille, pot, appjail... đang cố gắng mô phỏng hệ sinh thái container hiện đại; bên cạnh đó cũng tồn tại những cách tiếp cận khác tận dụng các primitive native của FreeBSD
Giới thiệu phần tiếp theo
- Trong phần sau, bài viết sẽ đề cập đến sự ngắn gọn và thanh nhã của hạ tầng dựa trên FreeBSD, từ nền tảng của jails và cơ chế hoạt động, cách giảm boilerplate thông qua jail manager, provisioning và triển khai bằng Ansible, sức mạnh của ZFS snapshots, và cách kết hợp tất cả những điều đó để xây dựng hạ tầng vững chắc, có thể mở rộng cho Hypha
1 bình luận
Ý kiến trên Hacker News
Chỉ với ưu thế kỹ thuật thì không thể thắng trong cuộc chiến hệ sinh thái
Giữa thập niên 90, Linux phát triển nhờ tốc độ ra quyết định nhanh, tính lan truyền của giấy phép GPL, cùng sự hậu thuẫn doanh nghiệp từ Red Hat và IBM
Tôi cài Linux vào năm 1994, nhưng cộng đồng FreeBSD lại xem thường chiếc PC 3.500 USD của tôi và bảo nó “không ra gì”
Có lỗi ở giao diện IDE, nhưng Linux đưa ra cách khắc phục chỉ sau vài ngày, còn phía BSD thì chỉ bảo tôi đi mua thiết bị SCSI
Khi đó tôi là sinh viên đại học, không có tiền, nên cuối cùng Linux là lựa chọn thực tế hơn
Sau này tôi có thử lại FreeBSD, nhưng lúc đó Linux đã làm được mọi thứ tôi cần rồi
Lỗi liên quan được tổng hợp trong bài wiki về CMD640
Dù vậy, tôi vẫn thích FreeBSD vì tính nhất quán của hệ thống cao hơn, và các thành phần cốt lõi như âm thanh hay API sự kiện được duy trì ổn định
Hỗ trợ driver cho phần cứng mới vẫn là Linux tốt hơn, nhưng tôi hy vọng FreeBSD đừng trở nên quá “giống Linux”
Thực ra với *nix hiện đại thì bên nào cũng làm được gần như mọi thứ. Giờ đây không còn là vấn đề hiệu năng mà là gu và sự quen thuộc
Trong khi đó BSD bị các doanh nghiệp né tránh vì vụ kiện với AT&T, và trong khoảng thời gian đó Linux đã chiếm lĩnh thị trường
Đến giờ vẫn có những bài viết bênh vực FreeBSD, nhưng rất khó đảo ngược xu thế đã hình thành từ thập niên 90
Nhưng tôi vẫn nghĩ hỗ trợ phần cứng đến giờ vẫn còn nhiều chỗ để cải thiện
Bài viết khá thú vị
Tôi không đồng ý với nhận định rằng các primitive của kernel Linux như namespaces, cgroups, seccomp cuối cùng đã tạo ra một hệ sinh thái trừu tượng hóa phức tạp
Linux trở nên phức tạp vì nó thành công, chứ không phải vì thiết kế thất bại
Nếu BSD mới là dòng chính thì rất có thể cũng sẽ xuất hiện một hệ sinh thái “quá mức kỹ nghệ” y hệt
Xét cho cùng, container chỉ là VM hạng nhẹ, nên tôi nghĩ dùng VM thật còn tốt hơn
Lý do Docker phổ biến là khả năng tái sử dụng và hệ sinh thái, chứ không phải vì cách ly bảo mật
Jail của FreeBSD thì đơn giản và thanh nhã, nhưng container OCI trên Linux lại dễ dùng hơn rất nhiều
Container không phải là một tính năng độc lập của kernel mà là một ảo giác được ghép từ nhiều namespace, mount và cơ chế cô lập tiến trình
Thiết kế của Linux là có chủ đích, và cgroups cùng seccomp còn được dùng rộng rãi ngoài container, như trong systemd hay flatpak
Triết lý “gia súc vs thú cưng” có thể được áp dụng ở cấp VM và orchestration
Nói jail tốt hơn thì về mặt thực tế không mấy thuyết phục
Docker thắng không phải nhờ khả năng cách ly kỹ thuật mà nhờ hệ sinh thái
Nhờ các công cụ như Dockerfile, public registry và compose, người ta có thể tạo môi trường có thể chạy được chỉ trong 30 giây
Jail của FreeBSD rất xuất sắc về mặt kỹ thuật, nhưng rào cản gia nhập lại cao
Gần đây cũng xuất hiện xu hướng quay lại với jail hoặc VM đơn giản vì độ phức tạp của stack container
Nhưng đây không phải chuyện cạnh tranh mà là mỗi bên có vai trò riêng
FreeBSD không có khái niệm như vậy, và cũng thiếu cả hệ thống image
Nếu FreeBSD đầu tư vào UX và hệ sinh thái như Docker, số người dùng có lẽ đã tăng lên gấp nhiều lần
Khoảng năm 2005, tôi từng vận hành cả công ty trên FreeBSD
Nhưng theo thời gian, Linux đã thống trị cả máy cá nhân lẫn công việc
Giờ Docker cũng đã đủ ổn, nên không còn lý do hợp lý nào để quay lại nữa
Nhưng do phản ứng chậm với thời đại CPU đa lõi nên đã bị Linux và Windows vượt qua
Hiện nay hiệu năng đã phục hồi, nhưng vẫn bất lợi vì thiếu driver và giới hạn về số lượng nhà phát triển
Tôi dùng Linux ở nơi cần GPU hay CUDA, còn với server cần ổn định thì dùng FreeBSD
UX của FreeBSD nhất quán hơn, nhưng xét thực tế thì Linux đã trở thành “con đường dễ chịu nhất”
Lúc nào thấy bài giới thiệu FreeBSD tôi cũng vui
FreeBSD đưa vào jail từ năm 2000, nhưng bên Linux khi đó đã có các công nghệ tương tự như OpenVZ và VServer
Cuối cùng, khi LXC xuất hiện vào cuối những năm 2000, người ta mới hình thành nhận thức rằng “FreeBSD đã đi trước”
Tôi tò mò không biết có bài nào giải thích ở mức kỹ thuật về cách triển khai cơ chế cách ly giữa container và VM hay không
Không phải kiểu nói chung chung rằng “chúng dùng chung kernel nên yếu hơn”, mà là tôi muốn biết chi tiết triển khai thực tế
Gần đây có những tính năng như systemd-oomd khiến tôi muốn quay lại FreeBSD
Trước đây tôi thường để nhiều tiến trình chạy trong terminal và lưu log khi phát triển,
nhưng giờ systemd lại giết cả nhóm tiến trình theo đơn vị cgroup, khiến công việc đang làm bị mất hết
Những thay đổi hệ thống không tương thích kiểu này làm vỡ luồng làm việc, và việc phải dùng systemd-run hoặc Docker mỗi lần để cô lập tiến trình thật sự rất bức bối
Cốt lõi thành công của Linux là tính lây lan của GPL và hiệu ứng mạng lưới
Khi người dùng xem Linux là tiêu chuẩn, các nhà sản xuất phần cứng cũng tự nhiên phát hành driver cho Linux
Nhờ tính linh hoạt của kernel, hệ sinh thái driver mã nguồn mở đã bùng nổ mạnh mẽ