Docker: ทำไมต้องใช้ src แทนที่จะใช้ html, www หรือชื่ออื่น?

2014-08-08| phunsanit| 0 Comment | 07:00

Categories:

ในการวางโครงสร้าง Repository หรือโฟลเดอร์สำหรับพัฒนาซอฟต์แวร์และเว็บแอปพลิเคชันยุคใหม่ (รวมถึงการใช้งานร่วมกับ Docker) นักพัฒนาส่วนใหญ่เลือกตั้งชื่อโฟลเดอร์เก็บโค้ดหลักของโปรเจกต์ว่า src/ (Source Code) แทนที่จะเป็น html/, www/, หรือ public_html/

บทความนี้จะอธิบายเหตุผลเบื้องหลังการเลือกใช้ชื่อ src/ ทั้งในมิติของ Software Engineering Conventions, ความปลอดภัย, และ สถาปัตยกรรม Container

ความหมายเชิงบริบท (Semantic Meaning): Source Code ทั้งระบบ vs ไฟล์หน้าเว็บ

ในอดีต (เช่น ยุค Web 1.0 หรือ Web Hosting ยุคดั้งเดิม) เว็บไซต์ประกอบด้วยไฟล์ HTML, CSS, JS และ PHP ที่เปิดให้ผู้ใช้เข้าถึงได้ตรงๆ การใช้ชื่อ public_html/ หรือ www/ จึงตรงไปตรงมา

แต่ในเว็บแอปพลิเคชันยุคใหม่ (เช่น Laravel, Symfony, Node.js, Next.js, หรือ Modern PHP Frameworks)

โค้ดมากกว่า 80% เป็น Internal Business Logic: เช่น Controller, Model, Service Layer, Database Migrations, Config, Environment Files (.env), และ Test Suites
มีเพียงโฟลเดอร์ย่อยเล็กๆ อย่าง public/ หรือ dist/ เท่านั้นที่เป็นจุดเข้าถึงของ Web Server (Document Root)

การใช้ชื่อ src สื่อความหมายตามหลักสากลว่า “โฟลเดอร์นี้คือ Source Code ทั้งหมดของแอปพลิเคชัน” ขณะที่การใช้ชื่อ html/ หรือ www/ จะสื่อความหมายผิดว่าทุกไฟล์ข้างในคือไฟล์สำหรับเปิดออกสู่สาธารณะ

การแยก Infrastructure Layer ออกจาก Application Source Code

เมื่อพัฒนาโปรเจกต์ร่วมกับ Docker, CI/CD หรือ DevOps Tools โครงสร้างของ Root Repository มักมีไฟล์คอนฟิกโครงสร้างพื้นฐานรวมอยู่ด้วย

JavaScript

Plain Text

my-project/
├── docker-compose.yml       # Infrastructure (Container Orchestration)
├── nginx/                   # Infrastructure (Web Server Config)
│   └── default.conf
├── .github/                 # CI/CD Workflows
│   └── workflows/
├── Makefile / scripts/      # Automation Scripts
└── src/                     # Application Source Code
    ├── app/
    ├── config/
    ├── public/              # Document Root จริงของ Web Server
    │   └── index.php
    └── composer.json

การแยก src/ ออกมาอย่างชัดเจนช่วยให้

Clean Separation of Concerns: นักพัฒนาฝั่ง Application ทำงานเฉพาะใน src/ โดยไม่ต้องยุ่งกับไฟล์ Docker หรือ Nginx
ตั้งค่าง่ายขึ้นใน CI/CD & Tooling: สามารถสั่ง Linter, Static Analysis (เช่น PHPStan), หรือ Unit Test (เช่น PHPUnit/Pest) ให้ตรวจสอบเฉพาะโฟลเดอร์ src/ ได้ทันที
การจัดการ Version Control: กำหนด .gitignore หรือสิทธิ์การเข้าถึงแยกกันระหว่างไฟล์ระบบกับไฟล์โค้ดได้เป็นระเบียบ

ความปลอดภัย (Security by Isolation)

หากตั้งชื่อโฟลเดอร์ว่า html/ แล้วเผลอกำหนดให้ Web Server (เช่น Nginx หรือ Apache) มองโฟลเดอร์นั้นเป็น Document Root ทั้งหมด จะเกิดช่องโหว่ร้ายแรง

ผู้ใช้ภายนอกอาจเข้าถึงไฟล์ .env ที่เก็บรหัสผ่านฐานข้อมูล
เข้าถึง Source Code Controller, Model หรือไฟล์ Log ได้โดยตรง

การจัดโครงสร้างแบบ src/ บังคับให้ Web Server ต้องชี้ Document Root ลึกลงไปที่ src/public (ในกรณีของ Laravel) ทำให้ไฟล์สำคัญทั้งหมดอยู่นอกพื้นที่ Document Root โดยสมบูรณ์

มาตรฐานสากลข้ามระบบนิเวศ (Cross-Ecosystem Convention)

src เป็นชื่อโฟลเดอร์มาตรฐานที่ใช้งานร่วมกันในแทบทุกภาษาและเฟรมเวิร์กในระดับอุตสาหกรรม

ภาษา / ระบบ	โครงสร้างมาตรฐาน
PHP (Modern / Frameworks)	`src/` (หรือแยก `app/` ภายใต้ Root ที่เก็บโค้ด)
Node.js / React / Vue / Vite	`src/`
Java / Kotlin (Maven / Gradle)	`src/main/java/`
Rust (Cargo)	`src/main.rs`, `src/lib.rs`
Go	`src/` (หรือ `pkg/`, `internal/`)
C / C++	`src/` และ `include/`

การใช้ src/ จึงช่วยลด Cognitive Load ทำให้นักพัฒนาในทีมเข้าใจโครงสร้างโปรเจกต์ได้ทันทีโดยไม่ต้องเรียนรู้ธรรมเนียมใหม่

แล้วทำไมใน Docker Container ถึงยังใช้ `/var/www/html`?

ความสับสนที่พบบ่อยคือ: “ถ้าบนเครื่อง Host เราใช้ src/ ทำไมใน Container ถึงยังเป็น /var/www/html?”

เครื่อง Host (เครื่องนักพัฒนา): ใช้ ./src เพื่อสื่อถึง Source Code ของ Repository ที่แยกจาก Docker Config
ภายใน Container (Linux Environment): ใช้ /var/www/html เพราะเป็นไปตามมาตรฐาน FHS (Filesystem Hierarchy Standard) ของระบบปฏิบัติการ Linux และเป็น Default Workdir/Document Root ของ Base Image ยอดนิยม (เช่น Official PHP-FPM, Apache, Nginx)

การ Mount Volume ด้วยรูปแบบ