看完這篇,再也不用焦慮如何寫dockerfile了






Dockerfile是Docker用來構建鏡像的文本文件,包括自定義的指令和格式。可以通過docker build命令從Dockerfile中構建鏡像。用戶可以通過統一的語法命令來根據需求進行配置,通過這份統一的配置文件,在不同的文件上進行分發,需要使用時就可以根據配置文件進行自動化構建,這解決了開發人員構建鏡像的複雜過程。

看完這篇,再也不用焦慮如何寫dockerfile了

Dockerfile的使用

Dockerfile描述了組裝對象的步驟,其中每條指令都是單獨運行的。除了FROM指令,其他每條命令都會在上一條指令所生成鏡像的基礎上執行,執行完後會生成一個新的鏡像層,新的鏡像層覆蓋在原來的鏡像之上從而形成了新的鏡像。Dockerfile所生成的最終鏡像就是在基礎鏡像上面疊加一層層的鏡像層組建的。

Dockerfile指令

Dockerfile的基本格式如下:

<code># Comment
INSTRUCTION arguments/<code>

在Dockerfile中,指令(INSTRUCTION)不區分大小寫,但是為了與參數區分,推薦大寫。Docker會順序執行Dockerfile中的指令,第一條指令必須是FROM指令,它用於指定構建鏡像的基礎鏡像。在Dockerfile中以#開頭的行是註釋,而在其他位置出現的#會被當成參數。

Dockerfile中的指令有FROM、MAINTAINER、RUN、CMD、EXPOSE、ENV、ADD、COPY、ENTRYPOING、VOLUME、USER、WORKDIR、ONBUILD,錯誤的指令會被忽略。下面將詳細講解一些重要的Docker指令。

FROM

格式: FROM <image> 或者 FROM <image>:/<image>/<image>

FROM指令的功能是為後面的指令提供基礎鏡像,因此Dockerfile必須以FROM指令作為第一條非註釋指令。從公共鏡像庫中拉取鏡像很容易,基礎鏡像可以選擇任何有效的鏡像。在一個Dockerfile中FROM指令可以出現多次,這樣會構建多個鏡像。tag的默認值是latest,如果參數image或者tag指定的鏡像不存在,則返回錯誤。

ENV

格式: ENV <value> 或者 ENV =<value> .../<value>/<value>

ENV指令可以為鏡像創建出來的容器聲明環境變量。並且在Dockerfile中,ENV指令聲明的環境變量會被後面的特定指令(即ENV、ADD、COPY、WORKDIR、EXPOSE、VOLUME、USER)解釋使用。

其他指令使用環境變量時,使用格式為$variable_name或者${variable_name}。如果在變量面前添加斜槓\\可以轉義。如\\$foo或者\\${foo}將會被轉換為$foo和${foo},而不是環境變量所保存的值。另外,ONBUILD指令不支持環境替換。

COPY

格式: COPY <dest>

COPY指令複製所指向的文件或目錄,將它添加到新鏡像中,複製的文件或目錄在鏡像中的路徑是<dest>。所指定的源可以有多個,但必須是上下文根目錄中的相對路徑。不能只用形如 COPY ../something /something這樣的指令。此外,可以使用通配符指向所有匹配通配符的文件或目錄,例如,COPY home* /mydir/ 表示添加所有以"hom"開頭的文件到目錄/mydir/中。/<dest>

<dest>可以是文件或目錄,但必須是目標鏡像中的絕對路徑或者相對於WORKDIR的相對路徑(WORKDIR即Dockerfile中WORKDIR指令指定的路徑,用來為其他指令設置工作目錄)。若<dest>以反斜槓/結尾則其指向的是目錄;否則指向文件。同理。若<dest>是一個文件,則的內容會被寫到<dest>中;否則指向的文件或目錄中的內容會被複制添加到<dest>目錄中。當指定多個源時,<dest>必須是目錄。如果<dest>不存在,則路徑中不存在的目錄會被創建。/<dest>/<dest>/<dest>/<dest>/<dest>/<dest>/<dest>

ADD

格式:ADD <dest>

ADD與COPY指令在功能上很相似,都支持複製本地文件到鏡像的功能,但ADD指令還支持其他功能。可以是指向網絡文件的URL,此時若<dest>指向一個目錄,則URL必須是完全路徑,這樣可以獲得網絡文件的文件名filename,該文件會被複制添加到<dest>/<filename>。比如 ADD http://example.com/config.property / 會創建文件/config.property。/<filename>/<dest>/<dest>

還可以指向一個本地壓縮歸檔文件,該文件會在複製到容器時會被解壓提取,如ADD sxample.tar.xz /。但是若URL中的文件為歸檔文件則不會被解壓提取。

ADD 和 COPY指令雖然功能相似,但一般推薦使用COPY,因為COPY只支持本地文件,相比ADD而言,它更加透明。

EXPOSE

格式: EXPOSE <port> [<port>/<protocol>...]/<protocol>/<port>/<port>

EXPOSE指令通知Docker該容器在運行時偵聽指定的網絡端口。可以指定端口是偵聽TCP還是UDP,如果未指定協議,則默認值為TCP。這個指令僅僅是聲明容器打算使用什麼端口而已,並不會自動在宿主機進行端口映射,可以在運行的時候通過docker -p指定。

<code>EXPOSE 80/tcp
EXPOSE 80/udp/<code>

USER

格式: USER <user>[:<group>[:]/<group>/<user>

USER指令設置了user name和user group(可選)。在它之後的RUN,CMD以及ENTRYPOINT指令都會以設置的user來執行。

WORKDIR

格式: WORKDIR /path/to/workdir

WORKDIR指令設置工作目錄,它之後的RUN、CMD、ENTRYPOINT、COPY以及ADD指令都會在這個工作目錄下運行。如果這個工作目錄不存在,則會自動創建一個。WORKDIR指令可在Dockerfile中多次使用。如果提供了相對路徑,則它將相對於上一個WORKDIR指令的路徑。例如

<code>WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd/<code>

輸出結果是 /a/b/c

RUN

格式1: RUN <command> (shell格式)格式2: RUN ["executable", "param1", "param2"] (exec格式,推薦使用)/<command>

RUN指令會在前一條命令創建出的鏡像的基礎上創建一個容器,並在容器中運行命令,在命令結束運行後提交容器為新鏡像,新鏡像被Dockerfile中的下一條指令使用。

RUN指令的兩種格式表示命令在容器中的兩種運行方式。當使用shell格式時,命令通過/bin/sh -c運行。當使用exec格式時,命令是直接運行的,容器不調用shell程序,即容器中沒有shell程序。exec格式中的參數會被當成JSON數組被Docker解析,故必須使用雙引號而不能使用單引號。因為exec格式不會在shell中執行,所以環境變量的參數不會被替換。

比如執行RUN ["echo", "$HOME"]指令時,$HOME不會做變量替換。如果希望運行shell程序,指令可以寫成 RUN ["/bin/bash", "-c", "echo", "$HOME"]。

CMD

CMD指令有3種格式。

格式1:CMD <command> (shell格式)格式2:CMD ["executable", "param1", "param2"] (exec格式,推薦使用)格式3:CMD ["param1", "param2"] (為ENTRYPOINT指令提供參數)/<command>

CMD指令提供容器運行時的默認值,這些默認值可以是一條指令,也可以是一些參數。一個Dockerfile中可以有多條CMD指令,但只有最後一條CMD指令有效。 CMD ["param1", "param2"]格式是在CMD指令和ENTRYPOINT指令配合時使用的,CMD指令中的參數會添加到ENTRYPOING指令中.使用shell和exec格式時,命令在容器中的運行方式與RUN指令相同。

不同之處在於,RUN指令在構建鏡像時執行命令,並生成新的鏡像;CMD指令在構建鏡像時並不執行任何命令,而是在容器啟動時默認將CMD指令作為第一條執行的命令。如果用戶在命令行界面運行docker run命令時指定了命令參數,則會覆蓋CMD指令中的命令。

ENTRYPOINT

ENTRYPOINT指令有兩種格式。

格式1:ENTRYPOINT <command> (shell格式)格式2:ENTRYPOINT ["executable", "param1", "param2"] (exec格式,推薦格式)/<command>

ENTRYPOINT指令和CMD指令類似,都可以讓容器在每次啟動時執行相同的命令,但它們之間又有不同。一個Dockerfile中可以有多條ENTRYPOINT指令,但只有最後一條ENTRYPOINT指令有效。

當使用Shell格式時,ENTRYPOINT指令會忽略任何CMD指令和docker run命令的參數,並且會運行在bin/sh -c中。這意味著ENTRYPOINT指令進程為bin/sh -c的子進程,進程在容器中的PID將不是1,且不能接受Unix信號。即當使用docker stop <container>命令時,命令進程接收不到SIGTERM信號。/<container>

推薦使用exec格式,使用此格式時,docker run傳入的命令參數會覆蓋CMD指令的內容並且附加到ENTRYPOINT指令的參數中。從ENTRYPOINT的使用中可以看出,CMD可以是參數,也可以是指令,而ENTRYPOINT只能是命令;另外,docker run命令提供的運行命令參數可以覆蓋CMD,但不能覆蓋ENTRYPOINT。

Dockerfile實踐心得

使用標籤

給鏡像打上標籤,有利於幫助瞭解進鏡像功能

謹慎選擇基礎鏡像

選擇基礎鏡像時,儘量選擇當前官方鏡像庫的肩寬,不同鏡像的大小不同,目前Linux鏡像大小由如下關係:

busybox < debian < centos < ubuntu

同時在構建自己的Docker鏡像時,只安裝和更新必須使用的包。此外相比Ubuntu鏡像,更推薦使用Debian鏡像,因為它非常輕量級(目前其大小是在100MB以下),並且仍然是一個完整的發佈版本。

充分利用緩存

Docker daemon會順序執行Dockerfile中的指令,而且一旦緩存失效,後續命令將不能使用緩存。為了有效地利用緩存,需要保證指令的連續性,儘量將所有Dockerfile文件相同的部分都放在前面,而將不同的部分放到後面。

正確使用ADD與COPY命令

當在Dockerfile中的不同部分需要用到不同的文件時,不要一次性地將這些文件都添加到鏡像中去,而是在需要時添加,這樣也有利於重複利用docker緩存。另外考慮到鏡像大小問題,使用ADD指令去獲取遠程URL中的壓縮包不是推薦的做法。應該使用RUN wget或RUN curl代替。這樣可以刪除解壓後不在需要的文件,並且不需要在鏡像中在添加一層。

錯誤做法:

<code>ADD http://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all/<code>

正確的做法:

<code>RUN mkdir -p /usr/src/things \\
    && curl -SL http://example.com/big.tar.xz \\
    | tar -xJC /usr/src/things \\
    && make -C /usr/src/things all/<code>

RUN指令

在使用較長的RUN指令時可以使用反斜槓\\分隔多行。大部分使用RUN指令的常見是運行apt-wget命令,在該場景下請注意以下幾點。

  1. 不要在一行中單獨使用指令RUN apt-get update。當軟件源更新後,這樣做會引起緩存問題,導致RUN apt-get install指令運行失敗。所以,RUN apt-get update和RUN apt-get install應該寫在同一行。比如 RUN apt-get update && apt-get install -y package-1 package-2 package-3
  2. 避免使用指令RUN apt-get upgrade 和 RUN apt-get dist-upgrade。因為在一個無特權的容器中,一些必要的包會更新失敗。如果需要更新一個包(如package-1),直接使用命令RUN apt-get install -y package-1。

CMD和ENTRYPOINT命令

CMD和ENTRYPOINT命令指定是了容器運行的默認命令,推薦二者結合使用。使用exec格式的ENTRYPOINT指令設置固定的默認命令和參數,然後使用CMD指令設置可變的參數。

比如下面這個例子:

<code>FROM busybox
WORKDIR /app
COPY run.sh /app
RUN chmod +x run.sh
ENTRYPOINT ["/app/run.sh"]
CMD ["param1"]/<code>

run.sh內容如下:

<code>#!/bin/sh
echo "$@"/<code>

運行後輸出結果為param1, Dockerfile中CMD和ENTRYPOINT的順序不重要(CMD寫在ENTRYPOINT前後都可以)。

當在windows系統下build dockerfile你可能會遇到這個問題

<code>standard_init_linux.go:207: exec user process caused "no such file or directory"/<code>

這是因為sh文件的fileformat是dos,這裡需要修改為unix,不需要下載額外的工具,一般我們機器上安裝了git會自帶git bash,進入git bash,使用vi 編輯,在命令行模式下修改(:set ff=unix)。

不要再Dockerfile中做端口映射

使用Dockerfile的EXPOSE指令,雖然可以將容器端口映射在主機端口上,但會破壞Docker的可移植性,且這樣的鏡像在一臺主機上只能啟動一個容器。所以端口映射應在docker run命令中用-p 參數指定。

<code># 不要再Dockerfile中做如下映射
EXPOSE 80:8080

# 僅暴露80端口,需要另做映射
EXPOSE 80/<code>

實踐Dockerfile的寫法

Java 服務的DockerFile

<code>FROM openjdk:8-jre-alpine
ENV spring_profiles_active=dev
ENV env_java_debug_enabled=false
EXPOSE 8080
WORKDIR /app
ADD target/smcp-web.jar /app/target/smcp-web.jar
ADD run.sh /app
ENTRYPOINT ./run.sh/<code>

可以看到基礎鏡像是openjdk,然後設置了兩個環境變量,服務訪問端口是9090(意味著springboot應用中指定了server.port=8080),設置了工作目錄是/app。通過ENTRYPOINT設定了啟動鏡像時要啟動的命令(./run.sh)。這個腳本中的內容如下:

<code>#!/bin/sh
# Set debug options if required
if [ x"${env_java_debug_enabled}" != x ] && [ "${env_java_debug_enabled}" != "false" ]; then
    java_debug_args="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005"
fi

# ex: env_jvm_flags="-Xmx1200m -XX:MaxRAM=1500m" for production
java $java_debug_args $env_jvm_flags -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -jar target/smcp-web.jar/<code>

如果我們要指定jvm的一些參數,可以通過在環境變量中設置env_jvm_flags來指定。

Maven Dockerfile

maven的Dockerfile也寫的很好,這裡我發上來也給大家參考下

<code>FROM openjdk:8-jdk

ARG MAVEN_VERSION=3.6.3
ARG USER_HOME_DIR="/root"
ARG SHA=c35a1803a6e70a126e80b2b3ae33eed961f83ed74d18fcd16909b2d44d7dada3203f1ffe726c17ef8dcca2dcaa9fca676987befeadc9b9f759967a8cb77181c0
ARG BASE_URL=https://apache.osuosl.org/maven/maven-3/${MAVEN_VERSION}/binaries

RUN mkdir -p /usr/share/maven /usr/share/maven/ref \\
  && curl -fsSL -o /tmp/apache-maven.tar.gz ${BASE_URL}/apache-maven-${MAVEN_VERSION}-bin.tar.gz \\
  && echo "${SHA}  /tmp/apache-maven.tar.gz" | sha512sum -c - \\
  && tar -xzf /tmp/apache-maven.tar.gz -C /usr/share/maven --strip-components=1 \\
  && rm -f /tmp/apache-maven.tar.gz \\
  && ln -s /usr/share/maven/bin/mvn /usr/bin/mvn

ENV MAVEN_HOME /usr/share/maven
ENV MAVEN_CONFIG "$USER_HOME_DIR/.m2"

COPY mvn-entrypoint.sh /usr/local/bin/mvn-entrypoint.sh
COPY settings-docker.xml /usr/share/maven/ref/

ENTRYPOINT ["/usr/local/bin/mvn-entrypoint.sh"]
CMD ["mvn"]/<code>

可以看到它是基於openjdk這個基礎鏡像來創建的,先去下載maven的包,然後進行了安裝。 然後又設置了MAVEN_HOME和MAVEN_CONFIG這兩個環境變量,最後通過mvn-entrypoing.sh來進行了啟動。

前端服務的兩階段構建

我有一個前端服務,目錄結構如下:

<code>$ ls frontend/
myaccount/  resources/  third_party//<code>

myaccount目錄下是放置的js,vue等,resources放置的是css,images等。third_party放的是第三方應用。

這裡採用了兩階段構建,即採用上一階段的構建結果作為下一階段的構建數據

<code>FROM node:alpine as builder
WORKDIR '/build'
COPY myaccount ./myaccount
COPY resources ./resources
COPY third_party ./third_party

WORKDIR '/build/myaccount'

RUN npm install
RUN npm rebuild node-sass
RUN npm run build

RUN ls /build/myaccount/dist

FROM nginx
EXPOSE 80
COPY --from=builder /build/myaccount/dist /usr/share/nginx/html/<code>

需要注意結尾的 --from=builder這裡和開頭是遙相呼應的。

作者:think123
原文鏈接:https://juejin.im/post/5e60745d518825492e4965ed


分享到:


相關文章: