Skip to main content

1. Tổng quan Container & Docker

Mục lục


1. Vì sao Container ra đời?

Những ngày tăm tối cũ

Ứng dụng vận hành doanh nghiệp — ứng dụng sập, doanh nghiệp chịu thiệt hại, thậm chí có thể biến mất. Điều này ngày càng đúng hơn theo thời gian.

Phần lớn ứng dụng chạy trên server, và trước đây mỗi server chỉ chạy được 1 ứng dụng duy nhất. Thế giới open-system (Windows, Linux) lúc đó chưa có công nghệ nào đủ an toàn để chạy nhiều ứng dụng cùng lúc trên chung 1 server.

Kịch bản quen thuộc: mỗi khi doanh nghiệp cần 1 ứng dụng mới, IT lại phải mua hẳn 1 server mới — mà phần lớn thời gian không ai biết trước ứng dụng đó cần bao nhiêu tài nguyên. IT buộc phải đoán khi chọn cấu hình server. Vì sợ mua thiếu (server yếu có thể khiến giao dịch thất bại, mất khách, mất doanh thu), IT luôn có xu hướng mua server to hơn hẳn mức cần thiết. Kết quả: hàng loạt server chỉ chạy ở mức 5-10% công suất thực — một sự lãng phí lớn vốn và tài nguyên công ty.

VMware xuất hiện

Giữa bối cảnh đó, VMware mang tới máy ảo (VM) — gần như chỉ sau một đêm, thế giới IT thay đổi hẳn. Lần đầu tiên có 1 công nghệ đủ an toàn để chạy nhiều ứng dụng doanh nghiệp trên cùng 1 server vật lý.

Đây là bước ngoặt: IT không còn phải mua hẳn server mới mỗi khi có ứng dụng mới — phần lớn trường hợp có thể tận dụng server sẵn có đang dư tài nguyên. Công ty đột nhiên khai thác được nhiều giá trị hơn hẳn từ tài sản hạ tầng sẵn có.

Nhược điểm của VM

Nhưng VM không hoàn hảo. Mỗi VM đòi hỏi 1 OS riêng đầy đủ — mỗi OS lại ngốn thêm CPU, RAM, storage lẽ ra có thể dùng để chạy thêm ứng dụng; mỗi OS lại cần patch, cần giám sát riêng; và trong nhiều trường hợp còn tốn thêm license riêng. Tất cả đều là lãng phí cả về chi phí vận hành (op-ex) lẫn chi phí đầu tư (cap-ex).

VM còn chậm khởi động, và khả năng di chuyển (portability) không tốt — di chuyển workload VM giữa các hypervisor hay giữa các nền tảng cloud khó hơn mức cần thiết.

Container lên ngôi

Các công ty vận hành ở quy mô web-scale như Google đã dùng công nghệ container để giải quyết đúng những hạn chế này của mô hình VM từ rất lâu trước đó.

Trong mô hình container, container tương đương với VM về vai trò — nhưng khác biệt cốt lõi là container không cần 1 OS đầy đủ riêng. Toàn bộ container trên cùng 1 host dùng chung 1 OS, giải phóng lượng lớn tài nguyên hệ thống (CPU, RAM, storage), giảm chi phí license, giảm gánh nặng patch/bảo trì OS — tiết kiệm cả cap-ex lẫn op-ex.

Container cũng khởi động nhanh và cực kỳ dễ di chuyển — chuyển workload container từ laptop lên cloud, rồi sang VM hoặc bare-metal trong data center, gần như liền mạch.

VM Model vs Container ModelContainers (Docker)Virtual MachinesNhẹ · dùng chung 1 OSApp Aown depsApp Bown depsApp Cown depsDocker EngineHost OSHardware InfrastructureNặng · mỗi VM 1 OS riêngVM 1Guest OSown depsApp AVM 2Guest OSown depsApp BHypervisor (e.g. ESXi)Hardware Infrastructure= 1 khoản "thuế OS" duy nhất= N khoản "thuế OS" riêng biệtCùng phần cứng, cùng nhiệm vụ — khác nhau ở khoản "thuế OS" phải trả cho mỗi instance

Container Linux

Container hiện đại bắt nguồn từ thế giới Linux, là thành quả của rất nhiều người và tổ chức đóng góp trong thời gian dài — riêng Google đã đóng góp không ít công nghệ liên quan tới container vào chính Linux kernel. Không có những đóng góp đó, container hiện đại như ngày nay khó lòng tồn tại.

Một vài công nghệ nền tảng giúp container bùng nổ những năm gần đây: kernel namespace, control group (cgroup), và dĩ nhiên là Docker.

Dù vậy, trước Docker, container vẫn phức tạp và nằm ngoài tầm với của phần lớn tổ chức. Phải tới khi Docker xuất hiện, container mới thực sự được phổ cập tới số đông.

Trước Docker và container hiện đại, đã tồn tại nhiều công nghệ ảo hóa cấp OS tương tự — có loại thậm chí bắt nguồn từ System/360 trên Mainframe. BSD Jails và Solaris Zones là 2 ví dụ nổi tiếng khác của công nghệ kiểu container trên Unix. Nội dung tài liệu này chỉ tập trung vào container hiện đại — loại được Docker phổ biến hóa.

Docker xuất hiện

Docker chính là "phép màu" biến Linux container từ thứ chỉ dân chuyên sâu mới dùng được, thành thứ ai cũng dùng được. Nói ngắn gọn: Docker, Inc. biến container trở nên đơn giản.

Container trên Windows và Mac

Microsoft đã đầu tư rất nhiều công sức để đưa Docker và công nghệ container lên nền tảng Windows, phối hợp chặt chẽ với Docker, Inc. Tại thời điểm cuốn sách gốc được viết, Windows container đã có mặt trên Windows 10 và Windows Server 2016. Tập công nghệ Windows lõi để hiện thực container được gọi chung là Windows Containers, còn công cụ tương tác ở tầng user-space vẫn chính là Docker — nhờ vậy trải nghiệm Docker trên Windows gần như giống hệt Docker trên Linux.

Điểm quan trọng cần nhớ: 1 container đang chạy luôn dùng chung kernel của máy host đang chạy nó. Container build để chạy trên host có kernel Windows sẽ không chạy được trên host Linux, và ngược lại — về lý thuyết, Windows container cần Windows host, Linux container cần Linux host. Tuy vậy thực tế không đơn giản như vậy: các sản phẩm như Docker for Windows có thể chuyển đổi qua lại giữa 2 chế độ Windows container và Linux container trên cùng 1 máy Windows 10.

Với Mac, chưa từng có khái niệm "Mac container" — nhưng vẫn chạy được Linux container trên máy Mac thông qua sản phẩm Docker for Mac, hoạt động bằng cách chạy container bên trong 1 Linux VM nhẹ ẩn phía sau, liền mạch tới mức developer gần như không cảm nhận được có VM ở đó.

Tóm tắt

Từng có thời mỗi lần cần ứng dụng mới là phải mua hẳn server mới. Rồi VMware xuất hiện, giúp IT khai thác giá trị tốt hơn từ tài sản hạ tầng sẵn có lẫn mới mua. Nhưng VM cũng không hoàn hảo. Tiếp nối thành công của VMware và hypervisor là 1 công nghệ ảo hóa nhẹ và hiệu quả hơn: container. Ban đầu container khó triển khai, chỉ tồn tại trong data center của các hãng web-scale có sẵn đội kỹ sư Linux kernel chuyên sâu — cho tới khi Docker, Inc. xuất hiện và đưa công nghệ ảo hóa bằng container tới với số đông.


2. Docker là ai, là gì?

Ba nghĩa của từ "Docker"

Không thể bàn về container mà không nhắc tới Docker. Nhưng khi ai đó nói "Docker", họ có thể đang nói tới ít nhất 3 thứ khác nhau:

  1. Docker, Inc. — công ty.
  2. Docker — công nghệ container runtime và orchestration.
  3. Docker — dự án mã nguồn mở (nay đã đổi tên thành Moby).

Muốn "sống sót" trong thế giới container, cần hiểu rõ cả 3 nghĩa này.

Nói ngắn gọn: Docker là phần mềm chạy trên Linux và Windows, dùng để tạo, quản lý, và orchestrate container. Phần mềm này được phát triển công khai trong khuôn khổ dự án mã nguồn mở Moby trên GitHub. Docker, Inc. là công ty đặt tại San Francisco, đóng vai trò maintainer chính của dự án mã nguồn mở này, đồng thời cung cấp thêm các bản Docker thương mại kèm hợp đồng hỗ trợ.

Docker, Inc. — từ dotCloud tới startup tỷ đô

Docker, Inc. là startup công nghệ có trụ sở tại San Francisco, do Solomon Hykes — developer kiêm doanh nhân gốc Pháp — sáng lập.

Thú vị là Docker, Inc. khởi đầu không phải với cái tên đó, mà là 1 nền tảng platform-as-a-service (PaaS) tên dotCloud. Phía sau nền tảng dotCloud sử dụng Linux container, và để tạo/quản lý các container đó, đội ngũ dotCloud tự xây 1 công cụ nội bộ, đặt biệt danh là "Docker". Đó chính là khởi nguồn của cái tên Docker.

Năm 2013, mảng kinh doanh PaaS của dotCloud gặp khó khăn, công ty cần 1 hướng đi mới. Họ thuê Ben Golub về làm CEO mới, đổi thương hiệu công ty thành "Docker, Inc.", loại bỏ hẳn nền tảng PaaS dotCloud, và bắt đầu hành trình mới với sứ mệnh đưa Docker và container tới với thế giới.

Tại thời điểm sách gốc được viết, Docker, Inc. đã huy động hơn 180 triệu USD qua 7 vòng gọi vốn từ những quỹ đầu tư mạo hiểm lớn ở Silicon Valley, với định giá thị trường ước tính khoảng 1 tỷ USD — và duy trì đội ngũ khoảng 200-300 nhân sự. Công ty cũng tổ chức hội nghị thường niên DockerCon, quy tụ cả hệ sinh thái container để thúc đẩy việc áp dụng Docker và công nghệ container nói chung.

Từ "Docker" xuất phát từ 1 từ lóng của Anh, chỉ công nhân bốc dỡ hàng ở cảng — người load/unload hàng lên xuống tàu.

Docker Engine — trái tim của mọi thứ

Khi phần lớn dân kỹ thuật nói "Docker", thứ họ thực sự nhắc tới là Docker Engine — phần mềm hạ tầng lõi chịu trách nhiệm chạy và orchestrate container.

💡 Hình dung: với ai quen thuộc VMware, Docker Engine giống hệt ESXi ở vai trò của nó — ESXi là hypervisor lõi chạy VM, còn Docker Engine là container runtime lõi chạy container.

Mọi sản phẩm khác — của chính Docker, Inc. lẫn bên thứ ba — đều xây xung quanh và cắm vào Docker Engine ở trung tâm.

Docker Engine tải về được từ website Docker, hoặc tự build từ source trên GitHub, có mặt trên cả Linux và Windows, với cả bản mã nguồn mở lẫn bản có hỗ trợ thương mại. Tại thời điểm viết sách, có 2 phiên bản chính: Enterprise Edition (EE)Community Edition (CE) — cả 2 đều có kênh phát hành ổn định theo quý (CE được hỗ trợ 4 tháng, EE được hỗ trợ 12 tháng), riêng CE có thêm kênh phát hành hàng tháng dành cho bản edge. Cách chia 2 bản này chỉ đúng trong giai đoạn sách được viết — mảng Enterprise sau đó đã tách khỏi Docker, Inc. (xem Nguồn tham khảo).

Từ Q1/2017, Docker đổi cách đánh số version theo dạng YY.MM-xx (tương tự Ubuntu) thay vì kiểu major.minor cũ — ví dụ bản CE đầu tiên phát hành tháng 6/2017 mang số hiệu 17.06.0-ce.

Moby — dự án mã nguồn mở đứng sau Docker

"Docker" còn dùng để chỉ chính dự án mã nguồn mở Docker — tập hợp tool được gộp lại thành Docker daemon và Docker client mà bạn tải về từ docker.com. Tuy nhiên dự án này đã được đổi tên chính thức thành Moby project tại DockerCon 2017 (Austin, Texas) — repo GitHub chuyển từ docker/docker sang moby/moby, kèm theo logo riêng.

Mục tiêu của Moby là chia nhỏ Docker thành các thành phần module hóa hơn, và thực hiện việc đó hoàn toàn công khai. Danh sách sub-project/tool hiện có nằm tại github.com/moby, riêng Docker Engine lõi nằm ở github.com/moby/moby — các phần khác tiếp tục được tách nhỏ và module hóa dần theo thời gian.

Là dự án mã nguồn mở, source code công khai, ai cũng có thể tải về, đóng góp, tùy biến, sử dụng — miễn tuân theo giấy phép Apache License 2.0. Nhìn vào lịch sử commit sẽ thấy sự góp mặt của những cái tên lớn trong ngành hạ tầng như RedHat, Microsoft, IBM, Cisco, HPE, cùng nhiều cá nhân độc lập. Phần lớn project và tool viết bằng Golang.


3. Hệ sinh thái Container & chuẩn OCI

Triết lý "Batteries included but removable"

Một trong những triết lý cốt lõi của Docker, Inc. thường được gọi là "Batteries included but removable" — nghĩa là phần lớn thành phần gốc của Docker đều có thể tháo ra và thay bằng thành phần từ bên thứ ba. Ví dụ điển hình là networking: Docker có sẵn networking stack tích hợp, nhưng stack này có thể pluggable — gỡ networking gốc của Docker và thay bằng giải pháp bên thứ ba là chuyện rất phổ biến.

Giai đoạn đầu, plugin bên thứ ba thường tốt hơn hẳn thành phần mặc định đi kèm Docker — điều này từng tạo ra thách thức về mô hình kinh doanh cho Docker, Inc. (công ty vẫn cần có lợi nhuận để tồn tại lâu dài), nên các "battery" mặc định ngày càng được cải thiện, kéo theo cạnh tranh trong hệ sinh thái ngày càng gay gắt hơn. Nhưng nhìn chung, "battery" gốc của Docker vẫn luôn tháo ra được — chỉ là ngày càng ít lý do để phải tháo ra mà thôi.

Hệ sinh thái container vì vậy vừa hợp tác vừa cạnh tranh — cộng đồng hay gọi đây là "co-opetition" (kết hợp giữa cooperation và competition) hoặc "frenemy" (vừa là bạn vừa là đối thủ). Cạnh tranh lành mạnh chính là động lực cho đổi mới.

Vì sao cần Open Container Initiative (OCI)?

Không thể bàn về Docker và hệ sinh thái container mà bỏ qua Open Container Initiative (OCI) — hội đồng quản trị (governance council) chịu trách nhiệm chuẩn hóa những thành phần nền tảng nhất của hạ tầng container, như định dạng image và container runtime.

Docker phát triển với tốc độ chóng mặt ngay từ đầu, được dùng theo ngày càng nhiều cách khác nhau — và tất yếu, một số bên bắt đầu cảm thấy chưa hài lòng. Cụ thể, công ty CoreOS không đồng tình với cách Docker triển khai một số việc, nên họ tự tạo ra 1 chuẩn mở mới tên appc, định nghĩa riêng định dạng image và container runtime, kèm theo 1 bản hiện thực chuẩn đó tên rkt (đọc là "rocket"). Điều này đẩy hệ sinh thái container vào thế có 2 chuẩn cạnh tranh nhau cùng lúc — cạnh tranh vốn thường là điều tốt, nhưng cạnh tranh giữa 2 chuẩn lại thường gây rối và làm chậm việc áp dụng công nghệ.

Trước tình huống đó, các bên liên quan ngồi lại và cùng thành lập OCI — 1 hội đồng gọn nhẹ, linh hoạt để quản trị chuẩn chung cho container. Tại thời điểm sách gốc được viết, OCI đã công bố 2 chuẩn:

  • Image spec — quy định định dạng image.
  • Runtime spec — quy định chuẩn cho container runtime.

💡 Hình dung: giống hệt cách ngành vận tải biển từng chuẩn hóa kích thước container hàng hóa (ISO 668) — trước đó mỗi hãng tàu tự chế khung container riêng, cẩu ở cảng này lắp vừa thì sang cảng khác lại không tương thích. Khi cả ngành thống nhất về đúng 1 bộ kích thước chuẩn, bất kỳ container nào cũng lên được bất kỳ tàu, xe tải, hay cần cẩu nào, bất kể hãng nào sản xuất ra nó. OCI đang làm đúng việc đó, chỉ khác là chuẩn hóa "kích thước" của container phần mềm thay vì container thép.

Docker vs CoreOS → hợp nhất thành OCIDocker(độc quyền ban đầu)tự định nghĩa image formattự định nghĩa container runtimeCoreOSappc — chuẩn image riêngrkt ("rocket") — runtime riêngkhông đồng tình cách Docker làm⚠ 2 chuẩn cạnh tranh nhau — gây rối, chậm áp dụng công nghệOCI — Open Container Initiativebảo trợ bởi Linux Foundation✔ 1 chuẩn chung — runtime nào tuân theo cũng cắm được vào Docker/KubernetesImage specRuntime specTừ Docker 1.11, Docker Engine tuân theo đúng OCI runtime spec

2 chuẩn OCI có ảnh hưởng lớn tới kiến trúc và thiết kế của chính Docker — từ bản Docker 1.11, kiến trúc Docker Engine đã tuân theo đúng OCI runtime spec. OCI hoạt động dưới sự bảo trợ của Linux Foundation, với Docker, Inc. và CoreOS, Inc. là những bên đóng góp chính.

Chuẩn hóa luôn đi kèm đánh đổi: nó làm chậm tốc độ đổi mới — nhất là với công nghệ đang phát triển với tốc độ cực nhanh như container. Đây là lý do vẫn thường xuyên có tranh luận sôi nổi trong cộng đồng container về ranh giới giữa chuẩn hóa và đổi mới.

Theo kinh nghiệm vận hành thực tế, phần lớn kỹ sư mới tiếp xúc Docker hay bỏ qua đúng nền tảng đã nói ở trên — cứ tưởng Docker "tự chế ra" container, trong khi thực chất giá trị lớn nhất của Docker, Inc. nằm ở việc đóng gói namespace/cgroup (vốn đã có sẵn trong Linux kernel từ trước) thành 1 trải nghiệm dễ dùng, rồi thúc đẩy cả ngành thống nhất theo chuẩn OCI. Hiểu đúng lịch sử này giúp không bị choáng khi sau này gặp runtime khác ngoài Docker (containerd trần, CRI-O...) — vì tất cả đều nói chung 1 "ngôn ngữ" OCI.

Biết container là gì và Docker đứng ở đâu trong bức tranh đó vẫn chưa đủ để bắt đầu làm việc — còn thiếu đúng 1 thứ: có Docker chạy thật trên máy. Phần tiếp theo lo đúng việc đó, trên cả Windows, Mac, Linux lẫn Windows Server — mỗi nơi Docker "giấu" phần kernel Linux cần thiết theo 1 cách khác nhau.


Nguồn tham khảo

Nguồn gốc: Bài viết lấy cảm hứng từ sách "Docker Deep Dive" — tác giả Nigel Poulton (bản phát hành version 4, 3/10/2017), Part 1: The Big Picture Stuff — chapter 1 "Containers from 30,000 feet" và chapter 2 "Docker". Nội dung được viết lại theo cách hiểu và ví dụ riêng, không sao chép nguyên văn hay dịch sát nguyên bản. Muốn đọc bản đầy đủ hoặc ủng hộ tác giả, có thể mua sách tại leanpub.com/dockerdeepdive.

Đính chính/cập nhật (fact-check):

  • Mảng Enterprise của Docker (Docker Engine Enterprise, Docker Trusted Registry, Universal Control Plane, CLI) đã được bán cho Mirantis — 11/2019, Mirantis press release
  • dotCloud (tiền thân Docker, Inc.) có 3 đồng sáng lập: Kamel Founadi, Solomon Hykes, Sebastien Pahl, thành lập tại Paris năm 2008 — Wikipedia — Docker, Inc.
  • Ben Golub trở thành CEO tháng 7/2013; dotCloud đổi tên chính thức thành Docker ngày 29/10/2013 — Wikipedia — Docker, Inc.
  • Tổng vốn Docker, Inc. huy động qua các vòng seed/A/B/C/D (2011-2015) cộng dồn xấp xỉ $178.8M, định giá vượt 1 tỷ USD sau vòng Series D (4/2015) — khớp đúng số liệu "hơn $180M, ~$1BN" nêu trong sách — Wikipedia — Docker, Inc.
  • Moby project được công bố ngày 18/4/2017 tại DockerCon (Austin, Texas) — 2017, Docker Blog — Introducing Moby
  • Docker 1.11 (4/2016) là bản Docker Engine đầu tiên tuân thủ OCI runtime spec, xây trên containerd + runc — 2016, Docker Blog — Docker 1.11