centos/python-38-centos7 Docker 镜像 - 轩辕镜像 | Docker 镜像高效稳定拉取服务

Python 3.8 容器镜像

此容器镜像包含Python 3.8，作为您Python 3.8应用程序的S2I（源到镜像）基础镜像。用户可选择基于RHEL或CentOS的构建器镜像。RHEL镜像可在Red Hat容器目录获取，CentOS镜像可在Quay.io获取，Fedora镜像可在Fedora Registry获取。生成的镜像可使用podman或docker运行。

注意：虽然本README中的示例使用podman，但您可以将任何此类调用替换为docker，参数保持不变。

描述

作为容器提供的Python 3.8是一个基础平台，用于构建和运行各种Python 3.8应用程序和框架。Python是一种易于学习、功能强大的编程语言，它具有高效的高级数据结构和简单而有效的面向对象编程方法。Python优雅的语法、动态类型以及解释型特性，使其成为在大多数平台的许多领域中进行脚本编写和快速应用开发的理想语言。

此容器镜像包含npm工具（参见基础镜像仓库），因此用户可使用它为Web应用程序安装JavaScript模块。不保证镜像中包含特定版本的npm或nodejs；这些版本可能随时更改，包含nodejs仅为使npm正常工作。

在OpenShift中使用

以下假设您使用受支持的镜像，可通过OpenShift中的python:3.8镜像流标签获取。在OpenShift中构建简单的python-sample-app应用程序可通过以下步骤实现：

oc new-app python:3.8~[***]

访问应用程序：

$ oc get pods
$ oc exec <pod> -- curl 127.0.0.1:8080

源到镜像（S2I）框架和脚本

此镜像支持OpenShift中的源到镜像（S2I）策略。源到镜像是一个OpenShift框架，可轻松编写接收应用程序源代码作为输入、使用构建器镜像（如本Python容器镜像）并生成运行组装应用程序的新镜像的镜像。

为支持源到镜像框架，构建器镜像中包含重要脚本：

• 镜像内的/usr/libexec/s2i/assemble脚本用于生成包含应用程序 artifacts 的新镜像。该脚本接收给定应用程序的源代码，并将其放置到镜像内的适当目录中。它利用Python应用程序开发中的一些常见模式（见下文环境变量部分）。
• /usr/libexec/s2i/run脚本被设置为生成的容器镜像（包含应用程序 artifacts 的新镜像）中的默认命令。它根据APP_MODULE、APP_FILE或APP_SCRIPT环境变量的设置运行应用程序，或尝试自动检测最佳运行方式。

使用Dockerfile构建应用程序

与源到镜像策略相比，使用Dockerfile是构建包含应用程序的Python容器镜像的更灵活方式。当源到镜像不够灵活或在OpenShift环境外构建镜像时，使用Dockerfile。

要在Dockerfile中使用Python镜像，请按照以下步骤操作：

1. 拉取基础构建器镜像

podman pull registry.access.redhat.com/ubi8/python-38

2. 拉取应用程序代码

此处使用可从[***]

git clone [***] app-src

3. 在容器内准备应用程序

此步骤通常至少包括以下部分：

• 将应用程序源代码放入容器
• 安装依赖项
• 在生成的镜像中设置默认命令

对于这三个部分，用户可以手动设置并在Dockerfile中显式使用python和pip命令，或使用镜像内的源到镜像脚本。

手动方式灵活性最高，但要求您知道如何手动处理模块或软件集合、如何使用正确版本的Python设置虚拟环境等。另一方面，使用源到镜像脚本可使您的Dockerfile为将来无缝切换到更新或不同平台做好准备。

要使用源到镜像脚本并通过Dockerfile构建镜像，请创建包含以下内容的Dockerfile：

FROM registry.access.redhat.com/ubi8/python-38
# 将应用程序源代码添加到assemble脚本期望的目录，并设置权限使容器无需root权限运行
USER 0
ADD app-src /tmp/src
RUN chown -R 1001:0 /tmp/src
USER 1001
# 安装依赖项
RUN /usr/libexec/s2i/assemble
# 设置生成镜像的默认命令
CMD /usr/libexec/s2i/run

4. 从准备好的Dockerfile构建新镜像

podman build -t python-app .

5. 运行包含最终应用程序的镜像

podman run -d python-app

环境变量

要设置这些环境变量，您可以将它们作为键值对放入源代码仓库中的.s2i/environment文件。

• APP_SCRIPT

  用于从脚本文件运行应用程序。应为脚本文件的路径（默认值为app.sh，除非设置为null），运行此脚本以启动应用程序。

• APP_FILE

  用于从Python脚本运行应用程序。应为Python文件的路径（默认值为app.py，除非设置为null），将此文件传递给Python解释器以启动应用程序。

• APP_MODULE

  用于使用Gunicorn运行应用程序，如此处所述。此变量使用MODULE_NAME:VARIABLE_NAME模式指定WSGI可调用对象，其中MODULE_NAME是模块的完整点分路径，VARIABLE_NAME指指定模块内的WSGI可调用对象。如果未指定，Gunicorn将查找名为application的WSGI可调用对象。

  如果未提供APP_MODULE，run脚本将在项目中查找wsgi.py文件，如果存在则使用它。

  如果使用setup.py安装应用程序，MODULE_NAME部分可从中读取。例如，参见setup-test-app。

• APP_HOME

  此变量可用于指定包含要运行应用程序的子目录。此变量指向的目录需要包含wsgi.py（用于Gunicorn）或manage.py（用于Django）。

  如果未提供APP_HOME，assemble和run脚本将使用应用程序的根目录。

• APP_CONFIG

  有效的Python文件路径，包含Gunicorn配置。

• DISABLE_MIGRATE

  将此变量设置为非空值可禁止在运行生成的镜像时执行manage.py migrate。这仅影响Django项目。有关在OpenShift环境中如何/何时运行数据库迁移的建议，请参见OpenShift博客上Django文章的“处理数据库迁移”部分（[***]

• DISABLE_COLLECTSTATIC

  将此变量设置为非空值可禁止在构建期间执行manage.py collectstatic。这仅影响Django项目。

• DISABLE_SETUP_PY_PROCESSING

  将此设置为非空值可跳过setup.py脚本的处理，如果您在requirements.txt中使用-e .触发其处理，或不希望将应用程序安装到site-packages目录中。

• ENABLE_PIPENV

  设置此变量以使用Pipenv（高级Python打包工具）管理应用程序的依赖项。仅当项目包含格式正确的Pipfile和Pipfile.lock时使用。

• PIN_PIPENV_VERSION

  与ENABLE_PIPENV一起设置此变量以使用特定版本的Pipenv。如果未设置，将安装PyPI上的最新稳定版本。例如PIN_PIPENV_VERSION=2018.11.26将安装pipenv==2018.11.26。

• ENABLE_MICROPIPENV

  设置此变量以使用micropipenv（pip的轻量级包装器，支持requirements.txt、Pipenv和Poetry锁定文件，或转换为pip-tools兼容输出）。专为容器化Python应用程序设计。仅适用于Python 3镜像。

• ENABLE_INIT_WRAPPER

  将此变量设置为非空值以使用init包装器。这对于无法回收僵尸进程的服务器（如Django开发服务器或Tornado）很有用。此选项可与APP_SCRIPT或APP_FILE一起使用。对于通过APP_MODULE使用的Gunicorn，由于Gunicorn可正确回收僵尸进程，因此从不应用此选项。

• PIP_INDEX_URL

  设置此变量以使用自定义索引URL或镜像下载构建过程中所需的包。这会影响requirements.txt中列出的包。它还会影响pipenv和micropipenv的安装以及容器中pip的更新，但如果在自定义索引中未找到，容器将尝试从上游PyPI安装/更新它们。

• UPGRADE_PIP_TO_LATEST

  将此变量设置为非空值可在安装任何Python包之前将pip程序及相关Python包（setuptools和wheel）升级到最新版本。如果未设置，将使用平台为所使用的Python版本包含的默认版本。

• WEB_CONCURRENCY

  设置此变量以更改工作进程数的默认设置。默认情况下，此值设置为可用核心数乘以2，上限为12。

源代码仓库布局

您无需更改现有Python项目仓库中的任何内容。但是，如果存在以下文件，它们将影响构建过程的行为：

• requirements.txt

  要使用pip安装的依赖项列表。格式文档见此处。

• Pipfile

  requirements.txt的替代品，项目目前处于积极设计和开发中，文档见此处。设置ENABLE_PIPENV环境变量为true以处理此文件。

• setup.py

  配置项目的各个方面，包括依赖项的安装，文档见此处。对于大多数项目，只需使用requirements.txt或Pipfile即可。设置DISABLE_SETUP_PY_PROCESSING环境变量为true以跳过此文件的处理。

运行策略

s2i-python生成的容器镜像按以下优先级顺序执行项目：

• Gunicorn

  如果安装了Gunicorn WSGI HTTP服务器，则使用它来提供应用程序。可通过在requirements.txt中列出或在setup.py的install_requires部分包含来安装。

  如果仓库中存在名为wsgi.py的文件，它将用作应用程序的入口点。可通过环境变量APP_MODULE覆盖此设置。Django项目默认包含此文件。

  如果requirements中同时包含Django和Gunicorn，您的Django项目将自动使用Gunicorn提供服务。

• Django开发服务器

  如果requirements中包含Django但未包含Gunicorn，则使用Django的开发Web服务器提供应用程序。但不建议在生产环境中使用。

• Python脚本

  当通过APP_FILE环境变量指定Python脚本路径时使用（如果存在app.py文件，则默认使用）。脚本将传递给常规Python解释器以启动应用程序。

• 应用程序脚本文件

  最通用的应用程序执行方式。当通过APP_SCRIPT环境变量指定可执行脚本文件路径时使用（如果存在app.sh文件，则默认使用）。直接执行脚本以启动应用程序。

热部署

如果使用Django，热部署将开箱即用。

要在使用Gunicorn时启用热部署，请确保仓库中包含Gunicorn配置文件，并将reload选项设置为true。确保通过APP_CONFIG环境变量指定您的配置。

要在运行中的容器中更改源代码，使用podman（或docker）的exec命令：

podman exec -it <CONTAINER_ID> /bin/bash

进入运行中的容器后，当前目录设置为/opt/app-root/src，即源代码所在位置。

另请参见

Dockerfile和其他源代码可在[***]Dockerfile，RHEL7的名为Dockerfile.rhel7，RHEL8的名为Dockerfile.rhel8，Fedora的名为Dockerfile.fedora。