tech.guitarrapc.cóm

Technical updates

Terraform に startswith と endswith が来る

Terraform はその言語である HCLがシンプルで分かりやすいのでとっつきやすい、と言われることがあります。 一方で、組み込み関数であれこれある割に、これがないの!? というのもあります。

そのなくてたびたび困るのが、startswithendswith 関数です。

tl;dr;

  • startswith と endswith をビルトイン関数に入れるPR が先ほどマージされたので、Terraform のリリースにいつ入るか楽しみ (ETAは不明)
  • これで startswith("hello world", "hello")endswith("hello world", "world") が書けるようになる

Terraform の組み込み関数

Terraform には組み込み関数 がありますが、バージョンが積み重なっても関数が増えることが少ない印象があります。

どんな関数があるかというのは、 Build-in Functions を見るといいでしょう。

www.terraform.io

startswith や endswith は組み込み関数に存在しない

この中で String Functions = 文字列操作の関数を見ると、StartsWithEndsWith に相当する関数がないことに気づきます。 ないのでどうするかというと、regexsubstrtrimprefix/trimsuffix あたりでやられることが多いと思います。1

# regex での startswith 代わり
can(regex("^vpc-", var.vpc-id))

# substr での startswith 代わり
substr(var.domain2, 0, length(var.domain1) + 1) == "${var.domain1}."

# trimprefix での startswith 代わり
trimprefix(var.domain2, var.domain1) != var.domain2

これでもいいという意見もありそうですが、さすがに startswith で済むものを流し読みしにくい感じで書かれてもうれしくないものです。

# startswith があればこれでいい
startswith(var.vpc-id, "vpc-")
startswith(var.domain2, var.domain1)

ということで Issue が 2021年には立っていたのですが、そこそこスルーされていました。

github.com

別の Issueですが、開発チームとしては従来のやり方でできるなら足したくないという意向があるようです。 startswith でもそれが適用されるのは、あんまりな気もしますがそういう方針なのでしょう。この方針ならとあきらめてました。

We're being pretty cautious about adding new functions that overlap with existing use-cases because Terraform has grown quite an unwieldy collection of builtins over the years, and so we've been considering various ways to allow for externally-defined functions (e.g. #2771) to avoid continuing to grow that set. https://github.com/hashicorp/terraform/issues/28855#issuecomment-856345294

組み込み関数として入れる意向とPRマージ

突然、startswithendswith は組み込み関数に足すのはありという方向に変わります。

I took your comments back to the team, and we revisited this particular decision. We do not need to wait for a function provider framework for these functions. In this case, startswith and endswith meet a sufficiently wide use case need to be considered for built-in functions. https://github.com/hashicorp/terraform/issues/28209#issuecomment-1123022185 より引用

ということでPRが提案され、2022/July/15 にマージされています。

github.com

これにより、次か近いバージョンで startswithendswith が使えるようになりそうです。 ヤッター。

おまけ: カスタム関数という道

Issue で知ったんですが、プラグインでカスタム関数を入れるという提案が 2015年から放置されていたりするんですね。 あったとしても、HCL ではあんまり使いたくない気もしますがどうなんでしょう。

github.com


  1. 例を書いておいてなんですが、やっぱりひどい。

Visual Studio 2022 でインラインで型名やパラメーター名を表示する設定

Visual Studio は便利ですが、Rider や Resharper を考えるとまだまだよくなる余地を感じます。 そんな中で Visual Studio 2022 になって有効にしている便利な設定をメモしておきます。

tl;dr;

コード上で分析情報や型、パラメーターをインライン表示できるようになり、目線をコードから移動せずに済むので便利。

  • Text Editor > C# > Advanced > Display diagnostics inline (experimental)
  • Text Editor > C# > Advanced > Display inline parameter name hints
  • Text Editor > C# > Advanced > Display inline type hints

きっかけ

Rider の Inlay hints がうらやましい。VS2019 のころに Rider でいいなぁと思っていたのが Inlay hints でした。1

www.jetbrains.com

Type name hints や Code analysis hints は、個人的に欲しいと思ってたものの Visual Studio ではどうやるのかなぁと思いつつ放置していたのでした。(やれると思ってなかった)

Visual Studio でインラインでヒントを表示する

Visual Studio 2022 では、Rider を見ててよさそうだった次の3つの設定を有効にしています。実際とてもいいので、しばらくは有効なままでやっています。

  • Display diagnostics inline (experimental)
  • Display inline parameter name hints
  • Display inline type hints

設定前後のコード表示を見ると、得られる情報量が違っているのがわかります。

設定前のコード表示

設定後のコード表示

Display diagnostics inline (experimental)

この設定を有効にすると、Error List で表示されていた分析情報 が コード上にインラインで表示されます。 Error List は常に見たいですが、IDEの下は一等地なのでそればかり見るわけにもいかないのでインラインでお知らせしてくれるほうが好ましく感じます。

Display diagnostics inline (experimental) 有効化前

Display diagnostics inline (experimental) 有効化後

設定は Text Editor > C# > Advanced > Display diagnostics inline (experimental) から行えます。

Display diagnostics inline (experimental)の設定箇所

ただし欠点もあり、書いている最中でも警告を出してきます。例えば、書いている最中の、文末のセミコロンがないというのさえ警告が出てきます。この時 at the end of the line of code にしていると、書いている最中のコードに被って何も見えなくなるので、on the right edge of the editor in window が妥協ラインになります。ただ、画面ギリギリの時に結局かぶるのですが。

書いている最中は警告出ないか一行上とかにずれてほしいものですね。

Display inline parameter name hints

この設定を有効にすると、メソッドのパラメーター名がコード上にインラインで表示されます。 時々、メソッド引数を enableNantoka: true のようにパラメーター名を明示して指定することがありましたが、それはこの設定で見たい情報に他なりません。設定しても今後もやるんでしょうが、コードリード上も便利で好ましく感じます。

Display inline parameter name hints 有効化前

Display inline parameter name hints 有効化後

設定は Text Editor > C# > Advanced > Display inline parameter name hints から行えます。

Display inline parameter name hints の設定箇所

気づいていなかったのですが、Visual Studio 2019 v16.8 で Display inline parameter name hints (experimental) として提供されていたんですね。

devblogs.microsoft.com

Display inline type hints

この設定を有効にすると、メソッドのパラメーターごとの型がコード上にインラインで表示されます。 var の型表示や メソッドのパラメーターの型もうれしいのですが、特にラムダ式でパラメーターの型がインラインでわかるのは思ったより便利で好ましいです。

Display inline type hints 有効化前

Display inline type hints 有効化後

設定は Text Editor > C# > Advanced > Display inline type hints から行えます。

Display inline type hints 設定箇所

まとめ

Visual Studio も粛々と進化しているのでいいですね。 そういえば、VS2019 で .NET 6 がサポートされていないのは悲しいと思うのでした。 .NET 6 使いたかったら VS2022 というのは、.NET にとってはネガティブインパクトが強そうですね。


  1. inline じゃなくて inlay なんですね

Azure SDK for .NET の認証を DefaultAzureCredential にそろえる

Azure SDK for .NET はなぜか AzureCredentialsDefaultAzureCredential という2つの認証方法があります。

今回は AzureCredentials しか受け付けない Azure SDK のクライアントに、DefaultAzureCredential で得た認証を使いたいというメモです。

tl;dr;

  • DefaultAzureCredential でとった認証はTokenを経由してAzureCredentials で利用できる
  • Token は 10分で切れるので長時間実行に使いまわすには 再度認証をとるなり工夫が必要
  • 多少の手間があってもDefaultAzureCredential のほうが認証の取り方が楽なので使っていきたい

AzureCredentials をなぜ使いたくないのか

AzureCredentials は古い Azure SDK (あるいは移行されていないSDK) でのみ利用されている (?) 気配です。AzureCredentials を使うには、個別サービスパッケージ Microsoft.Azure.Management.Xxxxx 以外にMicrosoft.Azure.Management.ResourceManager.Fluent を参照します。

例えばこんな感じで使えます。

gist.github.com

AzureCredentials は触ってみると使いにくい点がいくつかあります。

  • ローカルでの認証 (例: ServicePrincipal) や Managed Service Identity (System Assigned Identity / UserAssigned Identity) ごとにインスタンスの生成方法が異なる
  • NewtonSoft.Json 10.0.3 に依存していて脆弱性が解消されていない。1
  • 生成方法が SdkContext.AzureCredentialsFactory.FromXxxnew AzureCredentials(new XxxInformation の2つがありAPIから推測する情報が多い

Newtonsoft.Json の脆弱性 https://github.com/advisories/GHSA-5crp-9r3c-p9vr
medium.com

次に示す DefaultAzureCredential や他クラウドでの認証を考えると触りたくないと感じます。

DefaultAzureCredential でどう変わるのか

DefaultAzureCredential は新しい Azure SDK for .NET で利用が進んでいる気配で、新しいSDK やインターフェースでは DefaultAzureCredential が利用されています。(全部じゃない) DefaultAzureCredential を使うには、Azure Identity SDK を参照します。

例えばこんな感じで使えます。

gist.github.com

DefaultAzureCredential は、new DefaultAzureCredential() あるいは new DefaultAzureCredential(new DefaultAzureCredentialOptions())とインスタンスを生成するだけで動作環境から自動的に認証を取得します。例えば、環境変数、Azure環境上で Managed Service Identity (System Assigned Identity / UserAssigned Identity) 、Visual Studio、Visual Studio Code、az login など一通りカバーされており便利です。

docs.microsoft.com

AzureCredentials での開発体験を振り返ると、DefaultAzureCredential の「同じインスタンス生成で動作環境に応じた認証をいい感じに取れる」というのは、環境ごとの書き分けがいらないため書き心地が安定しており好ましく感じます。2

特に UserAssignedIdentity と System AssignedIdentity が 環境変数 AZURE_CLIENT_ID の有無で切り替わるのは、利用側で自由に調整できるので非常に都合がいいです。3

docs.microsoft.com

DefaultAzureCredential で得た認証を AzureCredentials で利用する

DefaultAzureCredentialAzureCredentials と型レベルでは互換性がないため代わりに利用できません。 しかし、DefaultAzureCredential でとった認証のトークンは、Microsoft.Rest.TokenCredentials を経由することでAzureCredentials に差すことができます。

こうすることで、認証の取り方はDefaultAzureCredential に任せつつ、AzureCredentials を必要とするクライアントを利用できます。 例えば次のように書くことができます。

gist.github.com

TokenRequestContext は 2022年現在は、https://management.azure.com/.default 固定で問題ないはずです。(Azureはちょいちょい変わるので何も信用できない)

まとめ

ちょっと Azure Database for なんとかのSDK を使って操作しようとしたら AzureCredentials で面食らったのでした。 DefaultAzureCredential は普通な使い心地でいいのですが、AzureCredentials は厳しいものがあるので今後も避けていきたいところです。


  1. Newtonsoft.Json を明示的にパッケージ参照して解消しましょう
  2. 認証の取得の書き心地という意味では、AWS SDK for .NET は AWS IAM との紐づけを含めてもっと洗練されていると感じます。なお AWS SSO の認証は全然ダメなのでよくなってほしい。
  3. 環境変数 AZURE_CLIENT_ID があれば User Assigned Identity が参照される。

Pulumi リソースのプロパティが変わってしまい create-replacement が発生する場合の対処方法

Pulumi のパッケージ更新をしたら、プロパティ名が変わっており craete-replacement が生じてしまう。

Pulumi SDK 側でプロパティ名が変更されると発生するのですが、普段出会うことはまずありません。 しかし稀に、プレビューパッケージを使ったり、プレビューから GA した直後のサービスで起こることがあります。

Azure の Container Apps で最近起こったので備忘録に挙げておきます。

Warning: この対処は、リソースの再作成がかかる 必須プロパティでのみ必要になります。オプショナルなプロパティでは、単純にプロパティ名変更に追随するだけでokです。

tl;dr;

リソースのプロパティ名変更に対応するには、2つの方法が考えられます。

  1. 該当 URN をステートから削除してリソースをインポートしなおす
  2. スタックをエキスポートしてステートJSON を直接編集してスタックにインポートしなおす

残念ながら、リソースの必須プロパティ名の変更で生じる reate-replacement に対処できる Custom Resource Options は存在しません。 類似ケースのIssue があるのですが、プロパティに Alias がつけられるようになれば Terraform の moved ブロックのように何とかなりそうですね。

github.com

問題の概要

Pulumi はリソース URN 自体の移動に対しては CustomResourceoption で Alias を指定することで移動が可能です。 リソースプロパティの無視は Ignore で可能です。

しかし、リソースのプロパティ名の変更が起こった時に、旧プロパティ名から新プロパティ名に変更を追随するためのマーカーを渡す方法がありません。 オプショナルなプロパティであればプロパティ名を変えればいいのですが、必須プロパティの場合 create-replacement が生じてしまいます。

対処方法

要はステートのプロパティ名が違っているので、一度 URN を削除してから同じ URN にインポートしなおすことでプロパティ名の変更に追随できます。 ステートを直接JSONで触るか/触らないかで、2つのワークアラウンドが考えられます。

  1. 該当 URN をステートから削除してリソースをインポートしなおす
  2. スタックをエキスポートしてステートJSON を直接編集してスタックにインポートしなおす

JSONを直接いじりたくないので、1について説明します。

該当 URN をステートから削除してリソースをインポートしなおす。

この方法は JSON を直接触るより手間がかかります。 代わりに、JSON で万が一にも変なところを触ってインポート時におかしくなるという状況は避けられます。

該当ステートの状態をブラウザで確認しておく (オプショナル)

このステップは必須ではありませんが、やることをお勧めします。

この後、Pulumi から URN を削除すると今の Pulumi での状態が見れなくなります。

できれば ブラウザで Pulumi Console の街頭 URN を開いて、プロパティの状態をタブで開いておきましょう。 タブで開いていおくことで、「構築時のコード」と「インポート時に必要なプロパティ」の暗黙の指定が明確に把握できます。 インポート時にコードとリソースの差分が出ても、このタブを見ればどんな違いがあるか推測するのに役立ちます。

該当コードの URN を見つける

Pulumi Console のリソース一覧 (グラフからでも一覧でもよし) を開き、該当の URN を見つけてください。 あるいは pulumi cli であれば pulumi stack --show-urns から探してもいいでしょう。

pulumi stack --show-urns | grep "リソース名"

URN: urn:pulumi:xxx:Stack名::Provider名:なんとかかんとか といったフォーマットの URN が見つかったらメモします。

ステートから URN を削除する

URN を ステートから削除することによって、クラウドプロバイダー上にリソースを残したまま Pulumi の対応を消すことができます。 pulumi cli をつかって、該当の URN 消します。

pulumi state delete <先ほど見つけたURN>

確認されるので y で削除を実行します。

クラウド環境からリソースをインポートする

Terraform同様に、Pulumi もクラウド環境の状態をコードに取り込むことができます。 Terraform は cli で terraform import クラウドリソースID で取り込みましたが、Pulumi はコード上の CustomResourceOptions.ImportId で指定します。

www.pulumi.com

例えば、Azure の Managed Environment であれば次のようになります。

Note: Pulumi.AzureNative を .NET で使っている場合、NuGet パッケージ 1.64.1 から 1.65.0 に更新すると発生します。

_ = new ManagedEnvironment("FooBar", new ManagedEnvironmentArgs
{
    EnvironmentName = "foo", // ここが AzureNative nuget パッケージの更新で Name から EnvironmentName に変わった
    AppLogsConfiguration = new AppLogsConfigurationArgs
    {
        Destination = "log-analytics",
        LogAnalyticsConfiguration = new LogAnalyticsConfigurationArgs
        {
            CustomerId = "ログアナリティクスID"
            // SharedKey = "シェアドキー" <- インポート時に SharedKey は入らないのでコメントアウト必須
        },
        ZoneRedundant = false, // 暗黙のプロパティ で false だが、インポート時は 明示的に指定しないと Diff が出てインポートが失敗する
        ResourceGroupName = "Foo-Group",
        Location = "japan-east",
        Tags = .... // あればちゃんと指定する
    }
}, new CustomResourceoptions
{
    Parent = this, // インポート時のリソースの Parent 指定になるので、コンポーネントと親子関係持たせるなら必須
    ImportId = "/subscriptions/xxxxxxx/resourceGorups/Foo-Group/providers/Microsoft.App/managedEnvironment/foo" // Azure Resource Id
});

インポート時の注意は、現在のリソースとの Diff が生じてはいけないということです。 このため、暗黙のプロパティで与えられる値も明示的に指定が必要です。(例では ZoneRedundant = false は暗黙で与えられるが明示的に指定が必要) インポート時のリソースは、 CustomResourceoptions.ImportId で指定しましょう。Azure の場合はリソースID です。

あとは差分がないか pulumi cli で確認します。

差分があるとインポートは 100% 失敗します、差分がないように気を付けてください。 ただし差分は Diff ではプロパティ名までしか確認できず値がわかりません。 「該当ステートの状態をブラウザで確認しておく」のステップで開いておいたタブでプロパティ値とコードを見比べるといいでしょう。

pulumi preview

差分がなければインポートを実行します。

pulumi up

インポートが成功すればokです。

コードから ImportId を削除する

コードから CustomResourceoptions.ImportId セクションを消して、 pulumi を実行してみて差分が出ず実行完了すれば終わりです。

まとめ

Pulumi の人からリプライがついていますが、Alias がリソースのプロパティに対しても使えれば解決するので近々できるようになったりするといいですね。

相談を受けて、そういえば記事にしていなかったので起こしました。

Windows 11 で Microsoft Teams がログオン時に勝手に起動するのを止めたい

Windows 11 をインストールしたときに戸惑ったのが Microsoft Teams がログオン時に勝手に起動することでした。

使ってないこともあって、無意識に無効にしたのですが先日困っている人がいたので記事にしておきます。

tl;dr;

Windows 11 では、スタートアップアプリ に Microsoft Teams が登録されています。 これを無効にすると、ログオン時に自動的に Microsoft Teams が起動してくるのを止めることができます。

Settings ->

スタートアップ アプリから Microsoft Teams を無効にする

Windows 11 のスタートアップアプリがどうなっているか確認する

Windows 11 の場合、2か所を確認するといいでしょう。

  1. タスクマネージャーの スタートアップアプリ
  2. スタートアップフォルダのショートカット

どちらもこれまでのWindows でも同じものがありますが、Windows 11 では少しアクセスしやすくなった気がします。

タスクマネージャーの スタートアップアプリ

タスクマネージャーのスタートアップ で確認できます。 ユーザーがログオンしたときに起動するアプリが登録されています。

これらのアプリをログオン時に起動するかどうかは、タスクマネージャーで有効/無効の切り替えできます。

Ctrl + Shift + Esc

タスクマネージャーのスタートアップアプリ

また、タスクマネージャーではなく 設定 (Settings) から行うこともできます。

Settings > Apps > Startup Apps に移動

スタートアップアプリ

なお、以前のWindows にあったシステムコンフィグのスタートアップ設定は、前述のタスクマネージャーに移動しています。

スタートアップメニュー や Ctrl +R で起動した実行ウィンドウで msconfig を入力

システムコンフィグのスタートアップ

スタートアップ

Windows の持つ専用フォルダ %appdata%\Microsoft\Windows\Start Menu\Programs\Startup を開くと確認できます。 ユーザーがログオンしたときに実行するアプリのショートカットが登録されています。

このパスにショートカットがおいてあれば起動するので、起動を無効にするにはショートカットを消すか移動します。

Ctrl +R で起動した実行ウィンドウで、 shell:startup を入力

shell:startup

スタートアップフォルダにはショートカットが登録されている

そのほか

Windos サービスやレジストリでの登録などもありますが、直接触る機会はかなり減ったように思います。 その背景には、アプリが自分自身でスタートアップを設定するか設定に持つことが増えたこともある気がしますね。