Docker 适合哪些场景

/Docker 怎么用 /

Docker 不是万能的，我们不能够期盼在 Docker 容器中运行所有的东西。符合 Heroku 公司 12 要素 ( https://12factor.net/zh_cn/ )风格的应用是最容易 Docker 化的，因为他们不维护状态。

推荐看看 12 要素，你会有收获的，官网有中文语言选择，可以看看，有时间后面我摘录分享出来。

在理想的微服务环境中，容器能在几毫秒内启动、停止而不影响集群的健康或应用程序的状态。

类似 ClusterHQ ( https://clusterhq.com/ )这样的创业公司正着手实现 Docker 化数据库和有状态的应用程序，在当下，由于编排和性能方面的原因，可能继续直接在虚拟机或裸机上运行数据库是较好的选择。

对网络吞吐量有高要求的应用进行最佳优化时不要使用 Docker，因为 Docker 使用 iptables 来完成主机 IP 到容器 IP 的 NAT 转换。通过禁用 Docker 的 NAT 来提升网络性能是可行的，但这是一个高级的使用场景，很少有团队会在生产环境中这么做。

docker 官网上说明了 docker 的典型场景：

1. 让应用快速打包与容易自动化部署

2. 创建轻量、私密的 PAAS 环境

3. 实现自动化测试和持续的集成/部署

根据这些特性，我们可以衡量评估一下，如果你的项目有如下痛点或者需求，那么可以去尝试去使用 Docker

• 需要频繁的升级，可以充分利用 docker 的镜像版本快速升级回退;

• 开发，测试，线上的代码运行环境经常变更,每当你查了半天 bug，最后竟然是环境不一致的时候;

• 销售演示或者 POC 的 demo, 启动后无历史数据，免去清理数据的苦恼,但其实也有，但是便捷;

• 项目体量过大, 进行了微服务改造, 需要统一管理，docker-compose 可以了解一下;

• 占用资源过多，可以利用 docker 资源配额和设置启动策略，提升稳定性;

• 整合开源服务，随着 docker 使用的普及，越来越多的开源项目提供了 docker 镜像部署。

注意 ：事物都是有两面，并不是所有项目都适合 docker 化改造，而且任何的改动都有可能产生不好的影响，要对技术保持敬畏,需要全方位权衡。

遵循科学流程，《企业级容器云架构开发指南》中给出了一个改造流程，可参考：

• 评估代价可行性

• 改造方案

• 代码修改

• 制作镜像

• 单机验证

• 多机部署

改造之前，软件架构设计看看是否遵循如下原则:

1. 倾向无状态服务,大部分服务都都需要保持无状态的。除了用于处理当前进行中的请求的临时信息，无状态服务不需要保持任何需要持久化的数据。无状态服务的优势在于可以非常容易地对他们进行销毁、重启、复制及伸缩，所有这一切都无需考虑任何数据处理方面的逻辑。并且，无状态服务更易于编写。

2. 倾向静态配置。所有宿主机和服务的配置都是静态的：一旦给服务器推送一项配置，该配置就会一直生效，直至显式地推送来新配置。与之相对的是那些动态配置的系统，其系统的实际配置是实时生成的，并会根据不同因素（如可用宿主机和即将到达的负载）进行自主修改。尽管动态系统的伸缩性更好，并且具有一些有趣的属性，如在出现某些故障时自动恢复等，但静态配置更易于理解和排错。

3. 倾向静态的网络布局。如果在一台宿主机中找到一项服务，除非新配置被确定并提交，否则总能在那台宿主机中找到该服务。

4. 区别对待无状态和有状态服务。尽管我们希望多数服务是无状态的，但是还是会有 MongoDB 和 ElasticSearch 等数据库类型服务用来持久化数据。这两种类型的服务在本质上是非常不同的，应该区别处理。例如，将一个无状态服务从一台宿主机移动到另一台上非常简单，只需要启动新服务，然后停止旧服务即可。但要对一个数据库进行移动，数据也要跟着移动。移动数据可能会花费很长时间，要求在迁移过程中停止服务，或通过设备方法进行在线迁移。在开发领域，通常将无状态服务比做“牲口”，它们没有名字，很容易被代替和伸缩，而将有状态服务比做“宠物”，它们是唯一的、具名的，需要维护，并且难以伸缩。

以上这些设计原则，将有状态服务与无状态服务分离，可以对本质上完全不同的服务进行区别处理（如图 3-1 所示），因此可以对每一种情况的处理方式进行优化和尽可能地简化。使用静态配置运行无状态服务使得操作系统的流程变得非常简单：多数情况下流程被简化成文件复制和容器重启，完全不需要考虑其他因素，如对第三方系统的依赖。

/Docker 的优点 /

1

简化配置

虚拟机的最大好处是能在你的硬件设施上运行各种配置不一样的平台(软件, 系统), Docker 在降低额外开销的情况下提供了同样的功能. 它能让你将运行环境和配置放在代码汇总然后部署, 同一个 Docker 的配置可以在不同的环境环境中使用, 这样就降低了硬件要求和应用环境之间耦合度。

2

代码可流水线管理

代码从开发者的机器到最终在生产环境上的部署, 需要经过很多的中间环境(开发-->测试-->beta-->线上). 而每一个中间环境都有自己微小的差别, Docker 给应用提供了一个从开发到上线均一致的环境, 让代码的流水线变得简单不少。

3

提升开发效率

不同环境中, 开发者的共同目标:

1. 想让开发环境尽量贴近生产环境;

2. 想快速搭建开发环境。

开发环境的机器通常内存比较小, 之前使用虚拟的时候, 我们经常需要为开发环境的机器加内存, 而现在 Docker 可以轻易的让几十个服务在 Docker 中跑起来。

4

隔离应用

开发时会在一个台机器上运行不同的应用:

1. 为了降低成本, 进行服务器整合;

2. 将一个整体式的应用拆分成低耦合的单个服务(微服务架构)。

5

整合服务器

Docker 隔离应用的能力使得 Docker 可以整合多个服务器以降低成本. 由于没有多个操作系统的内存占用, 以及能在多个实例之间共享没有使用的内存, Docker 可以比虚拟机提供更好的服务器整合解决方案。

6

调试能力

Docker 提供了很多的工具, 这些工具不一定只是针对容器, 但是却适用于容器. 他们提供了很多功能, 包括可以为容器设置检查点, 设置版本, 查看两个容器之间的差别, 这些特性可以帮助调试 Bug。

7

多租户环境

多租户环境的应用中, 它可以避免关键应用的重写。我们一个特别的关于这个场景的例子是为 IoT(物联网)的应用开发一个快速, 易用的多租户环境. 这种多租户的基本代码非常复杂, 很难处理, 重新规划以应用不但消耗时间, 也浪费金钱.

使用 Docker, 可以为每一个租户的应用层的多个实例创建隔离的环境, 这不仅简单而且成本低廉, 因为 Docker 环境启动的速度快, diff 命令很高效。

8

快速部署

Docker 为进程创建一个容器, 不需要启动一个操作系统, 时间缩短为秒级别。

可以在数据中心创建销毁资源而无须担心重新启动带来的开销。通常数据中心的资源利用率只有 30% , 通过使用 Docker 并进行有效的资源分配可以提高资源的利用率。

/Docker 的缺点 /

Docker 的安装非常容易.目前,Docker 支持所有的 Linux 系列系统,(Ubuntu,RHEL,Debian 等)。通过 Boot2Docker 虚拟工具 or 安装 Docker Desktop , 在 OS X 和 Windows 下也能够正常使用 Docker。

Docker 运行环境的限制:

• 必须是 64 位机器上运行,目前仅支持 x86_64 和 AMD64,32 系统不支持;

• 系统的 Linux 内核必须是 3.8 或者更高,内核支持 Device Mapper,AUFS,VFS,btrfs 等存储格式;

• 内核必须支持 cgroups 和命名空间。

二进制安装参考: https://docs.docker.com/engine/install/binaries/