对于在AWS EB中使用自定义AMI，我有以下疑问。
现在我有：
- 默认平台，Python 3.6+Amazon Linux 1.10.0，在EB配置中>实例>AMI我得到一个ID，我认为它是AWS提供的启动平台的默认AMI(如果是这样的话，它应该在每次平台更新时进行修改)
- 一些使用.eextensions文件完成的平台配置
- 我从CLI部署的Flask应用程序(eb deploy)
因此，为了避免.eextensions配置时间，我想使用一个包括(1)+(2)的自定义AMI，并像以前一样继续部署我的Flask应用程序。
因此，构建AMI：
- 我可以停止我正在运行的env的EC2实例，并从EC2控制台中的那个实例生成AMI吗？如果我这样做，那么AMI甚至会包含我的.eextensions文件和我的应用程序，这有问题吗
- 如果AMI不应该包括.eextensions文件，那么在执行AMI之前自定义平台的唯一方法就是SSH
- 在建立了AMI之后，我将其ID放入EB控制台>配置>实例，然后EB处理所有事情，比如更新EC2>自动缩放>启动选项
- 要进行platofrm更新，我必须首先从新平台手动重建AMI，然后更新EB配置中的AMI ID？所以不可能像我以前那样从EB控制台更新平台，然后保存新的AMI
- 当我部署我的应用程序时，它不应该包含.eextensions文件
- 如果我创建包含应用程序的AMI，那么EB自动缩放甚至可以节省部署应用程序的时间？(当然，在这种情况下，为了进行部署，我必须首先创建一个新的AMI)
感谢您的帮助。
我可以停止我正在运行的env的EC2实例，并从EC2控制台中的那个实例生成AMI吗？如果我这样做，那么AMI甚至会包含我的.eextensions文件和我的应用程序，这有问题吗？
您不必停止它。您可以通过运行实例来创建AMI。此外，您的实例在ASG中，因此停止它不是一个好主意。
如果AMI不应该包括.eextensions文件，那么在执行AMI之前自定义平台的唯一方法是SSH？
如果你在ami上已有应用程序，那也没关系。新部署仍将安装你的应用程序。
在构建AMI之后，我将其ID放入EB控制台>配置>实例，然后EB处理所有事情，比如更新EC2>自动缩放>启动选项？
是的，
要进行platofrm更新，我必须首先从新平台手动重建AMI，然后更新EB配置中的AMI ID？所以不可能像我以前那样从EB控制台更新平台，然后保存新的AMI？
可能，必须重复这个过程。
当我部署应用程序时，它不应该包含.eextensions文件？
这取决于他们做什么。如果他们安装的软件已经在自定义ami上，你可以删除它。
如果我创建包含应用程序的AMI，那么EB自动缩放甚至可以节省部署应用程序的时间？(当然，在这种情况下，为了进行部署，我必须首先创建一个新的AMI)。
自定义ami的目的是节省安装和配置通常不在AWS ami上的自定义软件的时间。它并不是为了取代或消除部署您的应用程序的需要。您仍然需要这样做，但可以跳过安装自定义软件包。
您可以从控制台和CLI中从正在运行的EC2实例创建自定义AMI。您创建的任何AMI都是实例的忠实副本，因此如果实例具有ebextensions，那么AMI也会这样做。
我想我理解你想从ElasticBeanstalk管理的实例创建一个AMI？如果是这样的话，那么ElasticBeanstalk EC2实例上需要存在某些文件，以便ElasticBean和Cloudformation可以管理环境。.eextensions是用于配置环境的脚本，至少根据我的经验，它们在您的repo中进行了维护。如果您的AMI具有.e扩展，那么很可能需要它们。
我不认为在ElasticBeanstalk下使用自定义AMI是典型的：关键是让AWS为您管理该层。我建议，如果你真的需要一个自定义AMI，你可以考虑直接在EC2中做你想做的事情，放弃ElasticBeanstalk。ElasticBeanstalk实际上只是EC2和其他服务的抽象"友好"接口(例如，自动缩放和负载均衡器实际上是EC2)。也许甚至可以考虑把你的申请放进一个码头？
您可以创建EC2实例的自定义AMI，该实例正在为弹性豆茎运行。如果您使用的是自定义AMI，那么就不需要使用.eextension文件，因为AMI应该包括在部署应用程序时已经进行的所有更改以及ebextension文件，或者在创建AMI之前在服务器中进行必要的更改。但最好使用AWS在创建Elastic Beanstalk时提供的默认AMI，并使用.eextension文件在部署期间执行所需任务。