06 thg 12, 2025·8 phút
Solomon Hykes và Docker: Tại sao containers trở thành mặc định
Tìm hiểu cách Solomon Hykes và Docker phổ biến containers, khiến Dockerfile, image và registry trở thành tiêu chuẩn để đóng gói và triển khai ứng dụng hiện đại.
Tìm hiểu cách Solomon Hykes và Docker phổ biến containers, khiến Dockerfile, image và registry trở thành tiêu chuẩn để đóng gói và triển khai ứng dụng hiện đại.
Solomon Hykes là kỹ sư đã giúp biến một ý tưởng tồn tại lâu — cô lập phần mềm để nó chạy giống nhau ở mọi nơi — thành thứ các nhóm thực sự có thể dùng hàng ngày. Năm 2013, dự án ông công bố với thế giới trở thành Docker, và nó nhanh chóng thay đổi cách công ty chuyển giao ứng dụng.
Lúc đó, vấn đề thì đơn giản và quen thuộc: một app chạy ổn trên máy lập trình viên, rồi hành xử khác trên máy đồng nghiệp, rồi lại hỏng ở staging hoặc production. Những “môi trường không nhất quán” này không chỉ gây phiền toái — chúng làm chậm phát hành, khiến lỗi khó tái tạo và tạo ra vô số khâu chuyển giữa phát triển và vận hành.
Docker cung cấp cho các nhóm một cách lặp lại để đóng gói ứng dụng cùng các phụ thuộc mà nó cần — nên ứng dụng có thể chạy giống nhau trên laptop, máy test hoặc trên mây.
Đó là lý do người ta nói containers trở thành “đơn vị đóng gói và triển khai mặc định.” Nói ngắn gọn:
Thay vì triển khai “một file zip cộng trang wiki hướng dẫn thiết lập,” nhiều nhóm triển khai một image đã bao gồm những gì app cần. Kết quả là ít bất ngờ hơn và phát hành nhanh, dự đoán được hơn.
Bài viết này kết hợp lịch sử và khái niệm thực tiễn. Bạn sẽ biết Solomon Hykes là ai trong bối cảnh này, Docker giới thiệu điều gì đúng lúc, và cơ chế cơ bản — mà không cần kiến thức hạ tầng sâu.
Bạn cũng sẽ thấy containers phù hợp ở đâu hôm nay: chúng kết nối với CI/CD và quy trình DevOps như thế nào, tại sao công cụ điều phối như Kubernetes trở nên quan trọng sau đó, và những gì containers không tự động sửa (đặc biệt về bảo mật và độ tin cậy).
Cuối cùng, bạn sẽ có thể giải thích — rõ ràng và tự tin — vì sao “ship it as a container” trở thành giả định mặc định cho triển khai ứng dụng hiện đại.
Trước khi containers phổ biến, đưa một ứng dụng từ laptop lập trình viên lên server thường đau đầu hơn cả việc viết ứng dụng. Các đội không thiếu nhân lực — họ thiếu một cách tin cậy để di chuyển “thứ đang chạy” giữa các môi trường.
Một lập trình viên có thể chạy app hoàn hảo trên máy mình, rồi thấy nó lỗi ở staging hoặc production. Không phải vì code thay đổi, mà vì môi trường khác. Phiên bản hệ điều hành khác, thiếu thư viện, file cấu hình hơi khác, hoặc database chạy với mặc định khác có thể phá vỡ cùng một build.
Nhiều dự án phụ thuộc vào hướng dẫn thiết lập dài và mong manh:
Dù viết cẩn thận, những hướng dẫn này nhanh chóng lỗi thời. Một đồng nghiệp nâng cấp một phụ thuộc có thể vô tình phá onboarding cho mọi người.
Tệ hơn, hai app trên cùng một server có thể cần phiên bản runtime hoặc thư viện không tương thích, buộc đội phải tìm giải pháp lắt léo hoặc dùng máy riêng.
“Đóng gói” thường là tạo ZIP, tarball hoặc installer. “Triển khai” lại là một tập script và bước trên server: provision máy, cấu hình, copy file, restart service, và hy vọng không ảnh hưởng tới thứ khác trên server.
Hai mối quan tâm hiếm khi khớp nhau. Package không mô tả đầy đủ môi trường cần, và quy trình triển khai phụ thuộc mạnh vào việc server đích được chuẩn bị “đúng như mong đợi.”
Các đội cần một đơn vị di động duy nhất mang theo phụ thuộc và chạy nhất quán trên laptop, server test và production. Áp lực đó — thiết lập lặp lại, ít xung đột hơn và triển khai dự đoán được — mở đường cho containers trở thành cách mặc định để chuyển phần mềm.
Docker không bắt đầu như một kế hoạch lớn để “thay đổi phần mềm mãi mãi.” Nó phát triển từ công việc kỹ thuật thực tế do Solomon Hykes lãnh đạo khi xây dựng một sản phẩm platform-as-a-service. Nhóm cần một cách lặp lại để đóng gói và chạy ứng dụng trên nhiều máy khác nhau mà không gặp các bất ngờ “chạy được trên máy tôi.”
Trước khi Docker trở nên quen thuộc, nhu cầu cơ bản rất rõ: đóng gói app với phụ thuộc, chạy ổn định và lặp lại cho nhiều khách hàng.
Dự án sau này thành Docker xuất phát từ giải pháp nội bộ — thứ làm cho việc triển khai trở nên dự đoán được và môi trường nhất quán. Khi đội nhận ra cơ chế đóng gói và chạy có ích rộng hơn sản phẩm của họ, họ công bố nó ra công chúng.
Việc công bố này quan trọng vì nó biến kỹ thuật triển khai riêng thành một chuỗi công cụ chung mà cả ngành có thể áp dụng, cải thiện và chuẩn hóa.
Dễ dàng bị nhầm lẫn, nhưng chúng khác nhau:
Containers đã tồn tại dưới nhiều hình thức trước Docker. Điều thay đổi là Docker đóng gói workflow thành tập lệnh và quy ước thân thiện với nhà phát triển — build một image, chạy một container, chia sẻ với người khác.
Một vài bước quen thuộc đã kéo Docker từ “hấp dẫn” thành “mặc định”:
Kết quả thực tế: các lập trình viên ngừng tranh luận cách sao chép môi trường và bắt đầu gửi cùng một đơn vị có thể chạy ở mọi nơi.
Containers là cách đóng gói và chạy một ứng dụng để nó hành xử giống nhau trên laptop, máy đồng nghiệp và production. Ý tưởng chính là cô lập mà không cần một máy tính đầy đủ mới.
Một máy ảo (VM) giống như thuê cả căn hộ: bạn có cửa riêng, tiện ích riêng và bản sao hệ điều hành của riêng bạn. Vì vậy VM có thể chạy các kiểu OS khác nhau cạnh nhau, nhưng nặng và khởi động chậm hơn.
Container giống như thuê một phòng khóa trong tòa nhà chia sẻ: bạn mang đồ đạc (mã + thư viện), nhưng tiện ích của tòa (kernel hệ điều hành) được chia sẻ. Bạn vẫn được tách biệt khỏi các phòng khác, nhưng không phải khởi động một OS hoàn chỉnh mỗi lần.
Trên Linux, containers dựa vào các tính năng cô lập tích hợp:
Bạn không cần biết chi tiết kernel để dùng containers, nhưng biết rằng chúng tận dụng tính năng OS — không phải phép màu.
Containers phổ biến vì:
Containers không phải là biện pháp an ninh theo mặc định. Vì containers chia sẻ kernel host, lỗ hổng ở cấp kernel có thể ảnh hưởng nhiều container. Cũng có nghĩa là bạn không thể chạy container Windows trên kernel Linux (và ngược lại) mà không có ảo hóa bổ trợ.
Vì vậy: containers cải thiện đóng gói và nhất quán — nhưng bạn vẫn cần thực hành bảo mật, vá lỗi và cấu hình đúng đắn.
Docker thành công một phần vì nó đưa ra mô hình tư duy đơn giản với các “phần” rõ ràng: một Dockerfile (hướng dẫn), một image (artifact được build) và một container (phiên bản đang chạy). Khi hiểu chuỗi này, phần còn lại của hệ sinh thái Docker bắt đầu có ý nghĩa.
Dockerfile là file văn bản mô tả cách build môi trường ứng dụng theo từng bước. Nghĩ như công thức nấu ăn: nó không nuôi ai ngay lập tức, nhưng chỉ cho bạn cách để tái tạo món ăn giống nhau mỗi lần.
Các bước Dockerfile thường gặp: chọn base (runtime), copy mã app, cài phụ thuộc, và khai báo lệnh để chạy.
Một image là kết quả build từ Dockerfile. Nó là snapshot đóng gói mọi thứ cần thiết để chạy: mã, phụ thuộc và mặc định cấu hình. Nó không “sống” — giống như một hộp đóng gói có thể chuyển đi.
Một container là khi bạn chạy image. Nó là một tiến trình sống với filesystem và cài đặt riêng. Bạn có thể start, stop, restart và tạo nhiều container từ cùng một image.
Images được build theo lớp. Mỗi lệnh trong Dockerfile thường tạo một layer, và Docker cố gắng tái sử dụng (cache) những layer không thay đổi.
Nói đơn giản: nếu bạn chỉ thay đổi mã ứng dụng, Docker thường có thể tái dùng layer đã cài package hệ điều hành và phụ thuộc, khiến việc rebuild nhanh hơn. Điều này cũng khuyến khích tái sử dụng giữa các dự án — nhiều image chia sẻ layer base chung.
Dưới đây là flow “công thức → artifact → phiên bản chạy”:
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]
docker build -t myapp:1.0 .docker run --rm -p 3000:3000 myapp:1.0Đây là lời hứa cốt lõi Docker phổ biến: nếu bạn build được image, bạn có thể chạy cùng thứ đó một cách đáng tin cậy — trên laptop, trong CI, hoặc trên server — mà không phải viết lại bước cài đặt mỗi lần.
Chạy container trên laptop của bạn hữu ích — nhưng điều làm thay đổi là khi các đội có thể chia sẻ cùng một build và chạy nó ở mọi nơi, không còn tranh luận “chạy được trên máy tôi” nữa.
Docker làm cho việc chia sẻ đó trở nên bình thường như chia sẻ code.
Một container registry là kho lưu trữ cho container images. Nếu image là app đã đóng gói, registry là nơi bạn giữ các phiên bản đóng gói để người khác và hệ thống có thể lấy.
Registry hỗ trợ workflow đơn giản:
Registry công khai (như Docker Hub) giúp bắt đầu dễ dàng. Nhưng hầu hết đội sẽ cần registry phù hợp với quy tắc truy cập và yêu cầu tuân thủ của họ.
Images thường được xác định bằng name:tag — ví dụ myapp:1.4.2. Tag không chỉ là nhãn: đó là cách con người và tự động hóa đồng ý xem phiên bản nào được chạy.
Một sai lầm phổ biến là dựa vào latest. Nghe tiện, nhưng mơ hồ: “latest” có thể thay đổi mà không báo trước, khiến môi trường trôi. Một deploy có thể pull một build mới hơn so với deploy trước đó — dù không ai có ý nâng cấp.
Thói quen tốt hơn:
1.4.2) cho releaseKhi bạn chia sẻ dịch vụ nội bộ, phụ thuộc trả phí hoặc mã công ty, thường bạn muốn registry riêng. Nó cho phép kiểm soát ai có thể pull/push, tích hợp với SSO và giữ phần mềm độc quyền ra khỏi chỉ mục công khai.
Đây là bước nhảy từ laptop đến đội: một khi images sống trong registry, CI, đồng nghiệp và server production đều có thể pull cùng một artifact — và triển khai trở nên lặp lại, không phải ứng biến.
CI/CD hoạt động tốt nhất khi nó coi ứng dụng như một “thứ” duy nhất có thể di chuyển qua các giai đoạn. Containers cung cấp đúng điều đó: một artifact đóng gói (image) mà bạn build một lần và chạy nhiều lần, ít gặp vấn đề “chạy được trên máy tôi”.
Trước containers, các đội cố gắng khớp môi trường bằng hướng dẫn dài và script chia sẻ. Docker thay đổi workflow mặc định: pull repo, build image, chạy app. Các lệnh giống nhau thường hoạt động trên macOS, Windows và Linux vì app chạy trong container.
Sự tiêu chuẩn hóa đó giúp onboarding nhanh hơn. Người mới ít thời gian cài đặt hơn và nhiều thời gian hiểu sản phẩm hơn.
Một pipeline CI/CD tốt hướng đến một đầu ra duy nhất. Với containers, đầu ra là image được tag (thường liên kết với commit SHA). Chính image đó được promote từ dev → test → staging → production.
Thay vì build app khác nhau cho mỗi môi trường, bạn thay đổi cấu hình (như biến môi trường) trong khi giữ artifact nguyên vẹn. Điều này giảm drift và giúp debug release dễ hơn.
Containers tương thích rõ ràng với các bước pipeline:
Bởi vì mỗi bước chạy trên cùng một app đóng gói, lỗi có ý nghĩa hơn: test pass ở CI có khả năng hành xử giống sau khi deploy.
Nếu bạn đang tinh chỉnh quy trình, cũng nên đặt các quy tắc đơn giản (quy ước tagging, ký image, scan cơ bản) để pipeline ổn định. Bạn có thể mở rộng khi đội lớn lên.
Liên hệ với những workflow tạo nhanh bằng AI ngày nay: nền tảng như Koder.ai có thể sinh và lặp ứng dụng full-stack (React trên web, Go + PostgreSQL backend, Flutter cho mobile) qua giao diện chat — nhưng bạn vẫn cần đơn vị đóng gói tin cậy để chuyển từ “chạy được” thành “có thể triển khai”. Xem mỗi build như một image container có phiên bản giữ cho phát triển gia tốc bởi AI vẫn tuân theo kỳ vọng CI/CD: build có thể tái tạo, deploy dự đoán và rollback sẵn sàng.
Docker làm cho việc đóng gói app một lần và chạy ở mọi nơi trở nên khả thi. Thử thách tiếp theo đến nhanh: các đội không chỉ chạy một container trên một laptop — họ chạy hàng chục (rồi hàng trăm) container trên nhiều máy, với các phiên bản thay đổi liên tục.
Khi ấy, “khởi động container” không còn là vấn đề khó nhất. Vấn đề khó là quản lý một đội: quyết định container nào chạy ở đâu, giữ đúng số bản online và phục hồi tự động khi có sự cố.
Khi có nhiều container trên nhiều server, bạn cần hệ thống phối hợp. Đó là chức năng của bộ điều phối (orchestrator): coi hạ tầng như một pool tài nguyên và liên tục làm cho ứng dụng ở trạng thái mong muốn.
Kubernetes trở thành câu trả lời phổ biến cho nhu cầu này (nhưng không phải lựa chọn duy nhất). Nó cung cấp tập khái niệm và API chung mà nhiều đội và nền tảng chuẩn hóa theo.
Tách biệt trách nhiệm sẽ rõ ràng hơn:
Kubernetes giới thiệu (và phổ biến) một số khả năng thực tế đội cần khi containers vượt quá một host:
Tóm lại, Docker làm cho đơn vị trở nên di động; Kubernetes giúp làm cho nó vận hành được — một cách dự đoán khi có nhiều đơn vị cùng chuyển động.
Containers không chỉ thay đổi cách triển khai phần mềm — chúng còn thôi thúc các đội thiết kế phần mềm khác đi.
Trước containers, việc chia app thành nhiều service nhỏ thường nhân lên nỗi đau vận hành: runtime khác nhau, xung đột phụ thuộc và script triển khai phức tạp. Containers giảm ma sát đó. Nếu mỗi service được ship dưới dạng image và chạy giống nhau, tạo service mới ít rủi ro hơn.
Dù vậy, containers cũng hoạt động tốt với monolith. Một monolith trong container có thể đơn giản hơn việc di cư nửa vời sang microservices: một unit deploy, một tập log, một đòn bẩy scaling. Containers không ép phong cách; chúng làm nhiều phong cách dễ quản lý hơn.
Nền tảng container khuyến khích các app hành xử như “hộp đen” có input/output dự đoán. Quy ước phổ biến gồm:
Những giao diện này giúp thay phiên bản, rollback và chạy cùng app trên laptop, CI và production dễ hơn.
Containers phổ biến các building block lặp lại như sidecars (container phụ bên cạnh app chính cho logging, proxy hoặc chứng chỉ). Chúng cũng củng cố quy tắc “một tiến trình mỗi container” — không phải luật cứng nhưng là mặc định hữu ích cho rõ ràng, scaling và debug.
Cạm bẫy chính là chia nhỏ quá mức. Chỉ vì bạn có thể tách mọi thứ thành service không có nghĩa bạn nên làm. Nếu một microservice làm tăng coordination, latency và chi phí triển khai nhiều hơn lợi ích, hãy giữ gộp lại cho đến khi có ranh giới rõ ràng — như nhu cầu scaling khác biệt, ownership khác nhau hoặc tách lỗi hợp lý.
Containers làm cho việc ship phần mềm dễ hơn, nhưng không tự nhiên khiến nó an toàn hơn. Một container vẫn là code cộng phụ thuộc, và có thể cấu hình sai, lỗi thời hoặc độc hại — đặc biệt khi kéo images từ Internet mà kiểm tra không đủ.
Nếu bạn không trả lời được “Image này từ đâu?” thì bạn đang chịu rủi ro. Các đội thường tiến đến chuỗi custody rõ ràng: build image trong CI kiểm soát, ký hoặc attestate thứ đã build, và ghi lại những gì nằm trong image (phụ thuộc, base image, các bước build).
SBOM (Software Bill of Materials) giúp: làm cho nội dung container hiển thị và có thể kiểm toán.
Scan là bước thực tiễn tiếp theo. Scan images thường xuyên để tìm lỗ hổng đã biết, nhưng xem kết quả là dữ liệu để ra quyết định — không phải là bảo đảm an toàn tuyệt đối.
Sai lầm phổ biến là chạy container với quyền rộng — user root mặc định, capability thừa, host networking hoặc privileged mode “vì nó chạy được.” Mỗi thứ mở rộng vùng ảnh hưởng khi có sự cố.
Secrets là bẫy khác. Biến môi trường, file cấu hình bake sẵn hoặc file .env commit có thể làm lộ credential. Ưu tiên store secret hoặc cơ chế secrets của orchestrator và xoay vòng secret như thể rò rỉ là điều tất yếu.
Ngay cả image “sạch” cũng có thể nguy hiểm khi chạy. Cần chú ý socket Docker bị phơi, mount volume quá rộng, và container có thể tiếp cận dịch vụ nội bộ không cần thiết.
Cũng nhớ: vá host và kernel vẫn quan trọng — containers chia sẻ kernel.
Nghĩ theo bốn giai đoạn:
Containers giảm ma sát — nhưng niềm tin vẫn phải được xây dựng, xác minh và liên tục duy trì.
Docker làm đóng gói có thể dự đoán, nhưng chỉ khi bạn dùng nó có kỷ luật. Nhiều đội rơi vào cùng ổ gà — rồi đổ lỗi cho “containers” trong khi thực ra là vấn đề quy trình.
Một sai lầm kinh điển là build image lớn: dùng full OS base image, cài công cụ build không cần khi runtime, copy cả repo (kể cả tests, docs, node_modules). Hậu quả là download chậm, CI chậm và bề mặt tấn công lớn hơn.
Vấn đề khác là build phá cache chậm. Nếu bạn copy toàn bộ source trước khi cài dependencies, mỗi thay đổi nhỏ buộc cài lại toàn bộ phụ thuộc.
Cuối cùng, đội thường dùng tag mập mờ như latest hoặc prod. Điều này làm rollback khó và biến triển khai thành chuyện đoán.
Thường là khác biệt về cấu hình (thiếu env vars hoặc secrets), mạng (hostnames, ports, proxy, DNS khác), hoặc lưu trữ (ghi dữ liệu vào filesystem container thay vì volume, hoặc quyền file khác giữa môi trường).
Dùng slim base images khi có thể (hoặc distroless nếu đội sẵn sàng). Pin phiên bản cho base image và phụ thuộc chính để build lặp lại được.
Áp dụng multi-stage builds để giữ compiler và công cụ build ra khỏi final image:
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:20-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
CMD ["node","dist/server.js"]
Cũng tag image bằng thứ có thể truy vết như git SHA (và tùy chọn một tag thân thiện với con người).
Nếu app thật sự đơn giản (một binary tĩnh, chạy ít, không cần scale), containers có thể thêm overhead. Hệ thống legacy gắn chặt với OS hoặc driver phần cứng đặc thù cũng có thể không phù hợp — đôi khi VM hoặc dịch vụ managed là lựa chọn sạch hơn.
Containers trở thành mặc định vì chúng giải quyết một cơn đau rất cụ thể: làm cho cùng ứng dụng chạy giống nhau trên laptop, test server và production. Đóng gói app cùng phụ thuộc giúp triển khai nhanh hơn, rollback an toàn hơn và handoff giữa các nhóm bớt mong manh.
Cùng quan trọng, containers chuẩn hóa workflow: build một lần, ship, run.
“Mặc định” không có nghĩa mọi thứ chạy Docker ở khắp nơi. Nó có nghĩa hầu hết pipeline hiện đại coi container image là artifact chính — hơn là một zip, snapshot VM hay tập các bước thủ công.
Mặc định thường bao gồm ba thành phần hoạt động cùng nhau:
Bắt đầu nhỏ và tập trung vào lặp lại.
.dockerignore sớm.1.4.2, main, sha-…) và định rõ ai được push vs pull.Nếu bạn thử nghiệm các cách nhanh hơn để build phần mềm (bao gồm cách làm bằng AI), giữ kỷ luật: version image, lưu nó trong registry và make deployments promote artifact đơn lẻ đó. Đó là lý do các đội dùng Koder.ai vẫn hưởng lợi từ delivery hướng container — lặp nhanh tốt, nhưng khả năng tái tạo và rollback mới làm cho việc đó an toàn.
Containers giảm vấn đề “chạy được trên máy tôi,” nhưng không thay thế thói quen vận hành tốt. Bạn vẫn cần monitoring, phản ứng sự cố, quản lý secrets, vá lỗi, kiểm soát truy cập và xác định rõ trách nhiệm.
Hãy coi containers là một tiêu chuẩn đóng gói mạnh mẽ — không phải là lối tắt thay cho kỷ luật kỹ thuật.
Solomon Hykes là kỹ sư dẫn dắt công việc biến ý tưởng cô lập hệ thống ở mức OS (containers) thành một quy trình thân thiện với nhà phát triển. Năm 2013, công việc đó được công bố dưới tên Docker, giúp các nhóm có thể đóng gói ứng dụng cùng các phụ thuộc và chạy nhất quán giữa các môi trường.
Containers là khái niệm nền tảng: các tiến trình cô lập sử dụng tính năng của hệ điều hành (ví dụ namespaces và cgroups trên Linux). Docker là bộ công cụ và tập quán giúp việc tạo, chạy và chia sẻ containers trở nên dễ dàng hơn (ví dụ: Dockerfile → image → container). Ngày nay bạn có thể dùng containers mà không cần Docker, nhưng Docker đã phổ biến hóa quy trình này.
Nó giải quyết vấn đề “works on my machine” bằng cách gói mã ứng dụng cùng các phụ thuộc vào một đơn vị có thể lặp lại và di động. Thay vì triển khai một file ZIP kèm hướng dẫn thiết lập, các nhóm triển khai một image container có thể chạy giống nhau trên laptop, CI, staging và production.
Một Dockerfile là công thức xây dựng.
Một image là kết quả đã build (snapshot bất biến bạn có thể lưu và chia sẻ).
Một container là phiên bản đang chạy của image đó (một tiến trình sống với filesystem/cấu hình cô lập).
Tránh latest vì nó mơ hồ và có thể thay đổi bất ngờ, làm môi trường bị trôi. Các lựa chọn tốt hơn:
1.4.2sha-<hash>)Registry là nơi lưu trữ image container để máy khác hoặc hệ thống có thể pull cùng một bản build.
Quy trình thường gặp:
Hầu hết đội ngũ cần registry riêng (private registry) cho quyền truy cập, tuân thủ và để code nội bộ không xuất hiện trên các kho công khai.
Containers chia sẻ kernel của máy chủ nên thường nhẹ hơn và khởi động nhanh hơn VM.
Một mô hình đơn giản:
Hạn chế thực tế: thường không thể chạy container Windows trên Linux kernel (và ngược lại) mà không có ảo hóa bổ trợ.
Chúng cho phép bạn tạo một đầu ra duy nhất cho pipeline: image.
Mô hình CI/CD phổ biến:
Bạn thay đổi cấu hình (env vars/secrets) theo môi trường, không thay artifact, nên ít drift và dễ rollback hơn.
Docker làm việc “chạy container” trên một máy trở nên dễ. Khi ở quy mô lớn, bạn cần thêm những thứ như:
Kubernetes cung cấp các khả năng đó để điều hành đội container một cách có thể dự đoán trên nhiều máy.
Containers giúp đóng gói nhất quán nhưng không tự động biến phần mềm an toàn. Một số cơ bản thực tế:
privileged, giảm capability, không chạy root nếu được)Với các lỗi thường gặp (image quá lớn, build phá cache, tag không rõ), xem thêm: /blog/common-mistakes-and-how-to-avoid-them