我有两个例子的码头文件,一个是工作的,另一个不是。两者之间的主要区别是基本图像。
简单的python基础图像停靠文件:
# 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
气流基图像对接文件:
# 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
在构建停靠文件之前,请在与poetry lock
文件相同的文件夹中运行pyproject.toml
!
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的映像要快得多,因为依赖项已经被缓存了,但是基于气流的映像将再次尝试并下载所有200个依赖项。从O知道的情况来看,通过指定--mount=type=cache
,目录将存储在映像存储库中,以便下次构建映像时可以重用该目录。通过这个,您可以调整最终的图像大小。
在运行映像时,依赖项是如何显示的?如果我运行docker run -it --user 50000 --entrypoint /bin/bash image
,一个简单的python导入正在处理气流映像,而不是python映像。何时以及如何将依赖关系重新附加到图像?
如果您想尝试一下,这里有一个虚拟项目,可以在本地复制,并在其中运行:https://github.com/ioangrozea/Docker-dummy
发布于 2022-09-09 09:36:37
也许它没有直接回答这个问题,但我认为你试图做的事情从一开始就没有什么意义,所以我建议你完全改变这个方法,尤其是你想要达到的目标在气流官方图像文档中有很好的描述,包括很多要遵循的例子。而你想要达到的结果(不管你多么努力)最终会得到超过200 MB的图像(至少20%),如果你遵循官方文档的话,你可以尝试得到它。
使用诗歌来建立这个形象没有什么意义,也不被推荐(在这种情况下,绝对没有必要使用诗歌)。
请参见评论这里。
虽然在使用其他工具如诗歌或pip工具方面取得了一些成功,但它们并不共享与pip相同的工作流--特别是在约束和需求管理方面。目前不支持通过诗歌或pip工具进行安装。如果您希望使用这些工具安装气流,您应该使用这些约束,并将它们转换为您的工具所需的适当格式和工作流。
诗歌和pip
有着完全不同的解决依赖关系的方法,虽然诗歌是管理小型项目依赖关系的一个很酷的工具,我真的很喜欢诗歌,但是他们固执己见地选择不同的对待库和应用程序,使得不适合管理气流的依赖--这是一个双重的应用程序,开发者可以在此基础上安装和建立库,而诗歌的限制根本不适用于气流。
我在去年给出的谈话中解释了更多,如果你对“为什么”感兴趣的话,你可以看到它。
那-怎么解决你的问题?在本例和诗歌中,不要使用--mount-type
缓存。使用Apache气流和“自定义”选项的多段图像,而不是“扩展”图像。这将给您带来更多的节省--因为您不会在最终的映像中添加“构建要点”(它们本身会将200 MB的图像大小添加到图像大小中,而唯一的方法是将图像分割成两个部分--一个具有“构建要点”并允许您构建Python包,以及一个作为“运行时”使用的部分,在其中只复制" build“python库。
这正是Airfow官方Python映像所采用的方法--它对重建的大小和速度进行了高度优化,尽管其内部结构非常复杂,但您高度优化、完全自定义的映像的实际构建就像下载气流Dockerfile
并运行正确的docker buildx build . --build-arg ... --build-arg ...
命令一样简单--气流Dockerfile
将为您完成所有优化--尽可能少的图像,并且它还允许您重用构建缓存--尤其是如果您使用buildkit --这是一种现代的、光滑的、非常优化的图像构建方式(气流Dockerfile需要像气流2.3一样构建组件)。
您可以看到关于如何构建自定义映像这里的所有细节-在这里,您有大量的例子和解释,为什么它的工作方式,以及你可以得到什么样的优化。关于如何添加依赖项、python包等,有一些例子。虽然这非常复杂,但您的图像看起来很复杂,这就是我建议您遵循这条路线的原因。
此外,如果你对推理的其他部分感兴趣,那么你可以在2020年气流峰会上观看我的谈话 --尽管演讲是在两年前进行的,一些小细节也发生了变化,但关于如何和为什么用我们在气流中所做的方式来构建图像的解释仍然非常有力。它变得简单一点,因为谈话是给予(即,你唯一不需要的是Dockerfile,没有充分的气流源是需要的),你需要使用buildkit -所有其余的保持不变。
https://stackoverflow.com/questions/73650173
复制相似问题