最近我有机会采访了 David Strauss，了解 Pantheon 如何使用容器来隔离从开发到生产环境的许多 Drupal 应用程序。他即将到来的 DrupalCon 演讲，大规模 PHP 容器：每台服务器 5K 个容器，将让我们了解定义和配置容器以充分利用我们的基础设施资源的技术。
最近我自己也深入研究了容器领域，我想向专家学习在生产环境中管理容器的挑战。David 运行着数百万与 Drupal 相关的生产容器，无疑是咨询这个主题的专家资源。我期待在 DrupalCon 上了解更多细节！
容器在过去几年中普及速度迅速增长。您认为这会如何具体地改变 Drupal 生态系统？
我看到了容器对 Drupal 生态系统的一些主要影响
1. 一致且丰富的堆栈： 过去，对于任何特定的守护进程组合，您都必须自己将它们连接在一起。通用发现从来没有真正适用于服务器堆栈，因为您会先部署服务，然后再附加发现，这甚至在接触身份验证/授权挑战之前就必须处理无数的不一致性。容器和编排工具颠倒了这种模型。它们从一致的可发现性、身份验证和授权模型开始，然后要求守护进程在这些约束条件下部署。这意味着现在可以组装丰富的堆栈，包括 Varnish、Solr、ElasticSearch、Beanstalk 和 Redis 等工具，并将它们与应用程序集成，而无需接触 IP、端口和密码。通过更多地访问从 PHP+MySQL 卸载到一流守护进程的方式，整个 Drupal 社区可以超越 LAMP 水平。
2. 更低的 HA（高可用性）门槛： 使用容器，可以轻松地在硬件主机 A 和 B 上部署应用程序服务器守护进程 P，同时在同一主机上部署单独的应用程序服务器 Q——所有这些都在一个操作系统镜像上。虽然您以前可以使用 VM，但操作系统的开销与中等大小的 PHP-FPM 池相比是巨大的。在某些情况下，这种操作系统开销使 VM 方法的效率只有容器的一半，这使得 HA 的成本居高不下。容器编排工具还以过去需要手动设置/干预或网络层三巧妙的方式自动化故障转移。
3. 更低的成本： 托管和开发平台可以更高效地运行，更快速地重新平衡负载，并在裸机硬件上高效地配置，从而降低传递给网站所有者/开发人员的成本和环境足迹。
运行如此多的容器，编排看起来是什么样的？管理服务器上的 5000 个容器有哪些痛点？
我们通过 Cassandra、Python、Chef、Consul 和 systemd 堆栈来处理编排，该堆栈识别哪些容器应该去哪里并配置它们。我们部署停止的容器，关闭空闲容器，并使用套接字激活按需（几乎）立即重新激活它们。
容器之间的通信通常通过相互验证的 TLS 进行。对于每个容器，我们颁发一个 x.509 证书，该证书标识容器的 UUID 以及它所属的网站和环境（开发、测试、生产等）。
在容器管理方面，您接下来想要解决哪些问题？
我们当前的项目之一是“冻结”，即完全序列化容器的能力（无论是在磁盘上存在的“水合”状态，还是像 mysqldump 生成的“脱水”导出状态）。我们正在研究容器镜像格式，例如 Rocket 支持的格式。
您如何看待开源开发对“容器革命”的影响？
我没有看到容器领域发生太多不是开源的事情！
对于一家公司或一个新的 Drupal 站点，想要彻底改革他们的开发和发布流程，您会给出什么建议？
对于编排、容器镜像，尤其是生产部署，目前还没有明确的赢家。在未来几年，我预计会出现一次洗牌——或者至少是多个兼容的实现。
Docker 非常适合连接开发堆栈，但在生产部署、密度和安全方面仍然很弱。CoreOS 具有丰富的生产部署服务和良好的安全模型，但作为一个完整的发行版而不是 CentOS 等的附加组件，它具有更高的入门门槛。Project Atomic 也值得关注，因为它与 CoreOS 竞争，但建立在更熟悉的 Red Hat 风格的基础上。systemd 拥有一套令人惊讶的丰富容器管理工具，并且越来越成为发行版上的标准 init 工具，使其成为传统发行版最开箱即用的选项。（免责声明：我是 systemd 开发人员。）libvirt-lxc 已经消亡，OpenShift 正在放弃其自研的容器工具；这是一些早期洗牌的证据。
因此，我的建议是进行实验，也许在开发环境中使用容器，但除非您准备好在一两年内从头开始重建，否则请等待部署。
DrupalCon 2015
演讲者访谈
本文是 DrupalCon 2015 演讲者访谈系列的一部分。DrupalCon 2015 汇集了来自全球各地数千名使用、开发、设计和支持 Drupal 平台的人员。它于 2015 年 5 月 11 日至 15 日在加利福尼亚州洛杉矶举行.
评论已关闭。