有时有在使用openshift去构建应用之前，你已经有了Dockerfile.
怎样才能让这个Dockerfile在openshift中也能很好的使用去部署程序？
答案是你需要作一些小的调整去适配一些openshift特有的限定。
举例：
我们有一个基于Sonatype开发的Nexus应用，而这个应用是开发用来保存该应用程序所需要的artifacts，例如dependencies的repo manager。它可以保存保存多种技术例如Java, .NET, Docker, Node, Python以及Ruby的artifacts。
Sonatype提供了一个Dockerfile, 基于Red Hat Linux base container image去构建Nexus service。这个Dockerfile用于在Red Hat Container Catalog中构建Nexus container image. 其中为满足openshift requirements作了一些针对性的配置，例如允许container image以任意用户去运行等。让我们来先一步步分析在https://github.com/sonatype/docker-rhel-nexus/blob/master/3.6.0/rhel/Dockerfile
指定base image, 定义maintainer, label以及image metadata.
复制uid_entrypoint脚本到container image中，然后安装Nexus所有的实时的包，例如tar和Java。
定义环境变量如data目录，user name和user ID. 从特定的URL下载Nexus服务，创建新的用户nexus并指定ID为200，并让其作为group 0的成员。 用‘-r’ 选项指定这个账户为系统账户。
创建Nexus服务所需要的folders，指定这些目录属于group 0。使得在openshift默认的安全策略下container可以正常工作。
给/nexus-data 配置一个volume, 这个目录保存了所有Nexus提供的artifacts。创建/etc/passwd.template文件，给uid_entrypoint脚本使用。
这个container image entry point就是uid_entrypoint这个脚本，也就是说当这个container image启动，则脚本会执行。
The uid_entrypoint script
我们知道openshift用一个随即用户ID去启动一个应用。而从以上的Dockerfile看出，我们其实是希望container可以以200 uid/nexus user进行启动。
uid_entrypoint脚本的目的就是去识别运行这个应用的用户ID，并将其定义为nexus user。让我们来看其是如何实现的：
/etc/passwd.template中有以下一行：
nexus:x:${USER_ID}:0:nexus application user:/nexus-data:/sbin/no-login
在container启动期间，用以下shell脚本识别运行container的用户ID，并更新/etc/passwd的文件，分配这个ID给nexus用户。
Creating Probes Scripts
Red Hat建议部署到Openshift的应用定义health probes. Nexus提供了一个API去去定这个service的状态，是alive或者deadlocks. 你可以用这个API去创造脚本去配置readlines和liveness的probes.
在该实验中，用下面两个脚本进行readiness和liveness的检查
