BOLD TECHNLOGY,

REAL IMPACT

ตารางเทียบเร็ว ________________________________________ ความเหมือน (ที่ควรถามให้ชัด ไม่ว่าเลือกทางไหน) 1. ขอบเขตงาน (Scope) และเป้าหมายธุรกิจ 2. กำหนดส่ง & Milestone ที่ตรวจรับได้ 3. เจ้าของสินทรัพย์ทางปัญญา (IP) และสิทธิ์ในซอร์สโค้ด/ดีไซน์ 4. ความปลอดภัยของข้อมูล (การเข้าถึง/เก็บ/ลบ/เข้ารหัส) 5. งบประมาณและรูปแบบการคิดเงิน (Fixed price, Time & Materials, Retainer) 6. ช่องทางสื่อสาร & จังหวะอัปเดตงาน (รายสัปดาห์/ราย Sprint) ________________________________________ ความแตกต่างเชิงลึก 1) การจัดการโครงการ • Software House: มี PM/BA กำกับ, ใช้ Agile/Scrum/Kanban, สถานะงานโปร่งใส (บอร์ด/เบิร์นดาวน์) • ฟรีแลนซ์: ผู้ว่าจ้างต้องทำหน้าที่ PM บางส่วน (จัดลำดับงาน ตัดสินใจ Trade off) เว้นแต่จะจ้าง PM เพิ่ม 2) คุณภาพซอฟต์แวร์ & การทดสอบ • Software House: มี QA, Code Review, Automated Test, CI/CD, Environment แยก Dev/Staging/Prod • ฟรีแลนซ์: ต้องระบุในสัญญาว่าจะมี Unit/E2E Test, Code Review, และเกณฑ์รับงานอย่างไร 3) ความปลอดภัย & คอมพลาย • Software House: คุ้นเคยมาตรฐานเช่น OWASP, ISO 27001, SOC 2, มีแนวทาง DevSecOps • ฟรีแลนซ์: ทำได้แต่ต้องกำหนดข้อกำหนด/Checklist และตรวจรับให้ชัด 4) ความต่อเนื่องระยะยาว • Software House: มีเอกสาร/คู่มือ/ฮันดโอเวอร์ และทีมซัพพอร์ตต่อเนื่อง • ฟรีแลนซ์: ต้องวางแผนโอนย้ายความรู้ (Knowledge Transfer) และสำรองคนเผื่อฉุกเฉิน 5) ต้นทุนทั้งหมด (TCO) • Software House: ค่าเรตสูงกว่า แต่รวม PM/QA/Infra ops บางส่วน → ลดงานแฝงของทีมคุณ • ฟรีแลนซ์: ค่าเรตต่อชั่วโมงต่ำกว่า แต่ผู้ว่าจ้างต้องแบกบางส่วน (PM/QA/สคริปต์ดีพลอย/มอนิเตอร์) สูตรคิดง่าย ๆ (ประมาณการ): TCO ≈ ค่าแรงพัฒนา + ค่า PM/QA + ค่าโฮสติ้ง/เครื่องมือ + ค่าแก้บั๊กหลังส่งมอบ + ค่าเสี่ยง (ดีเลย์/คนหาย) ________________________________________ เลือกแบบไหน: ใช้กรอบตัดสินใจนี้ • เลือก Software House ถ้า: o มีหลายระบบต้องเชื่อมต่อ (ERP/CRM/Payment/IoT) o งานต้องผ่านการตรวจสอบ/คอมพลาย (เช่น ข้อมูลการเงิน/สุขภาพ) o ต้องการ Roadmap และการดูแลต่อเนื่อง 12–36 เดือน o ทีมคุณไม่มี PM/QA/DevOps ภายใน • เลือกฟรีแลนซ์ ถ้า: o เป็นโปรเจกต์ MVP/PoC ระยะสั้น 4–12 สัปดาห์ o ขอบเขตชัดเจน หน้าจอไม่ซับซ้อน และความเสี่ยงยอมรับได้ o ต้องการเริ่มเร็ว งบจำกัด และคุณมีเวลาช่วยตัดสินใจ/ทดสอบ • แบบไฮบริด ถ้า: o อยากคุมงบ แต่ยังอยากได้วินัยของทีม → จ้างฟรีแลนซ์ + PM/QA part time o เริ่มจากฟรีแลนซ์ พอ Product Market Fit ค่อยโอนไป Software House หรือทีมถาวร ________________________________________ รูปแบบสัญญา & การคิดเงิน • Fixed Price: ราคาตายตัว เหมาะกับขอบเขตนิ่ง มีเอกสารชัด → เสี่ยงเปลี่ยนสcopeแล้วแพง • Time & Materials (T&M): คิดตามชั่วโมง/วัน เหมาะกับงานที่ต้องลองผิดลองถูก → ต้องคุมความคืบหน้าเข้ม • Retainer / Support Plan: รายเดือนเพื่อดูแล/ปรับปรุง/มอนิเตอร์ระบบหลังขึ้นจริง แนะนำ: PoC (T&M) → ระบุ Scope ชัด → เฟสพัฒนา (Fixed Price + Milestone) → สัญญาดูแลรายเดือน ________________________________________ เกณฑ์รับงาน (Definition of Done) • ฟีเจอร์ตาม scopeใช้งานได้ครบ, ผ่าน User Acceptance Test (UAT) • มีเอกสาร: วิธี Deploy, คู่มือผู้ใช้, คู่มือแอดมิน, แผนสำรองข้อมูล/กู้คืน (Backup/Recovery) • มีชุดทดสอบ และบันทึกผลการทดสอบ • มีแผนซัพพอร์ตหลังส่งมอบ/ระยะเวลารับประกันชัดเจน ________________________________________ ตัวอย่างประมาณการ (สมมติ) • แอปเว็บ MVP 8 หน้าจอ + ล็อกอิน + ชำระเงิน o Software House: 10–14 สัปดาห์, ทีม 5 บทบาท (PM/UX/FE/BE/QA), งบ X–Y บาท, รวม QA/ดีพลอย/มอนิเตอร์เบื้องต้น o ฟรีแลนซ์: 6–10 สัปดาห์, 1–2 คน, งบ ~60–75% ของ Software House แต่ผู้ว่าจ้างต้องช่วย PM/ทดสอบ/จัดการโฮสติ้ง ตัวเลขขึ้นกับความซับซ้อน เทคโนโลยีที่เลือก และการผสานระบบภายนอก ________________________________________ FAQ จะรู้ได้อย่างไรว่าผู้รับจ้าง “ดี” จริง? – ดูพอร์ตงาน/ลูกค้าอ้างอิง, ทดลองงานเล็ก (Spike/PoC), ประเมินคุณภาพสื่อสารและความเป็นระบบ ถ้าเริ่มกับฟรีแลนซ์แล้วอยากย้ายไป Software House? – ระบุสิทธิ์ IP เก็บโค้ดใน Git ของคุณเอง, บังคับเอกสาร/คู่มือ, ทำฮันดโอเวอร์เป็น Milestone หนึ่ง ควรใช้เครื่องมืออะไรช่วยโปร่งใส? – บอร์ดงาน (Jira/YouTrack/Trello), รีโปโค้ด (GitHub/GitLab/Bitbucket), CI (GitHub Actions/GitLab CI), สื่อสาร (Slack/Teams), มอนิเตอร์ (Sentry/Datadog) ________________________________________ สรุป • ถ้าคุณต้องการ ความครบวงจร ความเสถียร และมาตรฐาน → ควรไปทาง Software House • ถ้าคุณต้องการ ความเร็ว ประหยัด และขอบเขตชัด → ควรไปทาง ฟรีแลนซ์

Agentic AI คืออะไร? คิดง่าย ๆ ว่าเป็น พนักงานเสมือน ที่: 1. เข้าใจเป้าหมายของงาน, 2. วางแผนทีละขั้น 3. เรียกใช้เครื่องมือ/ระบบของบริษัท (เช่น CRM, ERP, อีเมล) 4. ตรวจงานตัวเอง 5. ขออนุมัติจากคนเมื่อจำเป็น ต่างจาก Chatbot / copilot ที่แค่ "ตอบหรือร่างข้อความ" – เอเจนต์จะ ทำงานให้เสร็จ เช่น เปิดเคส สร้างใบสั่งงาน ส่งอีเมล แจ้งเตือน ปรับปรุงข้อมูลในระบบ เป็นต้น ________________________________________ ทำไมปี 2025 ถึงน่าเริ่ม • แพลตฟอร์มพร้อมใช้งานมากขึ้น เชื่อมระบบธุรกิจได้ และมีฟังก์ชันควบคุมความปลอดภัย • สายงาน (CRM / ITSM / ERP) มีเอเจนต์สำเร็จรูปให้เริ่มเร็ว • องค์กรต่าง ๆ มีแนวทางกำกับดูแล (สิทธิ์ผู้ใช้ บันทึกการกระทำ นโยบายข้อมูล) ชัดเจนขึ้น ________________________________________ Use-case 1. บริการลูกค้า – เอเจนต์อ่านอีเมล/แชต → ค้นคำตอบจากฐานความรู้ → เติมข้อมูลลูกค้า → เสนอร่างคำตอบ/เปิดเคส/นัดช่าง 2. งานขาย–การตลาด – สรุปข้อมูลลูกค้าก่อนนัด, ร่างข้อเสนอและใบราคา, แนะนำขั้นตอนถัดไปให้เซลส์ 3. การเงิน (AP/AR) – ตรวจใบแจ้งหนี้เทียบ PO, ตามอนุมัติ, จัดการข้อยกเว้น, สรุปสถานะกระแสเงินสด 4. ซัพพลายเชน/ปฏิบัติการ – แจ้งเตือนดีเลย์, เสนอเปลี่ยนเส้นทางขนส่ง, อัปเดตข้อมูลสินค้า/ซัพพลายเออร์ 5. ไอที & Helpdesk พนักงาน – รับเรื่องอัตโนมัติ, รันขั้นตอนตรวจสอบพื้นฐาน, เสนอวิธีแก้/จองคิวช่าง 6. ความปลอดภัยไซเบอร์ – คัดกรองแจ้งเตือน, เติมข้อมูลภัยคุกคาม, ขออนุมัติให้กักกันเครื่องที่เสี่ยง 7. บุคคล & การเรียนรู้ – กลั่นกรองเรซูเม่, นัดสัมภาษณ์, จัดออนบอร์ดดิ้ง, แนะนำหลักสูตรสั้น ๆ ตามบทบาท 8. การเดินทาง/จัดซื้อ – แนะนำตัวเลือกที่ตรงนโยบาย, จัดทำเปรียบเทียบราคา, ติดตามสัญญาและคะแนนซัพพลายเออร์ เคล็ดลับ: เลือกงานที่ ขั้นตอนชัด ผลลัพธ์วัดได้ และมีระบบหลักรองรับ ก่อน เช่น ตั๋วไอทีระดับ 1 หรือใบแจ้งหนี้ที่มี PO คู่กัน ________________________________________ จะเริ่มอย่างไรใน 90 วัน (ฉบับไม่เทคนิค) ช่วงวัน 0–30: เลือกงานและตั้งกติกา (Frame & Safeguard) • เลือก 1 กระบวนการที่ชัดเจน (ตัวอย่าง: เคสลูกค้าแบบซ้ำ ๆ / ข้อยกเว้นใบแจ้งหนี้ / ตั๋วไอทีพื้นฐาน) • กำหนดขอบเขตข้อมูลที่เอเจนต์เข้าถึงได้, ใครอนุมัติอะไร, และต้องบันทึกอะไรไว้ตรวจสอบ • สร้างชุดตัวอย่างงาน 100–300 เคส เพื่อใช้ทดสอบและวัดผล ช่วงวัน 31–60: ทำต้นแบบและติดเครื่องมือตรวจวัด (Build & Instrument) • ให้เอเจนต์ทำ 2–4 ขั้นตอนแรก เช่น อ่านข้อมูล → ค้นคำตอบ → ร่างการกระทำ (ยังไม่ลงมือจริง) • เปิดโหมด ให้คนกดอนุมัติ ก่อนเอเจนต์จะเปลี่ยนข้อมูล/ส่งอีเมลจริง • เก็บสถิติ: อัตราทำงานถูกต้อง, เวลาที่ประหยัด, งานที่ยังต้องยกระดับให้คน ช่วงวัน 61–90: พิสูจน์ผลและค่อย ๆ ขยาย (Prove & Expand) • ปล่อยใช้กับผู้ใช้กลุ่มเล็ก (5–10%) และเทียบผลกับวิธีเดิม • เปิดให้เอเจนต์ทำงานอัตโนมัติสำหรับกรณีความเสี่ยงต่ำ, ส่วนกรณีเสี่ยงสูงยังต้องอนุมัติ • เขียนคู่มือปฏิบัติ (Runbook): ใครดูแล, วิธีหยุดฉุกเฉิน, วิธีย้อนกลับการเปลี่ยนแปลง ________________________________________ วัดความคุ้มค่าอย่างไร • ประหยัดเวลา ต่อเคส/งานหนึ่งชิ้น • ลดงานซ้ำ ๆ/ข้อยกเว้น ที่ต้องให้คนแก้ • คุณภาพคำตอบดีขึ้น (ลูกค้าพอใจขึ้น อัตราเปิดเคสซ้ำลดลง) • ความเสี่ยงต่ำลง (นโยบายถูกทำตาม, มีบันทึกตรวจสอบ) • ต้นทุนต่อการปิดงาน ลดลงเมื่อเทียบวิธีเดิม ________________________________________ ความเสี่ยงที่พบบ่อย & วิธีป้องกัน • ทำงานเกินสิทธิ์ → จำกัดสิทธิ์ทีละเครื่องมือ, ใช้บัญชีบริการแยกสำหรับเอเจนต์ • เข้าใจผิด/หลอน → ให้เอเจนต์อ้างอิงเฉพาะแหล่งความรู้ที่อนุมัติ และให้คนตรวจงานช่วงแรก • แก้ยากเมื่อผิดพลาด → ออกแบบให้ "ย้อนกลับได้" และมีปุ่มหยุดฉุกเฉิน • ไม่มีบันทึก → เก็บบันทึกว่าใครทำอะไร เมื่อไร และด้วยเหตุผลใด ทุกครั้ง • ผูกติดผู้ขาย → เลือกแพลตฟอร์มที่เชื่อมต่อระบบเดิมได้ และย้ายแพลตฟอร์มได้ภายหลัง ________________________________________ เลือกแพลตฟอร์มอย่างไร มองหาแพลตฟอร์มที่: • เชื่อมระบบที่คุณใช้อยู่ได้ (CRM/ERP/อีเมล/ไอที) • กำหนดสิทธิ์และการอนุมัติได้ ชัดเจน • บันทึกการกระทำและตรวจสอบย้อนหลังได้ • เริ่มเล็กได้แต่ขยายได้ ภายหลัง ________________________________________ คำถามที่พบบ่อย (FAQ) เอเจนต์จะแทนคนไหม? – ไม่จำเป็น เป้าหมายคือ ตัดงานซ้ำ ๆ ให้คนได้โฟกัสเรื่องสำคัญขึ้น ต้องมีทีมไอทีใหญ่ไหม? – เริ่มได้ด้วยทีมเล็ก ๆ หากเลือกแพลตฟอร์มที่มีเครื่องมือพร้อมใช้ ข้อมูลปลอดภัยแค่ไหน? – ตั้งสิทธิ์ขั้นต่ำ, กำหนดสิ่งที่เอเจนต์มองเห็น/ทำได้, และบันทึกทุกการกระทำ ต้องใช้งบมากไหม? – เริ่มจากโครงการนำร่องจุดเล็ก ๆ วัดผลก่อนขยาย ลดความเสี่ยงการลงทุน เริ่มที่ทีมไหนดี? – Helpdesk หรือการเงิน (ตรวจใบแจ้งหนี้) มักให้ผลเร็ว ________________________________________ บทสรุป Agentic AI คือวิธีง่ายและปลอดภัยในการ ทำให้กระบวนการทำงานดีขึ้น ในปี 2025 เริ่มจากงานที่ชัด วัดผลจริง และสร้างความเชื่อมั่นด้วยการอนุมัติโดยมนุษย์และบันทึกทุกก้าว เมื่อเห็นผลแล้วค่อยขยายสู่กระบวนการอื่น ๆ

สวัสดีครับ ผมได้กลับมาเขียน Blog อีกครั้งแล้วนะครับ หลังจากได้ไปท่องโลกสนธยา โลก DevOps มา ไม่ได้มีเวลากลับมาเขียน Blog เลย คิดถึงผู้อ่านทุกท่านนะครับ และผมหวังอย่างยิ่งว่า บทความนี้ อาจจะเป็นประโยชน์ต่อผู้อ่าน หรือ ผู้ที่ต้องการศึกษา Dockerfile ครับ Dockerfile ที่ดี ต้องมีอะไรบ้าง หลายคนคงทราบอยู่แล้วนะครับว่า Dockerfile ที่ดี ต้องรู้จักการ Copy ของที่จำเป็นต่อการรันแอปพลิเคชั่น และ ไม่ขาดสิ่งที่จำเป็นไป โดยในการทำ Dockerfile นั้นสิ่งที่ต้องห้ามเลย คือ Copy Credentials / Environment หรือ Sensitive Object ต่างๆนะครับ เอาขึ้นไป ผมขอตีมือทีนึงนะ 5555555555 เอาจริงๆ ผมเองก็มาเริ่ม Nerd กับ Dockerfile ในช่วงหลังๆชีวิตการทำงานตลอด 4 ปีที่ผ่านมานะครับ สมัยก่อน มีอะไรก็ก๊อปๆใส่ไปก่อน เอาขึ้นให้ได้ ช่วงต่อมา ก็เริ่มรู้แล้วว่า อะไรที่ไม่ควร Copy ใส่ และ มาถึง Step Build Multi-stage และ ก็มาถึงอีกสเต็ป คือ การเอา Dockerfile ยัดเขา Distroless ยัน Scratch Dockerfile ครับ ในบทความนี้ผมจะมาพาทำ Dockerfile แบบเบาสบาย ปลอดภัย และ คลีน ฉบับผมเองนะครับ โดยผมจะเริ่มจากการที่ผมนำโปรเจกต์ Website ส่วนตัวของผม มาเป็นต้บแบบในบทความนี้นะครับ Stack ที่ผมนำไป Containerized มีดังนี้ครับ Code base : Nuxt3 (Vue 3) + Bun.js OS base : Alpine Linux มาเริ่มกันเลยดีกว่าครับ ผมจะพาทัวร์ โดยเริ่มจากการดูโครงสร้าง Folder ก่อน Structure ของ Nuxt3 ทุกคนสังเกตเห็น .dockerignore ไหมครับ อันนี้แหละครับที่เป็นตัวช่วยทุกท่านในการ ไม่เอา File ที่เราไม่ต้องการ รวมถึง Sensitive Object ขึ้นไป เวลา Build Dockerfile ครับ .dockerignore ในไฟล์นี้ผมจะไม่เอาสิ่งที่เป็น Output เวลาที่ผม Build บน Local ขึ้นไป หรือ ไฟล์ต่างๆที่ไม่จำเป็น หรือ เกินจำเป็น เวลา Build ครับ เช่น node_modules, .output, .nuxt, .git หรือว่าพวก Sensitive Object เช่น .env หรือสิ่งที่ Editor เป็นคน Generate ให้ เช่น .vscode, .idea หรือ อื่นๆครับ และ ถ้า เป็นพวก Script ต่างๆที่ใช้งานเกี่ยวกับ Deployment ผมก็ไม่เอาขึ้นไปเช่นกันครับ เช่น ที่เก็บ File Helm Chart , YAML ของ K8s มาถึงส่วนที่สำคัญกันบ้างล่ะครับ คือ Dockerfile FROM oven/bun:alpine as base #เลือก Distro ที่เราต้องการจะนำมาเป็น Base สำหรับการ Build COPY package.json bun.lock ./app/ #คัดลอกไฟล์ package.json และ bun.lock ซึ่งเป็นไฟล์ระบุ Package ที่ใช้ภายในระบบ WORKDIR /app #กำหนดพื้นที่หรือขอบเขตในการ Execute RUN bun install --frozen-lockfile #ติดตั้งไฟล์ที่จำเป็นสำหรับการ Build Nuxt FROM base AS prerelease #เปลี่ยน Step การทำงาน ENV USER_NAME=isaac #กำหนด Username ENV UID=1001 #กำหนด User ID ENV GID=1001 #กำหนด Group ID #เริ่มติดตั้ง Package ที่จำเป็นต่อการใช้งาน RUN apk update && \ apk add --no-cache ca-certificates && \ addgroup -g ${GID} ${USER_NAME} && \ #เพิ่ม Group ที่ User ID จะอยู่ adduser -D -u ${UID} -G ${USER_NAME} ${USER_NAME} && \ # เพิ่ม User เข้า Group chown -R ${USER_NAME}:${USER_NAME} /app #ให้สิทธิ์ในโฟลเดอร์ /app ทั้งหมดแก่ User ดังกล่าว USER ${USER_NAME} #สลับ User COPY --from=base /app/node_modules node_modules #Copy File node_modules จาก Step COPY . . #Copy file ทั้งหมดที่จำเป็นสำหรับการ Build (ยกเว้น node_modules) ENV NODE_ENV=production #กำหนด ENV เป็น NODE_ENV=production เพื่อ build แบบ Production RUN bun run build #คำสั่ง Build FROM scratch #เปลี่ยน Step มาเป็น Step สุดท้าย คือการ สลับเป็น Scratch COPY --from=prerelease /etc/passwd /etc/passwd #คัดลอกไฟล์ที่จำเป็นจากสเต็บ Pre-release อันนี้เป็นไฟล์ /etc/passwd คือไฟล์ที่เกี่ยวข้องกับการจัดการ User COPY --from=prerelease /etc/group /etc/group #คัดลอกไฟล์ที่จำเป็นจากสเต็บ Pre-release อันนี้เป็นไฟล์ /etc/group คือไฟล์ที่เกี่ยวข้องกับการจัดการ User เช่นเดียวกัน ENV USER_NAME=isaac #กำหนด Username USER ${USER_NAME} #สลับ User WORKDIR /app #กำหนดพื้นที่หรือขอบเขตในการ Execute COPY --from=base /usr/local/bin/bun /usr/local/bin/bun #คัดลอกไฟล์ที่จำเป็นจาก Step Base อันนี้เป็น Executable ที่จำเป็นต่อการรัน App ของเรา คือ bun COPY --from=base "/usr/lib/libstdc++.so.6" "/usr/lib/libstdc++.so.6" #คัดลอก Library ที่จำเป็นสำหรับภาพรวม COPY --from=base /usr/lib/libgcc_s.so.1 /usr/lib/libgcc_s.so.1 #คัดลอก Library ที่จำเป็นสำหรับภาพรวม # คัดลอก Library ที่จำเป็นสำหรับภาพรวม # (Library นี้ ขาดแล้ว รันไม่ได้ คือ Library ที่เกี่ยวกับ ld เป็น dynamic linker # ถ้าก๊อปปี้ผิด ก็รันไม่ได้้เช่นกัน เช่น ถ้าเครื่องปลายทางใช้ AMD64 / Intel ควรเป็น ld-musl-x86_64.so.1 # หรือถ้าเป็น Apple Silicon / ARM64 ควรเป็น ld-musl-aarch64.so.1 COPY --from=base /lib/ld-musl-x86_64.so.1 /lib/ld-musl-x86_64.so.1 COPY --from=prerelease --chown=${USER_NAME}:${USER_NAME} /app/.output /app #คัดลอกโฟลเดอร์ Output สำหรับ Application โดย ต้องกำหนด User สำหรับการ Copy ให้ตรงกับ User ของเราที่กำหนดไว้ในขั้น Pre-release ENV NUXT_HOST=0.0.0.0 #กำหนด Environment ENV NUXT_PORT=3000 #กำหนด Environment EXPOSE 3000 #กำหนด Port ที่จะนำออก สำหรับ Container CMD ["bun", "run","server/index.mjs"] #กำหนด คำสั่ง ในการรัน Application ที่ท่านเห็นอยู่ข้างบนนี้คือ Dockerfile ของโปรเจกต์ ผมเองนะครับ แต่ละอัน ผมจะคอมเมนต์ และ อธิบายไว้ในไฟล์นะครับ สังเกตไหมครับว่า Dockerfile ดังกล่าว ผมใช้ scratch สาเหตุที่ผมใช้มีอยู่อย่างเดียวเลย …. ป้องกัน Shell Execution ครับ ค่อนข้างจะละเอียดเลยครับ เป็นไฟล์ที่ผมใช้เวลาศึกษาพอสมควร กว่าจะได้ Dockerfile นี้มา อาจจะรู้สึกว่ามันยุ่บยั่บไปหน่อย ไหนจะเรื่อง Lib ต่างๆที่ Copy มาเอง ไหนจะเป็น ld ที่จะต้องมาเลือก Architecture ภายหลัง วุ่นวายดีครับ แต่ผมจะบอกอย่างนึงนะครับ ที่ผมเลือกใช้ scratch แทน distroless เพราะ มันค่อนข้างเห็นชัดดีครับว่า อะไรที่เราจำเป็นต้อง Copy บ้าง และ distroless อาจจะไม่ตอบโจทย์ผมในเรื่องของการใช้งาน Alpine linux ครับ เพราะมันเป็น glibc แต่ Alpine Linux เป็น musl ไม่ว่าอย่างไรก็ดีครับ การเขียน Dockerfile ในแบบฉบับของผมเอง อาจไม่ใช่วิธีทางที่ดีหรือดูน่าชื่นชมสำหรับพี่ๆน้องๆทุกท่านนะครับ แต่ผมอยากมาแชร์วิธีการเขียนในแนวทางของผม ที่ผมได้ศึกษามา และ ได้มองเห็นจุดอ่อน และ ได้แก้จุดอ่อนในแบบฉบับของผมเพียงเท่านั้นเองครับ ผมยินดีรับความคิดเห็นที่สร้างสรรค์จากพี่ๆ ในวงการ Developer / DevOps / Security ทุกท่านอยู่นะครับ หวังว่าพี่ๆจะใจดีกับผมนะครับ ขอพระเจ้าอวยพรทุกท่านครับ สวัสดีครับ