【问题标题】:AWS AutoScaling Instance Cloning gitAWS AutoScaling 实例克隆 git
【发布时间】:2014-12-15 11:54:46
【问题描述】:

我正在使用自定义 AMI 在 AWS 中设置 Auto Scaling 组。 我知道 AWS 为“用户数据”保留了一个部分,人们可以在其中输入他们的脚本,并且可以在创建实例时执行它们,但我想我更愿意将启动脚本嵌入到图像本身中。

我将创建自定义映像(设置 Web 服务器和所需的所有其他软件包),然后需要创建一个启动脚本,例如将我的 git 存储库 (ssh) 克隆到“/var/www/”中。

我的问题是:将存储库直接克隆到 Web 服务器文件夹有什么缺点吗? 整个想法是:当平衡器上的负载过高时,将从 AMI 创建一个新实例,并且在启动时,该实例将从私有 git 存储库中获取源代码。 --> 对执行此过程的最佳方法有什么建议吗?我将不胜感激!

至于将新代码部署到已经运行的实例,我将使用 Capistrano。

提前致谢!

【问题讨论】:

    标签: git amazon-web-services deployment autoscaling


    【解决方案1】:

    有几个缺点,是的:

    1. 如果存储库特别大,这将需要一段时间 - 您在每次自动缩放引导程序中都提取了大量不需要的数据(您可以使用 git clone --depth=1 尝试最小化您下载的数据)。
    2. 您需要为此运行自己的单独遥控器,因为依赖第三方来部署代码并不好 - 您不希望在部署流程中依赖 github。
    3. 您的部署工件不会是不可变的,因为可以编辑不存在的标签/rebase 提交/无论如何。

    另一种方法是使用 fpm 之类的东西来构建部署工件,将其作为构建的一部分存储在 S3 中,然后使用 capistrano-artifact 让服务器在启动时从 S3 获取工件。天真地,您也可以在 S3 中压缩特定的修订和内容。这具有超级快速下载的额外好处。但是,您会失去一些回滚的灵活性 - 像 slugforge 这样的东西可能会通过将以前的车辆留在盒子上并明确支持基于符号链接的回滚来帮助解决这个问题。

    顺便说一句,我认为你很聪明,不要在用户数据中加入太多逻辑 - 你希望它尽可能简单,因为更改它意味着构建一个全新的启动配置。我建议不要在 AMI 上使用引导程序,而是将其存储在 S3 中并使用 runurl 从 userdata 脚本中执行它。

    【讨论】:

      【解决方案2】:

      您可以尝试使用 git clone 命令中的选项 --depth=1 来最小化下载的大小。这将使 git 只提取包的最后一个版本。

      【讨论】:

        猜你喜欢
        • 2013-03-16
        • 2017-12-02
        • 2015-03-29
        • 1970-01-01
        • 2017-01-27
        • 1970-01-01
        • 2018-09-22
        • 2011-01-12
        • 1970-01-01
        相关资源
        最近更新 更多