Docker应用迁移的解决方案培训课件.pptx

Docker应用迁移的解决方案 综述 Docker是典型的Client-Server工作模式，每一个Docker应用都是运行在机器中的Docker Engine之上。因此，Docker应用的迁移也就是把某个Docker应用，从一个Docker Engine迁移到另一个Docker Engine之上。 根据实现的方式不同，Docker应用迁移可以分为离线迁移和在线迁移。 离线迁移 Docker目前内置了一组命令，用来实现镜像和容器的备份。通过备份、传输、部署能够实现Docker应用的离线迁移。 save：将镜像打包至tar格式的压缩文件。 load：从tar格式的压缩文件加载镜像。 export：将容器的整个文件系统打包至tar格式的压缩文件。 import：从tar格式的压缩文件加载容器，并记录为镜像。 export/import的过程只保存容器当前的文件系统，而不保存运行状态，因此并不能提供不中断的服务。 离线迁移 Docker原生提供的这一组命令方便了系统运维，管理员可以轻易的将一台机器上的Docker镜像或者容器进行备份，然后分发给其他的应用场景使用。 在线迁移 在线迁移是在保持Docker应用运行的状况下，将这个应用从一个Docker Engine迁移到另一个Docker Engine。由于在工作环境下往往不能停机，因此在线迁移是系统运维中必不可少的功能。 目前Docker的版本已经发布到1.6.0（2015-04-17更新），实现Docker在线迁移的难点主要有两个： 缺乏成熟的容器迁移机制。 Docker Engine不能原生支持在线迁移。 容器迁移机制 虽然没有专门针对Docker的容器迁移机制，但是通过CRIU可以实现容器迁移的大部分功能。 CRIU是一个给Linux系统提供Checkpoint和Restore功能的工具，能够完成程序的备份/恢复，以及容器的迁移。在迁移过程中，它能够分批传输要复制的内存，从而保证在极短的停机时间内恢复容器的运行状态。 CRIU的工作流程 CRIU按照如下4个步骤进行容器的在线迁移： Pre-Dump：将容器的文件系统和内存数据打包，然后发送到目的机器。 Dump：将Pre-Dump过程中改变的数据发送到目的机器，得到最终待恢复的容器文件。 Restore：从打包好的容器文件中恢复容器的运行状态。 Kill：停止原始机器中运行的容器。 CRIU的工作流程 Dump过程具体的实现细节如下： 系统当前状态的信息在/proc中，它包括了文件描述符信息、管道参数和内存分布信息等等。 首先需要存档进程树的状态。 其次需要存档对每个任务分配的资源情况。 最后复制整个内存。 Restore过程具体的实现细节如下： 首先需要解决共享资源的问题，利用Dump过程的信息恢复共享资源，并划分到对应的进程下。 通过多次fork()恢复进程树。 恢复包括内存分配，计时器等基本资源。 CRIU面临的问题 CRIU目前的问题是无法将迁移后的容器挂载到Docker Engine。虽然CRIU能够将原始机器上的Docker应用迁移到目的机器上，但是当容器迁移后，目的机器上的Docker Engine并不能识别这个容器。因此这个容器将处于游离状态，并且不能与Docker Engine发生任何交互操作。 Docker Engine原生支持 虽然CRIU并不完全支持Docker在线迁移的特性，但是仍然有研究者希望利用CRIU去完善这个功能。 Google研究员Saied Kazemi在Github上有一个项目，尝试给Docker加入Checkpoint和Restore功能，从而实现Docker在线迁移。 他的做法是修改Docker源码，加入Checkpoint和Restore两条命令，然后调用CRIU提供的功能。目前项目处于开发中的状态，而且需要在未来申请合并到Docker的主线。 Docker Engine原生支持 右边是Saied Kazemi的一个Demo，演示了目前的项目效果： Docker Engine原生支持 Docker目前有两套不同框架的实现，一套是LXC，一套是libcontainer。前者是传统的容器虚拟化技术，后者则加入了更多专属于Docker的特性。因此要实现Docker Engine原生支持，主要是对libcontainer做出一定程度的修改。 总结 Docker目前提供的import/export命令只能支持离线迁移功能，由于无法在生产环境中提供不中断的服务，因此这两个命令更适合用于任务分发。 Docker在线迁移的两个难点，对应的解决方案如下： 缺乏成熟的容器迁移机制：根据Saied Kazemi的实验结果，可以借助CRIU实现。 Docker Engine不能原生支持在线迁移：在社区中反