# 第5章 示例：Beanstalk环境 目前，大多数软件公司内部都有多套基础设施环境。这些环境具有典型的3层结构：测试、预演和生产环境。部分公司在此之外还有预生产甚至是公测（canary）环境，不过这些都是特例。不同的环境为新代码甚至是基础设施组件的生命周期提供了隔离。这些环境通常由至少一个用于应用程序逻辑和展示的Web服务器层和一个数据库层组成。过去的10多年里，这些环境在不同公司内部已经相当稳定。我们在RelateIQ发现了另外一个极佳的Docker环境示例。他们正在做的事情很有趣，有可能打破这种标准的环境模式。 RelateIQ使用AWS Beanstalk为每个分支完整地编排出一个Web环境。这是通过其CI/CD基础设施使用Docker技术创造出来的一个全新的基础设施环境。他们从根本上把Web层与数据层分开。将典型的3层模型转换成仅剩数据存储。这一点一开始可能有点儿难以想象，我们来直观地看一下（如图5-1所示）。  图5-1 图5-1展示了3个不同的分支，即PerfTest、新的APD及新的UI分支。每个分支通过CI/CD系统来构建自己的Web容器。容器被构建和测试后，将被推送到仓库中。任何开发人员或团队，都能根据需要构建各个分支的Web环境。这还允许用户以不同的方式考虑如何使用容器，同时重新考虑环境的各个部分。SaaS公司采用这种模式的巨大优势之一是适应快速变化的能力。试想一下，如果将这类环境用于持续交付模型中，产品经理和设计师会如何利用这些环境。 举个例子，RelateIQ在2014年夏季通过Docker使用这种新模式，用一个全新的外观取代CSS，完全重新设计了整个Web应用程序。他们可以在并排的Web服务器中运行A/B测试，以对新旧版本进行比较。由于开发人员会在15～30分钟内提交代码，设计师和产品经理能够在一个隔离的环境中看到最近生效的变化。使用环境变量，还能够将Web服务器后端从预演数据服务器重定向到生产数据服务器上。Docker容器快速重启后，他们就能在几分钟内看到生产数据的最近生效的变化。当RelateIQ准备上线新设计的网站时，他们只需将容器从预演数据切换到生产数据。这样，开发人员就能确保数据与新UI正确匹配。 在这个环境中，RelateIQ使用Teamcity构建和部署应用程序。他们使用VCS触发器来监控GitHub仓库中特定的分支名称，以执行自动构建。例如，他们使用了“`docker-<分支>`”这样的名称。如果仓库中创建了一个以“`docker-`”开头的分支，那么这个分支自身的Docker容器将会自动被构建。为了快速启动，大多数开发人员会在预演时直接创建分支。分支一旦创建，Teamcity就会构建这个容器并推送到一个本地仓库中。他们使用亚马逊AWS的Beanstalk服务来部署和更新容器。 “AWS Elastic Beanstalk 是一项易于使用的服务，用于在熟悉的服务器（如 Apache 、Nginx、Passenger 和 IIS ）上部署和扩展使用 Java、.NET、PHP、Node.js、Python、Ruby、GO 和 Docker 开发的 Web 应用程序和服务。 您只需上传代码，Elastic Beanstalk 即可自动处理从容量预置、负载均衡、自动扩展到应用程序健康监控的部署。同时，您能够完全控制为应用程序提供支持的 AWS 资源，并可随时访问基础资源。” ——来源于[亚马逊](http://aws.amazon.com/cn/elasticbeanstalk/) Beanstalk将自动部署一台负载均衡器，设置自动扩展组，根据设置配备相应数量的实例/服务器，拉取并运行Docker容器，提供健康监控，并且使用安全组加固服务器。对刚刚起步的公司而言，这将使其在基础设施方面走得很远。如果将其与“一个Web服务一个容器”组合起来，对SaaS公司来说，这将变成一个非常有用的环境。 部署的执行有多种方式，从Elastic Beanstalk到使用S3存储桶（bucket）的JSON文件或对服务自身的API调用。在本示例中，使用的是在Teamcity配置中创建的S3存储桶的JSON文件。构建步骤之一将写新文件，并将变化推送给S3存储桶。文件包含了容器的位置、需要打开的端口，以及容器的名称。新文件被上传后，Elastic Beanstalk环境将自动启动一台新服务器，在这台服务器上拉取容器并进行设置，然后在健康检查通过后停止旧的容器和服务器（如图5-2所示），基本上创造了新服务的零停机时间部署。  图5-2 Elastic Beanstalk的使用表明，基础设施供应商真正开始运行自有容器只是时间问题，就像他们之前运行虚拟化基础设施一样。 Elastic Beanstalk容器的日志是全自动化的，就像该基础设施的其他部分一样。可以通过GUI工具拉取日志，并选择拉取的是服务器上的完整日志还是标准输出的最后100行。这两个选项只在排错时才有用，因此他们提供了一个新选项用于将日志尾部发送到S3存储桶中。使用能读取S3服务日志的集中式日志服务让公司能将这些日志直接集成到现有日志方案中。围绕日志部分有几个注意事项。日志的名称与容器名称无关。其名称是根据一个作为服务唯一标识而随机生成的服务名称所创建的。要追踪哪个唯一标识属于哪个Elastic Beanstalk将非常麻烦。 所有通过亚马逊AWS提供的服务都内置了各自的云监控方案，也支持Elastic Beanstalk。不过，监控非常基础。能获取ELB指标和服务器指标，但无法从容器本身获取任何东西。这是由于Elastic Beanstalk服务中容器与服务器比例为1:1。这意味着网络、CPU、磁盘以及内存指标通常来自于运行于宿主机上的容器指标。如果机器出现异常，只能SSH登录到服务中进行排错或部署新版本。 Beanstalk通过安全组和IAM角色提供了自动化防火墙端口安全，以加固用户访问。由于Beanstalk使用一个很低的容器宿主机比例，就像普通的应用程序和服务器环境一样，要将容器与其他容器隔离开非常容易。Beanstalk模板保证了跨新部署时新环境的一致性，可以轻松进行跨多台宿主机的安全性修改。 通过使用Docker以及亚马逊AWS的Elastic Beanstalk自动化基础设施，RelateIQ能够在一个可扩展的模板环境中为每一位前端工程师提供一个Web环境。这个环境非常容易创建，加上CI/CD系统的一点编排，它是完全自动化的。注意：如果想在自己的基础设施中做尝试，这个环境还有很多部分处于构建状态。日志可以做得更好，因为Beanstalk环境提供的唯一标识非常难用，截至本书编写时，每个服务上已经运行一个容器（很快就能支持多容器）。请记住，使用Docker可以让环境变得异常灵活，并为推动开发速度提供新的创新方法。 在第6章中，我们将深入讲述Docker的安全性话题。