Deploying Data Science Tools: Part 1

部署数据科学工具：第一部分 | Towards Data Science

数据科学

部署数据科学工具：第一部分

让数据科学代码在任何地方运行

Jarom Hulet

2026年10月16日

11分钟阅读

更喜欢我们在Google上的内容

分享

照片由Ludovic Delot通过Pexels提供

如果森林里有一棵树倒下而没有人听到，它会发出声音吗？如果你开发了一个出色的数据科学工具但没有人能使用它，它是否具有价值？

虽然一个运行在你笔记本电脑上的模型或优化工具可以提供一些价值，但其影响力将仅限于你的时间以及你向他人传达输出结果的能力。而部署后的工具可以让许多人访问其生成的宝贵预测和/或建议。这将你从中间移除，直接赋能业务合作伙伴、客户和同事使用工具。

这是一系列多篇文章，我们将从我笔记本电脑上的源代码出发，实现优化工具的完整CI/CD部署。本文将重点解决经典的"在我电脑上能运行，但在你电脑上不行"的挑战。

我们将涵盖的具体主题包括：

• 从GitHub克隆代码
• Python虚拟环境
• Docker和容器化

我们要部署的示例工具简介

我们部署的工具解决一个被称为"切割问题"的挑战。几年前，我写过一篇讨论该问题及其解决方案的文章——如果你想深入了解，可以查看链接。

这个工具（我称之为切割库存规划器）使用线性规划和一个基于FastAPI的简单用户界面，提供最优切割方案，以最小化你需要购买的库存件数。

让我们通过工具运行一个示例来说明。假设你想制作一把椅子，需要进行多次切割。你可以购买8英尺长的库存材料，而椅子需要各种切割长度。你可以使用简单的用户界面输入库存长度和切割清单，点击"生成切割方案"按钮，立即在屏幕上看到最优切割方案。虽然不花哨，但这是一个很好的简单用例，适合我们进行部署。

切割库存规划器工具截图 - 作者提供

在GitHub上共享代码

部署（宽泛地理解这个词）工具最简单的方式是与目标用户共享代码。直接共享源代码的最佳方式是通过版本控制和云存储工具如Git/GitHub。GitHub允许用户轻松地从编码项目中复制文件和文件结构。这并不是Git/GitHub教程，但让我们快速浏览用户如何获取优化工具的访问权限。然后我们将讨论这种方法的所有缺点。

如果你想跟随示例，这里是库存切割规划器代码的链接。

进入仓库后，导航到绿色的"<> Code"按钮。复制提供的链接。我们将使用这个链接告诉Git要克隆哪个仓库。

作者提供图片

打开终端，导航到你想存放仓库的目录，执行以下代码行（在'git clone'后使用复制的URL）：git clone https://github.com/jaromhulet/cutting-stock-planner.git

现在你已经在本地拥有了我代码的完美副本！代码克隆完成后，导航到仓库的根目录并运行下面看到的uvicorn命令——这将在本地运行用户界面。

你可以在网络浏览器中使用此URL访问用户界面：http://localhost:8000/

使用 GitHub 共享源代码并非完全不好，实际上它对编写代码非常有帮助 —— 尤其是多人协作时。但作为部署工具，它存在许多缺陷。其主要问题在于几乎所有部署责任（和挑战）都落在了用户身上。

下表列出了这些挑战并提供补充说明：

| 缺点 | 附加说明 | |------|----------| | 用户需要在机器上安装 Git 并克隆仓库 | 安装 Git 和克隆仓库并不困难，但需要一定的技术知识，对许多用户来说可能令人望而生畏。此外，这种操作也不够便捷，这成为技术用户采用该工具的额外障碍。 | | 用户需要在机器上安装正确版本的 Python | 不仅用户机器需要安装 Python（需要额外下载和安装），还必须安装特定版本的 Python。 | | 用户需要在机器上安装相同或兼容的 Python 包版本 | 如果包版本不匹配，应用程序可能会崩溃或行为异常。用户必须理解包版本要求并确保本地机器满足这些条件。虽然为该应用程序匹配包版本可以避免错误，但可能导致用户机器上其他有冲突包版本需求的应用程序出现问题。 | | 用户需要提供足够的计算资源 | 用户需要本地运行应用程序，这意味着计算资源必须由用户自己提供。对于这个简单的示例应用来说，这并不是大问题。但对于许多生产工具来说，本地运行可能困难甚至不可能。 |

使用 Python 虚拟环境

现在我们理解仅共享代码存在一些显著缺陷。让我们讨论一种 Python 技术 —— 虚拟环境，它能够解决仅克隆仓库的一些问题。虽然虚拟环境是朝着正确方向迈出的一步，但我们也会看到它本身也存在局限性。

注意：其他编程语言也有环境隔离的解决方案，但由于 Python 在数据科学领域应用广泛，本文将重点介绍 Python 虚拟环境。

我曾说过 Python 虚拟环境能改善问题，但它们到底是什么？Python 虚拟环境是一个包含 Python 解释器和独立 Python 包集合的隔离目录。它基于你机器上的特定 Python 安装创建，因此虚拟环境本身通常无法解决需要特定 Python 版本的问题。但这种隔离性确实允许用户在虚拟环境中进行更改，而不会影响其他项目、应用程序或代码库的设置或执行。

让我们通过一个简单的例子来说明虚拟环境的优势。假设我们有代码A，它是上个月开发的，使用的是FastAPI 0.141.1版本（就像我们的应用）。我们还有代码B，它是两年前开发的，使用的是FastAPI 0.120.0版本。目前我们电脑上安装的是FastAPI 0.141.0版本，但今天需要运行代码B。我们必须卸载FastAPI 0.141.0并安装FastAPI 0.120.0——这有点烦人。明天我们又需要运行代码A，这时又得切换回FastAPI 0.141.0！现在想象我们有多个代码库和多个软件包，这个问题会迅速变得令人头疼。

虚拟环境创建了相互隔离的区域，使不同配置可以共存而不会相互冲突。下图展示了虚拟环境如何帮助我们更轻松地管理运行代码A和代码B（参考我们之前的例子）而不会产生冲突。

虽然这不是一个教程，但我仍然想提供一些关于如何在虚拟环境中设置、激活和安装软件包的信息。下图展示了在Windows命令提示符中如何操作——不同操作系统会有略微不同的语法。

现在我们已经了解了虚拟环境是什么，以及如何利用它们帮助在其他机器上运行代码，让我们总结一下GitHub代码复制与虚拟环境的对比。

| 要求 | GitHub + 虚拟环境 | GitHub 仅限 | |-----------------------|------------------|------------------| | 需要安装Git吗？ | 是 | 是 | | 需要克隆仓库吗？ | 是 | 是 | | 需要安装Python吗？ | 是 | 否 | | 需要Python版本匹配代码要求吗？ | 是 | 否 | | 需要用户计算资源运行代码吗？ | 是 | 否 | | 需要在基础Python环境中安装应用依赖吗？ | 否！ | 是 |

虚拟环境帮助用户更系统地管理软件包依赖，但仍然需要用户自行在本机配置所需环境。在下一节中，我们将探讨Docker如何通过容器化技术将环境配置的大部分责任从用户手中转移。

使用Docker的容器化

到目前为止，我们讨论的都是需要用户自行配置环境才能在其他机器上运行应用的方法。Docker采用了不同的思路。它允许我们将代码及其依赖打包成容器镜像。然后我们可以将这个镜像分享给用户，用户可以通过Docker从中创建和运行容器。我们不再需要用户安装Python、配置虚拟环境并安装所需包，而是提供一个即开即用的环境。

Docker非常强大，解决了我们在尝试让代码在其他计算机上运行时遇到的许多问题。正因为如此，让我们花些时间更深入了解Docker。我们将从定义和讨论Dockerfile、镜像和容器开始。

Dockerfile

Dockerfile是一组用于创建Docker镜像（下一节将详细讲解）的指令。这些指令包括使用哪个Python版本、在哪里找到源代码以及从哪里获取包版本需求等。如果你还不熟悉Docker，这些可能暂时不太容易理解。让我们通过我们股票切割应用的简单Dockerfile来获得一些实际操作经验。

这是我们的应用的Dockerfile，我们将逐行分析以全面理解它的功能。

dockerfile

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

FROM python:3.12-slim：这行代码实际上是在告诉 Docker 以另一个已有的预构建镜像作为基础，该镜像包含 Python 3.12。这是一个官方的 Python Docker 镜像。可以将其理解为对现有配方进行修改。比如你喜欢在最喜欢的煎饼配方中添加香蕉，而不是自己重新发明一个包含香蕉的煎饼配方，你只需要使用别人已有的配方并添加自己的定制原料。在这个例子中，python:3.12-slim 是我们的起始配方，Dockerfile 的其余部分则添加了应用程序所需的其他内容。

WORKDIR /app：告诉 Docker 在镜像内部创建并使用 '/app' 作为工作目录。

COPY requirements.txt .：指示 Docker 将 requirements.txt 文件复制到镜像中。'.' 表示将文件复制到当前工作目录，该目录在上一行中已设置为 '/app'。

RUN pip install --no-cache-dir -r requirements.txt：指示 Docker 在构建镜像时安装 requirements.txt 中定义的包。这是 Docker 自动重建我们之前需要手动管理的包环境的地方，例如在克隆仓库和使用虚拟环境时。

COPY app.py .：告诉 Docker 将 app.py 文件复制到工作目录中。

EXPOSE 8000：告诉 Docker 应用程序预期在 8000 端口监听。这并不会实际使该端口在宿主机上可访问；端口映射是在运行容器时建立的。

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]：告诉 Docker 在从镜像启动容器时在终端运行这行代码。该命令会启动我们库存切割优化器的用户界面。

镜像

Docker 镜像是包含运行应用程序所需代码、依赖项和其他包的打包集合。它们是根据 Dockerfile 提供的指令创建的。Docker 镜像是可以共享的，以便在其他计算机上运行应用程序。

可以使用 docker build 命令轻松创建镜像。下图展示了我如何从 Dockerfile 'cutting-stock' 创建库存切割工具的镜像。

容器

容器只是镜像的运行实例。它们是正在运行的应用程序。我们无法仅通过 Dockerfile 或镜像解决库存切割问题，因为它们本身都不是正在运行的应用程序。容器是从镜像创建的，并提供运行环境，使我们的应用程序可以使用宿主机的计算资源执行。

要在另一台机器上运行我们的应用程序容器，要求是该机器已安装 Docker 并且有足够的计算资源来运行应用程序。Docker 会为我们处理其余的环境配置。

让我们看看如何使用 Docker 运行我们的应用程序。与创建镜像一样，Docker 使运行容器变得简单。

如果你已经创建了镜像（它已经存在于 Docker 的镜像存储库中），只需运行以下命令即可。如果镜像是别人共享给你的，请导航到镜像保存的位置，并首先运行以下命令将其添加到镜像存储库中：docker load -i cutting-stock.tar

现在，你可以在网页浏览器中访问这个链接：http://localhost:8000/

通过这个链接，你可以访问通过Docker容器运行的股票切割工具。它仍然在本地运行，界面与我们使用其他方法运行时完全相同。不同的是我们到达这里的方式：我们不需要安装Python或特定版本的软件包。我们只需要在本机安装Docker，获取镜像，并在终端中输入一行代码。这就是Docker的力量！

## 最终对比

我们已经比较了三种让代码在其他机器上运行的方法：直接从GitHub克隆代码、从GitHub克隆代码并在虚拟环境中运行、以及通过Docker容器运行代码。每种解决方案都比前一种有所改进。Docker容器是今天的胜者，只需用户提供计算资源、安装Docker、接收镜像并在终端中运行一两行命令即可。

以下是对比的总结表格：

| Docker | 否 | 需要在用户机器上安装Docker |

## 我们如何进一步改进？

在本文中探讨的解决方案中，本地运行Docker容器是实现代码可移植性的最佳方案。但它仍然对用户有一些特定要求。在下一篇文章中，我们将探讨如何通过云服务让应用实现可访问性，这只需要互联网连接和网页浏览器（几乎所有人都具备）。敬请期待！