将你的Python项目全面自动化.docx

将你的Python项目全面自动化.docx

《将你的Python项目全面自动化.docx》由会员分享，可在线阅读，更多相关《将你的Python项目全面自动化.docx（9页珍藏版）》请在冰豆网上搜索。

将你的Python项目全面自动化

如何将你的Python项目全面自动化

[导读]每个项目——无论你是在从事Web应用程序、数据科学还是AI开发——都可以从配置良好的CI/CD、Docker镜像或一些额外的代码质量工具（如CodeClimate或SonarCloud）中获益。

所有这些都是本文要讨论的内容，我们将看看如何将它们添加到Python项目中！

每个项目——无论你是在从事Web应用程序、数据科学还是AI开发——都可以从配置良好的CI/CD、Docker镜像或一些额外的代码质量工具（如CodeClimate或SonarCloud）中获益。

所有这些都是本文要讨论的内容，我们将看看如何将它们添加到Python项目中！

· 

在写这篇文章之前，我还写了一篇“Python项目终极设置”，读者感兴趣的话，可以先读下那一篇：

https:

//martinheinz.dev/blog/14。

· 

GitHub库中提供了完整的源代码和文档：

开发环境中可调试的Docker容器

有些人不喜欢Docker，因为容器很难调试，或者构建镜像需要花很长的时间。

那么，就让我们从这里开始，构建适合开发的镜像——构建速度快且易于调试。

为了使镜像易于调试，我们需要一个基础镜像，包括所有调试时可能用到的工具，像bash、vim、netcat、wget、cat、find、grep等。

它默认包含很多工具，没有的也很容易安装。

这个镜像很笨重，但这不要紧，因为它只用于开发。

你可能也注意到了，我选择了非常具体的映像——锁定了Python和Debian的版本——我是故意这么做的，因为我们希望最小化Python或Debian版本更新（可能不兼容）导致“破坏”的可能性。

作为替代方案，你也可以使用基于Alpine的镜像。

然而，这可能会导致一些问题，因为它使用musllibc而不是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镜像中是不存在的。

· 

你可以在DockerHub中找到这个镜像：

· 

你也可以在base.Dockerfile 中查看其非常简单的`Dockerfile`：

那么，我们在这个最终镜像中要做的是——首先我们从tester镜像中复制虚拟环境，其中包含所有已安装的依赖项，接下来我们复制经过测试的应用程序。

现在，我们的镜像中已经有了所有的资源，我们进入应用程序所在的目录，然后设置ENTRYPOINT，以便它在启动镜像时运行我们的应用程序。

出于安全原因，我们还将USER设置为1001，因为最佳实践告诉我们，永远不要在root用户下运行容器。

最后两行设置镜像标签。

它们将在使用make目标运行构建时被替换/填充，稍后我们将看到。

针对生产环境优化过的Docker容器

当涉及到生产级镜像时，我们会希望确保它们小而安全且速度快。

对于这个任务，我个人最喜欢的是来自Distroless项目的Python镜像。

可是，Distroless是什么呢？

这么说吧——在一个理想的世界里，每个人都可以使用FROMscratch构建他们的镜像，然后作为基础镜像（也就是空镜像）。

然而，大多数人不愿意这样做，因为那需要静态链接二进制文件，等等。

这就是Distroless的用途——它让每个人都可以FROMscratch。

好了，现在让我们具体描述一下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镜像：

dockerrun--entrypoint=sh-tigcr.io/distroless/python3-debian10:

debug

所有操作都只需一条命令

所有的Dockerfiles都准备好了，让我们用Makefile实现自动化！

我们首先要做的是用Docker构建应用程序。

为了构建dev映像，我们可以执行makebuild-dev，它运行以下目标:

# The binary to build （just the basename）.

MODULE :

= blueprint

# Where to push the docker image.

REGISTRY ?

= 

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（运行gitdescribe创建）替换dev.Dockerfile底部的标签，然后运行dockerbuild。

接下来，使用makebuild-prodVERSION=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