Mô hình kinh doanh mới của Docker và Kỷ nguyên trực quan hóa hình ảnh

Với việc phát hành quyền truy cập sớm của Docker Scout , Docker Hub cuối cùng cũng bắt đầu trực quan hóa nội dung hình ảnh. Điều đó thật tuyệt! Tại sao Docker Hub không làm điều này từ nhiều năm trước? Bởi vì mô hình kinh doanh của nó.

Trước khi đi xa hơn, hãy xem lại ngắn gọn Docker image được làm từ gì.

Tổng quan về nội dung

• Hình ảnh Docker được tạo thành từ các lớp
• Tại sao các nhà phát triển xem xét nội bộ hình ảnh Docker
• Cách các nhà phát triển thường xem nội bộ hình ảnh Docker
• Docker Scout: cách tốt hơn để kiểm tra nội bộ hình ảnh
• Điều gì khiến họ mất nhiều thời gian như vậy?
• Nền tảng hai mặt
• Những gì trong quá khứ mới chỉ là sự bắt đầu

Hình ảnh Docker được tạo thành từ các lớp

Khi bạn tải xuống hình ảnh Docker bằng cách chạy docker pull tại dòng lệnh, Docker CLI sẽ hiển thị tiến trình tải xuống của từng lớp khi nó kéo hình ảnh. Nếu bạn đã từng tải xuống Docker image, chắc chắn bạn đã từng nhìn thấy nó:

Nếu bạn đã từng làm việc với Docker trước đây thì có thể bạn đã xác định một số lớp này cho hình ảnh của riêng mình. Các nhà phát triển ngầm xác định các lớp này khi họ viết Dockerfiles. Ví dụ: mỗi dòng trong Dockerfile này tạo ra một lớp:

 FROM ubuntu:22.04 # install apt dependencies RUN apt-get update RUN apt-get install -y iputils-ping python3 python3-pip # install python dependencies RUN pip3 install numpy # cleanup apt lists RUN rm -rf /var/lib/apt/lists/* CMD ["/bin/bash"]

Các lớp là các thư mục Linux được lưu trữ—chúng là các tarball của hệ thống tệp. Docker tải xuống tất cả các lớp hình ảnh của bạn và giải nén từng lớp vào một thư mục riêng. Khi bạn khởi chạy một vùng chứa từ hình ảnh Docker bằng lệnh docker run , trình nền Docker sẽ kết hợp các lớp hình ảnh lại với nhau để tạo thành một vùng chứa.

Phần lớn giá trị gia tăng của Docker dưới dạng sản phẩm là nó trừu tượng hóa những chi tiết này, cho phép người dùng tận dụng lợi ích của các vùng chứa nhiều lớp mà không cần suy nghĩ về cách chúng hoạt động. Nhưng tất cả các thông tin trừu tượng đều bị rò rỉ và Docker cũng không ngoại lệ—đôi khi, bạn cần phải kéo rèm lại.

Tại sao các nhà phát triển xem xét nội bộ hình ảnh Docker

Kiểm tra chuỗi cung ứng

Các lớp hình ảnh Docker chứa câu chuyện gốc cho mọi tệp nhị phân có trong hệ thống tệp của vùng chứa. Dòng đầu tiên trong hình ảnh Docker là "dòng TỪ". Nó xác định hình ảnh Docker (và do đó, các lớp hình ảnh) mà Dockerfile xây dựng trên đó.

Bằng cách kiểm tra các lớp từ Dockerfile hiện tại và các lớp từ chuỗi hình ảnh gốc của nó, nhà phát triển có thể xác định mọi tệp trong hệ thống tệp gốc của vùng chứa đến từ đâu. Đây là thông tin rất có giá trị. Nó giúp các nhà phát triển:

• Tuân thủ các thỏa thuận cấp phép phần mềm
• Vượt qua kiểm tra tuân thủ suôn sẻ hơn
• Phát hiện và tránh các lỗ hổng bảo mật

Hãy tưởng tượng nhấp qua các lớp trong hình ảnh trực quan để theo dõi các thay đổi của tệp trên các phiên bản hình ảnh Docker. Khi quét bảo mật tự động xác định lỗ hổng trong một trong các hình ảnh của bạn, hãy tưởng tượng sử dụng công cụ kiểm tra lớp để xác định lỗ hổng được phát hiện như thế nào.

Tối ưu hóa kích thước hình ảnh

Kích thước hình ảnh quá lớn có thể khiến công ty tốn rất nhiều tiền. Nhiều quy trình CI/CD kéo hình ảnh Docker cho mọi yêu cầu kéo, do đó, việc tải xuống hình ảnh Docker kéo dài có thể làm chậm quy trình, khiến nhà phát triển hoạt động kém hiệu quả hơn và lãng phí thời gian của CPU. Bởi vì các tổ chức thường trả chi phí cơ sở hạ tầng theo giờ nên mỗi giờ bị lãng phí là một khoản chi phí không cần thiết.

Ngoài việc lãng phí tài nguyên điện toán, hình ảnh Docker cồng kềnh có thể dẫn đến chi phí truyền mạng quá cao. Nếu một tổ chức tải xuống hình ảnh Docker trên các khu vực AWS hoặc từ AWS sang mạng internet mở, thì sự phình to của hình ảnh Docker sẽ trực tiếp dẫn đến việc chi tiêu cơ sở hạ tầng lãng phí. Điều này cộng lại nhanh chóng.

Thật dễ dàng để vô tình tạo ra sự phình to vào các lớp hình ảnh Docker của bạn. Dockerfile được mô tả trước đó chứa một ví dụ cổ điển—lớp từ dòng 4 lưu 40 MB tệp trên đĩa, sau này sẽ bị lớp từ dòng 11 xóa. Do cách thức hoạt động của hình ảnh Docker, dữ liệu đó vẫn là một phần của hình ảnh, thêm vào đó 40 MB kích thước hình ảnh không cần thiết.

Đây là một ví dụ đơn giản—trên thực tế, nó lấy ngay từ tài liệu của Docker. Trong các Dockerfile phức tạp hơn, lỗi này có thể khó phát hiện hơn nhiều.

Cách các nhà phát triển thường xem nội bộ hình ảnh Docker

Các lớp hình ảnh của Docker có thể khó tương tác bằng cách sử dụng dòng lệnh, nhưng trước khi Docker Scout được phát hành gần đây, dòng lệnh là nơi bạn sẽ tìm thấy công nghệ tiên tiến nhất. Đây là hai cách tiếp cận cơ bản.

Bắt đầu một container và nhìn vào nó

Đây là phương pháp Unix tự làm, đơn giản. Tất cả những gì bạn cần là một máy chủ chạy daemon Docker. Đó là một cách tiếp cận đơn giản:

1. Chạy docker create để khởi động vùng chứa từ hình ảnh.
2. Sử dụng docker inspect để tìm các thư mục lớp của vùng chứa mới.
3. Tương quan các thư mục lớp đó với các dòng trong hình ảnh Docker.
4. cd vào các thư mục đó ở dòng lệnh và suy luận về các lớp trong đầu bạn.

Đây là một rắc rối. Giả sử chúng tôi đang cố gắng theo dõi một số hình ảnh phình to trong hình ảnh Docker mà chúng tôi đã sử dụng được vài tháng nhưng gần đây đã tăng kích thước đáng kể.

Đầu tiên, chúng ta tạo một thùng chứa từ hình ảnh:

 where-the@roadmap-ends ~ $ docker create --name example where-the-roadmap-ends 339b8905b681a1d4f7c56f564f6b1f5e63bb6602b62ba5a15d368ed785f44f55

Sau đó, docker inspect cho chúng ta biết thư mục lớp của hình ảnh được tải xuống nằm ở đâu trên hệ thống tệp của chúng ta:

 where-the@roadmap-ends ~ $ docker inspect example | grep GraphDriver -A7 "GraphDriver": { "Data": { "LowerDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47-init/diff:/var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff:/var/lib/docker/overlay2/j0dekt7y8xgix11n0lturmf8t/diff:/var/lib/docker/overlay2/zd57mz6l4zrsjk9snc2crphfq/diff:/var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff:/var/lib/docker/overlay2/8c639b22627e0ad91944a70822b442e5bff848968263a37715a293a15483c170/diff", "MergedDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47/merged", "UpperDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47/diff", "WorkDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47/work" }, "Name": "overlay2"

Các lớp mà chúng tôi muốn xem xét cho cuộc điều tra này là danh sách các thư mục "LowerDir". Các thư mục khác không phải là một phần của hình ảnh Docker—chúng ta có thể bỏ qua chúng.

Vì vậy, chúng tôi phân tích danh sách các thư mục "LowerDir" tại dòng lệnh:

 where-the@roadmap-ends ~ $ docker inspect example | grep GraphDriver -A7 | grep LowerDir | awk '{print $2}' | sed 's|"||g' | sed 's|,||g' | sed 's|:|\n|g' /var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47-init/diff /var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff /var/lib/docker/overlay2/j0dekt7y8xgix11n0lturmf8t/diff /var/lib/docker/overlay2/zd57mz6l4zrsjk9snc2crphfq/diff /var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff /var/lib/docker/overlay2/8c639b22627e0ad91944a70822b442e5bff848968263a37715a293a15483c170/diff

Đây là danh sách các lớp trong ảnh, theo thứ tự, lớp thấp nhất xếp trước. Bây giờ chúng ta cần tương quan thủ công các thư mục lớp này với các dòng Dockerfile đã tạo ra chúng.

Thật không may, Docker không cung cấp cho chúng tôi cách trích xuất trực tiếp những dòng này từ hình ảnh Docker — đây là cách tốt nhất chúng tôi có thể nhận được bằng cách sử dụng docker history :

 where-the@roadmap-ends ~ $ docker history where-the-roadmap-ends IMAGE CREATED CREATED BY SIZE COMMENT 6bbac081b2a7 2 hours ago CMD ["/bin/bash"] 0B buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c rm -rf /var/lib/apt/lists/* #… 0B buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c pip3 install numpy # buildkit 70MB buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c apt-get install -y iputils-pi… 343MB buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c apt-get update # buildkit 40.1MB buildkit.dockerfile.v0 <missing> 8 months ago /bin/sh -c #(nop) CMD ["bash"] 0B <missing> 8 months ago /bin/sh -c #(nop) ADD file:550e7da19f5f7cef5… 69.2MB

Sử dụng kết quả đầu ra này, chúng ta có thể xác định lớp nào có thư mục và lệnh Dockerfile nào đã tạo lớp đó (hiển thị trong cột CREATED BY).

Lệnh docker history xuất ra các lớp trong vùng chứa của bạn theo thứ tự giống như docker inspect kê các thư mục lớp. Biết được điều này, chúng ta có thể hợp nhất hai đầu ra lại với nhau theo cách thủ công để xem lớp nào lớn hơn các lớp khác, lệnh Dockerfile nào đã tạo chúng và thư mục nào chứa mỗi lớp.

Đây là nội dung của Lớp A, thực hiện apt-get update :

 where-the@roadmap-ends ~ $ du -hs /var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff/var/lib/apt/lists 38.2M /var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff/var/lib/apt/lists

So với nội dung của lớp B, việc xóa các tệp còn sót lại từ Lớp A:

 where-the@roadmap-ends ~ $ du -hs /var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff/var/lib/apt/lists 4.0K /var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff/var/lib/apt/lists

Thư mục /var/lib/apt/lists tồn tại ở cả hai lớp, nhưng ở Lớp B, thư mục này hầu như không sử dụng khoảng trống.

Đó là vì thư mục của lớp B chứa "tệp trắng", mà Docker sử dụng để đánh dấu các tệp để loại trừ khỏi hệ thống tệp vùng chứa cuối cùng.

Do đó, mặc dù các tệp bị "xóa" trong Lớp B, chúng vẫn tồn tại trong Lớp A và do đó góp phần làm tăng kích thước tổng thể của hình ảnh của bạn—38,2 MB gây ra sự phình to không cần thiết.

Bây giờ, điều đó không dễ dàng sao? 😉

Sử dụng lặn

Phương pháp thủ công phức tạp và khó sử dụng đến mức cộng đồng nguồn mở đã tạo ra một công cụ dành riêng cho nhiệm vụ này—nó có tên là dive . Dive là một công cụ CLI lấy hình ảnh làm đầu vào, phân tích hệ thống tệp của nó và trình bày giao diện người dùng tương tác dựa trên văn bản trong thiết bị đầu cuối của bạn. Nó tương quan với các lớp hình ảnh cho bạn, cho phép bạn kiểm tra các thư mục lớp dễ dàng hơn.

Khi chạy với hình ảnh Docker từ Dockerfile ở trên, nó trông như thế này:

 ┃ ● Layers ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │ Aggregated Layer Contents ├─────────────────────────────────────────────────────────────────────────────── Cmp Size Command └── var 69 MB FROM acee8cf20a197c9 └── lib 40 MB RUN /bin/sh -c apt-get update # buildkit └── apt 343 MB RUN /bin/sh -c apt-get install -y iputils-ping python3 python3-pip # buildkit └── lists 70 MB RUN /bin/sh -c pip3 install numpy # buildkit ├── auxfiles 0 B RUN /bin/sh -c rm -rf /var/lib/apt/lists/* # buildkit ├── lock ├── partial │ Layer Details ├─────────────────────────────────────────────────────────────────────────────────────────── ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-backports_InRelease ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-backports_main_binary-arm64_Packages.lz4 Tags: (unavailable) ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-backports_universe_binary-arm64_Packages.lz4 Id: 2bc27a99fd5750414948211814da00079804292360f8e2d7843589b9e7eb5eee ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_InRelease Digest: sha256:6e6fb36e04f3abf90c7c87d52629fe154db4ea9aceab539a794d29bbc0919100 ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_main_binary-arm64_Packages.lz4 Command: ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_multiverse_binary-arm64_Packages.lz4 RUN /bin/sh -c apt-get update # buildkit ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_restricted_binary-arm64_Packages.lz4 ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_universe_binary-arm64_Packages.lz4 │ Image Details ├─────────────────────────────────────────────────────────────────────────────────────────── ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_InRelease ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_main_binary-arm64_Packages.lz4 Image name: where-the-roadmap-ends ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_multiverse_binary-arm64_Packages.lz4 Total Image size: 522 MB ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_restricted_binary-arm64_Packages.lz4 Potential wasted space: 62 MB ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_universe_binary-arm64_Packages.lz4 Image efficiency score: 90 % ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_InRelease ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_main_binary-arm64_Packages.lz4 Count Total Space Path ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_multiverse_binary-arm64_Packages.lz4 2 28 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy_universe_binary-arm64_Pack ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_restricted_binary-arm64_Packages.lz4 2 7.3 MB /usr/bin/perl └── ports.ubuntu.com_ubuntu-ports_dists_jammy_universe_binary-arm64_Packages.lz4 2 4.4 MB /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30 2 2.9 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy_main_binary-arm64_Packages 2 2.0 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_main_binary-arm64_ 2 1.7 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_universe_binary-ar

Dive là một công cụ tuyệt vời và tôi rất vui vì nó tồn tại—nhưng đôi khi, nó không thành công. Giao diện dựa trên văn bản không phải là giao diện dễ sử dụng nhất—đôi khi Grafana còn đẹp hơn top .

Ngoài ra, hình ảnh lớn có thể lấn át khả năng của Dive. Khi kiểm tra các hình ảnh lớn, Dive tiêu tốn rất nhiều bộ nhớ—đôi khi kernel sẽ tắt tiến trình Dive trước khi nó xuất ra bất kỳ dữ liệu nào.

Docker Scout: cách tốt hơn để kiểm tra nội bộ hình ảnh

Từ quan điểm của nhà phát triển, việc mong đợi trực quan hóa lớp hình ảnh Docker tồn tại trong Docker Hub luôn là điều hợp lý. Xét cho cùng, dữ liệu hình ảnh Docker của chúng tôi đã tồn tại trong phần phụ trợ của Docker Hub.

Tôi thường tưởng tượng việc kiểm tra nội bộ hình ảnh Docker trong trình duyệt của mình bằng cách sử dụng giao diện người dùng trông giống như thế này:

Với Docker Scout, có vẻ như Docker đang đi theo hướng đó với tư cách là một công ty. Hôm nay, nếu tôi điều hướng đến hình ảnh Postgres mới nhất trong Docker Hub, tôi sẽ thấy điều này:

Là một nhà phát triển, điều này thật thú vị. Giao diện người dùng mới này cho phép tôi duyệt qua các chi tiết lớp hình ảnh một cách trực quan, làm nổi bật các vấn đề về lỗ hổng và kích thước hình ảnh giống như tôi muốn.

Điều gì khiến họ mất nhiều thời gian như vậy?

Khi Docker Hub ra mắt lần đầu tiên, nó có hai loại người dùng:

• Các nhà phát triển tải xuống hình ảnh Docker
• Nhà xuất bản phần mềm , người tải lên hình ảnh Docker

Và Docker phải tiếp cận hai loại người dùng này một cách khác nhau.

Sau khi Docker ra mắt vào năm 2013, các nhà phát triển ngay lập tức muốn sử dụng sản phẩm của họ. Bộ chứa Docker chuẩn hóa việc đóng gói và triển khai phần mềm của mọi người. Container nhanh chóng trở nên phổ biến trong cộng đồng nhà phát triển phần mềm.

Tuy nhiên, các nhà xuất bản phần mềm lại do dự hơn. Tại sao họ phải tải phần mềm của mình lên một nền tảng có tiện ích cốt lõi là loại bỏ sự khác biệt giữa các sản phẩm phần mềm?

Docker phải thu phục họ để giúp Docker Hub thành công. Vì vậy, thay vì tập trung vào việc thu hút các nhà phát triển, bộ tính năng và thiết kế của Docker Hub lại phục vụ cho các nhà xuất bản phần mềm.

Đối với các nhà xuất bản, Docker Hub là một trang tiếp thị. Nó đã cho họ một nơi để quảng cáo sản phẩm của họ. Nó không cho phép các nhà phát triển xem chi tiết nội bộ của hình ảnh Docker cũng như các đại lý ô tô không cho phép bạn tháo rời khối động cơ của họ. Các chi tiết kỹ thuật bên trong không được trưng bày mà bị ẩn đi, vì vậy người mua hàng tập trung vào bản thân sản phẩm chứ không phải cách chúng được sản xuất.

Docker Hub thiếu các tính năng dành cho nhà phát triển để tối ưu hóa kích thước hình ảnh và xem xét nội tâm chuỗi cung ứng vì Docker đã thu phục được các nhà phát triển không có các tính năng đó. Trên thực tế, những tính năng đó có xu hướng khiến các nhà xuất bản phần mềm bị coi thường—và họ là những người dùng mà Docker Hub vẫn cần phải thu phục để thành công.

Động lực phục vụ cả nhà xuất bản và nhà phát triển phần mềm này đã khiến Docker Hub trở thành một nền tảng hai mặt.

Nền tảng hai mặt

Nền tảng hai mặt là các doanh nghiệp có hai loại người dùng khác nhau và cần cả hai loại người dùng này tham gia vào nền tảng để mọi thứ hoạt động. Thông thường, động lực sử dụng nền tảng đã chia người dùng thành các nhóm khác nhau.

Mặc dù hai nhóm người dùng có thể không giao dịch trực tiếp với nhau, nhưng nền tảng hai mặt giống như thị trường—chúng không tạo ra giá trị trừ khi nhà cung cấp đến bán và người mua hàng đến mua.

Trong ngành công nghệ, nền tảng hai mặt có mặt khắp nơi. Khi thành công, những mô hình kinh doanh này có xu hướng tạo ra hiệu ứng mạng lưới thúc đẩy doanh nghiệp tăng trưởng và sinh lời bền vững. Sau một thời điểm nhất định, quy mô của nền tảng và vị trí đã được thiết lập trong không gian sẽ thu hút người dùng mới vào nền tảng.

Khi bạn biết mình đang tìm kiếm điều gì, bạn sẽ dễ dàng nhận ra nền tảng hai mặt. Dưới đây là ba ví dụ.

Linkedin

Trên LinkedIn, có hai loại người dùng—nhân viên và người quản lý tuyển dụng. Cả hai nhóm đều tham gia vì những lý do khác nhau - nhân viên muốn có việc làm và người quản lý tuyển dụng muốn thuê người.

Không nhóm nào có thể đạt được điều mình muốn từ địa điểm này cho đến khi nhóm kia bắt đầu tham gia. Sau khi có đủ số lượng người đăng ký trong mỗi nhóm, nó sẽ trở thành địa điểm mặc định dành cho các thành viên mới của một trong hai nhóm và sự phát triển của trang web vẫn tiếp tục duy trì, cho đến khi được Microsoft mua lại với giá 26 tỷ USD.

YouTube

Trên Youtube có người sáng tạo nội dung và có người xem. Người xem đến trang web để xem video—người sáng tạo nội dung xuất bản trên trang web để theo đuổi cảm xúc tốt, danh tiếng và vận may.

Sau khi YouTube tạo dựng được danh tiếng là nơi mà người sáng tạo nội dung có thể thành công, ngày càng có nhiều người sáng tạo nội dung xuất hiện—và khi họ tạo ra nhiều nội dung hơn thì sẽ có nhiều người xem ghé thăm hơn. Sau khi nền tảng này phát triển vượt quá một quy mô nhất định, người sáng tạo nội dung và người xem không còn lựa chọn nào khác ngoài việc tiếp tục sử dụng nền tảng đó—mỗi nhóm đều cần nhau và họ chỉ có thể tìm thấy nhau thông qua YouTube.

Trung tâm Docker

Để Docker Hub trở nên phù hợp, nó cần các nhà xuất bản phần mềm tải hình ảnh lên và nhà phát triển tải chúng xuống. Sau khi có đủ nhà xuất bản đẩy hình ảnh lên Docker Hub, nơi này sẽ trở thành nơi mặc định để các nhà phát triển lấy hình ảnh từ đó. Khi nền tảng tiếp tục phát triển, Docker Hub sẽ củng cố sự thống trị của mình với tư cách là cơ quan đăng ký duy nhất thống trị tất cả.

Những gì trong quá khứ mới chỉ là sự bắt đầu

Ít nhất đó là kế hoạch. Trên thực tế, Docker (công ty) đã từ chối và Docker Hub chưa bao giờ trở thành "một". Khi xây dựng nền tảng hai mặt, các công ty khởi nghiệp có một sản phẩm nhưng họ phải tìm sản phẩm phù hợp với thị trường hai lần. Đối với Docker, gánh nặng này quá sức chịu đựng—cuối cùng, nó đã chia Docker làm đôi .

Giờ đây, sau khi bán hoạt động kinh doanh doanh nghiệp của mình , Docker đã tự đổi mới chính mình, tập trung riêng vào dịch vụ đăng ký dành riêng cho các nhà phát triển và người sử dụng lao động của họ. Docker Hub không còn là nền tảng hai mặt nữa, mà đơn giản là SaaS—khách hàng trả phí hàng tháng để đổi lấy việc đẩy và kéo hình ảnh của họ.

Điều này làm thay đổi phép tính. Docker không còn có tư cách người dùng "nhà xuất bản" để làm hài lòng nữa — tất cả đều thuộc về các nhà phát triển. Đối với Docker Hub, điều này mở đường cho chức năng kiểm tra lớp hình ảnh của Docker Scout. Đối với những người trong chúng ta đang quan sát từ xa, nó thể hiện sự kết hợp tinh tế, mang tính nền tảng giữa mô hình kinh doanh của một công ty khởi nghiệp và việc cung cấp sản phẩm của nó.