使用Azure Polcy强制禁止非托管磁盘VM
今天再来分享一波Azure管理的经验，熟悉Azure的朋友都知道，Azure有托管磁盘和非托管磁盘之分，早期的VM全都是非托管磁盘的，需要我们手动维护以及规划磁盘的使用情况，还有20000 IOPS的限制等问题，为了解决这种问题，微软引入了托管磁盘的概念，托管磁盘相对于非托管磁盘来说，有很多的优势，主要有以下几点：
简单且可缩放的 VM 部署
托管磁盘在幕后处理存储。 以前，必须创建存储帐户才能存储 Azure VM 的磁盘（VHD 文件）。 进行扩展时，必须确保创建了额外的存储帐户，以便任何磁盘都不会超出对存储的 IOPS 限制。 使用托管磁盘处理存储时，不再受到存储帐户限制（例如每个帐户 20,000 IOPS）的约束。 另外，不再需要将自定义映像（VHD 文件）复制到多个存储帐户。 可在一个中心位置管理自定义映像（每个 Azure 区域保存一个存储帐户），并使用它们在一个订阅中创建数百个 VM。
托管磁盘支持在每个区域中的一个订阅中创建最多 50,000 个同一类型的 VM 磁盘，这使得可以在单个订阅中创建数以万计的 VM
可用性集的可靠性更高
通过确保可用性集中的 VM 的磁盘彼此之间完全隔离以避免单点故障，托管磁盘为可用性集提供了更佳的可靠性。 磁盘自动放置于不同的存储缩放单元（模块）。 如果某个模块因硬件或软件故障而失败，则只有其磁盘在该模块上的 VM 实例会失败。 例如，假定某个应用程序在 5 台 VM 上运行并且这些 VM 位于一个可用性集中。 这些 VM 的磁盘不会存储在同一个模块中，因此，如果一个模块失败，该应用程序的其他实例可以继续运行。
高度持久和可用
Azure 磁盘具备 99.999% 的可用性。 数据具有三个副本，高持久性可让用户高枕无忧。 如果其中一个或两个副本出现问题，剩下的副本能够确保数据的持久性和对故障的高耐受性。 此架构有助于 Azure 为 IaaS 磁盘持续提供企业级的持久性，年化故障率为 0%，达到行业领先水平。
粒度访问控制
可以使用 Azure 基于角色的访问控制 (RBAC) 将对托管磁盘的特定权限分配给一个或多个用户。 托管磁盘公开了各种操作，包括读取、写入（创建/更新）、删除，以及检索磁盘的共享访问签名 (SAS) URI。 可以仅将某人员执行其工作所需的操作的访问权限授予该人员。 例如，如果不希望某人员将某个托管磁盘复制到存储帐户，则可以选择不授予对该托管磁盘的导出操作的访问权限。 类似地，如果不希望某人员使用 SAS URI 复制某个托管磁盘，则可以选择不授予对该托管磁盘的该权限。
所以现在微软也是大力的推动托管磁盘的使用。那么在实际应用中，企业IT管理员也肯定希望用户能够更多地去使用托管磁盘，但如何来实施这点呢，光靠嘴说可能很多时候并不好使，最好是能够有一些技术手段限制创建非托管磁盘VM
Azure Policy是个很好的解决办法
Azure Policy 是 Azure 中的一项服务，可用于创建、分配和管理策略。 这些策略将在整个资源中强制实施不同的规则和效果，以便这些资源符合公司标准和服务级别协议。 Azure Policy 通过评估资源是否符合指定策略来满足此需求。 例如，可以设置一项策略，仅允许环境中有特定 SKU 大小的虚拟机。 实施此策略后，将评估新资源和现有资源的符合性。 通过使用正确的策略类型，可以确保现有资源的符合性。 也可以通过Policy明确禁止一些管理员不希望发生的操作
下边来看如何来实施policy吧，policy其实也是通过JSON文件的形式进行了一些定义，所以我们只需要编写一些policy的JSON文件即可
限制非托管磁盘VM的JSON文件如下：
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "Microsoft.Compute/virtualMachines/osDisk.uri",
"exists": true
}
]
},
"then": {
"effect": "deny"
}
}如何将这个定义转换为Policy呢？可以通过PowerShell
运行如下PowerShell命令
第一步：创建policydefinition
第二步：创建role assignment
之后可以看到在Azure Portal的policy里，也能够看到这些内容了
下边来尝试一下吧！在Portal中创建一个非托管磁盘的Linux VM
可以发现，在最后验证的时候，会提示被policy deny掉了！
Azure Policy是个很不错的东东，后续有机会继续和各位分享！