製做本身的docker鏡像

製做本身的Docker鏡像主要有以下兩種方式：

1.使用docker commit 命令來建立鏡像

1. 經過docker run命令啓動容器
2. 修改docker鏡像內容
3. docker commit提交修改的鏡像
4. docker run新的鏡像

2.使用 Dockerfile 來建立鏡像

使用 docker commit 來擴展一個鏡像比較簡單，可是不方便在一個團隊中分享。咱們可使用 docker build 來建立一個新的鏡像。爲此，首先須要建立一個 Dockerfile，包含一些如何建立鏡像的指令。

Dockerfile 基本的語法

• 使用#來註釋
• FROM 指令告訴 Docker 使用哪一個鏡像做爲基礎
• 接着是維護者的信息
• RUN開頭的指令會在建立中運行，好比安裝一個軟件包，在這裏使用 apt-get 來安裝了一些軟件

構建鏡像的步驟

1.新建一個目錄和一個 Dockerfile

$ mkdir new_folder
$ cd new_folder
$ touch Dockerfile

　　

# 這裏是註釋2.編寫Dockerfile，Dockerfile中每一條指令都建立鏡像的一層，例如：

# 設置繼承自哪一個鏡像
FROM ubuntu:14.04
# 下面是一些建立者的基本信息
MAINTAINER birdben (191654006@163.com)
# 在終端須要執行的命令
RUN apt-get install -y openssh-server RUN mkdir -p /var/run/sshd

　　

3.編寫完成 Dockerfile 後可使用 docker build 來生成鏡像。

$ sudo docker build -t="birdben/ubuntu:v1" .
# 下面是一堆構建日誌信息
 
############
我是日誌
############
 
# 參數：
# -t 標記來添加 tag，指定新的鏡像的用戶和鏡像名稱信息。
# 「.」 是 Dockerfile 所在的路徑（當前目錄），也能夠替換爲一個具體的 Dockerfile 的路徑。
 
# 以交互方式運行docker
$ docker run -it birdben/ubuntu:v1 /bin/bash
 
# 運行docker時指定配置
$ sudo docker run -d -p 10.211.55.4:9999:22 ubuntu:tools '/usr/sbin/sshd' -D
 
# 參數：
# -i：表示以「交互模式」運行容器，-i 則讓容器的標準輸入保持打開
# -t：表示容器啓動後會進入其命令行，-t 選項讓Docker分配一個僞終端（pseudo-tty）並綁定到容器的標準輸入上
# -v：表示須要將本地哪一個目錄掛載到容器中，格式：-v <宿主機目錄>:<容器目錄>，-v 標記來建立一個數據卷並掛載到容器裏。在一次 run 中屢次使用能夠掛載多個數據卷。
# -p：指定對外80端口
# 不必定要使用「鏡像 ID」，也可使用「倉庫名:標籤名」

鏡像構建上下文（Context）
若是注意，會看到 docker build 命令最後有一個 .。. 表示當前目錄，而 Dockerfile 就在當前目錄，所以很多初學者覺得這個路徑是在指定 Dockerfile 所在路徑，這麼理解實際上是不許確的。若是對應上面的命令格式，你可能會發現，這是在指定上下文路徑。那麼什麼是上下文呢？

首先咱們要理解 docker build 的工做原理。Docker 在運行時分爲 Docker 引擎（也就是服務端守護進程）和客戶端工具。Docker 的引擎提供了一組 REST API，被稱爲 Docker Remote API，而如 docker 命令這樣的客戶端工具，則是經過這組 API 與 Docker 引擎交互，從而完成各類功能。所以，雖然表面上咱們好像是在本機執行各類 docker 功能，但實際上，一切都是使用的遠程調用形式在服務端（Docker 引擎）完成。也由於這種 C/S 設計，讓咱們操做遠程服務器的 Docker 引擎變得垂手可得。

當咱們進行鏡像構建的時候，並不是全部定製都會經過 RUN 指令完成，常常會須要將一些本地文件複製進鏡像，好比經過 COPY 指令、ADD 指令等。而 docker build 命令構建鏡像，其實並不是在本地構建，而是在服務端，也就是 Docker 引擎中構建的。那麼在這種客戶端/服務端的架構中，如何才能讓服務端得到本地文件呢？

這就引入了上下文的概念。當構建的時候，用戶會指定構建鏡像上下文的路徑，docker build 命令得知這個路徑後，會將路徑下的全部內容打包，而後上傳給 Docker 引擎。這樣 Docker 引擎收到這個上下文包後，展開就會得到構建鏡像所需的一切文件。

若是在 Dockerfile 中這麼寫：

COPY ./package.json /app/
這並非要複製執行 docker build 命令所在的目錄下的 package.json，也不是複製 Dockerfile 所在目錄下的 package.json，而是複製 上下文（context） 目錄下的 package.json。

所以，COPY 這類指令中的源文件的路徑都是相對路徑。這也是初學者常常會問的爲何 COPY ../package.json /app 或者 COPY /opt/xxxx /app 沒法工做的緣由，由於這些路徑已經超出了上下文的範圍，Docker 引擎沒法得到這些位置的文件。若是真的須要那些文件，應該將它們複製到上下文目錄中去。

如今就能夠理解剛纔的命令 docker build -t nginx:v3 . 中的這個 .，其實是在指定上下文的目錄，docker build 命令會將該目錄下的內容打包交給 Docker 引擎以幫助構建鏡像。

若是觀察 docker build 輸出，咱們其實已經看到了這個發送上下文的過程：

$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
...
理解構建上下文對於鏡像構建是很重要的，避免犯一些不該該的錯誤。好比有些初學者在發現 COPY /opt/xxxx /app 不工做後，因而乾脆將 Dockerfile 放到了硬盤根目錄去構建，結果發現 docker build 執行後，在發送一個幾十 GB 的東西，極爲緩慢並且很容易構建失敗。那是由於這種作法是在讓 docker build 打包整個硬盤，這顯然是使用錯誤。

通常來講，應該會將 Dockerfile 置於一個空目錄下，或者項目根目錄下。若是該目錄下沒有所需文件，那麼應該把所需文件複製一份過來。若是目錄下有些東西確實不但願構建時傳給 Docker 引擎，那麼能夠用 .gitignore 同樣的語法寫一個 .dockerignore，該文件是用於剔除不須要做爲上下文傳遞給 Docker 引擎的。

那麼爲何會有人誤覺得 . 是指定 Dockerfile 所在目錄呢？這是由於在默認狀況下，若是不額外指定 Dockerfile 的話，會將上下文目錄下的名爲 Dockerfile 的文件做爲 Dockerfile。

這只是默認行爲，實際上 Dockerfile 的文件名並不要求必須爲 Dockerfile，並且並不要求必須位於上下文目錄中，好比能夠用 -f ../Dockerfile.php 參數指定某個文件做爲 Dockerfile。

固然，通常你們習慣性的會使用默認的文件名 Dockerfile，以及會將其置於鏡像構建上下文目錄中。

鏡像構建上下文

 

Docker的網絡功能相對簡單，沒有過多複雜的配置，Docker默認使用birdge橋接方式與容器通訊，啓動Docker後，宿主機上會產生docker0這樣一個虛擬網絡接口， docker0不是一個普通的網絡接口， 它是一個虛擬的以太網橋，能夠爲綁定到docker0上面的網絡接口自動轉發數據包，這樣可使容器與宿主機之間相互通訊。每次Docker建立一個容器，會產生一對虛擬接口，在宿主機上執行ifconfig，會發現多了一個相似veth**這樣的網絡接口，它會綁定到docker0上，因爲全部容器都綁定到docker0上，容器之間也就能夠通訊。Docker網絡

在宿主機上執行ifconfig，會看到docker0這個網絡接口， 啓動一個container，再次執行ifconfig, 會有一個相似veth**的interface，每一個container的缺省路由是宿主機上docker0的ip，在container中執行netstat -r能夠看到以下圖所示內容：
container路由

在容器中使用netstat -r命令查看容器的IP地址

容器中的默認網關跟docker0的地址是同樣的：

在宿主機中使用ifconfig查看docker0的IP地址

docker0
當容器退出以後，veth*虛擬接口也會被銷燬。

 

轉載自：https://birdben.github.io/2015/11/17/Docker/Docker%E5%AE%9E%E6%88%98%EF%BC%88%E4%BA%8C%EF%BC%89%E5%88%B6%E4%BD%9C%E8%87%AA%E5%B7%B1%E7%9A%84Docker%E9%95%9C%E5%83%8F/