เพิ่มเติม เกริ้นนำ อธิบาย docker, container,microservice และ api gateway

public/documents/chapter-4-superadmin-build-and-deploy.md

@@ -1,9 +1,273 @@
-# Deploy Document
+# บทนำ
+
+การพัฒนาและจัดการแอปพลิเคชันในยุคปัจจุบันได้มีการเปลี่ยนแปลงไปจากวิธีการเดิมๆ ด้วยการนำเทคโนโลยีใหม่ๆ มาใช้ ซึ่งทำให้กระบวนการพัฒนาและการดูแลระบบมีประสิทธิภาพมากขึ้น โดยเฉพาะการใช้ Container, Docker, Microservice, และ API Gateway ซึ่งแต่ละเทคโนโลยีก็มีบทบาทที่สำคัญในการสร้างแอปพลิเคชันที่สามารถปรับตัวได้ง่ายและสามารถขยายได้อย่างยืดหยุ่น
+
+# Container คืออะไร?
+
+Container คือ เทคโนโลยีที่ทำให้การรันแอปพลิเคชันเป็นไปอย่างมีประสิทธิภาพโดยการแยกแอปพลิเคชันและไลบรารีที่จำเป็นออกจากระบบปฏิบัติการหลัก (Host OS) ไว้ในสภาพแวดล้อมที่เป็นอิสระ Container จะบรรจุโค้ด ไลบรารี และการตั้งค่าทั้งหมดที่จำเป็นต้องใช้สำหรับการทำงาน ทำให้แอปพลิเคชันนั้นสามารถทำงานได้ไม่ว่าจะรันในสภาพแวดล้อมไหนก็ตาม เช่น บนเครื่องพัฒนาของโปรแกรมเมอร์ หรือบนเซิร์ฟเวอร์การผลิต
+
+การใช้ Container ช่วยให้
+
+- **ลดความขัดแย้ง** ในการพัฒนาระหว่างทีม เพราะทีมพัฒนาไม่ต้องกังวลว่าแอปพลิเคชันจะทำงานไม่ได้บนเครื่องอื่น
+- **ปรับขนาดได้ง่าย** ด้วยการโคลน Container เพิ่มเมื่อมีความต้องการใช้งานสูง
+- **การจัดการทรัพยากรมีประสิทธิภาพขึ้น** เนื่องจาก Container ใช้ทรัพยากรของระบบปฏิบัติการร่วมกัน ลดความซ้ำซ้อนของระบบที่ต้องจัดเตรียมทรัพยากรแยกเหมือนใน Virtual Machine
+
+# เปรียบเทียบระหว่างเทคโนโลยี Container และ Virtual Machine
+
+การเปรียบเทียบระหว่าง Container และ Virtual Machine (VM) เป็นหัวข้อสำคัญในการเลือกใช้สถาปัตยกรรมสำหรับการรันแอปพลิเคชัน เนื่องจากทั้งสองเทคโนโลยีนี้มีวิธีการทำงานและประโยชน์ที่แตกต่างกัน การทำความเข้าใจความแตกต่างระหว่าง Container และ VM จะช่วยให้ผู้พัฒนาและผู้ดูแลระบบสามารถเลือกใช้เทคโนโลยีที่เหมาะสมกับงานมากที่สุด
+
+# ภาพรวมของ Container และ Virtual Machine
+
+Virtual Machine (VM) คือ การจำลองระบบคอมพิวเตอร์ทั้งหมดที่รันอยู่บนฮาร์ดแวร์เสมือน โดย VM จะมีระบบปฏิบัติการที่แยกต่างหากจากระบบปฏิบัติการหลัก (Host OS) และทำงานได้อย่างอิสระในลักษณะของคอมพิวเตอร์เสมือน
+Container คือ เทคโนโลยีที่แบ่งแยกแอปพลิเคชันและไลบรารีที่จำเป็นออกจากระบบปฏิบัติการหลักในรูปแบบที่เบากว่า VM โดย Container ใช้ระบบปฏิบัติการร่วมกับ Host OS และมีการแยกแอปพลิเคชันจากกันในระดับของโปรเซส
+
+ต่อไปนี้คือการเปรียบเทียบความแตกต่างระหว่าง Container และ VM โดยพิจารณาในหลายๆ ด้าน
+
+1. **สถาปัตยกรรม**
+
+- **VM**: ทำงานบน Hypervisor (เช่น VMware, Hyper-V หรือ KVM) ซึ่งจัดการการสร้างและการรัน VM แต่ละตัว โดย VM แต่ละตัวจะมี Guest OS เป็นระบบปฏิบัติการที่รันภายในของตัวเอง พร้อมด้วย Kernel, แอปพลิเคชัน, และการตั้งค่าเฉพาะ ซึ่งหมายความว่า VM มีการแยกทรัพยากรอย่างสมบูรณ์
+- **Container**: ทำงานบน Container Engine (เช่น Docker, Kubernetes) โดยไม่ต้องใช้ Hypervisor และใช้ Host OS ร่วมกันทุก Container แต่มีการแยกแอปพลิเคชันและไลบรารีในระดับโปรเซส ทำให้ Container มีขนาดเล็กกว่าและมีการทำงานที่เบากว่า VM
+
+2. **ประสิทธิภาพ**
+
+- **VM**: เนื่องจาก VM มี Guest OS ที่เป็นระบบปฏิบัติการเต็มรูปแบบและต้องใช้ Hypervisor ในการรัน VM การใช้ทรัพยากร เช่น CPU และหน่วยความจำจึงมีค่าใช้จ่ายสูงและทำให้ประสิทธิภาพการทำงานช้าลง โดยเฉพาะเมื่อต้องรันหลาย VM พร้อมกัน
+- **Container**: Container ใช้ทรัพยากรร่วมกับ Host OS และมีขนาดเล็กกว่า VM จึงใช้หน่วยความจำและ CPU น้อยลง ซึ่งส่งผลให้ Container มีการทำงานที่รวดเร็วและมีประสิทธิภาพสูงกว่า VM
+
+3. **การใช้งานทรัพยากร (Resource Efficiency)**
+
+- **VM**: แต่ละ VM ต้องจัดสรรทรัพยากรแยกต่างหาก เช่น CPU, RAM และ Disk โดยการรัน VM หลายๆ ตัวพร้อมกันอาจส่งผลให้เกิดการใช้ทรัพยากรสูง ซึ่งไม่สามารถใช้งานทรัพยากรได้อย่างมีประสิทธิภาพเต็มที่เสมอไป
+- **Container**: Container ใช้ทรัพยากรร่วมกับ Host OS ทำให้ประหยัดพื้นที่และหน่วยความจำมากกว่า การสร้างและรัน Container หลายๆ ตัวในเวลาเดียวกันยังใช้ทรัพยากรได้น้อยกว่า และสามารถปรับขนาดการใช้งานได้ง่าย
+
+4. **การเริ่มต้นและการหยุดการทำงาน (Startup and Shutdown Time)**
+
+- **VM**: เนื่องจากแต่ละ VM มี Guest OS เต็มรูปแบบ การเริ่มต้นและหยุด VM จะใช้เวลาค่อนข้างนาน ต้องผ่านกระบวนการบูทและการโหลด OS ซึ่งจะกินเวลาและทำให้การตอบสนองช้าลง
+- **Container**: Container ใช้เวลาในการเริ่มต้นและหยุดทำงานเร็วกว่ามาก เนื่องจาก Container ไม่ต้องบูท OS ใหม่ แต่เป็นการเรียกโปรเซสในระบบปฏิบัติการหลักโดยตรง ทำให้เหมาะสมกับแอปพลิเคชันที่ต้องการความรวดเร็วและการตอบสนองทันที
+
+5. **ขนาดของ Image และการจัดเก็บ**
+
+- **VM**: VM มีขนาดใหญ่เนื่องจากมีการเก็บข้อมูลของ Guest OS, Kernel, และข้อมูลการติดตั้งต่างๆ ซึ่งส่งผลให้การย้ายหรือแชร์ VM Image ทำได้ยากและใช้เวลาในการส่งถ่ายข้อมูลมากขึ้น
+- **Container**: Container Image มีขนาดเล็กกว่ามากเพราะไม่ต้องเก็บ OS ทั้งระบบ แต่จะบรรจุเฉพาะแอปพลิเคชันและไลบรารีที่จำเป็น การแชร์หรือย้าย Container Image จึงทำได้รวดเร็วและง่ายขึ้น
+
+6. **ความสามารถในการพกพา (Portability)**
+
+- **VM**: VM สามารถรันบนระบบที่รองรับ Hypervisor ใดๆ ที่สามารถโฮสต์ VM ได้ แต่ยังมีข้อจำกัดเนื่องจากต้องพิจารณาเวอร์ชันของ Hypervisor และการตั้งค่าที่ใช้
+- **Container**: Container มีความสามารถในการพกพาสูงมาก เนื่องจากรันบน Container Engine ที่รองรับทุกแพลตฟอร์ม เช่น Docker ทำให้แอปพลิเคชันสามารถย้ายไปยังสภาพแวดล้อมที่ต่างกันได้ง่ายและทำงานได้เหมือนกันทุกที่
+
+7. **การแยกความปลอดภัย (Isolation and Security)**
+
+- **VM**: VM มีการแยกความปลอดภัยที่ดีกว่า เนื่องจาก Guest OS แต่ละตัวมี Kernel เป็นของตนเอง และทำงานในลักษณะอิสระ การโจมตีจาก VM หนึ่งไปยัง VM อื่นหรือ Host OS จึงทำได้ยากกว่า
+- **Container**: Container มีการแยกความปลอดภัยในระดับโปรเซส ซึ่งไม่สมบูรณ์เท่า VM เนื่องจากทุก Container ใช้ Host OS ร่วมกัน ทำให้หากมีการเจาะระบบหรือโจมตีในระดับ Kernel ของ Host OS อาจส่งผลต่อ Container ทั้งหมดได้
+
+# สรุปเปรียบเทียบ
+
+ต่อไปนี้เป็นตารางเปรียบเทียบระหว่าง Virtual Machine (VM) และ Container ที่แสดงให้เห็นความแตกต่างในด้านต่างๆ:
+| **คุณสมบัติ** | **Virtual Machine (VM)** | **Container** |
+|----------------------------|---------------------------------------------------------------|----------------------------------------------------------|
+| **สถาปัตยกรรม** | ใช้ Hypervisor เพื่อสร้าง VM แยกแต่ละตัว พร้อม Guest OS | ใช้ Host OS ร่วมกันในระดับโปรเซส ไม่ต้องใช้ Hypervisor |
+| **Guest OS** | แต่ละ VM มี Guest OS ของตนเอง | ไม่มี Guest OS แยก ใช้ OS เดียวกันทั้งหมด |
+| **ขนาด** | มีขนาดใหญ่ เนื่องจากต้องรวม Guest OS | ขนาดเล็กกว่า เนื่องจากใช้ OS ร่วมกัน |
+| **ประสิทธิภาพ** | ประสิทธิภาพต่ำกว่าเนื่องจากมี Overhead ของ Guest OS | ประสิทธิภาพสูงกว่า เนื่องจากไม่มี Overhead ของ OS แยก |
+| **การเริ่มต้นใช้งาน** | ใช้เวลานาน เนื่องจากต้องบูท Guest OS | ใช้เวลาน้อยกว่าเนื่องจากไม่ต้องบูท OS |
+| **การใช้งานทรัพยากร** | ใช้ทรัพยากรสูง เนื่องจากต้องแยก OS และ Kernel | ใช้ทรัพยากรน้อยกว่าเนื่องจากใช้ OS ร่วมกัน |
+| **ความยืดหยุ่นในการพกพา** | พกพาได้เฉพาะบนแพลตฟอร์มที่รองรับ Hypervisor | พกพาสะดวก ใช้ได้ทุกที่ที่มี Container Engine |
+| **การแยกความปลอดภัย** | การแยกระดับสูงเนื่องจากมี Kernel และ OS แยกแต่ละตัว | การแยกระดับโปรเซส อาจมีข้อจำกัดด้านความปลอดภัย |
+| **การจัดการ** | ซับซ้อนกว่าในการจัดการเนื่องจากต้องดูแล OS และ Kernel แยกกัน | จัดการง่ายกว่าเพราะใช้ OS เดียวกันทั้งหมด |
+| **กรณีใช้งาน** | ใช้ในศูนย์ข้อมูลขนาดใหญ่หรือการทดสอบแยกหลายระบบ | ใช้ใน DevOps การพัฒนาแอปฯที่ต้องการยืดหยุ่นสูง |
+
+# Docker คืออะไร?
+
+Docker เป็นแพลตฟอร์มที่ช่วยให้การพัฒนาและจัดการแอปพลิเคชันเป็นไปอย่างรวดเร็วและมีประสิทธิภาพ โดย Docker ใช้เทคโนโลยี Containerization เพื่อสร้างและรันแอปพลิเคชันในรูปแบบที่เรียกว่า Container ซึ่งเป็นหน่วยการทำงานที่มีความเป็นอิสระและมีทุกสิ่งที่จำเป็นสำหรับการทำงานของแอปพลิเคชัน เช่น โค้ด, ไลบรารี, ระบบไฟล์ และตัวแปรที่จำเป็น ทำให้สามารถพกพาและรันได้อย่างยืดหยุ่นในทุกระบบที่ติดตั้ง Docker ไว้
+
+# แนวคิดเบื้องต้นเกี่ยวกับ Docker
+
+Docker เป็นแพลตฟอร์มที่ช่วยให้การสร้าง รัน และจัดการแอปพลิเคชันในรูปแบบ Container เป็นไปอย่างสะดวกและมีประสิทธิภาพ ซึ่งแตกต่างจากการใช้งาน Virtual Machine ที่ต้องจำลองระบบปฏิบัติการแยกกัน Docker จะใช้เคอร์เนลของ Host OS ร่วมกันในระดับโปรเซส ดังนั้น Container จึงมีน้ำหนักเบาและใช้ทรัพยากรน้อยกว่า VM อย่างมาก ทำให้สามารถรันหลายๆ Container พร้อมกันได้บนฮาร์ดแวร์เดียว
+
+# ส่วนประกอบสำคัญของ Docker
+
+1. **Docker Engine**: เป็นซอฟต์แวร์หลักของ Docker ที่ทำหน้าที่รันและจัดการ Container ประกอบด้วยสองส่วนสำคัญ คือ
+
+- Docker Daemon (dockerd): เป็นตัวควบคุมการทำงานของ Docker โดยทำหน้าที่ในการสร้าง จัดการ และรัน Container รวมถึงทำงานร่วมกับ Docker CLI
+- Docker CLI: เป็นเครื่องมือบรรทัดคำสั่งที่ใช้ในการสื่อสารกับ Docker Daemon ทำให้เราสามารถสั่งการ เช่น การสร้างหรือรัน Container ได้
+
+2. **Docker Image**: Docker Image เป็นต้นแบบของ Container ที่บรรจุโค้ด ไลบรารี และทรัพยากรที่จำเป็นสำหรับการทำงานของแอปพลิเคชัน โดยแต่ละ Image จะถูกสร้างจาก Dockerfile ซึ่งเป็นไฟล์ที่กำหนดขั้นตอนการสร้าง Image เช่น การติดตั้งแพ็กเกจต่างๆ การคัดลอกไฟล์ และการกำหนดค่าที่จำเป็น
+
+3. **Docker Container**: Container คือ Instance ของ Docker Image ที่รันอยู่จริง ทำให้เราสามารถใช้งานแอปพลิเคชันหรือบริการต่างๆ ได้ในรูปแบบของ Container ซึ่งทำให้มีความยืดหยุ่นในการจัดการและสามารถรันแอปพลิเคชันหลายตัวในสภาพแวดล้อมที่แยกจากกันได้อย่างปลอดภัย
+
+4. **Docker Compose**: เป็นเครื่องมือที่ใช้สำหรับจัดการหลายๆ Container ที่ต้องการทำงานร่วมกัน โดยสามารถกำหนดการตั้งค่าของแต่ละ Container ได้ในไฟล์เดียว (ไฟล์ docker-compose.yml) เช่น การเชื่อมต่อกับเครือข่าย การกำหนดค่าทรัพยากร และการตั้งค่าอื่นๆ เหมาะสำหรับการพัฒนาและทดสอบแอปพลิเคชันที่มีหลายองค์ประกอบ เช่น การรันฐานข้อมูล และเว็บเซิร์ฟเวอร์พร้อมกัน
+
+5. **Docker Hub**: เป็นบริการคลังเก็บ Image ที่มีอยู่บนอินเทอร์เน็ต Docker Hub ช่วยให้ผู้ใช้สามารถดาวน์โหลด Image ที่มีอยู่แล้ว หรืออัปโหลด Image ของตัวเองได้ ซึ่งทำให้นักพัฒนาสามารถเข้าถึง Image ต่างๆ ได้อย่างสะดวกโดยไม่ต้องสร้าง Image ใหม่จากศูนย์
+
+# การทำงานของ Docker
+
+1. สร้าง Image จาก Dockerfile: นักพัฒนาสามารถสร้าง Docker Image โดยใช้ Dockerfile ซึ่งเป็นไฟล์ที่ประกอบไปด้วยคำสั่งและขั้นตอนการติดตั้งและการตั้งค่าต่างๆ เช่น การติดตั้งไลบรารี การคัดลอกไฟล์ และการกำหนดคำสั่งที่ต้องรันเมื่อเริ่มต้น Container
+2. สร้างและรัน Container: เมื่อมี Image แล้ว สามารถสร้าง Container ได้โดยการใช้คำสั่ง เช่น docker run ซึ่งจะสร้าง Instance ของ Image ที่ทำงานอยู่จริง Container นี้จะทำงานเป็นแอปพลิเคชันที่แยกออกจากระบบปฏิบัติการหลัก แต่ยังสามารถสื่อสารกับ Host ได้ตามการตั้งค่า
+3. การจัดการ Container ด้วย Docker Compose: หากแอปพลิเคชันต้องการหลาย Container ทำงานร่วมกัน เช่น มีทั้งฐานข้อมูลและ API นักพัฒนาสามารถใช้ Docker Compose เพื่อสร้างและจัดการ Container หลายๆ ตัวพร้อมกันได้ ทำให้การตั้งค่าทั้งหมดถูกรวมอยู่ในไฟล์เดียว และสามารถเรียกใช้ทุก Container ได้ด้วยคำสั่งเดียว (docker-compose up)
+4. การจัดการและการปรับแต่ง Container: Docker รองรับการควบคุมการใช้ทรัพยากรของ Container เช่น CPU และ RAM ซึ่งช่วยให้การทำงานของแอปพลิเคชันมีประสิทธิภาพมากขึ้น โดยสามารถกำหนดการใช้ทรัพยากรให้เหมาะสมตามความต้องการ
+
+# ข้อดีของ Docker
+
+1. พกพาสะดวกและสภาพแวดล้อมคงที่: Docker ช่วยให้นักพัฒนาสามารถรันแอปพลิเคชันใน Container เดียวกันในทุกๆ สภาพแวดล้อม เช่น การพัฒนา การทดสอบ และการใช้งานจริง โดยที่ไม่ต้องปรับแต่งใหม่
+2. การจัดการทรัพยากรที่มีประสิทธิภาพ: Container ใช้ทรัพยากรน้อยกว่า Virtual Machine เพราะไม่ต้องมี Guest OS ทำให้สามารถรันหลายๆ Container พร้อมกันบนเครื่องเดียวได้อย่างมีประสิทธิภาพ
+3. การเริ่มต้นและหยุดใช้งานรวดเร็ว: Container สามารถเริ่มต้นและหยุดใช้งานได้รวดเร็ว เพราะไม่ต้องรันระบบปฏิบัติการใหม่ จึงเหมาะกับงานที่ต้องการปรับเปลี่ยนบ่อย เช่น DevOps
+4. รองรับการทำงานแบบ Microservices: Docker เหมาะกับการทำงานในสถาปัตยกรรมแบบ Microservices ที่ต้องการแยกแอปพลิเคชันออกเป็นส่วนย่อยๆ แต่ละส่วนทำงานแยกจากกันและมีความเป็นอิสระ
+5. การควบคุมและจัดการทรัพยากรง่าย: Docker ช่วยให้สามารถควบคุมการใช้ทรัพยากรของแต่ละ Container ได้อย่างละเอียด เช่น การกำหนดขีดจำกัดการใช้ CPU และ RAM เพื่อให้แอปพลิเคชันมีประสิทธิภาพที่ดีที่สุด
+
+Docker เป็นเทคโนโลยีที่ช่วยให้การพัฒนาและการจัดการแอปพลิเคชันเป็นไปอย่างรวดเร็วและยืดหยุ่นด้วยการใช้ Container ซึ่งเป็นหน่วยการทำงานที่เบากว่า Virtual Machine ช่วยให้การพัฒนาแอปพลิเคชันหลายๆ ส่วนทำงานอย่างเป็นอิสระในรูปแบบ Microservices แต่การใช้งาน Docker ก็มีข้อจำกัดเช่นกัน ซึ่งควรพิจารณาตามความเหมาะสม
+
+# Microservice คืออะไร?
+
+Microservices คือสถาปัตยกรรมการออกแบบซอฟต์แวร์ที่เน้นการแบ่งแยกส่วนของระบบออกเป็นบริการย่อยๆ (Service) ที่เป็นอิสระต่อกัน โดยแต่ละบริการจะรับผิดชอบเฉพาะงานหรือฟังก์ชันหนึ่งๆ ของระบบ และสามารถสื่อสารกับบริการอื่นๆ ผ่านโปรโตคอล API (เช่น HTTP/REST, gRPC, หรือ Message Queue) ทำให้ระบบมีความยืดหยุ่นสูง สามารถพัฒนา ทดสอบ และปรับปรุงแต่ละส่วนแยกกันได้ รวมทั้งมีความสามารถในการสเกล (Scale) ตามความต้องการได้ดีกว่าการออกแบบระบบแบบ Monolithic ที่รวมทุกฟังก์ชันไว้ในแอปพลิเคชันเดียว
+
+# แนวคิดและการทำงานของ Microservices
+
+ในการออกแบบแบบ Microservices ระบบจะถูกแบ่งเป็นบริการย่อยๆ ซึ่งแต่ละบริการจะรับผิดชอบหน้าที่อย่างใดอย่างหนึ่ง เช่น การจัดการข้อมูลผู้ใช้ การประมวลผลข้อมูล การจัดการคำสั่งซื้อ เป็นต้น การแบ่งแยกแบบนี้ทำให้ทุกบริการมีความเป็นอิสระ สามารถปรับแต่งและพัฒนาแยกจากกันได้โดยไม่กระทบส่วนอื่นๆ ของระบบ ตัวอย่างเช่น:
+
+- **User Service** – จัดการข้อมูลผู้ใช้และการยืนยันตัวตน
+- **Product Service** – จัดการข้อมูลสินค้า
+- **Order Service** – จัดการข้อมูลคำสั่งซื้อ
+
+# องค์ประกอบสำคัญของ Microservices
+
+1. **การแยกเป็นอิสระ (Decentralized Services)**: แต่ละบริการจะทำงานแยกจากกันโดยสมบูรณ์ สามารถพัฒนาและปรับปรุงโดยทีมงานที่ดูแลเฉพาะบริการนั้นๆ ได้โดยไม่ส่งผลกระทบต่อบริการอื่นๆ
+
+2. **การสื่อสารผ่าน API**: Microservices สื่อสารระหว่างกันโดยใช้ API เช่น RESTful, gRPC, หรือใช้ Message Queue อย่าง RabbitMQ, Kafka เป็นต้น ทำให้บริการเหล่านี้สามารถแลกเปลี่ยนข้อมูลระหว่างกันได้แม้จะอยู่บนสถาปัตยกรรมหรือภาษาโปรแกรมที่ต่างกัน
+
+3. **ฐานข้อมูลแยกส่วน (Decentralized Data Management)**: แต่ละบริการมีฐานข้อมูลเป็นของตัวเอง ทำให้สามารถใช้ฐานข้อมูลประเภทที่เหมาะสมกับงานของตน เช่น บริการจัดการผู้ใช้อาจใช้ฐานข้อมูล SQL ในขณะที่บริการวิเคราะห์ข้อมูลอาจใช้ NoSQL หรือฐานข้อมูลเชิงกราฟ (Graph Database)
+
+4. **ความสามารถในการสเกล (Scalability)**: Microservices สามารถเพิ่มหรือลดจำนวน Instance ของบริการได้ตามความต้องการ เช่น หากบริการจัดการคำสั่งซื้อต้องรองรับปริมาณการใช้งานมาก สามารถเพิ่มจำนวนของ Order Service ได้โดยไม่ต้องเพิ่มบริการอื่นๆ
+
+5. **การใช้เทคโนโลยีที่เหมาะสม (Polyglot Programming)**: ในสถาปัตยกรรม Microservices แต่ละบริการสามารถเลือกใช้ภาษาโปรแกรมและเทคโนโลยีที่เหมาะสมกับงานของตัวเอง เช่น ใช้ Python สำหรับการวิเคราะห์ข้อมูล ใช้ Java หรือ .NET สำหรับระบบหลัก เป็นต้น
+
+6. **การติดตั้งและปรับปรุงง่าย (Continuous Deployment)**: แต่ละบริการสามารถปรับปรุง แก้ไข และติดตั้งใหม่ได้อิสระ โดยไม่จำเป็นต้องปล่อยซอฟต์แวร์ทั้งหมดใหม่ ซึ่งช่วยให้การปรับปรุงหรือแก้ไขบั๊กสามารถทำได้ทันที
+
+# ข้อดีของ Microservices
+
+1. **ความยืดหยุ่นในการพัฒนาและการทำงานเป็นทีม**: ทีมพัฒนาสามารถรับผิดชอบเฉพาะบริการที่ตนพัฒนาได้โดยตรง ทำให้แต่ละทีมสามารถเลือกเทคโนโลยีและการทำงานที่เหมาะสมได้ ช่วยให้ระบบพัฒนาได้เร็วขึ้นและมีคุณภาพสูงขึ้น
+
+2. **ความสามารถในการสเกลสูง**: Microservices สามารถเพิ่มหรือลดจำนวนของบริการต่างๆ ตามการใช้งานจริงได้ การสเกลนี้ช่วยให้เรารองรับปริมาณการใช้งานที่เพิ่มขึ้นได้โดยไม่ต้องเพิ่มกำลังทุกส่วนของระบบ
+
+3. **รองรับการเปลี่ยนแปลงและปรับปรุงได้ง่าย**: การอัปเดตหรือปรับปรุงสามารถทำได้เฉพาะในบางบริการ ไม่จำเป็นต้องปรับปรุงทั้งระบบ จึงช่วยลดความเสี่ยงและเวลาในการปรับปรุง
+
+4. **ความทนทาน (Fault Tolerance)**: หากบริการหนึ่งล้มเหลว บริการอื่นๆ ที่เหลือจะยังทำงานต่อไปได้ ซึ่งช่วยลดผลกระทบจากปัญหาที่เกิดขึ้นกับบริการบางส่วน
+
+# ข้อเสียของ Microservices
+
+1. **ความซับซ้อนในการออกแบบและจัดการ**: เนื่องจาก Microservices ต้องมีการเชื่อมโยงบริการหลายๆ ตัว การออกแบบและจัดการสถาปัตยกรรมจึงซับซ้อนมากขึ้น ทำให้ต้องมีการวางแผนที่ดีในเรื่องของการจัดการบริการ การตรวจสอบ และการบำรุงรักษา
+
+2. **ภาระในการสื่อสารระหว่างบริการ**: การสื่อสารระหว่างบริการต้องอาศัยโปรโตคอล เช่น HTTP, gRPC, หรือ Message Queue ซึ่งทำให้เกิดความหน่วง (Latency) และทำให้ต้องมีการจัดการกับการเกิดความล้มเหลวในการสื่อสาร
+
+3. **ค่าใช้จ่ายในการบำรุงรักษาสูงขึ้น**: เนื่องจากแต่ละบริการมีฐานข้อมูลและทรัพยากรแยกกัน ทำให้มีค่าใช้จ่ายและความยุ่งยากในการบำรุงรักษามากขึ้น รวมถึงการจัดการด้านความปลอดภัยและการสำรองข้อมูลที่ซับซ้อน
+
+4. **การทดสอบยากขึ้น**: การทดสอบ Microservices ต้องตรวจสอบการทำงานของแต่ละบริการและการทำงานร่วมกัน ซึ่งทำให้ต้องออกแบบการทดสอบที่ซับซ้อนมากขึ้น รวมถึงต้องใช้เครื่องมือเฉพาะสำหรับการทดสอบระบบที่มีหลายบริการ
+
+# การใช้งาน Microservices ในโลกจริง
+
+1. **การพัฒนาแอปพลิเคชันแบบ Cloud-native**: Microservices เป็นพื้นฐานของการพัฒนาแอปพลิเคชันแบบ Cloud-native ที่ใช้ Cloud Infrastructure ในการบริหารจัดการ เช่น การใช้ Kubernetes เพื่อจัดการบริการในรูปแบบ Container ซึ่งทำให้การปรับขนาดและการจัดการทรัพยากรเป็นไปอย่างมีประสิทธิภาพ
+
+2. **การจัดการทราฟฟิกด้วย API Gateway**: ระบบที่ใช้ Microservices จะมีบริการหลายตัวทำงานร่วมกัน ดังนั้นการใช้ API Gateway ช่วยจัดการการเข้าถึงบริการทั้งหมดให้เป็นระบบระเบียบ และจัดการทราฟฟิกที่เข้าถึงบริการต่างๆ ได้อย่างมีประสิทธิภาพ
+
+3. **การนำมาใช้ในองค์กรที่มีการเปลี่ยนแปลงบ่อย**: เนื่องจาก Microservices สามารถปรับปรุงเฉพาะส่วนได้ จึงเหมาะกับองค์กรที่ต้องการเปลี่ยนแปลงและปรับปรุงซอฟต์แวร์อย่างต่อเนื่องเพื่อรองรับตลาดหรือการพัฒนาใหม่ๆ
+
+# การเปรียบเทียบ Microservices กับ Monolithic
+
+| **คุณสมบัติ**               | **Monolithic Architecture**               | **Microservices Architecture**            |
+| --------------------------- | ----------------------------------------- | ----------------------------------------- |
+| **การพัฒนา**                | ทุกฟังก์ชันรวมอยู่ในแอปพลิเคชันเดียว      | แต่ละฟังก์ชันแยกเป็นบริการย่อยๆ           |
+| **การสเกล**                 | สเกลทั้งแอปพลิเคชันพร้อมกัน               | สเกลเฉพาะบริการที่ต้องการได้              |
+| **ความซับซ้อน**             | จัดการง่าย แต่ไม่ยืดหยุ่น                 | ซับซ้อนกว่าแต่มีความยืดหยุ่นสูง           |
+| **การปรับปรุง**             | ต้องปรับปรุงทั้งแอปพลิเคชัน               | ปรับปรุงเฉพาะบริการได้โดยไม่กระทบส่วนอื่น |
+| **การพัฒนาแบบทีม**          | ทีมต้องทำงานร่วมกันบนแอปพลิเคชันเดียว     | ทีมสามารถพัฒนาและจัดการบริการแยกกัน       |
+| **การปรับใช้ (Deployment)** | ปรับใช้ทั้งหมดพร้อมกันเป็นแพ็กเกจเดียว    | ปรับใช้ทีละบริการได้ตามความต้องการ        |
+| **การบำรุงรักษา**           | ซับซ้อนเมื่อแอปพลิเคชันขยายขนาด           | บำรุงรักษาแต่ละบริการได้แยกกัน            |
+| **ความทนทาน**               | ปัญหาส่วนใดส่วนหนึ่งอาจส่งผลกระทบทั้งระบบ | หากบริการใดล้มเหลว บริการอื่นยังทำงานได้  |
+| **การใช้เทคโนโลยี**         | ใช้เทคโนโลยีเดียวทั้งระบบ                 | แต่ละบริการเลือกใช้เทคโนโลยีที่เหมาะสมได้ |
+
+Microservices เป็นสถาปัตยกรรมที่ช่วยให้แอปพลิเคชันมีความยืดหยุ่นและสามารถปรับเปลี่ยนตามความต้องการขององค์กรได้ ทำให้แต่ละส่วนของระบบเป็นอิสระจากกัน ซึ่งเหมาะกับการพัฒนาแอปพลิเคชันที่มีการเปลี่ยนแปลงบ่อย หรือแอปพลิเคชันขนาดใหญ่ที่ต้องการประสิทธิภาพในการจัดการทรัพยากรและการสเกล
+
+# API Gateway คืออะไร?
+
+API Gateway คือส่วนกลางในการจัดการการสื่อสารระหว่างผู้ใช้ (Client) และบริการต่างๆ ภายในระบบที่ใช้สถาปัตยกรรมแบบ Microservices โดยมีหน้าที่รับคำขอจากผู้ใช้ ส่งต่อคำขอนั้นไปยังบริการต่างๆ ที่เกี่ยวข้อง และส่งผลลัพธ์กลับไปยังผู้ใช้ ซึ่งช่วยให้การสื่อสารภายในระบบเป็นไปอย่างมีประสิทธิภาพและง่ายต่อการจัดการ นอกจากนี้ API Gateway ยังมีฟังก์ชันในการจัดการการควบคุมการเข้าถึง (Access Control), การรักษาความปลอดภัย (Security), การจัดการการสเกล (Load Balancing) และการแคชข้อมูล (Caching) ทำให้เป็นส่วนสำคัญของระบบ Microservices ที่มีการจัดการหลายบริการ
+
+# หน้าที่และการทำงานของ API Gateway
+
+1. การควบคุมเส้นทาง (Routing): API Gateway ทำหน้าที่จัดการเส้นทางของคำขอที่เข้ามา โดยจะแยกแยะและส่งคำขอนั้นไปยังบริการที่เกี่ยวข้อง เช่น หากผู้ใช้ขอข้อมูลผู้ใช้งาน API Gateway จะส่งคำขอนั้นไปยัง User Service เป็นต้น
+
+2. การแปลงข้อมูล (Transformation): ในบางครั้ง คำขอและการตอบกลับจำเป็นต้องมีการแปลงข้อมูลหรือจัดรูปแบบให้ตรงกับความต้องการของผู้ใช้ เช่น การแปลงข้อมูลจาก XML เป็น JSON เพื่อความสะดวกในการใช้งาน
+
+3. การควบคุมการเข้าถึง (Access Control): API Gateway ทำหน้าที่ตรวจสอบสิทธิ์และการรับรองตัวตน (Authentication & Authorization) ของผู้ใช้ เช่น ตรวจสอบว่าเป็นผู้ใช้ที่ได้รับอนุญาตหรือไม่ก่อนส่งคำขอไปยังบริการต่างๆ ทำให้ระบบมีความปลอดภัยมากขึ้น
+
+4. การรักษาความปลอดภัย (Security): API Gateway สามารถจัดการการป้องกันภัยคุกคามต่างๆ เช่น การป้องกันการโจมตีแบบ DDoS, การใช้ HTTPS เพื่อลดความเสี่ยงในการแอบดักข้อมูลระหว่างการสื่อสาร และการจำกัดอัตราการเรียกใช้งาน (Rate Limiting) เพื่อป้องกันการใช้งานที่มากเกินไป
+
+5. การจัดการแคช (Caching): API Gateway มีการเก็บข้อมูลที่ถูกเรียกใช้บ่อยในหน่วยความจำ เพื่อเพิ่มประสิทธิภาพในการให้บริการ โดยไม่ต้องส่งคำขอไปยังบริการต้นทางทุกครั้ง ช่วยลดภาระงานของบริการต่างๆ
+
+6. การควบคุมการสเกล (Load Balancing): API Gateway ช่วยกระจายคำขอที่เข้ามายังเซิร์ฟเวอร์หรือบริการต่างๆ เพื่อให้โหลดการทำงานมีความสมดุลและช่วยให้ระบบรองรับปริมาณการใช้งานที่สูงขึ้นได้อย่างมีประสิทธิภาพ
+
+7. การตรวจสอบและวิเคราะห์ (Monitoring & Analytics): API Gateway สามารถรวบรวมข้อมูลการใช้งาน เช่น จำนวนคำขอ, ระยะเวลาการตอบกลับ, และสถิติการใช้งาน ซึ่งข้อมูลเหล่านี้สามารถนำไปวิเคราะห์เพื่อปรับปรุงบริการและแก้ไขปัญหาที่อาจเกิดขึ้นได้
+
+# ข้อดีของการใช้ API Gateway
+
+1. เพิ่มความปลอดภัยให้กับระบบ: API Gateway ช่วยให้สามารถรวมการจัดการด้านความปลอดภัยไว้ในจุดเดียว เช่น การจัดการการตรวจสอบสิทธิ์ (Authentication), การกำหนดนโยบายการเข้าถึง (Authorization Policy) ช่วยลดความเสี่ยงจากภัยคุกคาม
+
+2. จัดการการสื่อสารที่ซับซ้อนได้ง่ายขึ้น: API Gateway ทำหน้าที่เป็นศูนย์กลางการสื่อสารกับบริการย่อย ทำให้การจัดการคำขอและการกำหนดเส้นทาง (Routing) เป็นไปอย่างง่ายและมีระเบียบ
+
+3. เพิ่มประสิทธิภาพด้วยการแคช: คำขอบางคำขอ เช่น ข้อมูลที่มีการเปลี่ยนแปลงน้อย สามารถแคชไว้ใน API Gateway เพื่อลดการเรียกไปยังบริการต้นทาง ทำให้ระบบเร็วขึ้น
+
+4. รองรับการสเกลที่ดีขึ้น: API Gateway ช่วยกระจายโหลดไปยังบริการต่างๆ และช่วยลดภาระการประมวลผลในระบบ ลดความเสี่ยงที่จะเกิดปัญหาโหลดเกินในบางบริการ
+
+5. รวมการตรวจสอบการใช้งานไว้ในจุดเดียว: ช่วยให้นักพัฒนาสามารถตรวจสอบการใช้งานระบบแบบรวมศูนย์ ซึ่งช่วยในการตรวจหาปัญหาได้รวดเร็ว รวมถึงการบันทึกข้อมูลการใช้งานที่ช่วยวิเคราะห์และปรับปรุงบริการได้
+
+# ข้อเสียของการใช้ API Gateway
+
+1. เป็น Single Point of Failure: หาก API Gateway เกิดปัญหา ระบบทั้งหมดอาจไม่สามารถทำงานได้ ดังนั้นจึงต้องมีการวางแผนการทำงานแบบสำรอง (Redundancy) หรือการกระจายการใช้งานเพื่อป้องกันปัญหา
+
+2. เพิ่มความซับซ้อนของระบบ: การเพิ่ม API Gateway จะทำให้ระบบมีโครงสร้างซับซ้อนมากขึ้น โดยเฉพาะเมื่อมีการใช้งานร่วมกับหลายบริการและมีการกำหนดนโยบายต่างๆ มากมาย
+
+3. เกิดความล่าช้าเพิ่มขึ้น (Latency): การที่คำขอทั้งหมดต้องผ่าน API Gateway ก่อนที่จะไปยังบริการปลายทาง อาจทำให้เกิดความล่าช้าในระบบโดยเฉพาะหากมีการแปลงข้อมูลหรือแคชที่ซับซ้อน
+
+# การใช้งาน API Gateway ในโลกจริง
+
+- การจัดการการเข้าถึงหลายบริการในระบบ Microservices: API Gateway ช่วยให้ผู้ใช้สามารถเข้าถึงบริการต่างๆ ของระบบที่มีโครงสร้างแบบ Microservices ได้ผ่านจุดเดียว เช่น การเข้าสู่ระบบผู้ใช้ ที่ API Gateway สามารถรับคำขอและส่งต่อไปยังบริการย่อย เช่น บริการตรวจสอบตัวตน บริการจัดการข้อมูลผู้ใช้ เป็นต้น
+
+- การจัดการแอปพลิเคชันที่รองรับผู้ใช้หลายประเภท: เช่น ระบบอีคอมเมิร์ซที่ต้องรองรับทั้งผู้ใช้ทั่วไปและแอปพลิเคชันที่เป็น Partner สามารถกำหนดสิทธิ์และการเข้าถึงได้แตกต่างกันผ่าน API Gateway เพื่อควบคุมการเข้าถึง
+
+- การจัดการทราฟฟิกในระบบที่มีปริมาณการเข้าถึงสูง: เช่น บริการที่ใช้ในแอปพลิเคชันแบบ SaaS (Software as a Service) API Gateway จะช่วยกระจายโหลดและควบคุมปริมาณการเข้าถึง
+
+API Gateway เป็นส่วนสำคัญในระบบ Microservices ที่ช่วยจัดการการสื่อสารระหว่างผู้ใช้และบริการต่างๆ ภายในระบบ ทำให้การจัดการการเข้าถึงมีความปลอดภัย และระบบมีความเป็นระเบียบและสามารถปรับแต่งตามความต้องการได้ เช่น การควบคุมการเข้าถึง การแปลงข้อมูล การจัดการการแคชและการกระจายโหลด การใช้ API Gateway ช่วยให้การจัดการระบบขนาดใหญ่ที่มีหลายบริการเป็นไปอย่างมีประสิทธิภาพ
+
+# สุปการนำเอาเทคโนโลยี Container, Docker, Microservices และ API Gateway มาใช้ในการพัฒนาระบบ
+
+การใช้ Docker Containers, Microservices, และ API Gateway เป็นแนวทางการพัฒนาแอปพลิเคชันในยุคปัจจุบันเป็นแนวทางที่ได้รับความนิยมสูงมาก เนื่องจากมันช่วยปรับปรุงในหลายๆ ด้าน ทั้งในเรื่อง ประสิทธิภาพ, ความทันสมัย, และ ความปลอดภัย นี่คือการสรุปข้อดีของการใช้แนวทางเหล่านี้:
+
+1. **ประสิทธิภาพ (Performance)**
+
+- Docker Containers: การใช้ Docker ช่วยให้การพัฒนาและการดำเนินงานสามารถแยกกันได้ชัดเจนระหว่างบริการต่างๆ ทำให้สามารถประมวลผลแยกกันได้ดี การจัดการกับ resource และการขยายขนาด (scaling) ทำได้ง่ายและมีประสิทธิภาพสูงขึ้น เนื่องจาก containers สามารถทำงานได้บนเครื่องหลายเครื่องหรือหลายสภาพแวดล้อมได้โดยไม่ต้องแก้ไขโค้ด
+- Microservices: การแบ่งแอปพลิเคชันออกเป็น Microservices ช่วยให้สามารถพัฒนาและปรับปรุงบริการแต่ละตัวได้อย่างรวดเร็วและมีประสิทธิภาพ ไม่ต้องปรับแก้ระบบทั้งหมด ระบบสามารถขยายได้ตามความต้องการ (elastic scaling) และรองรับการทำงานในหลายภูมิภาคหรือเซิร์ฟเวอร์
+- API Gateway: ทำหน้าที่เป็นตัวกลางในการจัดการการเรียกใช้งานบริการต่างๆ ของ Microservices ช่วยลดภาระการจัดการการเชื่อมต่อที่ซับซ้อนระหว่าง microservices และช่วยเพิ่มความเร็วในการประมวลผลการเรียก API รวมถึงสามารถปรับแต่งการใช้ API ได้อย่างมีประสิทธิภาพ
+
+2. **ความทันสมัย (Modernization)**
+
+- การใช้ Docker และ Microservices ช่วยให้การพัฒนาระบบสามารถปรับตัวได้อย่างรวดเร็วตามเทคโนโลยีใหม่ๆ ได้ง่าย เพราะแต่ละ Microservice สามารถใช้เทคโนโลยีหรือเวอร์ชันที่ต่างกันได้ตามความเหมาะสม
+- API Gateway ทำให้การเชื่อมต่อระหว่างบริการต่างๆ สามารถทำได้ในลักษณะของ "Single Entry Point" ช่วยเพิ่มความสะดวกในการจัดการและบำรุงรักษาระบบ
+- แนวทางเหล่านี้ช่วยให้นักพัฒนาสามารถใช้ CI/CD (Continuous Integration / Continuous Deployment) เพื่ออัพเดทระบบได้บ่อยและสะดวก ทำให้สามารถนำเทคโนโลยีและฟีเจอร์ใหม่ๆ มาใช้งานได้อย่างรวดเร็ว
+
+3. **ความปลอดภัย (Security)**
+
+- Docker: Docker ช่วยแยกแต่ละบริการใน containers ทำให้การจัดการสิทธิ์การเข้าถึงหรือการใช้งานระบบสามารถทำได้ดีขึ้น ถ้าเกิดการเจาะระบบใน container หนึ่งก็ไม่สามารถเข้าถึงข้อมูลใน container อื่นได้ทันที
+- Microservices: การแยกบริการออกเป็น Microservices ช่วยจำกัดการเข้าถึงข้อมูลและลดการเสี่ยงจากการโจมตีแบบ "single point of failure" เนื่องจากระบบแยกออกเป็นส่วนๆ ที่สามารถควบคุมการเข้าถึงได้อย่างชัดเจน
+- API Gateway: API Gateway ทำหน้าที่เป็นตัวกลางในการรับส่งข้อมูลและการเข้าถึง APIs ซึ่งช่วยให้สามารถควบคุมการเข้าถึงด้วยการใช้งานเช่นการพิสูจน์ตัวตน (Authentication), การอนุญาต (Authorization), การป้องกันการโจมตี (Rate Limiting), และการตรวจสอบความปลอดภัย (Security Auditing)
+
+การใช้ Docker Containers, Microservices, และ API Gateway ไม่เพียงแต่ช่วยเพิ่ม ประสิทธิภาพ ในการพัฒนาและการขยายระบบ แต่ยังช่วยในการทำให้ระบบมีความ ทันสมัย และสามารถรองรับเทคโนโลยีใหม่ๆ ได้อย่างง่ายดาย พร้อมทั้งสามารถรักษาความ ปลอดภัย ของระบบได้อย่างมีประสิทธิภาพ
+
+การนำเทคโนโลยีเหล่านี้มาปรับใช้ในการพัฒนาระบบทำให้การสร้างแอปพลิเคชันที่มีความยืดหยุ่นสูง, ปรับขยายได้ตามต้องการ และตอบสนองต่อความปลอดภัยในยุคดิจิทัลได้เป็นอย่างดี
+
+# ขั้นตอนการติดตั้งระบบ
+
 เอกสารสำหรับการติดตั้งระบบของ BMA HRMS โปรแกรมในยุคปัจจุบันจะทำงานบนเทคโนโลยีคอนเทนเนอร์ เพื่อยืดหยุ่นในการทำงาน ตั้งแต่การพัฒนา ทดสอบและ ใช้งานจริง (Production) จำเป็นต้องเข้าใจพื้นฐานการทำงาน Docker เสียก่อน ก็จะสามารถจัดการบริการเพิ่มเติมที่จะเกิดขึ้นอนาคต เนื่องจากการใช้งานเป็นรูปแบบเดียวกัน นอกจากการใช้งานผ่านคำสั่งแล้วสามารถใช้ Portainer ในการจัดการผ่าน Web UI ได้ การติดตั้งจะอยู่ในเอกสารนี้
 
 ![Network Diagram](images/buildanddeploy/build-network-diagram.png)
 
 ## ติดตั้ง Docker
+
 Docker คอนเทนเนอร์สามารถเรียนรู้ ตั้งค่า ดูแล รักษาได้ง่ายและรวดเร็ว รองรับการขยายตัว สามารถเพิ่มคลัสเตอร์ได้ง่าย และสามารถปรับเปลี่ยนเป็น Kubernates ได้ในอนาคต
 สำหรับเอกสารนี้จะเป็นการติดตั้ง Docker บน debian 12 สำหรับบนวินโดว์(เพื่อการทดสอบเท่านั้น)ให้ติดตั้งบน WSL2 หรือใช้ Linux VM
 การติดตั้งโดยละเอียดดูได้จาก [คู่มือในเวปของ Docker](https://docs.docker.com/engine/install/debian/) วิธีการติดตั้งแบบย่อผ่าน
@@ -16,11 +280,13 @@ sudo sh get-docker.sh
 sudo usermod -aG docker user_name
 sudo usermod -aG sudo user_name
 ```
+
 แทน user_name ด้วยยูสเซอร์ที่ใช้ดูแลระบบ ในตัวอย่างจะให้อยู่ในกรุป docker และ sudo เพื่อให้มีสิทธิ์ในจัดการ service และไฟล์ที่เกิดจาก docker
 
 ## คำสั่ง Docker พื้นฐาน
 
 คำสั่งพื้นฐานของ docker ที่ใช้
+
 ```sh
 docker ps       # ดูรายการคอนเทนเนอร์ที่รันอยู่ในระบบ
 docker images   # ดูรายการอิมเมจที่มีในระบบ
@@ -28,10 +294,12 @@ docker pull [image_name:tag]        # ดึงอิมเมจมาในร
 docker network ls                   # แสดงรายการเน็ตเวิร์กของ docker
 docker network create [network_name] # สร้างเน็ตเวิร์กของ docker
 ```
+
 docker compose จะรันคอนเทนเนอร์ของ docker หลายๆตัวพร้อมกันได้ โดยดูการตั้งค่าจากไฟล์ compose.yaml หรือ docker-compose.yaml
 ที่อยู่ในโฟลเดอร์ที่เรียกคำสั่ง ในการทำงานทั่วไปเพื่อที่จะให้ง่ายต่อการใช้งาน จะใช้ docker compose เป็นหลัก ซึ่งจะมีผลเฉพาะ service ที่เขียนไว้ในไฟล์ compose
 
 คำสั่ง docker compose พื้นฐาน (ต้องมีไฟล์ compose.yaml หรือ docker-compose.yaml ในโฟลเดอร์ที่เรียกคำสั่ง)
+
 ```sh
 docker compose ps     # ดูรายการ service ที่ทำงานอยู่
 docker compose up -d  # เรียกทุก service ขึ้นมาทำงาน
@@ -39,18 +307,22 @@ docker compose up -d [service_name] # เรียกเฉพาะ serfvice
 ```
 
 โฟลเดอร์ที่ใช้เริ่มต้นสร้างโปรแกรม บริการต่างๆในหัวข้อต่อๆไปจะสร้างภายใต้ ~/docker/hrms และใช้เน็ตเวิร์กชื่อ hrms ในการสื่อสารระหว่างกัน ทำให้สามารถเรียกใช้ชื่อ service แทน IP Address ได้เหมือนมี DNS ภายใน
+
 ```sh
 docker network create hrms # สร้างเน็ตเวิร์ก hrms
 mkdir -p ~/docker/hrms     # สร้างโฟลเดอร์
 cd ~/docker/hrms           # เข้าไปในโฟลเดอร์
 ```
+
 ทดสอบการทำงานของ docker ให้สร้างโฟลเดอร์ simple-web มีไฟล์ compose.yaml สร้างโฟลเดอร์ html แล้วสร้างไฟล์ html/index.html ในโฟลเดอร์นั้นพร้อมเนื้อหาเรียกคำสั่ง docker compose up -d
+
 ```sh
 mkdir -p simple-web/html
 cd simple-web
 nano compose.yaml    # สร้างไฟล์ compose
 nano html/index.html # สร้างหน้าเวปสำหรับทดสอบ
 ```
+
 ไฟล์ compose.yaml
 เป็นตัวอย่างแบบง่ายเพื่อใช้งาน nginx เป็นเวปเซิร์ฟเวอร์ ที่พอร์ต 9082 บนเครื่องโฮส ถ้าไม่สั่งหยุดการทำงาน nginx จะเริ่มตัวเองเองถ้าโฮสเปิดขึ้นเครื่องใหม่ ทำงานในเน็ตเวิร์ก hrms การใช้งานใช้เว็บบราวเซอร์ไปที่ http://IP:9082
 
@@ -59,9 +331,9 @@ services:
   web:
     image: nginx
     volumes:
-     - ./html:/usr/share/nginx/html:ro
+      - ./html:/usr/share/nginx/html:ro
     ports:
-     - "9082:80"
+      - "9082:80"
     restart: unless-stopped
     networks:
       hrms:
@@ -71,6 +343,7 @@ networks:
 ```
 
 ## Services
+
 การออกแบบใช้สถาปัตยกรรม Microservice จะประกอบจากหลาย Service เพื่อความเป็นระเบียบจะแบ่งไว้สามโฟลเดอร์ apisix(API Gateway), bmahrms-service(3rd Party service), bmahrms(HRMS services)
 
 ```sh
@@ -81,18 +354,22 @@ mkdir -p bmahrms
 ```
 
 ### APISIX (API Gateway)
+
 ทำหน้าที่จัดการ https, limit, security, load balance,reverse proxy, และ route ใน Microservice ก่อนใช้งานให้ตั้งค่าโดเมนกับ Public IP ให้เรียบร้อยแล้ว Forward Port 80/443 มาที่เครื่องนี้
 การตั้งค่าต่างๆจะทำผ่าน Web API ในตัวอย่างจะใช้ curl
+
 ```sh
 mkdir -p apisix/apisix_conf/
 nano apisix/apisix_conf/config.yaml # configuration
 nano apisix/compose.yaml            # compose file
 docker compose up -d
 ```
+
 apisix/apisix_conf/config.yaml เป็นไฟล์คอนฟิกของ APISIX แก้ค่า put_admin_api_key_here, allow_admin ให้เหมาะสม
+
 ```yaml
 apisix:
-  node_listen: 9080              # APISIX listening port
+  node_listen: 9080 # APISIX listening port
   enable_ipv6: false
   enable_control: true
   control:
@@ -100,23 +377,24 @@ apisix:
     port: 9092
 deployment:
   admin:
-    allow_admin:               # https://nginx.org/en/docs/http/ngx_http_access_module.html#allow
+    allow_admin: # https://nginx.org/en/docs/http/ngx_http_access_module.html#allow
-      - 0.0.0.0/0              # We need to restrict ip access rules for security. 0.0.0.0/0 is for test.
+      - 0.0.0.0/0 # We need to restrict ip access rules for security. 0.0.0.0/0 is for test.
     admin_key:
       - name: "admin"
         key: put_admin_api_key_here
-        role: admin                 # admin: manage all configuration data
+        role: admin # admin: manage all configuration data
   etcd:
-    host:                           # it's possible to define multiple etcd hosts addresses of the same etcd cluster.
+    host: # it's possible to define multiple etcd hosts addresses of the same etcd cluster.
-      - "http://etcd:2379"          # multiple etcd address
+      - "http://etcd:2379" # multiple etcd address
-    prefix: "/apisix"               # apisix configurations prefix
+    prefix: "/apisix" # apisix configurations prefix
-    timeout: 30                     # 30 seconds
+    timeout: 30 # 30 seconds
 plugin_attr:
   prometheus:
     export_addr:
       ip: "0.0.0.0"
       port: 9091
 ```
+
 apisix/compose.yaml จะมีสอง service ตัว apisix จะเป็นโปรแกรมหลัก ส่วน etcd ฐานข้อมูลแบบกระจายตัว ใช้สำหรับเก็บการตั้งค่าของ apisix
 
 ```yaml
@@ -164,7 +442,8 @@ volumes:
   etcd_data:
     driver: local
 ```
-วิธีการติดตั้ง certificate(HTTPS) เนื่องจากของ *bangkok.go.th มี intermediate certificate 
+
+วิธีการติดตั้ง certificate(HTTPS) เนื่องจากของ \*bangkok.go.th มี intermediate certificate
 ให้นำ root CA รวมกับ intermediate เพื่อให้พร้อมใช้งาน การตั้งค่า APISIX จะทำผ่าน Web API ใช้ curl และ api-key ที่ตั้งไว้
 
 ```sh
@@ -179,16 +458,19 @@ curl http://127.0.0.1:9180/apisix/admin/ssls/1 \
      "snis": ["*.bangkok.go.th"]
 }'
 ```
+
 ถ้ามีการเซ็ต route ผ่าน APISIX สามารถทดสอบ ผ่าน curl ได้ด้วยคำสั่งนี้(การเซ็ตค่าจะอยู่ในหัวข้ออื่น)
+
 ```sh
 curl https://bma-hrms-id.bangkok.go.th -vvv
 ```
 
-
 ### 3rd Party Service (bmahrms-service)
+
 โปรแกรมกลุ่มนี้ที่พัฒนาโดย 3rd Party หรือ Frappet ไม่ได้มีฟังก์ชั่นงานเจาะจงสำหรับ HRMS ถูกใช้โดยโปรแกรมของ HRMS(เช่นฐานข้อมูล,เวปเซิร์ฟเวอร์ ฯลฯ) จะแยกมาใส่โฟลเดอร์ bmahrms-service
 การติดตั้งให้นำ compose.yaml และ คอนฟิกมาใส่โฟลเดอร์ bmahrms-service ให้เรียบร้อยก่อนใช้งาน สร้างโฟลเดอร์แต่ละ servie ทำดังนี้
-- Keycloak(bmahrms-postgres bmahrms-id)  เซิร์ฟเวอร์สำหรับจัดการยูสเซอร์และการ Authentication ในระบบ 
+
+- Keycloak(bmahrms-postgres bmahrms-id) เซิร์ฟเวอร์สำหรับจัดการยูสเซอร์และการ Authentication ในระบบ
 - MySQL(bmahrms-mysql) เป็นฐานข้อมูลของระบบ
 - MiniO(bmahrms-s3) เป็น Object Storage แบบเดียวกับ AWS s3 ใช้สำหรับเก็บไฟล์ มีประสิทธิ์ภาพสูงสามารถรับโหลดหนัก มีความปลอดภัยกว่าเก็บด้วยระบบไฟล์ทั่วไป สามารถขยายเพิ่มได้ในอนาคต ถูกใช้ในหลายระบบที่ต้องการเก็บไฟล์
 - Windmill รันเวิร์กโฟลว์การทำงานอัตโนมัติจากสคริปต์ หลักๆใช้เพื่อรันตัวสำรองข้อมูล
@@ -198,6 +480,7 @@ curl https://bma-hrms-id.bangkok.go.th -vvv
 - Frappet EDM ใช้สำหรับจัดการเอกสารที่ปลอดภัยรองรับโหลดจำนวนมากได้ จะมีระบบย่อยเบื้องหลังหลายตัว (bmahrms-edm,bmahrms-elasticsearch,bmahrms-kibana,bmahrms-mq)
 
 docker/bmahrms-service/compose.yaml ให้แก้ตัวแปรให้เหมาะสมตาม
+
 ```yaml
 networks:
   hrms:
@@ -268,7 +551,7 @@ services:
   bmahrms-mysql:
     image: mysql:8.0.17
     env_file: "service.env"
-    command: [ "--max_connections=5000" ]
+    command: ["--max_connections=5000"]
     restart: unless-stopped
     ports:
       - "9123:3306"
@@ -308,7 +591,7 @@ services:
     volumes:
       - kibana_data:/usr/share/kibana/data
     ports:
-     - 2130:5601
+      - 2130:5601
     restart: always
     networks:
       - hrms
@@ -354,13 +637,18 @@ services:
     networks:
       - hrms
 ```
+
 รันคำสั่งดังนี้ในตัวอย่างเรียกใช้งาน Keycloak จะใช้ 2 service ตัวอย่างนี้จะเรียกใช้ฐานข้อมูลแล้วค่อยเรียกใช้โปรแกรม keycloak
+
 ```sh
 docker compose up -d bmahrms-postgres
 docker compose up -d bmahrms-id
 ```
+
 ### BMA HRMS Service
+
 ระบบที่พัฒนาเพื่อ HRMS โดยเฉพาะ จะมี 3 ไฟล์
+
 - be.env ค่าคอนฟิกของ Backend
 - fe.env ค่าตอนฟิกของ Frontend
 - compose.yaml คอนฟิกของ Docker
@@ -379,6 +667,7 @@ docker compose up -d bmahrms-id
 - bmahrms-logs-n-backup Backup and Logs
 
 โปรแกรม Backend ถูกเรียกใช้โดย Frontend อีกที
+
 - bmahrms-report
 - bmahrms-recruit
 - bmahrms-insignia
@@ -397,8 +686,8 @@ docker compose up -d bmahrms-id
 - bmahrms-development
 - bmahrms-kpi
 
-
 docker/bmahrms/fe.env แก้ตัวแปร VITE_CLIENTSECRET_KEYCLOAK KC_SERVICE_ACCOUNT_SECRET
+
 ```
 # Frontend Global
 TZ=Asia/Bangkok
@@ -422,7 +711,9 @@ KC_SERVICE_ACCOUNT_CLIENT_ID=bma-ehr-dev
 KC_SERVICE_ACCOUNT_SECRET=put_service_account_secret_here
 MANAGEMENT_ROLE=storage_management
 ```
+
 docker/bmahrms/be.env แก้ค่าของ DB_PASSWORD,AUTH_PUBLIC_KEY, MINIO_KEY, MINIO_SECRET, STORAGE_SECRET,KC_SERVICE_ACCOUNT_SECRET,REDIS_HOST,KEYCLOAK_KEY,AUTH_PUBLIC_KEY, PUBLIC_KEY
+
 ```
 # Backend Global
 TZ=Asia/Bangkok
@@ -472,7 +763,9 @@ ELASTICSEARCH_HOST=bmahrms-elasticsearch
 ELASTICSEARCH_PORT=9200
 ELASTICSEARCH_INDEX=bma-ehr-log-index
 ```
+
 docker/bmahrms/compose.yaml
+
 ```yaml
 networks:
   hrms:
@@ -864,10 +1157,13 @@ services:
 ```
 
 ## Configuration
+
 การตั้งค่าเฉพาะของแต่ละ service และการตั้งค่า route การตั้งค่า route ส่วนใหญ่จะทำคล้ายๆกัน ส่วนที่เป็น Frontend จะเป็นการเซ็ตโดเมน(URL)ของแต่ละโปรแกรม ส่วนที่เป็น Backend จะเป็นการรวมหลาย backend เข้าในโดเมนเดียวกันแต่อยู่คนละ Subfolder ซึ่งเป็นการรวม Microservice เข้าด้วยกัน
 
 ### keycloak (bmahrms-id)
+
 ใช้สำหรับการ login ในระบบ (Identity Server) การสือสารหลัง API Gateway จะเป็น https แบบ self-signed
+
 ```sh
 cd bmahrms-service/keycloak_config
 openssl genrsa -out keycloak.key 2048
@@ -876,7 +1172,9 @@ cp keycloak.key keycloak.pem
 cat keycloak.crt >> keycloak.pem
 cd ..
 ```
+
 Keycloak Route
+
 ```sh
 curl "http://127.0.0.1:9180/apisix/admin/routes" \
 -H "X-API-KEY: put_admin_api_key_here" -X PUT -d '
@@ -893,7 +1191,9 @@ curl "http://127.0.0.1:9180/apisix/admin/routes" \
   }
 }'
 ```
+
 ### Portainer ()
+
 เป็นโปรแกรมสำหรับบริหารจัดการ container สามารถสิ่งเปิดปิดแก้ไขการทำงานของคอนเทนเนอร์ได้ เฉพาะผู้ดูแลระดับสูงถึงจะเข้าใช้งานส่วนนี้
 
 ```sh
@@ -911,14 +1211,18 @@ curl "http://127.0.0.1:9180/apisix/admin/routes" \
   }
 }'
 ```
+
 ### MySQL(bmahrms-postgres)
-init_mysql/*.sql เป็นที่เก็บ SQL Script สำหรับสร้างฐานข้อมูลตั้งต้น 
+
+init_mysql/\*.sql เป็นที่เก็บ SQL Script สำหรับสร้างฐานข้อมูลตั้งต้น
 จะถูกเรียกใช้ครั้งแรกตอนเริ่มฐานข้อมูลเป็นข้อมูลตั้งต้นของระบบ
 เนื่องจากไฟล์มีขนาดใหญ่หลายบรรทัดจะไม่ใส่ในเอกสารนี้
 
 ### Report Server
+
 เป็น Microservice ใช้สำหรับการออกรายงาน ไม่จำเป็นต้องมี domain ของตัวเอง ให้เป็น path ในโดเมนที่มีอยู่ได้ ให้นำไฟล์ต้นแบบซึ่งสร้างจาก MS Word และ Excel มาไว้ที่โฟลเดอร์นี้
-report-server-template/docx/*.docx, report-server-template/xlsx/*.xlsx 
+report-server-template/docx/_.docx, report-server-template/xlsx/_.xlsx
+
 ```sh
 curl "http://127.0.0.1:9180/apisix/admin/routes" \
 -H "X-API-KEY: put_admin_api_key_here" -X PUT -d '
@@ -979,7 +1283,9 @@ curl "http://127.0.0.1:9180/apisix/admin/routes" \
 ```
 
 ### EDM (Enterprixe Document Management)
+
 เป็นระบบจัดการเอกสารภายใน ประกอบไปด้วยโปรแกรมหลายตัว
+
 - EDM ตัวโปรแกรมหลัก
 - Elasticsearch ฐานข้อมูลดัชนีเอกสารเพื่อการค้นหาภาษาไทยแบบซับซ้อน อ้างผ่าน IP/PORT ไม่มี Route สู่ภายนอก
 - Kibana ใน WebUI การจัดการ Elasticsearch มี Route ใช้เฉพาะนักพัฒนา
@@ -987,11 +1293,14 @@ curl "http://127.0.0.1:9180/apisix/admin/routes" \
 - MiniO ใช้เพื่อเก็บไฟล์ต่างๆ มีหน้า console ใช้เฉพาะนักพัฒนา
 
 นอกเหนือจาก compose.yaml มีไฟล์คอนฟิกสองไฟล์
+
 ```sh
 nano edm_config/keycloak.json
 nano elasticsearch_config/config.yaml
 ```
+
 edm_config/keycloak.json
+
 ```json
 {
   "realm": "EDM",
@@ -1002,13 +1311,16 @@ edm_config/keycloak.json
   "confidential-port": 0
 }
 ```
+
 elasticsearch_config/config.yaml
+
 ```yaml
 network.host: 0.0.0.0
 s3.client.default.endpoint: bma-hrms-s3.bangkok.go.th
-
 ```
+
 EDM Route
+
 ```sh
 curl "http://127.0.0.1:9180/apisix/admin/routes" \
 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f2" -X PUT -d '
@@ -1024,8 +1336,10 @@ curl "http://127.0.0.1:9180/apisix/admin/routes" \
   }
 }'
 ```
+
 Kibana Route
 เป็น UI สำหรับ Elasticsearch สามารถใช้แบบ HTTP ตรงๆได้ผ่าน VPN ถ้า โดยทั่วไปใช้ผ่านเน็ตเวิร์กภายใน API gateway จะช่วยทำ Basic Authentication และ https ให้ควรใช้ ใช้ภายในเสำหรับนักพัฒนาเท่านั้น
+
 ```sh
 curl "http://127.0.0.1:9180/apisix/admin/routes" \
 -H "X-API-KEY: put_admin_api_key_here" -X PUT -d '