第五章常见问题

**Pod 资源配额已用完：**build 任务也是通过启动相应 Pod 来完成，如果 Pod 的配置已经达到上线将无法启动构建任务；
**调度构建任务 Pod 失败：**关于 Pod 调度失败的问题详见相关专题；
拉取构建任务镜像失败： 在 DataFoundry 中镜像构建任务是由一类系统基础镜像启动成 Pod 后完成，如果构建基础镜像拉取失败，将无法启动构建任务。

**容器构建 Dockerfile 不正确：**如果 Dockerfile 不正确容器将不能构建成功，因此需要保证 Dockerfile 经过严格测试，Dockerfile 中的关键信息发生变化是要及时更新，例如 tomcat 在 Apache 网站上的下载地址；
**构建过程中无法访问远程资源：**例如要现在的软件包，要更新的系统功能，这多是由于镜像中系统更新或者软件下载的默认源为国外地址，在国内访问时存在较多限制导致，当然也可能由于系统的相关网络功能异常导致，随着系统的不断稳定这类问题出现的机率已相对较小，因此当镜像构建过程中出现网络方面问题时可以先排除是否为国内无法访问国外网络地址，如果是在访问国外网络地址不受限制或国内网络地址出现异常时先排除对端服务是否正常，如对端服务正常才考虑平台网络问题，系统管理员处理此类问题的方法和流程详见网络问题处理专题介绍；
**私有git仓库的登录的鉴权信息配置错误：**可参考 buildconfig 专题介绍中私有 Git 仓库登录鉴权信息配置过程进行检查；
镜像构建所需计算、内存资源超出平台所分配资源： 这多是针对镜像构建中执行的从源代码 build 执行程序的过程，表示构建任务相对复杂或者构建任务配置不正确，导致在构建过程中消耗了过多的系统资源。

**镜像构建正常但镜像上传失败：**这类问题多是由平台内置镜像仓库异常导致，可尝试通过 oc start-build buildconfigname 来重新构建，以及删除 bc、is 后通过 oc new-build https://github.com/*** 来重新启动创建及启动构建任务，如持续失败或异常可与系统管理员联系。系统管理员处理此类问题的方法和流程详见镜像仓库问题处理专题介绍；
**节点到内部镜像仓库网络异常：**这种异常相对少见，这是构建任务还在建立与平台内容镜像仓库的网络连接，如果此时构建任务失败多提示“no route to host”或者“50X”网关错误，开发者遇到此类问题可以在尝试按照上述镜像上传失败案例中提供的oc start-build以及oc new-build命令尝试重新构建，如不能解决可与系统管理源联系，系统管理员可参考平台网络相关检查和处理流程进行处理，详见具体专题。

如果应用容器启动状态为 CrashLoopBackOff ，则说明容器中得应用没有正常启动，导致这种情况的原因主要包括如下几个方面：

**容器中应用启动方式不对：**由于在容器中除特殊需要通常是没有进程管理功能的，这也就是说容器中的应用不能以后台进程方式运行，子进程终止后容器也会终止，这些在应用适配容器以及 Dockerfile 编写时要格外注意，同时这些错误可以在容器构建完成后在 Docker 运行一下就可以很快发现；
**应用依赖的其他服务或者组件没有启动或者无法连接：**可以通过 oc logs 命令检查应用日志；
**容器中应用的启动用户不满足平台安全要求：**为了安全考虑通常平台是不会允许以容器中的 root 用户来启动容器中的应用，而是会限制用户 id 在 100 以上的用户来启动应用，而这需要通过在 Dockerfile 中用 user 关键词来显示声明，例如：
```
FROM baseimage
user root
RUN update_some_system_package

user 200
RUN build_some_application

CMD start_application.sh
```
平台在安全上的考虑除了容器中应用的启动用户设置外，还会对容器中应用启动后的一些系统级的操作进行限制，例如 fork、kill 等。

Provide feedback