是否可以丢弃 Azure 角色主机并在同一主机上启动它而不进行清理？
假设我的 Azure 角色在 Windows 临时文件夹中创建了很多临时文件并且忘记删除它们。有时它会收到“无法创建临时文件”错误。假设一旦发生这种情况，我的角色代码就会从 RoleEntryPoint.Run() 抛出异常，并且角色会重新启动。
我在这里谈论的并不是完美的 Azure 感知代码。我的角色可能会使用第三方黑盒代码，这些代码现在与 Azure 和“本地存储”无关，只会调用 System.IO.Path.GetTempPath() ，从而在某些非 Azure 中创建文件友好的位置。
问题是，如果角色在同一主机上启动，并且临时文件夹没有被第三方清理，则该文件夹仍然充满文件，并且角色将无法运行。根据这个答案 可能会发生为我的角色保留本地更改的情况，这在上述场景中是一个大问题。
当角色重新启动时，是否可以保证重置本地更改（例如创建的临时文件）？如何确保启动的角色处于相当干净的状态？
Suppose my Azure role creates a lot of temporary files in Windows temporary folder and forgets to delete them. At some point it will receive "can't create temporary file" error. Suppose that once that happens my role code throws an exception out of RoleEntryPoint.Run() and the role is restarted.
I'm not talking about perfect Azure aware code here. My role might use third-party black box code that would now nothing about Azure and "local storage" and would just call System.IO.Path.GetTempPath() and thus create files right in some not Azure friendly location.
The problem is that if the role is started on the very same host and the temporary folder is not cleaned up by some third party the folder is still full of files and the role will be unable to function. According to this answer it might happen that local changes are preserved for my role which is a huge problem in the above scenario.
Are local changes like created temporary files guaranteed to be reset when a role is restarted? How do I ensure that the started role is in reasonably clean state?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
该角色会在黄金映像（基本来宾操作系统 vhd）中的新部署、升级和新扩展实例上重置。通常，对于重新启动和崩溃，您会获得相同的 VHD 和计算机。
您编写的代码将无权写入操作系统驱动器 (D:) - 如果没有提升（或通过 RDP 登录来执行此操作）。此外，用户的角色根驱动器 (E:) 上有一个配额，可以防止您意外地将文件填满该驱动器。过去，您只能写入包大小的 10%。资源驱动器 (C:) 上也有配额，但配额要大得多，并且取决于 VM 大小。
非本地资源驱动器上不会清除任何内容，但如果尝试超出配额，最终会出现错误。您可以关闭本地资源上的粘性存储，它们将在重新启动时被清理。当然，与对磁盘的其他更改一样，当升级来宾操作系统（或底层根操作系统）时，这些非本地资源临时文件偶尔会丢失。如果您正在提升运行并确实搞砸了您的安装（您可以这样做），您将需要点击门户上的“重新映像”按钮，一切都会回到黄金映像。
The role gets reset on new deployments, upgrades, and newly scaled instances from the golden image (base guest OS vhd). Generally for reboots and crashes, you get the same VHD and machine.
The code you write will not have permission to write to the OS drive (D:) - without elevation that is (or logging in via RDP to do this). Further, there is a quota on the user's role root drive (E:) that will prevent you from accidentally filling the drive with files. This used to be 10% of the package size was all you were allowed to write. There is also a quota on the resource drive (C:), but that is much more generous and depends on VM size.
Nothing will be cleaned up on non-local resource drives but you will eventually get errors if you try to exceed quotas. You can turn off sticky storage on local resources and they will be cleaned up on reboot. Of course, like other changes to the disk, these non-local resource temp files will occasionally be lost when the guest OS is upgraded (or underlying root OS). If you are running elevated and really screw up your installation (which you can do), you will need to hit the "Reimage" button on the portal and it will all go back to the golden image.