简述 Docker 改造传统应用的流程

首先根据系统的特点判断是否适合 Docker 化改造，如适合改造，则开始制定改造方案，改造方案会涉及系统镜像的组成、镜像的参数、镜像的启动方式以及源码改造点等基本问题。接下来就是改造环节了，即改造代码以符合 Docker 的要求，然后制作镜像。最后是验证阶段，由于可以在一个单机上启动多个 Docker 容器进行联网调测，所以单机测试验证通过以后，基本上就表明了多机分布式部署的正确性，最后进行多机部署测试，以及生产环境的上线过程。

那么哪些应用适合 Docker 化改造？一般认为符合以下条件的应用是适合进行 Docker 化改造的。

1）频繁修改和升级的系统。

2）不太稳定，容易死机或者导致 CPU、内存等过度消耗的应用。

3）大量使用开源技术和中间件的系统。

4）其主要目的是用作演示的应用。

首先，很少变动的系统不适合进行 Docker 化改造，因为很少变动的系统意味着没有什么业务需求支撑，如果花很大代价将其进行改造，就是一种投资浪费。系统改动升级越频繁，Docker 化的价值越大，因为 Docker 镜像后的系统部署和升级都很容易实现标准化和自动化，大大提升了项目组的工作效率，减少了重复劳动，Docker 化以后，镜像都有版本，因此升级失败后的回滚也变得更容易和可靠。

其次，Docker 容器因为共享 Linux 内核，所以那些与 Linux 底层密切相关的应用是不适合 Docker 化的，因为这些容器大量操作内核 API，可能导致内核不稳定，如内核崩溃，此时其他容器都受牵连，这是非常严重的。所以这种情况是不能进行容器化的，必须要独立出去。而对于那些不太稳定、容易“自杀”或者容易导致 CPU 和内存过度消耗的应用，则很适合 Docker 化，因为 Docker 可以做 CPU 和内存的资源配额限制，例如，一个 Docker 容器只分配 1GB 的内存，则此容器内的进程如果申请超过 1GB 的内存，就可能会被 Docker Engine“杀死”，如果该容器限定了使用 0.5 个 CPU，那它永远不会得到超过 0.5 个 CPU 的使用量，因此 Docker 化以后，这种过度消耗资源的进程会被约束，不会导致系统问题。另外，如果某个进程不稳定并且容易“自杀”，则可以在容器化的时候设置它的启动策略为“restart=always”，这样如果 Docker Engine 发现这个容器“死了”，就会自动尝试重启这个容器。

最后，其主要目的是用作演示的应用以及项目 POC 也都适合 Docker 化。因为 Docker 比较轻量，很容易用 Docker 容器部署一个集群应用，这个集群应用只需要少量资源，如在高配置的笔记本式计算机上就能流畅演示。此外，如果演示者本身并不是很懂技术，相对于虚拟机等复杂的技术，Docker 的使用还是很容易快速掌握的，稍微培训一下，很多售前和销售人员就能正确启动一套 Docker 的演示集群。此外，每次创建的 Docker 容器都是全新的、没有历史数据的，因此每次演示都能确保系统是正常可靠的。

总结下 Docker 化改造传统应用的关键步骤如下。

1）评估代价与可行性——评估改造的可行性及资源投入等。

2）改造方案——包括如何升级改造、对代码进行修订的指导性意见等。

3）代码修订——对前期涉及的原有代码进行修订，包括一些接口设计等。

4）制作镜像——实施阶段，制作镜像。

5）单机验证测试——对镜像做单机验证。

6）多机部署——多机环境的正常部署和应用的正常启动。