繁体   English   中英

Azure CLI 与 Powershell?

[英]Azure CLI vs Powershell?

不能完全理解 Azure CLI 在 Windows 环境中的优点。

它是否针对想要从 Linux 环境管理 Azure IAAS 的受众?

我认为Powershell 内核将成为非 Windows 管理员的方式。 PowerShell Core 是否不会在所有平台上很好地移植,以服务于跨平台的受众?

简而言之,Azure CLI值得学习吗?

Azure CLI 是一个类似于 PowerShell 的工具,可用于所有平台。 无论您使用什么平台,都可以使用相同的命令:Windows、Linux 或 Mac。

现在,有两个版本的 Azure CLI。 Azure CLI 1.0 使用 Node.js 编写以实现跨平台功能,而新的 Azure CLI 2.0 使用 Python 编写以提供更好的跨平台功能。 两者都是开源的,可在 Github 上获得。 但是,目前,只有某些 PowerShell cmdlet 支持在 Linux 上使用。

是否面向想要从 Linux 环境管理 Azure IAAS 的受众?

我认为答案是肯定的。 对于 Linux 或 Mac 开发人员,我认为他们更有可能使用 Azure CLI。

Azure CLI 和 PowerShell 包都使用 Azure 的 REST API。

正如我们的一位 Microsoft 联系人所说:使用您喜欢和喜欢的任何内容。

Azure CLI 有一些优点:

  1. 开源 - 有很多优点。 未来可能会发展得更快。 您可以查看代码中的真正内容,社区可能会或将会更大,等等。
  2. Azure CLI 可与 Groovy、Python、Ruby 或任何其他脚本语言一起使用。 与经验丰富的 PowerShell 开发人员相比,获得这种语言的优秀开发人员更容易。 例如:因为 Java,我选择了 Groovy。 使用这种组合比学习 PowerShell 脚本更容易......

目前,PowerShell有一个非常大的好处:Azure 有一个巨大的 PowerShell 脚本示例存储库。 但是:通常你必须自己做才能满足你的要求 - 因此一个例子可能是一个很好的起点 - 有时从头开始更容易。

我的建议是:使用 Azure CLI --> 对于脚本,使用贵公司熟悉的语言。

只是想补充一下我在 Azure Cli 和 Az PowerShell 方面的经验。

根据 2019 年,两者都是跨平台的,因此它应该只是语言/语法首选项,但使用 Azure Cli all/大多数命令都是idempotent

我最终用 Azure Cli 脚本替换了我所有的 ARM 模板,因为它不那么冗长且易于阅读。

使用 Az Powershell,您仍然需要在创建资源之前检查资源是否存在,否则它会抛出异常,因此脚本可能会无缘无故变得非常复杂。

我们将 Azure Cli 和 Az Powershell 与 Azure DevOps 结合使用。 现在可以从 bash (Linux) 或 bat (Windows) 脚本执行 Azure Cli 命令。 所以它不是最佳的......(编辑 2020您现在也可以使用 Powershell 脚本运行 Azure CLI)

  • 我们使用 Azure Cli 部署资源,因为它易于阅读且命令是幂等的。
  • 对于复杂的脚本,我更喜欢使用 PowerShell,因为它有很多有用的语言功能。

编辑 2021

使用新的Azure Bicep ,我已经开始回到“ARM 类型”部署:如果您了解 ARM 模板并且即使在复杂的部署中也保持可读性,Bicep 真的很容易使用。

除了 Az CLI(Powershell 核心)之外,它还处理我需要做的大部分脚本。

PowerShell 比 CLI 有一些显着的优势:

  • PowerShell 是 Azure Functions 的一种语言 因此,您可以轻松编写模块或代码并将其推送到安全的 Azure 函数。 CLI 不是受支持的语言。
  • Azure 自动化 Runbooks 也是如此,而 CLI 不是受支持的语言。
  • 如果您想编排覆盖本地和云的混合工作负载,即将服务部署到 Windows Server,然后在 Azure 中部署端点以便与之交互,PowerShell 可以,但 CLI 不能(如果它确实如此,我会感到惊讶) )。
  • 如果您想投资一种可以调用遗留模块进行管理的语言,PowerShell 可以,但 CLI 不能。
  • 如果您想用 C# 或任何其他语言创建自己的 DLL 并将其合并到您的脚本中。 我不得不对 DLL 进行逆向工程并将它们包装在 PowerShell 中以合并到业务流程中。
  • 与 CLI 相比,我在使用 PowerShell 扩展 DevOps 管道方面取得了更大的成功。
  • PowerShell 对 Azure 单元和烟雾测试以及大型 Azure 并行部署(除了笨重的 DevOps 并行任务)等场景具有非常好的多线程工作负载支持。 TBH,我不知道 Azure CLI 中的本机多线程。
  • 我可以开发一个模块,在上述所有场景中使用它,然后将其提供给最终客户; TBH,我不相信我可以为 CLI 做到这一点(创建一个模块,对其进行数字签名,然后 nuget feed 发行版)。

几乎没有我没有在 PowerShell 中编写脚本的内容,而使用 CLI 我可以做一些事情,但不能做其他事情。 我的 PowerShell 技能在 10 多年来一直保持相关性,我一直在做企业 SharePoint、Dynamics,现在是 Office 和 Azure……所以我有偏见。

在 2018 年之前,Powershell 在非 Windows 平台上不可用。从 2018 年 1 月开始,Powershell 在 MacOS 和 Linux 平台上可用。

此处提供 MacOS 或 Linux 上的 Powershell 安装说明

PowerShell 也是开源的。 微软刚刚发布了 PowerShell Azure Az 模块(2018 年 12 月),它使用 .Net 核心。 所以它可以在 Linux、Mac OS 和 Windows 上运行。 如果愿意,Azure CLI 仍然可供 Linux 开发人员使用。

简而言之,是否值得学习 Azure CLI?

在进行 MS Azure 培训(AZ-900 基础知识和 AZ-303 Azure 架构师)时,我注意到练习是在Azure CLI中完成的。 诚然,他们都是“复制并粘贴此代码”,但似乎 MS 更喜欢 CLI 而不是 PowerShell,至少出于培训目的。

更新:我最近在代理背后的 Azure CLI 上遇到了很多麻烦。 PowerShell 没有任何问题。 作为习惯使用 PowerShell 的人,CLI 有点笨拙和笨拙。 也就是说,Terraform 需要 Azure CLI,因此这可能是考虑它的充分理由。

您不必在 Linux 上使用 Azure CLI,也可以在 Windows 上使用它,而且效果很好 =D

在我个人看来,这取决于你想做什么。 我更喜欢使用 Azure CLI 命令而不是 Azure CMDLETS。 但我仍然使用 PowerShell 作为我的脚本编程语言。

CLI 上的某些模块比 AZ 或 AzRM cmdlet 更“直接”。

两者都更可取,因为我们可以使用它们中的任何一个来编写脚本。 对于 Powershell 或 Azure CLI,您需要下载软件才能编写脚本,但更喜欢 Powershell,因为它是 Microsoft 的内置工具。 但我也注意到,如果我们将它与命令提示符进行比较,通过 Powershell 发出命令会更加复杂。

MS 有一篇关于该主题的文章,内容如下:

Azure CLI 和 Azure PowerShell 之间并不总是存在 Azure 服务的功能奇偶校验。

在选择正确的工具时,请考虑您过去的经验和当前的工作环境。

如果您主要使用 Windows 系统,Azure PowerShell 是自然而然的选择。 命令遵循动词-名词命名方案,数据作为对象返回。 如果您主要使用 Linux 系统,Azure CLI 感觉更自然。

选择能够利用您的经验并缩短学习曲线的工具。

由于这是社区中的常见问题,最近在文档中添加了一篇涵盖各种 Azure 命令行选项之间的异同和细微差别的文章: 选择正确的 Azure 命令行工具 该文档也应该回答您的大部分问题。

在管理 Azure 时,您有很多选择。 尽管Azure CLIAzure PowerShellAzure Cloud Shell具有重叠的功能,但各自的运作方式不同,而且语言有时会与环境混淆。

Azure CLI 与 Azure PowerShell: Azure CLI 和 Azure PowerShell 是命令行工具,可用于创建和管理 Azure 资源。 虽然两者都是跨平台的并可安装在 Windows、macOS 和 Linux 上,但Azure CLI可在 Windows PowerShell、Cmd 或 Bash 和其他 Unix shell 中运行,而Azure PowerShell需要 Windows PowerShell 或 PowerShell。

不同的 Shell 环境: Windows PowerShell、PowerShell、Cmd 和 Bash 是 Shell 环境。 您的 shell 环境不仅决定了您可以使用哪些工具,而且还会改变您的命令行体验。

Shell Environment | Azure CLI | Azure PowerShell |
------------------|-----------|------------------|
Cmd               | Yes       |                  |
Bash              | Yes       |                  |
Windows PowerShell| Yes       | Yes              |
PowerShell        | Yes       | Yes              |

使用 Azure 命令行工具并不总是必要的,但它是一项有用的技能。 以下是选择命令行工具时要记住的几个关键因素:

  • 在选择正确的工具时,请考虑您过去的经验和当前的工作环境。
  • Azure CLI 语法类似于 Bash 脚本的语法。 如果您主要使用 Linux 系统,Azure CLI 感觉更自然。
  • Azure PowerShell 是一个 PowerShell 模块。 如果您主要使用 Windows 系统,Azure PowerShell 是自然而然的选择。 命令遵循动词-名词命名方案,数据作为对象返回。
  • 请记住,Azure CLI 和 Azure PowerShell 之间并不总是存在 Azure 服务的功能奇偶校验。
  • 选择能够利用您的经验并缩短学习曲线的工具。 在有意义的情况下使用不同的工具。

我已经使用了 Az Powershel 和 cli,但是当文档不明确或不支持命令时,我强烈建议您跳过两者并上游到Azure Rest ZDB974238714CA8A1434A7CE1D08

Azure Rest API 通常由其他命令行工具调用,因此它最终成为功能最完整且通常有据可查的工具。 它也是跨平台的。

最难的部分是弄清楚身份验证。 从 powershell 开始,我通常使用类似这样的格式,但如果需要,转换为 curl+cli 或放置在 webapp 中。 这是一个随机的例子:

$azContext = Get-AzContext
$subscriptionId = $azContext.Subscription.Id
$azProfile = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile
$profileClient = New-Object -TypeName Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient -ArgumentList ($azProfile)
$token = $profileClient.AcquireAccessToken($azContext.Subscription.TenantId)
$authHeader = @{
    'Content-Type'='application/json'
    'Authorization'='Bearer ' + $token.AccessToken
}     
  
$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$rg/providers/Microsoft.Web/sites/$site/config/web?api-version=2022-03-01"
$Body = @{      
    "properties" = @{netFrameworkVersion = "v6.0"}
}
$Params = @{
    Uri = $uri
    Headers = $authHeader
    Method = "PUT"
    Body = $Body | ConvertTo-Json -Depth 10
}
$response = Invoke-RestMethod @Params
$response.properties.netFrameworkVersion

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM