Build & Deploy

BuildConfig & ImageStream

BuildConfig คือ spec ที่บอกว่า "จะ build image ยังไง" (จาก source code → container image) — OpenShift จัดการ build pipeline ให้ทั้งหมดโดยไม่ต้องมี CI tool ภายนอก ImageStream คือ "ป้ายติดตาม" image ที่ build เสร็จแล้ว (คล้าย tag ใน container registry แต่ OpenShift จัดการ เพิ่มเติมให้)

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: my-app
spec:
  source:
    git:
      uri: https://github.com/org/myapp.git
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: 'nodejs:18'
  output:
    to:
      kind: ImageStreamTag
      name: 'my-app:latest'
  triggers:
    - type: ConfigChange
    - type: ImageChange

🧠 จำง่ายๆ

"BuildConfig = สูตรทำอาหาร, ImageStream = ป้ายติดจานที่ทำเสร็จแล้ว" — สูตรบอกวิธีทำ (จาก source code ไปเป็น image) ป้ายบอกว่าจานไหนทำเสร็จรอบล่าสุดคือจานอะไร (tracking image version ล่าสุดที่พร้อมเสิร์ฟ)

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

ImageStream ไม่ได้เก็บ image จริงๆ ไว้เอง — มันเก็บแค่ metadata ที่ชี้ไปยัง image ใน registry (internal OpenShift registry หรือ external เช่น Docker Hub/Quay) สิ่งที่ทรงพลัง คือ ImageStream รองรับ ImageChange trigger: ถ้า image ต้นทางที่ ImageStreamTag ชี้ไปมีการอัปเดต (เช่น base image nodejs:18 ถูก patch ความปลอดภัยใหม่) OpenShift จะ trigger build ใหม่ของทุก BuildConfig ที่ depend บน image นั้นโดยอัตโนมัติ — เป็นกลไกที่ ทำให้ application image ได้รับ security patch ของ base image แบบ cascade อัตโนมัติ โดยไม่ต้อง มีคนมา manual rebuild เอง เป็น feature ที่ CI/CD pipeline ภายนอกทั่วไปทำไม่ได้ง่ายๆ เพราะต้อง สร้างกลไก watch base image เองต่างหาก

Source-to-Image (S2I)

S2I คือ build strategy ที่ ไม่ต้องเขียน Dockerfile เอง — ให้ OpenChain ตรวจจับภาษา/ framework จาก source code อัตโนมัติ (เช่นเจอ package.json = Node.js) แล้วใช้ builder image ที่เตรียม build steps มาตรฐานไว้แล้วสร้าง image ให้

oc new-app nodejs:18~https://github.com/org/myapp.git

🧠 จำง่ายๆ

"S2I = เครื่องซักผ้าอัตโนมัติ, Dockerfile = ซักมือเอง" — S2I ใส่ผ้า (source code) เข้าเครื่อง แล้วกดปุ่มเดียวได้ผ้าสะอาด (image) โดยไม่ต้องรู้รายละเอียดการซัก เหมาะกับงานมาตรฐานทั่วไป แต่ ถ้าผ้าพิเศษที่ต้องซักเฉพาะวิธี (build process ซับซ้อน) ต้องซักมือเอง (เขียน Dockerfile เอง)

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

S2I builder image ไม่ใช่ "มายากล" — มันคือ container image ธรรมดาที่ implement script 2 ตัว ตาม convention ที่ S2I กำหนด: assemble (สั่งตอน build — เช่น npm install, compile) และ run (สั่งตอน container start จริง) ทำให้องค์กรที่มี framework/runtime เฉพาะทางที่ S2I official builder ไม่รองรับ สร้าง custom S2I builder image ของตัวเองได้ โดยแค่ implement 2 script นี้ตาม spec แล้ว publish เป็น builder image ให้ทีมอื่นใช้ oc new-app เรียกใช้ได้ เหมือน builder มาตรฐาน — เป็นความสามารถที่หลายทีมไม่รู้ว่าทำได้ เพราะคิดว่า S2I ใช้ได้แค่กับ framework ที่ Red Hat เตรียม builder ไว้ให้เท่านั้น

DeploymentConfig vs Deployment

DeploymentConfig (dc) คือ OpenShift-native deployment controller ที่เกิดก่อน Deployment ของ K8s มาตรฐาน — มี trigger-based rollout (ConfigChange, ImageChange) ที่ ผูกกับ ImageStream ได้โดยตรง แต่ OpenShift เวอร์ชันใหม่ แนะนำให้ใช้ Deployment มาตรฐานแทน เพื่อความเข้ากันได้ข้าม platform

	DeploymentConfig	Deployment
Rollout trigger	ConfigChange, ImageChange (ผูก ImageStream ได้ตรง)	manual apply เท่านั้น
Rollback	oc rollout undo dc/my-app + เก็บ ReplicationController history	kubectl rollout undo + ReplicaSet history
Portability	OpenShift เท่านั้น	ใช้ได้ทุก K8s distribution

🧠 จำง่ายๆ

"DeploymentConfig = รถที่ custom เฉพาะโรงงานเดียว, Deployment = รถมาตรฐานขับได้ทุกที่" — DeploymentConfig มี feature พิเศษที่ผูกกับ OpenShift เท่านั้น (เหมือนรถแต่งที่ซ่อมได้แค่อู่ เฉพาะ) ส่วน Deployment ใช้ได้ทุก K8s cluster ไม่ว่าจะเป็นค่ายไหน (เหมือนรถมาตรฐานที่ซ่อมได้ ทุกอู่)

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

เหตุผลเชิงลึกที่ Red Hat ผลักดันให้ย้ายจาก DeploymentConfig ไป Deployment ไม่ใช่แค่เรื่อง portability แต่เป็นเรื่อง scalability ของ control plane เอง: DeploymentConfig ใช้ ReplicationController (controller รุ่นเก่ากว่า ReplicaSet) เป็นกลไกข้างใต้ ซึ่งมี reconciliation loop ที่ synchronous และช้ากว่า ReplicaSet/Deployment ที่ K8s upstream optimize มาต่อเนื่องหลายปี cluster ที่มี DeploymentConfig จำนวนมากจะเห็น control plane ทำงานหนักกว่าที่ควร เทียบกับใช้ Deployment จำนวนเท่ากัน — เป็นเหตุผลทาง performance ที่จับต้องได้ ไม่ใช่แค่เหตุผลด้าน ecosystem compatibility อย่างเดียว

English Summary

BuildConfig defines how to build an image from source; ImageStream tracks built images via metadata pointers (not storing images itself) and supports ImageChange triggers that cascade- rebuild dependent BuildConfigs automatically when a base image updates — a security-patch propagation feature most external CI pipelines lack. Source-to-Image (S2I) builders are just container images implementing two conventions (assemble and run scripts), so teams can author custom S2I builders for unsupported frameworks rather than assuming only Red Hat-provided ones work. DeploymentConfig predates and is OpenShift-exclusive, with tighter ImageStream-triggered rollouts, but is built on the older ReplicationController (slower, synchronous reconciliation vs. ReplicaSet) — Red Hat's push toward standard Deployment is partly a control-plane scalability concern, not just portability.