自定义应用 Pod 的启动命令
在使用 openshift 提供的 S2I 方式进行镜像的构建和启动 pod ，其中 run 脚本定义了 pod 的启动命令，但是在很多情况下，应用人员有时候需要对应用的启动命令进行修改，如添加个判断脚本，加载证书，还有开发人员等等因为代码原因或者环境原因导致的一些必须在启动 pod 时执行的命令，如果将这些都放在 run 脚本内，每次都需要重新制作基础镜像，非常麻烦运维人员和开发人员，所以我将这个给从 run 脚本从分离出来了。
解决方法：
我在 openshift 上创建一个 configmap，configmap 的内容可以让开发人员自定义pod的启动过程，将这个configmap挂载进pod，run 脚本去再去调用该 configmap 去启动 pod，以下就是 run 脚本，我将 configmap挂载在：/tmp/s2i/run.sh 路径下，因为 configmap 在 pod 内不能修改，第一条命令是将读取后重定向的方式创建一个新的脚本，因为在 windows 系统上编辑 configmap，会出现多余的字符，所以需要对 configmap 脚本做一些处理，要不然脚本运行会报错。在 openshift 页面上对 configmap 进行pod 的启动命令进行编辑，确实减少了一些工作量，并且也从代码上解耦了，不需要将这部分放在代码库里头。
#!/bin/bash
tr -d '\r' < /tmp/s2i/run.sh > /tmp/Run.sh
sh /tmp/Run.sh
测试、预发布、生产网络不通，如何解决镜像同步？
在一个客户那里遇到一个环境限制，测试、预发布、生产网络不通，不能开防火墙，也没有特定的中转机器，唯一能通三个环境的就只有存储设备，在这个情况下，只能通过nfs存储作为一个中间过度了，这个过度又可以分为两种方式。
第一种：
在测试环境中将准备好的镜像通过 docker save 保存后放到nfs共享盘上，预发布和生产再从nfs共享盘上去拿取文件，通过 docker load 导入本地，再 docker tag 修改镜像仓库，docker push 推送到预发布或者生产的镜像仓库，这些操作虽然最后都能通过 Jenkins 的 pipeline 脚本进行自动化完成，但是速度慢。
第二种：
因为测试环境的镜像仓库已经存在 S2I 结束后的镜像了，所以我将测试环境的镜像仓库数据目录使用nfs挂载，然后将该 nfs 也挂载至预发布或者生产镜像仓库，这个时候再预发布或者生产的机器上使用docker pull加上仓库名+应用名+tag 是能够拉取到对应测试环境镜像的，这个方式就很快了，也简单。
PS：虽然 skypo 这个工具能够在两个镜像仓库之间做同步，但是稳定性不好，尤其在镜像大的情况下，容易断掉，执行失败，所以我使用 docker pull和 docker push这个最为稳定的方式进行镜像仓库之间的同步。
Jenkins slave maven制作镜像每次都需要重新拉取依赖包文件
在运行 Jenkins pipeline 我使用的是 slave maven 去完成，这时候会新生成一个 maven pod 去完成 Jenkins job，这里有个问题在于，由于在 mvn 打包的时候，默认 maven pod 是没有包含依赖的 jar 包等文件，每次打包都需要重新拉取，这个时间会很长，取决于依赖包的大小和网络环境。这里也有两种解决方法。
第一种：
因为大部分包每个项目组都是通用的，所以直接将这些包打入到maven镜像内，以后在每个应用打包的，会根据差异拉取差异包，减少时间。
第二种：
创建一个nfs，挂载至 maven pod的/home/jenkins目录，因为默认拉取的包都是放在该目录下，以后 maven pod启动的时候就能够从该路径下读取依赖包，不需要再拉取了，每个应用一个，我是采用这种方式进行的。并且还通过 configmap 添加了 maven-setting文件。
image
image
image
在maven pod内挂载宿主机 docker
image
并分配scc权限以使用宿主机的文件：
oc adm policy add-scc-to-user privileged -z jenkins
关于配置管理
大部分客户那里都没有配置中心这么个东西，spring cloud 虽然自带了这个，但是 spring boo t和 mvc 这类是没有自带配置中心的，所以需要一个外部统一的配置中心，后期大部分客户都有规划部署一个配置中心，商业也好，开源也好，开源的话，目前来看还是比较推荐Apollo的，使用案例也多，如果客户能力强自己搞，不行的话，建议还是去买服务比较好或者商业配置中心。
那么在没有配置中心的情况下，如何解决配置管理呢？
以前都是在项目代码下一起管理配置，现在在容器下，肯定是需要针对不同环境使用不同的配置文件，虽然也可以在代码里头维护多份配置，但是如果在生产环境下发现配置问题，又得在从开发测试环境从新对代码编译打包制作镜像等等，配置能抽取出来就意味着修改配置，重启pod就可以解决了。
我想到了以下几种在没有配置中心的情况下管理配置的方法。
- configmap
这个大家应该都熟悉，这个是 openshift/kubernetes 默认的配置管理组件，但是缺点也很明显，没有版本管理、配置对比等等，这个只能在对配置没有强管理的情况下是可以使用的；如果需要进行轻度版本管理呢？我的想法是对 configmap 进行命名，如v1,v2。。。。，比如在生产需要修改配置时，创建一个新的configmap，把命名为app+v2，把原有的内容复制过来进行修改，然后在 DeploymentConfig 中将应用的configmap由v1切换为v2，这个也算是做到版本管理了，在配置有问题的时候也方便回滚。
- �在 gitlab 或者 svn 上创建一个 repo 放配置文件
首先在每个环境准备一个gitlab或者 svn，在本文开头自定义pod启动命令时，加入 git clone 或者 svn 命令，去拉取配置文件，然后再使用mv或者cp到应用定义好的读取配置文件路径。
configmap 挂载冲突的问题
当把多个 configmap 挂载到pod内的同一个路径下时，这个时候是会报错的，为了解决这种问题可以加入几个参数，参考如下：
volumeMounts:
- mountPath: /projects/configs/application.yml
name: application-yml
readOnly: true
subPath: application.yml
这个时候就能在/projects/configs目录下挂载多个configmap了，如application.yml等等，其中application.yml是文件名，subPath是关键参数，
网友评论