一、挂载卷需求和应对方案
下面列出了遇到的一些需求：
/opt/data 目录，需求10KB～2MB，可读写，存放特殊文件（本地配置备份，供配置服务容灾），几乎所有Java项目都需要。
simsong.ttf 字体文件，二进制，18MB，只读，应用程序需要用到。
xyz-linux-x64.so库文件，二进制，20KB，只读，跟证书类似，由专人配置，不得泄露，很多项目要用到。
qkban.cert 证书文件，纯文本，3KB，只读，由专人配置，不得泄露。
对于上面的第（2）项，我觉得可以放在GIT库，文件跟代码走。运行前，可以用脚本将文件拷贝到某个路径。
对于（3）（4）项，由于保密性，不宜和代码放在一起，而且应该有严格保密规则，例如只能在服务器上存放。抛开容器环境不谈，一个方案是直接将这个文件拷贝到服务器目录上；第二个方案是，文件加密存放在FTP等其他地方，然后在初始化服务器的时候，将这个文件拉取下来，解密后，放到相应目录。显然，第二个方案更好，方便管理。
再来看，上面的（3）（4）项，其中第（4）项，由于是文本文件，可以当做配置，用统一配置中心来管理。统一配置中心就好比第二个方案的FTP，而且具备可视化的管理，历史纪录还原等功能。但是第（3）项，是一个二进制文件，如果配置中心支持二进制文件，那也可以，但是目前不支持，所以，得想其他办法。最好的办法是改造、让配置中心支持二进制文件，但比较麻烦，有没有简单可行的方案？写个脚本，从FTP去取，解密后放在本地目录，并设置为只读，在服务器或应用程序运行前，运行这个脚本。
# 从ftp拉文件 wget http://10.12.1.1/zoa.jar.tar.gz # 加密 tar -czf - zoa1.jar | openssl enc -e -aes256 -k 123 -out zoa1.jar.tar.gz # 解密 openssl enc -d -aes256 -k 123 -in zoa1.jar.tar.gz | tar -xz -C . # 设置为只读 chmod 400 zoa.tar.gz
对于Kubernetes容器云环境，可以用只读方式，挂载这个文件，但是目前的挂载卷，只支持pod共享，不支持跨工作负载、跨namespace、跨宿主机共享，所以挂载不是一个好的办法，包括ConfigMap、Secret，都不能做共享，而且size限制为1MB。这些都不是理想的办法。
对于上面的（1），的确应该用挂载卷，但是问题是，几乎所有项目都需要这个功能，那能不能自动给某个类型的容器（根据镜像、标签等判断）挂载好这个目录？——使用Kubernetes的自定义CRD（CustomResourceDefinition）组件。
二、编译打包及镜像制作
临时方案：使用Rancher容器平台自带的pipeline功能。
我总结的缺点如下：（跟Jenkins和云效等DevOps平台比较）
1、不支持项目管理（此处所说的项目，是指研发称的应用项目，而非Rancher的概念）
传统的Jenkins或云效等DevOps平台，对pipeline的管理，都是先手动创建项目的（手动输入项目名，项目基础信息）。而Rancher不是，它是先配置git，它认为一个git地址就是一个项目（但是每个git分支，可以单独配置），实际使用上，不够灵活，我们会遇到问题，比如一个git地址，在Jenkins可以对应任意多个项目（我们想创建多少个就有多少个）。
不支持项目管理，就没办法做搜索和精细化权限管理，比如之前用的云效DevOps平台，先建项目，项目是有很多META和TAG信息的，比如开发负责人是谁，测试负责人是谁，比如“张三”，他登录进去就能看到自己有那些项目。而Rancher的维度不一样，它的维度不够灵活，做为一个Kubernetes管理平台，它是成功的，但是作为一个管理项目的DevOps平台，它还差的太多。
2、Pipeline这种每次拉Docker镜像去构建的方式，有利有弊
单次构建效率是偏慢的。
首先说一下编译缓存问题。（此问题和Pipeline无关，哪怕是Jenkins构建也可能会存在问题）
编译打包环境优化
第一个要谈的是Java项目，每次构建花费约15～20分钟，这个是很难受的，maven没有缓存，每次拉新包，第二个是NodeJS项目，每次构建花费25~35分钟，而且Rancher Pipeline日志界面还没有反应，不知道的还以为卡死了，也是因为没有node_modules缓存引起的。
Rancher Pipeline的原生构建方式，必然遇到上面两个问题。需要优化（给Maven加上本地repo，给NodeJS项目缓存node_modules）。
怎么解决这个问题呢？第一，我觉得编译打包的环境，要相对固定，CPU、内存、磁盘等要高配，要对项目的打包环境进行特殊优化，优化之后，让项目编译打包的速度达到最快，打包失败率降到最低。每次用Docker拉镜像创建全新打包环境的思路是不对的，这样做的优势是什么？是能让同一个项目能并发的进行多个编译打包，且能将打包任务均匀的分发到不同的宿主机上，达到整体的资源平衡。但这样做是没必要的，这又不是生产项目，不会长时间运行，而且同一时间运行的任务并不会很多（一个有几百个项目的公司，全都在同一时间去打包的概率不大），传统Jenkins方式我们用了这么久，也没有这个需求。为了节约资源和加快速度，每次打包完，可以stop这个容器，但是没必要删除它，下次用的时候，直接start就行了。现实是，在一个时间内，一个项目通常只有一个打包进程，这样我们可以用有状态的部署方式，挂载固定的卷来存放缓存，甚至固定到某一个宿主机上运行，以保持稳定和高效。
3、Rancher Pipeline太过依赖于脚本，而在可视化基础功能上太弱
基本上，需要自己改源代码，对pipeline进行扩展。注意，前端的代码是用的ember.js，在国外比较流行，国内用得较少，写个输入框还算简单，如果做复杂的功能就麻烦了。它自带的功能不算多，如果改动较多，还不如用熟悉的语言（VueJS、ReactJS）重写算了。或者，找个其他更强大的DevOps平台或者CI/CD平台（比如Drone），替换调它的Pipeline。
三、网络环境和方案
1、容器内的项目，怎么访问容器外的服务器，包括外网？
使用 Calico + BGP，打通容器和虚拟机的网络。这样做，用起来十分方便。