Python 2.7 容器镜像

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

注意：尽管本README中的示例使用podman命令，但所有此类命令均可替换为docker，参数保持不变。

镜像概述

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

此容器镜像包含npm工具（参见基础镜像仓库），用户可使用它为Web应用程序安装JavaScript模块。镜像中包含的npm或nodejs版本不做任何保证，这些版本可能随时变更，nodejs仅为支持npm功能而包含。

核心功能与特性

• S2I支持：提供源到镜像构建策略，通过assemble和run脚本自动化应用构建与运行流程
• 多运行策略：支持Gunicorn、Django开发服务器、Python脚本、应用脚本等多种应用启动方式
• 灵活配置：通过环境变量自定义应用入口、依赖安装、服务器参数等
• npm集成：内置npm工具，支持安装JavaScript依赖
• 多平台兼容：支持RHEL、CentOS、Fedora等多种基础镜像
• 热部署支持：Django应用默认支持热部署，Gunicorn可通过配置实现热部署

使用场景

• OpenShift环境：通过S2I快速构建和部署Python 2.7应用
• 外部Docker构建：当S2I不够灵活或在OpenShift外构建时，使用Dockerfile定制镜像
• Web应用开发：支持Django、Flask等Python Web框架，提供Gunicorn生产级服务器
• 脚本应用：运行简单Python脚本或自定义Shell脚本应用

使用方法

在OpenShift中使用

假设使用OpenShift中标签为python:2.7的支持镜像，构建简单python-sample-app应用可通过以下步骤：

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

访问应用：

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

源到镜像(S2I)框架与脚本

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

为支持S2I框架，构建器镜像中包含以下重要脚本：

• /usr/libexec/s2i/assemble：用于生成包含应用制品的新镜像。该脚本接收应用源代码并将其放置到镜像内的适当目录，利用Python应用开发中的常见模式（参见下文环境变量部分）。

• /usr/libexec/s2i/run：作为生成的容器镜像（包含应用制品的新镜像）的默认命令。它根据APP_MODULE、APP_FILE或APP_SCRIPT环境变量的设置运行应用，或自动检测最佳运行方式。

使用Dockerfile构建应用

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

按照以下步骤在Dockerfile中使用Python镜像：

1. 拉取基础构建器镜像

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

2. 获取应用代码

此处使用示例应用[***]

git clone [***] app-src

3. 在容器内准备应用

此步骤通常至少包括：

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

用户可在Dockerfile中显式使用python和pip命令手动完成上述所有步骤，或使用镜像中的S2I脚本。手动方式灵活性最高，但需手动处理模块、软件集合、虚拟环境等；使用S2I脚本可使Dockerfile便于未来无缝切换到更新或不同的平台。

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

FROM registry.access.redhat.com/ubi8/python-27
# 将应用源代码添加到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运行应用，如文档所述。此变量指定WSGI可调用对象，格式为MODULE_NAME:VARIABLE_NAME，其中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）。若未提供，assemble和run脚本将使用应用根目录。

• APP_CONFIG
  Gunicorn配置文件的有效Python文件路径，配置说明参见Gunicorn配置。

• DISABLE_MIGRATE
  设置为非空值可禁止运行生成镜像时执行manage.py migrate。仅影响Django项目。参见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时使用。（隐含UPGRADE_PIP_TO_LATEST以满足Pipenv依赖）。

• PIN_PIPENV_VERSION
  与ENABLE_PIPENV一起设置，用于指定Pipenv版本。若未设置，将安装PyPI上的最新稳定版本。例如PIN_PIPENV_VERSION=2018.11.26将安装pipenv==2018.11.26。

• 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生成的容器镜像按以下优先级顺序执行项目：

1. Gunicorn
   若安装了Gunicorn（通过requirements.txt或setup.py的install_requires列出），则使用Gunicorn WSGI HTTP服务器提供应用。
   若仓库中存在wsgi.py文件，将用作应用入口点，可通过APP_MODULE环境变量覆盖。Django项目默认包含此文件。
   若依赖中同时包含Django和Gunicorn，Django项目将自动通过Gunicorn提供服务。

2. Django开发服务器
   若依赖中包含Django但无Gunicorn，将使用Django开发Web服务器。不建议用于生产环境。

3. Python脚本
   通过APP_FILE环境变量指定Python脚本路径（默认查找app.py），脚本将传递给Python解释器执行以启动应用。

4. 应用脚本文件
   通过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。