自动调节和NFS服务器

在放大时，EBS卷和其数据将不被“克隆”。 要有这种行为，你想在启动时自动执行它。

1. 抓取WS-1 EBS卷的最新快照
2. 创build并附加音量

另一种方法，取决于EBS上有多less数据，是从S3中拉下来的。

通过安全组，您可以允许app_security_group中的任何服务器访问nfs_server_group中的任何服务器。 这将允许您dynamic更新安全组。

希望是有道理的。

如果您拥有实例的最近AMI（Amazon Machine Image），则只会“克隆”实例。 自从创build快照以后，文件系统可能会发生一些变化，所以最好使用AWS userdata创build一个Bash / CloudInit脚本，这个脚本会触发更改区域的更新，例如代码库，媒体等。

更新某些领域的选项可以是（列举优点和缺点）：

1. S3上的中央储存点
   • 访问存储区的权限通过您分配给您的实例的IAMangular色进行pipe理
   • AWS服务之间的快速I / O带宽
   • 一致的正常运行时间
   • Con：除非你使用桶版本控制 ，否则你没有源代码控制给你修改的灵活性
2. 用于引导数据的源代码控制（Git，Subversion）存储库：
   • 允许您通过源代码控制dynamic更新自举脚本，为其提供贡献和历史logging等
   • 骗局：需要（可能）外部连接到你的Git主机，权限和安全组configuration，以允许这一点
   • Con：可能比S3慢一点

以下是一个引导脚本示例，您可以将其应用于启动configuration，以触发其dynamic执行引导任务。 请注意，userdata脚本以root用户身份执行。

#!/bin/bash # Update your packages yum update -y # Get/execute bootstrapping cd /tmp git clone ssh://your-git-server/bootstrapping-repo.git chmod +x /tmp/your-repo/bootstrapping.sh # Execute it /tmp/your-repo/bootstrapping.sh # Remove the bootstrapping script remnants rm -rf /tmp/your-repo 

这种方法允许您灵活地随时更新您的“bootstrapping-repo”，而无需定期创build新的AMI。

对于后台，我在我的userdata中使用S3来获取相关的SSH密钥，主机文件等，以及引导存储库的Git。

最好让AMI保持最新状态，并保存到启动configuration中，这样新的实例就不必花太长的时间更新。 无论您是经常手动执行此操作，还是通过API或CLI编写脚本来完成，都取决于您。

仅供参考 ：实例启动时调用的用户数据和后续脚本的输出将logging到文件/var/log/cloud-init-output.log