如何將你的Python項目全面自動化？
每個項目——無論你是在從事 Web 應用程序、數據科學還是 AI 開發——都可以從配置良好的 CI/CD、Docker 鏡像或一些額外的代碼質量工具（如 CodeClimate 或 SonarCloud）中獲益。所有這些都是本文要討論的內容，我們將看看如何將它們添加到 Python 項目中！
- 在寫這篇文章之前，我還寫了一篇“Python 項目終極設置”，讀者感興趣的話，可以先讀下那一篇：https://martinheinz.dev/blog/14。
- GitHub 庫中提供了完整的源代碼和文檔：https://github.com/MartinHeinz/python-project-blueprint。
開發環境中可調試的 Docker 容器
有些人不喜歡 Docker，因為容器很難調試，或者構建鏡像需要花很長的時間。那么，就讓我們從這里開始，構建適合開發的鏡像——構建速度快且易于調試。
為了使鏡像易于調試，我們需要一個基礎鏡像，包括所有調試時可能用到的工具，像bash、vim、netcat、wget、cat、find、grep等。它默認包含很多工具，沒有的也很容易安裝。這個鏡像很笨重，但這不要緊，因為它只用于開發。你可能也注意到了，我選擇了非常具體的映像——鎖定了 Python 和 Debian 的版本——我是故意這么做的，因為我們希望最小化 Python 或 Debian 版本更新（可能不兼容）導致“破壞”的可能性。
作為替代方案，你也可以使用基于 Alpine 的鏡像。然而，這可能會導致一些問題，因為它使用musl libc而不是 Python 所依賴的glibc。所以，如果決定選擇這條路線，請記住這一點。至于構建速度，我們將利用多階段構建以便可以緩存盡可能多的層。通過這種方式，我們可以避免下載諸如gcc之類的依賴項和工具，以及應用程序所需的所有庫（來自requirements.txt）。
為了進一步提高速度，我們將從前面提到的python:3.8.1-buster創建自定義基礎鏡像，這將包括我們需要的所有工具，因為我們無法將下載和安裝這些工具所需的步驟緩存到最終的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}
從上面可以看到，在創建最后的runner鏡像之前，我們要經歷 3 個中間鏡像。首先是名為builder的鏡像，它下載構建最終應用所需的所有必要的庫，其中包括gcc和 Python 虛擬環境。安裝完成后，它還創建了實際的虛擬環境，供接下來的鏡像使用。接下來是build -venv鏡像，它將依賴項列表（requirements.txt）復制到鏡像中，然后安裝它。緩存會用到這個中間鏡像，因為我們只希望在requirement .txt更改時安裝庫，否則我們就使用緩存。
在創建最終鏡像之前，我們首先要針對應用程序運行測試。這發生在tester鏡像中。我們將源代碼復制到鏡像中并運行測試。如果測試通過，我們就繼續構建runner。
對于runner鏡像，我們使用自定義鏡像，其中包括一些額外的工具，如vim或netcat，這些功能在正常的 Debian 鏡像中是不存在的。
- 你可以在 Docker Hub 中找到這個鏡像：https://hub.docker.com/repository/docker/martinheinz/python-3.8.1-buster-tools
- 你也可以在base.Dockerfile 中查看其非常簡單的`Dockerfile`：https://github.com/MartinHeinz/python-project-blueprint/blob/master/base.Dockerfile
那么，我們在這個最終鏡像中要做的是——首先我們從tester鏡像中復制虛擬環境，其中包含所有已安裝的依賴項，接下來我們復制經過測試的應用程序。現在，我們的鏡像中已經有了所有的資源，我們進入應用程序所在的目錄，然后設置ENTRYPOINT，以便它在啟動鏡像時運行我們的應用程序。出于安全原因，我們還將USER設置為1001，因為最佳實踐告訴我們，永遠不要在root用戶下運行容器。最后兩行設置鏡像標簽。它們將在使用make目標運行構建時被替換 / 填充，稍后我們將看到。
針對生產環境優化過的 Docker 容器
當涉及到生產級鏡像時，我們會希望確保它們小而安全且速度快。對于這個任務，我個人最喜歡的是來自 Distroless 項目的 Python 鏡像。可是，Distroless 是什么呢？
這么說吧——在一個理想的世界里，每個人都可以使用FROM scratch構建他們的鏡像，然后作為基礎鏡像（也就是空鏡像）。然而，大多數人不愿意這樣做，因為那需要靜態鏈接二進制文件，等等。這就是 Distroless 的用途——它讓每個人都可以FROM scratch。
好了，現在讓我們具體描述一下 Distroless 是什么。它是由谷歌生成的一組鏡像，其中包含應用程序所需的最低條件，這意味著沒有 shell、包管理器或任何其他工具，這些工具會使鏡像膨脹，干擾安全掃描器（如 CVE），增加建立遵從性的難度。
現在，我們知道我們在干什么了，讓我們看看生產環境的Dockerfile……實際上，這里我們不會做太大改變，它只有兩行：
- # 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
我們需要更改的只是用于構建和運行應用程序的基礎鏡像！但區別相當大——我們的開發鏡像是 1.03GB，而這個只有 103MB，這就是區別！我知道，我已經能聽到你說：“但是 Alpine 可以更小！”是的，沒錯，但是大小沒那么重要。你只會在下載 / 上傳時注意到鏡像的大小，這并不經常發生。當鏡像運行時，大小根本不重要。
比大小更重要的是安全性，從這個意義上說，Distroless 肯定更有優勢，因為 Alpine（一個很好的替代選項）有很多額外的包，增加了攻擊面。關于 Distroless，最后值得一提的是鏡像調試。考慮到 Distroless 不包含任何 shell（甚至不包含sh），當你需要調試和查找時，就變得非常棘手。為此，所有 Distroless 鏡像都有調試版本。
因此，當遇到問題時，你可以使用debug標記構建生產鏡像，并將其與正常鏡像一起部署，通過 exec 命令進入鏡像并執行（比如說）線程轉儲。你可以像下面這樣使用調試版本的python3鏡像：
- docker run --entrypoint=sh -ti gcr.io/distroless/python3-debian10:debug
所有操作都只需一條命令
所有的Dockerfiles都準備好了，讓我們用Makefile實現自動化！我們首先要做的是用 Docker 構建應用程序。為了構建 dev 映像，我們可以執行make build-dev，它運行以下目標:
- # 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- .
這個目標會構建鏡像。它首先會用鏡像名和 Tag（運行git describe創建）替換dev.Dockerfile底部的標簽，然后運行docker build。
接下來，使用make build-prod VERSION=1.0.0構建生產鏡像：
- 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- .
這個目標與之前的目標非常相似，但是在上面的示例1.0.0中，我們使用作為參數傳遞的版本而不是git標簽作為版本 。當你運行 Docker 中的東西時，有時候你還需要在 Docker 中調試它，為此，有以下目標：
- # 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)
從上面我們可以看到，入口點被bash覆蓋，而容器命令被參數覆蓋。通過這種方式，我們可以直接進入容器瀏覽，或運行一次性命令，就像上面的例子一樣。
當我們完成了編碼并希望將鏡像推送到 Docker 注冊中心時，我們可以使用make push VERSION=0.0.2。讓我們看看目標做了什么：
- 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)
它首先運行我們前面看到的目標build-prod，然后運行docker push。這里假設你已經登錄到 Docker 注冊中心，因此在運行這個命令之前，你需要先運行docker login。
最后一個目標是清理 Docker 工件。它使用被替換到Dockerfiles中的name標簽來過濾和查找需要刪除的工件：
- docker-clean:
- @docker system prune -f --filter "label=name=$(MODULE)"
你可以在我的存儲庫中找到Makefile的完整代碼清單：https://github.com/MartinHeinz/python-project-blueprint/blob/master/Makefile
借助 GitHub Actions 實現 CI/CD
現在，讓我們使用所有這些方便的make目標來設置 CI/CD。我們將使用 GitHub Actions 和 GitHubPackage Registry 來構建管道（作業）及存儲鏡像。那么，它們又是什么呢？
- GitHub Actions 是幫助你自動化開發工作流的作業 / 管道。你可以使用它們創建單個的任務，然后將它們合并到自定義工作流中，然后在每次推送到存儲庫或創建發布時執行這些任務。
- GitHub Package Registry 是一個包托管服務，與 GitHub 完全集成。它允許你存儲各種類型的包，例如 Ruby gems 或 npm 包。我們將使用它來存儲 Docker 鏡像。如果你不熟悉 GitHub Package Registry，那么你可以查看我的博文，了解更多相關信息：https://martinheinz.dev/blog/6 。
現在，為了使用 GitHubActions，我們需要創建將基于我們選擇的觸發器（例如 push to repository）執行的工作流。這些工作流是存儲庫中.github/workflows目錄下的 YAML 文件：
- .github
- └── workflows
- ├── build-test.yml
- └── push.yml
在那里，我們將創建兩個文件build-test.yml和push.yml。前者包含 2 個作業，將在每次推送到存儲庫時被觸發，讓我們看下這兩個作業:
- jobs:
- build:
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v1
- - name: Run Makefile build for Development
- run: make build-dev
第一個作業名為build，它驗證我們的應用程序可以通過運行make build-dev目標來構建。
在運行之前，它首先通過執行發布在 GitHub 上名為checkout的操作簽出我們的存儲庫。
- 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
第二個作業稍微復雜一點。它測試我們的應用程序并運行 3 個 linter（代碼質量檢查工具）。與上一個作業一樣，我們使用checkout@v1操作來獲取源代碼。在此之后，我們運行另一個已發布的操作setup-python@v1，設置 python 環境。要了解詳細信息，請查看這里：https://github.com/actions/setup-python 我們已經有了 Python 環境，我們還需要requirements.txt中的應用程序依賴關系，這是我們用pip安裝的。
這時，我們可以著手運行make test目標，它將觸發我們的 Pytest 套件。如果我們的測試套件測試通過，我們繼續安裝前面提到的 linter——pylint、flake8 和 bandit。最后，我們運行make lint目標，它將觸發每一個 linter。關于構建 / 測試作業的內容就這些，但 push 作業呢？讓我們也一起看下：
- 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 }}
前四行定義了何時觸發該作業。我們指定，只有當標簽被推送到存儲庫時，該作業才啟動（*指定標簽名稱的模式——在本例中是任何名稱）。這樣，我們就不會在每次推送到存儲庫的時候都把我們的 Docker 鏡像推送到 GitHub Package Registry，而只是在我們推送指定應用程序新版本的標簽時才這樣做。
現在我們看下這個作業的主體——它首先簽出源代碼，并將環境變量RELEASE_VERSION設置為我們推送的git標簽。這是通過 GitHub Actions 內置的::setenv特性完成的（更多信息請查看這里：https://help.github.com/en/actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions#set-an-environment-variable-set-env ）。
接下來，它使用存儲在存儲庫中的 secretREGISTRY_TOKEN登錄到 Docker 注冊中心，并由發起工作流的用戶登錄（github.actor）。最后，在最后一行，它運行目標push，構建生產鏡像并將其推送到注冊中心，以之前推送的git標簽作為鏡像標簽。
感興趣的讀者可以從這里簽出完整的代碼清單：https://github.com/MartinHeinz/python-project-blueprint/tree/master/.github/workflows
使用 CodeClimate 進行代碼質量檢查
最后但同樣重要的是，我們還將使用 CodeClimate 和 SonarCloud 添加代碼質量檢查。它們將與上文的測試作業一起觸發。所以，讓我們添加以下幾行：
- # 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，我們會用環境變量GITHUB_REF來檢索這個變量。接下來，我們下載 CodeClimate test reporter 并使其可執行。接下來，我們使用它來格式化由測試套件生成的覆蓋率報告，而且，在最后一行，我們將它與存儲在存儲庫秘密中的 test reporter ID 一起發送給 CodeClimate。至于 SonarCloud，我們需要在存儲庫中創建sonar-project.properties文件，類似下面這樣（這個文件的值可以在 SonarCloud 儀表板的右下角找到）：
- sonar.organization=martinheinz-github
- sonar.projectKey=MartinHeinz_python-project-blueprint
- sonar.sources=blueprint
除此之外，我們可以使用現有的sonarcloud-github-action，它會為我們做所有的工作。我們所要做的就是提供 2 個令牌——GitHub 令牌默認已在存儲庫中，SonarCloud 令牌可以從 SonarCloud 網站獲得。
注意：關于如何獲取和設置前面提到的所有令牌和秘密的步驟都在存儲庫的自述文件中：https://github.com/MartinHeinz/python-project-blueprint/blob/master/README.md
小 結
就是這樣！有了上面的工具、配置和代碼，你就可以構建和全方位自動化下一個 Python 項目了！如果關于本文討論的主題，你想了解更多信息，請查看存儲庫中的文檔和代碼：https://github.com/MartinHeinz/python-project-blueprint， 如果你有什么建議 / 問題，請在存儲庫中提交問題庫，或者如果你喜歡我的這個小項目，請為我點贊。
