一.前言

最近一直在研究和實踐ASP.NET Core、Docker、持續整合。在ASP.NET Core 和 Dcoker結合下遇到了一些坑，在此記錄和分享，希望對大家有一些幫助。

二.中間映象

多階段構建產生的中間映象，映象快取層等

我前面寫過一個 《ASP.NET Core & Docker 零基礎持續整合 》的教程。裡面我們通過持續整合工具Jenkins構建Docker映象並執行容器，採用的是Docker Compose來進行編排構建執行的（Visual Studio 2017新增Docker支援是採用的Docker Compose）。細心的朋友可能會發現，每次構建完畢以後通過docker images

刪除所有無名稱映象：

docker rmi $(docker images -f "dangling=true" -q)

此命令應當加在構建的最後一步，示例：

echo ---------------Remove-Orphans------------------
docker-compose -f src/docker-compose.yml -f src/docker-compose.override.yml  -p alipaydemo down --rmi local --remove-orphans
echo ---------------Publishing...------------------
docker-compose -f "src/docker-compose.yml" -f "src/docker-compose.override.yml"  -p alipaydemo up -d --build

echo ---------------Clear-Images...------------------
docker rmi $(docker images -f "dangling=true" -q)
 

執行之後會看到以下效果：

這是非常有必要的，因為如果每次構建都殘留一些中間映象，會額外消耗我們的磁碟空間的。

三.固定容器外部埠

這裡主要講的是在自動化構建的過程中，通過docker compose來執行容器的外部埠，而不是直接通過docker run命令來指定。

我們通過Visual Studio 2017新增Docker支援（Docker Compose），通過Docker Compose編排構建執行容器，我們會發現每次構建以後，執行的容器的外部埠都不是固定的，比如32774、32775、32776等等。這對於我們設定了Nginx反向代理和API Gateway等配置的肯定是十分不方便的，我們每次構建完畢以後還要去改這些配置，不是扯淡嗎。所以我們需要固定我們容器執行的外部埠，我們可以通過改變docker compose的yml檔案來固定容器的外部埠。

Visual Studio 2017 新增的Docker支援所生成的檔案有如下結構：

我是用的版本為VS2017 15.6.5。如果是更早的版本新增Docker支援可能會多出一個docker-compose.ci.build.yml檔案，其實這一步沒必要，目前的最新的VS2017已經移除了該檔案。

我們固定容器外部埠需要修改的是docker-compose.override.yml檔案，我們需要修改的是ports。預設為：

ports:
  - "80"

這個80埠只是容器的內部埠，我們進行如下修改來知道容器執行時對映到伺服器的埠也就是外部埠：

ports:
  - "32775:80"

通過上面的設定，我們將容器的外部埠指定為32775，這樣我們在構建完成以後，容器執行以後的外部埠都將會為32775，無需再次修改Nginx反向代理等配置。

四.設定映象版本

我們的應用程式具有不同的版本號，我們不同版本的應用程式構建出來的映象應該也是具有不同的版本的，我們可以通過設定映象的Tag來表示不同的版本：

我們同樣可以在docker compose的yml裡面進行設定，這次修改的是docker-compose.yml檔案，我們直接在映象的名稱後面設定Tag，語法為：

image: <映象名稱>:<Tag>

比如我設定一個名為alipaydemo的映象Tag為V1：

image: alipaydemo:v1

完整的配置分享：

version: '3'

services:
  alipay.demo.pcpayment:
    image: alipaydemopcpayment:v1
    container_name: alipaydemocontainer
    build:
      context: .
      dockerfile: Alipay.Demo.PCPayment/Dockerfile

五.設定容器名稱

我們在通過docker compose執行的容器將會被指定一個預設的容器名稱，如果是第四節的配置，那麼容器的預設名稱為alipaydemopcpayment.alipay.demo.pcpayment.build_1，具有非常一長串，此時我們可以自己來指定這個容器的名稱，同樣我們需要修改docker-compose.yml檔案，設定容器名稱的命令格式為：

container_name: <容器名稱>

完整的配置分享：

version: '3'

services:
  alipay.demo.pcpayment:
    image: alipaydemopcpayment:v1
    container_name: alipaydemocontainer
    build:
      context: .
      dockerfile: Alipay.Demo.PCPayment/Dockerfile

通過上面的配置我們將容器名稱設定為了alipaydemocontainer

六.設定容器重啟策略

某一天我對伺服器進行了重啟，重啟以後發現通過Docker執行的服務無法訪問了，然後檢視原因，發現Docker服務沒有開機自啟，啟動了Docker以後發現容器又沒有自動啟動。

1.設定Docker開機自啟

我們可以直接通過chkconfig命令來設定Docker開啟自啟：

chkconfig docker

執行成功如下：

2.設定容器隨Docker啟動

我們要讓容器隨Docker啟動，就必須設定容器的重啟策略為always，我們通過docker compose來執行容器時可以在yml裡面指定。開啟docker-compose.override.yml檔案，新增配置：

restart: always

完整的配置示例：

version: '3'

services:
  alipay.demo.pcpayment:
    restart: always
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
    ports:
      - "32775:80"

七.Docker的重啟策略

1.設定容器重啟策略

這裡講的設定容器重啟策略主要是通過命令來進行互動，並非第六節講的通過docker compose來設定重啟策略，是對第六節的一個擴充套件閱讀。

我們可以在使用docker run命令時通過--restart引數來設定重啟策略：

docker run -d --restart=always alipaydemo
docker run -d --restart=on-failure:10 alipaydemo

第一條命令代表容器退出時總是重啟容器，第二條代表在容器非正常退出時重啟容器，最多重啟10次。

對於已經執行的容器可以通過docker update命令來指定：

docker update --restart=always alipaydemo 

2.Docker容器的重啟策略

Docker容器的重啟策略是面向生產環境的一個啟動策略，在開發過程中可以忽略該策略。
Docker容器的重啟都是由Docker守護程序完成的，因此與守護程序息息相關。
Docker容器的重啟策略如下：

• no，預設策略，在容器退出時不重啟容器
• on-failure，在容器非正常退出時（退出狀態非0），才會重啟容器
  • on-failure:3，在容器非正常退出時重啟容器，最多重啟3次
• always，在容器退出時總是重啟容器
• unless-stopped，在容器退出時總是重啟容器，但是不考慮在Docker守護程序啟動時就已經停止了的容器

3.Docker容器的退出狀態碼

docker run的退出狀態碼如下：

• 0，表示正常退出

• 非0，表示異常退出（退出狀態碼採用chroot標準）
  • 125，Docker守護程序本身的錯誤
  • 126，容器啟動後，要執行的預設命令無法呼叫
  • 127，容器啟動後，要執行的預設命令不存在

• 其他命令狀態碼，容器啟動後正常執行命令，退出命令時該命令的返回狀態碼作為容器的退出狀態碼

八.設定自動互動

我們在編寫Dockerfile時，可以通過RUN命令來執行一些命令，由此我們可以通過執行apt-get等命令，將一些必要的元件安裝到我們的映象之中，比如lsof等。我們有如下配置：

RUN apt-get install lsof

但是我們在安裝一個元件時，非常有可能遇到互動操作，比如“Dou you want to xxx?[y/n]”等，遇到這種將會中斷我們的Docker映象構建過程，那麼如何解決呢？我們可以給命令指定--assume-yes來實現自動互動：

RUN apt-get install lsof --assume-yes

持續整合自動化構建過程中，如若不設定自動互動將會被中斷：

使用apt-get install命令以前，最好使用apt-get update更新一下，避免出現問題。

九.ASP.NET Core 生成圖片問題

大家應該知道目前.NET Core(2.0)還是沒有System.Drawing程式集，如果我們要使用Image等物件來完成生成圖片驗證碼、圖片二維碼等操作只有通過第三方編寫的元件，ZKWeb.System.Drawing便是其中一個，我們使用它以後，我們在windows上執行良好，無需其他額外的操作。但是我們一到Linux執行或者使用Docker（dotnet映象使用的是ubantu環境）執行時，會發現程式無法正常生成圖片，會出現異常，這是因為我們的zk在Linux/Docker下執行需要安裝一個名為 libgdiplus 的元件，我們在構建Docker映象的時候可以通過RUN命令使用apt-get命令進行安裝：

RUN apt-get update
RUN apt-get install libgdiplus --assume-yes
RUN cd /usr/lib
RUN ln -s libgdiplus.so gdiplus.dll

apt-get update是非常有必要的

完整的Dockerfile配置提供給大家參考：

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY Alipay.Demo.PCPayment.sln ./
COPY Alipay.Demo.PCPayment/Alipay.Demo.PCPayment.csproj Alipay.Demo.PCPayment/
RUN dotnet restore -nowarn:msb3202,nu1503
COPY . .
WORKDIR /src/Alipay.Demo.PCPayment
RUN dotnet build -c Release -o /app

FROM build AS publish
RUN dotnet publish -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
RUN apt-get update
RUN apt-get install libgdiplus --assume-yes
RUN cd /usr/lib
RUN ln -s libgdiplus.so gdiplus.dll
ENTRYPOINT ["dotnet", "Alipay.Demo.PCPayment.dll"]

十.寫在最後

本文乃是我在實踐ASP.NET Core & Docker & 持續整合過程中遇到的問題和解決之道，完完全全的實戰經驗、總結，希望能幫助到大家。關於實踐ASP.NET Core & Docker 構建持續整合大家可以看我的這一系列文章：《ASP.NET Core & Docker 零基礎持續整合》。本文所說的實戰是我在實踐我的開源專案：

此專案及其演示專案通過持續整合自動化釋出到Nuget和通過Docker執行。這個專案是一個支援.NET Core的支付寶的服務端SDK專案，不僅僅提供支付能力，還提供支付寶生活號、服務窗、行業合作等開發。覺得好的希望能給一個Star支援（手動滑稽）。