Dockerfile MySQL — สร้าง Container ฐานข้อมูล MySQL ด้วย Docker 2026

โดย อ. บอม กิตติทัศน์ | 02/03/2026 | SiamCafe.net Since 1997

ความสำคัญของ Docker ในการจัดการ MySQL สำหรับระบบ Enterprise

ในสภาพแวดล้อมของระบบ Enterprise การจัดการฐานข้อมูล MySQL แบบดั้งเดิมซึ่งติดตั้งบนเซิร์ฟเวอร์กายภาพหรือ มักนำมาซึ่งความท้าทายด้านความสอดคล้องของสภาพแวดล้อมระหว่างการพัฒนา การทดสอบ และการผลิต Docker ถูกนำมาใช้เพื่อแก้ไขปัญหานี้โดยการห่อหุ้ม MySQL Server และการกำหนดค่าทั้งหมดไว้ในคอนเทนเนอร์ที่แยกออกมา ซึ่งช่วยให้มั่นใจได้ว่าสภาพแวดล้อมในการทำงานจะเหมือนกันทุกที่ ตั้งแต่เครื่อง Developer ไปจนถึงคลัสเตอร์ production

การใช้งาน Dockerfile สำหรับ MySQL นั้นไม่ใช่แค่การรัน MySQL ในคอนเทนเนอร์เท่านั้น แต่ยังเกี่ยวกับการสร้าง image ที่สามารถ reproduce ได้ มีความปลอดภัย และปรับแต่งได้ตามความต้องการขององค์กร Image นี้จะประกอบด้วยเวอร์ชันเฉพาะของ MySQL, การกำหนดค่าที่จำเป็น, และสคริปต์เริ่มต้นทั้งหมดที่บรรจุไว้ในแพ็กเกจเดียว การทำให้กระบวนการเป็นมาตรฐานนี้ช่วยลดความผิดพลาดที่เกิดจากความแตกต่างของสภาพแวดล้อมได้อย่างมาก

สำหรับทีม DevOps และ Database Administrators (DBAs) สิ่งนี้หมายถึงการควบคุมแบบ fine-grained มากขึ้นเหนือเวอร์ชันและคอนฟิгураเซชันของฐานข้อมูล พวกเขาสามารถสร้าง image ที่มี patch ด้านความปลอดภัยล่าสุด, tuning parameters สำหรับฮาร์ดแวร์เฉพาะ, และสคริปต์สำหรับการ init database ได้อย่างง่ายดาย Image ที่สร้างจาก Dockerfile นี้สามารถจัดเก็บใน private registry เช่น Docker Hub organization หรือ Azure Container Registry เพื่อให้ทีมต่างๆ ดึงไปใช้ได้อย่างมั่นใจ

นอกจากนี้ แนวทางนี้ยังสนับสนุนการทำ Infrastructure as Code (IaC) ซึ่งการกำหนดค่าฐานข้อมูลทั้งหมดถูกจัดการผ่าน code ที่สามารถติดตามความเปลี่ยนแปลงได้ในระบบ version control เช่น Git สิ่งนี้ช่วยเพิ่มความสามารถในการตรวจสอบ auditability และการ collaboration ภายในทีม โดยการเปลี่ยนแปลงใดๆ ใน Dockerfile หรือสคริปต์ SQL จะต้องผ่านกระบวนการ review และ testing เช่นเดียวกับ code application

โครงสร้างและคำสั่งหลักใน Dockerfile สำหรับ MySQL

Dockerfile สำหรับ MySQL image ที่มีประสิทธิภาพมักจะเริ่มต้นด้วยการเลือก base image ที่เป็นทางการจาก Docker Hub คำสั่ง `FROM` เป็นจุดเริ่มต้นที่สำคัญที่สุด โดยแนะนำให้ใช้ tag ที่ระบุเวอร์ชันที่ชัดเจน เช่น `mysql:8.0.33` แทนที่จะเป็น `mysql:latest` เพื่อหลีกเลี่ยงการอัปเดตเวอร์ชันที่ไม่คาดคิดซึ่งอาจทำให้การทำงานเสียหายได้ การยึดติดกับเวอร์ชันที่เฉพาะเจาะจงช่วยสร้างความมั่นใจให้กับสภาพแวดล้อม production ว่ามีความเสถียรและสามารถคาดการณ์ได้

คำสั่งต่อมาที่มีความสำคัญอย่างยิ่งคือ `ENV` ซึ่งใช้สำหรับกำหนด environment variables ที่ MySQL container จำเป็นต้องใช้ ตัวอย่างเช่น `MYSQL_ROOT_PASSWORD`, `MYSQL_DATABASE`, `MYSQL_USER`, และ `MYSQL_PASSWORD` การใช้ environment variables สำหรับข้อมูลที่เป็นความลับเช่นรหัสผ่านอาจไม่ปลอดภัยพอสำหรับ production ดังนั้นสำหรับระบบ Enterprise จึงแนะนำให้ใช้ Docker secrets หรือการ inject value จาก external vault (เช่น HashiCorp Vault) ในเวลารันไทม์แทน

คำสั่ง `COPY` มีบทบาทสำคัญในการนำไฟล์ configuration และ initialization script เข้าไปใน image การคัดลอกไฟล์ `custom.cnf` ไปยัง `/etc/mysql/conf.d/` ช่วยให้สามารถ override การตั้งค่า default ของ MySQL server ได้อย่างมีประสิทธิภาพ นอกจากนี้ การคัดลอกสคริปต์ SQL (.sql) หรือ shell script (.sh) ไปยัง `/docker-entrypoint-initdb.d/` ช่วยให้สามารถ execute คำสั่งหรือสร้าง schema เริ่มต้นได้ทันทีเมื่อ container ถูกสร้างขึ้นเป็นครั้งแรก

สุดท้าย คำสั่ง `VOLUME` ถูกใช้เพื่อกำหนดจุด mount สำหรับการจัดเก็บข้อมูลอย่างถาวร ซึ่งเป็นสิ่งสำคัญที่สุดสำหรับฐานข้อมูล เพื่อให้แน่ใจว่าข้อมูลจะไม่สูญหายเมื่อ container ถูกหยุดหรือลบออก การกำหนด volume เช่น `/var/lib/mysql` ช่วยให้สามารถ persist data ไว้บน host machine หรือ external storage system ได้

# Example of a basic MySQL Dockerfile

FROM mysql:8.0.33



# Set environment variables

ENV MYSQL_ROOT_PASSWORD=temp_root_password

ENV MYSQL_DATABASE=my_app_db

ENV MYSQL_USER=app_user

ENV MYSQL_PASSWORD=app_password



# Copy custom configuration

COPY ./config/custom.cnf /etc/mysql/conf.d/



# Copy initialization scripts

COPY ./init-scripts/init.sql /docker-entrypoint-initdb.d/

COPY ./init-scripts/privileges.sql /docker-entrypoint-initdb.d/



# Expose MySQL port

EXPOSE 3306



# Define volume for data persistence

VOLUME /var/lib/mysql

การกำหนดค่าคอนฟิกราเซชันและปรับแต่งสำหรับประสิทธิภาพ

การปรับแต่งการกำหนดค่าของ MySQL ภายใน Docker container เป็นขั้นตอนที่สำคัญเพื่อให้ได้ประสิทธิภาพและความเสถียรที่เหมาะสมสำหรับ workload ของ Enterprise การคัดลอกไฟล์คอนฟิกราเซชันแบบ custom เข้าไปในไดเรกทอรี `/etc/mysql/conf.d/` ใน image ช่วยให้สามารถ override การตั้งค่า default ได้ ไฟล์คอนฟิกราเซชันนี้ควรมีพารามิเตอร์ที่ปรับให้เหมาะกับทรัพยากรของ host system

พารามิเตอร์หลักๆ ที่ควรพิจารณาปรับแต่งได้แก่ `innodb_buffer_pool_size` ซึ่งควรตั้งค่าไว้ที่ประมาณ 70-80% ของหน่วยความจำที่ available สำหรับ container ในสภาพแวดล้อม production ที่มีการใช้งานหนัก การตั้งค่า `max_connections` ควรปรับค่าให้สอดคล้องกับความคาดหวังของ application ที่จะมาเชื่อมต่อ เพื่อป้องกันข้อผิดพลาด "too many connections" การตั้งค่า `innodb_log_file_size` และ `character-set-server` ก็มีความสำคัญต่อประสิทธิภาพและการรองรับภาษาเช่นกัน

นอกจากพารามิเตอร์มาตรฐานแล้ว ยังสามารถเพิ่มการตั้งค่าที่เฉพาะเจาะจงสำหรับการทำงานใน containerized environment ได้ ตัวอย่างเช่น การตั้งค่า `bind-address = 0.0.0.0` เพื่อให้ MySQL ฟังการเชื่อมต่อจากทุก network interface ภายใน container ซึ่งจำเป็นสำหรับการเชื่อมต่อจาก external application containers การการตั้งค่า performance_schema ในบางกรณีช่วยลดการใช้ทรัพยากรได้

สิ่งสำคัญคือทำการทดสอบการกำหนดค่าเหล่านี้ภายใต้เงื่อนไขการโหลดที่ production environment เพื่อหาค่าที่เหมาะสมที่สุด การใช้ tools เช่น `sysbench` สำหรับการทำ stress test สามารถช่วยในการidentifyจุด bottleneck และการตั้งค่าได้อย่างมีประสิทธิภาพ การกำหนดค่าที่ดีจะต้องสมดุลระหว่างการใช้ทรัพยากร ประสิทธิภาพ และความเสถียรของระบบ

# Example custom.cnf file for MySQL in Docker

[mysqld]

# Basic Settings

user = mysql

pid-file = /var/run/mysqld/mysqld.pid

socket = /var/run/mysqld/mysqld.sock

port = 3306

basedir = /usr

datadir = /var/lib/mysql

tmpdir = /tmp

lc-messages-dir = /usr/share/mysql

skip-external-locking



# Performance Tuning

innodb_buffer_pool_size = 1G

innodb_log_file_size = 256M

innodb_flush_log_at_trx_commit = 2

max_connections = 500

thread_cache_size = 10

table_open_cache = 2000



# Network

bind-address = 0.0.0.0



# Character Set

character-set-server = utf8mb4

collation-server = utf8mb4_unicode_ci

การจัดการข้อมูลอย่างถาวรและกลยุทธ์การจัดเก็บ

หนึ่งในความท้าทายที่ใหญ่ที่สุดในการรัน MySQL ใน Docker คือการจัดการ data persistence เนื่องจาก container โดยธรรมชาติแล้วเป็น stateless และ ephemeral ข้อมูลทั้งหมดที่อยู่ใน container จะสูญหายไปเมื่อ container นั้นถูกหยุดหรือลบออก ดังนั้น การ mapping directory ของ host machine เข้าสู่ container โดยใช้ Docker volumes หรือ bind mounts จึงเป็นสิ่งจำเป็นสำหรับการเก็บข้อมูลไว้อย่างถาวร

Docker volumes เป็นกลไกที่แนะนำสำหรับการจัดการ data persistence ใน production environment เนื่องจาก volumes ถูกจัดการโดย Docker engine เอง และให้ประสิทธิภาพที่ดีกว่า bind mounts ในบางกรณี คุณสามารถสร้าง named volume ด้วยคำสั่ง `docker volume create mysql-data` และ map มันไปยัง `/var/lib/mysql` ใน container ได้ การใช้ volumes ยังช่วยให้การ backup, restore, และ migration ของข้อมูลทำได้ง่ายขึ้น

สำหรับระบบ Enterprise ที่ต้องการ performance และความน่าเชื่อถือในระดับสูง การใช้ external storage systems ผ่าน Docker volume drivers เป็นทางเลือกที่เหมาะสม ตัวอย่างเช่น การใช้ driver สำหรับ Amazon EBS, Azure Disk Storage, หรือ Google Persistent Disk ช่วยให้สามารถจัดสรร storage ที่มีความทนทานได้ การกำหนดค่าเหล่านี้มักจะทำในระดับ orchestration platform (เช่น Kubernetes PersistentVolumes) hơnที่จะทำใน Dockerfile โดยตรง

นอกจากข้อมูลของฐานข้อมูลแล้ว ยังมีข้อมูลอื่นๆ ที่ persist เช่น MySQL log files (error log, slow query log, general log) การ map host directories สำหรับ log files เหล่านี้ช่วยให้สามารถเก็บไว้analyzeได้แม้ container จะถูกสร้างแล้วก็ตาม สิ่งสำคัญคือ permissions ของ host directories ถูกตั้งค่า correctly เพื่อให้ MySQL process ใน container สามารถเขียนข้อมูลได้

กระบวนการเริ่มต้นและสคริปต์สำหรับการฐานข้อมูล

กลไกที่สำคัญของ official MySQL Docker image คือการสคริปต์ initialization เมื่อ container ถูกสร้างขึ้นเป็นครั้งแรก (initialization upon first startup) ไดเรกทอรี `/docker-entrypoint-initdb.d/` มีบทบาทพิเศษ ไฟล์ใดๆ ที่อยู่ในรูปแบบ `.sql`, `.sql.gz`, หรือ `.sh` ที่ถูก copy ไปยังไดเรกทอรีนี้จะถูก execute ตามลำดับตัวอักษรหลังจาก MySQL server เริ่มทำงานแล้ว

สคริปต์ initialization เหล่านี้มีประโยชน์อย่างมากสำหรับการการตั้งค่า environment ตัวอย่างของการใช้งานการสร้าง database schema, การ insert seed data, การตั้งค่า user permissions และ privileges, หรือการ load stored procedures เริ่มต้น สคริปต์เหล่านี้ควรให้เป็น idempotent เท่าที่เป็นไปได้ เนื่องจากจะทำงานครั้งแรกเท่านั้นเมื่อ volume ว่างเปล่า

สำหรับการจัดการ user และ privileges การมีสคริปต์แยกต่างหากสำหรับการตั้งค่า permissions เป็นแนวทางปฏิบัติที่ดี instead of relying on environment variables เพียงอย่างเดียว สคริปต์ SQL สามารถ revoke permissions และตั้งค่า privileges แบบ fine-grained ตามความต้องการของ application ได้อย่างแม่นยำยิ่งขึ้น compliance กับนโยบายความปลอดภัยขององค์กร

ในบางสถานการณ์ที่ซับซ้อน อาจ shell script (.sh) สำหรับ logic การ initialize ที่ซับซ้อนกว่า เช่น การดึงข้อมูลจาก external source, การตรวจสอบสภาพแวดล้อม, หรือการเรียกใช้หลายๆ สคริปต์ SQL ตามเงื่อนไข tertentu สิ่งสำคัญคือสคริปต์เหล่านี้มีสิทธิ์ในการ execute (`chmod +x`) และเขียนให้เหมาะสมสำหรับการรันในสภาพแวดล้อมของ container

-- Example init.sql script for database schema creation

CREATE DATABASE IF NOT EXISTS enterprise_app;

USE enterprise_app;



CREATE TABLE IF NOT EXISTS users (

    id INT AUTO_INCREMENT PRIMARY KEY,

    username VARCHAR(50) NOT NULL UNIQUE,

    email VARCHAR(100) NOT NULL UNIQUE,

    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP

) ENGINE=InnoDB;



CREATE TABLE IF NOT EXISTS orders (

    id INT AUTO_INCREMENT PRIMARY KEY,

    user_id INT,

    amount DECIMAL(10, 2),

    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    FOREIGN KEY (user_id) REFERENCES users(id)

) ENGINE=InnoDB;

-- Example privileges.sql script for user permissions

-- Create application user with specific privileges

CREATE USER IF NOT EXISTS 'app_user'@'%' IDENTIFIED BY 'app_password';

GRANT SELECT, INSERT, UPDATE, DELETE ON enterprise_app.* TO 'app_user'@'%';

FLUSH PRIVILEGES;



-- Revoke unnecessary privileges for security

REVOKE ALL PRIVILEGES ON *.* FROM 'app_user'@'%';

GRANT PROCESS ON *.* TO 'app_user'@'%'; -- Often needed for monitoring

considerations ด้านความปลอดภัยสำหรับ MySQL Docker Containers

การรักษาความปลอดภัยให้กับ MySQL container ใน production environment ต้องการความเอาใจใส่อย่างมาก เริ่มต้นจากการไม่ใช้ default environment variables สำหรับรหัสผ่านที่สำคัญใน Dockerfile โดยตรง เนื่องจากค่าที่ hardcode ไว้สามารถถูกพบเห็นได้ผ่าน image history หรือ source control แทนที่ควรใช้ mechanism การ inject secrets อย่างปลอดภัยในเวลารันไทม์ เช่น Docker secrets (ใน Docker Swarm) หรือ external vaults เช่น HashiCorp Vault, AWS Secrets Manager, หรือ Azure Key Vault

การ limit privileges ของ MySQL user ภายใน container เป็นอีกขั้นตอนที่สำคัญ การใช้ root user สำหรับการเชื่อมของ application เป็นเวลานาน standard practice แทนที่ควรสร้าง user เฉพาะที่มี privileges ที่จำเป็นสำหรับการทำงานของ application เท่านั้น การใช้สคริปต์ initialization เพื่อกำหนดช่วยให้สามารถได้

การแยก network ของ container ออกเป็นอีกชั้นหนึ่งของความปลอดภัย MySQL container expose ไปยัง public internet โดยตรง แต่ถูก internal network ที่แยกไว้ และเฉพาะ application containers หรือ service ที่เท่านั้นที่สามารถเชื่อมได้ การใช้ Docker networks ช่วยสร้าง isolation นี้และการเข้าถึง containers

การ image สำหรับ vulnerabilities เป็น practice ที่ควรทำ regularly โดยใช้ tools เช่น Docker Scan, Trivvy, หรือ Clair เพื่อ identify known vulnerabilities ใน base image หรือ dependencies การ integrate การเหล่านี้เข้าไปใน CI/CD pipeline ช่วยว่า image ที่ปลอดภัยเท่านั้นที่จะ production environment นอกจากนี้ การอัปเดต base image อย่างสม่ำเสมอเพื่อรับ patches ด้านความปลอดภัยก็มีความสำคัญอย่างยิ่ง

การ monitor และจัดการ MySQL Containers

การ monitor MySQL containers ใน production ต้องการเครื่องมือและแนวทางที่การ monitor แบบ traditional sedikit due to the dynamic nature of containers การ metrics จาก MySQL container สามารถทำได้ผ่าน methods รวมถึงการใช้ MySQL's performance_schema, slow query log, หรือการ expose metrics ไปยัง external monitoring systems

การ integrate กับ centralized logging system เป็นสิ่งสำคัญสำหรับ Enterprise environment การ MySQL container เพื่อส่ง log ไปยัง stdout/stderr ทำให้ Docker daemon สามารถจัดการ logs ได้ จากนั้น log driver ของ Docker สามารถให้ส่ง logs ไปยัง centralized logging solution เช่น ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, หรือ Datadog ได้ สิ่งนี้ช่วยให้สามารถaggregateและanalyze logs จาก multiple containers ได้ในที่เดียว

สำหรับ performance monitoring การ exporters เช่น MySQLd Exporter สำหรับ Prometheus เป็นทางเลือกที่ได้รับความนิยม Exporter นี้จะ scrap metrics จาก MySQL server และ expose ออกมาในรูปแบบที่ Prometheus สามารถเข้าใจได้ จากนั้น metrics เหล่านี้สามารถvisualizeได้บน Grafana ซึ่งให้ dashboard ที่ comprehensive สำหรับสุขภาพและประสิทธิภาพของฐานข้อมูล

นอกจากการ monitor แล้ว การจัดการ routine maintenance tasks ภายใน container ก็เป็นความท้าทายเช่นกัน เช่น optimization ตาราง, การทำ backup, และการ cleanup data through scripts ที่เรียกใช้ผ่าน cron jobs within the container หรือโดย external orchestrator อย่างไรก็ตาม การ cron jobs ภายใน container อาจไม่ใช่แนวทางปฏิบัติที่ดีที่สุด และพิจารณาใช้ external job scheduler แทน

ข้อดี ข้อเสีย และข้อควรระวังที่สำคัญ

การใช้งาน Dockerfile สำหรับ MySQL นำมาซึ่งข้อได้เปรียบที่สำคัญหลายประการ ความสอดคล้องของสภาพแวดล้อม across all stages of development ซึ่งช่วยลดปัญหา classic ที่ว่า "ทำงานบนเครื่องผมได้" การของ Dockerfile และ associated scripts ให้ความสามารถในการติดตามการเปลี่ยนแปลงและ roll back ไปยัง image version ก่อนหน้าได้หาก การที่เร็วและ reproducible ก็

อย่างไรก็ตาม ข้อเสียและข้อควรระวังที่สำคัญ resource overhead จาก Docker daemon และ containerization layer อาจส่งผลต่อ performance โดยเฉพาะสำหรับ workload ที่ต้องการ disk I/O สูง การจัดการ data persistence ต้องการความเข้าใจอย่างลึกซึ้งเกี่ยวกับ Docker volumes และ storage drivers เพื่อการสูญเสียข้อมูล ความซับซ้อนของการตั้งค่า network สำหรับการเชื่อมต่อระหว่าง containers อาจเป็นเรื่องที่ท้าทายสำหรับผู้เริ่มต้น

ข้อควรระวังที่สำคัญคือ security การ hardcode credentials ใน Dockerfile เป็นอันตรายอย่างยิ่ง เนื่องจากจะถูกเก็บไว้ใน image layer และอาจถูก retrieve ได้ image ให้รับ credentials ผ่าน environment variables ในเวลารันไทม์แทน นอกจากนี้ การใช้ base image ที่ outdated ซึ่ง vulnerabilities ที่

, การ backup และ disaster recovery ต้องการแนวทางที่แตกต่างจากการตั้งค่า MySQL แบบดั้งเดิม การ backup ไม่ทำภายใน container itself แต่ทำ external host ที่สามารถ access data volume ได้ หรือ snapshot mechanism ของ underlying storage system การทดสอบ procedure การ restore ข้อมูลเป็นประจำ untukว่าในสถานการณ์ฉุกเฉิน data สามารถกู้คืนได้ successfully

การเลือก Base Image และการจัดการ Layer

การเลือก Base Image ที่เหมาะสมสำหรับ MySQL Dockerfile เป็นขั้นตอนแรกที่สำคัญ แนะนำให้ใช้ Official Image จาก Docker Hub (เช่น mysql:8.0) เนื่องจากได้รับการอัปเดตและตรวจสอบความปลอดภัยอย่างสม่ำเสมอ ควรระบุ tag เวอร์ชันที่ชัดเจนแทนการใช้ latest เพื่อหลีกเลี่ยงการเปลี่ยนแปลงที่ไม่ได้ตั้งใจ การสร้าง Layer ใน Dockerfile ควรออกแบบให้มีประสิทธิภาพ โดยการเขียนคำสั่งที่เปลี่ยนแปลงบ่อย (เช่น การคัดลอกไฟล์) ไว้ด้านล่าง และคำสั่งที่เปลี่ยนแปลงน้อย (เช่น การอัปเดตแพ็คเกจ) ไว้ด้านบน เพื่อ leverage caching และทำให้การ build image ทำได้รวดเร็วยิ่งขึ้น

การกำหนด Configuration ด้วย Configuration Files

แทนที่จะใช้คำสั่ง RUN ที่ยาวเหยียดใน Dockerfile เพื่อปรับแต่งการ MySQL แนะนำให้ใช้การ mount configuration file จาก host หรือใช้ custom my.cnf

สุขภาพของ Container และการ Monitor

การว่า MySQL container ทำงานอย่างถูกต้องเป็นสิ่งสำคัญ สามารถ HEALTHCHECK instruction ใน Dockerfile เพื่อให้ Docker ดำเนินการตรวจสอบสุขภาพของ container โดยอัตโนมัติได้ โดยทั่วไปจะใช้คำสั่งเช่น mysqladmin ping เพื่อตรวจสอบการทำงานของเซิร์ฟเวอร์ MySQL นอกจากนี้ ควรกำหนด resource constraints (CPU, Memory) ให้กับ container ผ่าน Docker runtime flags เพื่อ container ใช้ทรัพยากรเกินและต่อระบบโฮสต์และ containers อื่นๆ

การอัปเดตและจัดการ Image

ควรมีกระบวนการในการอัปเดต base image และแพ็คเกจต่างๆ ภายใน image เพื่อรับ patches ความปลอดภัยล่าสุด การสร้าง image ใหม่และควรจะเป็นส่วนหนึ่งของ CI/CD pipeline โดยอัตโนมัติ กัน ควรเก็บรักษา image versions ไว้บางส่วนใน image registry เพื่อให้สามารถ roll back ได้ในกรณีที่เกิดปัญหา với image เวอร์ชันใหม่ การใช้ multi-stage builds สามารถช่วยลดขนาดของ image สุดท้ายได้ โดยการ compile หรือเตรียมสิ่งที่จำเป็นใน stage แรก และคัดลอกเฉพาะไฟล์ที่ต้องการไปยัง stage สุดท้าย