完成第一章后，你现在应该对我们正在构建的应用有了很好的理解。您还应该已经注册了 AWS 帐户，并在 IAM 中设置了管理用户。如果您跳过了介绍性章节，那么关于身份和访问管理(IAM)的教程非常重要。您必须熟悉 IAM 的主要概念，才能使用 AWS 做几乎任何事情。
接下来，我们将开始使用 OpsWorks 应用部署服务将我们的基本应用部署到 AWS 的过程。在本章中，您将在 OpsWorks 中创建一个应用实例，并首次将其部署到 Web 上。在本章中，我们不会给代码库添加任何功能。不管怎样，我们已经迈出了在云中托管应用的第一步！
有趣的是，AWS OpsWorks 并不是由 AWS 从头开始构建的。2012 年，亚马逊收购了一家名为 Peritor 的公司，该公司提供类似功能的第三方企业部署服务。这两种产品的技术基础被称为 Chef ( www.chef.io/ )，这是一个用于以编程方式配置、自动化和简化服务器部署的框架。虽然您启动的每个 EC2 实例都有预设的配置，但是使用 Chef，您只需编写很少的代码就可以轻松地对环境做出自己的更改。使用 Chef 的一个优点是，您不必了解 AWS 虚拟服务器包的所有细微差别。相反，Chef 为您提供了一个用于配置常见服务器端软件的 API，如 nginx、Apache、PHP，甚至 Node.js。在本书的后面，您将直接使用 Chef 来了解这有多简单。
OpsWorks 旨在简化应用环境的定制和管理，为应用堆栈中不同类型的资源提供图形用户界面(以及 API)。我将很快更详细地回顾这些资源。任何尝试过像 OpsWorks 那样手动配置和部署应用的人都会告诉你，这可以节省大量时间，并大大降低出错的风险。没有涉足系统管理的普通软件开发人员会发现，作为云架构师，他/她现在拥有超人的能力。
随着我们继续学习本课并讨论该服务的具体功能，使用 OpsWorks 的好处应该是不言而喻的。也就是说，在易用性方面，定制总是要付出代价的。在 2013 年 2 月一篇关于 AWS OpsWorks 发布的博客文章( www.allthingsdistributed.com/2013/02/awt-opsworks.html )中，亚马逊首席技术官沃纳·威格尔提供了图 2-1 所示的便捷图表，这是 AWS 的风格。
图 2-1。
The plane of Convenience vs. Control in AWS application deployment
此图描绘了便利性与控制性的一维平面，显示了 OpsWorks 与其他应用部署选项的相对位置。如您所见，OpsWorks 介于管理应用堆栈的 DIY 方法和更简单、更少定制的弹性 Beanstalk 之间。如果这让你停下来重新评估 OpsWorks 是否真的是最适合你的想法，不要担心。有些人认为 OpsWorks 是弹性豆茎的下一代翻版。你与 AWS 合作的时间越长，你就越会看到它们推出新的功能和服务之间更好的协同作用。有时，这些改进的速度可能会令人无法抗拒:每隔几周，您就会收到 AWS 的一封电子邮件，通知您可能会在您的应用中使用六个新功能。因此，不要太担心星盘。在 AWS 世界中，两年是一段很长的时间，重要的是，对于 AWS 提供的服务，有一个广泛的抽象范围，它产生了一系列的功能和限制，这取决于服务是如何设计的。
此外，当我们用 OpsWorks 部署我们的应用时，我们在应用中使用了许多其他的 AWS 服务。最终产品将真正是其各部分的总和。在课程结束时，通过一些努力，你可能会明白如何将 OpsWorks 替换为 Elastic Beanstalk 或 CloudFormation。图 2-1 仅仅说明了当你戴上云架构师的帽子时，需要进行成本效益分析。
稍后，我们将开始探索 OpsWorks 控制面板。我们将回顾它的各种特性，同时了解对 OpsWorks 至关重要的各种其他 AWS 服务。我们还将一瞥基础技术厨师如何仍然与像我们这样的 AWS 用户相关。当您在 OpsWorks 中分配资源时，您的 AWS 帐户将开始产生使用费。在自问是否需要十个 m 3.2 x 大型 EC2 实例来托管 Photoalbums 应用时，请记住这一点。但是在我们开始在 OpsWorks 中分配资源之前，我们应该对这些资源多了解一点。
当您分配 EC2 实例、RDS (Rational Database Service)数据库实例和许多其他资源时，您做出的最重要的决定是什么和在哪里。什么是不言自明的。AWS 对这些资源有自己的定价等级，您可以在官方文档中找到。使用和定价之间的关系因服务而异，它们被单独记录。
例如，EC2 实例是根据功率(内存、CPU 时钟速度和物理处理器)×小时速率×小时数来预留的。为了回顾 EC2 实例类型的规范，这里提供了一个分类: http://aws.amazon.com/ec2/instance-types/ 。在确定实例类型时，您将使用您的判断，将您的技术需求与您的财务资源进行比较，交叉引用实例类型与此处的定价: http://aws.amazon.com/ec2/pricing/ 。虽然传统的托管服务(还有一些云托管平台)会对你预定的资源按月收费，但按小时收费才是 AWS 如此有用的原因。还是那句话，用什么付什么。这就是资源。在哪里是一个单独的问题，如果你从传统的主机转移，这是一个新的概念。
Caution
一旦您提供了您的账单信息，AWS 将允许您根据需要提供昂贵的资源。如果您是 AWS 新手，请小心请求过多的资源。每小时 1.50 美元听起来并不多，除非你不小心让一个实例在线三个月。
许多人认为云是某种模糊的、没有位置的全球实体。当然，仍然有真实的服务器和数据中心——数据并不是真的漂浮在对流层中。AWS 在全球各地运行数据中心，通常在地理上靠近主要的人口中心。在大多数情况下，有几个数据中心服务于相同的地理区域或地区。这些地区的名称有美国东部(北弗吉尼亚)、美国西部(俄勒冈州)和亚太地区(东京)。虽然地区的名称通常描述了西欧等大陆地区，但括号中的位置描述了数据中心所在的更具体的区域(参见图 2-2 )。请记住，AWS 在一个地区的其他地方维护额外的支持基础架构，并且并非所有服务在所有地区都可用。你可以在 http://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ 找到更详细的信息。
图 2-2。
AWS region data centers mapped (not pictured: GovCloud region)
地理在构建 web 应用时非常重要。无论你的代码有多快，或者你运行着多少台服务器，你的数据仍然要通过网络与用户交换。自拨号上网时代以来，随着技术的发展，用户的期望也发生了巨大的变化。你的最佳选择是将你的应用放在离你的预期用户群最近的地方。
Note
我将在第 4 章和第 5 章中与 S3 和 CloudFront 讨论在全球范围内发布你的内容的其他方式。
如前所述，许多地区有不止一个物理数据中心。如果某种服务中断暂时使一个数据中心无法运行，其他数据中心会保持该区域在线。这些数据中心在 AWS 服务中被抽象为可用性区域。在每个可用性区域内都有 EC2 实例和我们提供的其他资源。您可以将可用性区域视为包含运行 AWS 服务的硬件的数据中心。这个概念如图 2-3 所示。
图 2-3。
Illustration of a region containing four distinct availability zones
现在您已经熟悉了区域和可用性区域的概念，您可以开始考虑不同的场景了。本质上，我们仍然在现实世界中使用物理服务器。他们会崩溃；他们可以失去权力；他们可以有一个随机部分失败，等等。有无数的故障点，如果您的所有 EC2 实例都在一个可用性区域中，并且该区域断电了，该怎么办？您的应用将脱机。事实上，可以肯定的是，在某个时刻，您的某个可用性区域将会出现孤立的中断，因此我们要为此做好准备。
人们可以写一本关于云架构应急计划的书。就本书的范围而言，我们将保持简单。我们的应用将托管在单个区域中，实例位于多个可用性区域中。我们将使用其他 AWS 服务在其他地区更快地分发我们的内容。如果我们想要额外的冗余，我们也可以将我们的应用克隆到不同的地区。只要我们的数据库在所有地区保持同步，我们就可以随意复制我们的应用。我将在整本书中讨论这些种类的优化。
在我们进入 OpsWorks 仪表板之前，我们将在身份和访问管理中创建一个新角色。在第一章中，您在 PhotoAdmins IAM 组中创建了一个管理级别的用户，该用户应该能够在 OpsWorks 中执行任何任务。我还讨论了在我们的代码中存储凭证的安全风险，以防开发人员离开项目或装有应用本地副本的机器被盗或丢失。
为了避免这些风险，我们将使用 IAM 角色来管理与其他服务的认证。我们实际上需要两个新的 IAM 角色:一个用于托管我们的应用的 EC2 实例，另一个允许整个应用栈代表我们行事。通过为我们的实例创建一个角色，通常称为实例角色，我们可以通过 AWS API 以编程方式访问其他 AWS 服务，而无需在源代码中存储安全凭证。我们将首先创建这个角色。
返回 IAM 控制面板，单击左侧导航栏中的“角色”。找到页面顶部的“创建新角色”按钮，然后单击它。在下一个屏幕上，将提示您输入角色的名称，如图 2-4 所示。
图 2-4。
Set Role Name
我们希望我们的角色有一个逻辑名称，所以我们将使用 AWS-ops works-photoalbums-ec2-role，photo albums 应用中 EC2 实例的角色，它由 AWS OpsWorks 初始化。您可以使用任何有意义的约定，但我们使用的是[服务]-[应用]-[角色]的格式。单击下一步继续。同样，在为此角色创建 IAM 策略时，我们有许多选项可供选择。现在，我们将创建一个没有策略的基本角色。随着我们继续阅读本书的其余部分，我们将为这个角色添加更多的策略。首先会提示您选择角色类型。在服务角色选项框中，您会在列表顶部看到 Amazon EC2。单击选择按钮前进。
我们将再次能够选择策略(参见图 2-5 )。我们稍后将附加一个策略，因此请单击“下一步”继续查看视图。
图 2-5。
Selecting no policies for the aws-opsworks-photoalbums-ec2-role
在下一个视图中，您有机会在创建角色之前检查它。如果一切正常，单击创建角色。我们现在有了一个角色，可以分配给运行我们应用的 EC2 实例。然而，我们仍然需要整个应用堆栈本身的角色。
作为一个 OpsWorks 应用，我们的堆栈将需要权限来执行常规任务，比如重启实例、向 AWS 控制台报告指标等。作为用户，您可以在 OpsWorks 仪表板周围单击，并手动执行各种任务。我们希望确保我们创建的应用能够自己执行这些操作。我们将通过为整个应用堆栈创建一个角色来确保这一点。这个角色通常被称为服务角色。一旦创建了这个角色，我们就可以进入 OpsWorks 仪表板来创建我们的应用了。
返回 IAM 仪表板中的“角色”选项卡，再次单击“创建新角色”。我们再次需要为我们的新角色取一个名字。按照我们之前的命名约定，我们将把这个命名为 AWS-ops works-photo albums-service-role。命名约定也是[服务]-[应用]-[角色]。继续下一步将把您带到选择角色类型视图，在这里 AWS 服务角色已经打开并在您面前列出。将此列表向下滚动到末尾，在那里您会找到 AWS OpsWorks，然后单击 Select。在附加策略视图中，将只有一个可能的策略可供选择:AWSOpsWorksRole。这是 AWS 为 OpsWorks 服务角色提供的默认托管策略。选择该框，然后单击下一步。再次查看策略，并通过单击“创建角色”完成该过程。
您将返回到 Roles 视图，在这里您将看到您的新角色已经创建。选择您的新角色，进入角色详细信息视图。在权限标题下，您会看到 AWSOpsWorksRole 是唯一的策略(参见图 2-6 )。单击 Show Policy，将出现一个模态视图。
图 2-6。
Policies attached to the aws-opsworks-photoalbums-service-role
在模态视图中，您将有机会查看策略文档的原始 JSON。JSON 应该类似于清单 2-1 ，如下所示:
Listing 2-1. The OpsWorks Service Role Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstances",
"ec2:DescribeKeyPairs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticloadbalancing:DescribeInstanceHealth",
"elasticloadbalancing:DescribeLoadBalancers",
"iam:GetRolePolicy",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListUsers",
"iam:PassRole",
"opsworks:*",
"rds:*"
],
"Resource": [
"*"
]
}
]
}
您会注意到在Statement数组中有一个 JSON 对象，它具有属性Effect、Action和Resource。Effect应该是不言自明的:我们在这个语句中特别启用了权限。接下来，Action是一组 AWS 服务和动作。这些可能以后会更有意义，但是你可以通过观察它们来了解它们是什么。您可以从第一个操作中看到，对于默认的 OpsWorks 角色，我们只为GetMetricStatistics启用了 CloudWatch API 权限，但是我们为 EC2 和 Elastic Load Balancing 启用了各种读取权限，并为 OpsWorks 和 RDS 启用了所有操作。很快您就会看到，这些服务可以在 OpsWorks 中直接初始化和配置，因此堆栈拥有这些权限非常重要。
您还会注意到这里有一个非常重要的动作，名为iam:PassRole。该权限将允许您的应用将其角色传递给它所管理的 EC2 实例，使它们能够代表服务角色执行任务。这很重要，你很快就会发现原因。
最后，Resource数组只包含“*”，即所有资源。为了简单起见，我们提供 IAM 角色用于所有资源，即使它们是专门为我们的应用命名的。将来，您可以返回到这些角色的策略文档，并将它们限制为应用的资源。您将了解到在策略文档中定位特定资源的能力是一个强大的特性。
不幸的是，默认的 OpsWorks 服务角色对于我们的目的来说不够强大。如前所述，我们只有 EC2 的读取权限。然而，我们希望能够在 OpsWorks 中创建资源，因此我们需要附加一个额外的策略。从“AWS-ops works-photo albums-service-role”的详细视图中，单击“Attach Policy”以添加另一个托管策略。从策略列表中选择 AmazonEC2FullAccess，然后单击附加策略。您将返回到角色详细信息视图，并且应该看到现在有两个托管策略附加到该角色。
为了遵循最佳实践，Amazon 建议撤销根帐户访问密钥，并为根帐户启用多因素身份验证。您可以随意遵循这些指南，但是您至少应该学会如何通过用户帐户而不是根帐户来管理您的架构。然而，当在 OpsWorks 中创建我们的第一个应用堆栈时，我们必须拥有 IAM 管理员访问权限，在第 1 章中，我们没有将此权限授予我们的 PhotoAdmins 组。因此，创建我们的应用堆栈将是我们作为根用户的最后一个动作。虽然您现在可能拥有 AWS 帐户的 root 访问权限，但最好养成在任何 AWS 帐户(即您的雇主或客户的帐户)上作为用户工作的习惯。
到目前为止，您已经在 IAM 中做了很多工作，并且了解了很多我们还没有开始直接使用的技术。这可能有点令人困惑，因为我们已经快速地学习了一些非常抽象的概念。概括地说，这是迄今为止您使用 IAM 和 OpsWorks 所取得的成果:
- 您使用 root 帐户登录 AWS，该帐户在 IAM 中使用过，接下来将用于创建您的第一个应用堆栈。
- 您已经创建了一个 PhotoAdmins 组并定义了它的策略，授予该组管理大量 AWS 服务的权限，我们稍后将使用这些服务。
- 您向 PhotoAdmins 组添加了一个用户，以后您可以使用该用户在 AWS 控制台中登录并使用您的应用。
- 您已经为应用堆栈中的 EC2 实例创建了实例角色。
- 您已经为您的应用堆栈本身创建了一个服务角色。
在我们继续学习 OpsWorks 仪表板之前，我们还需要进行一个步骤来了解 SSH 密钥。请注意，这一步是完全可选的。对于示例应用，您不需要学习这一课，但是学习起来可能会很方便。如果你现在不想学这个，跳过下面的部分。
QUICK DETOUR: SSH KEYS
我们之前了解到，运行 Amazon Linux 实例的好处之一是严格的默认安全设置。开箱即用，您的实例只能通过 SSH 连接—FTP、SFTP 和其他常见的连接方法被禁用。要启用它们，您必须在 AWS 中打开正确的端口，并在命令行上安装软件，这本身就是一个单独的教程。要设置这些方法，您首先需要能够通过 SSH 连接到您的实例。幸运的是，Amazon 使得为实例生成密钥变得很容易。
如果我们必须为应用中的每个实例存储一个单独的 SSH 密钥，这不是很烦人吗？除了丢失和混淆键的风险之外，在栈中添加和删除实例将是一个更加劳动密集型的过程。Amazon 让这变得简单了，它允许我们在 AWS 控制台中创建一个 SSH 密钥，并将其设置为栈中所有实例的默认密钥。理论上，您可以对所有堆栈使用一个主密钥，但是每个堆栈一个密钥似乎更有意义。现在让我们继续创建我们的密钥。首先，我们必须前往 EC2 仪表板。为此，您可以单击左上角的橙色框图标，或者打开它旁边的服务菜单，然后在“计算和网络”部分找到 EC2，如下图所示。有时，如果您不确定在哪个类别中可以找到您需要的服务，返回 AWS 控制台会更容易。
EC2 仪表盘上有很多东西，比我现在需要详细查看的还要多。我们以后会在这里多呆些时间。在左侧导航中，您应该会看到一系列可折叠的部分，默认情况下它们是展开的。在“网络与安全”下，单击“密钥对”，如下图所示:
在这里，您将看到为 EC2 实例生成的所有 SSH 密钥的列表。这些密钥的加密是 1024 位 SSH-2 RSA。每个区域有 5，000 个键的限制，但大多数用户似乎不太可能接近这个上限。除了在控制台中创建您的密钥对之外，您还可以自己生成它们并将其导入 AWS 然而，这超出了本书的范围。
注意:如果删除密钥对，不会影响已经使用它们的实例。如果您有私钥的副本，您仍然可以连接到您的实例。但是，您将无法使用已删除的密钥对预配新实例。
到目前为止，AWS 中的一些 UI 设计选择应该开始变得熟悉了。与 IAM 类似，Create Key Pair 按钮位于主要内容区域的左上角。这只是打开一个模态窗口，您可以在其中命名密钥对，而不是开始一个多步骤的过程。让我们将其命名为 aws-opsworks-photoalbums-key，遵循与我们之前创建的 IAM 角色类似的命名约定。
当您单击 Create 时，将会生成密钥，并且一个名为aws-opsworks-photoalbums-key.pem的文件应该会自动下载到您的机器上。扩展名.pem是“隐私增强邮件”的缩写，这个文件被称为私钥。
AWS 将生成并存储相应的公钥，形成一个密钥对。公钥的副本将被保存到使用该密钥对提供的所有实例中，并且您必须提供匹配的私钥，以便使用 Amazon 提供的 Java 插件在命令行或浏览器中与您的实例建立安全连接。我们还没有任何实例，所以我们现在不会使用私钥来连接任何东西。将密钥保存在安全的地方，最好备份在某个地方。(提示:您可以将一个副本存储在一个私有的 S3 桶中，我们稍后将设置这个桶。)
当我们在 OpsWorks 中设置第一个应用时，了解我们的工具是什么非常重要。幸运的是，Amazon 为 OpsWorks 环境提供了一个很好的例子，因为它与一个 PHP 应用有关。你可以在图 2-7 中找到。
图 2-7。
The components of an OpsWorks stack
如您所见，AWS 中应用的所有组件都分组在 OpsWorks 堆栈中。堆栈是组成应用部署的所有组件的集合。您可能以前听说过应用堆栈这个术语；我一直在频繁使用它。OpsWorks 堆栈就是 AWS 环境中的应用堆栈。与传统的宿主环境不同，OpsWorks 中的堆栈组织分配给应用的所有资源。
在图 2-7 中，您可以看到包含在 OpsWorks 堆栈中的 PHP 应用服务器层。根据它的复杂性，我们的应用可以有很多层。对于像我们这样的基本 web 应用，只有几层:应用托管服务器(EC2 实例)、负载平衡器和数据库。
您还会注意到，应用与应用服务器实例是截然不同的。这代表了我们的应用的实际源代码，堆栈将负责部署它。OpsWorks 从代码库中检索源代码(通过互联网),并将源代码部署到我们的实例中。根据在堆栈、层和应用源代码级别定义的要求，OpsWorks 将确保正确配置实例，安装依赖项，并在实例上上传和运行应用。我将很快讨论这些组件中关注点的分离。
我们走了一些大的弯路，但最终是时候在 OpsWorks 中创建您的应用了。在 AWS 控制台中，在服务列表(中间列)中找到 OpsWorks 并单击它。由于巨大的“欢迎使用 OpsWorks”标题，您现在应该可以清楚地看到 OpsWorks 仪表板。您会注意到一个蓝色的大按钮，上面写着添加第一个堆栈。
想象一下，我们在一个传统的共享主机提供商上托管我们的应用。您可以使用您的帐户登录管理控制台来管理您的资源。您可能在一个选项卡中有一些 web 应用，然后在另一个选项卡中有一些数据库，甚至所有应用都托管在同一个数据库的不同表中。在这种模式下，管理很快就会变得混乱。你受到你自己、你的同事和/或你的前任的支配，希望遵循合乎逻辑的命名惯例。甚至一些云托管平台仍然是这样，这大大增加了人为错误的风险，在这位作者看来。
每个堆栈由一组独立的资源组成，这意味着影响一个应用的问题仅限于该应用。如果你的一个应用崩溃了，被黑了，或者耗尽了资源，变得没有反应，其他栈不会受到影响。因为我们将在多个可用性区域中创建实例，所以导致我们的应用宕机的唯一外部因素是主要的 AWS 服务崩溃。听起来是部署应用的好方法，对吗？
在 OpsWorks 中，您可以创建任意多的堆栈，它会将项目的所有资源整齐地组织到每个堆栈中。这对于创建开发和登台环境特别有用，因为每个堆栈上都有一个克隆按钮！您还可以一键启动和停止所有服务，并同时在所有实例上运行命令。如此简单却又如此强大！让我们把相册放到网上吧。继续并单击添加第一个堆栈。下一页发生了很多事情，如图 2-8 所示。
图 2-8。
Creating an application stack in OpsWorks
第一个领域很简单，输入相册，然后进入下一个领域。现在我们必须选择一个地区。有可能辨别你的目标受众的地理位置吗？亚马逊的主要数据中心在弗吉尼亚州北部，因此该地区默认为美国东部。除非你有理由改变这一点，否则我们可以让它保持原样。
下一个字段询问您是否要选择 VPC 或虚拟私有云( http://aws.amazon.com/vpc/ )。如果您想要将应用部署到专用网络，您可以将应用分配到此处的 VPC。在我们的例子中，我们正在构建一个供公众在网上消费的应用，所以我们不会选择 VPC。VPC 可以包含公共子网和私有子网，但这可能是续集的主题！
Note
如果要使用 VPC，必须在创建 OpsWorks 应用之前创建它。
我已经谈到了可用性区域，所以您知道您创建的每个实例都将在特定的可用性区域中运行。当您分配新实例时，默认可用性区域只是预选的可用性区域。这是一个纯粹为了方便而设计的字段。如果您正在管理大量实例，并且知道您希望它们位于特定的可用性区域中，那么在这里选择它可以省去以后在大量实例上更改区域的麻烦。但是，您当然可以在以后更改实例的可用性区域。让我们在这里保留默认值。
您将会看到默认操作系统下拉菜单为您提供了一些选择。除非你正在构建一个明确需要 Ubuntu 的应用，否则你很可能会选择最新版本的 Amazon Linux。截至发稿时，最新的是亚马逊 Linux 2014.09。
Amazon Linux 是基于 Red Hat Enterprise Linux 的 Linux 版本，由 Amazon 管理。它是专门为部署到 EC2 实例而设计的，值得注意的一个主要特性是 Amazon Linux 是为 AWS 环境中的最大安全性而定制的。默认情况下，远程访问 Amazon Linux 实例的唯一方式是通过 SSH。可以通过 AWS 控制台打开其他方法。与部署你从网上下载的 Linux 版本相比，Amazon Linux 的安全配置让你放心，因为它已经通过了专家的安全缺陷检查，而没有太多的限制，以免损害你的软件。
这带来了另一点，即通过利用云，我们试图避免陷入操作系统配置的地狱。我们不想部署定制版的 Ubuntu 我们希望启动一个实例，并知道它已经准备好以启动的速度运行我们的软件。如果我们不能信任运行在我们众多服务器上的操作系统，那么我们又回到了起点。亚马逊已经写了很多关于他们构建 Linux 的文章，你可以在这里找到全部: http://aws.amazon.com/amazon-linux-ami/ 。
您会注意到，除了 Amazon Linux 和 Ubuntu，您还可以选择使用自定义 AMI。此选项允许您创建运行特定软件包的实例，或者，如果您愿意，可以将实例锁定到特定版本的操作系统。亚马逊支持这一功能，但似乎不太情愿。它建议您应该使用 Amazon Linux，然后使用 Chef 定制您的安装，如果需要的话。这是最佳实践，但是您可以选择做您想做的任何事情。如果您使用 Chef 而不是自定义 AMI，那么您将受益于 Amazon 对您的操作系统的持续支持，同时允许您进行自定义选择。选择 Amazon Linux 并继续。
啊哦！又一个陌生的问题。我们的默认根设备类型应该是实例存储还是 EBS 支持的？这一切意味着什么？基于到目前为止对 EC2 实例的讨论，您现在应该认识到这些实例是短暂的。当您停止一个实例时(无论是否选择)，存储在该实例上的所有数据都将丢失。因此，依赖 EC2 实例来实现数据持久性并不是一个好主意。即使 EC2 实例提供了永久的数据持久性，我们会想要使用它们吗？AWS 应该使基础设施更容易管理，管理跨实例存储的唯一数据可能会变得复杂。
亚马逊对这个问题的解决方案叫做弹性块存储。借助 EBS，您可以为持久数据存储提供可扩展的磁盘驱动器。您一次只能将一个 EBS 实例附加到一个 EC2 实例，但是您可以获取我们的 EBS 的快照，并使用它来实例化一个新的 EBS。
这在我们的应用中有用吗？最终，我们将接受文件上传并存储，供用户通过网络访问。您肯定知道您需要持久的磁盘存储，并且我们希望在多个 EC2 实例上运行我们的应用。显然，这不是解决方案，因为存在实例过时的风险。很高兴知道这个功能的存在；它只是不适合我们的用例。
我们知道我们将需要一些持久的数据存储，并且我们知道 EBS 不能用于多个实例。因此，我们现在可以选择实例存储，因为我们知道只能在 EC2 实例上存储临时数据。这意味着文件上传、日志文件等。，将不得不存储在其他地方，我们将很快更详细地讨论这一点。
选择实例存储作为默认根设备类型后，您必须选择一个 IAM 角色。这是我们之前创建的堆栈级服务角色。从下拉列表中选择 AWS-ops works-相册-服务-角色。接下来，我们可以选择设置默认的 SSH 密钥。如果您经常需要在命令行上连接到实例，这是一个很方便的字段。它通过假设堆栈中的所有 EC2 实例应该使用相同的密钥来简化密钥管理，这是一种比为每个实例生成一个新的密钥对好得多的方法。我们的应用不需要这个，所以您可以选择不选择默认的 SSH 密钥。提醒一下，SSH 密钥在本章前面已经详细讨论过了。如果您按照这些步骤创建了一个密钥对，现在就从下拉列表中选择它。
接下来，我们必须选择默认的 IAM 实例配置文件。您还记得，我们之前创建了两个 IAM 角色:一个服务角色和一个实例角色。这是我们选择实例角色的地方，AWS-ops works-photo albums-ec2-role。您会注意到，在此屏幕中，您可以选择动态创建一个新角色，这将使 OpsWorks 自动为您生成一个角色。
说到命名约定，下一个选项可能是令人困惑的主机名主题。下拉菜单中有很多选项，如“烘焙食品”、“欧洲城市”、“野猫”等。当您在 OpsWorks 中创建 EC2 实例时，您不希望它们仅仅被命名为 instance-1、instance-2 等。主机名主题选项只是用于实例的主题名称，如“Photoalbums - london-1”或“Photoalbums - paris-2”等。你可以选择任何让你开心的事情，但是请注意列表中的第一个选项，图层依赖。这将根据实例所属的 OpsWorks 层来命名实例，我们稍后将回顾这个概念。我倾向于选择这个选项，因为这意味着您的实例将被命名为“Photoalbums nodejs-app1”、“Photoalbums nodejs-app2”等。在接下来的课程中，我们将使用层相关主题，但是如果你认为用猫命名服务器会很有趣的话，你可以随意选择另一个选项。
最后是堆栈颜色，这没有任何技术意义。这是用于 OpsWorks 仪表板中堆栈的配色方案，纯属个人喜好。让我们选择最右边的红色。
现在我们终于准备好点击右下角的添加堆栈。我们选择的选项出现在清单 2-2 中。再次检查您的选择，然后单击按钮。
Listing 2-2. Summary of Stack Creation Options
Name: Photoalbums
Region: US East
VPC: No VPC
Default Availability Zone: us-east-1a
Default operating system: Amazon Linux 2014.09
Default root device type: Instance store
IAM role: aws-opsworks-photoalbums-service-role
Default SSH key: aws-opsworks-photoalbums-key (optional)
Default IAM instance profile: aws-opsworks-photoalbums-ec2-role
Hostname theme: Layer Dependent
Stack color: red
恭喜你！您已经创建了第一个堆栈。我们现在处于 stack detail 视图中，该视图应列出设置应用的下四个主要步骤:
- 添加你的第一层。
- 添加您的第一个实例。
- 添加你的第一个应用。
- 在线查看您的申请。
所以，是的，在这一课中我们还有很长的路要走。请记住，本章的目标只是通过 OpsWorks 部署在 Web 上看到“Hello World”。下一步是了解图层。
层是应用的主要软件成分，以及与之配套的硬件。让我们稍微分解一下。当您在第一章中设置本地环境时，您必须完成两个主要任务:运行 Node.js 环境和运行数据库。这是我们应用的两个层次。在 OpsWorks 中，每一层都需要分配资源。
第一层，我们的 Node.js 应用，没有运行代码的机器是没有用的——它只是页面上的文字！因此，我们的 Node.js 应用层需要分配 EC2 实例。Layers 视图允许您将这些移动的部分联系在一起:源代码、环境和运行这两者的实例。
第二层，数据库层，有点不同。我们将使用 Amazon RDS 托管我们的数据库，我们将在后面的章节中设置它。就目前而言，理解这种看待问题的方式就足够了。
每个堆栈必须至少有一层，其中有两种类型:OpsWorks 层和 service 层。OpsWorks 层只是分配给它的 EC2 实例的蓝图。OpsWorks 为您提供了许多预设的 OpsWorks 层类型，这些层类型本身被分类为负载平衡器、应用服务器、数据库或其他。对于某些 OpsWorks 层子类型(尤其是 App Server)，您可能需要基于同一蓝图的多个实例。其他类型，如负载平衡器，通常只用于单个实例。
除了 OpsWorks 层，AWS 还提供了第二种类型，我们称之为服务层。服务层允许您将其他 AWS 服务作为层添加到 OpsWorks 堆栈中。目前，仅支持一种服务层类型:RDS。我希望将来会推出更多的服务。
是时候创建我们的第一层了。在堆栈详细信息页面的第一个标题下，单击添加层。就像我们创建堆栈时一样，我们会看到许多选项，如图 2-9 所示。
图 2-9。
Add Layer view
您可以看到主要的层类型是通过顶部的选项卡来区分的。我们还没有准备好添加 RDS(服务)层，因此我们将停留在 OpsWorks 选项卡中。我们的第一个选择是层类型。这是组织不同 OpsWorks 图层类型的地方。打开下拉菜单，你会看到一个列表，如图 2-10 所示。
图 2-10。
OpsWorks layer types
默认情况下，应用服务器标题下的 Rails 应用服务器是选中的。我们将选择 Node.js 应用服务器。突然间，我们的很多选择都消失了。嗯，那就简单了！下一个字段是 Node.js 版本。这使您可以选择使用不推荐的 Node.js 版本，以防您正在部署一个尚未在 Node.js 的最新版本中测试的应用。在撰写本文时，我们将坚持使用最新的 0.10.29 版本。
最后一个选项是弹性负载平衡器。我们将在下一章添加一个 ELB 到我们的堆栈中，所以我们暂时跳过这个。将此字段留空，然后单击添加层按钮。就这么简单！我们已经得到了我们的第一层，你应该被引导到层屏幕，如图 2-11 所示。
图 2-11。
Layers view
现在我们的堆栈中只有一层，那就是应用服务器层。运行我们的应用的所有 EC2 实例都将是这一层的一部分。如果你需要复习这是如何工作的，再看一下图 2-7 。
如您所见，在 OpsWorks 仪表板中已经有许多新的地方可供探索。接下来，让我们继续将我们的第一个实例添加到层中。单击屏幕右侧的添加实例按钮。下一个视图有一些介绍性的文字，以及图 2-12 中的界面。
图 2-12。
Add an instance
你会注意到只有几个设置可供选择。大多数配置都基于我们在创建堆栈时选择的默认值。例如，Hostname 字段根据我们之前选择的主机名主题预先填充了一个唯一的名称。您可以将其保留为 nodejs-app1，除非您有自己的命名约定。
可能最大的决定(没有双关语)是大小。您将在这里看到一个长长的选项列表，包括当前一代和上一代的尺寸，以及各种优化选项。亚马逊定期发布新一代实例，其规格和价位与上一代不同。你可以在这里对照这个列表: http://aws.amazon.com/ec2/instance-types/#Instance_Types 。为了不让这个页面变得过于臃肿，前代的规格被移到这里单独的一页: http://aws.amazon.com/ec2/previous-generation/ 。
在生产环境中，当创建应用服务器层的第一个实例时，您必须考虑很多因素。我将在后面详细讨论这一点。现在，选择列表中最小和最便宜的选项 t1.micro 是有意义的，一直到最底部。
接下来，我们为此实例选择可用性区域。同样，我们在创建堆栈时选择的默认值也被选中。您可以更改可用区域，但现在让它保持为 us-east-1a。我们稍后将在其他区域中创建实例，因此我们希望在默认区域中至少保留一个实例。继续并点击高级，这样您就可以看到额外的选项。
首先是扩容类型。这是我们稍后将深入研究的主题，但是现在我们希望我们的实例 24/7 在线，所以我们将选择该选项。您将在堆栈创建过程中认识到的其他字段。让我们不去管这些默认值，但是如果您想在实例级修改它们，最好知道它们在这里。点击 Add Instance，您将进入 Instances detail 视图，这是一个您非常熟悉的屏幕(见图 2-13 )。
图 2-13。
Instances view
在此视图中，您可以看到层中所有实例的状态。顶部的圆形图显示了处于各种状态的实例的数量和百分比:联机、启动、关闭、停止或错误。我们目前有一个实例已经停止，所以这里没有太多可操作的信息。在右上方，您会注意到一个按钮，上面写着 Start All Instances，这正是它所说的。您还可以单独启动或停止实例，例如，如果您想要手动扩展其中一个实例。或者，如果您想要手动扩展许多实例，您可以一次停止一个实例，扩展它们，然后重新启动它们，这样您的应用就不会出现任何停机。您还可以在此屏幕上向您的层添加更多实例。
在顶部黑色的 AWS 导航栏下面，您会注意到 OpsWorks 附加了一个灰色的导航栏。在左侧，您可以导航到当前堆栈，紧挨着它的是一个下拉菜单，可以导航到完全不同的堆栈或创建一个新的堆栈。单击导航按钮，您应该会看到类似于图 2-14 所示的下拉菜单。
图 2-14。
OpsWorks stack navigation menu
您将看到一些我们已经参观过的视图，以及一些不熟悉的视图。选择应用，我们将最终在 OpsWorks 中创建应用。
Apps 视图顶部的介绍性文本解释了这个概念，正如我所希望的那样:
An application represents the code stored in the repository that you want to install on the application server instance. When you deploy the application, OpsWorks downloads the code from the repository to the specified server instance.
当我们创建应用时，我们将 OpsWorks 配置为获取示例应用的副本，并将其部署到应用服务器层中的每个实例，然后启动这些实例。您应该会看到一个蓝色消息框，通知您没有应用，但可以添加应用。点击这个，我们就可以开始创建这个应用了。
首先是名称字段，您可以在其中输入相册的名称。下一个字段是 Type，它应该默认为 Node.js，所以我们可以不去管它。下一部分的标题是数据源，在这里您可以选择想要使用哪种类型的数据库。您可以选择 RDS，这是一个服务层。如果您希望在 OpsWorks 中创建 MySQL 数据库层，可以选择 ops works；如果您托管的是静态应用，则可以选择 None。我们将选择 RDS 并在稍后创建一个 RDS 实例(参见图 2-15 )。
图 2-15。
Add an app to your OpsWorks stack
我们已经到了一个重要的决策点:我们如何将我们的源代码部署到我们的服务器上？这是一个重要的决定，不是对你的应用的功能，而是对你的开发团队的工作流程。我们将逐一查看这些选项。您可以选择最适合自己的方法，在以后的课程中，我将假设您可以自己管理部署。图 2-16 显示了一个示例配置。
图 2-16。
Application Source configuration in OpsWorks app
如果您打开 Repository type 菜单，您将会在三个标题下看到五种类型:源代码控制、Bundle 和其他。如果从源代码管理部署，则提供 URL 和凭据，这将允许 OpsWorks 连接到您的存储库并从指定的分支下载源代码。如果您选择 Bundle，OpsWorks 将从指定位置检索一个 zip 文件，将其解压缩，然后运行应用。最后一个选项是其他，是针对更高级的用户。您可以使用 Chef recipes 来处理部署过程，而不是由 OpsWorks 检索您的代码。
如果您熟悉 GitHub，最简单的方法是从您自己的 GitHub 库进行部署。如果您使用另一个允许您通过 SSH 连接的 Git 存储库服务，过程基本上是相同的。我将在下面描述不同的方法，你可以选择适合你的方法并继续下去。
您将需要生成一个 SSH 密钥，以便 OpsWorks 可以连接到您的存储库。如果你需要帮助，这里有一个方便的指南: https://help.github.com/articles/generating-ssh-keys/ 。
Note
生成 SSH 密钥时，不要设置密码。OpsWorks 不支持带密码的 SSH 密钥，您将无法使用您的密钥进行部署。
生成密钥后，我们可以填写字段。首先是资源库 URL，您可以在 GitHub 的屏幕右侧找到它(参见图 2-17 )。如果您使用 Beanstalk 或其他存储库服务，您会在类似的侧栏中找到 SSH 克隆 URL。
图 2-17。
SSH clone URL in GitHub
将 SSH 克隆 URL 复制到剪贴板，并粘贴到 OpsWorks 中的存储库 URL 字段。接下来，我们需要您生成的私钥。它应该被命名为“github_rsa”之类的东西，并位于您计算机上的./ssh中。在纯文本编辑器中打开文件。它应该如下所示:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,3048941ED91AFBCE12E396E516EC35D4
0gkTkCilHDYOgommrpNVlmZjtKxrD4smsFOVgvhweaNv0G8aTMQcjYb461TqwdsJ
{{A BUNCH OF RANDOM CHARACTERS}}
iLOdRv+4XFKhN3ZKyJ9VwV0yxrV6hSR0FOwFzGtXAD8OJctMcyAwGctJJmNQmRe2
-----END RSA PRIVATE KEY-----
将文件内容复制到剪贴板上，并粘贴到存储库 SSH 密钥字段中。最后，您可以选择一个特定的分支/修订来部署。默认情况下使用 HEAD，所以我们不去管它。例如，如果您正在创建一个新的堆栈作为您的开发环境，您应该在这里输入您的开发分支名称。
与 Git 一样，您将为 OpsWorks 提供连接到您的存储库和下载源代码副本的凭证。使用 Subversion，您必须通过 HTTP 连接，提供您的帐户用户名和密码。与 OpsWorks 一样，您可以指定要部署的特定版本。但是，请注意，这次您必须在存储库 URL 中包含代码的完整路径。如果要从特定分支进行部署，请确保在存储库 URL 中包含目录路径。
如果您没有使用代码存储库，或者出于某种原因，您不想将目录从 repo 部署到 OpsWorks，还有一些其他选项。首先，您可以从 Web 上任何地方托管的归档进行部署。如果您选择 HTTP 存档，您只需要应用的 zip 存档的 URL。OpsWorks 将下载您的归档文件，提取它，并将其部署到您的实例中。如果您的归档受密码保护，您可以选择提供用户名和密码。如果你的 zip 文件可以在网上公开访问，显然这意味着你的源代码可以被任何人访问，这可能不是一个好主意。
就像部署 HTTP 归档文件一样，您也可以从亚马逊 S3(简单存储服务)上托管的归档文件进行部署。要设置这一点，我们必须绕道，但如果可以的话，整合资源并使用 HTTP 上的 S3 是明智的。当您选择 S3 时，您会看到您需要三条信息:您的存档的 URL、访问密钥和秘密。这意味着我们必须创建一个 S3 时段和一个 IAM 用户来访问该时段。我们将快速浏览这些步骤，并在本书的后面花更多的时间和 S3 在一起。
首先，让我们创建我们的 IAM 用户，允许访问 S3 存储桶。我们可以先创建一个组，然后像以前一样添加用户。然而，权限很简单，如果有必要，我们可以重用这个用户，所以让我们保持简单，只创建一个用户。最好是在一个新的标签中进行这种迂回。单击(或右键单击或按住 Control 键单击，具体取决于您的操作系统)左上角的橙色框，返回 AWS 主屏幕，然后选择 IAM。单击左侧导航栏中的用户，然后单击用户页面顶部的创建新用户。我们将这个用户称为 photoalbums-s3。当您进入下一个屏幕时，请确保单击下载凭据，以保存用户访问密钥/密码的副本。然后单击关闭。
现在，您应该会在用户列表中看到您的用户。单击名称进入用户详细信息视图。你以前来过这里！接下来，我们必须为用户生成一个策略，允许用户拥有对 S3 的完全访问权限。在权限标题下，单击附加用户策略。我们再次处于策略生成器中。在“选择策略模板”标题下，向下滚动并选择“亚马逊 S3 完全访问”。您将有机会在生成策略之前对其进行检查(参见图 2-18 )。
图 2-18。
S3 Full Access Permissions policy
接下来，我们必须创建我们的 S3 桶。回到 AWS 主页，点击 S3。单击左上角的创建存储桶。将出现一个模态弹出窗口，提示您命名该桶。输入 photoalbums-source-[您的姓名首字母]作为您的存储桶名称，并选择您所在地区的美国标准(参见图 2-19 )。
图 2-19。
Creating an S3 bucket
选择名称和区域后，单击创建。您将返回到 S3 的主视图，您的存储桶将出现在左侧。点击它，你会看到你的桶的内容，目前是空的。单击此视图左上角的上传。创建一个你的源代码的档案，并把它拖到上传对话框中。您不需要在这里设置任何其他选项；只需点击开始上传。
您将再次返回文件列表，上传进度将出现在屏幕右侧。完成后，在文件列表中点击您的.zip。在右上角，您会看到一个分段控制，当前选择了“无”。点击属性，您的档案的属性会出现在右侧，如图 2-20 所示。找到链接，并将完整的 URL 复制到剪贴板。
图 2-20。
S3 object properties
回到 OpsWorks，将 URL 粘贴到 Repository URL 字段中。访问密钥 ID 和秘密访问密钥是您创建的 IAM 用户的凭证。如果您下载了凭据，请将其打开并复制到这些字段中。如果您能够遵循所有这些步骤，那么您应该能够从 S3 进行部署。若要将更新部署到您的代码，您必须每次都覆盖 S3 存储桶中的 zip，或者上传新的 zip 并在您的应用设置中更改路径。如您所见，这并不理想。一些存储库服务还允许您从他们的服务器部署到 S3，因此也可以从您的存储库部署 zip 到 S3。无论如何，这种方法比生成一个 SSH 密钥并直接从 Git 部署要耗费更多的人力。
配置完应用源后，您将看到以下部分:环境变量、添加域和 SSL 设置。您将在后续课程中学习这些内容。如果其他一切看起来都很好，继续点击右下角的添加应用。你应该会返回到 Apps 视图，如图 2-21 所示，在这里你可以看到你的应用已经被创建了。
图 2-21。
The Apps view
嗯，除了部署您的应用之外，没有太多事情要做了！在我们这样做之前，我们必须启动一个实例。单击左上角的导航并选择实例以返回实例视图。在右上角，单击启动所有实例。您将看到实例旁边的 Status 字段更改为 requested，然后是 pending，booting，running_setup，最后是 online。整个过程需要几分钟。
现在我们有了一个在线实例，我们可以进行部署了。在导航下，选择应用以返回到应用视图。您会在相册行右侧的“操作”栏中看到“部署”按钮。点击它，您现在应该会发现自己在部署应用视图中，如图 2-22 所示。
图 2-22。
Deploy App view
您将看到除了 Deploy 之外，在这个视图中还有其他命令可用。您可以取消部署您的应用、回滚到以前的版本、启动、停止或重新启动应用。现在，我们将使用 Deploy 命令。下面的注释字段是您自己关于部署的内部注释。
下面的实例标题通知您将在其中一个实例上进行部署。您只能部署到已经启动的实例。这是因为停止的实例实际上并不存在。您无需为资源付费，因此 AWS 数据中心不会提供任何资源。除了启动实例之外，不能与已停止的实例进行交互。如果单击“高级”,可以看到正在部署的实例列表。
如果出于某种原因，您想只部署到特定的实例，您可以在这里选择/取消选择它们。其中一种情况是，您的一个实例出错(崩溃)，您需要部署一个补丁来解决这个问题。您部署到当前在线的实例，同时尝试将有问题的实例恢复在线。一旦上线，您可以再次运行部署，但是只能在刚刚从错误中恢复的实例上运行。您可能从未遇到过这种用例，但很高兴知道 OpsWorks 可以处理它！
点击【部署】，将进入部署视图，如图 2-23 所示。
图 2-23。
Deployment view
当部署运行时，您将看到一些活动指示器在旋转。完成后，顶部的状态将变为 successful，并且您的实例旁边会出现一个绿色复选标记。您会注意到这里有几个有趣的特性。在 SSH 列下，您可以选择通过 SSH 直接连接到任何正在运行的实例。你可能永远都不需要这么做，但拥有它是件好事。在日志列中，可以单击显示来查看实例的部署日志。
这些日志一开始可能有点让人不知所措；它们是部署应用时执行的所有厨师食谱的输出。它们通常应该是这样的:
[2014-10-26T18:48:44+00:00] INFO: Chef-client pid: 3167
如果您看到除了INFO和WARN之外的任何日志类型，您可能想要进一步调查。如果你喜欢冒险，你可以通过日志来了解发生了什么。几个主要事件大致如下:
- 运行
opsworks_custom_cookbooks::load和::execute命令。 - 基于你的应用的配置和语言的附加食谱列表被执行。
- 您的代码是通过 SSH 复制和验证的。
- 您的代码被部署到
/srv/www/photoalbums，Node.js 环境被配置。 - 检测到您的
package.json文件，并且安装了node_modules。 - 您的应用已启动(或重新启动)。
这是一种简化，但是它应该让您了解在幕后发生了什么来使您的代码在云中运行。现在是真相大白的时候了。打开 OpsWorks 导航菜单并选择“实例”。在 Public IP 列中，您应该看到您的单个实例的 IP 地址。点击它，您应该会看到我们的欢迎屏幕，如图 2-24 所示。
图 2-24。
Welcome to Photoalbums!
你能相信吗？我们终于在云中运行了我们的应用！因为我们没有配置负载平衡器或添加域，所以我们只是在单个实例上查看应用。这不是我们对 OpsWorks 的预期用途——我们不希望我们的用户直接访问 EC2 实例。我们将很快解决这个问题。
恭喜你，你有了一个驻留在网络上的应用，在云中！遗憾的是，在我们至少配置好数据库之前，它基本上还是没用的。你已经在这一章中讲述了很多，从探索 AWS 架构的主要概念到从头开始创建我们的应用堆栈和部署我们的代码。在下一章中，我们将使用 Amazon RDS 托管我们的数据库，我们的应用将第一次变得可用。通过学习如何使用 OpsWorks，您还学习了很多关于 AWS 的范例和术语，尤其是关于身份和访问管理以及 EC2 的知识。这是云架构和开发道路上的一大步。