python - Poetry 和 buildkit mount=type=cache 在 Airflow 图像上构建时不起作用

Question

我有 2 个 docker 文件示例，一个可以工作，另一个不能。两者之间的主要区别在于基础图像。

简单的 python 基础镜像 docker 文件:

# syntax = docker/dockerfile:experimental
FROM python:3.9-slim-bullseye

RUN apt-get update -qy && apt-get install -qy \
    build-essential tini libsasl2-dev libssl-dev default-libmysqlclient-dev gnutls-bin

RUN pip install poetry==1.1.15
COPY pyproject.toml .
COPY poetry.lock .
RUN poetry config virtualenvs.create false
RUN --mount=type=cache,mode=0777,target=/root/.cache/pypoetry poetry install

Airflow 基础镜像 docker 文件:

# syntax = docker/dockerfile:experimental
FROM apache/airflow:2.3.3-python3.9
USER root
RUN apt-get update -qy && apt-get install -qy \
    build-essential tini libsasl2-dev libssl-dev default-libmysqlclient-dev gnutls-bin

USER airflow
RUN pip install poetry==1.1.15
COPY pyproject.toml .
COPY poetry.lock .
RUN poetry config virtualenvs.create false
RUN poetry config cache-dir /opt/airflow/.cache/pypoetry
RUN --mount=type=cache,uid=50000,mode=0777,target=/opt/airflow/.cache/pypoetry poetry install

在构建 docker 文件之前，在与 pyproject.toml 文件相同的文件夹中运行 poetry lock!

pyproject.toml 文件:

[tool.poetry]
name = "Airflow-test"
version = "0.1.0"
description = ""
authors = ["Lorem ipsum"]

[tool.poetry.dependencies]
python = "~3.9"
apache-airflow = { version = "2.3.3", extras = ["amazon", "crypto", "celery", "postgres", "hive", "jdbc", "mysql", "ssh", "slack", "statsd"] }
prometheus_client = "^0.8.0"
isodate = "0.6.1"
dacite = "1.6.0"
sqlparse = "^0.3.1"
python3-openid = "^3.1.0"
flask-appbuilder = ">=3.4.3"
alembic = ">=1.7.7"
apache-airflow-providers-google = "^8.1.0"
apache-airflow-providers-databricks = "^3.0.0"
apache-airflow-providers-amazon = "^4.0.0"
pendulum = "^2.1.2"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

为了构建图像，这是我使用的命令:

DOCKER_BUILDKIT=1 docker build --progress=plain -t airflow-test -f Dockerfile . 

对于这两个图像，他们第一次构建 poetry install 将需要下载所有依赖项。有趣的是，我第二次构建图像​​时，基于 python 的图像要快得多，因为依赖项已经缓存，但是基于 airflow 的图像将再次尝试下载所有 200 个依赖项。据 O 所知，通过指定 --mount=type=cache 该目录将存储在图像存储库中，以便下次构建图像​​时可以重复使用。通过这种方式，您可以修剪最终图像的大小。

运行镜像时，依赖是怎么出现的？如果我运行 docker run -it --user 50000 --entrypoint/bin/bash image 一个简单的 python 导入正在 Airflow 图像上工作，而不是在 python 图像上工作。何时以及如何将依赖项重新附加到图像？

如果您想尝试一下，这里有一个可以在本地克隆并试用的虚拟项目: https://github.com/ioangrozea/Docker-dummy

Answer 1

也许它没有直接回答问题，但我认为你试图做的事情首先没有什么意义，所以我建议你完全改变方法，特别是你想要实现的是The Airflow Official image documentation 中有很好的描述，包括大量示例。如果您遵循官方文档，您想要实现的目标(无论您多么努力)最终会得到比您尝试获得的图像大 200 MB(至少 20%)的图像。

使用诗歌来构建该图像意义不大，不推荐(在这种情况下绝对没有必要使用诗歌)。

见评论here .

While there are some successes with using other tools like poetry orpip-tools, they do not share the same workflow as pip - especiallywhen it comes to constraint vs. requirements management. Installingvia Poetry or pip-tools is not currently supported. If you wish toinstall airflow using those tools you should use the constraints andconvert them to appropriate format and workflow that your toolrequires.

Poetry 和 pip 解决依赖关系的方式完全不同，而 poetry 是管理小型项目依赖关系的好工具，我真的很喜欢 poetry，他们坚持选择以不同的方式对待库和应用程序，使得它不适合管理 Airflow 的依赖项，Airflow 既是要安装的应用程序，也是供开发人员构建的库，而 Poetry 的局限性根本不适用于 Airflow。

我在 talk 中对此进行了更多解释我去年给了，如果你对“为什么”感兴趣，你可以看看。

那么 - 如何解决您的问题？不要在这种情况下使用 --mount-type 缓存和诗歌。使用 Apache Airflow 的多段图像和“自定义”选项而不是“扩展”图像。这将为您节省更多 - 因为您不会将“build-essentials”添加到您的最终图像中(他们自己将图像大小增加 ~200 MB，摆脱它们的唯一方法是拆分您的图像分为两个部分 - 一个具有“build-essentials”并允许您构建 Python 包，另一个用作“运行时”，您只复制“build”python 库。

这正是 Airfow 官方 Python 镜像所采用的方法——它针对重建的大小和速度进行了高度优化，虽然它的内部结构相当复杂，但高度优化的、完全自定义的镜像的实际构建就像下载airflow Dockerfile 并运行正确的 docker buildx build 。 --build-arg ... --build-arg ... 命令 - Airflow Dockerfile 将为您完成所有优化 - 从而产生尽可能小的图像，它还允许您重用构建缓存 - 特别是如果您使用 buildkit - 这是构建图像的现代、灵活且非常优化的方式(从 Airflow 2.3 开始，Airflow Dockerfile 需要 buildkit)。

您可以看到有关如何构建自定义图像的所有详细信息 here - 你有很多例子和解释为什么它以它的方式工作以及你可以获得什么样的优化。有关于如何添加依赖项、python 包等的示例。虽然这非常复杂，但您似乎对图像做了复杂的事情，这就是我建议您遵循该路线的原因。

此外，如果您对推理的其他部分感兴趣，可以观看我的 talk来自 Airflow 峰会 2020 - 虽然演讲是在 2 年前进行的并且一些小细节发生了变化，但关于如何以及为什么以我们在 Airflow 中的方式构建图像的解释仍然非常有效。自从演讲结束后，它变得更简单了一些(即你唯一不需要的是 Dockerfile，不需要完整的 Airflow 源)并且你需要使用 buildkit - 然而其余的都保持不变。