曾经，IT团队被告知容器最适合无状态的工作负载，并且最好不要将数据库放入其中。但随后，从SQL Server 2016开始，微软决定让其关系数据库软件在Docker容器中运行。那么，为什么现在可以在Docker容器化SQL Server呢？

为了回答这个问题，我们最好先理解一下容器的结构。尽管从技术层面来看，容器是一种虚拟化技术，但它们与虚拟服务器有很大不同。服务器虚拟化会将服务器的硬件层抽象出来，以便可同时运行多个操作系统副本，每个副本都隔离在虚拟化硬件中。

而另一方面，容器则是在应用程序层执行虚拟化。在单个主机系统运行的不同Docker容器共享一个基础镜像，这意味着它们全都使用相同的操作系统内核，并且不需要在每个容器内都有访客操作系统。这也使得容器很轻便，且在启动时表现出色。

数据库无法接受数据丢失

如果容器真的只是虚拟化应用环境，为什么在Docker运行SQL Server曾被认为不可行呢？这是因为，虚拟机和容器之间的主要区别是，后者基本上是一次性的，容器可能会被立即启动，但它们通常也很快会从系统中移除。

当发生这种情况时，容器内的数据将会丢失。这就是为什么容器通常用于运行无需持久数据的无状态工作负载的原因，例如前端Web服务器完成的处理工作。

Docker确实为IT管理员提供了一种选择，让IT管理员可关联所谓的联合文件系统与容器（作为存储可写入层）。然而，这种方法最常用于对基本容器镜像进行永久修改时–从而更改基于该镜像的容器。这种方法可能比较适合安装应用补丁的情况。

问题是，容器的可写入层中创建的文件会随着容器消失。虽然这对无状态使用没问题，但大多数应用（以及SQL Server等数据库）需要能够写入到磁盘，即使只是暂时。

为了实现这一目的，数据写入到联合文件系统的替代方法是将其写入数据卷。数据卷被映射到镜像，但它们被设置为容器本身之外主机文件系统Docker管理部分的子目录。

多个容器可共享一个数据卷并同时访问存储其中的数据，并且，当与其关联的容器被移除时，数据卷不会自动销毁，但如果不再需要数据卷时，你必须删除它。

数据卷实现数据库容器

除了确保数据持久性外，数据卷卷还有其他优点。它不会扩大单个容器的大小，并且，数据卷通常可提供比联合文件系统使用的存储驱动程序更好的读取和写入性能。因此，对于在Docker托管SQL Server或者在容器中运行任何数据库，一般的经验法则是将数据卷用于数据存储。

为确保不会意外丢失数据，其中一个技巧是以保证数据持久性的方式创建数据卷。例如，你可以创建永久性命名容器，并将特定数据卷与其关联。这样做可以让你安全地与SQL Server容器共享数据卷。即使所有数据库容器被移除，数据卷也不会被删除，因为它与仍然存在的容器相关联。

对于数据库管理员和开发人员来说，数据卷带来的持久数据存储使容器化SQL Server变得更可行，这是微软在发布SQL Server 2016时首次添加支持将SQL Server放在Windows系统Docker时带来的转变。随后，当SQL Server 2017发布时，微软还扩展了对基于Linux容器的支持。

尽管有这样那样的炒作，容器可能是也可能不是按需运行SQL Server 的最佳选择，因为在虚拟机中运行SQL Server更容易，但在某些情况下，容器是不错的选择。例如，如果你在内部开发数据库应用并希望确保从开发到生产的整个过程都使用相同环境时，或者你需要对SQL Server软件进行严格的版本控制，都可选择容器。