هر تیم application یک Dockerfile دارد — یا بدتر: کپی از Dockerfile همکار که «کار می‌کرد». نسخه base image قدیمی، RUN apt-get بدون patch، secret در layer، و کسی نمی‌داند داخل image چه هست.

Cloud Native Buildpacks (CNB) رویکرد دیگری است:

Transform your application source code into images that can run on any cloud.

یعنی buildpackها — نه developer — تصمیم می‌گیرند چگونه dependency نصب، compile، و لایه‌های image ساخته شوند. platform team یک builder تأییدشده تعریف می‌کند؛ developer فقط pack build یا git push می‌زند.

پروژه CNCF Graduated (۲۰۲۶) — از ریشه Pivotal و Heroku (۲۰۱۸) تا امروز با Paketo، Google، Salesforce و صدها سازمان enterprise.

مشکل Dockerfile-per-app

Developer A:  FROM node:14        ← EOL
Developer B:  FROM node:20-alpine ← OK
Developer C:  COPY . . && npm i   ← layer بزرگ، cache شکسته
Platform:     «همه image را scan کنید» → 400 Dockerfile متفاوت

CNB دانش build را در buildpack + builder متمرکز می‌کند — یک بار upgrade، همه appها به‌روز.

Cloud Native Buildpacks چیست؟

Cloud Native Buildpacks شامل:

• Specification — Platform API، Buildpack API، Distribution API (github.com/buildpacks/spec)
• Lifecycle — موتور فازهای build
• pack — CLI مرجع برای developer و operator
• Registry — کشف buildpackهای community (registry.buildpacks.io)
• Integrations — kpack، Tekton، GitLab Auto DevOps، CircleCI orb

سه نقش (persona)

چرا CNB؟ (از buildpacks.io)

معماری: از source به OCI image

نمای کلی

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│ App Source  │ ──► │  Platform    │ ──► │  OCI Image  │
│ (git/local) │     │ pack / kpack │     │  (registry) │
└─────────────┘     └──────┬───────┘     └─────────────┘
                           │
                    ┌──────▼───────┐
                    │   Builder    │
                    │ = stack +    │
                    │   buildpacks │
                    └──────┬───────┘
                           │
                    ┌──────▼───────┐
                    │  Lifecycle   │
                    │  (phases)    │
                    └──────────────┘

مفاهیم کلیدی

Lifecycle phases

طبق مستندات lifecycle:

Platform می‌تواند /cnb/lifecycle/creator را یک‌جا صدا بزند یا هر فاز را جدا — برای CI بدون Docker daemon (مثل GitLab K8s runner).

pack CLI — شروع سریع

نصب: install-pack

# ساخت image از سورس محلی
pack build my-app \
  --builder paketobuildpacks/builder-jammy-base \
  --path ./my-node-app

# اجرا
docker run -p 8080:8080 my-app

Builderهای رایج

Detect خودکار

Buildpackها فایل‌های marker را چک می‌کنند:

• package.json → Node.js buildpack
• pom.xml / build.gradle → Java
• requirements.txt / pyproject.toml → Python
• go.mod → Go

Developer زبان را declare نمی‌کند — detect می‌کند.

مثال: Node.js بدون Dockerfile

mkdir hello-cnb && cd hello-cnb

cat > package.json << 'EOF'
{
  "name": "hello-cnb",
  "scripts": { "start": "node server.js" }
}
EOF

cat > server.js << 'EOF'
const http = require('http');
http.createServer((_, res) => {
  res.end('Hello from Cloud Native Buildpacks!');
}).listen(process.env.PORT || 8080);
EOF

pack build hello-cnb \
  --builder paketobuildpacks/builder-jammy-base \
  --env BP_NODE_VERSION=20

docker run -p 8080:8080 hello-cnb

Buildpack:

1. Node engine نصب می‌کند
2. npm install (یا npm ci با lockfile)
3. launch process web = npm start تعریف می‌کند
4. image با non-root user و minimal run image export می‌شود

تنظیم build با environment variables

Paketo و buildpackهای دیگر با prefix BP_* configure می‌شوند:

pack build my-java-app \
  --builder paketobuildpacks/builder-jammy-base \
  --env BP_JVM_VERSION=21 \
  --env BP_MAVEN_BUILD_ARGUMENTS="-Dmaven.test.skip=true"

برای lifecycle مستقیم (بدون pack)، متغیرها در platform/env/ فایل می‌شوند (راهنما).

kpack — CNB روی Kubernetes

kpack پیاده‌سازی Kubernetes-native است:

• CRD: Image، Builder، ClusterBuilder، ClusterStore
• build بدون privileged Docker — با unprivileged K8s primitives
• rebuild خودکار وقتی git commit یا builder عوض شود

apiVersion: kpack.io/v1alpha2
kind: Image
metadata:
  name: my-app
  namespace: default
spec:
  tag: registry.example.com/my-app
  serviceAccountName: kpack-service-account
  builder:
    name: default-builder
    kind: ClusterBuilder
  source:
    git:
      url: https://github.com/org/my-app.git
      revision: main

مناسب platform operator که می‌خواهد هر namespace با builder استاندارد سازمان image بسازد.

یکپارچه‌سازی CI/CD

از مستندات buildpacks.io:

جریان GitOps (Argo CD):

git push → CI (pack/kpack) → push image to registry
                            → update manifest tag در GitOps repo
                            → Argo CD sync

Buildpack vs Dockerfile vs Kaniko

CNB برنده می‌شود وقتی صدها app مشابه (Java/Node/Python) دارید و platform team می‌خواهد policy یکسان.

Dockerfile برنده می‌شود وقتی app عجیب، multi-stage پیچیده، یا binary custom دارید.

چه زمانی CNB استفاده کنیم؟

✅ مناسب

• Platform team با ده‌ها/صدها microservice
• استاندارد Java / Node / Python / Go enterprise
• Patch امنیتی متمرکز — upgrade builder = همه appها
• Heroku-style developer experience روی K8s
• CI بدون Docker socket (lifecycle در container)
• Reproducible build و audit

❌ کمتر مناسب

برای سایت‌های static مثل P30Light (Astro) معمولاً build در CI + copy به nginx ساده‌تر از CNB است — CNB برای application server (Node/Java/…) shine می‌کند.

امنیت و compliance

• Non-root run image در builderهای مدرن (Paketo)
• Minimal run image — فقط runtime لازم (JRE نه JDK، مگر configure)
• Rebase — pack rebase برای swap run image بدون rebuild کامل
• SBOM — Paketo با Syft integration
• Scanner — image قابل پیش‌بینی → Trivy/Grype مؤثرتر
• Provenance — build reproducible از builder pin شده

Operator می‌تواند فقط builderهای internal registry را allow کند — developer نمی‌تواند FROM random/image بزند.

نوشتن buildpack سفارشی

برای زبان یا framework داخلی: How to write a basic buildpack

خلاصه:

1. detect — آیا این buildpack روی app اعمال می‌شود؟
2. build — dependency + compile
3. export — layer به contribution

سپس در builder.toml به builder اضافه کنید و publish به registry داخلی.

عملیات روزمره

# لیست builderهای local
pack builder suggest

# inspect builder
pack inspect-builder paketobuildpacks/builder-jammy-base

# build با cache
pack build my-app --builder paketobuildpacks/builder-jammy-base --path .

# rebase پس از patch OS
pack rebase my-app:latest --run-image paketobuildpacks/run-jammy-base:latest

# pull و update builder
pack builder pull paketobuildpacks/builder-jammy-base

CNB در کنار stack مدرن

Developer git push
       │
       ▼
┌──────────────┐     ┌─────────────┐     ┌──────────────┐
│ kpack / pack │ ──► │  Registry   │ ──► │ Kubernetes   │
│  (CNB build) │     │ (Harbor/ECR)│     │ Deployment   │
└──────────────┘     └─────────────┘     └──────────────┘
       ▲                                        │
       │         GitOps (Argo CD)               │
       └──────── manifest tag update ◄──────────┘

• شبکه pod: Kube-OVN
• runtime امن: Kata Containers (اختیاری)
• CI workflow: Argo Workflows

جمع‌بندی

Cloud Native Buildpacks برای سازمان‌هایی است که developer velocity می‌خواهند ولی control، compliance و maintainability را قربانی نمی‌کنند — همان وعده Heroku، حالا OCI-standard و CNCF Graduated روی هر cloud.

قدم بعدی

1. pack نصب کنید و tutorial رسمی را بزنید
2. یک app Node/Java با paketobuildpacks/builder-jammy-base build کنید
3. pack inspect-image — ببینید launch process و layerها چیست
4. در staging kpack نصب کنید و Image CRD تست کنید
5. builder سازمانی pin کنید — developer فقط از همان builder استفاده کند

منابع:

• Cloud Native Buildpacks — Official Site
• Documentation
• App Journey Tutorial
• Lifecycle Tutorial
• pack CLI (GitHub)
• kpack (Kubernetes)
• Paketo Buildpacks
• Buildpack Registry
• CNCF Specification

منتشر شده در P30Light — بخش زیرساخت سرور و Cloud Native.