将一个Amazon EC2文件夹指向另一个实例

我不知道这是否是正确的问题。但我在AWS上的Amazon EC2实例上运行了一个Web应用程序。我们想要推出一个将放置的WordPress博客www.myapp.com/blog。

我不希望它们在同一个Amazon EC2实例中，所以我创建了另一个实例并设置了我的WordPress环境。这是一个运行。

我现在需要做的是将此文件夹/blog指向此实例。我想我们必须使用Amazon Route 53做到这一点？我甚至试图这样做，但显然我可以创建一个CNAME blog.myapp.com而不是文件夹/blog。我们真的希望它能够存在www.myapp.com/blog。我应该使用类似的东西.htaccess吗？

我现在需要做的是将此文件夹/blog指向此实例。我想我们必须使用Amazon Route 53做到这一点？我甚至试图这样做，但显然我可以创建一个CNAME blog.myapp.com而不是文件夹/blog。我们真的希望它能够存在www.myapp.com/blog。我应该使用类似的东西.htaccess吗？

简短的回答。

简而言之，您所描述的内容 - 正如您所描述的那样 - 无法奏效。虽然blog/是主要www.myapp.comAmazon EC2实例上的目录/文件夹/路径，但您正在混淆服务器和Web URL路径的概念; aka：目录，文件夹和路径。

如果要启动新的Amazon EC2实例，则需要设置一个全新的服务器。并且具有相同基本主机名www.myapp.com但只有一个的两个服务器具有/blog无法发生的有效路径。

如果您想跨服务器拆分此站点，最好的办法是使用子域设置新的Amazon EC2实例，blog.myapp.com并将所有流量从第一个实例重定向www.myapp.com/blog到新的子域/主机。

更多细节如下。

更长的答案。

所以你有两个Amazon EC2实例：

• EC2实例1：正在托管www.myapp.com。
• EC2实例2：您想要托管www.myapp.com/blog。

首先，这与Amazon Route 53（亚马逊的DNS服务）无关。所有Amazon Route 53都会管理DNS条目，例如主机名和目标IP地址。理解这一点的简单方法是/URL中第一个路径（）左侧的任何内容都是主机名。所以在你的例子中：

www.myapp.com/blog

有问题的主机名是www.myapp.com。

因此，尝试通过CNAME www.myapp.com/blog从EC2实例1 “重定向” 到EC2实例2将永远不会发生。这在技术上是不可能的，这就是原因：

• 首先，永远不能为/URL中右侧的路径数据设置DNS条目。
• 其次，你基本上可以说明你要EC2实例1和EC2实例2至有完全相同的主机名www.myapp.com，而只在EC2实例2将拥有blog/这在技术上是不可能在你的问题暗示的方式。

更现实的解决方案是通过Amazon Route 53设置新的子域，以便新的Amazon EC2实例设置如下：

• EC2实例1：正在托管 www.myapp.com。
• EC2实例2：将主持blog.myapp.com。

在这样的，你可以再设置一个Apache重写规则，以部队为所有流量请求的情况下，www.myapp.com/blog去blog.myapp.com。使用这样的.htaccess命令非常可行且容易做到：

RewriteEngine On
RewriteRule     ^blog(/.*)?$    http://www.newdomain.com/ [R=301]

你会简单地把该在.htaccess位于根目录的文件www.myapp.com，这将重定向所有交通EC2实例1要blog/到blog.myapp.com。

还有一件事：使用Apache反向代理的优点/缺点。

因此，所有上述的说一个评论者确实带来了潜在的使用要求要建立和Apache反向代理管www.myapp.com/blog在EC2实例1到blog.myapp.com对EC2实例2。是的，这将从技术上实现原始问题概述的目标，但它开辟了潜在的蠕虫：

• 设置Apache反向代理的复杂性：现在我并不是说反向代理的概念如此复杂，普通用户无法学习如何使用它。一旦掌握了它，它实际上有点简单易懂。但复杂性来自于必须调整Apache配置并在设置的生命周期内管理这些配置。例如，在某些Web开发商店中，这将被视为DevOps任务。一些开发人员可能不想处理像这样的非常见的DevOps任务。
• 反向代理意味着两个服务器获取流量：由于反向代理基本上是将流量从一个服务器路由到另一个服务器的“管道”，因此去往EC2实例2的流量仍然必须通过EC2实例1。如果设置单独的Amazon EC2实例的目的是确保一台服务器不会影响另一台服务器，则反向代理可能会出现问题。让我们说大量的流量 - 来自真实用户或攻击 - 会www.myapp.com/blog发生什么？EC2实例1上的主服务器获得该流量以及EC2实例2 ; 因此两台服务器都可能存在漏洞 相比之下简单RewriteRule将流量反弹到子域是轻量级/可忽略的负载方式，并且由于大多数用户blog.myapp.com无论如何都会访问子域上的博客，因此两个服务器都与每个服务器的流量隔离/分离。
• 两台服务器都无法访问主服务器：简单易懂。如果EC2实例1正在管理流量www.myapp.com/blog以及核心内容www.myapp.com，如果该服务器发生故障，则两个站点都将无法访问。通过具有类似子域的blog.myapp.com方式，即使主服务器www.myapp.com停机，blog.myapp.com仍可访问。

这就是说如果你想探索使用Apache反向代理设置，我有两个关于服务器故障的答案 - 这一个和这个 - 解释了基本的配置和设置。

请注意，这些帖子主要关注使用端口的Solr和其他Java / Tomcat应用程序，8080以及我如何使用Apache Reverse Proxy让我的生活更轻松，因为Tomcat在我的拙见中很难配置/管理。Apache Reverse Proxying允许我使用相对容易理解的Apache配置来管理站点的前端Web访问，而不是处理Tomcat的怪癖。但是整体概念可以很容易地从Apache-to-Apache Reverse Proxy设置中使用。