（2）Docker

1 Docker与虚拟机有什么不同？

Docker 不是虚拟化硬件的技术，它依赖 container-based virtualization（基于窗口的虚拟化）的技术实现工具，可以认为它是操作系统用户运行级别的虚拟化。Docker 最初使用 LXC 驱动，后来移至由 libcontainer 基础库驱动，现已更名为 runc。docker 是容器化系统上管理容器及应用容器化的部署工具，而操作系统设计用于运行多进程任务，提供多种运算服务的能力，比如虚拟机拥有等同于操作系统的能力。

• 容器无需启动操作系统内核，启动速度非常快。
• 容器化技术很少或几乎不给主机系统增加负载，具有近乎原生的性能表现。
• 与硬件虚拟化不同，基于容器的虚拟化运行时不需要其他额外的虚拟管理层软件 。
• 主机上的所有容器共享主机操作系统上的进程调度，从而节省了额外的资源的需求。
• 与虚拟机 image 相比，容器镜像较小，易于分发。

2 Docker的应用场景和优势是什么？

• Docker的应用场景

（1）应用发布和交付：Docker 容器可以将应用程序和依赖项打包成一个可移植的容器，并且可以轻松地在不同环境中部署和运行。
（2）微服务架构：Docker 容器可以用于实现微服务架构。通过将每个微服务打包成一个容器，可以轻松地进行部署和扩展，而不会影响其他服务。
（3）CI/CD 流程：Docker 容器可以与 CI/CD 工具集成，使得开发团队可以轻松地构建、测试和发布应用程序。
（4）多租户应用程序：Docker 容器可以用于构建多租户应用程序。每个租户可以使用自己的独立容器来运行应用程序，从而提高安全性和可靠性。
（5）持续集成环境：Docker 容器可以用于构建持续集成环境。通过将持续集成工具打包到容器中，可以轻松地在各个环境中进行构建和测试。
（6）开发和测试环境：Docker 容器可以用于快速创建开发和测试环境。通过将应用程序和依赖项打包到容器中，可以避免在每个开发者之间重新安装软件和库。

• Docker的优势

（1）更快的交付和部署。开发人员使用镜像构建标准开发环境，运维和测试人员使用镜像来获得和开发人员相同的运行环境。开发环境和测试运维环境无缝对接，节约开发、测试、部署时间。
（2）更高效的资源利用。相较于虚拟机而言Docker不需要额外的Hypervisor支持，Docker是内核级别的虚拟化，实现更高的性能。
（3）更简单的更新管理。使用Dockerfile，通过简单的修改就可以代替大量的更新操作。

3 什么是docker-compose？

docker-compose是一个批量化编排和管理多个容器的工具，使用docker-compose.yaml文件配置容器清单。docker-compose命令只能管理docker-compose文件中涉及的容器，大部分命令与docker的命令重合，而docker命令能管理机器上所有的容器和镜像文件。

4 Docker 有哪些重要的概念？

• 镜像（Image）：Docker 镜像（Image），就相当于是一个 root 文件系统。比如官方镜像 ubuntu 16.04 就包含了完整的一套 Ubuntu16.04 最小系统的 root 文件系统。
• 容器（Container）：镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
• 仓库（Repository）：仓库可看成一个代码控制中心，用来保存镜像。

5 Docker UnionFS有什么作用？

Union文件系统（UnionFS）是一种分成，轻量级并且高性能的文件系统，支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下。Union文件系统的Docker镜像可以通过分层来进行继承，基于基础镜像，可以制作各种具体的应用镜像。即使一次同时加载多个文件系统，从外面看起来只能看到一个文件系统，联合加载会把各层文件系统进行叠加起来，这样最终的文件系统会包含所有底层的文件和目录。

6 如何在生产中监控Docker？

Docker提供docker status和docker事件等工具来监控生产中的Docker，使用这些命令获取重要统计数据的报告。当使用容器ID调用docker status时，获得容器的CPU、内存使用情况等，类似于Linux中top命令。Docker事件是一个命令，用于查看Docker守护进程中整改再进行的活动流，一些常见的Docker事件如 attach、commit、die、datach、rename、destroy等。

7 为什么不建议把数据库部署在Docker容器内？

Docker 容器提供了一种高效且灵活的方式来部署和管理应用，但通常不推荐将数据库部署在 Docker 容器中，主要基于以下几个方面的考虑：

• 数据持久性：Docker 容器的生命周期往往是短暂和易变的，而数据库需要持久存储数据。虽然可以通过挂载外部存储来解决数据持久性问题，但这增加了配置复杂性和管理难度。
• 性能问题：Docker 容器可能会引入额外的性能开销，尤其是在 I/O 操作频繁的情况下。对于高性能要求的数据库系统来说，直接在物理服务器或虚拟机上运行可能会更优。
• 备份与恢复：在容器中运行数据库可能使得备份和恢复过程更加复杂。虽然可以通过自动化工具来帮助实现，但相对于在传统环境中的数据库备份与恢复，容器化数据库可能需要额外的工作来确保数据的完整性和一致性。
• 状态管理：容器通常设计为无状态的，这与需要保持大量状态信息的数据库应用有所冲突。虽然可以使用状态持久化技术，但这又增加了额外的管理负担。
• 网络配置：容器化环境中的网络配置相对复杂，尤其是在多容器通信和容器与外界通信方面。对数据库而言，网络配置的复杂性可能影响其性能和可靠性。
• 安全性考虑：在容器中运行数据库可能需要额外的安全考虑，因为容器的隔离级别通常低于虚拟机。这可能使数据库面临更高的安全风险。
• 可监控性和可管理性：虽然容器化的环境可以通过各种工具进行监控和管理，但相对于专门为数据库优化的传统部署方式，容器可能在监控和日志管理方面有所不足。

综上所述，尽管使用 Docker 容器部署数据库在一些特定场景下可能带来便利（如开发环境、测试环境），在生产环境中，为了确保数据库的性能、稳定性和安全性，通常推荐使用更传统的部署方式，比如直接在物理服务器或虚拟机上部署。当然，随着技术的发展，对容器技术的改进也可能在未来改变这一现状。