建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)
無論你的項(xiàng)目是用于開發(fā)Web應(yīng)用，處理數(shù)據(jù)科學(xué)問題還是AI，使用配置良好的CI / CD，可在開發(fā)中調(diào)試且針對(duì)生產(chǎn)環(huán)境進(jìn)行了優(yōu)化的Docker鏡像，或一些其它的代碼質(zhì)量工具，都能讓你受益。
本文將告訴你該如何把它們加入Python項(xiàng)目中！
這是我的倉庫，其中包含完整的源代碼和文檔：https://github.com/MartinHeinz/python-project-blueprint
用于開發(fā)的可調(diào)試Docker容器
有些人不喜歡Docker，因?yàn)槿萜骺赡芎茈y調(diào)試，或者因?yàn)樗鼈兊溺R像需要很長時(shí)間才能構(gòu)建。因此，讓我們從構(gòu)建用于開發(fā)的理想鏡像開始，它能夠快速構(gòu)建且易于調(diào)試。
為了使鏡像易于調(diào)試，需要基礎(chǔ)鏡像，其中包括調(diào)試時(shí)可能需要的所有工具，例如bash，vim，netcat，wget，cat，find，grep等。
python:3.8.1-buster似乎是這一任務(wù)的理想選擇。它在默認(rèn)情況下包含許多工具，我們可以很容易地安裝所有缺少的東西。這個(gè)基本鏡像非常厚重，但這并不重要，因?yàn)榇藭r(shí)它將僅用于開發(fā)。
你可能已經(jīng)注意到，我選擇了非常具體的鏡像：鎖定了Python版本和Debian版本。這是故意的，因?yàn)槲覀兿Ｍ畲蟪潭鹊販p少由更新的，可能不兼容的Python或Debian版本引起“損壞”的可能性。
圖源：techcrunch
可以使用基于Alpine的鏡像作為替代。但是，這可能會(huì)引起一些問題，因?yàn)樗褂胢usllibc而不是Python依賴的glibc。因此，如果決定選擇此配置，請(qǐng)記住這一點(diǎn)。
至于構(gòu)建的速度，我們將利用多階段構(gòu)建以便緩存盡可能多的層。這樣，就可以避免下載例如gcc的依賴項(xiàng)和工具以及(requirements.txt中的)應(yīng)用程序所需的所有庫。
因?yàn)闊o法將下載和安裝這些工具所需的步驟緩存到最終的運(yùn)行程序鏡像中，我們將使用前面提到的python：3.8.1-buster創(chuàng)建自定義基本鏡像，該鏡像將包含需要的所有工具，從而進(jìn)一步提升處理速度。
說了這么多，來看看Dockerfile：
- # dev.Dockerfile
- FROMpython:3.8.1-buster AS builder
- RUN apt-get update&& apt-get install -y --no-install-recommends --yes python3-venv gcclibpython3-dev && \
- python3 -m venv /venv && \
- /venv/bin/pip install --upgradepip
- FROM builder ASbuilder-venv
- COPYrequirements.txt /requirements.txt
- RUN /venv/bin/pipinstall -r /requirements.txt
- FROM builder-venv AStester
- COPY . /app
- WORKDIR /app
- RUN/venv/bin/pytest
- FROMmartinheinz/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}
- LABELversion={VERSION}
從上面的文檔可以看到我們將創(chuàng)建3個(gè)中間鏡像，然后創(chuàng)建最終的運(yùn)行鏡像。第一個(gè)鏡像被稱為builder，它會(huì)下載構(gòu)建最終應(yīng)用程序所需的所有必需庫，其中包括gcc和Python虛擬環(huán)境。安裝完成后，它還會(huì)創(chuàng)建實(shí)際的虛擬環(huán)境以供下一個(gè)鏡像使用。
接著是builder-venv鏡像，該鏡像將依賴項(xiàng)列表(requirements.txt)復(fù)制到鏡像中，然后進(jìn)行安裝。緩存需要此中間鏡像，因?yàn)閮H在requirements.txt更改時(shí)才會(huì)安裝庫，否則僅使用緩存。
在創(chuàng)建最終鏡像之前，首先要針對(duì)應(yīng)用程序運(yùn)行測試。這就是tester鏡像做的工作。我們將源代碼復(fù)制到鏡像中并運(yùn)行測試。如果通過了，程序就會(huì)運(yùn)行至runner。
對(duì)于runner鏡像，我們使用的是自定義鏡像，其中包括普通Debian鏡像中不存在的一些額外功能，例如vim或netcat。你可以在Docker Hub上的這里找到此鏡像，還可以通過這里在base.Dockerfile中檢驗(yàn)這個(gè)非常簡單的Dockerfile。
因此，在最終鏡像中的工作有這些：首先復(fù)制虛擬環(huán)境，該環(huán)境保留了tester鏡像中所有已安裝的依賴項(xiàng)，接下來復(fù)制經(jīng)過測試的應(yīng)用程序。
現(xiàn)在，鏡像已經(jīng)擁有了所有源，移至應(yīng)用程序所在的目錄設(shè)置ENTRYPOINT，以便在鏡像啟動(dòng)時(shí)運(yùn)行應(yīng)用程序。出于安全原因?qū)SER設(shè)置為1001，因?yàn)樽罴褜?shí)踐告訴我們，永遠(yuǎn)不要在root用戶下運(yùn)行容器。
最后2行設(shè)置鏡像的標(biāo)簽。當(dāng)使用make 命令指向構(gòu)建并運(yùn)行時(shí)，這些將被替換或填充，這一點(diǎn)稍后我們會(huì)看到。
為產(chǎn)品優(yōu)化的Docker容器
談及產(chǎn)品級(jí)鏡像時(shí)，我們想確保它們小巧，安全且快速。我個(gè)人最喜歡的是Distroless項(xiàng)目中的Python鏡像。那么什么是Distroless?
可以這樣形容它：在理想的世界中，每個(gè)人都將使用FROM scratch作為其基本鏡像(即空鏡像)來構(gòu)建其鏡像。
但這不是大多數(shù)人想要做的，因?yàn)樗箪o態(tài)連接二進(jìn)制文件等。這就是Distroless發(fā)揮作用的地方了，它是為每個(gè)人設(shè)計(jì)的FROM scratch。
Distroless是由Google制作的一組鏡像，包含應(yīng)用所需的最低要求，這意味著沒有殼(shell)，程序包管理器或任何其他工具會(huì)使鏡像膨脹并給安全掃描器(例如CVE)造成信號(hào)噪聲，從而使其變得更難建立規(guī)則。
知道了要解決的問題，讓我們看一下生產(chǎn)型Dockerfile ...... 實(shí)際上，在這里不需要做太多更改，只有兩行：
- # prod.Dockerfile
- # 1. Line - Change builder image
- FROMdebian:buster-slim AS builder
- # ...
- # 17. Line - Switch to Distroless image
- FROMgcr.io/distroless/python3-debian10 AS runner
- # ... Rest of the Dockefile
需要更改的只是用于構(gòu)建和運(yùn)行應(yīng)用程序的基本鏡像!
但是差別是巨大的：我們的開發(fā)鏡像為1.03GB，而這個(gè)鏡像僅為103MB，這是完全不一樣的!
我知道你會(huì)說“但是Alpine可以變得更小”是的，沒錯(cuò)，但是大小的差距并不那么重要。你只會(huì)在下載/上傳鏡像時(shí)注意鏡像的大小，這種情況并不常見。當(dāng)鏡像運(yùn)行時(shí)，大小完全不重要。比大小更重要的是安全性，就這一點(diǎn)而言，Distroless肯定具有優(yōu)勢，因?yàn)锳lpine(這是一個(gè)很好的替代)具有許多額外的程序包，可以增加攻擊面。
關(guān)于Distroless值得一提的最后一件事是調(diào)試鏡像。考慮到Distroless不包含任何殼(甚至不包括sh)，這使得需要調(diào)試和檢查時(shí)非常棘手。為此，所有Distroless鏡像都有調(diào)試版本。
因此，當(dāng)遇到麻煩時(shí)，可以使用debug標(biāo)簽構(gòu)建生產(chǎn)鏡像，并將其部署到常規(guī)鏡像旁邊，在其中執(zhí)行并且進(jìn)行如線程轉(zhuǎn)儲(chǔ)的操作?？梢韵襁@樣使用python3鏡像的調(diào)試版本：
- docker run --entrypoint=sh -tigcr.io/distroless/python3-debian10:debug
適用一切情況的單一命令
在準(zhǔn)備好所有Dockerfile后，不妨使用Makefile將其自動(dòng)化吧!要做的第一件事是使用Docker構(gòu)建應(yīng)用程序。因此，為了構(gòu)建開發(fā)鏡像，我們可以執(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 tagsto set the version string
- TAG := $(shell git describe --tags--always --dirty)
- build-dev:
- @echo "\n${BLUE}BuildingDevelopment 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- .
該目標(biāo)文件首先通過在dev.Dockerfile的底部用標(biāo)簽替換鏡像的名稱和標(biāo)簽來構(gòu)建鏡像，該標(biāo)簽是通過運(yùn)行g(shù)it describe然后運(yùn)行docker build來創(chuàng)建的。
下一步——使用make build-prod VERSION = 1.0.0構(gòu)建生產(chǎn)版本：
- build-prod:
- @echo "\n${BLUE}Building Productionimage 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)文件非常相似，但是在1.0.0版本上的示例中，我們將把版本作為參數(shù)傳遞，而不是使用git標(biāo)簽作為版本。
當(dāng)在Docker中運(yùn)行所有內(nèi)容時(shí)，有時(shí)需要在Docker中對(duì)其進(jìn)行調(diào)試，為此，有以下目標(biāo)文件：
- # Example: make shell CMD="-c 'date> datefile'"
- shell: build-dev
- @echo "\n${BLUE}Launching a shellin the containerized build environment...${NC}\n"
- @docker run \
- -ti \
- --rm \
- --entrypoint /bin/bash \
- -u $$(id -u):$$(id -g) \
- $(IMAGE):$(TAG) \
- $(CMD)
從上面可以看出，bash覆蓋了入口點(diǎn)，而參數(shù)則覆蓋了容器命令。這樣，我們可以像上面的示例那樣直接進(jìn)入容器并進(jìn)行調(diào)試或運(yùn)行一個(gè)關(guān)閉命令。
當(dāng)完成編碼并想將鏡像推送到Docker注冊(cè)表時(shí)，可以使用makepush 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"
- @dockerpush $(IMAGE):$(VERSION)
它首先運(yùn)行之前看過的build-prod文件，然后運(yùn)行docker push。這里假設(shè)已登錄Docker注冊(cè)表，因此在運(yùn)行此注冊(cè)表之前，需要運(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)"
使用GitHub Actions的CI / CD
現(xiàn)在開始使用所有這些方便的make目標(biāo)命令來設(shè)置CI / CD。我們將使用GitHub Actions和GitHub Package Registry來構(gòu)建管道(工作)并存儲(chǔ)鏡像。那么這兩個(gè)東西到底是什么呢?
- Github Actions是可以幫助自動(dòng)化開發(fā)工作流程的作業(yè)/管道?？梢允褂盟鼈儊韯?chuàng)建單個(gè)任務(wù)，然后將它們組合到自定義的工作流程中，然后在諸如每次推送到倉庫或創(chuàng)建發(fā)行版的時(shí)候執(zhí)行這些工作流程。
- GitHub Package Registry是與GitHub完全集成的軟件包托管服務(wù)。它可以存儲(chǔ)各種類型的軟件包，例如：Ruby gems或npm軟件包。我們將使用它來存儲(chǔ)Docker鏡像。
- 如果你不熟悉GitHub Package Registry，并且想要了解更多相關(guān)信息，可以查看我的博客文章：https://martinheinz.dev/blog/6
[[323310]] 圖源：unsplash
現(xiàn)在，為了使用GitHub Action，需要?jiǎng)?chuàng)建工作流，這些工作流將根據(jù)選擇的觸發(fā)器(例如，推送到倉庫)執(zhí)行。這些工作流是YAML文件，位于倉庫中的.github / workflows目錄中：
- .github
- └── workflows
- ├── build-test.yml
- └── push.yml
第一項(xiàng)工作名為build，它通過運(yùn)行make build-dev命令來驗(yàn)證是否可以構(gòu)建應(yīng)用程序。但在運(yùn)行它之前，它首先通過執(zhí)行在GitHub上發(fā)布的名為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
第二項(xiàng)工作稍微復(fù)雜一些。它針對(duì)應(yīng)用程序以及3個(gè)linter(代碼質(zhì)量檢查器)運(yùn)行測試。
與上一項(xiàng)工作相同，我們使用checkout@v1操作獲取源代碼。之后，運(yùn)行另一個(gè)名為setup-python@v1的已發(fā)布操作，該操作幫助設(shè)置了python環(huán)境(你可以在此處找到有關(guān)它的詳細(xì)信息)。
現(xiàn)在有了python環(huán)境，還需要使用pip安裝的requirements.txt中的應(yīng)用程序依賴項(xiàng)。此時(shí)可以繼續(xù)運(yùn)行make test命令，這將觸發(fā)Pytest套件。如果測試套件通過，將繼續(xù)安裝前面提到的linters，即pylint，flake8和bandit。最后運(yùn)行make lint命令，這將觸發(fā)每個(gè)linter。
這就是構(gòu)建/測試工作的全部流程，但是應(yīng)該如何推送呢?來看一下：
- on:
- push:
- tags:
- - '*'
- jobs:
- push:
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v1
- - name: Set env
- run: echo ::set-envname=RELEASE_VERSION::$(echo ${GITHUB_REF:10})
- - name: Log intoRegistry
- run: echo "${{secrets.REGISTRY_TOKEN }}" |
- docker login docker.pkg.github.com -u ${{github.actor }} --password-stdin
- - name: Push to GitHubPackage Registry
- run: make pushVERSION=${{ env.RELEASE_VERSION }}
前4行定義了何時(shí)觸發(fā)這項(xiàng)工作。我們指定僅當(dāng)將標(biāo)簽推送到倉庫時(shí)才開始該工作(*在這種情況下指定標(biāo)簽名稱可以是任何模式)，因此不會(huì)在每次推送到倉庫時(shí)都將Docker鏡像推送到GitHub Package Registry，而僅在推送指定應(yīng)用程序新版本的標(biāo)簽時(shí)才推送到GitHubPackage Registry。
現(xiàn)在到了工作的主體，它是從檢索源代碼并將RELEASE_VERSION的環(huán)境變量設(shè)置為推送的git標(biāo)簽開始的。這是通過GitHub Actions的內(nèi)置:: setenv功能完成的。
接下來，它使用存儲(chǔ)在repository secrets中的REGISTRY_TOKEN登錄到Docker注冊(cè)表，并登錄啟動(dòng)工作流的用戶(github.actor)。最后，在最后一行中，它運(yùn)行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ì)量檢查
最后但并非最不重要的一點(diǎn)是，還要使用CodeClimate和SonarCloud來添加代碼質(zhì)量檢查。這些將與上面展示的test工作一起觸發(fā)。因此，我們?cè)谄渲刑砑訋仔校?/p>
- # test, lint...
- - name: Send report toCodeClimate
- run: |
- export GIT_BRANCH="${GITHUB_REF/refs\/heads\//}"
- curl -Lhttps://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: SonarCloudscanner
- uses: sonarsource/sonarcloud-github-action@master
- env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
從CodeClimate開始，首先導(dǎo)出GIT_BRANCH變量，然后使用GITHUB_REF環(huán)境變量進(jìn)行檢索。其次，下載CodeClimate測試報(bào)告程序并使其可執(zhí)行。然后，使用它來格式化由測試套件生成的覆蓋率報(bào)告，并在最后一行將其發(fā)送到帶有測試報(bào)告器ID的CodeClimate中，該ID存儲(chǔ)在repository secrets中。
至于SonarCloud，我們需要在倉庫中創(chuàng)建如下所示的sonar-project.properties文件(文件中的值可以在SonarCloud儀表板的右下角找到)：
- .organization=martinheinz-github
- sonar.projectKey=MartinHeinz_python-project-blueprint
- sonar.sources=blueprint
除此之外，只需使用已有的sonarcloud-github-action就可以幫我們完成所有工作。要做的就是提供2個(gè)令牌：GitHub令牌(默認(rèn)情況下位于倉庫中)和SonarCloud令牌(可從SonarCloud網(wǎng)站獲得)。
注意：有關(guān)如何獲取和設(shè)置所有上述令牌和密鑰的步驟，請(qǐng)參見README文件：
https://github.com/MartinHeinz/python-project-blueprint/blob/master/README.md
[[323311]] 圖源：unsplash
有了上述的工具、配置和代碼，你就可以構(gòu)建和自動(dòng)化下一個(gè)Python項(xiàng)目的方各個(gè)方面了?？烊ピ囋嚢?
標(biāo)題名稱：精益求精！如何讓你的Python項(xiàng)目從自動(dòng)化中受益
文章分享：http://fisionsoft.com.cn/article/dpeeicd.html
