Firecracker là gì và tại sao các công ty hạ tầng Agent lại quan tâm đến nó?

in Vietnamese.</think>Mỗi ngày, AWS Lambda thực thi hàng nghìn tỷ lệnh gọi hàm mỗi ngày. AWS Fargate lên lịch cho hàng triệu container. Mỗi một trong số đó là một máy ảo hoàn chỉnh, với kernel riêng, khởi động trong tích tắc.

Làm thế nào? Khoảng 50.000 dòng Rust có tên Firecracker, ra đời vì ngành công nghiệp cuối cùng đã thừa nhận rằng một container Linux kiểm soát tài nguyên chưa bao giờ được thiết kế để trở thành ranh giới bảo mật.

Vấn đề cô lập

Mỗi Docker container trên máy tính xách tay của bạn là ba tính năng kernel Linux trong một lớp áo khoác:

• Namespaces là những tấm bịt mắt. Một tiến trình bên trong có một góc nhìn riêng tư về hệ thống: danh sách PID riêng, ngăn xếp mạng riêng, bảng gắn kết riêng, tên máy chủ riêng và ID người dùng riêng. PID 1 bên trong container là một PID ngẫu nhiên nào đó trên máy chủ; container thậm chí không thể thấy các tiến thể thấy các tiến trình khác.
• cgroups là ngân sách. Control groups là lớp kế toán và giới hạn tốc độ của kernel. Chúng giới hạn lượng CPU, bộ nhớ, IO đĩa và băng thông mạng mà một cây tiến trình được phép tiêu thụ.
• seccomp + capabilities là danh sách cho phép. Capabilities chia nhỏ quyền root thành ~40 đặc quyền riêng biệt (bind cổng thấp, tải module kernel, gắn kết hệ thống tệp, v.v.) để bạn chỉ cấp những quyền cái cần. seccomp là một bộ lọc theo tiến trình quyết định tiến trình nào (API duy nhất của không gian người dùng vào kernel) được phép thực hiện.

Bạn có thể tự kiểm chứng điều này mà không cần cài Docker:

<code-segment id="0" lang="text">

unshare --fork --pid --mount-proc bash

</code-segment>

Mọi thứ khác Docker làm (các lớp hình ảnh, registry, DNS) đều là lớp DNS) là lớp điều phối bên trên.

Tất cả.

Tất cả sự bảo vệ đó đều đi qua một kernel Linux duy nhất, khoảng 30 triệu dòng mã với 400+ syscall. Mọi container trên máy chủ đều gọi vào cùng một kernel đó. Một lỗi trong bất kỳ syscall nào cũng có thể kết thúc trò chơi cho mọi tenant trên máy đó.

Máy ảo hoàn chỉnh giải quyết quyết vấn đề cô lập bằng vũ lực: mỗi VM có kernel riêng.

CPU hiện đại có "chế độ khách" chạy các lệnh của khách trực tiếp trên silicon thật. Máy chủ chỉ bị kéo vào khi khách làm điều gì đó có đặc quyền (chạm vào phần cứng thật, gây lỗi, bị ngắt). Một hypervisor là lớp mỏng phân xử những khoảnh khắc đó.

Linux đi kèm hypervisor của nó dưới dạng một module kernel gọi là KVM, được hiển thị tại /dev/kvm. Nó dựa trên các phần mở rộng ảo hóa phần cứng (vmx trên Intel, svm trên AMD):

<code-segment id="1" lang="text">

Kiểm tra xem KVM có sẵn không

ls -l /dev/kvm

</code-segment>

Vấn đề với VM hoàn chỉnh là chúng chúng chậm và nặng. Một VM QEMU cổ điển giả lập toàn bộ một PC tưởng tượng (BIOS, bus PCI, bộ điều khiển IDE, card VGA, bàn phím PS/2) vì đó là thứ mà một hệ điều hành năm 1998 mong đợi để khởi động. Hình ảnh có kích thước hàng trăm megabyte. Khởi động mất vài giây. Dung lượng bộ nhớ là hàng trăm MiB trước khi khối lượng công việc của bạn bắt đầu. Đối với một yêu cầu web sống 40ms, bạn sẽ mất 40× thời gian đó để khởi động máy.

Vậy bạn bị kẹt giữa:

• Container: khởi động 50ms, chi phí 5 MiB, bề mặt tấn công kernel dùng chung.
• VM: khởi động 5+ giây, chi phí 300+ MiB chi phí, cô lập phần cứng.

Mọi người chạy mã đa tenant đa người dùng không tin cậy (AWS, và về cơ bản là mọi nhà cung cấp sandbox AI hiện có) đều cần cả hai mặt của sự đánh đổi đó cùng một lúc.

Bước vào microVM

Một VMM (Virtual Machine Monitor) là tiến trình không gian người dùng điều khiển hypervisor: nó thiết lập bộ nhớ khách, cắm các thiết bị ảo và bảo KVM bắt đầu chạy mã khách.

Một microVM là một VMM với PC năm 1998 bị xóa: không BIOS, không bus PCI, không VGA, không USB, không ACPI (không có phần cứng kế thừa mà một máy tính để bàn thực sự khởi động qua, và không liên quan đến một cuộc gọi hàm 40ms). Những gì còn lại: KVM, một console nối tiếp và một số thiết bị virtio (net, block, vsock).

virtio là giao diện thiết bị tiêu chuẩn "Tôi biết tôi đang chạy trong một VM". Khách hợp tác với hypervisor thông qua các NIC và đĩa ảo nhẹ (virtio-net, virtio-block) thay vì giả vờ điều khiển một card Intel e1000 thực sự hoặc bộ điều khiển IDE. Sự hợp tác đó, cùng với tất cả phần cứng kế thừa bị thiếu ở trên, là lý do lớn nhất khiến microVM khởi động nhanh.

Kết quả:

• ~125ms khởi động từ khi VMM khởi chạy đến khi không gian người dùng khách chạy init.
• <5 MiB chi phí bộ nhớ VMM mỗi VM (bộ nhớ kế toán mà máy chủ trả cho mỗi VM, trước khi khối lượng công việc khách tự cấp phát bất kỳ thứ gì).
• 150 VM/giây tốc độ tạo trên một máy chủ.
• ~2–8% hiệu suất thời gian chạy so với máy thực.

Cùng mức độ cô lập phần cứng như một VM hoàn chỉnh với cùng mật độ như một container.

Firecracker là VMM, tiến trình thực sự nói chuyện với /dev/kvm và khởi động microVM. Phần còn lại của bài viết này là toàn bộ ngăn xếp đó từ đầu đến cuối.

Firecracker

Vào tháng 11 năm 2018, AWS đã mã nguồn mở Firecracker tại re:Invent. Nó đã chạy Lambda trong sản xuất, thứ khiến lệnh import pandas của bạn khởi động lạnh của bạn đủ nhanh để tính phí theo mili giây. Vào năm 2020, nhóm đã công bố kiến trúc tại NSDI '20.

Kiến trúc

Được fork từ crosvm của Google, viết lại bằng Rust, với hơn một nửa số mã bị xóa. Mỗi tiến trình Firecracker là một microVM, với chính xác ba loại luồng (được ghi lại trong docs/design.md):

• API thread là bàn đặt hàng. Một máy chủ REST gắn với một Unix socket (một socket chỉ cục bộ sống dưới dạng tệp trên đĩa, không phải là cổng TCP). Chấp nhận cấu hình trước khi khởi động và các hành động hạn chế sau đó.
• VMM thread là xưởng sản xuất phần cứng. Nó giả vờ là mọi thiết bị mà khách có thể thấy. Khi khách chạm vào thứ mà nó nghĩ là thanh ghi NIC, CPU tạm dừng khách, VMM xử lý cú chạm ("khách đá hàng đợi TX, xả nó") và tiếp tục. Cơ chạy. Cơ chế: khách đọc/ghi các địa chỉ ma thuật; CPU bẫy chúng ra máy chủ.[^mmio]
• vCPU threads là những người chạy. Một mỗi CPU khách, mỗi cái trong một vòng lặp chặt: yêu cầu KVM chạy khách cho đến khi có điều gì đó thú vị xảy ra (chạm chạm thiết bị, ngắt, dừng), xử lý nó, lặp lại.

Chúng nói chuyện với nhau qua các kênh Rust (hàng đợi tin nhắn trong tiến trình, không khóa). Khách thấy chính xác bốn thiết bị.

Bốn thiết bị

• virtio-net là NIC của VM, không có giả lập năm 1998. Khách ghi các gói tin vào một virtqueue (một bộ đệm vòng trong bộ nhớ dùng chung); VMM xả chúng ra qua một thiết bị TAP phía máy chủ (một giao diện Ethernet ảo mà kernel hiển thông là một tệp), được điều khiển bởi io_uring hoặc epoll để luồng VMM không bị chặn.
• virtio-block là đĩa của VM, chỉ là IO tệp trên máy chủ. Khách đặt các yêu cầu sector vào một virtqueue; VMM phát hành pread/pwrite đơn giản vào một tệp máy chủ. Không IDE, không AHCI, không SCSI.
• virtio-vsock là hệ thống liên lạc nội bộ của VM với máy chủ. Được định địa chỉ bằng một bộ (context-id, port) thay vì cặp IP/cổng, để tác nhân khách có thể gọi về nhà (nhật ký, ping sức khỏe, siêu dữ liệu snapshot) mà không cần IP khách và không có gì trên dây để giả mạo.
• 8250 serial UART là console khởi động. Một chip n chip nối tiếp kế thừa nhỏ được giả lập tại một địa chỉ cố định. Được sử dụng cho nhật ký khởi động sớm và kết xuất sự cố trước khi virtio hoạt động. Rẻ, phổ biến, không bao giờ biến mất.

Khởi động một microVM, từ đầu đến cuối

API là toàn bộ mặt phẳng điều khiển: kênh cấu hình, được tách biệt có chủ đích khỏi mặt phẳng dữ liệu (các luồng vCPU thực sự chạy mã khách). Bạn khởi động tệp nhị phân trỏ đến một Unix socket:

<code-segment id="2" lang="text">

firecracker --api-sock /tmp/firecracker.sock

</code-segment>

Sau đó, bạn PUT cấu hình vào nó:

<code-segment id="3" lang=" lang="text">

curl --data '{

"boot-source": {

"kernel_image_path": "/path/to/vmlinux",

"boot_args": ["console=ttyS0"]

},

"drives": [{

"drive_id": "rootfs",

"path_on_host": "/path/to/rootfs.ext4",

"is_root_device": true

}],

"machine-config": {

"vcpu_count": 1,

"mem_size_mib": 128

}

}' http://localhost/snapshot/create

Bốn cuộc gọi HTTP. Đó là toàn bộ mặt phẳng điều khiển.

Hành tây bảo mật

Một ranh giới KVM duy nhất đã rất mạnh. Firecracker bọc thêm hai lớp xung quanh nó.

[Jailer là một trình xây dựng hộp cát. Công việc duy nhất của nó là đóng gói VMM trước khi nó chạy. Nó tạo một chroot (một tính năng Linux khóa một tiến trình vào một cây thư mục con duy nhất như thể thư mục đó là gốc của hệ thống tệp; tiến trình theo nghĩa đen không thể đặt tên bất kỳ thứ gì ở trên nó), thả vào một không gian tên PID mới để nó không thể thấy các tiến trình khác của máy chủ, chuyển sang uid/gid không có đặc quyền, áp dụng giới hạn CPU/bộ nhớ cgroup, và chỉ sau đó thực thi tệp nhị phân Firecracker bên trong nhà tù đó:

<code-segment id="3" lang="text">

jailer --id <unique-id> --exec-file /usr/bin/firecracker --uid <uid> --gid <gid <gid> --chroot-base-dir /srv/jailer

</code-segment>

Bây giờ bản thân tiến trình VMM không có hệ thống tệp nào ngoại trừ một chroot dành riêng, không có quyền nhìn thấy các tiến trình khác trên máy chủ và không có khả năng root. Nếu một cuộc vượt ngục từ khách đến máy chủ thực sự xảy ra qua virtio hoặc KVM, kẻ tấn công sẽ rơi vào chroot đó với các giới hạn cgroup.

Seccomp là một danh sách cho phép syscall theo từng luồng. Bất kỳ thứ gì không có trong danh sách đều bị giết (hoặc trả về EPERM) trước khi nó đến trình xử lý syscall của kernel. Firecracker cung cấp ba cấp độ:

1. Cấp độ 0: tắt. Đừng dùng trong sản xuất.
2. Cấp độ 1: danh sách cho phép theo số syscall.
3. Cấp độ 2: cũng ràng buộc giá trị đối số (ví dụ: ioctl được phép, nhưng chỉ với KVM_RUN làm lệnh). Mặc định và được khuyến nghị.

Mỗi luồng nhận được bề mặt tối thiểu có thể: luồng API không cần ioctl(KVM_RUN); các luồng vCPU không cần socket(). Một cái nhìn đơn giản về một quy tắc trông như thế nào:

<code-segment id="4" lang="rust">

// Chỉ cho phép ioctl với lệnh KVM_RUN

SeccompRule::new_rule(Action::Allow, Syscall::ioctl)

.and_condition(Condition::new(1, ArgCmp::Eq, KVM_RUN))

.build()

</code-segment>

Mỗi lớp phải thất bại độc lập để kẻ tấn công đến máy chủ.

Ảnh chụp nhanh: mã gian lận đằng sau Lambda SnapStart

Chụp ảnh nhanh của một microVM đang chạy. Khôi phục nó trong mili giây, trên một máy chủ khác, vào một tiến trình VMM hoàn toàn mới. Bỏ qua khởi động kernel, bỏ qua init, bỏ qua làm ấm JIT.

Bạn đóng băng VM đang chạy và kết xuất trạng thái bộ nhớ + thiết bộng lên đĩa:

<code-segment id="5" lang="text">

Chụp ảnh nhan

curl --unix-socket /tmp/firecracker.sock -X PUT \

--data '{"snapshot_type": "Full": true}' \

http://localhost/vm/snapshot/create

</code-segment>

Một ảnh chụp ảnh nhan trạng thái sau khi làm ấm, vì vậy VM được khôi phục thức dậy giữa cuộc đời của nó, không phải ở đầu.

Đây chính xác là những gì AWS Lambda SnapStart làm: khởi tạo một Java Lambda một lần, chụp ảnh nhan microVM và khôi phục ảnh nhan đó vào mỗi lần khởi động lạnh tiếp theo (thông báo). Khởi động lạnh JVM đột nhiên từ 8+ giây xuống dưới giây.

Cách chúng kết hợp với nhau

gVisor là một thiết kế khác: một kernel không gian người dùng trong Go, một triển khai lại giao diện syscall Linux chạy như một tiến trình bình thường. Các syscall của khách chạm của khách chạm vào gVisor thay vì kernel máy chủ, và gVisor quyết định chuyển tiếp gì (nếu có) xuống dưới. Khởi động nhanh hơn microVM, chi phí syscall 10–30% trên đường nóng và một ranh giới tin cậy khác.

Firecracker nằm trong ô "kernel riêng, nhưng không có PCI BIOS": cô lập phần cứng, mô hình thiết bị nhỏ và khởi khởi động trong mili giây.

Chọn công cụ của bạn:

Ai sử dụng cái này

Gần như nhanh hơn để liệt kê các nền tảng serverless không nằm trên microVM.

Firecracker trong sản xuất:

• AWS Lambda và AWS Fargate: trường hợp sử dụng ban đầu. Mỗi lần gọi Lambda đều đáp xuống một microVM Firecracker; các tác vụ Fargate là các VM Firecracker với một thời gian chạy container mỏng bên trong.
• [Fly.io Machines](https://fly.io/docs/machines/): mỗi máy fly chạy là một microVM Firecracker, phân phối toàn cầu, với khởi động lạnh dưới giây và đĩa liên tục.
• Hầu hết mọi hộp cát thực thi mã AI mà bạn đã sử dụng trong mười tám tháng qua đều sống trong một microVM Firecracker.

Hình dạng của một API hộp cát gần như sau đây gần như giống nhau ở các nhà cung cấp:

<code-segment id="6" lang="text">

Tạo một sandbox, chạy mã, lệnh, nhận kết quả

sandbox = client.create_sandbox()

result = sand.run("python -c 'print(2**100)'")

print(result.text)

</code-segment>

Trong khoảng bốn dòng mã: một microVM Firecracker khởi động, một kernel khởi tạo, một tiến trình tác nhân bên trong khách nhận lệnh của bạn qua vsock, chạy nó, phát trực tiếp kết quả về và VM chết.

Kỷ nguyên tác nhân: tại sao tất cả điều này quan trọng ngay bây giờ

Một năm trước, "hộp cát AI là gì?" là một câu hỏi ngách. Nếu một LLM tạo mã, có khả năng cao là nó không an toàn 100% để chạy trên bất kỳ máy nào, vì vậy bạn sẽ chạy nó trong một hộp cát phù duy nhất.

Ngày nay, mọi sản phẩm AI nghiêm túc đều gửi một tác nhân. Hộp cát của họ cũng tốt hơn, nhưng hình dạng của các tác nhân đã thay đổi, và các câu trả lời thời thời gian chạy cũ không phù hợp với hình dạng mới.

**Tác nhân trong tiến trình so với tác nhân cấp máy chủ

Vòng một của các tác nhân AI sống bên trong ứng dụng của bạn. Bạn nhập một thư viện, nối một vòng lặp và chạy nó trong backend hiện tại của bạn:

<code-segment id="7" lang="text">

Ứng dụng của bạn, vòng lồng nhau: tác nhân trong tiến trình

import { generateText } from 'ai';

const agent = new Agent({ model: 'gpt-4' });

const result = await agent.run('Tóm tắt email này');

</code-segment>

Mỗi cuộc gọi là một vòng tròn HTTP đến một mô hình. Mỗi cuộc gọi công cụ là một hàm trong tiến trình của bạn. "Hộp cát" là máy chủ của bạn. Đây là thế giới của Vercel AI SDK, LangChain, OpenAI Agents SDK. Nó hoạt động tốt và vẫn cung cấp một phần lớn các tác nhân sản xuất ngày nay.

Vòng hai thì khác. Claude Code, Codex và OpenCode là các tác nhân cấp máy chủ: các tệp nhị phân tiếp quản một máy, không phải thư viện sống bên trong máy của bạn. Chúng mong đợi một shell thực sự, một trình quản lý gói và một đĩa có thể ghi. Khi bạn giao cho Claude Code một nhiệm vụ, nó chạy loại này:

<code-segment id="8" lang="text">

Tác nhân cấp máy chủ: chiếm quyền điều khiển máy

claude "Cài đặt phụ thuộc và chạy thử nghiệm

</code-segment>

Đó là một shell/bash. Nó cần một hệ thống tệp thực sự, một fork/exec thực sự, một trình quản lý gói, một đĩa bạn có thể ghi, một mạng bạn có thể truy cập. Không có điều nào trong số đó có thể được diễn diễn dưới dạng lược đồ công cụ chat-completion, và không có điều nào an toàn để chạy trong một container kernel dùng chung cùng với các tenant khác.

Các phòng thí nghiệm đang đào tạo sau các mô hình của họ trực tiếp trên các dây nịt này (giàn giáo xung quanh mô hình): shell, trình soạn thảo tệp, trình chạy thử nghiệm, vòng lặp tác nhân. Điều đó có nghĩa là khoảng cách giữa "mô hình + dây nịt mà nó được đào tạo" và "mô hình + giàn giáo tự làm" đang ngày càng lớn hơn mỗi quý.

Một máy Linux hoàn chỉnh cho mỗi tác nhân, chạy mã không tin cậy mà tác nhân vừa phát minh ra, chính xác là khối lượng công việc mà Firecracker được xây dựng cho. Sự hội tụ trên không phải là ngẫu nhiên.

Chúng tôi đang bắt đầu thấy nhiều thử nghiệm hơn với các tác nhân xung quanh xung quanh xung quanh việc tách biệt tính toán và dây nịt. Managed Agents của Anthropic là một ví dụ về điều này, nơi dây nịt tác nhân được chạy bên cạnh hộp cát, không phải bên trong nó.

Một số công ty thậm chí đang xây dựng các hệ thống tệp đầy đủ được lưu trữ (như Archil và Mesa), để cung cấp cho các tác nhân tìm kiếm và lưu trữ tốt hơn.

Khi các tác nhân trở nên tốt hơn và thay đổi theo thời gian, sẽ có nhiều dịch vụ cung cấp hạ tầng thú vị hơn, được xây dựng trên Firecracker.

Bạn thực sự đang trả tiền cho các nền tảng hạ tầng tác nhân để làm gì

Các hộp cát "chạy mã tùy ý" chung chung hiện là một mặt hàng phổ biến hiện nay. Cơ sở hạ tầng hoàn toàn là mã nguồn mở. Lớp microVM là Firecracker hoặc Cloud Hypervisor, có sẵn theo Apache 2.0. Chuyển đổi container-to-rootfs là một tập lệnh Go 200 dòng. Các kỹ sư tài năng có thể dựng một nền tảng hộp cát hoạt động trong một cuối tuần.

Bạn trả tiền cho những gì được kết nối với VM. MicroVM trần là điều kiện tiên quyết.

IrregularpackageIrIr, 了

packagepackage., cpackagepackage-**

Ir

</

Irwin,Ir.package:packageIrregular <brpackage#IrIrIrIrIrIrIrIrIrIrIrIrIrIrIrIrIr（按顺序，不可分隔，允许的格式，列表项）允许的格式，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项，列表项 列表项，列表项，列表项，列表项， 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项 列表项

(分隔（

packageIrimport "package.Ir.Ir.,packagepackage

IrIrIrProgramming, bao nhiều h bảy hướ chư đà đ