![总结:我需要设置从 EFS 到多个 EC2 的快速自动同步](https://linux22.com/image/722798/%E6%80%BB%E7%BB%93%EF%BC%9A%E6%88%91%E9%9C%80%E8%A6%81%E8%AE%BE%E7%BD%AE%E4%BB%8E%20EFS%20%E5%88%B0%E5%A4%9A%E4%B8%AA%20EC2%20%E7%9A%84%E5%BF%AB%E9%80%9F%E8%87%AA%E5%8A%A8%E5%90%8C%E6%AD%A5.png)
总结:我需要设置从 EFS 到多个 EC2 的快速自动同步
我已经在 AWS 中设置了一个 EC2 自动扩展组,并且正在寻找管理到我的实例的代码部署的最佳方法,尽可能减少服务中断(最好没有),并且尽可能减少人为错误的范围(最好没有,哈哈哈)...
这是 Magento 网站。我最初考虑将所有 Web 内容存储在 EFS(弹性文件系统)中,并让我的 EC2 在启动时挂载它,这样就只有一个它们各自都可以访问的集中式代码库。我很快发现这是一个非常糟糕的想法 - 通过网络共享提供 Magento 大小的网站的 Web 内容基本上是不可行的,而且 EFS 的延迟甚至比平均 NFS 共享还要糟糕。
我现在想要实现的是在 EFS 中拥有一个集中的代码库,并从那里到每个实例上的“本地”(EBS)目录进行近乎实时的同步。
我尝试rsync
使用“拉”方法,让每个实例将文件从 EFS rsync 到其自身。一开始看起来不错,但似乎每次扫描后速度都会逐渐变慢(上次检查时已超过一个小时)。
我试过了find
,结果类似。
我尝试过文件传送带的symlink_or_copy
传输器,但它似乎仍然很慢 - 也许是因为出于某种原因,它无法用来inotify
发现变化并回落到轮询。
最终目标是让开发人员将新文件和更改的文件部署到单个位置,并让这些文件快速自动复制到所有正在运行的实例中。开发人员不必知道或关心有多少实例正在运行 - 它可能每小时都会变化。
对类似问题的回答非常好,也是我目前使用的方法 - 更新一个受保护的 EC2 实例,创建新的 AMI,终止剩余实例并根据新映像启动替换实例。 EFS 基本上变得多余。
但所需的手动干预确实比我长期坚持的要麻烦得多,而且更容易出现人为错误。我不想每次部署时都必须创建新的 AMI 和启动配置,并更新 Auto Scaling 组以使用该新 LC。
那么...如何快速自动地从 EFS 同步到多个 EC2?
如果我让 fileconveyor 与 inotify 协同工作,是否可以解决这个问题?或者这只是徒劳无功,有人知道吗?
答案1
我会这么做:
- 创建一个“黄金映像”AMI,其中所有东西都已就绪。理想情况下,可以使用以下组合进行设置:云形成和奥普斯沃克斯。
- 设置AWS 代码提交存储你的源代码
- 设置AWS 代码部署将更新的源代码部署到您的实例。这意味着您不必为每次源代码更改重建 AMI,这是一个简单的部署。使用黄金映像而不是从头开始构建,您可以快速获得新实例的好处,只需稍稍延迟即可更新代码。这是一个相当简单的更新,因此可能可以使用EC2 用户数据如果你想快速完成它。
- 如果你想要自动构建测试/预生产环境、测试和生产部署(可选择手动批准),你可以看看AWS 代码管道。
- 您可以使用 Route53 / Nginx / HAProxy 进行蓝 / 绿(渐进)部署,或使用多种方法进行红 / 黑(切换)部署。
这些东西的运作并不复杂,但如果你不熟悉它,可能需要一些时间。一旦你做到了,自动化可以节省大量的测试和部署时间。
答案2
亚马逊AWS官方博客可能是一个选项。你可以从一个 EC2 实例构建一个工件,将其推送到 S3,然后将其推出使用 CodeDeploy。 引用:
最后,每个实例上的 AWS CodeDeploy 代理从指定的 Amazon S3 存储桶或 GitHub 存储库中提取目标修订,并使用 AppSpec 文件中的说明将内容部署到实例。
CodeDeploy 确实支持蓝/绿部署并允许修订和回滚,这可能对您的情况有帮助。