AWS SSO環境下でASP.NET CoreからAWSのリソースを参照する場合はAWSSDK.SSOとAWSSSO.SSOOIDCを参照する。
AWS SSO配下のアカウントのプロファイルを使って署名URLを発行しようとしたところ、下記のような例外が発生しました。
An unhandled exception occurred while processing the request.
FileNotFoundException: Could not load file or assembly ‘AWSSDK.SSO, Culture=neutral, PublicKeyToken=null’. 指定されたファイルが見つかりません。
System.Reflection.RuntimeAssembly.InternalLoad(ObjectHandleOnStack assemblyName, ObjectHandleOnStack requestingAssembly, StackCrawlMarkHandle stackMark, bool throwOnFileNotFound, ObjectHandleOnStack assemblyLoadContext, ObjectHandleOnStack retAssembly)
InvalidOperationException: Assembly AWSSDK.SSO could not be found or loaded. This assembly must be available at runtime to use Amazon.Runtime.Internal.SSOServiceClientHelpers, AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604.
Amazon.Runtime.Internal.SSOServiceClientHelpers.CreateClient(RegionEndpoint region, string serviceClassName, string serviceConfigName, string parentAssemblyName, IWebProxy proxySettings)
AWS Toolkitのバージョンが問題?
下記のIssueを見るとVisual StudioのAWS向け拡張機能であるAWSToolkit for VisualStudioの問題だから最新にすれば治るよとのこと。
https://github.com/aws/aws-toolkit-visual-studio/issues/268
変わらずエラーが出ますね。ローカルにインストールされたバージョンは1.35.2.0
でした。1.34.0.0
で解決しているはずなのでやはり違う問題のようです。
AWSSDK.SSOパッケージとAWSSDK.SSOOIDCパッケージのインストール
あ、エラーメッセージにAWSSDK.SSO
パッケージが解決できないって書かれてますね。AWSSDK.SSO
とAWSSDK.SSOOIDC
の両方をプロジェクトに追加します。片方だけだと最初の例外と同様にFileNotFoundExceptionが発生するので注意してください。
Docker for Desktop有料化に伴い、プランを検討したがどのプランも合わなかった
Docker for Desktop の有料化に伴い必要ならライセンスを購入しようという流れになった。
ただ実際に確認を初めて見たところ、管理方針からビジネスプランが必要で開発者一人当たり年 $252 必要だという結論になり、WSL2 ベースの Linux 上にインストールして利用する必要があったので経緯をまとめておく。
Docker for Desktop の利用用途
ほとんどの運用環境は AWS の ECS 上のコンテナアプリケーションとして動かしているんだけれど、各開発者の環境は下記の観点から Docker for Desktop を利用している。
- 各端末への Docker の初期セットアップやバージョンアップ時の設定コストを抑える。
- Docker for Desktopのダッシュボード機能でローカルのコンテナ管理コストを抑える。
- 複数ラインの開発の切り替えコストを抑える。
- 運用環境と同じ環境にすることで環境差による不具合を抑える。
- docker-compose を利用することで、開発環境の初期環境設定コストを抑える。
1,2 以外は WSL2 上に Docker をインストールする事でも乗り切れたんだけれど、フォローの手間や便利に使わせてもらっていることもあり、管理方針と年間の利用料が合えば費用を払えばいいんじゃない?という流れになった。
Docker Hub アカウントの管理方針
下記の運用で Docker Hub のアカウントを管理したい。
- クレジットカードの管理は1か所で行い、管理者のみが設定できるようにしたい。
- クレジットカード毎の請求情報を出力し経理に提出する。
- アカウントの管理は1か所で行い、管理が利用者の参加・脱退を管理できるようにしたい。
- Docker Hub へのイメージの登録、公開の予定はないが、実施する場合は特定のアカウントのみ実施できるようにする。
アカウントの種別ごとの価格と検討
2021 年 12 月現在、Docker の有料プランは下記のようになっている(カッコ内は月契約の場合の金額) 。
https://www.docker.com/pricing
- Pro: 年契約で 月 5USD (7USD)
- Team: 年契約で 月 7USD (9USD) Team ライセンスは最低 5 アカウントから
- Business: 年契約で 月 21USD
Pro ライセンス
下記の理由から管理方針と合わない。
- アカウントごとにクレジットカードを登録する必要があり、利用者の入退場を管理できない
- アカウントごとに領収書をダウンロードする必要があって運用が回らない
Team ライセンス
Team ライセンスにすることでProライセンスに比べ下記の利点があるが、
- 請求情報は組織に登録するため、アカウント毎に登録したり領収書をダウンロードする必要はない
- あらかじめ組織で購入したシートを招待したアカウントに割り当てることで管理できるため、入退場時の管理を一括して行える
招待したアカウントの権限が必ず Owner になり変更できないため採用できない。
- 一般ユーザーが組織のリポジトリにイメージを登録、公開する事を制限できない
- 一般ユーザーが支払情報を変更することを制限できない
Business
運用は満たされそうだが、金額的に採用できない。
まとめ
$5 払えば利用できるんだから払えばいいじゃんという意見が多いが、ライセンスを支払う必要があるほとんどの日本企業は Business が必要になる気がする。
ReSharper と Rider の .NET 6 / Visual Studio 2022 対応
おぉ、ReSharper と Rider が .NET 6 / Visual Studio 2022 に対応してる!待ってました!
リリースに関する JetBrains のブログ投稿はこちら
https://blog.jetbrains.com/dotnet/2021/12/08/resharper-2021-3/
https://blog.jetbrains.com/dotnet/2021/12/08/dottools-2021-3/
https://blog.jetbrains.com/dotnet/2021/12/08/rider-2021-3-released/
Rider はともかく Visual Studio 2022 が 64bit 化された影響があるので、ReSharper のリリースはもう少し後かなと思っていたのでこれはうれしいですね!
.NET6.0のAlpineイメージの3.13はまだプレビュー
おや?とりあえず特別な何かが無いのであれば3.14を使おう
❯ mcr.microsoft.com/dotnet/sdk:6.0-alpine3.13
# dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.0-preview.7.21378.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0-preview.7.21377.19 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
❯ mcr.microsoft.com/dotnet/sdk:6.0-alpine3.14
# dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
企業でDocker for Desktopを利用する場合、どのプランを使えばいいの?
Docker Desktopのライセンス変更により、2021/08/31 から Docker Desktop を利用する場合、Docker is Updating and Extending Our Product Subscriptionsに記載されている通り下記の要件に当てはまる利用者はDockerの有料サブスクリプションを購入する必要が出てきました。
- 従業員数が200人を超える企業
- 年間の売り上げが 1,000万ドル 以上の企業
で、↑の条件に当てはまる企業でDocker for Desktopを利用する場合、どのプランを購入すれば良いの?って話なのですが、Proの場合は人ごとにクレジットカードを割り当ててサブスクリプションを購入する必要があるので実質はTeamからになるような気がします(Teamであれば一括で購入して利用者にサブスクリプションを割り当てることができそう)。さらに、組織的に請求書が必要になる場合はBusinessが必要になります。
Teamの場合費用はこんな感じで、年払いと月払いで変わってくるのと、最初の5ユーザーは少し値引きがあるみたいですね。Businessは営業に問い合わせくださいな感じなのでどうなるかはホームページからはわかりませんでした。
- 月払い
最初の5ユーザーまで $7(人/月)
それ以降のユーザー $9(人/月)
- 年払い
最初の5ユーザーまで $5(人/月)
それ以降のユーザー $7(人/月)
この費用を払いたくない場合、WindowsであればWSL2上のLinuxにDockerエンジンをいれてあげれば回避できそうですが、インストールの煩雑さやDocker自体のアップデートなどを考えるとDocker for Desktopを使い続けたいですね。
.NET のApple Silicon対応メモ
Apple Silicon に対する.NET の対応方針。とりあえず.NET5はRosetta 2でのエミュレーションまで実施して、ネイティブ対応は.NET 6ですね。
Qiitaへの初投稿
所属会社でもっと技術を公開していこうって動きがあって、だいぶ遅まきながらQiitaへ初投稿です。月1ぐらいで何かしら書いていこうと思います。こっちはこっちで気軽に続けます。
Swagger UI で OIDC の Implicit FlowなAPIを呼びだす。
Swagger UI で OIDC の Implicit Flow な認証を必要とする API を呼びだそうとすると、response_typeにid_tokenが無いぞ。とか、nonceが無いぞ。とか言ってうまく呼びだせない。
issueを見るとOIDC対応はOAS3からだよと書いてあって、終わっているんだかどうだかよくわからない状況になっています。
参考
– https://github.com/swagger-api/swagger-ui/issues/3906
– https://github.com/swagger-api/swagger-ui/issues/3517
OIDCサーバーの実装にもよると思うけれど、IdentityServer 4 を使っている環境では authorizationUrl をこんな風に指定してあげたらどうにか動くようになった。
securityDefinitions:
bearer:
type: oauth2
description: MyApi
flow: implicit
authorizationUrl: 'https://myidp/connect/authorize?nonce=xxxxxxxxx&response_type=id_token'
scopes:
openid: openid token
profile: profile
あっ、Swaggerをホストしているサーバーをlocalhost:3000とかで起動するなら、Identity Server側のRedirectUrisに http://localhost:3000/oauth2-redirect.html を入れる必要がありますね。
docker-composeで起動するならこんな感じですかね
version: "3"
services:
swagger:
image: swaggerapi/swagger-ui
volumes:
- ./swagger.yml:/usr/share/nginx/html/swagger.yaml
environment:
API_URL: swagger.yaml
OAUTH_CLIENT_ID: xxxxxxxx
OAUTH_CLIENT_SECRET: xxxxxxxx
OAUTH_SCOPES: openid profile
ports:
- "3000:8080"
PowerAutomateで、Office 365 グループ宛ての新着メールをトリガーする場合はOffice 365 Groups Mailコネクターを使おう
Office 365 の Outlook の受信をもとに作業を自動化する場合、PowerAutomateのトリガーはOffice 365 Outlookコネクターを利用します。ただし、Office 365 グループ宛ての新着メールをトリガーする場合、このトリガーの「新しいメールが届いたとき(V3)」や「新しいメールが共有メールボックスに届いたとき(V2)」を使ってもトリガーすることができません。
Office 365グループ宛ての新着メールをトリガーしたい場合は、Office 365 Groups Mailコネクターを利用して、「When a new email arrives to a groupトリガー」を設定する必要があります。
どのグループからのメールをフックするかを選択し、
Get a thread postアクションで投稿を取得します。
改めてGroup IDを選択し、Thread IDにトリガーのConversion thread IDとPost IDを設定するとこんな感じに2段階のループになります。
このコネクターで取得できる値はここで説明されています。とりあえず今回欲しいのはこのあたりですね。
属性 | 概要 |
Email address of the user | 送信元メールアドレス |
Name of the user | 送信元名 |
Body content | 本文 |
本文はHTMLメールの場合、当たり前ですがHTMLが入ってきてしまうので、Content ConversionコネクタのHtml to textアクションでテキストに変換してあげます。
メールの件名が欲しい場合は、Get a conversation threadアクションを使って、Conversation topic をComposeしてあげれば取得できます。
参考
https://powerusers.microsoft.com/t5/Building-Flows/Flows-for-Office-365-Groups/m-p/144442
https://flow.microsoft.com/en-us/blog/use-our-new-office-365-groups-mail-connector/
ASP.NET Coreの開発中アプリのコンテナで、テスト証明書を作りHTTPSを有効にする。
Visual StudioでASP.NET Coreのコンテナ対応アプリケーションを作成する場合、プロジェクトテンプレートでHTTPS用の構成チェックボックスを有効にすることでDockerコンテナであっても簡単にHTTPSに対応したアプリケーションを作成できます。一度作成したASP.NET Coreのコンテナアプリケーションの場合は、自前でテスト証明書を作成し、環境変数を設定することでHTTPSに対応することができます。
Dockerfile で 443 ポートを EXPOSE する
HTTPSの構成を無しで作成した場合Dockerfileは80しかEXPOSEしていないと思うので443も追加してあげましょう。
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
Visual Studioでデバックする場合
Visual Studioでデバックする場合は、launchSettings.jsonにHTTPSで起動する旨を記載すると、Visual Studioがよろしくやってくれるのでだいぶお手軽です。おそらくこんな感じになっていると思うので、
"Docker": {
"commandName": "Docker",
"launchBrowser": true,
"launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
"publishAllPorts": true
}
起動設定を見ながら必要な設定を追加します。とりあえずデバックするだけなら、こんな感じですかね。
"Docker": {
"commandName": "Docker",
"launchBrowser": true,
"launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
"publishAllPorts": true,
"useSSL": true,
"environmentVariables": {
"ASPNETCORE_URLS": "https://+:443;http://+:80",
"ASPNETCORE_HTTPS_PORT": "44360"
},
"httpPort": 51803,
"sslPort": 44360
}
Visual Studioは実行時に自動的にテスト証明書を作成しパスワードをユーザーシークレットに保存します。プロジェクトにユーザーシークレットが含まれていない場合は、プロジェクトのコンテキストメニューからユーザーシークレットの管理を選択してVisual Studioがユーザーシークレットを使えるようにします。
この状態でデバック実行を開始すれば、https://localhost/が開きコンテナでのデバック時もHTTPSで開発を進めることができます。