如何将Azure ML对接至JFrog Artifactory等非ACR镜像仓库

存在成熟可直接落地的实现方案，完全可以将Azure ML（以下简称AML）全功能对接到JFrog Artifactory等非ACR镜像仓库，你目前探索的「在Artifactory侧提前构建无AML定制修改的自定义镜像、AML仅负责拉取镜像运行Pipeline」的路径是生产环境的主流实践，完全可行。

AML从v2版本的SDK、CLI开始就没有强制绑定ACR，原生支持拉取第三方合规镜像仓库的容器镜像，不需要对平台本身做二次开发，只要按以下要求配置即可覆盖全部功能：

• 凭据配置：如果是私有Artifactory仓库，两种配置方式二选一即可：
• 在AML工作区的连接配置中添加容器仓库类型的凭据，填入Artifactory地址、具有拉取权限的用户名/专用访问Token，AML调度计算资源时会自动注入凭据完成镜像拉取，不需要在Pipeline脚本中手动执行docker login
• 给AML使用的计算集群、计算实例、在线端点节点配置用户托管标识，给该标识分配Artifactory对应仓库的拉取权限，不需要在AML侧存储固定凭据，安全性更高
• 镜像构建要求：你提到的不对镜像做AML定制修改完全可以实现，只需要保证镜像满足任务本身的运行时依赖即可：比如跑Python任务就预装对应版本的Python和业务依赖包，如果需要调用AML的运行时API，只要保证镜像内的az cli及ml扩展版本和提交任务用的客户端版本匹配即可，不需要额外植入AML专属代理程序——AML启动容器时会自动注入任务执行所需的sidecar和上下文环境，不会因为镜像来自第三方仓库丢失功能。
• 全功能适配注意点：要覆盖AML全部能力只需要避开几个默认配置的坑：

1. 配置AML自定义环境（Environment）时，直接指定Artifactory的镜像全路径即可，AML会直接拉取镜像缓存到计算节点，不会强制要求镜像存储在关联ACR，也不会自动把镜像同步到ACR
2. 使用在线端点部署、模型打包、ParallelRunStep等内置能力时，均支持直接指定Artifactory镜像作为运行载体，只要在计算资源的网络出站规则中放通Artifactory的访问地址即可；如果是私有网络部署的AML，建议配置Artifactory的私有网络访问地址，避免公网拉取镜像超时
3. 不建议使用AML内置的镜像构建任务推送镜像到Artifactory，该原生构建逻辑默认只推送镜像到工作区关联的ACR，镜像构建、漏洞扫描、版本治理的流程完全可以放在你现有的Artifactory配套CI链路上完成，构建完成后把镜像地址传给AML调用即可，和你当前的探索路径完全匹配。

该方案属于AML官方明确支持的使用方式，不属于非正规的hack方案，目前已经有大量企业在生产环境用这套模式对接内部统一的Artifactory镜像仓库，好处是可以直接复用企业已有的镜像治理、安全扫描、权限管控体系，不需要单独维护ACR的镜像流程；唯一的取舍是需要自行负责镜像的版本维护和依赖更新，不会自动同步AML官方发布的基础镜像更新。

内容的提问来源于stack exchange，提问作者user3899966