From dcbeab1c7b8715172913af7ba86e87b1d7621b2f Mon Sep 17 00:00:00 2001 From: wjunlu Date: Mon, 23 Oct 2023 10:09:20 +0800 Subject: [PATCH] Add oEEP-0014 for publishing AI container images and modify oEEP-0005. --- ...21\345\270\203\346\265\201\347\250\213.md" | 27 ++++++++-- ...34\345\203\217\350\247\204\350\214\203.md" | 50 +++++++++++++++++++ 2 files changed, 72 insertions(+), 5 deletions(-) create mode 100644 "oEEP/oEEP-0014 openEuler AI\345\256\271\345\231\250\351\225\234\345\203\217\350\247\204\350\214\203.md" diff --git "a/oEEP/oEEP-0005 openEuler\345\256\230\346\226\271\345\256\271\345\231\250\351\225\234\345\203\217\345\217\221\345\270\203\346\265\201\347\250\213.md" "b/oEEP/oEEP-0005 openEuler\345\256\230\346\226\271\345\256\271\345\231\250\351\225\234\345\203\217\345\217\221\345\270\203\346\265\201\347\250\213.md" index 934548a..c35ca2a 100644 --- "a/oEEP/oEEP-0005 openEuler\345\256\230\346\226\271\345\256\271\345\231\250\351\225\234\345\203\217\345\217\221\345\270\203\346\265\201\347\250\213.md" +++ "b/oEEP/oEEP-0005 openEuler\345\256\230\346\226\271\345\256\271\345\231\250\351\225\234\345\203\217\345\217\221\345\270\203\346\265\201\347\250\213.md" @@ -12,7 +12,7 @@ ## 动机/问题描述: ### 初衷 -openEuler官方网站目前仅在发布了容器镜像的原始文件，如果未上传至任何三方docker镜像仓，开发者们不得不通过如下命令进行加载： +目前仅在openEuler官方网站发布了容器镜像的原始文件，如果未上传至任何三方docker镜像仓，开发者们不得不通过如下命令进行加载： ``` wget https://repo.openeuler.org/openEuler-20.03-LTS/docker_img/aarch64/openEuler-docker.aarch64.tar.xz docker load < openEuler-docker.aarch64.tar.xz @@ -36,11 +36,16 @@ docker run -ti openeuler-20.03-lts bash - 作为OpenStack的上游开发者，我希望基于openEuler容器镜像定制OpenStack Kolla（容器组件）。 - 作为HPC领域的运维人员，部分软件依赖容器镜像（例如[Warewulf 4](https://warewulf.org/docs/development/quickstart/el7.html#pull-and-build-the-vnfs-container-and-kernel)），我希望通过容器镜像快速部署HPC集群。 -### 相关SIG组及指责 +### 相关SIG组及职责 - openEuler Release SIG：发布原始容器镜像的版本及更新版本，协助集成容器官方发布至Release流程中，随版本推送容器镜像，由每个版本的Release Manager负责发布至https://repo.openeuler.org/。 - openEuler Infra SIG：负责一键发布组件的设计、开发与维护，集成容器官方发布至Release流程中，由Infra SIG的维护者进行代码审核和最终镜像发布到容器镜像仓。 - openEuler Cloud Native SIG：负责原始容器镜像的裁剪、发布及代码审核。 +### 本oEEP解决的问题 +- 问题1：当前容器镜像发布至第三方仓流程未集成至Release流程，需要在版本发布后一天，人为触发。 +- 问题2：当前Release发布的原始文件(openEuler-docker.aarch64.tar.xz)，仅在首个版本进行发布，而update版本未进行发布。 +- 问题3：当前缺少AI容器发布到第三方仓库的流程，需要进行规范。 + ## 方案的详细描述: ### 1. 命名、标签规则 1. 名称: openeuler/openeuler @@ -69,7 +74,14 @@ docker run -ti openeuler-20.03-lts bash https://gitee.com/openeuler/openeuler-docker-images ### 3. 代码合入与审核 -1. 上传：上传dockerfile、脚本至openeuler-docker-images仓库。 +1. 上传：上传dockerfile、meta.yml、脚本至openeuler-docker-images仓库。 + +特殊地，mete.yml用于制作AI容器镜像，其中每一对的内容如下： +- tag (key): 镜像的标签 +- Dockerfiel_path (value): 制作标签为tag镜像的Dockerfile保存路径 + +因此，AI容器镜像的标签不遵循上文对原始容器镜像的标签规范。 + 2. 审核：由Cloud Native SIG Maintainer进行审核后合入。 ### 4. 发布流程 @@ -82,7 +94,7 @@ https://repo.openeuler.org/openEuler-{VERSION}/docker_img/update/YYYY-MM-DD/ ；最新update版本覆盖拷贝至：https://repo.openeuler.org/openEuler-{VERSION}/docker_img/update/current/。 2. 通过"一键发布工具"获取发布的容器原始文件，发布至第三方容器仓库。 -- "一键发布工具" [eulerpublisher](https://gitee.com/openeuler/eulerpublisher)已经上线，由openEuler Infrastructure SIG维护，形式如下： +- "一键发布工具"——[EulerPublisher](https://gitee.com/openeuler/eulerpublisher)已经上线，由openEuler Infrastructure SIG维护，形式如下： ``` - 获取： eulerpublisher container prepare --version ${VERSION} @@ -94,5 +106,10 @@ eulerpublisher container check --version ${VERSION} --repo openeuler/openeuler - 一键获取、测试、推送 eulerpublisher container publish --version ${VERSION} --repo openeuler/openeuler ``` -- 目前[eulerpublisher](https://gitee.com/openeuler/eulerpublisher)通过Jenkins任务进行容器进行镜像发布(例如20.03、22.03维护版本的update[发布](https://jenkins.osinfra.cn/job/luweijun/job/eulerpublisher/47/))。 +- 目前EulerPublisher通过Jenkins任务进行容器进行镜像发布(例如20.03、22.03维护版本的update[发布](https://jenkins.osinfra.cn/job/luweijun/job/eulerpublisher/47/))。 +3. 通过"一键发布工具"，基于原始容器制作AI容器镜像，发布至第三方容器仓库。 +``` +# EulerPulisher一键发布AI容器镜像 +eulerpublisher container publisher --meta meta.yml +``` diff --git "a/oEEP/oEEP-0014 openEuler AI\345\256\271\345\231\250\351\225\234\345\203\217\350\247\204\350\214\203.md" "b/oEEP/oEEP-0014 openEuler AI\345\256\271\345\231\250\351\225\234\345\203\217\350\247\204\350\214\203.md" new file mode 100644 index 0000000..6e08844 --- /dev/null +++ "b/oEEP/oEEP-0014 openEuler AI\345\256\271\345\231\250\351\225\234\345\203\217\350\247\204\350\214\203.md" @@ -0,0 +1,50 @@ +--- +标题: openEuler AI容器镜像软件栈规范 +类别: 流程设计 +摘要: 描述openEuler AI容器镜像软件栈分层、tag规范 +作者: 鲁卫军（wjunlu217 at gmail.com） +状态: 初始化 +编号: oEEP-0014 +创建日期: 2023-10-20 +修订日期: 2023-10-20 +--- + +## 动机与目标 +NVIDIA、AMD、昇腾等不同算力供应方分别推出各自的SDK以及各种AI加速库，但是多样性的算力和软件环境差异给用户部署AI应用带来了诸多不便。为了改善这一问题，不同厂商分别发布了对应各自算力的AI容器镜像，用户只需要在目标环境中加载镜像并启动容器，这大大减少了应用部署和环境配置的时间，使得AI模型的使用过程更加高效。 + +在此背景之下，制作和发布基于openEuler的AI容器镜像变得越来越迫切。但是目前对开发者制作相应AI容器镜像的指导非常匮乏，不同场景的容器镜像应该预装哪些软件？镜像Tag如何规范？ + +### 现状 +目前主流厂商发布AI容器镜像的预装软件内容及Tag示例如下表所示 +| | NVIDIA | AMD | +|-----------|------------|---------| +| Softwares | `base`: CUDA runtime (cudart)
`runtime`: `base` + CUDA math libraries + NCCL + cuDNN
`devel`: `runtime` + tools for building CUDA images | ROCm + pytorch
ROCm + tensorflow | +| Tags | `-base/runtime/devel-`
for example, `12.2.0-runtime-ubuntu20.04` | - `rocm__py_pytorch_`
- `rocm--tf-dev`
for example, `rocm5.7_ubuntu22.04_py3.10_pytorch_2.0.1` | + +通过对主流厂商发布AI容器镜像的分析，发现 +1. 软件栈 + +尽管不同厂商对AI容器镜像的预装软件内容存在差异，但软件栈分层基本相似，可归纳为以下几层 +```mermaid +graph TB; +A[(
Tools

AI Framework

SDK)] +``` + +2. 镜像TAG + +已发布的AI容器镜像Tag一般由镜像中预装软件和版本信息组合而成，通常为：`--` + +### 本oEEP的目的 +指导不同算力设备的开发者，如何制作基于openEuler的AI容器镜像。 + +## 方案描述 + +### 镜像内容及Tag规则 +- 基础SDK镜像：包含不同算力SDK的基础镜像，Tag为`-oe`，例如，cann7.0.RC1.alpha002-oe2203sp2 +- AI框架镜像：在基础SDK镜像之上，包含AI框架的镜像，Tag为`--oe`，例如，pytorch2.1.0-cann7.0.RC1.alpha002-oe2203sp2 +- 大模型应用镜像：在AI框架镜像之上，包含AI应用的镜像`---oe`，例如，chatglm6b-cann7.0.RC1.alpha002-pytorch2.1.0-oe2203sp2表示部署chatglm-6b大模型、包含cann-7.0.RC1.alpha002和pytorch 2.1.0的openEuler-22.03-LTS-SP2容器镜像 + +### 镜像发布（参考[oEEP-0005](./oEEP-0005%20openEuler%E5%AE%98%E6%96%B9%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E5%8F%91%E5%B8%83%E6%B5%81%E7%A8%8B.md)） +- AI容器镜像构建依赖meta.yml文件，文件内每一对指明构建镜像的Tag和Dockerfile +- AI容器镜像由EulerPublisher根据meta.yml构建并发布到对应的镜像仓库 + -- Gitee