ลองอ่านคอนเซ็ปตอนแรกตื่นเต้นมากครับ นึกว่า DigitalOcean ทำ Serverless ออกมาแล้ว แต่จริงๆเป็น PaaS (Platform as a Service) ตัวหนึ่ง ที่ช่วยสร้าง Infrastructure ต่างๆ ให้โดยที่เราไม่ต้องจัดการอะไรเองเลย แต่ก็ยังตื่นเต้นอยู่นะ เพราะมันทำด้วย Kubernetes ที่ Scaling ได้ และรองรับภาษาหลายตัว รวมถึง PHP ด้วยจ้า

มีอะไรน่าสนใจใน DigitalOcean App Platform

ก่อนจะพาดูผมทดสอบ ขอขายของให้สุดก่อน ว่าทำไมผมถึงชอบมัน และตื่นเต้นอยากลองใช้

1. ราคาถูก – คนใช้ DigitalOcean อย่างผมจะรู้ว่าที่นี่ราคาถูกดี รวมถึงเจ้าระบบ App Platform ด้วย ที่เริ่มต้นเพียง 5$ ต่อเดือน (แต่ใช้ ฟรี ได้นะ ถ้าเป็น static files)
2. รองรับหลายภาษาเขียนโปรแกรมและเฟรมเวิร์ก – เช่น Node.js, Python, Django, Go, PHP, Laravel, React, Ruby, Ruby on Rails, Gatsby, Hugo แต่ถ้าอยากใช้นอกเหนือกว่านี้ เช่น .NET Core ก็ทำเป็น Docker Container ไปใช้ได้ รวมถึงทำไต์ง่ายๆ เป็น static sites หรือ CDN ก็ได้
3. Scale ได้ง่าย – เพราะทำงานอยู่บน Kubernetes clusters จึงทำให้ รองรับการ Scale-out หรือ Scale-up ได้ เพียงแค่กดเปลี่ยนแพ็คเกจของ App หรือกดเพิ่มลดจำนวน App ในหน้า Dashboard ได้เลย
4. Zero Downtime – ในขณะที่เรา Scale-out หรือ Scale-up ตัว Server เราอยู่ จะไม่กระทบกับเว็บไซต์เรา ผู้เข้าเว็บไซต์ยังทำงานได้ปกติ
5. Automated Deployment – มันจะเชื่อมต่อกับ Github ของเรา (อนาคตจะต่อกับ Bitbucket,GitLab ได้) และเมื่อมีการ Push Code ขึ้นไป ก็จะทำการ Deploy ทันทีที่ App Platform ทำให้เราเห็นการเปลี่ยนแปลงได้ทันทีบนหน้าเว็บไซต์เรา

ตั้งแต่ข้อ 3-5 ถ้าเราจะวางระบบ Infrastructure ให้ได้แบบนี้ คงไม่ใช่เรื่องง่ายๆเลย (อย่างน้อยก็สำหรับผมคนหนึ่งแล้วหละ)

ปล. จะเรียกว่าข้อเสียไหมไม่รู้นะครับ แต่ตอนนี้ยังไม่มีบริการทางฝั่ง Asia ให้เลือก ดังนั้นอาจมีผลกับความเร็วเล็กน้อย, รวมถึงยังไม่มีฟีเจอร์ให้ใช้งานอะไรมาก จนถึงขั้นกำหนด Pipeline หรือลงรายละเอียด จนถึงขั้นเป็น CI/CD แบบใน Jenkins ได้

แนะนำให้ศึกษาเรื่องเหล่านี้ก่อน

บริการนี้เรียกได้ว่าเป็น Automated Deployment ดังนั้น หากจะนำไปใช้งานจริง ควรจะเข้าใจที่มาที่ไปไว้บ้าง ว่า Best Practice ที่ควรทำเป็นอย่างไร เพราะหากอ่านแล้วและนำไปใช้จริง อาจจะเกิดความเสียหายได้ ดังนั้น ผมแนะนำให้ไปอ่านเรื่องราวนี้ก่อนครับ

• สรุปแนวคิด The Twelve Factors ในภาพเดียวจบ
• เริ่มต้นทำ CI/CD – Automation Deployment ด้วย Git และ Jenkins (3 – จบ)
• ต้องคิดอย่างไร รู้อะไร และทำอย่างไร เพื่อให้เกิด Automated Test
• จะทำระบบให้รองรับ Automated Test ได้อย่างไร (Testable)
• มาทำความรู้จักกับ Serverless และ AWS Lambda ฉบับคนคิดจะใช้ (ไม่เกี่ยวแต่อยากนำเสนอ แหะๆ)

ทดสอบ DigitalOcean App Platform กันหน่อย

ไปสร้าง Repository บน GitHub ไว้ และนำไฟล์โค้ดของเว็บไซต์เรา push ขึ้นไปรอไว้ก่อน ในที่นี้ผมใส่ index.html ไว้

เข้า DigitalOcean และไปที่เมนู App จากนั้นกด Launch Your App (ใครยังไม่ได้สมัคร ก็ไปสมัครสมาชิก DigitalOcean กันก่อนนะ)

สำหรับครั้งแรก จะเจอให้ Link Account กับ GitHub ก่อนนะครับ

เมื่อ Link Account GitHub เสร็จ ก็เลือก Repository ที่เราต้องการใช้สร้าง

จากนั้นเลือก Region ซึ่งปัจจุบันตอนผมทดสอบ ยังมีเพียงฝั่งทวีป America และ Europe เท่านั้น, จากนั้นเราเลือก Git Branch ที่ต้องการเชื่อมโยงการ Deploy และเลือกว่าจะให้ Deploy อัตโนมัติทันทีเมื่อมีการ Push Code เข้าสู่ Branch นั้น

มาถึงส่วนสำคัญ คือการ Config App ของเรา ว่าจะตั้งค่าอย่างไรบ้าง ดังนี้

• Type – คือประเภทของ APP ซึ่งในที่นี้ระบบมองว่าโค้ดผมเป็น HTML มันเลยเลือกให้เป็น Static Site ให้
• HTTP Routes – กำหนด Path ในการเข้าถึง เช่น / จะวิ่งเข้ามาที่ App นี้ หรือจะตั้งว่า /aabbcc ก็ได้ ดังนั้นใครเข้า www.web.com/aabbcc ก็จะเข้ามาที่ App นี้
• Environment Variables – ตัวแปรที่เก็บไว้ใช้ในระบบ เช่น เก็บ User/Password Database ไว้ที่นี่เป็นต้น
• Build Command – เป็น Shell Script จะใส่อะไรก็ได้ หรือเว้นไว้ก้ได้
• Output Directory – ที่เก็บผลลัพธ์หลังจาก build แล้ว

ส่วนปุ่มด้านล่าง Add a Database คือการให้ App นี้อนญาตให้เชื่อมต่อกับ Database อะไรได้บ้าง หรือจะสร้างใหม่เลยก็ได้นะ

ขั้นตอนสุดท้ายคือการเลือกแพ็คเกจใช้งาน ซึ่งในที่นี้เป็น Static Site เลยทำให้ใช้งานได้ฟรีครับ แต่ถ้าเราใช้กับพวก Dynamic Script อย่าง Node.js, PHP, Docker ก็จะต้องใช้เป็น Basic หรือ Pro เท่านั้น แต่ก็ถือว่าเป็นการเริ่มต้นใช้งานที่ถูกมากๆ แค่ 5$ เท่านั้น (แต่แพ็คเกจ Basic ทาง DigitalOcean แนะนำให้ใช้เป็นระบบสำหรับทดสอบ หรือ Prototype จะดีกว่านะ)

หลังจากกด Launch Starter App แล้ว รอสักครู่ มันจะสร้าง Instant และเมื่อเสร็จแล้ว ก็จะเห็น URL สำหรับการใช้งาน

เมื่อทดลองเข้าไปดูตาม URL ก็จะเห็นหน้าที่ผมไว้สร้างไว้บน GitHub แล้ววว

แต่หน้าตามันดูห่วยๆ เนอะ คราวนี้ผมจะสร้าง css file เพิ่ม

และทำการ push code ขึ้นสู่ GitHub

มีไฟล์ css เพิ่มมาใน GibHub แล้ว

พอผมกลับไปดูหน้าเว็บไซต์ ว้าวว มันเป็นระเบียบสวยงามขึ้นแล้ววว

ไปดูรายการ Deployments มีการเก็บบันทึกไว้ว่ามีการ Deploy อะไรไปบ้าง

สรุป

อย่างที่ผมเกริ่นไปตอนแรก การจะวางระบบ Infrastructure ให้ได้แบบนี้ หรือเริ่มใช้ Kubernetes คงไม่ใช่เรื่องง่ายๆเลยสำหรับผู้ใช้งานทั่วไป หรือโปรแกรมเมอร์หลายๆคน รวมถึงผมด้วย ต่อให้สร้างขึ้นมาได้ แต่การดูแลรักษาเป็นเรื่องที่ปวดหัวมาก เช่น ถ้ามีผู้ใช้เข้ามาสูงมากๆ หรือถ้าโดน DDoS โจมตี เป็นต้น

ดังนั้นการมีบริการ PaaS ลักษณะนี้ขึ้นมา ก็ช่วยทำให้เราสะดวกมากขึ้น และทำให้โปรแกรมเมอร์อย่างเรา สามารถเป็น DevOps ได้เองอย่างไม่ยากเย็นนัก

บทความนี้อ้างอิงวิธีการจาก Digitalocean Tutorials : How To Set Up Automatic Deployment with Git with a VPS

คำเตือน: อย่างที่บอก มันแค่อำนวยความสะดวกด้วย Git ดังนั้นก่อนจะ Deploy ขึ้น Production Server ควรผ่านการ Test ให้เสร็จเสียก่อน

(รูปตัวอย่างของ Git Deployment ของ จาก flyingcorkmedia.com)

เตรียมของ

บน Production Server:

• Directory ที่เราใช้ Live เว็บไซต์ เช่น /var/www/domain.com
• Directory ที่เราใช้เก็บ Git Repo เช่น /var/repo/site.git

บน Localhost:

• ติดตั้ง Git
• ทำการผูก SSH Key ระหว่างเครื่องเรา (Localhost) กับ Production Server (ถ้าไม่ผูกก็ได้ แต่จะต้องมาพิมพ์รหัสตลอดทุกครั้งที่ Commit นะ, ตัดสินใจดูเอาเอง)

เริ่มต้นทำ Git Repo บน Production Server

ถ้ายังไม่ได้สร้าง /var/repo/site.git ให้ใช้คำสั่ง

[wc_code]mkdir /var/repo/site.git[/wc_code]

จากนั้น เข้าไป git init ให้มันด้วยคำสั่ง git init –bare

[wc_code]cd /var/repo/site.git
git init –bare[/wc_code]

อธิบาย: git init –bare จะสร้างและเก็บค่าคอนฟิกของ Version Control เฉยๆ จะไม่มีการเก็บ Source Code

ทำการ Git Hook

ให้เข้าไปที่ไดเร็กทอรี่ repo ที่ได้สร้างไว้เมื่อสักครู่ จากนั้น ปรับ permission ไฟล์ hooks/post-receive เพื่ออนุญาตให้ execute file ได้ และเข้าไปแก้ไขข้อมูลในไฟล์นั้น

[wc_code]cd /var/repo/site.git
chmod +x hooks/post-receive
vi hooks/post-receive[/wc_code]

ในไฟล์นั้นจะไม่มีข้อมูลใดๆ จากนั้นให้เราใส่คำสั่งดังนี้

[wc_code]#!/bin/sh
git –work-tree=/var/www/domain.com –git-dir=/var/repo/site.git checkout -f[/wc_code]

เป็นการบอกว่า เมื่อมีการ git push เข้ามา ให้ส่ง source code ไปยัง /var/www/domain.com

จากนั้นให้เราบันทึกและออกมาจากหน้า editor
เป็นอันเสร็จขั้นตอนที่ต้องทำบน Production Server

ทำ Git Repo บน Localhost

คราวนี้เรามาจัดการบนเครื่อง Localhost เราต่อ โดยให้เราเข้าไปที่ไดเร็กทอรี่ที่เก็บ Source Code ของเรา จากนั้นเข้า Git Bash และทำการพิมพ์ git init

[wc_code]git init[/wc_code]

และพิมพ์คำสั่งทำการสร้าง remote ขึ้นมาชื่อ live

[wc_code]git remote add live ssh://user@mydomain.com/var/repo/site.git[/wc_code]

เป็นอันเสร็จขั้นตอนของ Localhost ครับ

ทดลองใช้งาน

ให้ลองสร้างไฟล์ขึ้นมาสักไฟล์หนึ่ง จากนั้น ทำการ commit git ตามปกติ แต่ ขั้นตอน push ให้ส่งไปที่ remote live แทน เช่น

[wc_code]git add .
git commit -m “Test push file to production server”
git push live master[/wc_code]

ข้อมูลบนเว็บไซต์ของเราบน Production Server จะมีการเปลี่ยนแปลงไปตามที่เราได้แก้ไขไป

เพิ่มขั้นตอนทำเป็น Development Environment ก่อนก็ได้นะ

การเอาขึ้น Production ด้วยคำสั่งเดียวมันดูอันตรายไปหน่อย อาจทำขั้นตอนเดียวกันนี้แต่เป็น Development Environment ก่อนก็ได้ โดยทำเหมือนเดิมทุกอย่างเลยครับ

โดยสมมติว่า

• Directory ที่เราใช้ Live Beta เว็บไซต์ เช่น /var/www/beta
• Directory ที่เราใช้เก็บ Git Repo Beta เช่น /var/repo/beta.git

ให้สร้าง Config Version Control

[wc_code]cd /var/repo/beta.git
git init –bare
chmod +x hooks/post-receive
vi hooks/post-receive[/wc_code]

ใส่ข้อมูลในไฟล์ hooks/post-receive ว่า

[wc_code]#!/bin/sh
git –work-tree=/var/www/beta –git-dir=/var/repo/beta.git checkout -f[/wc_code]

จากนั้นมา add remote beta ใน repo localhost เราไปที่ไดเร็ดทอรี่ beta.git

[wc_code]git remote add beta ssh://user@mydomain.com/var/repo/beta.git[/wc_code]

คราวนี้ เวลาพัฒนาหรือแก้ไขปรับหรุง Source Code เสร็จ ก็ทำการนำเข้า Dvelopment Environment เพื่อทดสอบก่อน

[wc_code]git add .
git commit -m “New version”
git push beta master[/wc_code]

เมื่อทดสอบระบบทั้งหมดใน Development Environment  เสร็จ ก็ทำการนำเข้า Production อีกครั้ง

[wc_code]git push live master[/wc_code]

เป็นอันจบขั้นตอนทั้งหมด

ไว้คราวหน้าลอง CI/CD แล้วจะมาเขียนเหลาไหฟังอีกครั้ง

—

Featured Image from  flyingcorkmedia.com