【问题标题】:Deploying to EC2 instances behind a load balancer; PHPStorm + GitHub部署到负载均衡器后面的 EC2 实例; PHPStorm + GitHub
【发布时间】:2016-06-01 12:17:01
【问题描述】:

我知道这个问题已经在很多地方得到了部分回答,但答案是如此......在地图上到处都是,过时且没有得到很好的解释。我正在寻找截至 2016 年 2 月的最佳做法

设置:

驻留在 EC2 实例中的基于 PHP 的 RESTful 应用程序服务。 EC2 实例使用 S3 上传用户数据(图像文件),使用 RDS MySql 作为其 DB(这两点并不是特别重要。)

我们在 PHPStorm 中开发,我们的源代码控制是 GitHub。当我们部署时,我们只是使用 PHPStorm 的内置 SFTP 部署将文件直接上传到 EC2 实例(我们有一个实例用于我们的暂存环境,另一个用于我们的生产环境)。我经常部署到 Staging 非常。一天可以20次。我只需单击 PHPStorm 中的一个文件并说“部署到 Staging”,它会执行 SFTP 传输。或者,我可能只是单击整个项目,然后单击“部署到 Staging”——某些文件夹和文件被排除在上传之外,这是 PHPStorm 部署配置的一部分。

最近,我将我们的 EC2 实例放在负载均衡器后面。我这样做是为了可以通过不支持单个 EC2 实例的证书管理器利用 Amazon 的免费 SSL 产品。

所以,现在有一个负载均衡器,后面只有一个 EC2 实例。我维护一个指向 EC2 实例的弹性 IP,以便我可以直接访问它(请参阅上面我当前的部署方法)。

问题:

我还没有勇气在我的负载均衡器后面创建额外的(克隆)EC2 实例,因为我不确定我应该如何部署到它们。想到了一些想法,但它们都很老套。

鉴于上述场景,目前A) 将代码库快速部署到负载均衡器后面的一组 EC2 实例以及 B)的最流畅和最佳方式是什么> 实际上“克隆”我当前的 EC2 实例以创建其他实例。

尽管我已经提出了一些(高度技术性的)建议,但我还不能真正在脑海中清晰地描绘出上述内容。

谢谢!

【问题讨论】:

    标签: amazon-web-services github amazon-ec2 load-balancing amazon-elb


    【解决方案1】:

    您需要将您的 EC2 实例视为 100% 可有可无。意思是,它可以随时终止,您不必在意。替换 EC2 实例将启动并接管工作。

    有 3 种方法可以做到这一点:

    方法 1:每次部署都会创建一个新的 AMI 映像。

    当您部署应用程序时,您将其部署到工作程序 EC2 实例,其唯一目的是“设置”您的应用程序。部署新版本后,您可以从 EC2 实例创建一个新的 AMI 映像,并使用新的 AMI 映像更新您的 Auto Scaling 启动配置。旧的 EC2 实例被终止并替换为新代码。

    新的 EC2 实例上已经有最新的代码,因此可以将它们添加到负载均衡器中。

    方法 2:每次部署都在实例外存储(如 Amazon S3)上完成。

    EC2 实例将从 Amazon S3 下载最新代码并在启动时安装。

    因此,为了使新代码生效,您可以终止旧实例并启动新实例以替换它们,这些实例开始使用新代码。

    这可以以滚动更新方式完成,也可以作为蓝/绿部署。

    方法 3:与方法 2 类似,但这次实例有一些智能,可以发出信号下载并安装代码。

    这样,您无需终止实例:现有实例被告知要从 S3 更新,并且它们自己会这样做。

    一些可能有帮助的工具包括:

    • 厨师
    • Ansible
    • CloudFormation

    更新:

    方法 2 和 3 都从配置为从 S3 拉取网页资产的“基本”AMI 开始。此 AMI 不会因您网站的版本而异。

    例如,AMI 可能已经安装了 Apache 和 PHP,并在启动时从 S3 中提取 .php 网站资产并将它们放入 /var/www/html

    CloudFormation 可以很好地解决这个问题。另外,对于方法3,可以使用cfn-hup来等待更新信号。收到信号后,它将从 S3 中提取更新的资产。

    另一种可能性是使用 Elastic Beanstalk,它可用于为您管理所有这些。

    更新:

    要从 Git 拉取您的 AMI 映像,请尝试以下操作:

    1. 设置一个 EC2 实例,安装所有您需要为您的 Web 应用程序安装的东西
    2. 安装 Git 并为 Git pull 设置一个本地存储库。
    3. 关闭并创建实例的 AMI。

    部署时,请执行以下操作:

    1. Git push 到 GitHub
    2. 根据您的 AMI 映像启动一个新的 EC2 实例。

    作为用户数据的一部分(在 EC2 实例启动期间指定),指定如下内容:

    #!/bin/sh
    cd /git/app
    git pull
    ; copy files from repo to web folder
    composer install
    

    这样完成后,用户数据将充当脚本,将在首次启动时运行。

    【讨论】:

    • OK.. 等等.. 首先,我要问:我真的被一个叫“Matt Houser”的人回答了吗?
    • 嗯,嗯,这里是 Matthew Housser,所以这很有趣。 =P 好的,继续……我想我会先问一些问题,然后从这个问题开始:使用“方法 3”,这与 Auto Scaling 配合得好吗?我认为 Auto Scaling 确实是我最终应该做的明智之举。方法 3 似乎没有更新“AMI”,那么它是如何工作的(也许它不会)?
    • 是的,这一切都适用于 Auto Scaling。 Auto Scaling 是可行的方法,即使只有一个实例(只要该实例是一次性的)。我已更新我的答案以解决方法 2 和 3 的 AMI 问题。
    • 由于我们使用 GitHub 作为我们的服务器代码,并且不想开始使用 S3 来托管我们的服务器代码,可以公平地说我们可以替换所有“从 S3 拉取” ” 上面带有“从 GitHub 拉取”的建议?
    • 是的,你也可以这样做。只要您不手动上传,它从哪里来并不重要。
    猜你喜欢
    • 1970-01-01
    • 2021-01-04
    • 2021-03-30
    • 1970-01-01
    • 2020-02-12
    • 2017-09-06
    • 1970-01-01
    • 2012-12-01
    • 1970-01-01
    相关资源
    最近更新 更多