GitLab 18+ Feature

GitLab CI/CD Components

สร้าง Pipeline แบบ Reusable ด้วย Components และ Catalog เลิก copy-paste YAML กันได้เลย

GitLab CI/CD Components Catalog Reusable

Architecture Overview / ภาพรวมสถาปัตยกรรม

GitLab CI/CD Components Architecture CI/CD Catalog gitlab.com/components Security secret-detection Build docker-build Deploy kubernetes Test unit-test Your Project .gitlab-ci.yml include: component: ... Components จาก Catalog → Include ใน Project → Pipeline ทำงาน

1 บทนำ - GitLab CI/CD Components คืออะไร

GitLab CI/CD Components คือ reusable units ของ CI/CD configuration ที่สามารถนำกลับมาใช้ใหม่ได้ในหลายๆ project โดยไม่ต้อง copy-paste YAML ซ้ำๆ เป็น feature ใหม่ใน GitLab 16+ และปรับปรุงมากขึ้นใน GitLab 18+

Component คืออะไร

เป็น single YAML file ที่อยู่ในโฟลเดอร์ templates/ ของ project ประกอบด้วย jobs, scripts, variables ที่สามารถ reuse ได้

Catalog คืออะไร

เป็น centralized registry ของ components ที่คุณสามารถค้นหา, browse และ include เข้ามาใช้ใน project ของคุณได้

ประโยชน์หลัก

  • DRY Principle - ไม่ต้อง repeat code ซ้ำ
  • Easy Maintenance - แก้ไขที่เดียว ใช้ได้ทุกที่
  • Version Control - จัดการ version ได้ชัดเจน
  • Share & Reuse - แชร์ระหว่างทีมหรือ public ได้

2 ทำไมต้องใช้ Components (แทน copy-paste YAML)

ปัญหาใหญ่ของการทำ CI/CD แบบดั้งเดิมคือการ copy-paste YAML ระหว่าง projects ทำให้เกิดปัญหาตามมามากมาย

❌ Before: Copy-Paste YAML Project A .gitlab-ci.yml Project B .gitlab-ci.yml Project C .gitlab-ci.yml Problems: • แก้ไขทุกที่เมื่อ update • Version ไม่ตรงกัน • งานซ้ำซ้อน Migrate ✅ After: Use Components Component Repo templates/*.yml Project A include Project B include Project C include Benefits: • แก้ไขที่เดียว ใช้ได้ทุกที่ • Version control ชัดเจน • ง่ายต่อ maintenance
Copy-Paste

50 projects = แก้ 50 ครั้ง

Components

50 projects = แก้ 1 ครั้ง

Efficiency

ลดเวลา 80%

3 การสร้าง Component ของตัวเอง

การสร้าง Component ต้องมีโครงสร้างโฟลเดอร์ที่ถูกต้องและ syntax เฉพาะ

โครงสร้างโฟลเดอร์

my-component-project/
├── templates/
│   ├── secret-detection.yml      # Component 1
│   ├── docker-build.yml          # Component 2
│   └── deploy-k8s.yml            # Component 3
├── README.md                      # Documentation
└── .gitlab-ci.yml                 # Test pipeline

ตัวอย่าง Component File

# templates/docker-build.yml
# ระบุ spec สำหรับ inputs
spec:
  inputs:
    stage:
      default: build
      description: "Stage ที่จะ run job"
    image-name:
      default: $CI_REGISTRY_IMAGE
      description: "ชื่อ Docker image"
    dockerfile:
      default: Dockerfile
      description: "Path ไป Dockerfile"
    tags:
      default: ["docker"]
      type: array
      description: "Runner tags"

---
# Component implementation
build-image:
  stage: $[[ inputs.stage ]]
  image: docker:24
  services:
    - docker:24-dind
  tags: $[[ inputs.tags ]]
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $[[ inputs.image-name ]]:$CI_COMMIT_SHA -f $[[ inputs.dockerfile ]] .
    - docker push $[[ inputs.image-name ]]:$CI_COMMIT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

สิ่งสำคัญ: Component file ต้องขึ้นต้นด้วย spec: block และมี --- separator ก่อน implementation

4 CI/CD Catalog - ค้นหาและใช้งาน

CI/CD Catalog เป็น centralized place สำหรับค้นหาและใช้ components ที่คนอื่นสร้างไว้ สามารถเข้าถึงได้ที่ gitlab.com/explore/catalog

1. Browse Catalog 🔍 2. Select Component 3. Include in Pipeline 4. Run Pipeline 🚀 gitlab.com/explore/catalog → เลือก Component → Copy include snippet → Paste ใน .gitlab-ci.yml

วิธีใช้ Component จาก Catalog

# .gitlab-ci.yml
include:
  # Include component จาก GitLab Catalog
  - component: $CI_SERVER_FQDN/components/secret-detection@1.0.0
    inputs:
      stage: security
      
  # Include component จาก private project
  - component: $CI_SERVER_FQDN/my-org/shared-components/docker-build@2.1.0
    inputs:
      stage: build
      image-name: $CI_REGISTRY_IMAGE/app
      dockerfile: Dockerfile.prod

stages:
  - security
  - build
  - test
  - deploy
Public Catalog

Components จาก GitLab และ community ที่เข้าถึงได้ฟรี

Private Catalog

Components ภายในองค์กรที่ share ระหว่าง projects

5 Component Inputs และ Parameters

Inputs ทำให้ components มีความยืดหยุ่น สามารถปรับแต่งได้ตามความต้องการของแต่ละ project

ประเภทของ Inputs

# templates/deploy.yml
spec:
  inputs:
    # String input พร้อม default
    stage:
      default: deploy
      description: "Stage name for deployment"
      
    # String ที่จำเป็นต้องระบุ
    environment:
      description: "Target environment (required)"
      
    # Array input
    tags:
      type: array
      default: ["kubernetes"]
      
    # Boolean input
    enable-cache:
      type: boolean
      default: true
      
    # Number input
    replicas:
      type: number
      default: 2
      
    # Options (enum)
    strategy:
      type: string
      options:
        - rolling
        - blue-green
        - canary
      default: rolling

---
deploy:
  stage: $[[ inputs.stage ]]
  tags: $[[ inputs.tags ]]
  script:
    - kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - kubectl scale deployment/app --replicas=$[[ inputs.replicas ]]
  environment:
    name: $[[ inputs.environment ]]

การใช้งาน Inputs

# .gitlab-ci.yml ของ project ที่ใช้ component
include:
  - component: $CI_SERVER_FQDN/my-org/deploy-component@1.0.0
    inputs:
      stage: deploy-prod
      environment: production
      replicas: 5
      strategy: blue-green
      tags:
        - kubernetes
        - production
      enable-cache: false

Tip: ใช้ $[[ inputs.name ]] syntax เพื่ออ้างถึง input values ใน component

7 Best Practices

1
Semantic Versioning

ใช้ semantic versioning (1.0.0, 1.1.0, 2.0.0) สำหรับ components เพื่อให้ผู้ใช้สามารถ lock version ได้

# แนะนำ: lock version
- component: .../my-component@1.2.3

# หรือใช้ major version only
- component: .../my-component@1

# หลีกเลี่ยง: ไม่ lock version
- component: .../my-component  # อันตราย!
2
Documentation ครบถ้วน

เขียน README.md ที่อธิบาย inputs, outputs, และตัวอย่างการใช้งาน

3
Default Values

กำหนด default values สำหรับ inputs ที่ไม่จำเป็นต้องระบุ เพื่อให้ใช้งานง่าย

4
Test Components

สร้าง test pipeline ใน component project เพื่อทดสอบว่า component ทำงานถูกต้อง

5
Single Responsibility

แต่ละ component ควรทำหน้าที่เดียว เช่น build, test, deploy แยกกัน

8 การใช้งานในองค์กรไทย

สำหรับองค์กรในประเทศไทย สามารถประยุกต์ใช้ Components ได้หลายแบบ

องค์กรไทย - Thai Organization Shared Components company/components • thaicompliance-check • line-notify Team A E-commerce include components Team B Mobile App include components Team C Backend ประโยชน์สำหรับองค์กรไทย ✓ มาตรฐานเดียวกันทั้งองค์กร • ✓ ลดเวลาพัฒนา • ✓ Audit ง่าย • ✓ PDPA Compliance

ตัวอย่าง Components สำหรับองค์กรไทย

# templates/line-notify.yml - ส่ง notification ไป LINE
spec:
  inputs:
    stage:
      default: notify
    message:
      description: "ข้อความที่จะส่ง"
    token-variable:
      default: LINE_NOTIFY_TOKEN
      description: "Environment variable ที่เก็บ token"

---
notify-line:
  stage: $[[ inputs.stage ]]
  image: curlimages/curl
  script:
    - |
      curl -X POST https://notify-api.line.me/api/notify \
        -H "Authorization: Bearer ${$[[ inputs.token-variable ]]}" \
        -d "message=$[[ inputs.message ]]"
  rules:
    - when: on_success
ทำไมต้องมี
  • • มาตรฐานเดียวกัน
  • • สอบบัญชีง่าย
  • • PDPA compliant
ตัวอย่าง
  • • line-notify
  • • thaicompliance-check
  • • slack-thai-msg
เริ่มต้น
  • • สร้าง shared repo
  • • เขียน components
  • • Share ทั้งองค์กร

9 Troubleshooting / แก้ไขปัญหาที่พบบ่อย

Component not found

สาเหตุ: Path หรือ version ไม่ถูกต้อง

# ตรวจสอบ format
- component: $CI_SERVER_FQDN/group/project/component-name@version

# ตัวอย่างที่ถูกต้อง
- component: gitlab.com/my-org/components/docker-build@1.0.0
Input validation error

สาเหตุ: Input type ไม่ตรงกับที่กำหนด

# ผิด: number input รับ string
replicas: "5"  # ❌

# ถูก: number input รับ number
replicas: 5    # ✓
Permission denied

สาเหตุ: ไม่มีสิทธิ์เข้าถึง component project

แก้ไข: ตรวจสอบว่า CI/CD token มีสิทธิ์ read หรือเพิ่ม project เป็น allowed project

Component conflicts

สาเหตุ: หลาย components ใช้ชื่อ job เดียวกัน

# แก้ไข: ใช้ input เพื่อ override job name
include:
  - component: .../docker-build@1.0.0
    inputs:
      job-name: build-api
      
  - component: .../docker-build@1.0.0
    inputs:
      job-name: build-worker
Debug Tips
  • ใช้ CI_DEBUG_TRACE: "true" เพื่อดู full pipeline debug
  • ตรวจสอบ component ใน GitLab UI → CI/CD → Editor
  • ใช้ include: local เพื่อ test component ก่อน publish

สรุป

สิ่งที่เรียนรู้
  • ✅ Component คืออะไร และทำไมต้องใช้
  • ✅ การสร้าง Component ของตัวเอง
  • ✅ การใช้งาน CI/CD Catalog
  • ✅ Inputs และ Parameters
  • ✅ Best Practices
  • ✅ การประยุกต์ใช้ในองค์กรไทย
ข้อมูลเพิ่มเติม