Gitea: ตั้ง Git Server ส่วนตัวพร้อมวางแผนสำรอง repository และฐานข้อมูล
ติดตั้ง Gitea ด้วย Docker Compose ตั้ง URL, SSH และข้อมูลถาวรให้พร้อมก่อนเชิญทีมเข้าใช้ พร้อมจุดตรวจเรื่อง backup
Gitea เป็นบริการ Git โอเพนซอร์สที่โฮสต์เอง ใช้เก็บ repository พร้อม issue, pull request และงานร่วมกันของทีมขนาดเล็กถึงกลาง จุดที่ควรวางแผนตั้งแต่วันแรกคือ URL ที่ผู้ใช้ clone, ช่องทาง SSH และข้อมูลถาวร เพราะย้ายทีหลังอาจกระทบ remote URL ในเครื่องนักพัฒนาทุกคน
เลือกรูปแบบข้อมูลก่อนรัน
เอกสาร Installation with Docker มีตัวอย่าง Docker Compose และ image ของ Gitea ให้เลือกเวอร์ชันที่ต้องการใช้งานจริง แยก /data เป็น volume ถาวร รวมทั้งฐานข้อมูลถ้าเลือกใช้ภายนอก SQLite อาจพอสำหรับการทดลอง แต่ทีมที่มีงานพร้อมกันควรพิจารณา PostgreSQL หรือ MariaDB ตามข้อกำหนดและความสามารถในการดูแล อย่าใช้ volume ที่หายเมื่อสร้างคอนเทนเนอร์ใหม่
ตั้งชื่อโดเมนจริงและกำหนดค่า URL ของเว็บก่อนให้คน clone repo หากใช้ reverse proxy ตรวจ ROOT_URL และ HTTPS ให้ตรงกับ URL ที่คนเข้าถึง ตั้งพอร์ต SSH ของโฮสต์ให้ไม่ชนกับ SSH ที่ใช้ดูแลเครื่อง เช่นแมป 2222 ไป 22 ของคอนเทนเนอร์ แล้วทดสอบ clone ผ่าน SSH จากเครื่องอื่น อย่าเดาว่าการเปิดหน้าเว็บสำเร็จหมายถึง push ผ่าน SSH สำเร็จ
ลำดับทดลองติดตั้ง
- เตรียม Docker Compose และสร้างโฟลเดอร์เก็บข้อมูลถาวร กำหนด UID/GID ให้เข้ากับสิทธิ์บนเครื่อง หากใช้ bind mount
- นำ Compose จากเอกสารทางการมาปรับ image tag, volume, port, database และค่าที่ขึ้นต้น
GITEA__ตามบริการที่ต้องใช้ - ตรวจ
docker compose configแล้วเริ่มด้วยdocker compose up -d; ตรวจdocker compose psและdocker compose logs - เปิดหน้าเว็บ installation wizard ตรวจชื่อฐานข้อมูล host และ
ROOT_URLให้ตรงกับ reverse proxy แล้วสร้างบัญชี admin - สร้าง repository ทดลอง ทำ clone, commit, push ผ่านทั้ง HTTP(S) หรือ SSH ที่ทีมจะใช้ และเปิด issue/PR ทดลองก่อนย้ายข้อมูลจริง
การตั้งค่าเช่น GITEA__server__DOMAIN และ GITEA__server__SSH_DOMAIN ควรสัมพันธ์กับ DNS ที่ใช้จริง ถ้าเชื่อม Actions runner เพิ่ม ให้แยกแผนความปลอดภัยของ runner เพราะ job จาก repository มีสิทธิ์รันโค้ด; ไม่ควรให้ runner เข้าถึง secret ของระบบหลักโดยไม่จำเป็น
สำรองและอัปเดต
การสำรอง Gitea ต้องรวม repository, attachment, configuration และฐานข้อมูลที่ใช้งานอยู่ เอกสาร Backup and Restore อธิบายคำสั่ง dump และข้อจำกัดของการคืนค่า ควรทดสอบ restore ในเครื่องอีกตัวอย่างน้อยหนึ่งครั้ง พร้อมลอง clone repo หลังคืนข้อมูล เพื่อจับกรณีไฟล์และ metadata ไม่ตรงกัน
ก่อนอัปเดต image ให้เก็บสำรองชุดล่าสุด ตรวจ release notes และทดสอบใน staging ถ้ามีงานสำคัญ อย่าเปลี่ยนจาก rootful image ไป rootless เพียงแค่แก้ tag เพราะเอกสารระบุว่า layout และการใช้งานต่างกัน ระหว่างอัปเดตให้เช็ก log migration แล้วทดสอบ login, clone และ push หลังเริ่มระบบ
ใช้เมื่อไร
Gitea เหมาะกับทีมที่ต้องการควบคุมที่เก็บโค้ดและกำหนดรอบสำรองเอง การโฮสต์เองเพิ่มภาระดูแลฐานข้อมูล HTTPS อัปเดตและความพร้อมใช้ ถ้าเป็น repository สำคัญ ให้กำหนดผู้ดูแลและเวลาตอบสนองเมื่อระบบล่มก่อนย้ายงานทั้งหมดเข้ามา
อ่านเพิ่มเติม: ติดตั้งด้วย Docker · สำรองและกู้คืน