混合云集成方案Azure Arc

对于大型集团公司来说，由于监管或ISV支持的原因，即使在群“云”逐鹿的当下，总有一部分应用没法上云。哪怕一些价值链相对简单的公司，也可能需要多云并举才能各取所长。毕竟在企业对云的印象中，Workday精于人事，SAP擅长财务，微软......做基础架构就好。

微软似乎也始终不忘初心，在去年底的Ignite大会上发布了Azure Arc产品，旨在帮助用户在拥有多个数据中心，多个云服务商的情况下实现服务的集成化管理。小编经历的基础架构项目没有几十个也有十几个，客户的普遍痛点在于：

对所有服务器执行统一的治理策略；
建立跨DC的系统合规性状态面板；
领导层希望基础平台更高效现代化–例如容器化、CI/CD，对于这些新技术如何管控安全与合规；
如何给不在云上的服务器打标签；
基础架构分布太广：分支机构、DC、实体店......
混合云环境无法统一管理体验。

之前我们说了很多Azure的组件，作为纯云的环境，Azure的管理组件可以完全覆盖其IaaS、PaaS和SaaS的全部服务。当然无论这些原生工具功能多么强大，但都只能辐射到Azure的产品，而企业的环境往往会跨越多个平台或云环境，该选择怎样的管理产品呢？

这里Azure Arc可以将一些基础的Azure服务和管理单元无缝延伸到其他任意环境和架构中。包括：

在任何地方运行Azure数据服务
在各个环境中延伸Azure管理节点
在本地环境达成云体验
在任何地方部署Azure安全代理

在目前发布的Arc版本中，主要对以下三个场景实现了集中管理。首先是组织并治理不同环境中的服务器，其中包括了物理和虚拟服务器，通过统一的web界面实现可扩展的管理；第二是大规模管理Kubernetes应用，通过DevOps技术快速地在企业各环境中部署和配置K8S应用；第三是跨环境地运行数据服务，简单地部署合规性，安全性策略，快速响应业务需求。

在虚机管理上，Azure Arc可以对目标服务器进行资源分组及自定义标签管理。

除此之外，通过统一的合规中心，可以对所有环境下不同分组或标签的服务器分配不同的安全策略，并可查看每一台终端的详细违规信息。

早在Azure Arc诞生之前，Onprem服务器就可以通过Azure Stack的形式享用部分Azure云的便利性与集成度；此外Azure IoT又向所有外部终端提供了统一的云端入口；现在有了Azure Arc这块板图，Azure混合云可谓完成了大一统。

Azure Arc提供的不再是系统级的工具，而是数据中心级的，通过线上下载安装包，用户需要给每个Azure Arc的成员数据中心指定网关，然后为成员数据中心的成员服务器安装代理。Azure Arc可方便的与Windows Admin Center，SCCM或SCVMM集成，从而通过批量部署的方式推送到数据中心的目标服务器上。当然安装账户需要具有“Azure Connected Machine Onboarding”的角色。

这里先小结下Azure Arc在服务器管理上的优势。首先它提供了覆盖Windows和Linux服务器，覆盖物理机和虚拟机，覆盖私有数据中心和其他云数据中心，带站点感知的列表管理；其次Azure Arc自带安全和治理策略，可要求所有节点匹配对应的合规要求；它还提供了基于角色的访问控制和自定义标签管理。

下面要聊的是Azure Arc对于容器的管理，这部分我们从一个案例入手。说一家零售企业要将旗下100多家门店的所有应用迁移到K8S集群的容器中以实现微服务拆解和DevOps，该企业面临的问题是如何统一地部署、配置、管理并监控位于不同地区的容器化应用。

Azure Arc for K8S的主要优势在于，为跨区域（云，本地）的组织提供了统一组织视图（Azure Portal）；根据订阅关系或资源组来配置和部署应用；引入GitOps模型批量更新或配置应用；在调用新的应用或配置时，可基于授信源代码控制（例如从某一特定Github订阅来更新公司的CI管道）；开发工具感知（使用公司习惯的IDE环境）。

在Azure Arc for K8S的环境里创建集群会自动生成“azure–<资源组名>”的命名空间，这个命名空间包含了Azure Arc的配置代理，连接代理和控制管理器，以将对外接口全部集成到Azure Portal上。

在GitOps的概念里，Github的安全管理员将安全配置Yaml文件上传到云端，Pods集群管理员定义策略，指定某个应用受某一Git Repo的安全控制，然后K8S集群通过Arc操作器将配置写到位于云端的Azure Arc中，本地的K8S集群就去找Git Repo的Url，最后匹配到这一集群所应配置的安全基线。