AWS Tools for PowerShellを試してみる

【2022年3月追記】

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

dev.classmethod.jp

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

【追記ここまで】

---

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

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

• AWS Tools for Windows PowerShell | AWS
• AWS Tools for Windows PowerShellを使ってみた | DevelopersIO
• startAWSPowerShell/readme.md at master · senkousya/startAWSPowerShell · GitHub

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

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

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

古い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でサービス情報が出力されるちょっとイケてない感じです。

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

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

とすると良いでしょう。

認証

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

docs.aws.amazon.com

アクセスキーの生成

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

---

---

---

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

認証情報の設定

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

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

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

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

設定した認証情報は

Get-AWSCredential -ListProfileDetail

で参照できます。

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

Set-DefaultAWSRegion -Region ap-northeast-1

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

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

認証情報の保存先

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

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

に保存されます。

このAWS SDKストアはAWS SDK for .NETやToolkit 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とは？」という点で理解できてない点はあるのですが、

• 【小ネタ】Amazon EC2のReservation IDって何なんだろう？ | DevelopersIO

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

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

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

最後に

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

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

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

つい先日、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ファイルを直接ダウンロードできる様になりました。

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

細かい手順については

• Manual Package Download | Microsoft Docs

を参照してください。

4. Aligning with NuGet

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

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

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

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

blog.shibata.tech

を参考にしてください。

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

これまでは、Install-Module、Install-Script、Install-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を持つことができそれぞれに識別名と個別の権限を付与することができる様になりました。

細かい設定については

• Managing API keys | Microsoft Docs

をご覧ください。

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

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

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

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

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

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

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

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

PowerShell Core 6.1がリリースされました

公式情報はコチラ。

blogs.msdn.microsoft.com

本エントリでは公式情報をベースに補足を入れる形で説明していきます。

新機能について

公式ブログではPowerShell Core 6.1の新機能として以下の点を挙げています。

1. Windows 10およびWindows Server 2019との互換性強化

公式ブログで、

Compatibility with 1900+ existing cmdlets in Windows 10 and Windows Server 2019

と説明されている様にBuild 17711以降のWindows 10およびWindows Server 2019に対する互換性が強化されています。
具体的にどの点を修正しているかまでは公開されていませんが、PowerShell Core側、OS側両方に修正が入っているものと思われます。

この互換性の強化については、以前に

blogs.msdn.microsoft.com

で説明されており、詳細はコチラのエントリを見ると良いでしょう。

---

【2018/10/01追記】

この点について別エントリでまとめました。
こちらも併せてご覧ください。

blog.shibata.tech

【追記ここまで】

2. .NET Core 2.1化

PowerShell Core 6.0がリリースされた時のアプリケーション基盤は.NET Core 2.0(ラインタイムバージョンで2.0.4)でしたが、PowerShell Core 6.1では.NET Core 2.1(ラインタイムバージョン2.1.3)に更新されています。

.NET Core 2.1の新機能はコチラに記載されています。

PowerShell Coreとしては主にセキュリティ更新やパフォーマンス改善の部分で恩恵を受けています。

3. サポートプラットフォームの最新化

サポートされるプラットフォームがPowerShell Core 6.0の頃に対して最新化されています。
同時に古いプラットフォームがいくつかEOLとなっています。

現時点でサポートされるプラットフォームは以下。

• Windows 7/8.1/10
• Windows Server 2008R2/2012/2012R2/2016 (and 2019 on release)
• Windows Server Semi-Annual Channel (SAC)
• macOS 10.12+
• Ubuntu 14.04/16.04/18.04
• Debian 8.7+/9
• CentOS 7
• Red Hat Enterprise Linux (RHEL) 7
• openSUSE 42.3
• Fedora 27/28

以下は非公式のコミュニティサポートのみ

• Ubuntu 18.10
• Arch Linux
• Raspbian (ARM32)
• Kali Linux
• Alpine (experimental Docker image coming soon)

以下のLinuxディストリビューションについてはディストリビューション自体がEOLとなったためPowerShell Coreとしてもサポート外となりました。

• Ubuntu 17.04
• Fedora 25,26
• openSUSE 42.2

ちなみに、PowerShell Core 6.0リリースの際に説明した通り、PowerShell Core のサポート ライフサイクルはMicrosoft Modern Lifecycle Policyとなります。

docs.microsoft.com

4. パフォーマンス改善

先述の.NET 2.1化による影響を主としてパフォーマンスが改善されています。
公式ブログでは"Significant"と謳っていますが具体的なベンチマークが公開されているわけではないのでほどほどに受け止めておくと良いでしょう。
(ただし、開発環境に対してパフォーマンス測定ツールが導入されており内部的な計測はされている様です)

---

【2018/09/16 追記】

いくつかのコマンドレットに対するパフォーマンス計測結果がDocsに記載されていました。

• What's New in PowerShell Core 6.1 | Microsoft Docs

詳細はこちらをご覧ください。

【追記ここまで】

---

私もすべての改善点を挙げることはできませんが、内部的に.NET Core 2.1の新機能であるSpan<T>を使う修正が入るなどランタイムだけではなくコードベースの改善も幾つかなされています。

以下に幾つかパフォーマンス改善に関するプルリクエストを列記しておきます。

• Improve performance on json to psobject conversion
• Adding LanguagePrimitives.TryCompare to provide faster comparisons
• Improving performance of Import-CSV
• Improve performance of Group-Object
• Further improve PSMethod to Delegate conversion
• Reduce allocations in TableWriter

5. Markdown cmdlets

Markdownを扱うコマンドレットが追加されました。
細かい話は

blog.shibata.tech

をご覧ください。

6. Experimental feature flags

試験的な機能追加に備えるための機能が追加されました。
仕様についてはコチラのRFCをご覧ください。

• PowerShell-RFC/RFC0029-Support-Experimental-Features.md at master · PowerShell/PowerShell-RFC · GitHub

現時点で採用された試験的な機能は無いためこれが役に立つのはもうしばらく先の話となります。

仕組みについてですが、基本的にはpowershell.config.jsonに利用する試験的な機能を記述する形になります。

// RFCのサンプルを例示
{
  "ExperimentalFeatures": [
    "A-Experimental-Feature-name",
    "Another-Experimental-Feature-Name"
  ]
}

機能の側はコマンドレットにExperimental属性を付けることで有効・無効化の対象となります。

// RFCのサンプルを一部改変して例示
[Experimental("A-Experimental-Feature-name", ExperimentAction.Show)]
[Cmdlet(Verbs.Invoke, "WebRequest")]
public class InvokeWebRequestCommandV2 : WebCmdletBaseV2 { ... }

[Experimental("A-Experimental-Feature-name", ExperimentAction.Hide)]
[Cmdlet(Verbs.Invoke, "WebRequest")]
public class InvokeWebRequestCommand : WebCmdletBase { ... }

その他

その他新機能の詳細についてはDocsのリリースノートとGitHubのチェンジログを見るのが一番です。
本ブログでも近いうちにこの内容をまとめたいと思います。

また、公式ブログで触れられていないものの影響が大きそうな点として

• ThreadJobの追加 (PowerShell Core 6.1で導入されるThreadJobについて 参照)

• PSReadLineのバージョンが1.2から2.0-Beta.3に更新

あたりが挙げられます。

---

【2018/10/16追記】

Docsにある新機能・破壊的変更について別エントリでまとめました。

blog.shibata.tech

こちらも併せてご覧ください。

【追記ここまで】

PowerShellの今後について

公式ブログでは今後の方針について一切触れられませんでした。

あくまで私の予測ですが、今後しばらくは現状維持となりWindows 10およびWindows Server 2019との互換性の強化や不具合の改善につとめていくのかな？と思います。