Docker được triển khai bằng khoảng 100 dòng Bash: Bocker (2015)

 (github.com/p8952)
6 điểm bởi GN⁺ 2024-11-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bocker là một dự án triển khai Docker bằng khoảng 100 dòng Bash, cung cấp quy trình tương tự Docker như pull image, run container, xem log, commit và xóa
  • Để chạy cần btrfs-progs, curl, iproute2, iptables, libcgroup-tools, util-linux 2.25.2 trở lên, coreutils 7.5 trở lên; đồng thời cần hệ thống tệp btrfs dưới /var/bocker và cấu hình mạng bridge0
  • Ví dụ trong README cho thấy quy trình pull image centos:7, chạy lệnh trong container, commit kết quả yum install -y wget, rồi kiểm tra /usr/bin/wget trong lần chạy sau
  • Bocker chạy với quyền root và thay đổi interface mạng, bảng định tuyến, quy tắc tường lửa, nên được khuyến nghị chạy trong máy ảo; không có bảo đảm nào về khả năng không làm hỏng hệ thống
  • Hiện đã triển khai docker pull, images, ps, run, exec, logs, commit, rm/rmi, networking và quota dựa trên CGroups, nhưng data volume, data volume container và port forwarding vẫn chưa được triển khai

Mục đích và phạm vi của Bocker

  • Bocker là dự án triển khai Docker bằng khoảng 100 dòng Bash
  • README trình bày luồng lệnh tương tự Docker dựa trên Bash, bao gồm các chức năng như quản lý image, chạy container, xem log, commit thay đổi và giới hạn tài nguyên

Yêu cầu để chạy

  • Các gói cần thiết để chạy như sau

    • btrfs-progs

      • curl
      • iproute2
      • iptables
      • libcgroup-tools
      • util-linux 2.25.2 trở lên
      • coreutils 7.5 trở lên
      • Phần lớn bản phân phối không kèm util-linux đủ mới, nên có thể cần tải mã nguồn util-linux 2.25 và tự biên dịch
      • Hệ thống cần có cấu hình sau
      • Hệ thống tệp btrfs được mount dưới /var/bocker
      • Network bridge tên bridge0 với IP 10.0.0.1/24
      • Bật IP forwarding tại /proc/sys/net/ipv4/ip_forward
      • Cấu hình tường lửa để định tuyến traffic từ bridge0 ra interface vật lý
      • Có kèm Vagrantfile để dễ dàng tạo môi trường cần thiết

Lưu ý khi chạy

  • Ngay cả khi đáp ứng các yêu cầu, Bocker vẫn được khuyến nghị chạy trong máy ảo
  • Bocker chạy với quyền root và cần thay đổi các mục sau
    • Interface mạng
    • Bảng định tuyến
    • Quy tắc tường lửa
  • README nêu rõ không thể bảo đảm rằng Bocker sẽ không làm hỏng hệ thống

Luồng sử dụng ví dụ

  • Khi lấy image centos:7 bằng bocker pull centos 7, một image ID như img_42150 sẽ được tạo
  • bocker images hiển thị image ID và nguồn
    • Ví dụ output: img_42150, centos:7
  • bocker run img_42150 cat /etc/centos-release in thông tin bản phát hành CentOS trong container
    • Ví dụ output: CentOS Linux release 7.1.1503 (Core)
  • bocker ps hiển thị container ID đã chạy và lệnh
  • bocker logs ps_42045 hiển thị log output của container đó
  • bocker rm ps_42045 xóa container
  • Khi chạy bocker run img_42150 which wget ban đầu, kết quả cho thấy chưa có wget
  • Sau khi cài wget bằng bocker run img_42150 yum install -y wget, dùng bocker commit ps_42018 img_42150 để phản ánh thay đổi vào image
  • Sau đó bocker run img_42150 which wget sẽ in ra /usr/bin/wget

Giới hạn tài nguyên và CGroups

  • Ví dụ chạy Bocker cho thấy container được đặt dưới CGroups
    • Trong /proc/1/cgroup xuất hiện các mục như memory:/ps_42152, cpuacct,cpu:/ps_42152
  • Ví dụ về CPU share và giới hạn bộ nhớ mặc định như sau
    • /sys/fs/cgroup/cpu/ps_42152/cpu.shares: 512
    • /sys/fs/cgroup/memory/ps_42152/memory.limit_in_bytes: 512000000
  • Có thể thay đổi giới hạn tài nguyên bằng biến môi trường
    • BOCKER_CPU_SHARE=1024
    • BOCKER_MEM_LIMIT=1024
  • Ví dụ sau khi thay đổi cho thấy các giá trị sau
    • CPU shares: 1024
    • memory limit: 1024000000

Tính năng đã triển khai và chưa triển khai

  • Các tính năng hiện đã triển khai như sau
    • docker build †
    • docker pull
    • docker images
    • docker ps
    • docker run
    • docker exec
    • docker logs
    • docker commit
    • docker rm / docker rmi

    • Networking

      • Hỗ trợ quota / CGroups
      • † bocker init cung cấp một triển khai rất hạn chế của docker build
      • Các tính năng chưa được triển khai như sau
      • Data Volume Containers
      • Data Volumes
      • Port Forwarding

Giấy phép

  • Bocker là phần mềm tự do có thể được phân phối lại và sửa đổi theo các điều khoản của GNU General Public License
  • Có thể chọn phiên bản giấy phép GPL v3 do Free Software Foundation công bố hoặc bất kỳ phiên bản nào về sau
  • Chương trình được phân phối với hy vọng sẽ hữu ích, nhưng không có cả bảo đảm ngầm định về khả năng thương mại hóa hay sự phù hợp cho một mục đích cụ thể

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-11-24
Ý kiến trên Hacker News

  • Tôi từng làm một thứ tương tự bằng proot, tên là Bag [1], và chắc tôi đã không mô tả nó là một lựa chọn thay thế Docker
    Nó không liên quan đến cgroups, và giao diện dòng lệnh cũng khác Docker. Bối cảnh là tôi đã tạo một chuỗi proxy trông giống lưu lượng HTML thông thường để vượt qua kiểm duyệt Internet và kiểm tra gói tin sâu; nó cần chạy liên tục ở bất cứ đâu, nhưng tôi không muốn port nó thành ứng dụng native cho Android
    Tôi muốn chạy nó trong Termux, nhưng lúc đó Termux không có JDK/JRE; nếu dùng proot để dựng môi trường Arch Linux thì có thể dùng JDK. Môi trường Arch bên trong Termux nhìn chung hữu ích hơn, và việc tạo rồi xóa các môi trường dùng một lần với cấu hình khác nhau, sau đó vào bằng proot để chỉ chạy một lệnh duy nhất, cũng dễ tự động hóa bằng script. Vì vậy tôi đặt tên là bag.sh, với ý nghĩa nó nhỏ hơn rất nhiều so với container vận tải
    Thú vị là bag.sh vẫn còn roadmap/TODO chưa đụng tới suốt 5 năm. Vì viết trên màn hình di động và muốn xem mà không phải cuộn, nên phần lớn được căn dòng 40 cột
    [1]: https://github.com/hkoosha/bag

    • Chắc hẳn có khá nhiều câu chuyện kiểu này. Tôi từng phải đóng gói nhiều thành phần thành một môi trường duy nhất trong tình huống VM không phù hợp, nên đã dùng chroot và deb-bootstrap rồi tạo trình cài đặt bằng makeself
      Tôi tạo một Debian nhỏ trong /opt, chứa phần mềm cần thiết cùng các phụ thuộc như MySQL, và nó chạy khá ổn; nó được dùng cho đến khi công ty mà tôi làm thứ này cho họ bị mua lại vào khoảng năm 2016. Nói rộng hơn, tôi nghĩ tự triển khai một phiên bản thô sơ của một ứng dụng lớn là một trong những cách tốt nhất để học cách nó hoạt động bên trong
    • Có vẻ script thiếu vài dấu ngoặc kép quan trọng. Nên chạy thử shellcheck
      mkdir -p $(dirname "$2")
    • Xoay ngang một chiếc tablet 8 inch thì tôi mới vừa có được khoảng 80x22 ở kích thước thực sự đọc được
      Kết hợp với một bàn phím Bluetooth khoảng 10 inch, đủ gọn để nhét thoải mái vào túi trong áo khoác da, thì dù rời nhà không mang túi, bạn vẫn có thể ngồi ở một góc beer garden gần đó để viết code. Lạ là nó cũng khá năng suất; có lẽ vì so với laptop, ma sát để chuyển sang các thứ gây xao nhãng thường ngày cao hơn một chút, nên bạn sẽ nhấp một ngụm bia và tiếp tục nhìn chằm chằm vào code

  • Tôi thích những thứ như thế này. Từ lâu tôi đã thích những thứ làm bằng Bash tối giản
    Có cả một proof of concept bộ cân bằng tải nội bộ cluster bằng Bash 40 dòng, được làm tại một hackathon do chúng tôi tổ chức khoảng 10 năm trước để quảng bá hạ tầng phân tán như Docker, Mesos: https://github.com/cell-os/metal-cell/blob/master/discovery/...
    Có lẽ đã thất lạc rồi, nhưng tôi cũng từng có một công cụ chuyển tiếp colo-to-cloud dựa trên reverse SSH tunnel, có tính dư thừa và phân tán. Những bộ sưu tập kiểu này được tổng hợp rất tốt trên Shell Fu và các nơi tương tự: https://www.shell-fu.org/

    • shell-fu.org rất tuyệt, nhưng tôi cũng muốn xem bình luận của những người dùng khác

  • Việc có thể tái triển khai phần lớn Docker đơn giản như thế này chính là vấn đề lớn nhất mà công ty Docker đã và vẫn đang đối mặt. Về cơ bản, nó gần với mã keo nối các tính năng của kernel lại với nhau
    Nơi Docker thực sự tạo thêm giá trị không chỉ là Docker Hub, mà là Docker for Windows và Mac. Trải nghiệm tích hợp tốt hơn rất nhiều so với việc tự đụng vào VirtualBox và Vagrant để chạy Docker trên máy phát triển

    • Rancher Desktop cũng là một lựa chọn thực dụng và miễn phí. Sau khi giấy phép mới của Docker được áp dụng, nhiều nơi, bao gồm cả chỗ làm của tôi, đã chuyển sang đó
      Cá nhân tôi nghĩ phép màu thật sự của Docker là định dạng image Docker/OCI. Đó là cách xử lý caching và phân phối container image rất tốt, và vẫn là điểm cốt lõi phân biệt nó với VM “toàn phần” và workflow của VM
    • Docker Desktop trên Mac là một mớ hỗn độn đầy hạn chế và thiếu quyền. Dùng Docker CLI với Colima trên Mac cũng có hạn chế về quyền, nhưng ít nhất tránh được giấy phép vô lý và GUI của Docker
      Trên Windows có thể dùng Docker trong WSL và nó chạy rất tốt. Thật khó hiểu vì sao lại dùng Docker Desktop
    • Trên macOS tôi chỉ dùng Colima, trải nghiệm tốt hơn nhiều và nhẹ hơn nhiều
    • Không, Docker lẽ ra nên ưu tiên làm PaaS như CloudRun, Render, Fly rồi bán giá cao cho doanh nghiệp
      Thay vào đó họ làm Docker Swarm nửa vời, không hoạt động đáng tin cậy cho đúng, và nhanh chóng bị Kubernetes vượt qua
    • Trong các hệ thống phổ biến và kiếm ra tiền, có nhiều thứ có thể được tái triển khai “dễ dàng”. Tôi từng nghĩ giá trị của Docker nằm ở Docker image, và có vẻ Docker thực sự được dùng như vậy
      Cách tôi dùng chỉ là lấy môi trường build ảo của ai đó để build phần mềm vài năm trước

  • Trong kho có những cụm như “chưa được triển khai”, “TODO”, “đang làm”, mà nhìn commit cuối cùng đã từ vài năm trước thì thấy hay
    Điều đó khiến tôi thấy nhẹ lòng hơn một chút về việc không quay lại xem các TODO mình rải rác trong code. Không phải muốn hạ thấp tác giả, chỉ là thấy được an ủi thôi

    • Ý hay đấy. Hoàn toàn không phải hạ thấp, mà là đang bình thường hóa trạng thái như vậy nên tôi thấy tốt
      Với code không lương, tình nguyện, làm vì sở thích, nếu chỉ vì nó được công khai mà cảm thấy gánh nặng phải làm, thì việc lập trình sẽ kém vui hơn, và có thể khiến những code lẽ ra đã được công khai lại không được công khai nữa
    • Tôi cảm thấy phần lớn dự án, có lẽ mọi dự án, đều không bao giờ kết thúc. Biết khi nào nên dừng là điều quan trọng
    • Tôi nghĩ như vậy là tốt. Một thứ có thể đơn giản là đã hoàn thành; không nhất thiết lúc nào cũng phải có đầy ắp ý tưởng tiếp theo, dù thường thì luôn có ý tưởng tiếp theo
      Nếu lúc nào cũng có ý tưởng tiếp theo thì theo định nghĩa, cũng sẽ luôn còn TODO chưa hoàn thành. Thực ra trạng thái bình thường của mọi dự án nên là như vậy
    • Khi bắt đầu một dự án, nên dành thời gian nghĩ về “phi mục tiêu”, tức những tính năng nảy ra trong đầu nhưng chủ ý sẽ không triển khai
      Đặt ranh giới phạm vi rõ ràng là hoàn toàn ổn và thường hữu ích. Nhờ vậy sẽ không bị cảm giác dự án mãi mãi chưa “hoàn thành” vì cứ chạy theo các ngả rẽ
    • Hoàn toàn ổn. Khi chương trình làm được việc tôi muốn và phần việc của tôi xong, tôi dừng phát triển. Phần mềm không phải sở thích của tôi

  • Thật ngạc nhiên là lazydocker vẫn chưa được nhắc đến như một lựa chọn thay thế tuyệt vời cho Docker Desktop. Dùng được trên Linux/macOS/Windows [1]
    Đây là một giao diện terminal khá giàu tính năng, và còn có lợi thế là có thể chạy qua SSH
    [1] https://github.com/jesseduffield/lazydocker

    • Nó vừa được đăng đúng nghĩa là vài ngày trước: https://news.ycombinator.com/item?id=42214873
    • Lazydocker chắc chắn trông thú vị, nhưng việc README.md của một dự án mã nguồn mở có quảng cáo tự quảng bá cho một sản phẩm ở lĩnh vực hoàn toàn khác thì hơi quá
      Ít nhất thì đây là lần đầu tôi thấy chuyện như vậy. Tôi cũng tò mò liệu kiểu quảng cáo này có được điều khoản dịch vụ hoặc chính sách sử dụng được phép của GitHub cho phép không

  • Tôi tò mò vì sao Bocker lại thường xuyên lên trang nhất như vậy. Đến năm 2024 mà Docker vẫn còn gây tranh cãi đến thế sao?
    Tôi không hiểu vì sao mọi người không thừa nhận rằng Docker đã mang lại những thứ thực sự hữu ích, chủ yếu là phân phối phần mềm và “chạy dễ dàng ở mọi nơi”

    • Đây chỉ là công cụ học tập để xem Docker hoạt động như thế nào thôi
      Docker là sự kết hợp của các công nghệ kernel đã tồn tại sẵn. Namespace, cgroups, union file system, và có lẽ thêm vài thứ nữa
    • Lý do nó thường xuyên lên trang nhất là vì nhiều người nghĩ Docker là thứ cực kỳ phức tạp, nhưng ở mức nền tảng nhất thì thực ra nó khá thanh nhã và có thể hiểu được
      Vì thế nó thú vị, và về cơ bản là một câu chuyện đúng kiểu HN hoàn hảo
    • Có thể nó lên trang nhất không phải để hạ thấp Docker, mà vì người ta thấy Docker hữu ích và muốn biết nó hoạt động như thế nào. Bocker có thể là lối vào để tìm hiểu các công nghệ đó
    • Ở công ty, tôi đem overlayfs ra trình bày để rút ngắn quy trình CI dài dòng, và mọi người đều ngạc nhiên với mức tăng tốc
      Chỉ sau khi demo cho vài người, tôi mới nhận ra rằng họ cũng có thể cứ dùng /, hoặc lẽ ra tôi đã có thể đem Docker cho họ

  • Một người anh em khác mẹ là https://bastillebsd.org/
    Bastille dùng shell để quản lý FreeBSD jail với nhiều cấu trúc kiểu như có thể thấy trong Docker. Phụ thuộc rất ít nên tôi thích nó hơn các phần mềm quản lý jail khác trên BSD

    • cbsd cũng khá ấn tượng: shttps://www.bsdstore.ru/en/about.html
      Tuy nhiên dù là công cụ dựa trên CLI/TUI, nó gần như là một giải pháp “quá mức tối đa”. Dạo này tôi đang đi qua các bước tạo và quản lý jail chỉ bằng cấu hình mặc định của FreeBSD, nhưng đây chỉ là giai đoạn tạm thời
      Tôi chỉ làm vậy cho đến khi đủ khắc sâu trong đầu cách toàn bộ mọi thứ ăn khớp với nhau để tự tin debug; sau đó tôi định thôi cái trò gõ đá vào nhau như người nguyên thủy và quay lại dùng công cụ cấp cao hơn như một người biết điều
    • Đúng vậy. Với một script shell khoảng 100 dòng thì nó đem lại khá nhiều giá trị
      Nhưng tôi mất một lúc mới hiểu vì sao nó tên là Bastille. La Bastille là pháo đài được xây để bảo vệ Paris khỏi các cuộc tấn công của người Anh trong Chiến tranh Trăm năm, rồi sau này được chuyển thành nhà tù

  • Cần cẩn thận với đoạn “phần lớn distro không cung cấp phiên bản util-linux đủ mới, nên có lẽ bạn sẽ phải lấy mã nguồn ở đây và tự biên dịch”
    Tiền tố cài đặt mặc định là /usr/bin, nên quá trình cài đặt có thể ghi đè lệnh mount hiện có bằng một phiên bản đòi hỏi thư viện không tồn tại. Khi đó ở lần khởi động tiếp theo, kernel sẽ mount hệ thống tệp ở chế độ chỉ đọc

    • Phải là /usr/local/bin

  • Không tốt để dùng hằng ngày, nhưng giúp có cảm giác Docker là gì và hoạt động ra sao
    Trên Linux, Docker về cơ bản là một chroot hào nhoáng

    • Trên macOS/Windows, Docker về cơ bản là một chroot hào nhoáng bên trong Linux VM

  • Sự thật thú vị: Docker bắt đầu bằng Bash, sau đó chuyển sang Python, rồi cuối cùng ổn định với Go
    Ngoài ra, tại một meetup Docker năm 2013, có người đã viết một bản clone Docker bằng Bash. Mọi người muốn học, và hy vọng những thứ như thế này sẽ có ích