Zarf: gói cả ứng dụng Kubernetes vào một file để mang vào cụm không có internet

Thử hình dung một lệnh helm install hỏng ngay ở dòng đầu tiên vì node không kéo được image. Ở một cụm Kubernetes bình thường, đó là lỗi cấu hình. Ở cụm của một ngân hàng, nhà máy hay đơn vị quốc phòng không có đường ra internet, đó là chuyện thường ngày, và mỗi lần như vậy bạn lại phải đi một vòng xin phép để chép file vào.

Zarf không xóa được vòng xin phép đó, nhưng nó gom nhiều lần chép lẻ tẻ về một lần: một file duy nhất, được kiểm trước khi qua ranh giới. Theo tài liệu chính thức, đây là công cụ theo kiểu khai báo, dùng để đóng gói và đưa phần mềm vào những môi trường bị cắt mạng, mạng hạn chế hoặc hoàn toàn đứng riêng.

Với FDE, đây không phải chuyện ngách. Càng có nhiều khách hàng thuộc ngành bị quản lý chặt, bạn càng hay phải đưa phần mềm vào một cụm mà mình không bao giờ được nối mạng tới.

Bài toán thật sự là “mang theo hết”

Theo Mattermost, một nhà cung cấp từng triển khai sản phẩm của mình bằng Zarf, công cụ này được thiết kế để đưa phần mềm vào hệ thống cô lập cùng toàn bộ file và dependency đi kèm. Mục đích ban đầu là cài ứng dụng vào cụm container do Kubernetes điều phối, nơi có những quãng dài không có mạng.

Nguồn gốc của công cụ giải thích vì sao nó khắt khe như vậy. Wayne Starr của Defense Unicorns, công ty đầu tiên viết ra Zarf, kể rằng nó xuất phát từ một nghiên cứu tại Naval Postgraduate School phục vụ Hải quân Mỹ.

Brandt Keller, người làm Zarf, nói trên podcast của OpenSSF rằng ngay từ đầu nó đã nhắm tới việc đóng gói, chuyển và deploy phần mềm một cách tin cậy. Mọi thứ được mô tả trong một manifest khai báo, nên package ghi lại đúng trạng thái của ứng dụng và lần deploy nào cũng ra cùng một kết quả.

Một package chứa những gì?

Bài tổng kết của OpenSSF cho biết một package Zarf gói chung image, Helm chart và cấu hình của ứng dụng vào một file. Tài liệu Create a Package mô tả lệnh zarf package create làm việc theo thứ tự: nạp nội dung của từng component, gom mọi image, tạo SBOM nếu bạn không chủ động bỏ qua, rồi mới ghi ra file archive.

SBOM nghe thì phụ, nhưng lại rất có giá. Ở khách hàng bị quản lý chặt, thứ giữ chân bạn lâu nhất thường không phải lệnh cài mà là buổi rà soát bảo mật trước đó. Khi danh sách thành phần đi kèm đúng file sẽ được mang vào, bạn trả lời câu hỏi “trong này có gì” bằng tài liệu chứ không bằng trí nhớ.

Keller khuyên rằng mọi thứ phải được kiểm tra trước khi đi qua ranh giới vào mạng cô lập. Vì thế đừng bỏ qua SBOM chỉ để build nhanh hơn vài phút.

Thử hình dung một lần triển khai

Giả sử bạn cần đưa vào cụm on-prem của một ngân hàng một ứng dụng gồm hai image backend và frontend, một Helm chart và một manifest ConfigMap. Bước khai báo là ghi đủ bốn thứ đó vào file zarf.yaml.

Template trong tài liệu bắt đầu bằng kind: ZarfPackageConfig; phần còn lại dưới đây chỉ là minh họa tối giản, tên trường cần đối chiếu với trang Create a Package trước khi dùng:

kind: ZarfPackageConfig
metadata:
  name: ngan-hang-app
  version: 0.1.0
components:
  - name: app
    required: true
    images:
      - registry.example.com/backend:1.0.0
      - registry.example.com/frontend:1.0.0
    charts:
      - name: app-chart
        localPath: ./chart
        namespace: app
    manifests:
      - name: config
        files:
          - ./configmap.yaml

Chỗ dễ sai nhất là danh sách images: nó phải khớp với mọi image mà chart thật sự dùng. Build trên máy có mạng, bạn được một file archive duy nhất kèm SBOM.

File đó đi qua kênh mà khách cho phép để sang phía không có mạng. Theo hướng dẫn Getting Started, trên một cụm mới bạn chạy zarf init trước, rồi mới deploy package. Toàn bộ chuỗi lệnh khá ngắn (tên file chỉ là minh họa):

# Phía có mạng: build package từ zarf.yaml
zarf package create .

# Phía không có mạng, lần cài đầu trên cụm mới
zarf init
zarf package deploy <file-package-cua-ban>

Lệnh deploy cũng nhận package từ OCI registry. Ví dụ trong Getting Started cài package mẫu dos-games từ ghcr.io và truyền thêm cờ --key trỏ tới một public key để kiểm tra chữ ký package, đúng tinh thần kiểm tra trước khi tin.

Lợi ích lớn nhất là tính lặp lại. Lần nâng cấp sau, bạn sửa zarf.yaml, build rồi deploy lại theo đúng quy trình, thay vì làm lại bằng tay từng bước.

Giới hạn nào cần biết trước khi hứa với khách?

Rủi ro lớn nhất đến từ chính mô hình “mang theo hết”. Vì lúc deploy không kéo được gì thêm, quên một image hay một chart con là phải build lại và chuyển file lại từ đầu, qua đúng quy trình phê duyệt của khách.

Giới hạn kế tiếp là phạm vi. Zarf được thiết kế cho cụm Kubernetes và các workload cloud-native, nên nó phát huy tác dụng khi phía khách đã có hoặc sẽ dựng một cụm như vậy. Theo FAQ, Zarf cũng chạy được ở môi trường có mạng, nên bạn có thể dùng cùng một package cho cả môi trường thử nghiệm lẫn môi trường kín.

Bản thân Zarf là một binary biên dịch tĩnh bằng Go và Rust, không có phụ thuộc ngoài. Mang công cụ vào môi trường kín vì thế cũng đơn giản như mang package.

Ba lỗi nên tự kiểm trước khi file rời phía có mạng

Lỗi phổ biến nhất là khai thiếu image: chart kéo thêm một sidecar hay một image phụ mà zarf.yaml không ghi. Cách tự kiểm là deploy thử package lên một cụm kind đã chặn đường ra internet, rồi xem có pod nào kẹt ở trạng thái không kéo được image không.

Lỗi thứ hai là quên thứ tự: deploy package ứng dụng lên cụm chưa chạy zarf init. Hãy ghi bước này vào runbook giao cho khách, vì người vận hành phía họ có thể không biết.

Lỗi thứ ba là bỏ qua SBOM hoặc chữ ký cho nhanh. Thử hình dung buổi rà soát bảo mật: vài phút tiết kiệm lúc build có thể bị trả lại bằng nhiều ngày chờ duyệt, chỉ vì không ai trả lời được package chứa gì.

Nên học gì trước, và kể thế nào khi đi phỏng vấn?

Zarf miễn phí, cấp phép Apache-2.0, nhưng công cụ chỉ là lớp trên cùng. Trước khi đụng tới nó, bạn cần chắc tay với Helm, với cách image được kéo về node, và với OCI registry, vì đó chính là những thứ Zarf gói lại.

Khi đọc mô tả công việc FDE, hãy để ý các từ “air-gapped”, “on-prem”, “disconnected” hay khách hàng trong ngành quốc phòng, tài chính. Trong CV, đừng chỉ ghi “biết Zarf”: hãy viết rằng bạn đã đóng gói một ứng dụng thật, deploy nó vào cụm không có mạng, và đưa SBOM cho đội bảo mật duyệt.

Trong phỏng vấn, hãy kể theo trình tự: bạn liệt kê dependency ra sao, kiểm package trên cụm cô lập thế nào, và trả lời đội bảo mật bằng tài liệu gì. Người phỏng vấn muốn nghe bạn đã lường trước chỗ hỏng, không chỉ biết tên công cụ.

Ở khách hàng air-gap, bạn hiếm khi có cơ hội sửa lỗi lần thứ hai trong cùng một ngày. Một package được kiểm kỹ trước khi rời phía có mạng chính là cách giữ lời hứa với khách.