FastAPI 部署在Docker的详细过程

Docker 学习

https://www.cnblogs.com/poloyy/p/15257059.html

项目结构

. ├── app │ ├── __init__.py │ └── main.py ├── Dockerfile └── requirements.txt

FastAPI 应用程序 main.py 代码

from typing import Optional from fastapi import FastAPI app = FastAPI() @app.get(“/”) def read_root(): return {“Hello”: “World”} @app.get(“/items/{item_id}”) def read_item(item_id: int, q: Optional[str] = None): return {“item_id”: item_id, “q”: q}

Dockerfile

# 1、从官方 Python 基础镜像开始 FROM python:3.9 # 2、将当前工作目录设置为 /code # 这是放置 requirements.txt 文件和应用程序目录的地方 WORKDIR /code # 3、先复制 requirements.txt 文件 # 由于这个文件不经常更改，Docker 会检测它并在这一步使用缓存，也为下一步启用缓存 COPY ./requirements.txt /code/requirements.txt # 4、运行 pip 命令安装依赖项 RUN pip install –no-cache-dir –upgrade -r /code/requirements.txt # 5、复制 FastAPI 项目代码 COPY ./app /code/app # 6、运行服务 CMD [“uvicorn”, “app.main:app”, “–host”, “0.0.0.0”, “–port”, “80”]

第四步：运行 pip 命令解析

RUN pip install –no-cache-dir –upgrade -r /code/requirements.txt

–no-cache-dir 选项告诉pip不要将下载的包保存在本地，因为只有当pip 将再次运行以安装相同的包时才会这样，但在使用容器时情况并非如此 –no-cache-dir只与pip有关，与 Docker或容器无关 –upgrade选项告诉 pip升级已经安装的软件包 因为上一步复制文件可能会被Docker 缓存检测到，所以这一步也会在Docker 缓存可用时使用 在这一步中使用缓存会在开发过程中一次又一次地构建镜像时节省大量时间，而不是每次都下载并安装所有依赖项

Docker 缓存 

这里有一个重要的技巧Dockerfile，首先只复制依赖项的文件，而不是 FastAPI 应用程序代码

./requirements.txt /code/requirements.txt Docker 和其他工具以增量方式构建这些容器映像，在另一层之上添加一层 从 Dockerfile 的顶部（首行）开始，由 Dockerfile 的每个指令来创建任何文件 Docker 和其他工具在构建镜像时也是用内部缓存 如果文件自上次构建容器镜像后没有更改，则它将重用上次创建的同一层，而不是再次复制文件并从头开始创建一个新的层 仅仅避免文件副本并不一定会改善太多，但是因为它在该步骤中使用了缓存，所以它可以在下一步中使用缓存 例如，它可以将缓存用于安装依赖项的指令

RUN pip install –no-cache-dir –upgrade -r /code/requirements.txt

requirements.txt 不会经常改变，所以通过复制该文件，Docker 可以在该步骤中使用缓存 Docker 将能够使用缓存进行下一步下载和安装这些依赖项，这就是节省大量时间的地方 下载并安装该软件包的依赖关系可能需要几分钟，但使用的缓存将只需要几秒 由于在开发过程中一次又一次地构建容器镜像以检查代码更改是否有效，因此可以节省大量累积时间

./app /code/app

在 Dockerfile 尾部，复制 FastAPI 应用程序代码 由于这是最常更改的内容，因此将其放在最后，在此步骤之后的任何内容都将无法使用缓存

构建 Docker Image

在 Dockerfile 打开命令行

docker build -t myimage .

查看镜像

docker images

启动 docker 容器

docker run -d –name mycontainer -p 80:80 myimage

查看容器

docker ps

访问 127.0.0.1/

访问 127.0.0.1/docs

带有 Gunicorn 的官方 Docker 镜像 – Uvicorn

此镜像包含一个自动调整机制，可根据可用的 CPU 内核设置工作进程的数量 它具有合理的默认值，但仍然可以使用环境变量或配置文件更新所有配置 此镜像上的进程数是根据可用的 CPU 内核自动计算的，它将尝试从 CPU 中榨取尽可能多的性能 但这也意味着，由于进程数取决于容器运行的 CPU，消耗的内存量也将取决于此 因此，如果应用程序消耗大量内存（例如使用机器学习模型），并且服务器有很多 CPU 内核但内存很少，容器最终可能会使用比可用内存更多的内存，这会大大降低性能（甚至崩溃）

官方栗子

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.9 COPY ./requirements.txt /app/requirements.txt RUN pip install –no-cache-dir –upgrade -r /app/requirements.txt COPY ./app /app

应用场景

如果正在使用Kubernetes，并且已经设置了集群级别的复制，就不应该使用此镜像，最好从头开始构建镜像 如果应用程序足够简单，以至于根据 CPU 设置默认进程数效果很好，不想费心在集群级别手动配置复制，并且运行的容器不会超过一个应用程序 或者如果使用Docker Compose进行部署，在单个服务器上运行等

使用 poetry 的 docker image

# 第一阶段:将仅用于安装 Poetry 并从 Poetry 的 pyproject.toml 文件生成带有项目依赖项的 requirements.txt。 FROM tiangolo/uvicorn-gunicorn:python3.9 as requirements-stage # 将 /tmp 设置为当前工作目录;这是我们将生成文件requirements.txt的地方 WORKDIR /tmp # 安装 poetry RUN pip install poetry # 复制 COPY ./pyproject.toml ./poetry.lock* /tmp/ # 生成 requirements.txt RUN poetry export -f requirements.txt –output requirements.txt –without-hashes # 这是最后阶段，在这往后的任何内容都将保留在最终容器映像中 FROM python:3.9 # 将当前工作目录设置为 /code WORKDIR /code # 复制 requirements.txt;这个文件只存在于前一个 Docker 阶段，这就是使用 –from-requirements-stage 复制它的原因 COPY –from=requirements-stage /tmp/requirements.txt /code/requirements.txt # 运行命令 RUN pip install –no-cache-dir –upgrade -r /code/requirements.txt # 复制 COPY ./app /code/app # 运行服务 CMD [“uvicorn”, “app.1_快速入门:app”, “–host”, “0.0.0.0”, “–port”, “80”] 第一阶段 Docker 是 Dockerfile 的一部分，它作为一个临时容器的镜像是仅用于生成一些文件供后面阶段使用 使用 Poetry 时，使用Docker 多阶段构建是有意义的 因为实际上并不需要在最终容器镜像中安装 Poetry 及其依赖项，只需要生成的requirements.txt 文件来安装项目依赖项