GitLab — พื้นฐาน, คุณสมบัติ และ CI/CD

GitLab คืออะไร?

GitLab — เป็นแพลตฟอร์ม DevOps โอเพนซอร์สแบบครบวงจรภายใต้สัญญาอนุญาต MIT แตกต่างจาก GitHub ที่รวมบริการต่างๆ ผ่านการผสานรวม GitLab มอบเครื่องมือเดียวสำหรับวงจรชีวิตการพัฒนาทั้งหมด ตั้งแต่การจัดการโค้ดและการตรวจสอบโค้ด ไปจนถึง CI/CD การตรวจสอบ ความปลอดภัย และการปรับใช้ แพลตฟอร์มไม่ต้องการบริการของบุคคลที่สามสำหรับงาน DevOps ส่วนใหญ่

ประวัติของ GitLab เริ่มต้นในปี 2011 ในฐานะโปรเจกต์ภายในของนักพัฒนาชาวยูเครน เวอร์ชันสาธารณะแรกเปิดตัวในเดือนกันยายน 2011 และในปี 2015 GitLab กลายเป็นโปรเจกต์แรกบน GitLab.com โดยเปิดให้บริการโฮสติ้งบนคลาวด์ ในปี 2017 GitLab ได้ดำเนินการโยกย้ายที่เจ็บปวดแต่ให้บทเรียน — การย้ายโครงสร้างพื้นฐานทั้งหมดจาก Azure ไปยัง Google Cloud ซึ่งดำเนินการถ่ายทอดสดและบันทึกไว้ในชุดโพสต์บล็อก

สถาปัตยกรรมของ GitLab ประกอบด้วยสามองค์ประกอบหลัก: GitLab Rails (เว็บแอปพลิเคชันบน Ruby on Rails), GitLab Shell (จัดการการดำเนินการ Git ผ่าน SSH) และ Gitaly (เซิร์ฟเวอร์ gRPC สำหรับเข้าถึงข้อมูล Git) CI/CD จัดเตรียมผ่าน GitLab Runner — แอปพลิเคชันแยกต่างหากที่ติดตั้งบนเซิร์ฟเวอร์ build และดำเนินการ job ในสภาพแวดล้อมที่ แยกออกจากกัน (Docker, Kubernetes, VirtualBox)

GitLab CI/CD: ไปป์ไลน์และรันเนอร์

GitLab CI/CD — เป็นระบบรวมและส่งมอบอย่างต่อเนื่องในตัวซึ่งเป็นข้อได้เปรียบหลักของแพลตฟอร์ม แตกต่างจาก GitHub Actions GitLab CI/CD ถูกสร้างไว้ในสถาปัตยกรรมตั้งแต่เริ่มต้นและไม่ต้องการการตั้งค่าแยกต่างหาก: ทุกโปรเจกต์จะได้รับ CI/CD โดยอัตโนมัติหลังจากเพิ่มไฟล์ .gitlab-ci.yml ในรูทของรีปอซิทอรี

ไปป์ไลน์ประกอบด้วยสเตจที่ทำงานตามลำดับหรือขนานกัน: build → test → deploy แต่ละสเตจประกอบด้วย job หนึ่งรายการขึ้นไปที่ทำงานบนรันเนอร์ หาก job ในสเตจใดล้มเหลว สเตจทั้งหมดจะถูกทำเครื่องหมายว่าล้มเหลว และสเตจถัดไปจะไม่ทำงานตามค่าเริ่มต้น ด้านล่างนี้คือตัวอย่างไปป์ไลน์สำหรับโปรเจกต์มือถือ:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner รองรับ executor หลายประเภท: Docker (แนะนำ), Kubernetes, SSH, VirtualBox และ Parallels ตัวเลือกที่ได้รับความนิยมมากที่สุดคือ Docker executor ซึ่งรันแต่ละ job ในคอนเทนเนอร์แยกต่างหาก รันเนอร์สามารถลงทะเบียนเป็นแบบเฉพาะสำหรับโปรเจกต์เดียวหรือแบบใช้ร่วมกัน (shared) สำหรับทั้งกลุ่ม GitLab.com มีรันเนอร์ใช้ร่วมกันฟรีโดยจำกัดที่ 2000 นาที ต่อเดือน

คุณสมบัติขั้นสูงของ CI/CD

GitLab CI/CD รองรับการเรียกใช้ด้วยตนเอง (when: manual), การเรียกใช้แบบหน่วงเวลา (when: delayed), การทำงานขนาน (parallel: 5), เมทริกซ์, ไปป์ไลน์แบบไดนามิก (child pipelines) และไปป์ไลน์หลายระดับ (parent-child) ซึ่งช่วยให้สร้างสถานการณ์ที่ซับซ้อนได้: ตัวอย่างเช่น สร้างไปป์ไลน์แบบไดนามิกสำหรับแต่ละโมดูลใน monorepo หรือรัน build ขนานสำหรับสถาปัตยกรรม Android ต่างๆ (arm64, x86_64)

GitLab vs GitHub: ความแตกต่างหลัก

GitLab และ GitHub — เป็นคู่แข่งหลักสองรายในตลาดแพลตฟอร์ม Git แต่ปรัชญาและสถาปัตยกรรมของทั้งคู่แตกต่างกันโดยพื้นฐาน GitHub มุ่งเน้นชุมชนเปิด ระบบนิเวศของการผสานรวม และคุณสมบัติทางสังคม (fork, star) GitLab มุ่งเน้นวงจร DevOps ที่ครอบคลุมและมอบเครื่องมือทั้งหมดพร้อมใช้งานทันที ตั้งแต่การวางแผนจนถึงการตรวจสอบ

ความแตกต่างทางสถาปัตยกรรมหลัก: GitLab — เป็นแอปพลิเคชันแบบเสาหินเดียวที่นักพัฒนาติดตั้งทั้งชุด คุณสมบัติทั้งหมด (CI/CD, Container Registry, Security Scanning, Pages) ถูกสร้างในตัวและทำงานทันทีหลังจากติดตั้ง GitHub เป็นแพลตฟอร์มที่มี API ซึ่งคุณสมบัติส่วนใหญ่ถูกนำไปใช้ผ่านการผสานรวมกับบริการของบุคคลที่สาม: Travis CI, CircleCI, Jenkins, SonarQube ตารางด้านล่างเปรียบเทียบคุณลักษณะสำคัญ:

การเลือกระหว่าง GitLab และ GitHub ขึ้นอยู่กับความต้องการของทีม หากลำดับความสำคัญคือการปรับใช้รวดเร็วโดยไม่ต้องกำหนดค่าและชุมชนเปิด — เลือก GitHub หากคุณต้องการควบคุมโครงสร้างพื้นฐานอย่างเต็มที่ โฮสต์ด้วยตนเอง และความปลอดภัยในตัว — GitLab เหมาะกว่า ตามการสำรวจของ Stack Overflow (2024) นักพัฒนา 90% ใช้ GitHub, 33% ใช้ GitLab (มักใช้ทั้งสองแพลตฟอร์มพร้อมกัน)

Self-Managed GitLab: การติดตั้งบนเซิร์ฟเวอร์ของคุณเอง

Self-Managed GitLab (เดิมคือ On-Premises) ช่วยให้คุณติดตั้งแพลตฟอร์มบนเซิร์ฟเวอร์ของคุณเองและควบคุมข้อมูล โครงสร้างพื้นฐาน และเวลาทำงานได้อย่างเต็มที่ ซึ่งสำคัญอย่างยิ่งสำหรับองค์กรที่มีข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ: ภาคการเงิน สถาบันรัฐบาล องค์กรทางการแพทย์ที่ไม่สามารถเก็บข้อมูลบนเซิร์ฟเวอร์ของบุคคลที่สาม

การติดตั้ง GitLab รองรับบน Ubuntu, Debian, CentOS และผ่าน Docker แพ็คเกจ Omnibus อย่างเป็นทางการประกอบด้วยส่วนประกอบทั้งหมด: เว็บเซิร์ฟเวอร์ (NGINX), ฐานข้อมูล (PostgreSQL), แคช (Redis), ตัวจัดการ Git (Gitaly) และกระบวนการพื้นหลัง ข้อกำหนดขั้นต่ำ: RAM 4 GB และ CPU 2 ตัวสำหรับทีมสูงสุด 100 คน สำหรับการติดตั้งขนาดใหญ่ที่มีโหลดสูง แนะนำให้ แยก ส่วนประกอบไปยังเซิร์ฟเวอร์ต่างๆ

# การติดตั้ง GitLab CE บน Ubuntu ผ่าน Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# การติดตั้งแพ็คเกจ
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# การดูสถานะ
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab ไม่มีข้อจำกัดด้านนาที CI/CD — รันเนอร์ทั้งหมดเป็นขององค์กร และพลังของมันถูกจำกัดโดยฮาร์ดแวร์ของคุณเองเท่านั้น นอกจากนี้ยังมี การจำลองแบบภูมิศาสตร์ (Geo-replication) สำหรับภูมิภาค บันทึกการตรวจสอบ การบล็อก IP และการผสานรวมกับผู้ให้บริการ LDAP/SAML ขององค์กร GitLab เผยแพร่อัปเดตทุกเดือน (วันที่ 22) พร้อมคุณสมบัติใหม่และการแก้ไขความปลอดภัย

เครื่องมือความปลอดภัยในตัวของ GitLab

ความปลอดภัยใน GitLab ถูกสร้างในระดับแพลตฟอร์มและรวมสแกนเนอร์หลายตัวที่ทำงานในทุกขั้นตอนของไปป์ไลน์ SAST (Static Application Security Testing) วิเคราะห์ซอร์สโค้ดเพื่อหาช่องโหว่โดยไม่ต้องรันแอปพลิเคชัน รองรับมากกว่า 15 ภาษา รวมถึง Java, Kotlin, Swift, Python และ JavaScript DAST (Dynamic Application Security Testing) ทดสอบเว็บแอปพลิเคชันที่กำลังทำงานเพื่อหาช่องโหว่จากภายใน

เครื่องมือเพิ่มเติม: Container Scanning ตรวจสอบ Docker images เพื่อหาช่องโหว่ในเลเยอร์พื้นฐาน; Dependency Scanning วิเคราะห์ dependencies ของโปรเจกต์และเตือนเกี่ยวกับ CVE ที่ทราบ; Secret Detection ค้นหาคีย์ API, รหัสผ่าน และโทเค็นที่ถูก commit โดยไม่ตั้งใจ; Fuzz Testing ทำการทดสอบอัตโนมัติด้วยข้อมูลที่ไม่ถูกต้องเพื่อค้นหาข้อบกพร่องที่ไม่ชัดเจน ผลการสแกนทั้งหมดแสดงในแดชบอร์ดความปลอดภัยแบบรวม

GitLab ยังมีเครื่องมือ การปฏิบัติตามข้อกำหนด (Compliance) สำหรับตอบสนองความต้องการด้านกฎระเบียบ แดชบอร์ดการปฏิบัติตามข้อกำหนดแสดงสถานะการปฏิบัติตามของทุกโปรเจกต์ เหตุการณ์การตรวจสอบบันทึกทุกการกระทำของผู้ดูแลระบบและนักพัฒนา และกรอบการปฏิบัติตามข้อกำหนดอนุญาตให้บังคับใช้นโยบายการกำหนดค่าสำหรับกลุ่มโปรเจกต์เฉพาะ ทำให้ GitLab เป็นตัวเลือกยอดนิยมในสภาพแวดล้อม องค์กร ที่มีข้อกำหนดด้านความปลอดภัยที่เข้มงวด

Container Registry และ Dependency Proxy

GitLab Container Registry — เป็นรีจิสทรี Docker ในตัวที่ผสานรวมกับ CI/CD หลังจากสร้าง Docker image ในไปป์ไลน์แล้ว สามารถเผยแพร่ไปยัง Registry ได้ทันทีโดยใช้ตัวแปรสภาพแวดล้อม CI_REGISTRY และ CI_REGISTRY_USER Registry รองรับการแคชแบบ pull-through การติดแท็ก นโยบายการทำความสะอาด และการสแกนช่องโหว่โดยตรงในรีจิสทรี

Dependency Proxy — กลไกการแคชสำหรับคอนเทนเนอร์และ images จากรีจิสทรีภายนอก (Docker Hub, Quay, GCR) เมื่อไปป์ไลน์ร้องขอ image เช่น ubuntu:latest GitLab จะตรวจสอบแคชก่อน — หาก image ถูกดาวน์โหลดแล้ว จะไม่ถูกดึงอีกครั้ง ซึ่งช่วยลดภาระบนรีจิสทรีภายนอก เร่งไปป์ไลน์ และป้องกันขีดจำกัดอัตราของ Docker Hub

สำหรับนักพัฒนามือถือ GitLab มี GitLab Pages สำหรับโฮสต์เอกสารและรายงานการทดสอบ หลังจากรันการทดสอบ อาร์ติแฟกต์ (รายงาน HTML, ภาพหน้าจอ, บันทึก) สามารถเผยแพร่เป็น Pages และแชร์ลิงก์กับทีม QA ซึ่งสะดวกกว่าการอัปโหลดรายงานไปยังพื้นที่เก็บข้อมูลบนคลาวด์เนื่องจากทุกอย่าง อยู่ ในโปรเจกต์ GitLab เดียวกัน

GitLab API และ Webhooks

GitLab API (REST และ GraphQL) ให้เข้าถึงทรัพยากรทั้งหมดของแพลตฟอร์ม: โปรเจกต์, ผู้ใช้, ไปป์ไลน์, Merge Requests, รีจิสทรี API ใช้สำหรับระบบอัตโนมัติ: สร้างโปรเจกต์จากเทมเพลต, กำหนดผู้ตรวจสอบ, รับสถานะไปป์ไลน์ Webhooks อนุญาตให้ส่งการแจ้งเตือน HTTP ไปยังระบบภายนอกเมื่อเกิดเหตุการณ์: push, merge, การสร้าง Issue Webhooks ผสานรวมกับ Mattermost, Slack, Telegram และระบบตรวจสอบภายใน

GitLab Pages สำหรับเอกสารมือถือ

GitLab Pages เผยแพร่เว็บไซต์แบบคงที่จากรีปอซิทอรีโดยอัตโนมัติ สำหรับโปรเจกต์มือถือ Pages สะดวกสำหรับโฮสต์เอกสาร API, รายงานความครอบคลุมของการทดสอบ และผลการวิเคราะห์ lint การเผยแพร่เกิดขึ้นโดยอัตโนมัติหลังจากไปป์ไลน์สำเร็จ — เพียงเพิ่มขั้นตอน deploy ด้วยการเผยแพร่ไปยัง Pages ใน .gitlab-ci.yml ผลลัพธ์สามารถเข้าถึงได้ที่ https://namespace.gitlab.io/project-name