ใช้ Gitea Action Runner ทำ Automation นอกเหนือจาก CI/CD

เวลาพูดถึง Gitea Actions หรือ runner คนส่วนใหญ่มักนึกถึงภาพเดิม ๆ คือ push code แล้วระบบรัน test, build image, deploy application หรือ sync content ไปยังปลายทางบางอย่าง ซึ่งเป็นภาพที่ถูกต้อง แต่ผมคิดว่ายังไม่ครบ

ถ้ามองให้ลึกลงไปอีกนิด act_runner ของ Gitea ไม่ได้เป็นแค่เครื่องมือ CI/CD แต่มันคือเครื่องรันงานแบบ self-hosted ที่รับคำสั่งจาก workflow YAML ได้ มี secrets มี logs มี history ของทุก run และสามารถ trigger ได้จาก event หรือ schedule

พูดง่าย ๆ คือถ้าคุณมี Gitea อยู่แล้ว คุณอาจมี automation engine ที่ดีพอสำหรับงานหลายแบบอยู่ในมือ โดยไม่จำเป็นต้องเริ่มจาก n8n, Jenkins หรือ cron job กระจัดกระจายบน server หลายเครื่องทันที

แต่ประโยคนี้ต้องมีดอกจันกำกับไว้หน่อย เพราะ runner ที่ยืดหยุ่นมากก็อันตรายมากได้เหมือนกัน ถ้าเราให้สิทธิ์มันกว้างเกินไป หรือปล่อยให้ workflow ที่ไม่ไว้ใจไปรันบน host ตรง ๆ บทความนี้เลยไม่ได้อยากชวนให้ใช้ Gitea Runner แทนทุกอย่าง แต่ชวนมองว่ามันเหมาะกับงาน automation แบบไหน และต้องวาง guardrail อย่างไร

มอง Runner ใหม่: ไม่ใช่แค่ Pipeline แต่เป็น Script Engine ที่มีระบบกำกับ

จุดที่ทำให้ Gitea Runner น่าสนใจสำหรับงาน automation ทั่วไปคือมันมีของที่ cron job ธรรมดามักไม่มีครบตั้งแต่แรก

อย่างแรกคือ syntax คุ้นมาก ถ้าคุณเคยใช้ GitHub Actions มาก่อน โครงสร้าง workflow ของ Gitea Actions จะดูไม่แปลกตา เพราะ Gitea ตั้งใจให้เข้ากันได้กับแนวคิดและ YAML หลายส่วนของ GitHub Actions แม้ในทางปฏิบัติจะยังมีรายละเอียดที่ไม่เหมือนกันทั้งหมด

อย่างที่สองคือ secrets อยู่ในระบบกลาง คุณไม่ต้องเขียน API key, token หรือ password ลงใน shell script ที่วางทิ้งไว้บน server แบบหลวม ๆ เอกสารของ Gitea มีส่วนของ Actions Secrets สำหรับเก็บค่าที่ sensitive และเรียกใช้ใน workflow ได้ผ่าน context ที่กำหนดไว้

อย่างที่สามคือ logs และ audit trail ใช้งานง่าย ทุกครั้งที่ workflow รัน คุณเห็นได้ว่าเริ่มเมื่อไร จบเมื่อไร fail เพราะอะไร และ output อยู่ตรงไหน สำหรับทีมเล็กหรือ homelab ที่เริ่มมีงานอัตโนมัติหลายตัว จุดนี้ช่วยลดอาการ “เมื่อคืน script พังแต่ไม่มีใครรู้” ได้เยอะ

อย่างสุดท้ายคือมันรองรับทั้ง event-driven และ scheduled workflow งานบางอย่างเกิดจาก push หรือ pull request ได้ ส่วนงานบางอย่างก็รันตามเวลา เช่น ทุกคืน ทุกสัปดาห์ หรือทุกเช้า ตรงนี้ทำให้มันเริ่มทับพื้นที่ของ cron ได้พอสมควร

ใช้แทน Cron Job สำหรับ Homelab และงาน Ops บางส่วน

use case แรกที่เห็นภาพง่ายที่สุดคือใช้ runner เป็น cron job ที่มีหน้าตา มี log และมี secrets

เช่น backup งานสำคัญทุกคืน workflow อาจ checkout repo ที่เก็บ script จากนั้น SSH เข้าเครื่องเป้าหมายเพื่อบีบอัด directory ที่กำหนด เข้ารหัส แล้วส่งไปยัง S3-compatible storage, NAS อีกเครื่อง หรือ cloud storage ที่เราเตรียมไว้ ข้อดีคือ credential ถูกเก็บใน Gitea Secrets และ run history อยู่ใน Gitea UI ไม่ใช่อยู่แค่ใน syslog ที่ต้องไปตามหาเอง

อีกตัวอย่างคือ maintenance รายสัปดาห์ เช่นรัน update บน server ภายในบ้านหรือ lab ผ่าน SSH ตรงนี้ต้องระวังมาก เพราะคำสั่งแนว apt update หรือ apt upgrade อาจดูธรรมดา แต่ถ้าปล่อยให้รันแบบไม่มี rollback, ไม่มี maintenance window หรือไม่มี alert เมื่อ fail ก็สร้างปัญหาได้เหมือนกัน ผมมองว่ามันเหมาะกับงานที่ scope ชัดและความเสี่ยงต่ำก่อน เช่น update package list, ตรวจ disk usage, ตรวจ service health หรือ generate report มากกว่าการสั่ง upgrade production server แบบไม่ดูผล

อีกงานที่เข้ากับ homelab คือ dynamic DNS update ถ้าบ้านใช้ public IP ที่เปลี่ยนได้ workflow แบบ schedule สามารถเช็ก IP ปัจจุบัน แล้วเรียก API ของ DNS provider เพื่อ update record เฉพาะเมื่อ IP เปลี่ยนจริงได้ งานแบบนี้เขียนเป็น script ได้ไม่ยาก แต่พอมาอยู่ใน Gitea Actions คุณได้ secrets, logs และ retry behaviour ที่เป็นระบบขึ้น

Data Pipeline เล็ก ๆ ที่ไม่ต้องตั้งระบบใหญ่

อีกกลุ่มงานที่เหมาะคือ data pipeline ขนาดเล็ก เช่น ดึงข้อมูลจาก public API ทุกวัน แปลงเป็น JSON หรือ CSV แล้ว commit กลับเข้า repository

ตัวอย่างเช่น ดึงข้อมูลสภาพอากาศ, ราคาสินทรัพย์, RSS feed, vulnerability feed หรือข้อมูล status จาก service ภายใน แล้วเก็บผลลัพธ์เป็นไฟล์ timestamped ใน repo วิธีนี้เหมาะกับข้อมูลที่ไม่ใหญ่มาก และอยากได้ประวัติการเปลี่ยนแปลงแบบ Git ช่วย track ให้

ถ้าจะทำ web scraping ก็ทำได้เหมือนกัน แต่ควรทำอย่างระมัดระวัง อ่าน robots.txt และเงื่อนไขการใช้งานของเว็บนั้น ๆ ไม่ยิง request ถี่เกินไป และไม่เก็บข้อมูลที่ไม่ควรเก็บ ผมชอบใช้ runner กับ scraper แบบเบา ๆ เช่นตรวจหน้า release note ว่ามีเวอร์ชันใหม่หรือยัง หรือเช็กหน้า status page แล้วบันทึก diff มากกว่าการ scrape ข้อมูลจำนวนมากแบบจริงจัง

อีก use case คือ database cleanup เช่นรัน SQL script เพื่อลบ log เก่าที่เกิน retention, vacuum/optimise table หรือสร้าง report รายสัปดาห์ งานแบบนี้ควรแยก database credential เป็น secret, จำกัดสิทธิ์ user ให้ทำได้เท่าที่จำเป็น และทดสอบ script กับ staging หรือ dump ก่อนเสมอ เพราะ workflow ที่สะดวกมากสามารถทำความเสียหายได้เร็วมากถ้าคำสั่งผิด

งาน Content และ Media Processing

ใน repo ที่มีรูป, podcast, video หรือเอกสารจำนวนมาก Gitea Runner ใช้เป็นเครื่องมือจัดการ content workflow ได้ดีพอสมควร

ตัวอย่างใกล้ตัวคือ image optimisation สมมติเรามี folder สำหรับโยนรูปต้นฉบับขนาดใหญ่เข้ามา workflow สามารถตรวจไฟล์ใหม่ ใช้ ImageMagick หรือเครื่องมือที่เหมาะสม resize/compress แล้ว commit ไฟล์ที่ optimised กลับเข้า repo ได้ วิธีนี้ช่วยลดงาน manual และทำให้ทุกคนในทีมได้ผลลัพธ์ตามมาตรฐานเดียวกัน

งานแบบ podcast หรือ video ก็ใช้แนวคิดคล้ายกัน เช่น drop ไฟล์เสียงหรือวิดีโอลง branch เฉพาะ จากนั้น workflow เรียก FFmpeg ผ่าน Docker container เพื่อสร้างไฟล์ compressed, waveform, thumbnail หรือ audio-only version ข้อดีคือ dependency หนัก ๆ อยู่ใน container ไม่ได้ปนกับ host มากเกินไป

อย่างไรก็ตาม งาน media processing ใช้ CPU, RAM และ disk I/O สูงกว่างาน script ทั่วไปมาก ถ้า runner ตัวเดียวกันใช้ทั้ง build code, backup และ transcode video งานจะเริ่มชนกันง่าย ผมแนะนำให้แยก runner label สำหรับงานหนัก เช่น heavy-compute หรือ media-runner และตั้ง timeout กับ concurrency ให้ชัด

Notification และ Personal Alert

งานแจ้งเตือนก็เป็นอีกพื้นที่ที่ runner ใช้ได้ดี โดยเฉพาะใน homelab ที่ยังไม่อยากตั้ง monitoring stack เต็มรูปแบบ

ตัวอย่างเช่น workflow ทุก 10 นาที ping service สำคัญ ถ้าเจอ HTTP 404, 502 หรือ timeout ก็ส่ง Discord, Slack หรือ Telegram webhook ไปแจ้งเตือน งานนี้ไม่ได้แทน monitoring platform จริงจังทั้งหมด แต่ช่วยให้รู้เร็วขึ้นว่า service ที่เราใช้เองล่มหรือไม่

อีกแบบคือ daily morning digest ทุกเช้า workflow ไปดึง weather, calendar, RSS feed, task list หรือสถานะ server แล้วส่ง summary ให้เรา วิธีนี้เหมาะกับคนที่อยากได้ automation ส่วนตัวแบบไม่ต้องมี UI ซับซ้อน แค่มี script ที่ดึงข้อมูลได้และ webhook ปลายทางก็พอ

จุดที่ควรระวังคือ notification workflow ต้องออกแบบไม่ให้ spam ถ้า service ล่มต่อเนื่อง 2 ชั่วโมงแล้ว workflow ยิงทุก 10 นาทีโดยไม่มี deduplication หรือ cooldown สุดท้าย alert จะกลายเป็นเสียงรบกวนมากกว่าข้อมูล

Best Practice: Labels, Docker และ Host Runner

หัวใจของการใช้ Gitea Runner แบบ adaptive คืออย่าให้ runner ทุกตัวเหมือนกันหมด

ใน Gitea Actions คำว่า runs-on จะจับคู่กับ runner labels ที่เรากำหนดไว้ เอกสารของ Gitea อธิบายว่า label สามารถ map กับ execution environment ได้ เช่น label ที่พา job ไปรันใน Docker image เฉพาะ หรือ label ที่ชี้ไปยัง host environment บางแบบ เพราะฉะนั้น runs-on: ubuntu-latest ใน self-hosted world ไม่ได้แปลว่ามีเครื่อง hosted เหมือน GitHub แต่แปลว่าคุณมี runner ที่ประกาศ label นั้นไว้

ผมชอบแยก label ตาม trust และ workload เช่น

1. docker สำหรับงานทั่วไปที่ควรรันใน container
2. linux-shell สำหรับงานดูแล host ที่จำเป็นต้องเข้าถึงเครื่องโดยตรง
3. backup-runner สำหรับงาน backup ที่มีสิทธิ์อ่านข้อมูลบาง path
4. heavy-compute สำหรับงาน transcode, image processing หรือ batch job หนัก ๆ

โดยหลักการ งานที่ไม่ต้องแตะ host ควรรันใน Docker เพราะ clean กว่าและลดผลกระทบกับเครื่อง runner ได้มากกว่า ส่วนงาน host execution ควรเก็บไว้เฉพาะกรณีที่จำเป็นจริง เช่น system maintenance, backup path บน host, หรือ network task ที่ต้องใช้ tool บนเครื่องนั้นโดยตรง

Security ที่ไม่ควรมองข้าม

Runner คือเครื่องที่รับคำสั่งจาก workflow ไป execute จริง ดังนั้นถ้า workflow ถูกแก้โดยคนที่ไม่ควรมีสิทธิ์ หรือ runner มี access กว้างเกินไป ความเสียหายจะไปไกลกว่าแค่ pipeline fail

ข้อควรคิดก่อนใช้ runner กับงาน automation ทั่วไปคือ

1. อย่าให้ repo ที่ไม่ไว้ใจรันบน runner ที่มี host access
2. อย่าใช้ runner เดียวกันกับงานที่มี trust level ต่างกันมาก
3. จำกัด secrets ให้เท่าที่ workflow นั้นต้องใช้จริง
4. ระวัง Docker socket เพราะ job ที่แตะ Docker socket ได้มักมีอำนาจสูงกว่าที่คิด
5. ตั้ง timeout, concurrency และ retention ของ logs ให้เหมาะสม
6. แยก runner สำหรับ production deploy ออกจาก runner สำหรับทดลอง

ในมุมนี้ Gitea Runner ไม่ได้ต่างจาก automation tool อื่นมากนัก คือมันดีเมื่อเราใช้เพื่อทําให้กระบวนการเป็นระบบ แต่จะเสี่ยงทันทีถ้าใช้เป็นทางลัดให้ script ทุกอย่างมีสิทธิ์เท่ากันหมด

ตัวอย่าง Workflow แบบย่อ

ตัวอย่างนี้เป็นภาพรวมของ scheduled workflow ที่รัน script และส่ง notification เมื่อ fail โค้ดจริงควรปรับตาม environment ของคุณ

name: Daily automation

on:
  schedule:
    - cron: "0 1 * * *"
  workflow_dispatch:

jobs:
  run-task:
    runs-on: docker
    steps:
      - uses: actions/checkout@v4
      - name: Run daily script
        run: ./scripts/daily-task.sh
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}

สิ่งที่ควรสังเกตคือ workflow นี้ยังไม่ได้ทำอะไรน่าตื่นเต้น แต่มันมีโครงที่ดีพอให้ต่อยอดได้ มี schedule, manual trigger, checkout, secret และ runner label ที่ชัดเจน จุดเริ่มต้นแบบนี้มักดีกว่าการเขียน cron ยาว ๆ ไว้ในเครื่องเดียวแล้วลืมว่ามันอยู่ตรงไหน

สรุป

Gitea Action Runner น่าสนใจเพราะมันอยู่กึ่งกลางระหว่าง CI/CD platform กับ automation engine ขนาดเล็ก ถ้าคุณมี Gitea อยู่แล้ว มันสามารถช่วยงาน backup, maintenance, data fetching, media processing และ notification ได้โดยไม่ต้องเพิ่มระบบใหม่ทันที

แต่ความยืดหยุ่นนี้ควรมาพร้อมวินัยในการออกแบบ runner labels, secrets, execution mode และ trust boundary ให้ดี งานทั่วไปควรรันใน container งานที่ต้องแตะ host ควรถูกแยกและคุมเข้ม งานที่ใช้ secret สำคัญไม่ควรปนกับ repo ที่ใครก็แก้ workflow ได้

สำหรับผม วิธีคิดที่คุ้มที่สุดคือเริ่มจาก automation เล็ก ๆ ที่ซ้ำบ่อย มีผลลัพธ์ตรวจสอบได้ และถ้าพังก็ไม่ทำให้ระบบหลักเสียหาย แล้วค่อยขยับไปงานที่สำคัญขึ้นเมื่อเราเข้าใจพฤติกรรมของ runner และข้อจำกัดของ environment ตัวเองจริง ๆ

แหล่งข้อมูลอ้างอิง

• Gitea Actions overview: https://docs.gitea.com/usage/actions/overview
• Gitea Act Runner documentation: https://docs.gitea.com/usage/actions/act-runner
• Gitea Actions quick start: https://docs.gitea.com/usage/actions/quickstart
• Gitea Actions Secrets: https://docs.gitea.com/usage/actions/secrets
• Gitea Actions comparison with GitHub Actions: https://docs.gitea.com/usage/actions/comparison

Image Prompts

• cover: ภาพประกอบสไตล์ Ghibli-inspired เชิง editorial สำหรับบทความภาษาไทยเรื่องการใช้ Gitea Action Runner เป็น self-hosted automation engine นอกเหนือจาก CI/CD ในฉาก homelab บนโต๊ะทำงาน มี server self-hosted แบบไม่ติดโลโก้ เครื่อง runner แผ่น workflow YAML แบบไม่มีตัวหนังสือ calendar schedule cards backup drive notification bell และ data files ไหลผ่านเส้นแสงนุ่ม ๆ องค์ประกอบระยะกลางถึงกว้าง มุมระดับสายตา แสงโคมไฟอบอุ่นตัดกับฉากหลังสีน้ำเงินยามเย็น โทนสีเขียวเข้ม amber อุ่น เทา charcoal และครีม ไม่มีตัวอักษร ไม่มีโลโก้ ไม่มี watermark ไม่มี UI overlays ไม่มีใบหน้าหรือนิ้วผิดรูป
• inline-1: ภาพประกอบสไตล์ Ghibli-inspired เชิง editorial ของการใช้ Gitea Action Runner แทน cron job ที่กระจัดกระจาย ในห้อง server เล็ก ๆ มีบอร์ด automation ที่จัดระเบียบดี task cards ตามเวลา backup archive box สัญลักษณ์ lock สำหรับ encryption สัญลักษณ์ cloud storage กล่อง NAS และเครื่อง runner ที่กำลังรัน nightly maintenance อย่างสงบ มุมกล้องระยะกลางแบบ slightly top-down แสงใช้งานจริงอบอุ่น โทนสีเขียวหม่น เทาอ่อน amber และครีม ไม่มีข้อความอ่านได้ ไม่มีโลโก้ ไม่มี watermark ไม่มี UI overlays ไม่มีภาพ hacker
• inline-2: ภาพประกอบสไตล์ Ghibli-inspired เชิง editorial ของ data pipeline และ lightweight web scraping ด้วย Gitea Action Runner เครื่อง runner ขนาดเล็กบนโต๊ะกำลังรวบรวม weather cards market chart cards RSS pages และ database records ให้กลายเป็น icon ไฟล์ JSON และ CSV แล้วส่งเข้า repository self-hosted ที่แทนด้วยชั้นเก็บเอกสารเป็นระเบียบ ภาพไหลจากซ้ายไปขวาด้วยเส้นแสงสะอาด แสงเช้านุ่ม ๆ อารมณ์อยากรู้อยากเห็นแต่ practical โทนสี teal หม่น ครีม เทาอบอุ่น และส้มอ่อน ไม่มีตัวอักษร ไม่มีโลโก้ ไม่มี watermark ไม่มี UI overlays ไม่มีภาพหน้าจอเว็บไซต์จริง
• inline-3: ภาพประกอบสไตล์ Ghibli-inspired เชิง editorial ของ best practices สำหรับ adaptive Gitea runners มี runner stations 3 จุดแยกชัดเจนใน homelab ได้แก่ Docker runner ที่ isolate งานทั่วไป host-level maintenance runner อยู่หลังแนวกั้นเตือน และ heavy compute media-processing runner พร้อมสัญลักษณ์คลื่นเสียงกับม้วนฟิล์ม ใช้ label tags เป็น marker สีโดยไม่มีตัวหนังสือ มี secrets เป็นซองจดหมายล็อก และ logs เป็นม้วนกระดาษเรืองแสง องค์ประกอบระยะกลางถึงกว้าง ดูเป็นระบบและ professional แสงในห้องนุ่ม ๆ โทนสี forest green slate grey cream และ warm gold ไม่มีข้อความอ่านได้ ไม่มีโลโก้ ไม่มี watermark ไม่มี UI overlays ไม่มีมือผิดรูป ไม่มีภาพ hacker