每個(gè)項(xiàng)目——無論你是在從事 Web 應(yīng)用程序、數(shù)據(jù)科學(xué)還是 AI 開發(fā)——都可以從配置良好的 CI/CD、Docker 鏡像或一些額外的代碼質(zhì)量工具（如 CodeClimate 或 SonarCloud）中獲益。所有這些都是本文要討論的內(nèi)容，我們將看看如何將它們添加到 Python 項(xiàng)目中！

• 在寫這篇文章之前，我還寫了一篇“Python 項(xiàng)目終極設(shè)置”，讀者感興趣的話，可以先讀下那一篇：https://martinheinz.dev/blog/14。

• GitHub 庫(kù)中提供了完整的源代碼和文檔：https://github.com/MartinHeinz/python-project-blueprint。

開發(fā)環(huán)境中可調(diào)試的 Docker 容器

有些人不喜歡 Docker，因?yàn)槿萜骱茈y調(diào)試，或者構(gòu)建鏡像需要花很長(zhǎng)的時(shí)間。那么，就讓我們從這里開始，構(gòu)建適合開發(fā)的鏡像——構(gòu)建速度快且易于調(diào)試。

為了使鏡像易于調(diào)試，我們需要一個(gè)基礎(chǔ)鏡像，包括所有調(diào)試時(shí)可能用到的工具，像bash、vim、netcat、wget、cat、find、grep等。它默認(rèn)包含很多工具，沒有的也很容易安裝。這個(gè)鏡像很笨重，但這不要緊，因?yàn)樗挥糜陂_發(fā)。你可能也注意到了，我選擇了非常具體的映像——鎖定了 Python 和 Debian 的版本——我是故意這么做的，因?yàn)槲覀兿Ｍ钚』?Python 或 Debian 版本更新（可能不兼容）導(dǎo)致“破壞”的可能性。

作為替代方案，你也可以使用基于 Alpine 的鏡像。然而，這可能會(huì)導(dǎo)致一些問題，因?yàn)樗褂?code style="margin-right: 2px;margin-left: 2px;padding: 2px 4px;max-width: 100%;font-size: 14px;border-radius: 4px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;box-sizing: border-box !important;overflow-wrap: break-word !important;">musl libc而不是 Python 所依賴的glibc。所以，如果決定選擇這條路線，請(qǐng)記住這一點(diǎn)。至于構(gòu)建速度，我們將利用多階段構(gòu)建以便可以緩存盡可能多的層。通過這種方式，我們可以避免下載諸如gcc之類的依賴項(xiàng)和工具，以及應(yīng)用程序所需的所有庫(kù)（來自requirements.txt）。

為了進(jìn)一步提高速度，我們將從前面提到的python:3.8.1-buster創(chuàng)建自定義基礎(chǔ)鏡像，這將包括我們需要的所有工具，因?yàn)槲覀儫o法將下載和安裝這些工具所需的步驟緩存到最終的runner鏡像中。說的夠多了，讓我們看看Dockerfile：

#?dev.Dockerfile
FROM?python:3.8.1-buster?AS?builder
RUN?apt-get?update?&&?apt-get?install?-y?--no-install-recommends?--yes?python3-venv?gcc?libpython3-dev?&&?\
????python3?-m?venv?/venv?&&?\
????/venv/bin/pip?install?--upgrade?pip
FROM?builder?AS?builder-venv
COPY?requirements.txt?/requirements.txt
RUN?/venv/bin/pip?install?-r?/requirements.txt
FROM?builder-venv?AS?tester
COPY?.?/app
WORKDIR?/app
RUN?/venv/bin/pytest
FROM?martinheinz/python-3.8.1-buster-tools:latest?AS?runner
COPY?--from=tester?/venv?/venv
COPY?--from=tester?/app?/app
WORKDIR?/app
ENTRYPOINT?["/venv/bin/python3",?"-m",?"blueprint"]
USER?1001
LABEL?name={NAME}
LABEL?version={VERSION}

從上面可以看到，在創(chuàng)建最后的runner鏡像之前，我們要經(jīng)歷 3 個(gè)中間鏡像。首先是名為builder的鏡像，它下載構(gòu)建最終應(yīng)用所需的所有必要的庫(kù)，其中包括gcc和 Python 虛擬環(huán)境。安裝完成后，它還創(chuàng)建了實(shí)際的虛擬環(huán)境，供接下來的鏡像使用。接下來是build -venv鏡像，它將依賴項(xiàng)列表（requirements.txt）復(fù)制到鏡像中，然后安裝它。緩存會(huì)用到這個(gè)中間鏡像，因?yàn)槲覀冎幌Ｍ?code style="margin-right: 2px;margin-left: 2px;padding: 2px 4px;max-width: 100%;font-size: 14px;border-radius: 4px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;box-sizing: border-box !important;overflow-wrap: break-word !important;">requirement .txt更改時(shí)安裝庫(kù)，否則我們就使用緩存。

在創(chuàng)建最終鏡像之前，我們首先要針對(duì)應(yīng)用程序運(yùn)行測(cè)試。這發(fā)生在tester鏡像中。我們將源代碼復(fù)制到鏡像中并運(yùn)行測(cè)試。如果測(cè)試通過，我們就繼續(xù)構(gòu)建runner。

對(duì)于runner鏡像，我們使用自定義鏡像，其中包括一些額外的工具，如vim或netcat，這些功能在正常的 Debian 鏡像中是不存在的。

• 你可以在 Docker Hub 中找到這個(gè)鏡像：https://hub.docker.com/repository/docker/martinheinz/python-3.8.1-buster-tools

• 你也可以在base.Dockerfile?中查看其非常簡(jiǎn)單的`Dockerfile`：https://github.com/MartinHeinz/python-project-blueprint/blob/master/base.Dockerfile

那么，我們?cè)谶@個(gè)最終鏡像中要做的是——首先我們從tester鏡像中復(fù)制虛擬環(huán)境，其中包含所有已安裝的依賴項(xiàng)，接下來我們復(fù)制經(jīng)過測(cè)試的應(yīng)用程序?，F(xiàn)在，我們的鏡像中已經(jīng)有了所有的資源，我們進(jìn)入應(yīng)用程序所在的目錄，然后設(shè)置ENTRYPOINT，以便它在啟動(dòng)鏡像時(shí)運(yùn)行我們的應(yīng)用程序。出于安全原因，我們還將USER設(shè)置為1001，因?yàn)樽罴褜?shí)踐告訴我們，永遠(yuǎn)不要在root用戶下運(yùn)行容器。最后兩行設(shè)置鏡像標(biāo)簽。它們將在使用make目標(biāo)運(yùn)行構(gòu)建時(shí)被替換 / 填充，稍后我們將看到。

針對(duì)生產(chǎn)環(huán)境優(yōu)化過的 Docker 容器

當(dāng)涉及到生產(chǎn)級(jí)鏡像時(shí)，我們會(huì)希望確保它們小而安全且速度快。對(duì)于這個(gè)任務(wù)，我個(gè)人最喜歡的是來自 Distroless 項(xiàng)目的 Python 鏡像?？墒?，Distroless 是什么呢？

這么說吧——在一個(gè)理想的世界里，每個(gè)人都可以使用FROM scratch構(gòu)建他們的鏡像，然后作為基礎(chǔ)鏡像（也就是空鏡像）。然而，大多數(shù)人不愿意這樣做，因?yàn)槟切枰o態(tài)鏈接二進(jìn)制文件，等等。這就是 Distroless 的用途——它讓每個(gè)人都可以FROM scratch。

好了，現(xiàn)在讓我們具體描述一下 Distroless 是什么。它是由谷歌生成的一組鏡像，其中包含應(yīng)用程序所需的最低條件，這意味著沒有 shell、包管理器或任何其他工具，這些工具會(huì)使鏡像膨脹，干擾安全掃描器（如 CVE），增加建立遵從性的難度。

現(xiàn)在，我們知道我們?cè)诟墒裁戳?，讓我們看看生產(chǎn)環(huán)境的Dockerfile……實(shí)際上，這里我們不會(huì)做太大改變，它只有兩行：

#?prod.Dockerfile
#??1.?Line?-?Change?builder?image
FROM?debian:buster-slim?AS?builder
#??...
#??17.?Line?-?Switch?to?Distroless?image
FROM?gcr.io/distroless/python3-debian10?AS?runner
#??...?Rest?of?the?Dockefile

我們需要更改的只是用于構(gòu)建和運(yùn)行應(yīng)用程序的基礎(chǔ)鏡像！但區(qū)別相當(dāng)大——我們的開發(fā)鏡像是 1.03GB，而這個(gè)只有 103MB，這就是區(qū)別！我知道，我已經(jīng)能聽到你說：“但是 Alpine 可以更?。　笔堑?，沒錯(cuò)，但是大小沒那么重要。你只會(huì)在下載 / 上傳時(shí)注意到鏡像的大小，這并不經(jīng)常發(fā)生。當(dāng)鏡像運(yùn)行時(shí)，大小根本不重要。

比大小更重要的是安全性，從這個(gè)意義上說，Distroless 肯定更有優(yōu)勢(shì)，因?yàn)?Alpine（一個(gè)很好的替代選項(xiàng)）有很多額外的包，增加了攻擊面。關(guān)于 Distroless，最后值得一提的是鏡像調(diào)試?？紤]到 Distroless 不包含任何 shell（甚至不包含sh），當(dāng)你需要調(diào)試和查找時(shí)，就變得非常棘手。為此，所有 Distroless 鏡像都有調(diào)試版本。

因此，當(dāng)遇到問題時(shí)，你可以使用debug標(biāo)記構(gòu)建生產(chǎn)鏡像，并將其與正常鏡像一起部署，通過 exec 命令進(jìn)入鏡像并執(zhí)行（比如說）線程轉(zhuǎn)儲(chǔ)。你可以像下面這樣使用調(diào)試版本的python3鏡像：

docker run --entrypoint=sh -ti gcr.io/distroless/python3-debian10:debug

所有操作都只需一條命令

所有的Dockerfiles都準(zhǔn)備好了，讓我們用Makefile實(shí)現(xiàn)自動(dòng)化！我們首先要做的是用 Docker 構(gòu)建應(yīng)用程序。為了構(gòu)建 dev 映像，我們可以執(zhí)行make build-dev，它運(yùn)行以下目標(biāo):

#?The?binary?to?build?(just?the?basename).
MODULE?:=?blueprint
#?Where?to?push?the?docker?image.
REGISTRY??=?docker.pkg.github.com/martinheinz/python-project-blueprint
IMAGE?:=?$(REGISTRY)/$(MODULE)
#?This?version-strategy?uses?git?tags?to?set?the?version?string
TAG?:=?$(shell?git?describe?--tags?--always?--dirty)
build-dev:
?@echo?"\n${BLUE}Building?Development?image?with?labels:\n"
?@echo?"name:?$(MODULE)"
?@echo?"version:?$(TAG)${NC}\n"
?@sed?????????????????????????????????\
?????-e?'s|{NAME}|$(MODULE)|g'????????\
?????-e?'s|{VERSION}|$(TAG)|g'????????\
?????dev.Dockerfile?|?docker?build?-t?$(IMAGE):$(TAG)?-f-?.

這個(gè)目標(biāo)會(huì)構(gòu)建鏡像。它首先會(huì)用鏡像名和 Tag（運(yùn)行git describe創(chuàng)建）替換dev.Dockerfile底部的標(biāo)簽，然后運(yùn)行docker build。

接下來，使用make build-prod VERSION=1.0.0構(gòu)建生產(chǎn)鏡像：

build-prod:
?@echo?"\n${BLUE}Building?Production?image?with?labels:\n"
?@echo?"name:?$(MODULE)"
?@echo?"version:?$(VERSION)${NC}\n"
?@sed?????????????????????????????????????\
?????-e?'s|{NAME}|$(MODULE)|g'????????????\
?????-e?'s|{VERSION}|$(VERSION)|g'????????\
?????prod.Dockerfile?|?docker?build?-t?$(IMAGE):$(VERSION)?-f-?.

這個(gè)目標(biāo)與之前的目標(biāo)非常相似，但是在上面的示例1.0.0中，我們使用作為參數(shù)傳遞的版本而不是git標(biāo)簽作為版本 。當(dāng)你運(yùn)行 Docker 中的東西時(shí)，有時(shí)候你還需要在 Docker 中調(diào)試它，為此，有以下目標(biāo)：

#?Example:?make?shell?CMD="-c?'date?>?datefile'"
shell:?build-dev
?@echo?"\n${BLUE}Launching?a?shell?in?the?containerized?build?environment...${NC}\n"
??@docker?run?????????????????????????????????????????????????????\
???-ti?????????????????????????????????????????????????????\
???--rm????????????????????????????????????????????????????\
???--entrypoint?/bin/bash??????????????????????????????????\
???-u?$$(id?-u):$$(id?-g)??????????????????????????????????\
???$(IMAGE):$(TAG)?????????????\
???$(CMD)

從上面我們可以看到，入口點(diǎn)被bash覆蓋，而容器命令被參數(shù)覆蓋。通過這種方式，我們可以直接進(jìn)入容器瀏覽，或運(yùn)行一次性命令，就像上面的例子一樣。

當(dāng)我們完成了編碼并希望將鏡像推送到 Docker 注冊(cè)中心時(shí)，我們可以使用make push VERSION=0.0.2。讓我們看看目標(biāo)做了什么：

REGISTRY??=?docker.pkg.github.com/martinheinz/python-project-blueprint
push:?build-prod
?@echo?"\n${BLUE}Pushing?image?to?GitHub?Docker?Registry...${NC}\n"
?@docker?push?$(IMAGE):$(VERSION)

它首先運(yùn)行我們前面看到的目標(biāo)build-prod，然后運(yùn)行docker push。這里假設(shè)你已經(jīng)登錄到 Docker 注冊(cè)中心，因此在運(yùn)行這個(gè)命令之前，你需要先運(yùn)行docker login。

最后一個(gè)目標(biāo)是清理 Docker 工件。它使用被替換到Dockerfiles中的name標(biāo)簽來過濾和查找需要?jiǎng)h除的工件：

docker-clean:
?@docker?system?prune?-f?--filter?"label=name=$(MODULE)"

你可以在我的存儲(chǔ)庫(kù)中找到Makefile的完整代碼清單：https://github.com/MartinHeinz/python-project-blueprint/blob/master/Makefile

借助 GitHub Actions 實(shí)現(xiàn) CI/CD

現(xiàn)在，讓我們使用所有這些方便的make目標(biāo)來設(shè)置 CI/CD。我們將使用 GitHub Actions 和 GitHubPackage Registry 來構(gòu)建管道（作業(yè)）及存儲(chǔ)鏡像。那么，它們又是什么呢？

• GitHub Actions?是幫助你自動(dòng)化開發(fā)工作流的作業(yè) / 管道。你可以使用它們創(chuàng)建單個(gè)的任務(wù)，然后將它們合并到自定義工作流中，然后在每次推送到存儲(chǔ)庫(kù)或創(chuàng)建發(fā)布時(shí)執(zhí)行這些任務(wù)。

• GitHub Package Registry?是一個(gè)包托管服務(wù)，與 GitHub 完全集成。它允許你存儲(chǔ)各種類型的包，例如 Ruby gems 或 npm 包。我們將使用它來存儲(chǔ) Docker 鏡像。如果你不熟悉 GitHub Package Registry，那么你可以查看我的博文，了解更多相關(guān)信息：https://martinheinz.dev/blog/6 。

現(xiàn)在，為了使用 GitHubActions，我們需要?jiǎng)?chuàng)建將基于我們選擇的觸發(fā)器（例如 push to repository）執(zhí)行的工作流。這些工作流是存儲(chǔ)庫(kù)中.github/workflows目錄下的 YAML 文件：

.github
└──?workflows
????├──?build-test.yml
????└──?push.yml

在那里，我們將創(chuàng)建兩個(gè)文件build-test.yml和push.yml。前者包含 2 個(gè)作業(yè)，將在每次推送到存儲(chǔ)庫(kù)時(shí)被觸發(fā)，讓我們看下這兩個(gè)作業(yè):

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Run Makefile build for Development
      run: make build-dev

第一個(gè)作業(yè)名為build，它驗(yàn)證我們的應(yīng)用程序可以通過運(yùn)行make build-dev目標(biāo)來構(gòu)建。

在運(yùn)行之前，它首先通過執(zhí)行發(fā)布在 GitHub 上名為checkout的操作簽出我們的存儲(chǔ)庫(kù)。

jobs:
??test:
????runs-on:?ubuntu-latest
????steps:
????-?uses:?actions/checkout@v1
????-?uses:?actions/setup-python@v1
??????with:
????????python-version:?'3.8'
????-?name:?Install?Dependencies
??????run:?|
????????python?-m?pip?install?--upgrade?pip
????????pip?install?-r?requirements.txt
????-?name:?Run?Makefile?test
??????run:?make?test
????-?name:?Install?Linters
??????run:?|
????????pip?install?pylint
????????pip?install?flake8
????????pip?install?bandit
????-?name:?Run?Linters
??????run:?make?lint

第二個(gè)作業(yè)稍微復(fù)雜一點(diǎn)。它測(cè)試我們的應(yīng)用程序并運(yùn)行 3 個(gè) linter（代碼質(zhì)量檢查工具）。與上一個(gè)作業(yè)一樣，我們使用checkout@v1操作來獲取源代碼。在此之后，我們運(yùn)行另一個(gè)已發(fā)布的操作setup-python@v1，設(shè)置 python 環(huán)境。要了解詳細(xì)信息，請(qǐng)查看這里：https://github.com/actions/setup-python 我們已經(jīng)有了 Python 環(huán)境，我們還需要requirements.txt中的應(yīng)用程序依賴關(guān)系，這是我們用pip安裝的。

這時(shí)，我們可以著手運(yùn)行make test目標(biāo)，它將觸發(fā)我們的 Pytest 套件。如果我們的測(cè)試套件測(cè)試通過，我們繼續(xù)安裝前面提到的 linter——pylint、flake8 和 bandit。最后，我們運(yùn)行make lint目標(biāo)，它將觸發(fā)每一個(gè) linter。關(guān)于構(gòu)建 / 測(cè)試作業(yè)的內(nèi)容就這些，但 push 作業(yè)呢？讓我們也一起看下：

on:
??push:
????tags:
????-?'*'
jobs:
??push:
????runs-on:?ubuntu-latest
????steps:
????-?uses:?actions/checkout@v1
????-?name:?Set?env
??????run:?echo?::set-env?name=RELEASE_VERSION::$(echo?${GITHUB_REF:10})
????-?name:?Log?into?Registry
??????run:?echo?"${{?secrets.REGISTRY_TOKEN?}}"?|?docker?login?docker.pkg.github.com?-u?${{?github.actor?}}?--password-stdin
????-?name:?Push?to?GitHub?Package?Registry
??????run:?make?push?VERSION=${{?env.RELEASE_VERSION?}}

前四行定義了何時(shí)觸發(fā)該作業(yè)。我們指定，只有當(dāng)標(biāo)簽被推送到存儲(chǔ)庫(kù)時(shí)，該作業(yè)才啟動(dòng)（*指定標(biāo)簽名稱的模式——在本例中是任何名稱）。這樣，我們就不會(huì)在每次推送到存儲(chǔ)庫(kù)的時(shí)候都把我們的 Docker 鏡像推送到 GitHub Package Registry，而只是在我們推送指定應(yīng)用程序新版本的標(biāo)簽時(shí)才這樣做。

現(xiàn)在我們看下這個(gè)作業(yè)的主體——它首先簽出源代碼，并將環(huán)境變量RELEASE_VERSION設(shè)置為我們推送的git標(biāo)簽。這是通過 GitHub Actions 內(nèi)置的::setenv特性完成的（更多信息請(qǐng)查看這里：https://help.github.com/en/actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions#set-an-environment-variable-set-env ）。

接下來，它使用存儲(chǔ)在存儲(chǔ)庫(kù)中的 secretREGISTRY_TOKEN登錄到 Docker 注冊(cè)中心，并由發(fā)起工作流的用戶登錄（github.actor）。最后，在最后一行，它運(yùn)行目標(biāo)push，構(gòu)建生產(chǎn)鏡像并將其推送到注冊(cè)中心，以之前推送的git標(biāo)簽作為鏡像標(biāo)簽。

感興趣的讀者可以從這里簽出完整的代碼清單：https://github.com/MartinHeinz/python-project-blueprint/tree/master/.github/workflows

使用 CodeClimate 進(jìn)行代碼質(zhì)量檢查

最后但同樣重要的是，我們還將使用 CodeClimate 和 SonarCloud 添加代碼質(zhì)量檢查。它們將與上文的測(cè)試作業(yè)一起觸發(fā)。所以，讓我們添加以下幾行：

#?test,?lint...
-?name:?Send?report?to?CodeClimate
??run:?|
????export?GIT_BRANCH="${GITHUB_REF/refs\/heads\//}"
????curl?-L?https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64?>?./cc-test-reporter
????chmod?+x?./cc-test-reporter
????./cc-test-reporter?format-coverage?-t?coverage.py?coverage.xml
????./cc-test-reporter?upload-coverage?-r?"${{?secrets.CC_TEST_REPORTER_ID?}}"
-?name:?SonarCloud?scanner
??uses:?sonarsource/sonarcloud-github-action@master
??env:
????GITHUB_TOKEN:?${{?secrets.GITHUB_TOKEN?}}
????SONAR_TOKEN:?${{?secrets.SONAR_TOKEN?}}

我們從 CodeClimate 開始，首先輸出變量GIT_BRANCH，我們會(huì)用環(huán)境變量GITHUB_REF來檢索這個(gè)變量。接下來，我們下載 CodeClimate test reporter 并使其可執(zhí)行。接下來，我們使用它來格式化由測(cè)試套件生成的覆蓋率報(bào)告，而且，在最后一行，我們將它與存儲(chǔ)在存儲(chǔ)庫(kù)秘密中的 test reporter ID 一起發(fā)送給 CodeClimate。至于 SonarCloud，我們需要在存儲(chǔ)庫(kù)中創(chuàng)建sonar-project.properties文件，類似下面這樣（這個(gè)文件的值可以在 SonarCloud 儀表板的右下角找到）：

sonar.organization=martinheinz-github
sonar.projectKey=MartinHeinz_python-project-blueprint
sonar.sources=blueprint

除此之外，我們可以使用現(xiàn)有的sonarcloud-github-action，它會(huì)為我們做所有的工作。我們所要做的就是提供 2 個(gè)令牌——GitHub 令牌默認(rèn)已在存儲(chǔ)庫(kù)中，SonarCloud 令牌可以從 SonarCloud 網(wǎng)站獲得。

注意：關(guān)于如何獲取和設(shè)置前面提到的所有令牌和秘密的步驟都在存儲(chǔ)庫(kù)的自述文件中：https://github.com/MartinHeinz/python-project-blueprint/blob/master/README.md

小 ?結(jié)

就是這樣！有了上面的工具、配置和代碼，你就可以構(gòu)建和全方位自動(dòng)化下一個(gè) Python 項(xiàng)目了！如果關(guān)于本文討論的主題，你想了解更多信息，請(qǐng)查看存儲(chǔ)庫(kù)中的文檔和代碼：https://github.com/MartinHeinz/python-project-blueprint。

作者：Martin Heinz
編譯：平川
來源：https://martinheinz.dev/blog/17