萬字長文搞定 Docker，請收藏！

這周分享的內容是關於 Docker 的基礎，大概的內容分爲下面的兩個部分

前言

第一趴 ---Docker 容器圈簡介

Docker 容器圈簡介

第二趴 ---Docker 基本操作

Docker 基本操作

容器圈

容器這個新生事物，現在還可以說是新生事物嗎？對於我們學生而言，我覺得沒毛病，你說呢？

容器技術可說重塑了整個雲計算市場的形態，帶動了一批年輕有爲的容器技術兒，不過「容器」這個概念是 Docker 公司發明的麼，不是，它只是衆多 Pass 項目中的最底層，沒人關注的那一部分而已。

什麼是 Pass 項目？

Pass 項目之所會被很多公司所接受，自然是因爲解放了部分開發人員的勞動力，儘快幹玩活兒早點下班。其依賴的就是「應用託管」的能力，在電腦上鬥過地主的應該知道，託管了以後就會自動出牌，同樣的道理，爲了儘量的彌補本地和雲上的環境差異，就出現了 Pass 開源項目。

舉個例子來說，運維人員小仙雲上部署一個 Cloud Foundry 項目，開發人員只需要簡單的一行代碼就可以實現將本地的應用部署到雲上

就這樣一行代碼就實現了將本地應用上傳到雲上，屬實很輕鬆。

那麼這個命令執行的基本原理是怎樣的？

實際上，我們可以將其最核心的組件理解爲一套應用的打包和分發機制。雲上部署的 Cloud Foundry 會爲大部分編程語言定義一種打包的格式，當開發人員執行命令的時候，實際上是將可執行文件和啓動腳本打包上傳到雲上的 Coulud Foudry 中，然後 Cloud Foundry 通過相應的調度器選擇一個虛擬機的 Agent 將壓縮包下載後啓動

那如何區分虛擬機中的不同應用呢？

虛擬機一般不可能只跑一個應用，因爲這樣確實也太浪費資源了，我們可以想想，現在手上的電腦，可以用 Vmvare 導入幾個虛擬機，所以諸如 Cloud Foundry 通過引入操作系統的 Cgroups 和 Namespace 等機制，從而來爲每個應用單獨創建一個叫做「沙盒」的隔離環境，然後在這些「沙盒」中啓動應用，通過這樣的方法就讓虛擬機中應用各自互不干擾，讓其自由翱翔，至於 Cgroups 和 **Namespace ** 的實現原理，後續我們再共同的探討

這裏所謂的隔離環境就是「容器」。

那 Docker 和這 Pass 項目的 Cloud Foundry 的容器有啥不一樣？

自然不一樣，不然現在我們一旦提到容器，想到的不會是 Docker，而是 Cloud Foundry 了吧。Cloud Foundry 的首席產品經理就覺得沒什麼，畢竟自己放的屁都是香的！

不一樣，而且當時還發了一份報告，報告中還寫到：“ Docker 不就是使用了  Cgroups  和  Namespace  實現的「沙盒」而已，不用過於關注”。

沒想到的是，隨後短短的幾個月，Docker 項目迅速起飛以至於其他所有  Paas  社區都還沒來及反應過來，就已經宣告出局

什麼魔力讓 Docker 一發不可收拾？

就是提出了鏡像的概念。上面我們說過，Paas  提供的一套應用打包的功能，看起很輕鬆省事，但是一旦使用了 Paas，你就要終身服務於它，畢竟他是提供商，是「爸爸」，用戶需要爲每個版本，每種語言去維護一個包，這個打包的過程是需要多次的嘗試，多次試錯後，才能摸清本地應用和遠端 Paas 的脾氣，從而順利部署。

而 Docker 鏡像恰恰就是解決了打包這一根本問題。

什麼是 Docker 鏡像？

Docker 鏡像也是一個壓縮包，只是這個壓縮包不只是可執行文件，環境部署腳本，它還包含了完整的操作系統。因爲大部分的鏡像都是基於某個操作系統來構建，所以很輕鬆的就可以構建本地和遠端一樣的環境。

這就很牛皮了，如果我們的應用是在 Centos7 上部署，我們只需要將項目環境部署在基於 Centos7 的環境中，然後無論在哪裏去解壓這個壓縮包，都可以保證環境的一致性。在整個過程中，我們根本不需要進行任何的配置，因爲這個壓縮包可以保證：本地的環境和雲端是一致的，這也是 Docker 鏡像的精髓

開發者體驗到了 Docker 的便利，從而很快宣佈 Paas 時代的結束，不過對於大規模應用的部署，Docker 能否實現在當時還是個問號

就在 2014 年的 DockerCon 上，緊接着發佈了自研的「Docker swarm」，Docker 就這樣 一度奔向高潮，即將就到達了自己夢想之巔。

爲什麼會推出 Docker Swarm?

雖然 Docker 通過「容器」完成了對 Paas 的「降維打擊」，但是 Docker 的目的是：如何讓更多的開發者將項目部署在自己的項目上，從技術，商業，市場多方位的爭取開發者的羣體，爲此形成自家的  Paas 平臺做鋪墊

Docker 項目雖然很受歡迎，就目前看來只是一個創建和啓動容器的小工具。需要應該清楚的一點是，用戶最終部署的還是他們的網站，服務甚至雲計算業務。所以推出一個完整的整體對外提供集羣管理功能的 Swarm 勢在必行，這個項目中的最大亮點即直接使用了 Docker 原生的 API 來完成對集羣的管理。

對於單機項目，只需要執行下面一條語句即可實現容器

對於多機的項目，只需要執行

你看，從單機切換到多機，使用的方法也就參數不同而已，所以這樣一個原生的「Docker 容器集羣管理」一發布就受到大家的青睞。隨着自身生態的逐漸完善，藉助這一波浪潮並通過各種併購來強大自己的平層能力

要說最成功的案例，非 Fig 項目莫屬。之所以這麼屌，是因爲作者提出了「容器編排」的概念。

什麼是容器編排？

其實這也不是什麼新鮮內容，比如在 Linux 中的 Makefile 和常見的 SHELL 腳本，它是一種通過工具或者配置來完成一組虛擬機或者關聯資源的定義、配置、創建等工具。

容器的編排是怎麼樣的呢

我們先以 Fig 爲例，假設開發人員小黑，現在要部署一個項目，其中包含了應用容器 A，數據庫容器 B，負載容器 C，這個時候 Fig 只需要將三個容器定義在一個配置文件，然後指定他們的關聯關係，執行下面的命令即可

當然也可以在 Fig 的配置文件中配置各種容器的副本，然後加上 Swarm 的集羣管理功能，這樣不就是 Paas 了麼。只是這個項目被收購以後，修改名字爲 compose 了，後續也會的 compose 進行詳細的闡述

就這樣一個以「鯨魚」爲商標的 Docker，火遍全球，因爲它秉持將「開發者」羣體放在食物鏈的頂端。一分鐘實現網站的部署，三分鐘搭建集羣，這麼多年以來，很多後端開發者很少將眼光放在 Linux 技術上，開發者們爲了深入的瞭解 Docker 的技術原理，終於將眼光放入諸如 Cgroups 和 Namespace 技術中。

就在這一時之間，後端及雲計算領域的大佬都匯聚於這個「小鯨魚」的身邊。隨後到了考慮集羣的方案，論集羣的管理調度能力，還不得不提 Berkeley 的 Mesos，專注於大數據領域，更加關注的是計算密集型的業務。憑藉着它天生的兩層調度機制，讓它很快發佈了一個叫做 Marathon 的項目，這個項目隨即成爲了 Swarm 的有力競爭對手。

這還沒完，說了這麼久，還沒有提到在基礎設施領域翹楚的 Google 公司，是的，同在這一年，宣告了一個叫做 Kubernetes  項目的誕生。

隨着  Docker 生態的建立，Docker swarm，Docker compose，Machine 形成了三件套，此時大量圍繞 Docker 項目的網絡，存儲，監控都湧現。在令人興奮的背後，是對它更多的擔憂，這主要來源於對 Docker 商業化戰略的顧慮，Docker 公司對於 Docker 着絕對的權威並在多個場合直接和谷歌，微軟對幹

其實在 Docker 興起的時候，谷歌也開源了一個 Linux 容器：Imctfy，在當時這個項目在 Docker 面前真是弟弟，所以向 Docker 公司表示想合作的意願，Docker 顯然不同意，且在之後的不久自己發佈了一個容器運行時的庫 Libcontainer，可能由於太急躁，其代碼可讀性極差，不穩定和頻繁的變更，讓社區叫苦不迭

爲了切割 Docker 項目的話語權，決定成立一箇中立的基金會。所以於 2015 年將這個 Libcontainer 捐出，並修改名稱爲 Runc，然後依據 RunC 項目，制定了一套容器和鏡像的標準和規範 ----OCI

什麼是 OCI

爲了讓 Docker 不能太囂張，其他玩家構建自身平臺的時候不依賴於 Docker 項目，提出一個標準和規範 ----OCI。這一標準並沒有改變 Docker 在容器領域一家獨大的現狀。Google 坐不住了，必須得搞點大招

**Google ** 給 RedHat 等夥伴打了電話，說咱們共同牽頭髮起一個基金會 -----CNCF。目的很簡單，以 kubernetes 爲基礎，建立一個以由開源基礎設置主導，按照獨立基金會方式運營的平臺級社區，來對抗 Docker 公司爲核心的容器商業生態

爲了做好這個事兒，CNCF 必須完成兩件事兒

CNCF 如何解決第一個問題 ---- 編排能力

Swarm 的無縫集成以及 Mesos 的大規模集羣的調度管理能力，很明顯，如果繼續往這兩個方向發展，後面的路不一定好走。所以，kubernetes 選擇的方式是 Borg，其基礎特性是 Google 在容器化基礎設施多年來實踐的經驗，這也正是項目從一開始就避免了和 Swarm ，mesos 社區同質化的重要手段

看似很有技巧，怎麼落地？

RedHat 正好擅長這玩意呀，它能真正的理解開源社區運作和項目研發真諦的合作伙伴。作爲 Docker 一方，主要不管的強調「Docker native」，但是由於 kubernetes 沒有跟 Swarm 展開同質化的競爭，所以這個「Docker Native」的說法並沒有什麼殺傷力。反而其獨特的設計理念和號召力，讓其構建了一個完全與衆不同的容器編排管理生態。

就這樣很快就把 Swarm 甩在了身後。隨機開始探討第二個問題，CNCF 添加了一系列容器工具和項目，面對這樣的壓迫，Docker 在 2016 年決定放棄現有的 Swarm 項目，而是將容器編排等全部內置到 Docker 項目中。

而 kubunetes 的應對方案也蠻有意思，開啓「民主化架構」，kubernetes 爲開發者暴露可以擴展的插件機制，讓用戶可以隨意的通過植入代碼的方式介入到 kubernetes 的每一個階段，很快，整個容器圈出現了優秀的作品：火熱的微服務治理項目 lstio 等

面對 kubernetes 的 強力攻擊，Docker 公司不得不面對失敗的事實，只好放棄開源社區專注於商業化轉型，所以於 2017 年將容器運行時部分 containerd 捐贈給了 CNCF，從而將 Docker 項目改名爲 Moby，然後交給社區維護，於 2017 年，**Docker ** 公司宣佈將在企業版內置 kubernetes 項目，這也標誌了 kubernetes「編排之爭」的結束

Docker 能做什麼

Docker 是一個用於開發，發佈，運行應用的程序於一體的開放平臺。如果我們需要將貨物整齊的擺放在船上且互不影響，那麼一種可行的方案即通過集裝箱進行標準化，我們將各種貨品通過集裝箱打包，然後統一的放在船上進行運輸，Docker 其實就是這樣一個將各種軟件進行打包成集裝箱，然後分發。

Docker 的安裝

Docker 是一個跨平臺的解決方案，支持各大平臺比如 Centos，Ubuntu 等 Linux 發行版。下面講述的是在 Centos 中的使用，安裝

運行上述命令，Docker 首先會檢查本地是否有 hello-world 這個鏡像，如果發現本地沒有這個鏡像，Docker 就會去 Docker Hub 官方倉庫下載此鏡像，然後運行它。最後我們看到該鏡像輸出 "Hello from Docker!" 並退出。

Docker 核心概念

Docker 的操作主要圍繞鏡像，容器，倉庫三大核心概念

什麼是鏡像？

一句話說即鏡像是 Docker 容器啓動的先決條件，因爲鏡像會提供容器運行的一些基礎文件和配置文件，是容器啓動的基礎。說白了，要啓動容器，需要鏡像來提供一些基礎環境。

使用的鏡像的方式有哪些？

什麼是容器？

容器是鏡像的運行實體。鏡像是靜態的只讀文件，可是容器是要運行的，需要可寫文件層。所以容器運行着真正的應用進程，所以自然會有創建，運行，停止，暫停和刪除五種狀態

既然容器是直接運行的運行程序，那它是有自己的命名空間嘛？

容器有自己獨立的命名空間和資源限制，意味着在容器內部，你無法看到主機上面的進程，環境變量等信息，這就是容器和物理機上的進程本質區別

什麼是倉庫？

鏡像倉庫類似於代碼倉庫，用來分發和存儲鏡像，分爲公共鏡像和私有鏡像。Docker hub 是 Docker 的官方公開鏡像倉庫，很多的官方鏡像都可以在上面找到，但是訪問很慢，所以可以找國內的鏡像源，當然後面我們也會自己搭建一個私有鏡像倉庫

三者的關係是怎麼樣的？

上圖清晰的展現了鏡像是容器的基石，容器是在鏡像的基礎上創建的。一個鏡像可以創建多個容器，倉庫用來存放和分發鏡像

Docker 架構

容器技術的發展可說突飛猛進了，市面上除了 Docker 容器還有 coreos 的 rkt，lxc 等，這麼多種容器，是不是需要一個標準呢，不然就太容易亂套了

你可能會說直接把 Docker 作爲標準不就好了，但是有這麼多相關的容器技術，誰不想喫個好瓜，除此之外，當時的編排的技術也競爭火爆，當時的三主力分別是 Docker Swarm，kubernetes 以及 mesos。作爲原生的 Docker Swarm 自然優勢明顯，但是 kubernetes 不同意啊，它們覺得調度形式太單一了

因此爆發了容器大戰，OCI 也就在此出現。

OCI 是開放的容器標準，輕量級開放的治理結構，目前主要有兩個標準，分別是容器運行時標準和容器鏡像標準

在如此競爭激烈下面，Docker 的架構成爲了下面這個樣子

Docker 的整體架構爲 CS 架構，客戶端和服務端兩部分組成，客戶端發送命令，服務端接受處理指令，其通信的方式有多種，即可以通過 Unix 套接字通信，也可以網絡鏈接遠程通信

Docker 客戶端

我們平時通常使用 Docker 命令行的方式和服務端打交道，其實還可以通過 **REST API ** 的方式和 Docker 服務端交互，甚至使用各種預言的 sdk 和 Docker 的服務端交互，美滋滋

Docker 服務端

Docker 服務端是 Docker 後臺服務的總稱。其中 Dockerd 是一個非常重要的後臺進程，它負責響應並處理 Docker 客戶端的請求，然後轉化爲 Docker 的具體操作

Docker 重要的組件

我們去 Docker 默認安裝路徑先看看有哪些組件

這裏主要說明下 runc 和 contained 組件

通過上圖，可以看到，dockerd 通過 gRPC 與 containerd 通信，由於 dockerd  與真正的容器運行時，runC 中間有了 containerd 這一  OCI  標準層，使得 dockerd 可以確保接口向下兼容。

gRPC 是一種遠程服務調用。containerd-shim 的意思是墊片，類似於擰螺絲時夾在螺絲和螺母之間的墊片。containerd-shim 的主要作用是將 containerd 和真正的容器進程解耦，使用 containerd-shim 作爲容器進程的父進程，從而實現重啓 dockerd 不影響已經啓動的容器進程。

docker 各個組件之間的關係

此時發現其 pid 爲 4428，隨後我們查看進程之間的關係

注意，docker19 就看不到兩者是父子關係了

可以先使用 ps aux | grep contained ，然後使用 pstree 查看 contained 的 pid , 實際上，Docker 啓動的時候，contained 就啓動了，dockerd 和 contained 一直就存在。當執行了 docker run 以後，contained 就會創建 contained-shim 充當墊片進程，然後啓動容器的真正進程 sleep 3600，這和架構圖一致

075528566666

Docker 相關組件

對於我們最直觀的即 Docker 命令，作爲 Docker 客戶端的完整實現，通過 Docker 命令來實現所有的 Docker 客戶與服務端的通信

Docker 客戶端於服務端的交互過程是怎麼樣的呢

Docker 組件向服務端發送請求後，服務端根據請求執行具體的動作並將結果返回給 Docker，Docker 解析服務端的返回結果，並將結果通過命令行標準輸出展示給用戶。這樣一次完整的客戶端服務端請求就完成了

dockerd 爲 Docker 服務端後臺的常駐進程，負責接收客戶端的請求，處理具體的任務並將結果返回客戶端

那麼 Docke r 客戶端採用哪幾種方式發送請求

第一種方式：通過 unix 套接字與服務端通信，配置的格式爲：unix://socket_path。默認的 dockerd 生成的 socket 文件存放在 /var/run/docker.sock，此文件只能是 root 用戶才能訪問，這也是爲什麼剛安裝完 Docker 後只能 root 來進行訪問操作

第二種方式：採用 TCP 的方式與服務端通信，配置格式爲：tcp://host:por，爲了保證安全，通常還需要使用 TLS 認證

第三種方式：通過 fd 文件描述符的方式，配置格式爲：fd:// 這種格式一般用於 systemd 管理的系統中。

在 Linux 中，有一個叫做 init 的進程，是所有進程的父進程，用來回收那些沒有回收的進程，同樣的道理，在容器內部，可以通過加上參數 --init 的方式，讓 1 號進程管理所有的子進程，例如回收殭屍進程

舉個例子示範，以鏡像 busybox 爲例

此時的 1 號進程爲爲 sh 進程，如果加上 --init

你會發現，此時的 1 號進程爲 docker-init，而不是 sh 了

docker-proxy 用來將容器啓動的端口映射到主機，方便主機的訪問。

假設目前啓動一個 nginx 容器並將容器的 80 端口映射到主機的 8080 端口

查看容器 IP

此時使用 ps 查看主機是否有 docker-proxy 進程

可以發現當進行端口映射的時候，docker 爲我們創建了一個 docker-proxy  進程，並且通過參數將容器的 IP 和端口傳遞給 docker-proxy，然後 proxy 通過 iptables 完成 nat 的轉發

從最後一句可以看出，當我們主機訪問 8080 端口的時候，iptable 將流量會轉發給 172.17.0.2 的 80 ，從而實現主機上直接訪問容器的業務

使用 curl 訪問一下 nginx 容器

contained 組件

contained 主要負責容器的生命週期管理，同時還會負責一些其他的功能

主要負責那些功能？

鏡像的管理

接收 dockerd 的請求

管理存儲相關資源

管理網絡資源

containerd-shim 的意思是墊片，類似於擰螺絲時夾在螺絲和螺母之間的墊片。containerd-shim 的主要作用是將 containerd 和真正的容器進程解耦，使用 containerd-shim 作爲容器進程的父進程，從而實現重啓 containerd 不影響已經啓動的容器進程。

ctr 實際上是 containerd-ctr，它是 containerd 的客戶端，主要用來開發和調試，在沒有 dockerd 的環境中，ctr 可以充當 docker 客戶端的部分角色，直接向 containerd 守護進程發送操作容器的請求。

Docker 鏡像使用

來，繼續，我們看看鏡像是什麼。鏡像是一個只讀的鏡像模版且包含了啓動容器所需要的文件結構內容。鏡像不包含動態數據，構建完成將不會改變

對於鏡像都有哪些操作?

對於鏡像的操作分爲：

拉取鏡像

拉取鏡像直接使用 docker pull 命令即可，命令的格式如下

現在舉個例子，這裏有個鏡像叫做 busybox，這個鏡像集成了上百個常用的 Linux 命令，可以通過這個鏡像方便快捷的查找生產環境中的問題，下面我們一起操作一波

首先會在本地鏡像庫查找，如果不存在本地庫則直接去官網拉取鏡像。拉取完鏡像後隨即查看鏡像

如果要查看指定的鏡像，則使用 docker image ls 命令進一步查詢

我們仔細觀察這兩個鏡像，就會發現這兩個鏡像的 IMAGE ID 其實是一樣的，這是什麼原因呢

實際上他們都是指向的同一個鏡像文件，只不過其別名不一樣而已，如果此時不想要 mybox 鏡像，想刪除這個鏡像

此時再次使用 docker images 查看確實刪除了

如何自己構建自己鏡像呢

之前說過，有兩種方式，一種是通過 docker commit 的方式，一種是 docker build 的方式。首先看看使用容器提交鏡像的方式

此時啓動了一個 busybox 容器並進入到容器，並在容器中創建一個文件，並寫入內容

此時就在當前目錄下創建了一個 hello.txt 文件並寫入了內容。現在新建另外一個窗口，然後提交爲一個鏡像

然後使用 docker image ls 查看發現確實生成了鏡像

然後我們再看看使用 dockerfile 的方式

先看看都有哪些命令

這麼多，不存在的，我們先看一個 dockerfile 就知道如何用了

基本操作已經會了，現在我們看看鏡像的實現原理

爲了清楚的看見鏡像的存儲結構，通過 docker build 構建鏡像

因爲我的 docker 使用的是 overlay2 文件驅動，所以進入到/var/lib/docker/overlay2 ，使用 tree 查看

可以清楚的看到，dockerfile 的每一行命令都會生成一個鏡像層

Docker 容器操作

我們通過一個鏡像可以輕鬆的創建一個容器，一個鏡像可以有多個容器，在運行容器的時候，實際上是在容器內部創建了這個文件系統的讀寫副本，如下圖所示

容器的生命週期是怎麼樣的?

容器的生命週期一共有五個狀態分別爲

通過 docker cretate 進入容器的初建狀態，然後通過 docker start 進入運行狀態，通過 docker stop 進入停止狀態，運行狀態的容器可以通過 docker pause 讓其變爲暫停狀態，爲了詳細的查看這些過程，我們實操一下

通過 docker create 創建的容器處於停止的狀態，使用 docker start busybox 進入啓動狀態

當使用 docker run 創建並啓動容器的時候，docker 後臺的執行邏輯爲

可以進入交互模式麼

同時使用-it 參數可以讓我們進入交互模式，容器內部和主機是完全隔離的。另外由於此時的 sh 爲 1 號進程，所以如果通過 exit 退出 sh，那麼容器也就退出，所以對於容器而言，殺死容器中的主進程，那麼容器也就會被殺死

通過 docker stop 停止容器，其原理是給運行中的容器給 sigterm 信號，如果容器爲 1 號進程接受並處理sigterm，則等待 1 號進程處理完畢後就退出，如果等待一段時間後還是沒有處理，則會通過發送 sigkill 命令強制終止容器

如何進入容器？

想要進入容器，有三種方案，分別是 docker attach，docker exec，nsenter 等

通過 docker ps -a 查看當前的進程信息

可是當我們在進行窗口進行 docker attach 的時候，這個命令就不好用了，所以使用 docker exec 的方式

奇怪的發現居然是兩個sh 進程，主要是因爲，當我們使用 docker exec方式進入容器的時候，會單獨啓動一個 sh 進程，此時的多個窗口都是獨立且不受干擾，也是非常常用的方式

現在基本上知道了如何創建，啓動容器，那麼怎麼刪除容器呢

使用 docker rm 的方式刪除容器

如果此時，容器正在運行，那麼需要添加-f的方式停止正在運行的容器

如果想要導出容器怎麼操作呢

這簡單，不過在導出之前先進入容器創建一個文件

然後導出爲文件

此時會在當前目錄生成一個 busybox.tar 文件，此時就可以將其拷貝到其他的機器上使用

那如何導入容器呢

通過 docker import的方式導入，然後使用docker run啓動就完成了容器的遷移

此時容器名稱爲 busybox：test，然後我們使用 docker run 啓動並進入容器

此時發現之前在/tmp創建的目錄也被遷移了過來

倉庫

容器的基本操作應該都會了，那麼我們應該如何去存儲和分發這些鏡像，這就需要介紹下倉庫；

我們可以使用共有鏡像倉庫分發，也可以搭建私有的倉庫

倉庫是啥玩意

錢錢倉庫放錢，這個倉庫放鏡像。Github 放代碼，我們理解鏡像的倉庫可以聯想 Github 倉庫。

在學習的過程中，不太能區分註冊服務器和倉庫的關係。註冊服務器其實是用來存放倉庫的實際機器，而倉庫我們可以將其理解爲具體的項目或者目錄。一個註冊服務器可以存放多個倉庫，每個倉庫可以存放多個鏡像

公有倉庫

Docker hub 是當前全球最大的鏡像市場，差不多超過 10w 個容器鏡像，大部分操作系統鏡像都來自於此。

如何使用公共鏡像倉庫和存儲鏡像

此時假設我的賬戶是 xiaolantest，創建一個 busybox 的倉庫，隨後將鏡像推送到倉庫中。

第一步：拉取 busybox 鏡像

第二步：推送鏡像之前先登錄鏡像服務器 (注意用戶名密碼哦)，出現 login Succeeded 表示登錄成功

第三步：推送之前還要做一件事，重新對鏡像命名，這樣測能正確的推動到自己創建的倉庫中

第四步：docker push 到倉庫中

私有倉庫

Docker 官方提供了開源的鏡像倉庫 Distribution，鏡像存放於 Docker hub 的 Registry 中

此時 Docker 爲busybox鏡像創建了一個別名localhost:5000/busybox，localhost:5000爲主機名和端口，Docker 將會把鏡像推送到這個地址。

此時，我們驗證一下從本地鏡像倉庫拉取鏡像。首先，我們刪除本地的busybox和localhost:5000/busybox鏡像。

可以看到此時本地已經沒有busybox這個鏡像了。下面，我們從本地鏡像倉庫拉取busybox鏡像：

隨後再使用 docker image ls busybox 命令，這時可以看到我們已經成功從私有鏡像倉庫拉取 busybox 鏡像到本地了

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/SW-f2l7KVEYLC0IRqIkrAA

猜你喜歡