Skip to main content

OpenShift Best Practices & Code Review Checklist

Template / Helm บน OpenShift​

OpenShift มีระบบ Template ของตัวเอง (พารามิเตอร์ไซส์ YAML แบบ native ก่อน Helm จะแพร่หลาย) แต่ปัจจุบัน Helm คือมาตรฐานที่แนะนำ (OpenShift 4.x รองรับ Helm เต็มรูปแบบ มี Helm chart catalog ใน web console ด้วย) — Template ยังมีให้ใช้เพื่อ backward compatibility กับระบบเก่า

helm install my-app ./chart -n my-team     # วิธีมาตรฐานที่แนะนำปัจจุบัน
oc process -f template.yaml | oc apply -f -  # วิธีเก่าแบบ OpenShift Template
🧠 จำง่ายๆ

"Template = ภาษาถิ่นเก่า, Helm = ภาษากลางที่ทุกคนเข้าใจ" — Template ใช้ได้แค่บน OpenShift เท่านั้น (เหมือนภาษาถิ่นที่คนนอกพื้นที่ไม่เข้าใจ) ส่วน Helm ใช้ได้ทุก K8s distribution (ภาษา กลางที่สื่อสารข้าม platform ได้) ทีมใหม่ควรเริ่มจาก Helm เสมอ

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

Template มี feature หนึ่งที่ Helm ไม่มี built-in มาให้โดยตรง: generate: expression ใน parameter ที่สร้างค่าสุ่ม/unique ได้ในตัว (เช่น generate password แบบสุ่มตอน process template โดยไม่ต้องพึ่ง external tool) ทำให้ oc process เหมาะกับ use case ที่ต้องการสุ่มค่า secret ใหม่ทุกครั้งที่ deploy instance ใหม่ (เช่น demo environment ที่ spin up เยอะๆ) ได้ง่าย กว่า Helm ที่ต้องพึ่ง lookup function หรือ pre-install hook เขียนเพิ่มเองถึงจะทำแบบเดียวกัน ได้ — เป็นเหตุผลเดียวที่บางทีมยังคง maintain Template คู่ไปกับ Helm สำหรับ use case เฉพาะนี้ แม้จะ migrate ส่วนใหญ่ไป Helm แล้วก็ตาม

Resource Quota ระดับ Project​

ResourceQuota และ LimitRange ของ K8s ใช้ได้ปกติบน OpenShift แต่ OpenShift เพิ่ม multi-project quota (ClusterResourceQuota) ที่ K8s เปล่าไม่มี — จำกัด resource รวม ข้ามหลาย project พร้อมกันได้ (เช่น "ทีม A ใช้ได้รวมไม่เกิน 50 core ไม่ว่าจะกระจายกี่ project ก็ตาม")

apiVersion: quota.openshift.io/v1
kind: ClusterResourceQuota
metadata:
  name: team-a-quota
spec:
  selector:
    annotations:
      openshift.io/requester: team-a
  quota:
    hard:
      requests.cpu: "50"
      requests.memory: 100Gi
🧠 จำง่ายๆ

"ResourceQuota = งบประมาณต่อแผนก, ClusterResourceQuota = งบประมาณรวมทั้งบริษัทไม่ว่าจะมีกี่ แผนกย่อย" — K8s เปล่าคุมได้แค่ระดับ namespace เดียว ถ้าทีมมีหลาย namespace (หลาย project) ต้องตั้ง quota แยกทุก namespace เอง ส่วน OpenShift คุมรวมได้ทีเดียวข้าม project ทั้งหมดของทีม

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

ClusterResourceQuota ใช้ label/annotation selector เลือก project ที่จะนับรวม (ไม่ใช่ ระบุชื่อ project ตรงๆ ทีละตัว) หมายความว่าถ้าทีมสร้าง project ใหม่แล้วแปะ annotation openshift.io/requester: team-a ตามที่ quota กำหนดไว้ project ใหม่นั้นจะถูกนับรวมเข้า quota เดิมโดยอัตโนมัติทันที โดยไม่ต้องไปแก้ ClusterResourceQuota object เลย — เป็นกลไกที่ scale ได้ดีมากสำหรับองค์กรที่ทีมสร้าง project ใหม่บ่อยๆ (self-service project creation) เพราะ admin ตั้ง policy ไว้ครั้งเดียว แล้ว project ใหม่ที่ตรงเงื่อนไขก็ถูกคุม quota อัตโนมัติโดย ไม่ต้องมานั่งตามแก้ quota ทุกครั้งที่มี project ใหม่เกิดขึ้น

Code Review Checklist​

  • Dockerfile รองรับ arbitrary UID (chgrp 0 + chmod g=u สำหรับไฟล์ที่ต้องเขียนได้) — ไม่ hardcode ให้รันเป็น root
  • ใช้ Deployment แทน DeploymentConfig สำหรับโปรเจกต์ใหม่ (portability + performance)
  • Route มี TLS termination ที่เหมาะสม (edge เป็น default ที่ดีสำหรับส่วนใหญ่)
  • ไม่ขอ SCC ที่กว้างกว่า restricted โดยไม่มีเหตุผลชัดเจน (เช่น ขอ anyuid เพราะ "ขี้เกียจ แก้ Dockerfile" ไม่ใช่เหตุผลที่ดีพอ)
  • BuildConfig มี ImageChange trigger ถ้าต้องการ auto-rebuild ตาม base image update
  • ตั้ง ClusterResourceQuota ถ้าทีมมีหลาย project เพื่อคุม resource รวมไม่ให้บานปลาย
English Summary

Helm is the recommended templating approach on modern OpenShift over native Template/ oc process, though Templates retain one niche advantage: built-in generate: expression for random value generation without extra tooling. ClusterResourceQuota extends resource limits across multiple Projects via label/annotation selectors — new matching projects are automatically pulled under existing quota without manual edits, which scales well for self- service project creation. Review checklist: Dockerfiles should support arbitrary UIDs rather than assuming root, prefer Deployment over DeploymentConfig for new work, avoid requesting broader SCCs than restricted without real justification, and set ClusterResourceQuota for teams spanning multiple projects.