ローカルのサーバー環境がよくなったので、ローカルでAzure Pipelines / GitHub Actionsのセルフホストランナーを作ろうとしています。最初はpackerでactions-runnerのレポジトリの内容を書き換えてローカルで動くようにしようと思っていたのですが、Ansibleでやったほうがよくないか？ということで（hclはほとんどCopilotに書き換えてもらった）、AnsibleのためにHyper-VのVMをほぼ自動でやるために環境を用意したのでそのメモです。大半はCopilotに書いてもらいましたがテストは自分でやりました。

必要なものは Windows Server 2025(2022でもたぶん大丈夫) と WSL2のみです。WSL2の入れ方はこちらを見てください。

learn.microsoft.com

cloud-initにはmeta-dataとnetwork-config、user-dataの3つのファイルが必要です。meta-dataはこのPowerShellスクリプト内で作るので不要です。

実行のためのPowerShellスクリプト

# 初期化作業
$seeddata = <cloud-initで使うファイルひな形を置いているところ>
$suffix = [system.datetime]::Today.Year.tostring()+[system.datetime]::Today.Month.ToString("00")+[system.datetime]::Today.Day.ToString("00")
$vmName   = "ubuntuagent"+$suffix
$workDir  = Join-Path "D:\HyperV\agent" -ChildPath $suffix
$vSwitch  = <Hyper-Vの仮想スイッチ名>
$cpu      = 4
$memoryGB = 16
$seediso = Join-Path $workDir -ChildPath "seed.iso"

#metadata作成
New-Item -ItemType Directory -Force -Path $workDir | Out-Null

$metadata = Join-Path $workDir -ChildPath "meta-data"
new-item $metadata -ItemType File -Force  | Out-Null
$utf8NoBom = [System.Text.UTF8Encoding]::new($false)
"instance-id: ubuntu-agent-"+$suffix, "`nlocal-hostname: agent-" + $suffix+"`n"  | Set-Content -Path $metadata -Encoding $utf8NoBom

# workfolderにコピー
$userdata = Join-Path $seeddata -ChildPath "user-data"
copy-item $userdata -Destination $workDir -Force
$networkconfig = Join-Path $seeddata -ChildPath "network-config"
Copy-Item $networkconfig -Destination $workDir -Force
Set-Location $workDir

wsl.exe -e bash -lc "sudo apt update && sudo apt install -y qemu-utils cloud-image-utils"

# ubuntu
$imgUrl = "https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-amd64.img"
Invoke-WebRequest -Uri $imgUrl -OutFile "$workDir\ubuntu-24.04-amd64.img"

$disk = $vmName + "-amd64.vhdx"
wsl.exe -e bash -lc "qemu-img convert -p -f qcow2 -O vhdx ubuntu-24.04-amd64.img $disk"
$vhdx = Join-Path $workDir -ChildPath $disk
Resize-VHD -Path $vhdx -SizeBytes 64GB

# このフォルダに user-data  / network-config を保存済みとする
wsl.exe -e bash -lc "cloud-localds -v --network-config=network-config seed.iso user-data meta-data"

# VM 作成
New-VM -Name $vmName -MemoryStartupBytes ${memoryGB}GB -Generation 2 -SwitchName $vSwitch | Out-Null
Set-VM -Name $vmName -ProcessorCount $cpu

Get-VMHardDiskDrive -VMName $vmName | Remove-VMHardDiskDrive
Add-VMHardDiskDrive -VMName $vmName -Path $vhdx

# Secure Boot: Linux（Microsoft UEFI CA）
Set-VMFirmware -VMName $vmName -EnableSecureBoot On -SecureBootTemplate "MicrosoftUEFICertificateAuthority"

Add-VMDvdDrive -VMName $vmName -Path $seediso | Out-Null
$disk = Get-VMHardDiskDrive -VMName $vmName
Set-VMFirmware -VMName $vmName -FirstBootDevice $disk

# ゲストサービス（Guest Service Interface）を有効化
## 英語版OSはこちら
Enable-VMIntegrationService -VMName $vmName -Name "Guest Service Interface"
## 日本語版OSはこちら
Enable-VMIntegrationService -VMName $vmName -Name "ゲスト サービス インターフェイス"

network-config

version: 2
ethernets:
  any:
    # Hyper-V でインターフェイス名が変動しても拾えるようにワイルドカードでマッチして eth0 にリネーム
    match:
      name: "e*"
    set-name: eth0
    addresses: [IPアドレス]
    nameservers:
      addresses: [DNSサーバー]
    routes:
      - to: default
        via: <デフォルトゲートウェイ>

IPアドレスはお好みで。最初使っていないやつ一覧から取得して…とか考えていましたがやめました。

#cloud-config
locale: en_US.UTF-8
ssh_pwauth: false

hostname: <ホスト名>

users:
  - name: agent
    gecos: Azure Pipeline Agent
    groups: [sudo]
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    shell: /bin/bash
    ssh_authorized_keys:
      - 公開鍵

package_update: true
package_upgrade: true

apt:
  sources:
    ansible-ppa:
      source: "ppa:ansible/ansible"
    git-core-ppa:
      source: "ppa:git-core/ppa"

package_update: true
packages:
  - linux-virtual
  - linux-cloud-tools-virtual
  - linux-tools-virtual
  - curl
  - git
  - python3-venv
  - python3-pip
  - software-properties-common
  - ansible

# ルートパーティションとファイルシステムを自動拡張（64GB VHDX に合わせて）
growpart:
  mode: auto
resize_rootfs: true

runcmd:
  - systemctl enable --now hv-kvp-daemon.service || true
  - systemctl enable --now hv-fcopy-daemon.service || true
  - systemctl enable --now hv-vss-daemon.service || true
  - bash -lc "git config --system init.defaultBranch main"
  - bash -lc "mkdir -p /etc/ansible && printf '[defaults]\nhost_key_checking = False\n' > /etc/ansible/ansible.cfg"
  - bash -lc "curl -LsSf https://astral.sh/uv/install.sh | sh"
  - bash -lc "~/.local/bin/uv tool install ansible-core"
  - bash -lc "~/.local/bin/uv tool install ansible-dev-tools --with-executables-from ansible-core,ansible-lint,ansible-navigator"
  - systemctl restart ssh

ホスト名はスクリプトで直せば（書き換えれば）よかったですね。これはめんどくさがらずにやるべきだった…。

start-vm $vmnameでVMが起動するので、指定したIPアドレスでssh接続できるはずです。WSLでsudoするときにパスワード聞かれるので、まぁそこだけうまいことやってください。

これでVMが作成できたので、次はansibleでactions-runner相当のものを入れてみます。

2025-09-27

26の更新

Azure DevOpsリリース Azure Pipelines GitHub Advanced Security

Azure DevOps sprint 262リリースノートの翻訳を行いました。オリジナルはこちらからご覧ください。

learn.microsoft.com

今回の目玉は何といってもCoding AgentをAzure Boardsから呼び出せるようになることでしょう…とはいっても、GitレポジトリはGitHubでなくてはなりません（悲）。GitHub使いつつもチケット管理はAzure Boards使っているところが結構多い、というところでしょうか。プレビュー申請して通ったので、試してみたいと思います。

GitHub Advanced Security for Azure DevOps、今週は小幅なUIの改良とか設定の部分ですね。ほぼ毎回強化が入っているのはセキュリティ対応でしっかり予算が出ているのかなと。

AzureAppServiceManageタスクで拡張機能のバージョン指定ができるようになったそうです。特定のバージョンで固定したい場合は便利です。今回は目玉が一つだけ、という感じでしたが次回は何が出るでしょうね。ではまた三週間後。

translate to Japanese to Azure DevOps release not…

2025-09-20

Microsoftのドキュメントはなぜ「わかりにくい」といわれるのか

Azure Docs Microsoft

Xでも社内でもしばしば「Microsoftのドキュメントがわかりづらい」という声を聴きます。私は印刷物のころから…それこそMS-DOSの時代から、ずーっと見ていたので、慣れきってしまったのか、「わかりづらい」とはあまり思っていません。もちろん初めて聞く概念や初めて学ぶ分野（例えば認証で使う標準技術に関連するところ）に関してはわかりづらいではなく、「知らない」のとMicrosoft外の技術に関しては本来の規格の仕様書を読むのが筋です。標準規格の部分に関しては軽く書かれることもありますが、それを求めるのは酷というか、対象外でいいでしょう。

で、ここではいくつかのタイプを想定して考えてみます。対象は .NET とAzureとしてみます。ほかのドキュメントでも大して変わらないかもしれませんが、私がよく見るのがこのへんなので。

Xのような140文字で「わかりづらい」では何がわからないのかわからないので、この辺はいろんな人の話を聞いてみたいと思っています。誤訳とかは「わかりづらい」ではなくドキュメントのミスなので対象外です。翻訳レポジトリへの貢献いろんな騒動で受けてくれなくなったのは残念です。

完全な未経験者

一部には初学者向けの部分もありますが、私の理解ではMicrosoft Learnは未経験者向けというドキュメントにはなっていないと思います。MCPのxx-900試験を少なくとも初見で受かるような人じゃないと難しいんじゃないかなぁ、と思います。

なので、完全な初学者はLearnで学ぶのではなく（Learnも使いつつ）、別の参考書とかIT基礎的な話が先かなと思います。

何度かAzureや.NETでシステムを作っている人

前提としてMicrosoftの用語はある程度理解できるものとします。これはおそらく日本語の機械翻訳に引っかかるケースかな、と思います。最新のものを除いて、かなりのドキュメントが日本語されるのですが、以前のニューラルネットワークベースのものはお世辞にもわかりやすいとは言えないのかな、と思います。LLMベースになってくるかもしれませんが、製品の名称であるとか、Buildを開発と訳すようなやつですね。

こういうのがちょいちょい引っかかってストレスになってわかりにくさを助長しているというのは理解できます。

Microsoft Learnの翻訳は今かなり少なくなっていると思いますが、人間が翻訳しているものと機械翻訳とが混在しています。今LLMでの翻訳はかなり良くなっているので、あとはプロンプトなどでうまく訳さないところの指示ができれば改善していくかもしれません。私もLLM使って翻訳することあります。

あと、Microsoftが古い（サポート切れた製品の）ドキュメントどんどん消しているのもある意味わかりにくさを助長していると思います。古いものからの積み重ねで「昔はいいコンテンツがあったんだけど」というものも消えて行っています。今はさすがに少なくなったと思いますが、例えばMFCを使わない素のWin32のプログラムの作り方みたいなコンテンツはいいのあったんですが、今はどこに…という感じです。

過去の知識や経験がある人なら気にならない（かもしれない）ことでも、その前提の資料がなくなると新規でやっていく人はどこを見ればいいのかわかりづらいのはあるかなと思っています。

他社サービスを普段使っていて、都合でAzureや .NET を使わなくてはならなくなった人

はじめてMicrosoftのドキュメントを読むことになった人。クラウドの基本知識はあるが、普段使いの用語に慣れきっていて、Microsoftの用語はほとんど知らないとします。おそらく多くの「わかりにくい」と言っている人はここじゃないかなと想像しています。違ったら教えてください。

ここは難しいですね。私も仕事でAWSやOracle, VMwareやRed Hatのドキュメント読みますけど、どこもそれなりに「どこにあるんだ」というケースが多いです。たいていは検索で見たいページ一発で当てられるし、今は生成AIによる検索も便利です。とはいえ、必ずリンク先はみるし、なんなら公式以外探すなとも指示します。

仮に「AWSではこうだからAzureもこうだ」という先入観でlearnを読んでいるとわかりにくいと思います。そうじゃないことがあるかもしれませんが。私AWSのドキュメント読むときは、別物としてAzureことは頭から落として読むようにしています。あと、Azureはどうしてもオンプレミスを含むハイブリッドやライセンスのことも考えると「どこに書いているんだわかりづらい」という点はそうだと思います。