Azure云管場景下的RESTAPI實戰(zhàn),azure云架構(gòu)-ESG跨境

Azure云管場景下的RESTAPI實戰(zhàn),azure云架構(gòu)

Azure云管場景下的RESTAPI實戰(zhàn)

隨著云計算的普及，在企業(yè)中使用多家云供應商的場景已經(jīng)非常普遍，而多云的管理給企業(yè)帶來的全新的挑戰(zhàn)，大部分的企業(yè)需要借助云管平臺實現(xiàn)多云的管理。

   微軟云作為國際化云供應商，為廣大企業(yè)和合作伙伴提供了安全和功能豐富的接口實現(xiàn)云管平臺的開發(fā)和配置，借助這些接口可以實現(xiàn)價格的獲取，消耗的獲取和預測，已經(jīng)服務的增、刪、改、查等操作。

No.1Azure Retail API

Azure 客戶一直在尋找一種以編程方式檢索所有 Azure 服務的零售價格，可以使用零售費率價格 API 來獲取所有 Azure 服務的零售價格。

終結(jié)點：

https://prices.azure.com/api/retail/prices

實例：

https://prices.azure.com/api/retail/prices $filter=serviceName eq Virtual Machines and armRegionName eq southeastasia and armSkuName eq StandardD2dsv4

結(jié)果：

No.2身份標識

在介紹下一個API前，需要先了解一下微軟身份標識。Microsoft 標識平臺可以為用戶在構(gòu)建應用程序時提供集成身份驗證和授權(quán)，并提供對你的的授權(quán)訪問。而在云中，企業(yè)需要一個集中的身份驗證和授權(quán)的平臺，這個平臺就是Azure Active Directory(Azure AD)。

在Azure AD中有兩個作為身份標識的對象，他們分別是Application Object 和 Service Principal Object。

應用程序?qū)ο螅ˋpplication Object）定義與軟件一對一對應的關(guān)系，服務如何發(fā)出令牌來訪問應用程序、應用程序可能需要訪問的資源以及應用程序可以執(zhí)行的操作。

服務主體對象（Service Principal Object）是Azure AD定義的安全訪問受保護資源的安全主體對象，在訪問受保護資源時，需要對應用程序進行身份驗證，在訪問資源時進行授權(quán)。

所以在我們的應用程序（例如，云管平臺）希望管理到Azure里面受保護的資源的時候，就必須借助Azure AD的身份標識平臺對其進行身份驗證和授權(quán)的操作。

No.3Azure Rest API

大多數(shù) Azure 服務（例如 Azure 資源管理器提供程序和經(jīng)典部署模型）要求客戶端代碼使用有效憑據(jù)進行身份驗證，然后才能調(diào)用服務的 API。身份驗證由 Azure AD 在各個參與者之間協(xié)調(diào)，并為您的客戶端提供Access Token作為身份驗證的證明。然后將Token發(fā)國際快遞后續(xù) REST API 請求的 HTTP 授權(quán)標頭中的 Azure 服務。

我們需要創(chuàng)建服務主體（Service Principal），通過Azure AD完成身份的驗證和授權(quán)后方可通過Azure Rest API獲得訪問資源的權(quán)限。通過az ad sp createforrbac獲得所需要的appid, password, tenant。默認獲得contributor權(quán)限。

第二步，根據(jù)我們服務主體的權(quán)限獲得accesstoken。用于對客戶端進行身份驗證和獲取訪問令牌的兩個 Azure AD 終結(jié)點稱為 OAuth2 /authorize 和 /token 終結(jié)點。

第三步，訪問所需要的資源，微軟按照服務提供全面的API文檔，供客戶參考使用。

https://docs.microsoft.com/enus/rest/api/azure/

https://management.azure.com/

subscriptions/{subscriptionId}/

resourcegroups/

{resourceGroupName}

?apiversion=20210401

No.4查看消耗

當我們創(chuàng)建所需要的服務以后，接下來用戶就需要對服務產(chǎn)生的費用進行查看了。最早微軟的消耗賬單情況只能通過EA門戶查看，這對于賬單管理員來說權(quán)限可能過大。微軟目前將用量嵌入到我們通常使用的管理門戶中，這樣我們就可以通過服務主體的方式獲得賬單使用情況。

通過Consumption Rest API，用戶可以查詢到關(guān)于合同里面消耗的一切信息。比如下面顯示的，虛擬機在某一天消耗的時間，費用，單價和預留實例情況等信息。

https://management.azure.com/{scope}/providers/Microsoft.Consumption/usageDetails?apiversion=2019001

與此同時，Rest API也能幫助企業(yè)對用量進行預測。

https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Consumption/forecasts?apiversion=2019001

No.5Manage Subscription

Azure為了更用戶統(tǒng)一的體驗，逐漸將以前EA門戶的功能，例如創(chuàng)建和管理訂閱，查看賬單等功能逐漸集成的管理門戶中，同時為了身份的安全性，Rest API也可以支持通過服務主體對訂閱進行管理和創(chuàng)建。所以，目前我們可以通過兩種方法對訂閱進行管理。

1. 通過獲得ID Token對訂閱進行管理，官方不建議使用此方法。

2. 獲得Access Token對訂閱進行管理。

我們演示通過Access Token對訂閱進行管理：

1. 創(chuàng)建服務主體。步驟略

2. 獲得Bill ID和 Enrollment ID;

必須是Account Owner才能GET到Bill Account ID和Enrollment Account ID。

3. 為服務主體賦予EA權(quán)限（Subscription Creator），從而可以獲得創(chuàng)建訂閱的權(quán)限；

PUT

https://management.azure.com/providers/Microsoft.Billing/billingAccounts/{billingAccountName}/enrollmentAccounts/{enrollmentAccountName}/billingRoleAssignments/{billingRoleAssignmentName}?apiversion=2019001preview

Billing Account Name 和 Enrollment Account Name從上部獲得。Bill Role Assignment Name可以通過Powershell 創(chuàng)建出GUID。

在Body中需要填寫，Service Principal Object ID和Tenant ID，而在billingRoleDefinitions填寫SubscriptionCreator ID，這個SubscriptionCreator并不會在EA門戶中顯示，只有作為帳戶所有者的用戶才能將 SubscriptionCreator 角色分配給 SPN。它通過編程方式創(chuàng)建，僅供編程使用。

4. 創(chuàng)建訂閱

PUT https://management.azure.com/providers/Microsoft.Subscription/aliases/sampleAlias?apiversion=20200901

Body中輸入

返回成功結(jié)果：

特別聲明：以上文章內(nèi)容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。