FastAPI部署在Docker的详细过程Docker 学习
项⽬结构
.
├── app
│├── __init__.py
│└── main.py
├── Dockerfile
└──
FastAPI 应⽤程序 main.py 代码
from typing import Optional
from fastapi import FastAPI
app = FastAPI()
@("/")
def read_root():
return {"Hello": "World"}
@("/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
python安装教程非常详细
# 2、将当前⼯作⽬录设置为 /code
# 这是放置 ⽂件和应⽤程序⽬录的地⽅
WORKDIR /code
# 3、先复制 ⽂件
# 由于这个⽂件不经常更改，Docker 会检测它并在这⼀步使⽤缓存，也为下⼀步启⽤缓存
COPY ./ /
# 4、运⾏ pip 命令安装依赖项
RUN pip install --no-cache-dir --upgrade -r /
# 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 /
--no-cache-dir 选项告诉pip不要将下载的包保存在本地，因为只有当pip 将再次运⾏以安装相同的包时才会这样，但在使⽤容器时情况并⾮如此--no-cache-dir只与pip有关，与 Docker或容器⽆关
--upgrade选项告诉 pip升级已经安装的软件包
因为上⼀步复制⽂件可能会被Docker 缓存检测到，所以这⼀步也会在Docker 缓存可⽤时使⽤
在这⼀步中使⽤缓存会在开发过程中⼀次⼜⼀次地构建镜像时节省⼤量时间，⽽不是每次都下载并安装所有依赖项
Docker 缓存
这⾥有⼀个重要的技巧Dockerfile，⾸先只复制依赖项的⽂件，⽽不是 FastAPI 应⽤程序代码
./ /
Docker 和其他⼯具以增量⽅式构建这些容器映像，在另⼀层之上添加⼀层
从 Dockerfile 的顶部（⾸⾏）开始，由 Dockerfile 的每个指令来创建任何⽂件
Docker 和其他⼯具在构建镜像时也是⽤内部缓存
如果⽂件⾃上次构建容器镜像后没有更改，则它将重⽤上次创建的同⼀层，⽽不是再次复制⽂件并从头开始创建⼀个新的层
仅仅避免⽂件副本并不⼀定会改善太多，但是因为它在该步骤中使⽤了缓存，所以它可以在下⼀步中使⽤缓存
例如，它可以将缓存⽤于安装依赖项的指令
RUN pip install --no-cache-dir --upgrade -r /
< 不会经常改变，所以通过复制该⽂件，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 ./ /
RUN pip install --no-cache-dir --upgrade -r /
COPY ./app /app
应⽤场景
1. 如果正在使⽤Kubernetes，并且已经设置了集级别的复制，就不应该使⽤此镜像，最好从头开始构建镜像
2. 如果应⽤程序⾜够简单，以⾄于根据 CPU 设置默认进程数效果很好，不想费⼼在集级别⼿动配置复制，并且运⾏的容器不会超过⼀个应⽤程序
3. 或者如果使⽤Docker Compose进⾏部署，在单个服务器上运⾏等
使⽤ poetry 的 docker image
# 第⼀阶段：将仅⽤于安装 Poetry 并从 Poetry 的 l ⽂件⽣成带有项⽬依赖项的 。
FROM tiangolo/uvicorn-gunicorn:python3.9 as requirements-stage
# 将 /tmp 设置为当前⼯作⽬录；这是我们将⽣成⽂件的地⽅
WORKDIR /tmp
# 安装 poetry
RUN pip install poetry
# 复制
COPY ./l ./poetry.lock* /tmp/
# ⽣成
RUN poetry export - -- --without-hashes
# 这是最后阶段，在这往后的任何内容都将保留在最终容器映像中
FROM python:3.9
# 将当前⼯作⽬录设置为 /code
WORKDIR /code
# 复制 ；这个⽂件只存在于前⼀个 Docker 阶段，这就是使⽤ --from-requirements-stage 复制它的原因
COPY --from=requirements-stage / /
# 运⾏命令
RUN pip install --no-cache-dir --upgrade -r /
# 复制
COPY ./app /code/app
# 运⾏服务
CMD ["uvicorn", "app.1_快速⼊门:app", "--host", "0.0.0.0", "--port", "80"]
第⼀阶段 Docker 是 Dockerfile 的⼀部分，它作为⼀个临时容器的镜像是仅⽤于⽣成⼀些⽂件供后⾯阶段使⽤
使⽤ Poetry 时，使⽤Docker 多阶段构建是有意义的
因为实际上并不需要在最终容器镜像中安装 Poetry 及其依赖项，只需要⽣成的 ⽂件来安装项⽬依赖项
poetry 详细教程
到此这篇关于FastAPI 部署在 Docker的⽂章就介绍到这了，更多相关FastAPI 部署在 Docker 内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。