Google Cloud Platform： 使用 Google App Engine 进行部署
0/5 (0投票)
第一部分的延续，部署到云端。
- Google Cloud Platform：Google App Engine 入门（第一部分）
- Google Cloud Platform：使用 Google App Engine 进行部署（第二部分）
- Google Cloud Platform：用户管理（第三部分）
- Google Cloud Platform：移动端点（第四部分）
- Google Cloud Platform - Google Cloud SQL（第五部分）
- Google Cloud Platform - Google Cloud Datastore（第六部分）
- Google Cloud Platform - Google Cloud Storage（第七部分）
第二部分：实际的云
在本系列的第一部分中，我们快速浏览了Google Cloud Platform的各个部分，然后深入研究了如何在Google App Engine中运行一个“Hello World”应用程序。Google App Engine是一个基于Java Servlet的环境，因此基本上就是编写一个简单的Servlet，并确保Servlet部署描述符包含Google App Engine所需的元素。但我们忽略了故事中一个重要部分。
我们，呃……我们实际上从未将其部署到云端。
云化
假设本地机器已经运行了上次的代码（如果您还没有阅读第一部分，请参阅Google Cloud Platform：Google App Engine入门（第一部分）），则代码正在Google App Engine环境的本地副本中运行。要将其部署到云端，我们首先需要做几件事；特别是，我们需要设置并运行一个Google Cloud Platform账户，然后配置一个应用程序将被部署的环境。
首先，使用您的Google账户（现在哪个开发者还没有Gmail账户？）注册，然后前往http://cloud.google.com/console创建一个项目。对话框会要求您提供两项内容：项目名称和项目标识符，Google会为您生成。就Google而言，标识符是关键部分——这是识别云中所有其他项目中项目的唯一值，因此Google会建议一个值。最终，如果未设置DNS CNAME记录来别名它（这超出了本文的范围），它将成为应用程序访问的默认域（<identifier>.appspot.com）。
完成这些操作后，项目就创建好了，等待代码。
部署
第一部分中的Ant脚本可以将应用程序推送到云端，但在成功执行此操作之前，本地工具需要了解一些信息。具体来说，它需要知道应用程序标识符，并且它需要知道键盘前的手指属于真正拥有云空间的那一方。为了前者，我们需要编辑appengine-web.xml描述符中的<application>元素以读取应用程序标识符；因此，由于我的示例应用程序被赋予了标识符“summer-scion-375”，<application>元素应读取
<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
<application>summer-scion-375</application>
<version>1</version>
<threadsafe>true</threadsafe>
</appengine-web-app>
顺便说一句，<version>元素也很重要，但我们稍后会讲到。
完成后，运行Google SDK中的一个shell脚本/批处理文件，名为“appcfg”（MacOS/*nix上是appcfg.sh）。这个小工具会扫描appengine-web.xml文件中的设置（应用程序和版本），然后要求您提供Google凭据，然后立即将所有代码上传到云端。也可以从“ant update”调用相同的脚本，因此选择您觉得更方便的方式。（我更喜欢通过Ant完成所有操作，这样我就可以在更新之前自动执行某些任务，例如提交到源代码管理或处理配置文件以设置开发与生产环境等；请随意选择。）但是，第一次必须从命令行调用它，所以启动“appcfg update war”，其中第一个参数是上传应用程序，第二个参数是WEB-INF目录的位置，其中可以找到appengine-web.xml。它会提示输入Google账户电子邮件和密码，然后上传应用程序。
如果部署过程中出现任何问题，例如处理过程中出现网络超时或类似情况，请执行“appcfg rollback war”以清理本地文件并重试。对于好奇的人来说，appcfg有许多命令行参数可以自定义体验（包括“--passin”命令，该命令要求每次都输入密码），并且可以通过通常的方式找到它们：“appcfg help”。（或者您可以阅读有关它的页面http://developers.google.com/appengine/docs/java/tools/uploadinganapp，但那样还有什么乐趣呢？）
更新完成后，应用程序就可以正常运行了：在浏览器中访问“http://summer-scion-375.appspot.com/hello”，然后享受又一个在互联网上运行的“Hello, World”应用程序的温暖美好。（请注意，这里实际上有两个hello——一个在根目录下，是上次创建的index.html文件，还有一个是“/hello”URL模式后面的Servlet。）
仪表板
在我们继续之前，请花点时间再次查看您创建项目的Google Cloud Console。点击您创建的项目链接，进入该项目的Console视图，然后在左侧边栏的中间位置有一个“Google App Engine”链接，该链接会在新的浏览器标签页中打开App Engine仪表板。这两个是独立的控制台——Console是项目的“全局视图”，其中包含指向您的应用程序涉及的Google Cloud Platform不同部分的链接，包括Google App Engine、Google Cloud Storage、Google Cloud SQL等。就其本身而言，它不是一个特别数据丰富的仪表板，但它是所有其他仪表板的中心。
另一方面，Google App Engine仪表板是指标爱好者的天堂。加载到浏览器页面后，Google App Engine仪表板会立即向开发者/管理员提供大量有关正在运行的应用程序的数据，包括页面中央的一个漂亮图表（在“Charts”下的下拉菜单中有各种设置可以更改显示的数据）以及——也许是应用程序所有者所需的最重要信息——在标记为“Billing Status”的部分下方的资源消耗统计信息网格。请参见图1，其中显示了我示例应用程序的视图。更重要的是，隐藏在“Billing Status”旁边的“Settings”链接后面是至关重要的“Enable Billing”和“Enable Billing Administrators”按钮，用于配置Google将如何、何时以及向何处收费以换取更多的云资源。
然而，还需要注意一件事：在仪表板的“Charts”部分正上方有一个标记为“Version”的下拉菜单，当前设置为“1”，并且被标记为“（Default）”。Google App Engine认识到开发人员通常希望拥有不同版本的代码（至少，我们有当前版本“n”，前一个版本“n-1”，代表一个快速回滚的备份版本，以防我们搞砸了某些东西，以及下一个版本“n+1”，代表我们想尝试一下，看看是否搞砸了某些东西的版本）。此值由appengine-web.xml中的<version>标签控制，因此如果我们对Java代码进行更改（也许我们查找“name”查询参数，并使用它来稍微自定义问候语），并将<version>标记为2，然后运行“ant update”，版本1和版本2将在上述下拉菜单中可用。
话虽如此，一旦版本2成功上传，似乎有什么不对：再次在浏览器中指向http://summer-scion-375.appspot.com URL会显示没有任何变化。这是因为Google App Engine不会自动将流量路由到版本2，直到被告知这样做为止，这可以通过点击左侧边栏中的“Versions”链接，在显示的表格中选择“2”，然后将其设为默认应用程序，通过点击“Make Default”来完成。这是故意的；版本2在成为默认版本之前不会处于活动状态。
“Default”意味着还有其他方法可以看到该版本的应用程序。Google App Engine会在服务器上同时保留几个版本的代码，并将流量指向标记为“default”的版本。但是，您可以通过浏览“http://<version>.<identifier>.appspot.com”来构建URL以访问应用程序的任何给定版本。由于summer-scion-375的版本2是默认版本，因此在没有版本前缀的情况下显示的就是它，但我们仍然可以通过访问“http://1.summer-scion-375.appspot.com”来访问版本1（或者版本3，当我们稍后再次增强应用程序以包含一些真正激进的东西，例如当前日期和时间时）。
一点点……更多
尽管Web最初诞生于超链接文档，带有<blink>标签、动画GIF、图像地图和播放您最喜欢的音乐片段的主页（请参阅http://www2.warnerbros.com/spacejam/movie/jam.htm快速了解过去的美好时光），但在过去几年里，Web已逐渐从文档集合演变为数据集合。根据“Web 2.0”的称号，云部署的“应用程序”越来越普遍，它们实际上只是通过HTTP访问的数据端点，为各种端点提供XML或JSON：单页HTML/JavaScript/CSS、移动端或（有时）桌面应用程序。因此，虽然我们当然可以探索一种或多种生成HTML并在服务器端返回的Java工具包/框架，但2003年已经过去了，它想要回它的代码。现在是2013年，我们想构建一个“Web 2.0”应用程序。
一种实现方法是采用现有的Servlet应用程序，创建一系列端点（“/greeting”），这些端点接受传入的JSON数据包（例如“{name:’Fred’}”），对其进行解析、处理，并返回一个传出的JSON数据包（“{message:’Hello, Fred!’}”），所有这些都手动用Java完成，但这工作量很大。特别是，解析和准备JSON端点将使大部分工作变得非常缓慢，因为我们将序列化和反序列化为文本格式，并且缺乏类型检查和验证。（还记得在WS-* Web服务时代做这件事有多有趣吗？）
幸运的是，Google App Engine提供了一个专门用于构建此类端点的“后端”，我们将研究如何使用它来创建一个提供此类数据驱动功能的问候服务。但在那之前，我们必须弄清楚用户是谁，以便恰当地问候他们，这将是下一篇文章的主题。在此期间，如果您感到孤独，有一个Web应用程序等待向您问好，所以请保持一个浏览器标签页打开，祝您编码愉快！
