Microsoft Build 2022 で気になった発表・更新内容

はじめに

確認した更新情報のソースは以下

Microsoft Build 2022 Book of News

どうでもいいけど日本語翻訳のページ(以下)が最初はあったようだが、今はなくなっているようだ。
https://news.microsoft.com/build-2022-book-of-news/ja/

そのため、Google キャッシュや日本語ニュースサイトでリンク切れが起きていた。少なくとも現時点(2022/5/29 22:00)では。

ということで本題はここから

なお、まだ実際に手を動かして確認したわけではなく、単にドキュメントを読んで理解した限りでの認識を書いているため、実際の挙動と異なる可能性があるのはご容赦願いたい。

気になった発表・更新内容

パートナーシップ

Meta, which has selected Azure as a strategic cloud provider to help accelerate AI research and experimentation for developers

Meta が Azure を使って AI 学習の技術革新に貢献してくれることが期待される。
MicrosoftAWS, Google Cloud と比べてこういうパートナーシップを一番うまくやっている(実際のところはよくわからんが)気がするので、今後の発展に期待できる。

Azure Container Apps の GA(一般提供)

techcommunity.microsoft.com

App Service のユースケースにはまらないケースで、じゃあ Azure Kubernetes Service を使うのかというと Too Fat 。
ちょうどいい落としどころとして期待できる。
GA したので使っていきたい。

Azure Kubernetes Service

techcommunity.microsoft.com

盛り沢山だった。

Web application routing add-on (preview)

Web Application Routing add-on on Azure Kubernetes Service (AKS) (Preview) - Azure Kubernetes Service | Microsoft Docs

まずはアドイン。 AKS を使って Web サービスを構成しようとすると、 ingress-nginx や Key Vault を使った Secret 管理がほぼ必須になる。
そのためこれらの管理を含めてまるっとパッケージ適用してくれるアドインがあるというのはよい。
実際これらに依存する業務ドメインのアプリケーションの書き換えが発生しないかというとそんなことはないだろうが、パッケージの選定をしなくて済むことは大きいと思う。
あとはクラスターバージョンとともにアドインのバージョンを更新し続ける運用が必要ということになる。(組み込んだわけではないので知らんけど)

An add-in to the Kubernetes-based Event Driven Autoscaler (KEDA)

KEDA | Kubernetes Event-driven Autoscaling

イベント駆動で開発しようとすると Azure Function を選んでしまうのだが、 AKS を使っている場合の選択肢として有用そう。
あとは使い勝手を知りたい。

Managed NAT Gateway

Managed NAT Gateway - Azure Kubernetes Service | Microsoft Docs

NAT のトラブルは Azure を使っていてよくぶつかる問題。
その回避策がインフラ側で提供されていることは安心感がある。
アプリケーションを改修すべき状況であってもすぐに対応できないことは往々にしてある。

Draft integrated experience (preview)

Azure Kubernetes Service (AKS) 用 Dapr 拡張機能 (プレビュー) - Azure Kubernetes Service | Microsoft Docs

Yaml マニフェストGitHub Action のワークフローファイルを簡単生成。
これを見ると開発者が簡単に AKS を始められる準備が整備されていて、よいことだとは思うが、その後のクラスターはもちろんマニフェストファイルの運用どうするんだという問題の比重が大きくなっていっていることに不安を覚える。
どこまでカバーされるんだろう。

あとマイクロサービスにおける Yaml マニフェストの管理方法をみんなどうやっているのかが気になった。
k8s について十分に習熟したチームならマイクロサービスのリポジトリ上でそのアプリケーションの Yaml マニフェストを管理し、基盤部分のみ別のリポジトリで管理すればいいと思う。
実際経験しているのはこうではなく、インフラ基盤の管理チームが k8s をリードしてそのチーム管理のリポジトリですべての Yaml マニフェストを管理している。このあたりのバランスがどこかで変わっていく必要があるのかな、ということを感じた。

Custom node configuration is now generally available

Customize the node configuration for Azure Kubernetes Service (AKS) node pools - Azure Kubernetes Service | Microsoft Docs

インフラエンジニアが喜びそう。
わからんのでお任せしよう。

App Service

techcommunity.microsoft.com

App Service も更新はそこそこあるが個人的に気になったのは1点のみ。

Secure Networking for Every Application

The screenshot below shows both private endpoints (securing inbound network traffic) and regional virtual network integration (securing outbound network traffic) being set up as part of creating a new web application:

Inbound も Private Endpoint に対応。
もう App Service Environment を使う理由はなんかしらのポリシーを満たすため以外にはなさそう。

SQL Database

techcommunity.microsoft.com

CI/CD パイプラインのサポート

With CI/CD pipeline support via GitHub Actions integration, you can build, test and deploy your apps quickly and efficiently.

いまいち読み取れなかった。

Planning new scenarios and use cases for Azure SQL Database local development experience! - Azure SQL Database Devs’ Corner

上記ドキュメントの通り読み取ると、ローカル開発のための環境整備していて、 CI/CD パイプラインは今後検討するよ、ってことでいいのかな。
DB 開発の CI/CD はちょうど気になっている分野なので今後に期待したい。

SQL Database Emulator

Introducing the Azure SQL Database emulator - Azure SQL Database | Microsoft Docs

つい最近 Mac M1 を使っている同僚が「MS SQL が動かないので困っている」と言ってたが、どうやらこの sql-edge の Docker イメージは動くらしいので後で教えてあげよう。
イメージは これ かな

Microsoft Dev Box

techcommunity.microsoft.com

率直に誰が管理するんだろう。
コンプライアンスやセキュリティの観点だと IT 部門だが、イメージそのものは開発チームじゃないと管理できなそう。
開発チームがこれを管理するのが割に合うんだろうか。

Developer Community

techcommunity.microsoft.com

資格は多様化が進んでいる印象。
また、その学習コンテンツも無料で揃ってきている。
全然追ってなかったけど(英語ができれば)専門家に QA する機会が不定期に用意されているっぽいイベントも見かけるので、利用できる状態でありたい。

Teams

www.microsoft.com

Figma 流行ってるのか。全然知らなかった。 draw.io 使ってた。

Power Platform

Microsoft Power Pages

powerpages.microsoft.com

どういうロールの人が使うんだろう。
事例を見る限り非エンジニアってことなのかな。

Windows

WSL が Microsoft Store で利用可能

devblogs.microsoft.com

Microsoft Store からなら管理者権限なしでインストールできるので、ガバナンスが効いている環境で嬉しそう。

終わりに

一通り読んだ。
あとはもう少し試すなどしていきたい。 特に以下。

  • AKS 周り全般
  • Azure Container Apps

Microsoft Azure の資格に紐づくアカウントを整理する

先日レジュメサイトを見直したときに、思い立ってアカウントを整理したのでそれについて書く。

レジュメサイトの乗り換えについては以下。 kheiakiyama.hateblo.jp

結論を3行で

  • 資格情報はプライベート利用の個人アカウントにひもづけたほうがいい
  • 資格情報が紐づくアカウントの切り替えは、 Q&A に投稿することでサポートメンバーに対応してもらえる
  • Microsoft Learn は Azure 使っていなくても学習に便利

整理前の状況

Microsoft Azure の資格情報は以下の URL で確認できる。

ダッシュボード

この資格情報は個人アカウントに紐づく仕様となっている。

私に紐づいているアカウントは以下のとおり。

  • プライベートメールアドレスの個人アカウント
  • 職場メールアドレスの個人アカウント(Microsoft Azure 資格)
  • 職場メールアドレスの組織アカウント

現在勤めている Colorkrew Inc.Microsoft のパートナーで、資格情報を持つ個人アカウントに職場の組織アカウントに紐づけることで、パートナー要件に反映できる。
資格は "職場メールアドレスの個人アカウント" に紐づいていたので、それをそのまま職場メールアドレスの組織アカウントに紐づけていた。

整理が必要な理由

アカウントの整理をした理由は以下の通り。

  • 資格情報の確認が Microsoft Learn 配下のシステムになっている点
  • 職場が変わった場合に手間が発生する点
  • 職場メールアドレスがそもそも永続的に利用できない点

順に説明する。

資格情報の確認が Microsoft Learn 配下のシステムになっている点

繰り返しになるが、資格情報の確認は以下のサイトで行う。

ダッシュボード

上記ページはコンテンツの拡大が著しい、 Microsoft Learn の配下にあるのがポイントだ。

docs.microsoft.com

私の場合、Microsoft Learn はプライベートのアカウントで学習状況を進めており、これが分散されるのは嬉しくない。(見直したところ、職場メールアドレスでも行っていた・・・)
いまいち達成感はないが、ポイントが加算されてレベルが少しずつ増えてほしいものだ。
(ようやくレベル7 !)

また、資格の有効期限延長が可能になり、これが Microsoft Learn 上でレコメンドされるようになっている。

Microsoft 認定ダッシュボード

12月15日、Microsoftは、学習者が最新の状態を維持できるように 新しいアプローチを導入 しました。6か月以内に有効期限が切れる有効な認定資格をお持ちの方は、Microsoft Learnの更新アセスメントに合格することで、毎年、無料で認定資格を更新することができます。

Microsoft認定資格を更新する | Microsoft Docs

このあたりからも Microsoft Learn で主に利用するアカウントと、資格情報が紐づくアカウントが同じであるほうがスムーズであることがうかがえる。

職場が変わった場合に手間が発生する点

docs.microsoft.com

上記のよくある質問を読むと、

  • パートナー組織に紐づけたユーザが、別のパートナー組織に紐づけできる
  • パートナー組織の全体管理者は、ユーザの紐づけを解除できる

らしいことが読み取れる。
問題は私が "職場メールアドレスの個人アカウント" を利用していたことにある。
もしも職場が変わると、離職に伴いこの個人アカウントは利用できない。
つまり自分でパートナー組織の紐づけを解除したり、切り替えることができないことになる。

離職前の会社の全体管理者に依頼するしか解決手段がないことになるため、セルフコントロールできないのはあまりよろしくない。

職場メールアドレスがそもそも永続的に利用できない点

最後にこれは当然といえば当然だが、離職すれば職場メールアドレスは利用できない。
せっかく取得した資格を喪失するのはもったいないので、プライベートのメールアドレスに紐づけておくのが無難だろう。

どのように資格の紐づけを変更するか

Microsoft Learn 内の Q&A ページに投稿することで、資格を紐づけるアカウントを切り替えできる。
私の投稿は以下のリンクなので参考になれば。

How to change email address on Certificate Profile with my MCID? - Training, Certification, and Program Support

MCID や個人情報のやり取りを行う都合上、パブリックな Q&A ページではなくプライベートメッセージでのやりとりが必要になる。

以前のアカウント

  • プライベートメールアドレスの個人アカウント
  • 職場メールアドレスの個人アカウント(Microsoft Azure 資格)
  • 職場メールアドレスの組織アカウント

現在のアカウント

  • プライベートメールアドレスの個人アカウント(Microsoft Azure 資格)
  • 職場メールアドレスの個人アカウント
  • 職場メールアドレスの組織アカウント

また、同時に Microsoft のパートナー組織への紐づけもプライベートメールアドレスに対して行うように設定をし直した。

おわりに

余談だが Microsoft Learn は Git や GitHub などの Generic なコンテンツも扱っているため、Microsoftクラスタに若干遠い人も利用してみるとよいと思う。

すべて参照 - Learn | Microsoft Docs

レジュメの Static site を Jekyll(Azure CDN) から Hugo(Static Web Apps) に乗り換えた話

タイトルで8割書いてるので、あとは補足だけ書く。

サイトはこちら。

cv.kheiakiyama.com

背景

理由1: ビルド遅い問題

GitHub Actions を使ってビルドしているが、ビルドからデプロイまで、約8分前後の時間がかかっていた。

内容を精査すると、主に Jekyll でビルドするための bundle install に時間が大半を占めていた。
また、 Gemfile が Dependabot に検知される要因になっていて、地味に嫌な感じだった。

移行先を検討していたところ、Hugo は使ったことがあり、 2021年時点でベストな静的サイトジェネレータの一つらしいのでそれにした。

Best static site generators of 2021 | TechRadar

理由2: Static Web Apps 使いたい

Azure Static Web Apps – App Service | Microsoft Azure

単に使いたかった。
静的コンテンツだけなら Azure CDN と大して変わらないが、 PullRequest でレビューできるのは便利。

Azure Static Web Apps における実稼働前環境での pull request の確認 | Microsoft Docs

そのうち Function 機能もちゃんと使ってあげたい。

移行方法

Jekyll から Hugo

頑張って載せ替えるだけ。

Jekyll to Hugo by kheiakiyama · Pull Request #2 · kheiakiyama/kheiakiyama.github.com · GitHub

個人のレジュメサイトなので、移行前に使っていたデザインテーマはあきらめて別のテーマに移行した。

Azure CDN から Static Web App

Static Web App への載せ替えは淡々とやるとして、移行は TXT レコードを使ったダウンタイムなしの移行を試したが動かなかったのであきらめて CNAME を切り替えてしまった。

Set up a custom domain in Azure Static Web Apps | Microsoft Docs

TXT record validation 、現在は Zone Apex しか対応してないのでは?というのが予測。

移行後

約8分かかっていたビルド&デプロイが1分10秒前後で終わるようになった。

速いのは正義。

GitHub Actions と Azure Pipeline を両方使っていて思うことを書く

この記事は Azure DevOps Advent Calendar, GitHub Actions Advent Calendar 11日目の記事で、表題のとおり両方を実用していて思うところを書く。

はじめに断っておくと、この記事ではマルバツの比較表は出てこない。
特徴を理解して使い分けが必要というのが結論。

はじめに

サービスができた歴史上、GitHub Actions のほうが後発なので、足りないところを感じる場面が多々ある。
たとえば Yaml の書き方で不便さを感じたり、欲しい job が用意されてなかったり、細かい制御ができなかったりという具合だ。

Yaml の書き方

前提として git-flow に近い形で CI/CD を組むことが多いため、それに沿った書き方をしている。
develop に対して開発環境、 master に対して本番環境があるイメージ。

このときのリリースパイプラインは、トリガーやリソースは環境ごとに異なるが、処理の流れは同じパイプラインを組む、としている。
これを Azure Pipeline で組むと、 Template を作ってそこに環境毎の変数を渡す、という形が実装しやすい。

- stage: xxxx
  variables:
  - group: 'dev-env-variable-group' # ここが prod だと変わる
  jobs:
  - template: deployment-template.yml
    parameters:
      azureConnectionName: '$(AzureConnectionName)'
      resourceGroupName: '$(ResourceGroupName)'
      environment: 'DEV' # ここが prod だと変わる

これと同じことを GitHub Actions でやろうとすると、やりづらい。
そもそも GitHub Actions には Template がない
そのため、ブランチによって処理を変えるなどの対応をするか、Yaml を複製することになる。

ここに対するいいアイデアがあったら知りたい。

GitHub Actions で使いたい Job がない

ないのはどうしようもない。
なかったら作ればいいじゃない、ということで GitHub Actions Advent Calendar を見ると結構多くの人が作っているのがわかる。

GitHub Actions では 6000 以上の Job が Marketplace に公開されているとのこと。
私も1つ作った。
kheiakiyama.hateblo.jp

個人的にはイチから OSS を作る機会は初めてだったので、いい経験になっている。

GitHub Actions で細かい制御ができない

Azure Pipeline ユーザにはおなじみの Approvals and check 機能GitHub Actions にはない。
と書くつもりが、 GitHub Universe で今月末にベータ版が公開されるという発表があった。

Environment Protect rulesでは、例えばデプロイ前に人間(required reviewers)の承認を求めるようにしたり、時間を置いたりできる(今月末にベータとして利用可能予定)
GitHub Universe 2020の基調講演で発表された新機能を紹介、GitHub ActionsのアップデートやDependency reviewなど - クラウド Watch

GitHub Actions の agent は Azure Pipeline の fork ということなので、今後も Azure Pipeline にある機能は適宜取り込まれると期待してよさそう。

The GitHub-hosted runner application is a fork of the Azure Pipelines Agent
Specifications for GitHub-hosted runners - GitHub Docs

ところで GitHub Actions のほうが軽量で実行が速い気がするのは fork だからなのだろうか。

導入するまでの敷居

どのクラスタに対して存在するツールか、という問題だと思っている。
自分がたまたま Azure を利用する立ち位置なので敷居は高くないが、たとえば AWS ユーザに Azure Pipeline 勧めるのは現実的ではない。
とはいえ AWS ユーザにも GitHub(Microsoft 傘下!) はかなり使われているため、GitHub Actions に抵抗はそう感じないはずだ。

また、Azure Pipeline ひいては Azure DevOps を使うとなると、エンタープライズ向けのもろもろの機能がついてきてしまうため、そこに目がいってしまい、まずは CI/CD だけ手軽に導入して試す、となりづらい印象がある。
(それもあってか Azure ではいくつかの機能は内部的に Azure Pipeline を作成する、という挙動がある。個人的にはあまり好きではない)

この点、GitHub Actions は GitHub ユーザにスムーズに利用してもらえる位置づけである。
実際のところ、サービス公開以降 Travis CI や Circle CI ユーザが移行しているのを SNS 上で見かけることは多い。

おわりに

ということで、どちらも甲乙つけがたいので今後も両方使い続けていきたい。

Terraform で Market Place の Azure VM をデプロイするときにやること

Terraform 使い始めてしばらくになるのに知らなかったのでメモを残しておきます。

Terraform 定義

plan block がマストです。

resource "azurerm_virtual_machine" "main" {
  ...

  plan {
    name      = "{Name}"
    publisher = "{publisher}"
    product   = "{product}"
  }
}

storage_image_reference で記載する値と同じようなものを入れることになります。
詳細は Azure Provider のドキュメントを参照ください。

Azure Resource Manager: azurerm_virtual_machine - Terraform by HashiCorp

デプロイ前に実行すること

利用許諾に承諾する必要があります。
Azure ポータルでデプロイするときに画面に表示されるアレですね。

それぞれ以下のコマンドで実行します。

Azure CLI: az vm image | Microsoft Docs

PowerShell: AzureRM.MarketplaceOrdering Module | Microsoft Docs

もちろん該当のサブスクリプションに対して行う必要があるので、そこは注意ですね。

Cognitive Service を使った Jekyll 製の翻訳サイトを話題の Static Web Apps に載せ替えた

昨日書いた Azure CDN + Blob Static website のサイト、載せ替えたい欲求が高まったので載せ替えた。

今回の変更は Build 前だったのだが、今やるなら話題の Static Web Apps で実装するのがよさそう。というかもう載せ替えたい。

kheiakiyama.hateblo.jp

ホスティング

f:id:khei-fuji:20200525124958p:plain
hosting

これまで Azure CDN + Blob static website だったのが Static Web Apps に変わったので非常にシンプルになった。

デプロイ

f:id:khei-fuji:20200525125018p:plain
deployment

デプロイも構成要素が減った分シンプルになった。
Static Web Apps ではリソース作成時、GitHub Action が作成され、 GitHub の Secret にデプロイ用のキーが登録される仕様なので、それを使ってデプロイされる。

パイプラインは こちら

f:id:khei-fuji:20200525125855p:plain
GitHub - Secret

現在は Preview で課金されないことになっているが、個人サイトで使うには金額次第で元の構成に戻す可能性があるため、前の GitHub Action はファイルを残してある。
Disable にできない仕様のようなので、意味がない Trigger 設定にしておく。
参考: How can I disable a github action? - GitHub Community Forum

つまづいた点

Jekyll でデプロイできない

このサイトでは Jekyll を使っていて、Hugo のチュートリアル を見てデプロイ設定を推察して書いていたが、デプロイできずに Issue 投げて質問して解決した。

How do we use for jekyll? · Issue #27 · Azure/static-web-apps · GitHub

これだと NG(Hugo はこのパターン なのに・・)

        app_location: '/'
        app_artifact_location: '_site'

これで OK

        app_location: '_site'
        app_artifact_location: ''

一応回答の通りに対応したが、それだと app_artifact_location がなんのためにあるのかって気もしていて、たぶんそのうち解決するのだと思う。

感想

Static Site 部分、API 部分どちらも Consumption Plan になりますように。(個人でも払える範囲だといいなあ)

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

GitHub Actions を使って Azure CDN + Blob Static website を使った Cognitive Service の翻訳サイトをデプロイ

昔作った Cognitive Service による翻訳サイトのホスティングを普通の方法にアップデートした。

github.com

以前の課題

kheiakiyama.hateblo.jp

  • Azure Function Proxy で静的ホスティングは現代的ではないのと、Function のコストが微妙にかかるのでやめたい
  • Travis CI やめたい
  • 昔の記事まで保持するとコストかかる

ホスティング

f:id:khei-fuji:20200523230047p:plain
hosting

以前は Function Proxy + Blob Storage で配信していた。
当時は Blob Static website や Front Door がなく、CDN の設定もやりづらかった印象だったが、今はよくなっているので Azure CDN に置き換えた。
今回の変更は Build 前だったのだが、今やるなら話題の Static Web Apps で実装するのがよさそう。というかもう載せ替えたい。

デプロイ

f:id:khei-fuji:20200523230104p:plain
deployment

これまで Travis CI で処理していた部分を GitHub Actions で書き直した。
GitHub Actions での Blob へのデプロイは install-azcopy-action でインストールした azcopy が行う。
自分の cv サイトがほぼほぼ同じデプロイ方法 なので簡単に載せ替えできた。

翻訳記事の生成

f:id:khei-fuji:20200523230021p:plain
translate

このサイトは RSS フィードを更新することが目的にあるため、コンテンツが追加されるごとにサイトが再度 Generate されないといけない。
以前は Travis CI のジョブを API で呼び出していたが、今回は GitHub Actions を呼び出す。
公式にあるように repository_dispatch を呼び出す必要がある。

参考:

ほか

ついでに Blob Storage のライフサイクル管理をいじって、90日前より前のコンテンツはすべて削除することにした。
RSS フィードを1週間読まないことはあっても 90日はさすがに不要なので。
経費削減。

Azure Storage のライフサイクルの管理 | Microsoft Docs

{
    "rules": [
        {
            "enabled": true,
            "name": "SaveCosts",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "tierToCool": {
                            "daysAfterModificationGreaterThan": 30
                        },
                        "delete": {
                            "daysAfterModificationGreaterThan": 90
                        }
                    }
                },
                "filters": {
                    "blobTypes": [
                        "blockBlob"
                    ],
                    "prefixMatch": [
                        "translated"
                    ]
                }
            }
        }
    ]
}

感想

GitHub Actions じわじわ詳しくなってきた。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方