Java War包 + Tomcat 部署的两种方案
1.可以把 WAR 包和 Tomcat 打包放进一个镜像里面。打包简单，但是无论是我要更新 WAR 包还是说我要更新 Tomcat，都要重新做一个新的镜像。
2.镜像里面只打包 Tomcat。它就是一个 Tomcat，但是需要使用数据卷的方式，比如说 hostPath，从宿主机上把 WAR 包挂载进我们 Tomcat 容器中，挂到我的 web APP 目录下面，这样把这个容器启用起来之后，里面就能用了。但是容器部署的宿主机不是固定的，所以我们一定要额外维护一套分布式存储系统。
容器组合方法之 Init Container
1.首先定义一个 Init Container，它负责把 WAR 包从镜像里拷贝到一个 Volume 里面，其会比用户容器先启动，并且严格按照定义顺序来依次执行。 2.APP 目录，实际上是一个 Volume。 3.此时这个 Volume 里面已经存在了应用的 WAR 包，等到第二步执行启动这个 Tomcat 容器的时候，去挂这个 Volume，一定能在里面找到前面拷贝来的War。
容器设计模式之 Sidecar
就是说Pod 里面，可以定义一些专门的容器，来执行主业务容器所需要的一些辅助工作。
常见的场景有:
1.负责将文件copy到共享目录，这样只要是挂载了这个共享目录的容器，就能拿到文件。
2.原本需要在容器里面执行 SSH 需要干的一些事情，可以写脚本、一些前置的条件，其实都可以通过像 Init Container 或者另外像 Sidecar 的方式去解决；
3.日志收集，日志收集本身是一个进程，是一个小容器，那么就可以把它打包进 Pod 里面去做这个收集工作；
4.Debug 应用，实际上现在 Debug 整个应用都可以在应用 Pod 里面再次定义一个额外的小的 Container，它可以去 exec 应用 pod 的 namespace；
5.查看其他容器的工作状态，这也是它可以做的事情。不再需要去 SSH 登陆到容器里去看，只要把监控组件装到额外的小容器里面就可以了，然后把它作为一个 Sidecar 启动起来，跟主业务容器进行协作，所以同样业务监控也都可以通过 Sidecar 方式来去做。
Sidercar的优点
1.将辅助功能从我的业务容器解耦了，所以能够独立发布 Sidecar 容器。
2.这些辅助容器是可以复用的，减少重复劳动，
Sidercar的用法
1.应用与日志收集
应用将日志写入V，日志收集组件如Logstash filebeat从V读取收集日志。
2.代理容器
当我们的应用需要访问外部服务集群时，我们可以定义一个proxy通过一个统一的ip去访问外部服务集群，应用和proxy容器之间通过localhost高速网络通道通信。
3.适配器模式
当我们需要改变应用暴露的接口形态时，我们可以不去更改业务代码，而是通过适配器容器去做一个转换。
总结
笔者公司目前用到的是openshift ecs，目前项目都是一个Pod部署一个容器也就是应用，这就是所谓的富容器的设计模式。通过对Pod和容器设计模式的了解，会考虑逐步对富容器进行解耦，将它们拆分成多个容器部署在同一个Pod中，实现解耦和复用。
