最近AZ-104を取るために勉強を始めました。AZ-104はかなり広い範囲で詳細な知識が求められるので、普通に勉強していてもすぐに忘れてしまいます。
そんなわけで、効率よく復習できるように、最初は面倒でも学んだことを記録に残すようにしようと思います。内容はかなり断片的なので、「まとめる」と言うには程遠いレベルですが、自分が試験直前にざっと復習できるようにすることが目標なのでご容赦ください。
コンテンツは随時更新していく予定。
2022年2月
AZ-104に合格しましたので体験記を書きました。
Azure AD のロール（役割）と権限周り
Azure AD の Global Administratorロールを持つユーザだけがAzureテナントにユーザを作成することができる。AzureのOwnerロールを持っていてもダメ。Azure ADのロールとAzureのロールは別物（ここは難しい）。
Azure ADユーザがAzure Kubernetes Service (AKS) にアクセスできるようにするには、対象のドメインにOAuth2.0のエンドポイントを設定する必要がある
Azure AD のユーザグループにはAssignedとDynamicのタイプがある。Assignedは手動でユーザを追加する。Dynamicは複雑な条件式でルールを作って、例えばDepartmentがSalesならなんとかグループ、みたいなことができる。
Dynamicタイプのグループにマニュアルでユーザを追加することはできない。
さらにAzure ADのユーザグループではSecurityグループとMicrosoft 365グループの区別がある。Securityグループは従来のADにおけるセキュリティポリシーのグループと考えて良い。Microsoft 365グループはかなり特殊な存在。Teamsのアカウントもこのグループに属しているらしい。
有効期限付きのグループを作れるのはMicrosoft 365グループだけ
普通のAzure ADグループは入れ子にできるが、Microsoft 365グループは入れ子にできない。
普通のAzure ADグループを入れ子にした場合、親グループに対するロールは子供に引き継がれる。つまり、親グループの所有者ロールを持ったアカウントは子供グループに対する所有者ロールも保持することになる。
Azure AD ユーザに特定のロールを付与するには以下の手順。
1. 対象のドメインのGlobal Administratorロールを持つアカウントでAzure Portalに入る
2. 左上のブレードから「Azure Active Directory」を選ぶ
3. 対象のユーザを選ぶ
4. 左ペインから「割り当てられたロール」を選ぶ
5. 必要なロールを追加する
招待するとかいう選択肢はない。
Azure AD Premium P2ライセンスを購入して、特定のユーザに割り当てる場合も、基本的には上の手順と同じで、4.の「割り当てられたロール」のところで「ライセンス」を選択してやれば良い。
オンプレのマシンを Microsoft System Center Service Manager (以下 Service Manager)で監視しており、Azure VM で発生したアラートを Service Manager に転送したい時、 The IT Service Management Connector (ITSMC)を使うと良い。
例えば、自分がAD管理者だとする。ADに参加している会社のマシン全てに対してログインできるようにしたい。今後新しくADに参加するマシンに対しても、勝手にログインできるようにしたい。でもPCが多過ぎると一個ずつユーザ追加するのは困難。そんな時、Azureではそれを実現する方法がある。設定の仕方は、左上のブレードから 「Azure Active Directory」 を選択し、「デバイス」を選択。すると、「Additional local administrators on Azure AD joined devices」という項目があり、これを有効にすると実現できる。ちなみに、この選択肢はAzure AD Premiumでないと出てこない。
試験ではこの詳細手順が問われることはなく、とにかく「デバイス」メニューに行けば良い、という事が問われる。
Azure ADにマシン（PCやスマホ）を参加させる場合、対象のデバイスにログインできるアカウントの群を分けることができる。ひとつはAzure AD Registeredでもうひとつは Azure AD joined。joinedの方は、ADに登録されているユーザであれば対象デバイスにログインできる。Registeredの場合はjoinedの人たちに加えて、ローカルで作成したユーザでもログインできるようになる。
他のユーザに対してReaderロールを割り当てられるような準管理者的なユーザを作りたい。特定のリソースに対して。どんなロールを付与する必要があるか？→User Access Administrator role。例えばあるVirtural Network (VNet1)に対する読み取り権限を、他のユーザに付与できるようなアカウントUser1を作りたいとする。この時User1のVNet1に対するロールとしてUser Access Administrator roleを加えてやる。
Azure AD にカスタムドメインを設定する。
1. ポータルからAzure ADに行って「カスタムドメイン」を選択。
2. 独自取得したドメインを追加すると、認証用のコードが発行される。
3. 発行されたコードを独自ドメイン側のTXTかMXレコードに登録する
4. ポータルに戻って認証を進める
MXを使っていいの？って感じはする。
Cloud Device Administrator ロールを持つユーザはAzure AD内のデバイスの追加・削除ができる。
社外の人をADに招待する場合、Azure Active Directoryブレード→External Identities→Manage external collaboration settingsに進んで詳細を設定する。試験では「external collaboration」を設定すれば良いことだけを覚えておく。
ハイブリッドタイプのADを構築していて、あるユーザuser1のソースがオンプレのADだったとする。このときuser1のidentity, contact info, job infoのいずれかを更新したい場合、はオンプレ側のADから設定を変更する必要がある。それ以外はAzure ADから変更できる。
あるユーザがサブスクリプション内にTraffic Analyticsを追加できるようにするためには、対象のサブスクリプションに対するReaderロールがあれば事足りる。
Global Administrators グループにAD Joined デバイスでMFA (Multi-Factor Authentication) を使ってログインさせるような設定を入れたい場合、Azure AD conditional access policy でアクセス許可してやる。間違い選択肢は以下。
・Azure AD conditional access policy で session control 変更する
・user setting で multi-factor authentication ページに行く
オンプレの AD に追加したユーザを即座に Azure AD に追加したい場合、 PowerShell で Start-ADSyncSyncCycle -PolicyType Initial を実行する。
Azure上(Azure ADではない)の権限など
あるリソースグループに後付けでタグを追加するようなポリシーを作成した場合、そのリソースグループに既に存在している配下のリソースにも自動的にタグが追加される（ポリシーを作成した瞬間にタグが追加される）。ただし、対象のリソースグループそのものには追加されない。
一方で、リソースグループにつけたタグは配下のリソースには継承されない。
リソースによってSubscription間を移行できるものとできないものがある。同様に、リソースによってリソースグループ間を移行できるものとできないものがある。同様に、リージョン間を移行できるものとできないものがある。一覧はこちら。傾向としては、リージョン間の移行はまだまだサポートされていない。気になるVMの移行は、普通のVMであればリージョン間の移行までできると考えておいて良い。先の一覧で探すならMicrosoft.Computeの中の.availabilitysetsと.diskと.virtualmachinesががリージョン間でYesになっていることと、さらにMicrosoft.Storageもリージョン間Yesで、さらにMicrosoft.Network内の.networkinterfacesや.networksecuritygroupsや.publicipaddressesがYesになっていることが確認できる。
Azure MarketplaceのリソースをPowerShellからデプロイする際、「User failed validation to purchase resources.」と出る。これを解消するにはPowerShellからSet-AzMarketplaceTermsコマンドを実行する。Azure Portalからではない。
Logic Apps Contributorのロールを持つアカウントはLogic Apps （ロジックアプリというリソース）を追加、編集できる。
DevTest Labs User のロールを持つアカウントは Azure DevTest Labs 内のVMへの接続と、再起動などすることができる。Azure DevTest Labsについては以下を参照。
くらう道：検証環境を素早く構築できる「Azure DevTest Labs」とは？
Azureログを解析するには、Kustoというクエリ構文を使う。こんな感じ。search in (Event) “error”→Eventテーブルからerrorという文字列を探す。多分全カラムから。
VMは同一リージョン内にあるVNetにしか接続できない。厳密にはVMにはNICをアタッチする必要がある。そしてNICはどこかのVNETに所属（接続）している必要がある。NICを別リージョンに属するVNETに接続することはできない。
リソースを動的に生成するVMを作りたい場合、対象のVMのManaged Identity settingsを設定する。 Managed Identity settings の詳細は以下。
Qiita: Azure Managed Identityを使ってソースから資格情報を追い出す
Azure AD のセッティングのひとつに「どのユーザがデバイスをそのADに参加させることができるか？（Users may join devices to Azure AD）」というのがある。デフォルトはALLとなっているが、ここでユーザを指定すると、そのユーザだけがデバイスを参加できるように絞ることができる。ポータル上では 対象の AD を選んで Devices > Device Settings に行くと設定できる。ここで指定されたユーザは Device Administrators ロールが割り当てられる。逆に言えば、このロールが付与されたユーザは無条件でデバイスを参加させることができる。
上と同じようなの設定で「どのユーザがデバイスを登録させることができるか？（Users may register their devices with Azure AD）」というのもある。こちらは、「参加」の前段階の「登録」ができるかどうかを設定できる。メニューの場所は上と同じ。
Global Administrator と Device Administrator ロールは、デフォルトで Azure AD に join したマシンのAdmin権限を持ってログインできる。Cloud Device Administrator はダメ（ログインできない）。
MFA (Multi Factor Authentication) の設定の仕方。多分Azure AD Premium P2ライセンスを購入しないと設定できない。試験ではどの項目を設定する必要があるか、のみ問われる。答えは「Users」「Cloud Apps」「Grants」の三つ。つまり、「どのユーザ」に「どのアプリで認証して」ログインを「許可する/しない」を設定する流れ。以下のリンクを見るのが早い。
チュートリアル:Azure AD Multi-Factor Authentication を使用してユーザーのサインイン イベントのセキュリティを確保する
MFA を設定する時に usage model を作る必要がある。usage model というのは、色んな設定のまとまりと考えれば良い。例えば、ログインする度に認証を求めるか（per login）、ユーザごとに認証を求めるか（per user）の設定や、MFA 対象となるユーザグループの設定など。で、試験ではこの usage model に変更を加えたい時には、既存のものを元にして作り直さなければならないことが問われる。現状では usage model は一度作った後に変更することができない。
オンプレとAzureのハイブリッドADを構成している状態で、オンプレ側に新しいユーザを作った。それをすぐにAzure ADに反映させたい時は、オンプレのマシンで以下を実行する必要がある。
Start-ADSyncSyncCycle -PolicyType Initial
Management Groupに対して行えるアクションがADロールによって異なる。Ownerロールはもちろんなんでもできる。ポリシーをアサインできるのは Resource Policy Contributor と User Access Administrator のみ。さらにほかのユーザに対してアクセス権を与えられるのは User Access Administrator のみ。 User Access Administrator 強い。でも User Access Administrator は Management Groupを作ったり削除することはできない。普通の Contributor ロールならManagement Groupを作ったり削除することができる。なんやこれ。ややこしすぎる。
Delete Lock をかけられる対象は VM などのリソースや、リソースグループ。さらにサブスクリプションにもロックをかけられる。が、 Management Group にはかけることができない。
タグをつけられる対象も上と同じ。
Azure App Service関連
App Service とは[Web Apps][Mobile Apps][Functions][API Apps]のアプリケーション群の総称
App Service を作成する場合、必ず App Service Plan も一緒に作らないといけない。 App Service Plan というのは App Service が実行される環境のこと。ぶっちゃけていうとVMらしい。
App Service を別のリソースグループに移行するには注意が必要。結論を言うと、App Service を別のリソースグループに移行したとしても、App Service Plan は元のRGに居残っている。
App Service がデプロイされる環境を App Service Plan と呼ぶが、 App Service Plan は複数作ることができる。 App Service Plan が複数あっても必ずひとつのある webspace に配置される。webspace はリージョンとリソースグループの組み合わせで一意に決まる。なので、ある App Service Plan がある webspace にデプロイされると、次に同じリージョンの同じリソースグループに作った別の App Service Plan は最初に使われた webspace と同じ環境に作成される。App Service は同一 webspace 内の別の App Service Plan に移行できるが、別の webspace 内にある App Service Plan には移行できない。
上の説明で行くと App Service は別のリージョンに移動できない（webspace はリージョンとリソースグループによって一意に定まり、 App Service は別の wabspace に移動できないため）。でも移行先のリージョンで App Service Plan を作り、そこに移行したい App Service の複製を作れば行ける。
デプロイスロットを追加すると、ステージング環境を用意できる。これによってシームレスな本番適用ができて、失敗した時はすぐに戻せる。アプリが Standard、Premium、Isolated のいずれかのレベルで実行されている必要がある。
デプロイスロットを使いたい場合、App Service Plan をスケールアウトする必要がある。つまり、App Service Plan の設定を Standard、Premium、Isolated に格上げするということ。こんなケースでもスケールアウトって呼ぶらしい。
Web App に CNAME や A レコードを設定することで、カスタムドメインを割り当てることができる。
Storage Account関連
Block blobs, File shares, Page blobsタイプ（この３つの区別をAccount kindと呼ぶ）のストレージアカウントを作りたい場合は、ストレージアカウントを作る時にPerformanceをStandardからPremiumに変更して作成する必要がある。
Storage Accountには3種類ある。GPv1 (General Purpose Version 1)、GPv2、Blob Storageの３つ。歴史的にはGPv2が一番新しく、Microsoftは今後GPv2に移行することを推奨している。
現時点ではGPv1のStorage Accountを作ることはできない。
なので、実質GPv2かBlobを選ぶことになる。この選択はStorage Accountを作る時にPerformanceという項目でStandardかPremiumを選ぶことで行う。StandardがGPv2でPremiumがBlobタイプ。さらに、Premiumを選択するとBlobのタイプを問われる。すなわちページBlob、ブロックBlob、File Shares(?と思うが、普通にFileのことと思われる)。
ページBlobとブロックBlobの違いは、、、？ BlockBlob はランダムな読み書きを必要としないファイルタイプに使われる。例えば jpg のような画像コンテンツは最初から最後まで読み取ることが前提なので、BlockBlob に保存するのが良い。一方、PageBlob はランダムな読み書きが必要なファイルタイプに使われる。例えば vhd ファイル。これはVMのファイルなので、この中にはVM用の HDD なども含んでいる。ということは、ランダムな読み書きが必要という事。こういうファイルは PageBlob に格納するのが良い。
GPv1とGPv2はGeneral Purposeと言うだけあって、色んな種類のデータを格納できる。色んな種類とは、Blob、File、キュー、テーブルの4つ。一方、Blob StorageタイプのStorage AccountではBlobしか格納できない。
GPv1 では、ブロック BLOB、ページ BLOB、File、Queue、Table にアクセスできる。
Azure Import/Export serviceはAzure Blob storage と Azure File storageだけImportできる。
Azure Import/Export serviceはAzure Blob storage だけExportできる。なので、TableやQueueタイプはImportもExportもできない。
Storage Accountにアプリケーションが時間制限付きでアクセスできるようにするにはSAS（shared Access Signature)を使う必要がある
General Purpose v1 (GPv1) アカウントはティア（Tie）をサポートしない。つまり、Hot, Cool, archiveの区別がない。GPv2はある。
ティア（Tie）をサポートしているのはGPv2と BlobStorage のみ。
オンプレにある数TBレベルのデータをAzure Storage Accountにコピーするには、 Azure Import/Export service を使う。物理ディスクをデータセンターに発送する大技。
1. WAImportExportを使ってオンプレのディスクを外付けHDDにコピー（ジャーナルファイルができる）
2. Azure Portalからストレージアカウントに対するImport Jobを作成する（1.の ジャーナルファイル が必要）
3. 外付けHDDをデータセンターに発送（2.でJob作成した時に発送先が指定される）
4. Azure PortalからImport Job をアップデートする（3.で取得したdelivery tracking numberを入力するのと、「発送したよ」チェックをONにする）
ちなみに WAImportExport を使う前に dataset.csv と driveset.csv を作成する必要がある。 dataset.csv は 移行したいフォルダ名やファイル名を記述する。 driveset.csv 対象のドライブを指定するのと同時に、それが暗号化されているかいないかを示す。
Storage Account に File share (ファイル共有) を作った場合、 UNC は以下の構成。
\\ストレージアカウント名.file.core.windows.net\ファイル共有名
例えば Storage account の名前が contosostorage で、ファイル共有の名前が data なら以下。
\\contosostorage.file.core.windows.net\data
注意点としてはサブスクリプション名は含まれない。なるほど。 これのせいでストレージアカウントの名前はAzure全ユーザ間で重複してはいけないのか。
Azure Support の Live migration サービスはストレージアカウントをZRSに変換してくれる。ただし、対象のストレージアカウントはLRSでなければならない。
ZRSはGP2、Premium block blobs、Premium file sharesしかサポートされていない。しかも地域限定。詳しくは以下のページ。
Azure Storage の冗長性
Storage Account は普通に作るとインターネットに公開される（URLさえ知って入れば誰でもアクセス可能になる）。
それを阻止するには以下のようにする。
1. Storage Account の Firewall & virtual networks の設定で、「Selected networks」を選択する。
2. アクセス元のIPアドレスを登録する。レンジで指定しても良い。
VM から Storage Account に接続したい場合は、VM と Storage Account は同一リージョンに存在する必要がある。その上で、VM側のVNetの「Service Endpoint」の設定で、「Storage Account」へのエンドポイントを作成する。この辺りの概念はかなり難しい。なぜなら Service Endpoint と聞いてもピンとこないから。 個人的にこの用語を聞くと「何かのサービスが、他のアプリに接続させてあげるための足だしポイント（=Endpoint）」のようなイメージを持ってしまう（私だけ？）。で、Storage Account が VNet に接続させてあげるようにする必要があるので、Storage Account 側で設定する必要があるんじゃないの？となって混乱します（※1）。しかし、ここでは「VNet が Storage Account に接続させてあげるようにする」ために、VNet 側でStorage Account への「足だしポイント」を作成する必要がある、と考えれば考えやすいか、、、
※1：実際にはStorage Account 側の設定からでもVNetからの接続を許可することができますが、やっていることは VNet に Service Endpoint を作成する設定なので、結局は「VNet に Storage Account への足だしポイント（Endpoint）を作成する」という考え方で良いと思います。
Azure Import/Export service を使って Azure にデータを送りたい時、送り先として使えるのはどれか？（他の選択肢に惑わされないように太文字を選択する。）
a virtual machine
an Azure Cosmos DB database
the Azure File Sync Storage Sync Service
Azure File Storage
Azure Blob Storage
Azure Data Lake Store
Azure SQL Database
Azure Data Factory
Locally Redundant Storage (LRS) では 1ゾーンの中の異なるDCに3つのレプリケーションが同期的に作られる。
AzCopy でコピーできるのは blob と file だけ。table と queue はサポートされていない。まあ、妥当とは思う。
AzCopy を使うとき、認証方法は基本的に SAS (Shared Access Signature)しか使えない。ただし、Blobをコピーする時は Azure AD でも認証できる。
SQL Server の Docker インスタンスに使う用途でストレージを用意する場合、どのストレージ（Azure File/Blob/Table/Queue）が適切か？→Azure File が正解。Blob は恒久的なアタッチができないし、Tableタイプはそもそも「分散Key-Valueストア」、つまり No SQL。
「Availability Set (可用性セット)」を設定することで、VM の可用性をコントロールすることができる。ここで、可用性とはメンテに対する可用性と障害に対する可用性に分類される。Update Domain (更新ドメイン) とは、メンテの時に一緒に落ちるグループを指す。Fault Domain (障害ドメイン) とは、電源障害や共通のHDDに障害があったときに一緒に落ちるグループを指す。New-AzAvailabilitySet というコマンドの引数として Update Domain 数と Fault Domain 数を指定することで、可用性を高めることができる。与える数字が多いほうが可用性が高いが、3 以上の数字を与えてもいいの、、、？
Azure lifecycle management rules を使うと、データのアクセス頻度に応じて適切にティア（hot/cool/archive）を設定してくれる。
Azure lifecycle management rules は GPv2, Premium Block Blob, BlobStorage で使うことができる。 BlobStorage タイプと言うストレージアカウントは新規では作れないように見える？
マップドライブ（またはネットワークドライブ）として使えるのは Azure Files だけ。Blobタイプはマップできないので、Azure ポータルとか AzCopy を使ってファイル操作しないといけない。
Azure file share をマップする場合、開けなければいけないポートは445。これはSMB (Server Message Block) が使うポート。
Azure File Sync 関連
Azure File Sync では Cloud Endpoint はひとつの Sync group につきひとつ。一方、 Server Endpoint は複数あっても良い。一つのサーバ内の複数フォルダでも良い。でもクラウド側は必ずひとつ。
Server Endpoint にファイルを作成すると、サーバ内の Azure File Sync change detection job が即座に変更を検出し、他のエンドポイント（=グループ内の Server Endpoint と Cloud Endpoint）に即座に共有する。
一方、Cloud Endpoint にファイルを作成すると、Server Endpoint 側に共有されるには最大24時間かかる。なぜなら Server Endpoint側（つまりローカル側）の Azure File Sync change detection job は1日に1回しか走らないから。
Server Endpoint を作成する際、「クラウドの階層化（tiering）」を設定できる。これは、 Server Endpoint の物理ディスク容量を節約するための設定で、あまり使わないファイルはクラウドのみに保存して、ローカルサーバディスク上ではキャッシュのみを保存する仕組み。
Azure File Sync agent をインストールする時、Storage Sync Service のリソース名を登録する必要がある。なので、Agent をインストールする前に Sync Service を作っておく必要がある。
Azure Recovery Service Vault 関連
Azure Recovery Service Vault (日本語では Recovery Service コンテナと訳されているっぽい) では、なんだかよく分からないが、とにかく各種リソースをバックアップできる。
Azure Recovery Service Vault を作成する際、Subscription を指定する必要がある。
Azure Backup Report を設定すると、 Azure Recovery Service Vault にバックアップされた内容の統計を取ることができる。どのリソースが何回バックアップされて、サイズはいくつになっているか、どのリソースで課金されているかなどを測定することができる。
Azure Backup Report を利用するには Log Analytics workspaces を作成する必要がある。 workspaces を作成する際、Subscription を指定する必要がある。しかし、workspace と コンテナ（ Recovery Service Vault のこと）のSubcription は同じでなくても良い。同様に workspace と コンテナ のリージョンは同じでなくても良い。なので、 workspace に制限は少ない、と覚えておく。一方で、 コンテナと Storage Account は同一リージョンでなければならない。
Recovery Service Vault で VM をバックアップする場合、一つのVMに対して複数の Vault (バックアップ先) を指定することはできない。
Vault を変更する場合（つまり、バックアップ先を変更する場合）、先に既存のバックアップ設定を停止しなければならない。
Recovery Service vault を削除する場合、最初に「バックアップを停止する」必要がある。次に、バックアップされたデータを削除する必要がある。
Recovery Service Vault では blob データをバックアップできない。なのでGpv2 のストレージアカウントがあったとして、その中に blob コンテナが作成されている場合、そのストレージアカウントをまるごとバックアップすることはできない。
Recovery Service Vault では vault と同じリージョンにあるリソースしかバックアップできない。 リソースグループのリージョンは関係ない。 なぜ、、、、？
Recovery Service Vault とは別に、オブジェクト レプリケーションと言う機能がある。これは Storage account 内の指定したBlob ストレージを、別のリージョンに非同期でレプリケートする機能。Storage account 自体のレプリケーション設定（ZSR や LRS）とも異なる機能らしい。この機能が使えるのは Storage account の account kind が GPv2 か Premium Block Blob のみ。
ここで、似たようなバックアップ機能が3つ出てきたので簡単にまとめておく
Storage account のレプリケーション・・・Storage account 自体をZRSやGRSのような方式で複製する。ZRS をサポートしているのはGP2、Premium block blobs、Premium file shares といった制約がある。
オブジェクトレプリケーション・・・Storage account 内のストレージを別リージョンに複製する。この機能をサポートしているのは GP2、Premium block blobs だけ。
Recovery Service Vault ・・・Storage Account だけでなく、色んなリソースをバックアップできる。ただし、同一リージョン内にあるリソースしかバックアップできない。
その他
VM のアラートログを監視したい場合、Microsoft Monitoring Agent VM extension をVMに add するのではなく、install する必要がある。
VM のアラートログを監視したい場合、以下の三つの設定をする。
1. Azure Log Analytics workspace を作成する
2. Microsoft Monitoring Agent を VM にインストールする
3. Azure Monitor で監視するアラートを設定し、データソースとして1. で作成した workspace を設定する。
VM への全てのアクセスをモニタしたい時は、以下の設定をする。
1. 当該リージョンで Network Watcher を有効にする
2. サブスクリプションに Microsoft.Insights provider を登録する
3. Network Watcher の画面から NSG flow logs を追加する
Credit alerts は 設定した予算の90%と100%に達した時に自動的にアカウントのオーナーにメール送信される。
アラート設定において、条件発動した時に送信できるメールやSMSの数量には制限がある。メールは1時間に100通まで。SMSは5分に1通。Voice Message も5分に1回。
リソースのデプロイを自動化したいと思ったら、Azure で使うのは Azure Resource Manager (ARM) を使う。ARM ではプログラミングのような制御構文も利用できる。例えば反復する時は copy 構文を使う。copy を使うと対象のプロパティに対する値を動的に与えられる。例えばVMに複数のディスクを割り当てたい時など。
リソースが作成された日付を知りたい場合は対象のリソースグループを選んで、Deployment メニューに行く。これはリソースがテンプレートで自動的に作成された場合も同じ。
Kubernates に YAML ファイルを割り当てる場合、kubectl コマンドを使う。az aks というコマンドではない。
AKS (Azure Kubernates Service) に Pod をデプロイする（要はコンテナにアプリをデプロイする事）場合、az acr build コマンドを使う。acr とは Azure Container Registry のことで、Azure におけるコンテナサービスと考えて良さそう。
kubectl をローカルマシンにインストールする場合、 az aks install-cli と打つ（Azure CLI が入っている前提）
AKS で使うアドレス範囲で重要なのは Pod CIDR と Service CIDR. Pod CIDR はそのままで、 Pod に割り当てられるレンジ。Service CIDR は Pod 内のサービスに割り当てられるレンジ。
VM を異なる VNet に移動させることはできない。やりたい場合は VM と ディスクを切り離し、ディスクを移動先の VNet からアクセスできるようにした上で、VM を作り直す必要がある。
ASP.NET Core apps は Windows でも Linux でもインストールできる。
Azure Web Apps は 同一リージョンにある App Service plans にしかデプロイできない。
DNS のポートは53。HTTPは80でHTTPSは443（念のため）。
Azure Private DNS Zone はVNet 内のみで動くDNS。VMにドメイン名をつけておいて、他のVMがそのドメイン名でアクセスできるようにしてくれる。
Azure Private DNS Zone を作ったら、次にVirtual Network Link を作ってVNet と DNS Zone を紐づけてやる必要がある。もっと言うと、 Azure Private DNS Zone のリソースを作る時に聞かれるのは単純に名前だけなので、その zone が受け持つべき ドメイン とVNet を後から指定する必要があるが、その時に使うのが Virtual Network Link だと言える。
Azure Private DNS Zone で Virtual Network Link を設定する際、「Enable Auto Registration」をONにすると、その VNET 内の VM を全部 DNS に登録してくれる。その時、その VM の DNS Suffix は見ない。例えば、 zone 名が aaa.com で、それに対応する VNET の中に VM1 があり、その DNS suffix が bbb.com だったとしても、VM1 は aaa.com に勝手に登録される。
Public DNS Zone は VNet と紐づけたり、自動的に DNS レコードを追加したりすることはできない。
Azure CLI を使うと、オンプレのDNSレコードを Azure DNS にインポートすることができる。 Azure PowerShell ではなく、 Azure CLI。
Virtual Machin 関連
Scale Sets を使って自動的にVMをデプロイする時、例えばWeb Serverをインストールした状態でデプロイしたいとする。そんな時はAzure Resource Manager テンプレートの extensionProfile を設定してやる。さらにVM Scale Set を使う？
ある VM が Planned Maintenance の影響を受けてしまう場合、回避するには Redeploy するしかない。Redeploy ブレードというのがある。
VM のスケールアップ（CPU パワーアップ）する時はVMを停止しなければならない。
VM 5つを含むスケールセットを最速で作りたい場合、スケールセットのオーケストレーションモードを ScaleSetVM にする。
近接通信配置グループ（proximity placement groups）を使うと、VMを単一のデータセンター内にデプロイすることができる。対象となるVMとproximity placement groups は同一リージョンになければならない（当然か）。
今までは VM にアタッチするディスクは非管理ディスク (unmanaged disc) だったが、今は管理ディスクしか使えない。今までの非管理ディスクでは、別途ストレージアカウントを作る必要があったが、非管理ディスクではそれが必要ない。管理ディスクとは（Azureが）管理しているディスク、と言う意味。Azure が管理しているからうまいこと冗長化してくれている。
Linux VM の metrics を監視したい時は、対象のVMに AzurePerformanceDiagnostics extension をインストールする。Linux Diagnostic Extension (LAD) 3.0 というのはない。
テンプレートからVMをデプロイする際に必要なのは username と password。リソースグループも与えないといけない気もするけど、ひとまず username で覚えておく。
月末に負荷がかかる処理をするようなVMがある。負荷を軽減したいが対象のアプリはマルチインスタンスに対応していない（=別のVMにデプロイできない）。そんな時は runbook で VM のサイズを調整してやるような設定を入れる。
VM デプロイ後の各種ミドルウェアの状態をVM間で揃えたい場合、Desired State Configuration (DSC) を使う。これをインストールしておいて、スクリプトを用意しておくと、例えば NGINX を自動でインストールできる。
上と同じようなことは Azure Custom Script Extension でもできる。その場合、SetupComplete.cmd というバッチファイルを作成して、%windir%\setup\scripts に入れておく。そうすると、OS がインストールされた直後にそのバッチファイルを実行することができる。
VM をデフォルトのドライブセッティングで作ると、Cドライブだけが作られる。その後、Dを追加して、そこに入れたファイルはVMをリデプロイすると消える。
On premise の VM を Azure にもっていきたい場合、VM の世代とハードディスクのタイプに注意する必要がある。 Azure は 第一世代のVM の場合は vhd 形式しか受け付けない。なので、第一世代の vhdx で作成されたVM をAzure に持っていきたい場合は vhd 形式に変換する必要がある。が、2021年時点では、Azure は第一世代でも vhdx を受け入れるようになっている。 なので、これを問う問題が今後も出てくるかは微妙。
第一世代か第二世代の大きな違いは、第一世代が BIOS ブートなのに対して 第二世代は UEFI ブートである点。Hyper Vの設定画面の左側に BIOS という文字があれば第一世代と判断して良い。でも第二世代の場合に UEFI とは表記されない場合があるので注意。もう一つの違いはフロッピーがあるかないか。第一世代だけ設定画面にフロッピーが出てくる。第一世代と第二世代の違いはこれだけではないので、詳しくは自分で調べる。
vhd と vhdx の大きな違いは vhdx の方はハイパーVを起動したままディスク容量を変更できる点。名前から察しがつくように、歴史的には vhdx の方が新しく vhd の上位互換と言える。Hyper V を作成する場合、デフォルトでは vhdx 形式が選択される。
第一世代⇔第二世代はVM作成後変更することはできないが、vhd ⇔ vhdx は変換することができる。
ARM (Azure Resource Manager) テンプレートでデプロイした時のテンプレートを後で参照するにはリソースグループの「Deployments」に行く。
VM がメンテナンスの対象になって、すぐにどこかに移行したい時は「リデプロイ」する。
VM に使われる CPU のクォータ制限には割り当て解除済み（deallocated）のCPUもカウントされる。つまり、VM が停止していてもカウントされてしまうという事。
ランサムウェア（ransomware）にかかったVMで、ファイルを復旧するために File Recovery 機能を使う。この時、元のVMを使っても良い。ほかにもOSが同一ならどんなVMにでも復旧させられる。ただし、同一リージョン内にいないといけない。
上の例で、VM自体を復旧させたい時も、同一VMに復旧できるし他のVMにも復旧できる。この場合もOSやリージョンは同一でなければならない。
バックアップを設定する時 Backup Pre-Check status で警告が出たら VM にインストールされている Azure VM Agent のバージョンが古い可能性がある。
テンプレート内で設定できる障害ドメイン数（platformFaultDomainCount）の最大値は2 か 3。リージョンによる。アップデートドメイン数（platformUpdateDomainCount）の最大値は20。
NSG (Network Security Group) をデフォルトで作ると、全ての Inbound をブロックする。ただし、同一VNETからのアクセスはOK。ロードバランサーからのアクセスもOK。一方、Outbound は全て許可。
VM をコマンドから作りたい場合、az vm create コマンドを使う。New-AzureRmVm とか New-AzVM とかではない。
Availability Set （可用性セット）に登録されている VM のサイズを変更したい場合、同一 Availability Set に登録されている全ての VM を停止しなければならない。サイズの変更する際、場合によっては VM をホストするハードの変更を伴う可能性がある。Availability Set に登録されている VM たちは、可用性を確実に管理するため同一のハードにデプロイされている。なので、別ハードに移る時はみんな一緒になる。みんな一緒になると、その Availability Set に VMがいつくあるか分からないし、どれだけ時間がかかるかもわからない。なので、VM は全部停止して置け、という理屈。
VM にアタッチされているディスクを取り外す場合、VM を停止する必要はない。
オンプレのVMを Azure にアップロードしたい場合は New-AzImage か Add-AzVhd コマンドを使う。New と Add がややこしい。
オンプレの VM を Azure にレプリケートしたい場合にセットアップすべき要素は三つ。Hyper-V site , Azure Recovery Services Vault, replication policy 。詳細は以下。
Azure にオンプレミス Hyper-V VM のディザスター リカバリーを設定する
VPN のネットワークトポロジは、Point to Site (P2S) 型と Site to Site (S2S) 型がある。P2S は複数の Point （つまりクライアント）から、一つの Site （ネットワーク）にアクセスさせる形。よくあるのは、社員に自宅から社内ネットワークにアクセスさせてあげる時のようなケース。各クライアントから対象ネットワークに対して個別の VPN セッションが張られる（と思う）。
一方、S2S はネットワーク同士をつなげるカタチ。それぞれのネットワークにゲートウェイを設置するため、両ネットワーク間の通信経路はゲートウェイ間に集約されるので、VPN のセッションもひとつだけになる（と思うけど自信がない、、、）
VPN クライアントが存在するVPNネットワークにおいて（要は Point to Site VPN）、VPNネットワークの構成が変わった時、VPN クライアント側は VPN client configuration package を再インストールし直さないといけない（VPN client configuration package って何、、、？）。
Microsoft SQL Server Always On availability group とは SQL Server 2012 から追加された機能で、DB のフェイルオーバーを勝手にやってくれるもの。例えば、2台の VM に目的の DB を入れておいて、Always On 可用性グループに登録しておき、SQL へのアクセスのフロントエンドとしてロードバランサーを置いておく。SQL クライアントは常にロードバランサーに問い合わせするようにしておき、あとはロードバランサーがそれぞれの VM の状態を見て適切にリクエストを割り振ってくれる。この設定はかなりややこしい、実用性はあると思う。
SQL Server AlwaysOn 構築メモ（その１）
Always ON 可用性グループの構築についての詳細は難しすぎてここでは紹介できない。が、試験では、ロードバランサーが Always ON 可用性グループをリッスンするために、どのような設定が必要か問われる。ここではとにかく「フローティングIPを有効にする」を選択する（この設定が何を意味しているのかはよく分かりません、、、）。
VM に静的なプライベートIPを設定するには Set-AzureStaticVNetIP コマンドを使う。
Azure Backup 以下の全てのバックアップをサポートしている（他にもあると思うけど選択肢としては以下が出てくるので、全て選択する）。
・Windows 10
・Windows Server 2012 以降（※1）
・起動しているVM
・起動していないVM
・Debian 8.2 以降
※1: 厳密には Windows Server 2008 以降サポートしている
VNet をピアリングする時、お互いのアドレススペースがかぶっていたらだめ。例えば、以下の二つはピアリングできない。
VNet1: 10:11.0.0/16
VNet2: 10:11.0.0/17
Azure Virtual Network (Vnet) の基本。Vnet は Azure 内の仮想ネットワーク。Vnet を作る時、アドレススペースを指定する。例えば10.0.0.0/16のように。で、Vnetの中に必ずサブネットを作成する必要用がある。なので、Vnet > subnet という関係。Vnet の中には複数のsubnet を作成することができる。例えば subnet1 = 10.0.0.0/24 で subnet2 = 10.0.1.0/24 のように。
同じ Vnet の中ならプライベートIPで通信ができる（もちろん、NSGや Windows Firewallの設定がきちんとしている前提で）。でも異なる Vnet 間ではプライベートIPで通信はできない。パブリックIPを使えば通信はできる（当たり前だけど）。
VNet が既にピアリングされている場合、その VNet に新しい Address Space を追加することはできない。一度ピアリングを解除してやる必要がある。
ロードバランサーを使うとき、配下の VM は Availability Set か VM の Scale Set に登録されている必要がある。
ロードバランサーには2種類ある。Basic Load Balancer と Standard Load Balancer. 響きがどっちも似ていて区別しにくいが、Standard の方が格上でお金がかかる。
Standard の方が格上なので、できることが多い。以下はその一部。
・ポートフォワーディング。443で来たリクエストを配下VMの80に流す、とか。
・HA (High Availability) ポートを使用できる。これが何なのかは不明（汗）
・複数の Availability Set (or VM Scale Set) を使うことができる。Basic ではひとつだけ。
Azure の Public IP はリージョンに依存している。つまり、あるリージョンで作った Public IP を別リージョンに移すことはできない。別リージョンにある Resource Group に移動させたとしても、その IP はオリジナルのリージョンにとどまる（というか、どんなリソースであっても別リージョンのリソースグループに移動させたところでリソース自体のリージョンが変わるわけではないか、、、）。
ネットワーク関連
ASG (Application Security Group) を使うと、複数VMのIPアドレスをグループ化することができる。グループ化できると、NSG (Network Security Group) を作る時にすごい楽。例えば、Web フロントのVMが10個あるような場合、NSGの中でそれぞれのIPアドレスに対してルールを作成するのはかなり苦痛だと思う。そこで、ASG で「WebFront」などのようにグループ名を作り、そのグループの中に10個のVMのNICを登録する。すると、NSG の中で、「WebFront向けのトラフィックは80と443のみ許可するよ」というルールを1つ追加するだけで行ける。便利！
IPアドレスではなくNICを登録するのがキモ。NICには複数のIP、例えばパブリックとプライベートのIPが紐づいている。なので、IPアドレスをASGに登録する方式だと、全てのIPを登録しなければいけなくなり、煩雑になってしまうからだと思う。
コメント