しばたテックブログ

気分で書いている技術ブログです。

Azure Cloud ShellのPowerShellがGAしました

Ignite 2018に合わせてひっそりとGAがアナウンスされています。

azure.microsoft.com

すでにCloud ShellのBashはGAしてますので、これでCloud Shellが完全にGAしたことになります。

GAで何が変わったのか?

前に

blog.shibata.tech

でお伝えした様にCloud Shellの基盤であるコンテナはすでに統一されており、環境としてはBash、PowerShellどちらも差異のない状況でした。
このため環境および機能面でみればCloud ShellのPowerShellがGAしたからといって特に変わる点はありません。
単純コンソール左上の(PREVIEW)の表示が取れたくらいしかないと思います。

利用者目線でみればGAによって正式にサポート対象になったことが重要でしょう。
(ただCloud Shellのサポートって何だ?といわれると言葉に詰まりますが...)

AzureRMモジュールからAzモジュールへ

こちらはBash、PowerShell両方に関するはなしです。

(多分)今回のタイミングに合わせて今回のタイミングのちょっと前からCloud Shellで使用されるAzure管理用のPowerShellモジュールが、従来のAzureRM.NetcoreからAzに切り替わっていました。

www.powershellgallery.com

f:id:stknohg:20180925140705p:plain

このAzモジュールは簡単に言ってしまうと.NET Standard版のAzure PowerShell Moduleで、まだきちんとしたアナウンスがされていないため断言はできないのですが、従来のWinodws PowerShell版AzureRMモジュールと.NET Core版のAzureRM.Netcoreを統合するためのモノだと思われます。

現時点ではVer.0.2.2が最新であり、まだまだプレビュー版です。
GitHubのマイルストーンを見てもVer.1.0はかなり先になりそうな雰囲気です。

従来のモジュールに対してAzモジュールはコマンドレットの接頭語がAzであり、例えばサブスクリプションを取得するには

Get-AzSubscription (※ Get-AzureRmSubscription ではない)

を使います。
ただ、互換性を確保するために、従来の接頭語であるAzureRmがつくコマンドはエイリアスとして定義されている様です。

PS Azure:\> gal Get-AzureRmSubscription | select Name, Definition

Name                    Definition
----                    ----------
Get-AzureRmSubscription Get-AzSubscription
PS Azure:\> gal *AzureRm* | select Name, Definition

Name                                                   Definition
----                                                   ----------
Add-AzureRmAccount                                     Add-AzAccount
Add-AzureRmADGroupMember                               Add-AzADGroupMember
Add-AzureRmApiManagementApiToProduct                   Add-AzApiManagementApiToProduct
Add-AzureRmApiManagementProductToGroup                 Add-AzApiManagementProductToGroup
Add-AzureRmApiManagementRegion                         Add-AzApiManagementRegion
Add-AzureRmApiManagementUserToGroup                    Add-AzApiManagementUserToGroup

・・・(後略)・・・

このため、ふつうに使う分にはこれまでと同様なハズ...です。
(実際にどこまで互換性があるのかは検証してません。すいません...)

【訂正】切り替え時期について

ブログ公開当初、この切り替えはGAと同時かと記述してましたが、セルビアのMVPである@alexandairさんのツイートを見るに今月頭には既に切り替わっていた様です。

最後に

ざっとこんな感じです。

環境としてはGAしたものの肝心のモジュールは新しいとはいえプレビュー版でちぐはぐ感があります。
とはいえCloud Shellの環境は日々更新されますのであまり細かいことは考えない方が幸せになれそうです。

AWS Tools for PowerShellを試してみる

【2022年3月追記】

2022年3月に現職の会社ブログでAWS Tools for PowerShellの入門記事を書きました。

dev.classmethod.jp

最新の情報は上記記事をご覧ください。

【追記ここまで】


ただいまAWSを勉強中でせっかくなのでAWS Tools for PowerShellを試してみることにしました。

基本的には公式ドキュメントと先人の資料を参考にして試しています。

本エントリは私の備忘録としての側面が強く、詳細な情報は上記参考元を見て頂くのが良いでしょう。

モジュールのインストール

AWS Tools for PowerShellはPowerShellモジュールとして提供されています。

f:id:stknohg:20180920183701p:plain

古いPowerShellやオフライン環境向けにMSIインストーラーもありますが、今であればPowerShell Galleryからインストールするのが良いでしょう。

# Windows PowerShell
Install-Module -Name AWSPowerShell -Scope CurrentUser -Force

AWS Tools for PowerShellはAzure PowerShellとは異なり一つのモジュールにAWSの各種サービスを管理するためのコマンドがまとめられています。
このため、インストール後のモジュール全体のサイズで90MB程度と大容量であり、インストールには時間が結構かかります。

PowerShell Coreの場合はモジュール名が異なるためこちらとなります。

# PowerShell Core
Install-Module -Name AWSPowerShell.NetCore -Scope CurrentUser -Force

サポートされるサービス

公式の手順によると以下のコマンドで管理できるAWSサービスの一覧を取得できるそうです。

Get-AWSPowerShellVersion -ListServiceVersionInfo

ただ、このコマンドの結果は最初の説明文がstring型、そのあとにPSCutomObjectでサービス情報が出力されるちょっとイケてない感じです。

f:id:stknohg:20180920183721p:plain

このため利用できるサービスを純粋に取得するには、

Get-AWSPowerShellVersion -ListServiceVersionInfo | Select-Object -Skip 1

とすると良いでしょう。

認証

AWS Tools for PowerShellの認証はIAMユーザーで発行するアクセスキーを指定する形で行われます。
公式の手順は以下にドキュメント化されています。

docs.aws.amazon.com

アクセスキーの生成

IAMユーザーの設定画面から以下の様な感じで作成しました。
UIはコロコロ変わるでしょうし細かい説明は端折ります。

f:id:stknohg:20180920183806p:plain


f:id:stknohg:20180920183817p:plain


f:id:stknohg:20180920183838p:plain


アクセスキーIDとシークレットアクセスキーを記録しておいてください。

認証情報の設定

先人の資料によるとInitialize-AWSDefaultConfiguration(= Initialize-AWSDefaults)*1を使い認証情報などの既定値を保存する様ですが、公式ドキュメントを見ると、

Initialize-AWSDefaultConfiguration は実行しないようお勧めします。ただし、PowerShell を実行している EC2 インスタンスの起動にインスタンスプロファイルを使用していなくて、認証情報プロファイルを手動で設定する場合は除きます。この場合は、認証情報プロファイルに認証情報が含まれないことに注意してください。

とあり、基本的にはSet-AWSCredentialを使い認証情報を プロファイル として保存しておくのが良さそうです。

Set-AWSCredential -AccessKey [アクセスキーID] -SecretKey [シークレットアクセスキー] -StoreAs [プロファイル名]

設定した認証情報は

Get-AWSCredential -ListProfileDetail

で参照できます。

f:id:stknohg:20180920183936p:plain

また、デフォルトのリージョンはSet-DefaultAWSRegionで設定できます。
(ただし永続化されません。永続化したい場合はInitialize-AWSDefaultConfigurationを使うしかない様です)

Set-DefaultAWSRegion -Region ap-northeast-1

f:id:stknohg:20180920183950p:plain

リージョン一覧はGet-AWSRegionで取得できます。

Get-AWSRegion | Where-Object { $_.Name -like "*tokyo*" }

f:id:stknohg:20180920184008p:plain

認証情報の保存先

ちなみに、認証情報はデフォルトでWindowsの場合だと

  • C:\Users\[username]\AppData\Local\AWSToolkit\RegisteredAccounts.json (AWS SDKストア)

に保存されます。

このAWS SDKストアはAWS SDK for .NETToolkit for Visual Studioとも共用らしいのですが、細かいことはまだよくわかりませんので正確な情報は公式ドキュメントを見てください。
AWS Tools for PowerShellにおいてはWindows PowerShellとPowerShell Coreで共用されていました。

ただ、AWS CLIで使われる認証情報ファイル(C:\Users\[username]\.aws\credentials)とは別物だそうです。

defaultプロファイル

先述のプロファイルですが、名前がdefaultのものを特別視しており、この名前のプロファイルの内容は自動で検索対象になるそうです。
そしてInitialize-AWSDefaultConfigurationで設定した内容はこのプロファイルに保存されます。

試してみる

とりあえずお試しとしてEC2の情報を取得してみます。

EC2インスタンスはGet-EC2Instanceで取得できる様ですが、こいつの戻り値はAmazon.EC2.Model.Reservation型であり、実際にはReservationを返します。

「Reservationとは?」という点で理解できてない点はあるのですが、

にあるEC2インスタンスに対するアクションを指しているものと思われます。
このためEC2インスタンス情報を取得するには以下の様にInstancesプロパティを拾ってやる必要があります。
認証情報は-ProfileNameパラメーターで指定してあります。

 Get-EC2Instance -ProfileName MyProfile | Select-Object -ExpandProperty Instances | Format-List

f:id:stknohg:20180920184111p:plain

とりあえずそれっぽい情報が取得できたので良しとします。

最後に

とりあえずこんな感じです。
わからないことはまだまだ多いのですが、随時内容を更新していければと思います。

*1:Initialize-AWSDefaultsはInitialize-AWSDefaultConfigurationのエイリアスです。

PowerShell Galleryがリニューアルしました

f:id:stknohg:20180916151011p:plain

つい先日、PowerShell Core 6.1のリリースと足並みを揃える形でPowerShell Galleryのサイトがリニューアルしました。

公式のアナウンスはコチラです。

blogs.msdn.microsoft.com

リニューアル自体は以前からアナウンスされ、プレビュー版のサイトが公開されてフィードバックを募っていたのが晴れて正式リリースとなった形です。

また、PowerShell Galleryのリニューアルと同時にPowerShellGetのモジュールがVer.2.0.0とメジャーバージョンアップしています。

PowerShell Gallery更新内容

公式のアナウンスからいくつかかいつまんで説明します。

1. Modern UIの採用

サイトのデザインが今っぽく変更され、以前は無かったモバイル向けのデザインも追加されています。

また、各モジュールの情報に対して主要な情報のみ初期表示し、その他の要素については折りたたまれた状態にするといった最適化を図ったそうです。

2. パフォーマンス改善

CDNの利用*1によりモジュールのダウンロード速度が改善されたそうです。
特にアメリカ国外でのダウンロードが大きく改善されているであろうとの事です。

3. マニュアルダウンロード

PowerShell Galleryはもともと内部的にNugetを利用しており、モジュールも内部的にはnupkgの形で保持されています。

今回のリニューアルでこのnupkgファイルを直接ダウンロードできる様になりました。

f:id:stknohg:20180916151101p:plain

インターネットに直接接続できない環境に対してこのnupkgを使い手動でモジュールのインストールをする事ができます。

細かい手順については

を参照してください。

4. Aligning with NuGet

こちらは利用者に直接関係のない話ですが、PowerShell GalleryとPowerShellGet内部で利用しているNugetのバージョンが更新されその改善点も反映されたとのことです。
後述のNuget API Key管理の更新はこの変更があってのことだそうです。

モジュール利用者向けの更新点

最新のPowerShellGet 2.0.0ではモジュール利用者の利便性を高めるために以下の変更が加えられています。

PowerShellGetの更新方法については本ブログの

blog.shibata.tech

を参考にしてください。

インストール時のデフォルトスコープの変更

これまでは、Install-ModuleInstall-ScriptInstall-Packageでモジュールやスクリプトをインストールする際のデフォルトスコープはAllUsersであり要管理者権限でした。

PowerShellGet 2.0.0からはデフォルトスコープが以下の様に変更されます。

  • PowerShell 3.0 - 5.1 : コンソールが管理者として実行されている(昇格している)場合はAllUsers、そうでない場合はCurrentUser
  • PowerShell 6.0 - : 常にCurrentUser

この変更に至る経緯については

github.com

を見ると参考になります。

モジュール開発者向けの更新点

今回のリニューアルでモジュール開発者にとっては大きな変更が発生しています。

公式ブログに

Most important: Publishers must update to PowerShellGet module version 1.6.8 or higher to publish to the PowerShell Gallery. Older versions of PowerShellGet are fine for find, save, install, and update functions, but not for publishing.

とある様にPowerShellGetのバージョンが1.6.8以降(現時点では2.0.0しかない)でないとモジュールの公開やバージョンアップ*2が出来なくなりました。

また、セキュリティ強化のために以下の変更が加えられています。

1. API Keyの有効期限

モジュールを公開するために使用するNuget API Keyに有効期限が設けられ、1日、90日、180日、270日、365日のいずれかを指定する必要があります。

既存のAPI Keyは有効期限無期限の"Full access API key"として残されていますが、一度削除すると二度と再作成することはできません。

2. API Keyの画面表示

新しいPowerShell Galleryでは作成したAPI Keyの値は画面表示されることは無く、作成時にクリップボードに保存して値を確認・保存することしかできなくなりました。
API Keyの値を忘れた場合は再作成するしかありません。

3. 複数Keyの作成

これまでは単一のAPI Keyしか持てませんでしたが、新しいPowerShell Galleryでは複数のAPI Keyを持つことができそれぞれに識別名と個別の権限を付与することができる様になりました。

f:id:stknohg:20180916151219p:plain

細かい設定については

をご覧ください。

4. 二要素認証のサポート

PowerShell Galleryで使用するアカウントで二要素認証がサポートされました。
PowerShell Gallery独自の二要素認証ではなく、使用するMicrosoft Accountの二要素認証の仕組みを流用している様で、Microsoft Accountで二要素認証を有効にしている場合はそのままPowerShell Galleryでも有効になっていました。

詳細はコチラをご覧ください。

5. ログインアカウントの変更機能

これまではPowerShell Gallery初回登録時のMicrosoft Accountがログインアカウントとなり変更できませんでしたが、今は変更できる様になりました。

詳細はコチラをご覧ください。

*1:以前はCDNを使っていなかったのか?といった点については明言されていませんが、使ってないことは無いでしょうし、利用方法を改善したものと思われます。

*2:バージョンアップは可能でした。元の文章を思いっきり誤読してました...