我的客户使用AWS作为他的VPS。他遇到问题的一件事是，如果现场实例的出价高于他的出价，那么他的实例就会被终止。看起来并不是什么大不了的，除了现场实例不是持久的，所以我们每次都要从图像中恢复。
他希望我做的是写一些会在每X个时间内检查已终止实例的内容，然后自动重启。更重要的是，他想要某种方式来假装“坚持”。我最好的想法是每Y个时间从每个服务器创建一个图像，然后从该图像启动（如果/当该实例终止时）。
任何其他想法都会很高兴听到。我想我的问题是，我在这里走在正确的轨道上，你们有没有知道任何可能存在的解决方案？
更新：差不多一年之后，我回到这里找到所有这些精彩的回应，并且比我预期的更多关注这个话题。以下很多答案虽然内容丰富且有帮助，但却质疑我的推理。我想说，即使在那个时候，我100％同意这不是一个明智的想法，但我的客户要求，尽管我有任何尝试，但要把事情转向更好的方向。
非常感谢你的帮助。我最终确定了如何完全按照自己的意愿行事，并且能够编写一些自动重新启动已终止实例的代码。这从来都不容易，但是当我转移到新客户时，它运作良好。
祝你们中任何有同样问题的人好运，你们（可能通过武力，就像我的情况一样）进行一些不容易的事情。现场请求更便宜，因为这里的一些人在他们的回复中提到，特别是因为持久性没有提供。否则，我认为“现货要求”市场的定价会大不相同。
同样， 可能，我做到了，这是一次很棒的体验。如果没有办法，你必须伪造它！如果你不这样做，别人就会。
更新II：我只想提醒大家，这是我基本上的任务。虽然当时许多人只是驳回了整个概念，但我最终得到了一个或多或少功能的SaaS，允许人们轻松管理和监控所有现场实例，包括启用/禁用自动持续重启的能力。实例，单个实例的计划时间（它们应该或不应该启动它们）等。
虽然我绝对同意，从开发人员的角度来看，这是一个不优雅的需求，当时我不想要这样做，我仍然说它是在某种程度上是好的，被要求在它上面工作，因为我不仅学到了很多很多，而且我对我的能力和代码都有很大的信心，但我制作了一个非常有用，据我所知，我的客户非常有价值的软件（即使他们要求错误的东西，因为他们不知道更好）。
我试图说服他，但他坚持认为，既然他是那个付钱的人，我把注意力集中在那里，不仅完成了许多在这里被贬低的愚蠢而且使其有利可图对于某人。
如果那愚蠢，它就不会为任何人省钱。
看，我现在读这篇文章并且畏缩了一下。那时我更天真。我更了解AWS lot ，现在，我现在更好地编写批次，等等。当然。
但是我仍然为解决这个问题感到骄傲，特别是因为正是这些同事，年龄更大，经验更丰富，毫无疑问是伟大的程序员，他们告诉我它不能或不应该'完成。你是那些对我提出挑战的人，谢谢你！
如果有利可图，该怎么办？你确定它不应该吗？
答案 0 :(得分：23)
我们最终找到了解决方案，这就是我们必须做的事情。我将逐步列出这一点，以便为那些可能正在寻找类似解决方案的人重新创建这个...
如果您按照上述步骤操作T，您将在旧实例终止时的同一点上有一个新实例。因此，我们已经实现了某种形式的持久性。
答案 1 :(得分：11)
（感谢Ethan Barron的一些原创想法。这是一个带有一些更正和澄清的版本。）
[1]。创建一个新的专色实例。取消激活根设备的“终止时删除”。记下体系结构（x86_64）和内核ID。
[2]。 SSH进入新实例并创建一些文件，这些文件应该在重新启动后持续存在。不要终止实例。
[3]。在实例仍在运行时创建实例的快照（这可能会在极少数情况下导致文件系统不一致，因此限制写入启动卷）。请注意该快照的名称。
[4]。现在退出SSH连接并终止实例。
[5]。从步骤3中创建的快照创建AMI（AWS不支持从卷创建AMIS;它必须是快照。如果您使用的是剩余卷，则还有一个步骤：创建该快照。
[6]。根据步骤1中的体系结构，步骤1中的内核ID以及步骤5中创建的AMI请求新的专色实例。
这应该有效。
答案 2 :(得分：8)
如果您使用的是ubuntu，我找到了一个方便的解决方案。它使用了一个名为'overlayroot'的功能，该功能包含在ubuntu发行版中。我们的想法是将根文件系统保持为只读，并将所有更改写入EBS支持的覆盖文件系统。由于root是只读的，因此可以在终止时删除它，并且所有更改都将保留在overlay文件系统中。
首先创建一个启用overlayroot的自定义AMI。使用AWS控制台启动您最喜欢的AMI。登录并将以下行添加到/etc/overlayroot.local.conf
overlayroot=device:dev=/dev/xvdf,timeout=180,recurse=0
使用AWS从您的实例创建自定义AMI“Instances-＆gt; Actions-＆gt; Image-＆gt; Create Image”
现在创建EBS卷并将其附加到实例。 “Volumes-＆gt; Actions-＆gt; Attach Volume”然后初始化音量。
mkfs.ext4 /dev/xvdf
此第一个实例仅用于创建自定义AMI并初始化卷，因此可以终止它。在创建自定义图像之前，请勿附加EBS卷，以使其不包含在图像中。
每次启动竞价型实例时都应遵循以下步骤。
重新启动您的实例。 “Instances-＆gt; Actions-＆gt; Instance State-＆gt; Reboot”。登录后，您应该看到类似这样的内容
ubuntu@ip-10-178-74-83:~$ mount
overlayroot on / type overlayfs (rw,discard)
...
/dev/xvda1 on /media/root-ro type ext4 (ro,relatime,data=ordered)
/dev/xvdf on /media/root-rw type ext4 (rw,relatime,data=ordered)
答案 3 :(得分：7)
更新：时间已经改变
现在可以将EC2竞价型实例请求配置为stop而不是terminate出价现货实例，或者用于导致竞价实例中断的任何其他与容量相关的事件。
请参阅EC2开发人员指南中的Interruption Behavior。某些类的实例也可以通过安装适当的代理来休眠。
请注意，此新功能并不保证实例会继续运行，而只会保证它们将以之前的EBS卷，私有IP，弹性IP和实例ID重新启动。
以前的答案如下：
Spot 实例不能是持久性的，但是点请求可以。
永久竞价请求：当您将竞价出价请求指定为“持久”时，您可以确保在您的实例终止后自动重新提交 - 由您或Amazon EC2终止 - 直到您取消出价请求为止。这使您可以在竞价价格低于最高价格时自动启动竞价型实例。
http://aws.amazon.com/ec2/spot-instances/#4
在价格在范围内的任何时候保持机器运行，但就其余部分而言，考虑你的现场实例正在做什么，你认为磁盘的持久性是要走的路。想想“云”。想想“短暂的”。竞价型实例旨在成为启动，获取工作，工作，提交工作的短暂机器，如果它们消失，工作仍然在那里等待下一个实例再次获取它，完成它并提交它。您可以“使用”它们与EBS一起使用并保留卷，但如果这样做，则无法重新启动这些实例（正如您所注意到的那样）。
如果您的AMI使用实例存储，并存储需要外部持久化的所有内容（例如，在S3中），那么您不需要破解AWS架构并且可以坐下来看着您的计算机启动当价格合适时，做他们的工作，并在价格超出范围时再次关闭。而且，没有任何腐烂，因为每个靴子都是一个闪亮的清洁系统。
或者，您的实例可以挂载由始终打开的计算机导出的NFS共享。
或者：https://serverfault.com/questions/448043/auto-attach-ebs-volume-to-a-new-spot-instance
答案 4 :(得分：3)
现场实例的性质是它们是短暂的，所以不能让你不能使实例持续＃34;。但是，您可以使用EBS使数据持久化。
您对图像的想法很好，我不确定是否有任何其他方法可以做到这一点。
您可以随时查看spot instances上的文档或跳转到forums，看看是否有任何AWS工程师有任何想法。
- 编辑 -
不确定这是否会起作用 - 因为它会产生额外的成本，但您可以随时立即从生成的图像中启动实例并立即生成并终止现有实例。它会给出持久性的假象，特别是如果您不依赖于EBS卷来保留数据。
答案 5 :(得分：2)
AWS最近推出了一个新的竞价型实例仪表板，使您可以更轻松地将实例保持在持久状态。这还包括自动定价和区域支持，因此人们不必担心竞标理想价格。 启动实例后，创建实例的AMI，即可。 下次请求现场实例时，只需从“保存的实例”列表中选择该实例。内核和EBS按原样恢复。
答案 6 :(得分：0)