คู่มือการโฮสต์เว็บแอพพลิเคชัน Ruby on Rails บน VPS

Ruby on Rails is a powerful web application framework, but hosting Rails applications requires different server setup and understanding compared to traditional PHP websites. This guide walks you through choosing a suitable VPS, installing the essential tools, configuring your web server, and preparing your environment for production deployment. Whether you are deploying your first Rails app or managing multiple services, understanding the hosting fundamentals will help you build a reliable and performant infrastructure.

Ruby on Rails เป็นเฟรมเวิร์กสำหรับการพัฒนาเว็บแอพพลิเคชันที่มีความสามารถสูง แต่การโฮสต์แอพพลิเคชัน Rails ต้องการการเตรียมการและความเข้าใจด้านเซิร์ฟเวอร์ที่แตกต่างจากการโฮสต์เว็บไซต์แบบ PHP ดั้งเดิม บทความนี้จะอธิบายขั้นตอนการเลือก VPS, การติดตั้งชุดเครื่องมือที่จำเป็น, และการตั้งค่าเซิร์ฟเวอร์เพื่อให้แอพพลิเคชัน Rails ของคุณทำงานได้อย่างมั่นคงและเร็วแรง

Ruby on Rails แตกต่างจากเว็บไซต์ PHP อย่างไร

เว็บไซต์ PHP ทั่วไปทำงานผ่านไฟล์สคริปต์ที่อยู่บนดิสก์ เซิร์ฟเวอร์เว็บจะประมวลผลแต่ละไฟล์เมื่อมีการร้องขอ ในขณะที่ Ruby on Rails เป็นแอพพลิเคชันที่ต้องการให้อินสแตนซ์แอพพลิเคชันทำงานอยู่ตลอดเวลาบนเซิร์ฟเวอร์ Rails ต้องการกระบวนการแอพพลิเคชันที่ทำงานต่อเนื่อง (persistent) เช่น Puma หรือ Unicorn ที่รักษาการเชื่อมต่อ HTTP ไว้ และเซิร์ฟเวอร์เว็บเช่น Nginx จะทำหน้าที่เป็นตัวกลาง (reverse proxy) เพื่อส่งคำขอไปยังกระบวนการเหล่านี้ นอกจากนี้ Rails แอพพลิเคชันยังต้องการการเตรียมการเพิ่มเติมเช่นการคอมไพล์ assets และการจัดการข้อมูล dependencies

• PHP ทำงานตามคำขอแต่ละครั้ง Rails ต้องการให้กระบวนการแอพพลิเคชันทำงานตลอดเวลา
• แอพพลิเคชัน Rails ต้องการไฟล์ Gemfile เพื่อจัดการ dependencies
• Assets (JavaScript, CSS, รูปภาพ) ต้องผ่านการประมวลผลเฉพาะ
• Rails ต้องการฐานข้อมูล (ส่วนใหญ่ PostgreSQL หรือ MySQL)
• การติดตั้ง Rails ต้องมีคำสั่ง Ruby บนเซิร์ฟเวอร์

ความต้องการพื้นฐานของ VPS สำหรับแอพพลิเคชัน Rails

สำหรับแอพพลิเคชัน Rails ขนาดเล็กถึงกลาง VPS ที่มีจำนวน CPU core อย่างน้อย 2 cores ความจำ RAM อย่างน้อย 2 GB และพื้นที่ดิสก์ 20-30 GB เป็นจุดเริ่มต้นที่เหมาะสม อย่างไรก็ตาม ขนาดของแอพพลิเคชันและจำนวนผู้ใช้พร้อมกันจะส่งผลต่อความต้องการจริง แอพพลิเคชันที่มีการประมวลผลข้อมูลมากหรือมีผู้ใช้จำนวนมากอาจต้องการ RAM มากกว่านี้ ปัจจุบัน SSD ได้กลายเป็นมาตรฐานอุตสาหกรรมและให้ประสิทธิภาพการอ่าน-เขียนที่เร็วกว่า HDD อย่างมาก

• CPU 2-4 cores สำหรับแอพพลิเคชันเล็กถึงกลาง
• RAM อย่างน้อย 2 GB (4-8 GB สำหรับแอพพลิเคชันที่ต้องใช้เยอะ)
• SSD 20-50 GB เป็นจุดเริ่มต้นขึ้นอยู่กับความต้องการ
• Bandwidth เพียงพอสำหรับจำนวนผู้ใช้ที่คาดการณ์
• Uptime guarantee อย่างน้อย 99% เป็นการลงทุนที่ดี

การติดตั้ง Ruby, Rails และ Bundler บนเซิร์ฟเวอร์ใหม่

ขั้นตอนแรกคือการเตรียมสภาพแวดล้อม Linux ให้พร้อม โดยปกติจะเริ่มต้นด้วยการอัปเดตแพคเกจของระบบ (apt update && apt upgrade) จากนั้นติดตั้ง dependencies ที่จำเป็นสำหรับการคอมไพล์ Ruby เช่น build-essential, libssl-dev, libreadline-dev, zlib1g-dev เป็นต้น วิธีการติดตั้ง Ruby ที่นิยมคือการใช้ rbenv ซึ่งช่วยให้คุณสามารถจัดการเวอร์ชัน Ruby หลายเวอร์ชันบนเซิร์ฟเวอร์เดียวกันได้ หลังจากติดตั้ง Ruby เรียบร้อย ให้ติดตั้ง Rails gem และ Bundler ซึ่งเป็นตัวจัดการ dependencies สำหรับ Rails

• อัปเดตระบบแพคเกจด้วย apt update && apt upgrade
• ติดตั้ง build tools และ libraries ที่จำเป็นสำหรับการคอมไพล์
• ใช้ rbenv เพื่อติดตั้งและจัดการเวอร์ชัน Ruby
• ติดตั้ง Rails gem หลังจากติดตั้ง Ruby
• ติดตั้ง Bundler เพื่อจัดการ gems ของแอพพลิเคชัน

เลือกเซิร์ฟเวอร์แอพพลิเคชัน: Puma กับ Unicorn

เซิร์ฟเวอร์แอพพลิเคชันเป็นกระบวนการที่รักษาการเชื่อมต่อ HTTP และตอบสนองต่อคำขอจากผู้ใช้ Puma เป็นเซิร์ฟเวอร์ที่ได้รับความนิยมอย่างแพร่หลายในปัจจุบันเนื่องจากความเร็วและความสามารถในการจัดการ threads Puma สามารถจัดการหลายคำขอพร้อมกันด้วยกลไก threading จึงมีประสิทธิภาพสูงในสภาพแวดล้อมที่มีข้อจำกัดทรัพยากร Unicorn เป็นเซิร์ฟเวอร์ที่เก่ากว่าและใช้กระบวนการแยกต่างหากเพื่อจัดการคำขอ แม้ว่า Unicorn ยังใช้ได้ แต่เนื่องจาก Puma มีประสิทธิภาพที่ดีกว่า จึงเป็นตัวเลือกที่แนะนำสำหรับแอพพลิเคชันใหม่

• Puma ใช้ threading เพื่อจัดการหลายคำขอบนกระบวนการเดียว
• Unicorn ใช้กระบวนการแยกต่างหากสำหรับแต่ละคำขอ
• Puma มีการใช้หน่วยความจำต่ำกว่า Unicorn
• Puma รองรับ SSL termination ในตัว
• Puma มีความเรียบง่ายในการกำหนดค่าและการติดตั้ง

การตั้งค่า Nginx เป็น Reverse Proxy สำหรับ Rails

Nginx เป็นเซิร์ฟเวอร์เว็บที่เบาและรวดเร็ว ซึ่งตำแหน่งที่เหมาะสมของมันคือการทำหน้าที่เป็น reverse proxy ที่รับคำขอจากอินเทอร์เน็ตและส่งต่อไปยังกระบวนการ Puma ของแอพพลิเคชัน การตั้งค่า Nginx นั้นเกี่ยวข้องกับการสร้างไฟล์คอนฟิกโดยระบุที่อยู่ของเซิร์ฟเวอร์ Puma (โดยปกติ localhost:3000 หรือ localhost:8080) นอกจากนี้ Nginx จะจัดการการแคช static files ของแอพพลิเคชัน การบีบอัดการตอบสนอง และการทำให้ URL เป็นระเบียบ (normalize) การแยกหน้าที่ระหว่าง Nginx และ Puma เช่นนี้ยังช่วยให้คุณสามารถรีสตาร์ทแอพพลิเคชันได้โดยไม่ต้องปิดเว็บเซิร์ฟเวอร์ ทำให้โครงสร้างพื้นฐานมีความยืดหยุ่นและปลอดภัยมากขึ้น

• ตั้งค่า Nginx upstream block เพื่อชี้ไปยังเซิร์ฟเวอร์ Puma
• กำหนด server block สำหรับโดเมนของแอพพลิเคชัน
• เปิดใช้งาน gzip compression สำหรับลดขนาดการตอบสนอง
• ตั้งค่า proxy headers เพื่อส่งข้อมูลไปยัง Puma
• ปิดใช้งาน default server block เพื่อความปลอดภัย

การตั้งค่าฐานข้อมูล: PostgreSQL กับ MySQL

ฐานข้อมูลเป็นศูนย์กลางสำหรับเก็บข้อมูลแอพพลิเคชัน Rails รองรับ PostgreSQL และ MySQL ได้ดี PostgreSQL มีข้อดีดังต่อไปนี้: ความสามารถขั้นสูง เช่น JSON support, full-text search, และ array data types ทำให้เหมาะสำหรับแอพพลิเคชันที่ต้องการการค้นหาและการประมวลผลข้อมูลที่ซับซ้อน MySQL เป็นตัวเลือกที่เบาและรวดเร็ว โดยเฉพาะ MariaDB (ตัวแปร MySQL ที่เป็นโอเพ่นซอร์สอย่างแท้จริง) ส่วนใหญ่แอพพลิเคชัน Rails ใหม่ใช้ PostgreSQL เป็นค่าเริ่มต้นเนื่องจากความสามารถมากมายและการรองรับ Rails ที่ดี

• PostgreSQL ให้ประสิทธิภาพที่ดีและมีคุณลักษณะขั้นสูง
• MySQL/MariaDB เหมาะสำหรับแอพพลิเคชันขนาดเล็กถึงกลาง
• ติดตั้งไคลเอนต์ Ruby database gem (pg สำหรับ PostgreSQL, mysql2 สำหรับ MySQL)
• กำหนดค่า Rails database.yml ให้ชี้ไปยังฐานข้อมูล
• ตั้งค่า user และ password ที่ปลอดภัยสำหรับการเข้าถึงฐานข้อมูล

การคอมไพล์ Assets และการให้บริการในการตั้งค่าการผลิต

Asset pipeline คือคุณลักษณะของ Rails ที่คอมไพล์และบีบอัด JavaScript, CSS, และรูปภาพเพื่อให้เหมาะสำหรับการผลิต ในการพัฒนาแอพพลิเคชันมักไม่มีการบีบอัด แต่สำหรับสภาพแวดล้อมการผลิต การเรียกใช้ rake assets:precompile จะสร้างไฟล์ที่บีบอัด fingerprinted ซึ่งสามารถแคชที่ CDN หรือการตั้งค่าการแคชของไคลเอนต์ได้ Assets เหล่านี้จะถูกเก็บไว้ในไดเรกทอรี public/assets และสามารถให้บริการโดย Nginx โดยตรงเพื่อประสิทธิภาพสูงสุด

• รันคำสั่ง rake assets:precompile ในการสร้างแอพพลิเคชัน
• สร้างไฟล์บีบอัด fingerprinted สำหรับการแคชระยะยาว
• ตั้งค่า Nginx เพื่อให้บริการ public/assets ด้วยหัวข้อแคช
• ลบไฟล์ assets เก่าหลังจากการอัปเดต
• พิจารณาใช้ CDN สำหรับการกระจายเนื้อหา assets

งานพื้นหลัง: Sidekiq และความต้องการการโฮสต์

งานพื้นหลังเป็นสิ่งสำคัญสำหรับแอพพลิเคชันที่ต้องประมวลผลงานที่ใช้เวลา เช่น การส่งอีเมล, การสร้างรายงาน, หรือการประมวลผลภาพ Sidekiq เป็นไลบรารีสำหรับประมวลผลงานพื้นหลังในสภาพแวดล้อม Rails ซึ่งใช้ Redis เพื่อจัดเก็บงาน Sidekiq ช่วยให้ผู้ใช้ไม่ต้องรอให้งานเสร็จสิ้น โดยจะส่งงานนั้นเข้าคิว Redis แล้วให้กระบวนการ Sidekiq worker ประมวลผลในเบื้องหลังแทน เมื่อโฮสต์แอพพลิเคชันที่มี Sidekiq คุณจะต้องติดตั้ง Redis และเรียกใช้ Sidekiq workers เป็นกระบวนการแยกต่างหากโดยใช้เครื่องมือเช่น systemd หรือ supervisor

• ติดตั้ง Redis เพื่อจัดเก็บคิว Sidekiq
• ตั้งค่า Sidekiq worker processes ให้เรียกใช้ในเบื้องหลัง
• ใช้ systemd หรือ supervisor เพื่อจัดการกระบวนการ Sidekiq
• ควรมี Redis backup สำหรับความเสถียร
• ตรวจสอบข้อมูลสถิติ Sidekiq เพื่อการสังเกตการทำงาน

วิธีการปรับใช้: Capistrano, Docker และ CI/CD

การปรับใช้ (deploy) หมายถึงการย้ายรหัสจากเครื่องพัฒนาของคุณไปยังเซิร์ฟเวอร์การผลิต Capistrano เป็นเครื่องมือปรับใช้แบบคลาสสิกที่สคริปต์กระบวนการปรับใช้และเปิดตัวแอพพลิเคชันใหม่บนเซิร์ฟเวอร์ปลายทาง Docker นำเสนอแนวทางอื่น: การปรับใช้คอนเทนเนอร์ (container) ที่บรรจุแอพพลิเคชัน dependencies และเวอร์ชันของภาษาที่จำเป็นไว้ด้วยกันอย่างครบถ้วน ทำให้สภาพแวดล้อมสอดคล้องกันในทุกที่ที่ปรับใช้ นอกจากนี้ CI/CD pipeline (เช่น GitHub Actions, GitLab CI) ยังทำให้การทดสอบและการปรับใช้เป็นไปโดยอัตโนมัติทุกครั้งที่คุณส่งโค้ดไปยังคลัง การเลือกวิธีการปรับใช้ขึ้นอยู่กับความต้องการของแอพพลิเคชันและทีมของคุณ

• Capistrano ทำให้การปรับใช้ง่ายผ่านการเรียกใช้ SSH อัตโนมัติ
• Docker สร้างภาชนะที่สอดคล้องกันสำหรับการปรับใช้ที่เชื่อถือได้
• CI/CD pipelines ทำให้การปรับใช้อัตโนมัติเมื่อโค้ดได้รับการส่ง
• ใช้ git hooks เพื่อป้องกันการส่งโค้ดที่มีข้อผิดพลาด
• กำหนดค่าพื้นที่ทำงานแยกต่างหากสำหรับบิลด์และการปรับใช้