每个Python项目都可以从自动化DevOps中受益：使用Makefile、file优化的Docker镜像、配置良好的CI / CD、代码质量工具等等。
每个项目（无论您使用的是Web应用程序，数据科学还是AI项目）都可以从配置良好的CI / CD，可在开发中调试且针对生产环境进行了优化的Docker中受益，还可以使用一些额外的代码质量工具，例如CodeClimate或SonarCloud。所有这些都是我们将在本文中介绍的内容，我们将看到如何将它们添加到您的Python 项目中！
这是带有完整源代码和文档的存储库： github.com/MartinHeinz/python-project-blueprint
用于开发的可调试Docker容器
# 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}
|
开始几行带有builder的是建立我们的最终应用程序的所有必要的库，这包括gcc和Python的虚拟环境。安装后，它还会创建实际的虚拟环境，然后供下一个镜像使用。
接下来是 builder-venv ，它将我们的依赖项列表（requirements.txt）复制到镜像中，然后进行安装。缓存需要此中间镜像，因为我们只想在requirements.txt 发生更改时安装库 ，否则我们只使用缓存。
在创建最终镜像之前，我们首先要针对我们的应用程序运行测试。这就是tester 中发生的情况 。我们将源代码复制到镜像中并运行测试。如果他们通过了，我们继续进入runner。
在ruuner部分：
首先我们复制虚拟环境，该虚拟环境保留了 镜像中所有已安装的依赖项 ，然后我们复制了经过测试的应用程序。现在，我们已经在镜像中拥有所有源，我们将移至应用程序所在的目录，然后进行设置， 以便在镜像启动时运行我们的应用程序。出于安全原因，我们还设置为1001 用户，因为最佳做法告诉我们，永远不要在root 用户下运行容器 。最后两行设置镜像的标签。当使用make 目标运行构建时，这些将被替换/填充， 稍后我们将看到。
为生产而优化的Docker容器
当涉及生产级图像时，我们将要确保它们小巧，安全和快速。我个人最喜欢Distroless 项目中的Python镜像。
它是由Google制作的一组镜像，包含您的应用所需的最低限度，这意味着没有外壳，程序包管理器或任何其他工具会膨胀该镜像并给安全扫描器（如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 具有许多额外的程序包，可以增加攻击面。
自动完成任务的Makefile
一切 Dockerfiles 准备就绪后，让我们使用来自动完成任务 Makefile！我们要做的第一件事是使用Docker构建应用程序。因此，要构建开发映像，我们可以 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- .
|
下一步构建产品: 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- .
|
在存储库中找到Makefile 完整代码清单 ：https： //github.com/MartinHeinz/python-project-blueprint/blob/master/Makefile
CI / CD和GitHub Actions
现在，让我们使用所有这些方便的 make 目标来设置我们的CI / CD。我们将使用 GitHub Actions 和 GitHub Package Registry 来构建我们的管道（作业）并存储我们的图像。那么，这些到底是什么？
- GitHub Actions 是 可以帮助您自动化开发工作流程的作业/管道。您可以使用它们创建单个任务，然后将它们组合到自定义工作流程中，然后在（例如）每次推送存储库或创建发行版时执行这些工作流程。
- GitHub Package Registry 是与GitHub完全集成的软件包托管服务。它允许您存储各种类型的软件包，例如Ruby gems 或 npm 软件包。我们将使用它来存储我们的 Docker 映像。
现在，要使用 GitHub Actions，我们需要创建 工作流 ，这些工作流将基于我们选择的触发器（例如，推送到存储库）执行。这些 工作流 是 YAML 文件，.github/workflows位于我们存储库中的目录中：
.github
└── workflows
├── build-test.yml
└── push.yml
|
在其中，我们将创建2个文件 build-test.yml 和 push.yml。首先，它们build-test.yml 将包含2个作业，这些 作业将在每次推送到存储库时触发，让我们来看一下：
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Run Makefile build for Development
run: make build-dev
|
这是通过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
|
下面Push到Git的配置：
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 }}
|
完整的代码 在这里。
使用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 测试报告程序并使其可执行。接下来，我们使用它来格式化测试套件生成的覆盖率报告，并在最后一行将其发送到 带有存储在存储库机密中的测试报告者ID的CodeClimate。
至于 SonarCloud，我们需要sonar-project.properties 在我们的存储库中创建如下所示的 文件（该文件的值可以在SonarCloud 仪表板的右下角找到 ）：
.organization=martinheinz-github
sonar.projectKey=MartinHeinz_python-project-blueprint
sonar.sources=blueprint
|
在以下位置查看本文文档和代码：github.com/MartinHeinz/python-project-blueprint