「Azure」の記事 - Crieit

Arch Linux（WSL2）にazure-cliをインストール

2023-03-25T17:59:38+09:00

Arch Linuxに（WSL2）にazure-cliをインストールした際の備忘録。

１．必要なパッケージのインストール
　下記に記載のあったパッケージをインストール。
　Python 3.10.10
　libffi　（何かの依存関係でインストールされていた）
　openssl-1.1
　Linux に Azure CLI をインストールする

２．azure-cliのインストール
　yay -S aur/azure-cli　でインストール

３．azure devopsのインストール
　下記を参考にazure devopsをインストール。
　１から４まで実行すると、デフォルトの組織、プロジェクトの設定までできるのでやっておく。
　Azure DevOps CLI の概要

４．PATの設定
　Azure DevOpsにcliで接続するために、下記を参考にPATを作成。
　PATは作成時にトークンが表示されるが、ウィンドウを閉じると二度と確認ができないため、環境変数に設定するなどをして保存しておくこと。
　個人用アクセストークンを使用する

５．az loginの実行
　az login --use-device-code　を実行してログイン。
　az loginでログインしようとすると、「localhostに接続できません」と表示されるので、オプションをつけて実行する。

６．az devops loginの実行
　az devops login --organization https://dev.azure.com/{Organization}　を実行してログイン。
　az loginを事前にしていればトークンの指定は不要、とのことだけど、トークンの入力を促すメッセージは表示されるし、トークンを入れても失敗と表示される。
　だけど、接続はできるようになっている。理由は不明。
　トークンの指定不要であればPATはいらないのでは、と思ったけれど、PATをrevokeすると接続ができなくなるので、PATは必要。

azコマンドでリソースを参照できること、az boardsでワークアイテムの登録までできることを確認。

Azure Data Factory、Synapse AnalyticsとAzure DevOpsの連携

2023-03-21T19:48:40+09:00

何回やっても時間が空くと忘れるのでメモ。
Synapse Analyticsの場合も同じだったので、Synapse Analyticsで実施する場合は、下記のAzure Data FactoryをSynapse Analyticsに読み替える。

１．Azure DevOpsにサインインする。
　Azure Data Factory（以降、ADF）と連携する、組織、プロジェクトを作成する。
　公開しないのであれば、Privateで問題ない。

２．組織をAzure AD登録する。
　ADFと連携する組織の「設定」から、Azure AD連携を行う。
　この時、Azure AD連携を行うとサインアウトになって、再度サインインが必要となった。
　次にサインインする場合は、Azure DevOpsの更新HPから「無料で始める」をクリックする。
　サインインすると無料アカウントのディレクトリになっているので、ディレクトリの切り替えを行って、Azure AD登録したディレクトリを選択すると、作成した組織、プロジェクトが確認できる。

３．リポジトリを初期化する。
　プロジェクトの「Repos」から、リポジトリの初期化を行う。
　mainブランチが設定される。

４．ADFと連携する。
　ADFのFactory Studioにサインインし、管理画面の「Source control」＞Git Configurationを選択して、Azure DevOpsと連携設定を行う。
　Azure AD登録をしていない組織は表示されない。
　リポジトリ、コラボレーションブランチ、発行ブランチなどを設定し、「適用」をクリックする。

Azure Pipelineを使ってリリースする場合の構成の検討

2021-12-05T22:37:31+09:00

Azure Pipelineを使った場合の利点の１つに、リリースするARMテンプレートにはないリソースを削除するところまで自動化できる、という点があると思う。
カスタムデプロイを使用した場合、リソースの差分は手動で削除しないといけないし、完全デプロイをコマンドラインから実行すると、リソースグループ単位で再構成される（確か）
なので、きれいにリリースができるのはとてもいい。

で、じゃあリリースに失敗しても綺麗に戻せるね、って考えたときに、どこから戻す？

本番ADFはライブモードで運用するから、戻すといったらARMテンプレートになるけど、カスタムデプロイは前述のように差分が残る
なので、開発ADF（もしくは検証用ADF）から戻すことになる

開発ADFのブランチ構成は、基本的に以下のようになる
・adf_publish：ライブモードの環境
・main：プルリクエストで反映、adf_publishへ発行用
・work：作業用

adf_publishの内容をリリースする、とした場合、流れは以下
work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF

戻そう、とした場合、本番ADFの状態をどこかに保持しておかないといけない
そうした場合、adf_publshに保存用のブランチを作成しておくほうが無難なんだろうか

work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF
　　　　　　　　　　　　　　　　　　　　　　　∟yyyymmdd_release

上のような構成にしておいて、本番ADFへの反映で失敗したら、yyyymmdd_releaseブランチから戻す
でも、Azure Pipelineのリリースは、Artifactsが必要で、Artifactsは手動実行できない
退避しているブランチに変更入れるわけにはいかない

そうなると、ブランチはmainに作成したほうがいいんだろうか

work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF
　　　　　　　　　　　　　　∟yyyymmdd_release

mainはプルリクエストで変更分をいろいろマージすると思うけど、リリースタイミングでブランチを切っておいて、失敗したらリリースタイミングのブランチで戻して、adf_publishに発行して、本番ADFに反映
いまいちな気がする

work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF
　　　　　　　　　　　　　　　　　　　　　　　∟yyyymmdd_release
↑の構成にして、リリース物件に更新用のreadmeを格納して、そこを更新して戻す、のほうがよさそう
readmeを更新した際のコミットコメントは「リリースに失敗したため、戻し作業を実施」とか？
ちょっとカッコ悪いかな

Azure Pipelineを使ったリリースの実施方法２

2021-12-04T23:58:56+09:00

Azure Pipelineでリリースした際に、増分リリースだと名称変更などした場合に反映先ADFにリソースが残ってしまうので、その対処方法について確認。

◆前提
増分リリース

◆前準備
・デプロイ前後に実行するスクリプトの準備
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-sample-script#pre--and-post-deployment-script
上記をそのままコピーして、反映元のブランチにPowerShellスクリプトとして保存する
トリガーの停止も組み込まれているので別途用意する必要はない
デプロイ前、デプロイ後の処理も、スクリプト実行時の引数で切り分けて実行するようになっている

◆手順
１．ジョブの追加
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-sample-script#script-execution-and-parameters
リリースの前後に、PowerShellを実行するジョブを追加する
デプロイ前のジョブのScript Argumentsには下記を設定する

-armTemplate "$(System.DefaultWorkingDirectory)/" -ResourceGroupName  -DataFactoryName  -predeployment $true -deleteDeployment $false

デプロイ後のジョブのScript Argumentsには下記を設定する

-armTemplate "$(System.DefaultWorkingDirectory)/" -ResourceGroupName  -DataFactoryName  -predeployment $false -deleteDeployment $true

下記のような感じになる

２．保存して動作確認

★注意
トリガーを削除して同じ名前で異なる種類のトリガーを作成したら、リリースでエラーが発生する
同名トリガーの型を更新できない、というエラーだった
TriggerTypeCannotUpdate: Trigger type cannot be updated.null

DataFactoryでトリガーを再作成しようとすると、一度トリガー削除→発行→再作成という手順をとらないといけないけど、Azure Pipelineでも同様らしい

↑スクリプトを修正して解決できた
対処方法は下記。

前準備で作成したスクリプトに下記を追加する
① $triggersToStartの下くらいに以下を追加
同名、かつ、テンプレート内と反映先でタイプの違うトリガーを取得

#Trigger reCreate
$triggersNameAndTypeInTemplate = $triggersInTemplate | ForEach-Object { 
    New-Object PSObject -Property @{
        Name = $_.name.Substring(37, $_.name.Length-40)
        TriggerType = $_.Properties.type
    }
}
$triggersToReCreate = $triggersToStop | ForEach-Object {
    foreach($entry in $triggersNameAndTypeInTemplate.GetEnumerator()) {
        if (($entry.Name -eq $_.Name) -and ($_.TriggerType -ne $entry.TriggerType)) {
            Write-Host "reCreate target trigger name " $_.Name
            New-Object PSObject -Property @{
                Name = $_.Name
                TriggerType = $_.TriggerType
            }
        }
    }
}

② if ($predeployment -eq $true) {}のブロックの中の、$triggersToStop | ForEach-Object {}のブロックの次に以下を追加

    #Delete reCreate trigger
    Write-Host "Deleting triggers for reCreate"
    $triggersToReCreate | ForEach-Object { 
        Write-Host "Deleting trigger "  $_.Name
        $trig = Get-AzDataFactoryV2Trigger -name $_.Name -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName
        if ($trig.RuntimeState -eq "Started") {
            if ($_.TriggerType -eq "BlobEventsTrigger" -or $_.TriggerType -eq "CustomEventsTrigger") {
                Write-Host "Unsubscribing trigger" $_.Name "from events"
                $status = Remove-AzDataFactoryV2TriggerSubscription -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.Name
                while ($status.Status -ne "Disabled"){
                    Start-Sleep -s 15
                    $status = Get-AzDataFactoryV2TriggerSubscriptionStatus -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.Name
                }
            }
            Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.Name -Force 
        }
        Remove-AzDataFactoryV2Trigger -Name $_.Name -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Force 
    }

Azure Pipelineを使ったリリースの実施方法１

2021-12-04T14:24:27+09:00

Azure Pipeline使って別のDataFactoryへのリリースをやってみたので、備忘録。
記載するのはAzure Pipelineを使ったリリースまでで、トリガーの設定変更や、削除したリソースの反映までは行っていない

実行したのは下記なので、それぞれ手順を記載
・mainブランチに変更が入った場合にトリガー起動でリリース
・adf_publishへの発行をトリガーとしてリリース

◆前提
増分デプロイ

◆使ったDataFactory
開発ADF：作業用：DevOpsにコラボレーションブランチを作成済み
本番ADF：開発ADFのリリース先：ライブモード

◆前準備
１．開発ADFのコラボレーションブランチを作成しているプロジェクトにサービス接続を作成する
　プロジェクトは作成していたけど、サービス接続を作成してなかったからリリースを作成してもデプロイできなかった
https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/templates/deployment-tutorial-pipeline#create-a-devops-project
２．ブランチの役割を決めておく
　リリース先に反映するブランチを決めておく
　下記の構成で、mainブランチをデフォルトブランチにしてリリース設定をすると、workからのプルリクエストを許可した時点で本番ADFに反映される
　adf_publish：ライブモードの動作環境。mainブランチで発行することで、mainの内容が反映される
　mainブランチ：workの内容をプルリクエストでマージする先
　workブランチ：開発用

◆手順（mainブランチに変更が入った場合にトリガー起動でリリース）
１．ビルド用のパイプラインを作成する
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-improvements#create-an-azure-pipeline
　package.jsonの作成や場所は、リリース用のブランチのどこか
　公式のyamlの部分を作成環境に合わせて修正する
　$(Build.Repository.LocalPath)＝ブランチの/（ルート）に該当するので、ブランチの直下に格納する場合は記載不要
　ブランチの直下に「build」フォルダを作成した場合は、「build」と記載する。
　$(Build.Repository.LocalPath)はコンテナ内にチェックアウトされたリソースフォルダを指している

２．リリースを作成する
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-automate-azure-pipelines
上記の手順の「Azure Pipelines リリースをセットアップする」６．で、↑の１で作成したパイプラインを指定すると、トリガー起動するようになる（Source typeで「Build」を選択する）

「Azure Resource Manager connection」では、前準備で作成したサービス接続を選択する
前準備で作成したサービス接続を選択しないとサブスクリプションやリソースグループを選択できない

タスクを設定する際に選択するARMテンプレートは、リリースするブランチに格納してある、ARMTemplateForFactory.jsonと、ARMTemplateParametersForFactory.json
今回は開発ADF→本番ADFなので、「Override template parameters」でfactoryNameを上書きしている

３．保存して動作確認
問題なければ、デフォルトブランチに変更内容を反映することでリリースまで実行される

★注意点
１で作成したビルド用のパイプラインで出力されるARMテンプレートは、adf_publishに反映されない
なので、adf_publishに反映する場合は「発行」を押下する必要がある

◆手順（adf_publishへの発行をトリガーとしてリリース）
※「mainブランチに変更が入った場合にトリガー起動でリリース」１の手順は不要

１．リリースを作成する
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-automate-azure-pipelines
上記の手順の通りにSource typeで「Azure Repos Git」を選択する
Defult branchでadf_publishを選択する

２．トリガーを設定する
稲妻のアイコンを押下して、トリガーを設定する
今回はadf_pulishへの発行をトリガーにするので、Continuous deployment triggerを有効にして、Branchに「adf_publish」を選択する

３．リリースを作成する
「mainブランチに変更が入った場合にトリガー起動でリリース」２と同じ

４．保存して動作確認

Azure Synapse Analyticsの覚書（2021/9/5）

2021-09-05T22:38:06+09:00

Azure Synapse Analyticsについて、覚えたことを記載。

Synapse Analyticsのメモリについて
データウェアハウスの容量設定

上記にあるように、DWU毎にサービスレベルが決まっている。
「データウェアハウスあたりのメモリ」はディストリビューションの総メモリサイズとなっている。
200DWUであれば、データウェアハウスあたりのメモリは120GBとなっていて、「コンピューティングごとの配布」が60となっている。
「コンピューティングごとの配布」に記載されている値は、データウェアハウスのディストリビューション数。
そのため、1ディストリビューションあたりのメモリサイズは2GBとなる。

動的リソースクラス
動的リソースクラス

Synapse Analyticsでは、ユーザーに動的にメモリを割り当てることができる。
最初のユーザー（管理者ユーザー）はsmallrcから変更できないため、smallrc以外のリソースクラスを割り当てる場合は、専用のユーザーを作成する必要がある。
xlargercを割り当てると、メモリの70%をユーザーの処理に使用する。
これは、1ディストリビューションあたりのメモリの割り当てなので、上記の例にならって、200DWUであれば、xlargercを割り当てられたユーザーが使用可能な最大メモリは、2GB×70％＝1.4GBとなる。多分。
リソースクラスの割り当ては課金対象ではないので、DWUを上げる前にリソースクラスの見直しをして、使用可能なメモリサイズを調整してからDWUを上げてもいいかもしれない。

メモリの見積もり
メモリ要件の見積もり方法

テーブルにデータ移行を行う場合は、上記からメモリの見積もりを行ったほうがよい。
数百カラムのテーブルのデータ移行を行う場合、列圧縮に必要なメモリが足りなくて、データ移行時にエラーが発生する可能性がある。

select-insertするstored procedureを作成する場合はSSMSから実行する。
Synapse Analytics Studioのクエリエディタからだと、select-insertを含むstored procedureのcreateがエラーになった。
SSMSからだと問題なく作成できたし、動作した。
バグ？

📝 Azure Cosmos DB でソートしようとするとフリーズする

2021-07-06T00:47:48+09:00

MongoDB 用 API で Azure CosmosDB 向けの開発を行っていたのですが、sort 実行時にエラーが発生してしまいリソースが取得できなくなる問題が発生してしまいました。

結論から言ってしまうと、この Stack Overflow の回答通り対処すれば解決可能なのですが、簡易的に日本語でも解決策を記しておきます。

また、本記事内容の問題に遭遇したときに見つけたのですが、事前に Azure CosmosDB の Docker イメージを利用しておけば、CosmosDB 特有の挙動に気づけるようになるかもしれません。私は MongoDB の Docker イメージを利用して開発や動作検証を行っておりました。

公式サイトでの MongoDB 用 API でのインデックス管理についての記事を見ていくと下記の文言が出てきます。

クエリに並べ替えを適用するには、並べ替え操作で使用されるフィールドに対してインデックスを作成する必要があります。

そのため、例えば MongoDB の ORM である Mongoose の利用例でいうと、スキーマを定義する際に下記のようにソートに利用したいキーに対してインデックスを指定する必要があります。

@Schema({ timestamps: { createdAt: "created_at", updatedAt: "updated_at" } })
export class TestSchema1 extends Document {
  _id: string;

  // ソートしたいキーには index を付ける
  @Prop({ index: true })
  sort!: number;
}
const schema = SchemaFactory.createForClass(TestSchema1);
export const TestSchema1 = schema;

また、範囲検索を行いたい場合は各キーにインデックスを作成することで可能になります。

@Schema({ timestamps: { createdAt: "created_at", updatedAt: "updated_at" } })
export class TestSchema2 extends Document {
  _id: string;

  @Prop()
  start_at: Date;

  @Prop()
  end_at: Date;
}

// start_at と end_at で範囲検索を行いたいため、
// それぞれに unique インデックスを作成している
const schema = SchemaFactory.createForClass(TestSchema2)
  .index({ start_at: 1 }, { unique: true })
  .index({ end_at: 1 }, { unique: true });

export const TestSchema2 = schema;

地味な Tips のような記事ですが、割とハマりました。。この記事が同じ轍を踏んでしまっている方の参考になれれば幸いです 😇

Azure Administratorへの道（6回：AzureAD周辺）

2020-12-26T13:03:48+09:00

Qrunchからお引越しした記事です : created_at: 2019-09-02 21:16:06 +0900

知識が薄ぼんやりとしているAzureADのおさらい。

0. スキルの評価対応

アイデンティティの管理
　＞　Azure Active Directory (AD) を管理する
　＞　Azure AD オブジェクト (ユーザー、グループ、およびデバイス) の管理
　＞　ハイブリッドアイデンティティの実装と管理

1. AzureAD

・Office365やAzureの管理に利用する。
・カスタムドメインの登録が可能。
・AzureにはAADのユーザに対してRBACで権限を割り振る。
・ユーザの種類
　＞AADで作成したユーザ OR ドメコンから連携されたユーザ
　＞メンバー OR ゲスト
・ユーザの属性
　通常のドメコンと違うような属性は次の２つ。
　①利用場所
　　国を指定。これを指定しないとライセンス(Premiumライセンスなど)が割り振れない。
　②ユーザープリンシパルネーム
　　ユーザーのインターネット形式のログイン名
　　[email protected]みたいな形式
　　AzureやOffice365へログインする際のユーザ名の名前
・グループ
　動的にグループ割り当てができる
　→開発部所属のメンバーは開発部グループに自動所属のような感じか
　グループに有効期限を設け、破棄したりもできる
　グループの所有権があるユーザは、グループにユーザを追加できる。
・セルフパスワードリセット
　SMS、メール、秘密の質問、いずれかで変更。
・外部アクセス
　外部のメールアカウントを登録することで外部アクセスさせることが可能
・デバイス管理
　デバイスもAADに参加させ管理できる。
・アプリケーション
　3rd Partyのアプリとも統合できるケースがある。
　→Boxとか。
・条件付アクセス
　条件付アクセスポリシーにより設定。
　条件：ユーザ、グループ、デバイス、場所、などなど。
　制御：MFA、準拠デバイス指定、アプリ利用、利用規約を読ませる、などなど。
・アクセスレビュー
　現在のアクセス状況をレビュアが参照し、アクセス権を引き続き付与するか、
　破棄するか、などの判断・処理を実施できる。
・アイデンティティ保護（identiry Protection）
　脆弱性、リスクイベント、リスクを出しているユーザ、などが分かる。
　→Torブラウザで接近しているユーザは誰、MFAの設定をしない人がいる、とかが分かる。
　リスクイベントのレベルはポリシー（ユーザリスクポリシー、サインインリスクポリシー）で設定できる。
　→ポリシーに準拠しない場合はアクセスブロック、もできる。

2.ハイブリッドアイデンティティ

・オンプレミスドメコンとの同期。
・セットアップの流れ
★前提
　AzureAD：plazazurecontoso.onmicrosoft.com
　ドメコン：consoto.local
　→これをplazcontoso.comとして統一連携する。

　①AzureADの作成
　②AADでカスタムドメインの設定（plazcontoso.com）
　③ドメコンにUPN Suffix追加（plazcontoso.com）
　④同期対象ユーザのUPNを[user]@plazcontoso.comに変更
　　→powershellで一括変更
　⑤AzureADコネクトのデプロイ
　　→オンプレミス側にAADコネクト専用のドメコンを用意し、そこにデプロイする
　　　インターネットへ接続できる環境に存在する必要がある。
　⑥連携対象を指定（ドメインやOUなどで指定）
　⑦AzureADのごみ箱を有効にする

・ドメインフォレスト、AADコネクト、AzureAD
　①ドメインフォレスト：AADコネクト = N:1
　　複数フォレストの情報を１つのAADコネクトに集約はできる
　②AADコネクト：AzureAD = 1:1
　　AzureADとAADコネクトは1つに対して1つ
　　なので、もしAフォレストはAzureAD1、BフォレストはAzueAD2に連携、
　　という場合はAADコネクトは2台必要。
・AADコネクトの３つのSSO（シングルサインオン）認証
　①パスワードハッシュ同期
　　ドメコン→AADコネクト→AzureADの流れでハッシュ化したパスワードを連携し、
　　その内容を元にAzureADは認証を行う方式。
　　AzureADアカウントの有効期限は「無期限」になる。
　②パススルー認証
　　（流れ）
　　AzureADの認証情報をAADコネクトに暗号化して引き渡す
　　→AADコネクトは認証情報を解号してドメコンに引き渡す
　　→ドメコンは認証結果をAADコネクトに返す
　　→AADコネクトは認証結果をAzureADへ返す
　③フェデレーション認証
　　ドメコンに参加しているPCから、「追加の認証情報入力なし（シームレス）」で
　　AzureADの認証をする場合はコレ。（…くそダルイ構成だな）
　　【前提１】ADFSとWebアプリケーションプロキシ(WAP)が必要
　　【前提２】ドメコン⇔AzureAD間はAzureADコネクトでディレクトリを同期している

　　（流れ）
　　ユーザはドメイン参加PCからサービス（例：Office365）へ接近する。
　　→Office365はADFSに認証トークンを要求
　　→ドメイン参加PCはADFSから認証トークンを受領
　　→ドメイン参加PCはWAPを経由してAzureADへトークンを連携
　　→AzureADはトークンを受領し、Office365アクセストークンを発行
　　→ユーザはOffice365へアクセスできる
・パスワードライトバック
　AzureAD側でパスワードを変更した場合、それをドメコン側にも反映させる。
　通常、同期方向はドメコン→AzureADだが、この機能をオンにしていると
　パスワードの変更だけは双方同期になるような感じ。（かな？）
・同期間隔
　最短で30分間隔。間隔は変更可能。
・同期内容のフィルタ
　AD情報で何を同期するかをフィルタできる。
　勤務地は連携しない、とか。通常はデフォルト設定で十分らしい。

3.所感

・他にも色々あったけど、AZ-103の枠から外れるので飛ばした。
・「AzureAD」だけで覚えることありすぎでしょ…
　Azureの試験範囲にいれないでよ…
　（Azureと密接な関係にあるのは分かるけど）
・ハイブリッド連携はなんとなく理解していたけど、良いおさらいになりました。

Azure Administratorへの道（5回：Load Balancer）

2020-12-26T13:01:33+09:00

Qrunchからお引越しした記事です : created_at: 2019-09-02 21:16:06 +0900

ネットワーク周辺は業務でしっかりやったので概ね割愛。
ロードバランサだけ知識不足なため、そこだけは学習する。

0. スキルの評価対応

仮想ネットワークの構成と管理
　> Azure 負荷分散の実装

1. ロードバランサ（全体）

・Azureの負荷分散は大きく次の４つ
　①Public Load Balancer
　　OSI参照モデル4層（Tranceport層：TCP/UDP）の制御。
　　インターネットに接している。（パブリックIPアドレスが必要）
　②Internal Load Balancer
　　OSI参照モデル4層（Tranceport層：TCP/UDP）の制御。
　　VNet内の制御。⇒パブリックIPは不要。
　③Application Gateway
　　OSI参照モデル7層（Application層）の制御。
　　SSLオフロードやWAF（WebApplicationFirewall）の機能もある。
　④Traffic Manager
　　OSI参照モデル7層（Application層）の制御。
　　厳密にはロードバランサではない。
　　DNSレベルでの地理的負荷分散（?）を行う。

2. パブリックロードバランサ

・SKUはBasicとStandardの２種類 : 詳細
　⇒機能差、性能差の面でStandardにすることが望ましい。
・バックエンドプール
　ロードバランサにより負荷分散している同一構成のマシン達のことを指す。
・正常性プルーブ(Health Probe)
　負荷分散対象のマシンのうち、どれが正常でどれが死んでいるかを検査する方法。
　プルーブ（Probe）は「調べる、精査する」の意味なので、「健康診断」くらい雑に訳しておくと覚えやすい。
・SNAT（送信元NAT）
　SNATの機能を持つ。（中から外へのNAT）
　DNATとSNATがよくわからなくなるので以下まとめを記載しておく。（我ながらへっぽこ）

SNAT はプライベートアドレスから発生した通信をグローバルアドレスに届ける技術。
プライベートアドレス(S)をグローバルアドレスに書き換えて通信を実現している。
ホームネットワークから外部サービスへの通信等がこれ。

DNAT はグローバルアドレスから発生した通信をプライベートアドレスに届ける技術。
グローバルアドレス(D)をプライベートアドレスに書き換えて実現している。
ホームネットワークで web/mail 等のサーバ等を複数台構築してアドレスを一つに見せて外部に公開する場合がこれ。

　引用元サイト
　他参考サイト

　この機能があるので、Load BalancerのNAT規則を整理すればバックエンドにいる任意のVMにRDPで接近できる。
　（3389ポートで接近した場合はVM1、3390ポートで接近した場合はVM2、みたいな制御）
　受信NAT規則（Inbound Nat Rule）として構成する。

　ちなみに、VM自体にパブリックIPがひもづけられている場合、SNATはしない。
　→VMに付いているパブリックIPでの通信を優先する。

・分散モード
　①ハッシュベースの分散モード
　　５要素（送信元IP、送信元ポート、あて先IP、あて先ポート、プロトコル）を元に
　　ハッシュ値を作成する。そのハッシュ値を元にバックエンドのVMへ分散していく。
　　→なので、クライントPCの利用ポートが変わるとあて先VMが変わったりする。
　②ソース IP アフィニティモード
　　２要素（送信元IP、あて先IP）を元にハッシュ値を作成し、その値を元に分散する。
　　①と違って、クライアントPCのIPアドレスが変わらない限りあて先VMは変わらない。
　　→処理途中で通信先VMが変わると困るこまる場合はこっち。
　　　リモートデスクトップゲートウェイの構成に使うそうな。

3. インターナルロードバランサ

・VNet内の負荷分散に使う。FrontEndにPublicロードバランサを置いてWEBアクセスを負荷分散している裏で、
　WEBサーバ→複数DBサーバへのアクセス負荷分散を実施するのに使う、など。
・Vnet内で使う、パブリックIPアドレスがない、などを除いて、基本パブリックロードバランサとできることは同じ。

4. Application Gateway

・Web Traffic load Balancer。（なので、WEBアクセスのトラフィック制御での利用しかできない）
・URLベースのルーティングができる。
　→例えばURLが
　　①https:\//xxx/imagesの場合、画像を保管するWEBサーバへ転送
　　②https:\//xxx/videosの場合、動画を保管するWEBサーバへ転送。
　　という制御ができる。（すごい）
・SSLオフロードの機能。
　→SSL/TLSのエンコード、デコードをサーバから肩代わり。
・複数サイトのホスティングへも対応。
　→http:\//contoso.comはcontosoサーバプールへ転送、http:\//fabrikam.comはfabrikamサーバプールへ転送、など。
・WAF（Web Application Firewall）の役割ができる。
　→Webサーバへのアクセスにおいて不正な通信内容
　　（SQLインジェクション、クロスサイトスクリプティングなどの恐れがある通信）を遮断する。

5. Traffic Manager

・「DNS ベースのトラフィックロードバランサー」
　というのが、どういうことか全然分からなかったけどこの図を見てやっと分かった。
　①クライアントがDNSサーバに問い合わせる。
　②DNSサーバはTraffic Managerへ問い合わせる。
　③Traffic Managerは定められた分散規則にしたがって、いずれかのエンドポイントのパブリックIPを返す。
　④取得したIPアドレスで直接エンドポイントへ接近する。
・この手法をとることで、地理的負荷分散もできる。
　→例えば、東日本リージョン、西日本リージョンにそれぞれWEBサーバを配置した構成も実現できる。
・分散方法（ルーティング方法）は次の通り。
　①優先順位
　　基本、プライマリサイトへアクセスさせ、障害時だけセカンダリを使うときはコレ。
　②重み付け
　　均等に分散したりするときはコレ。例えば、本番環境A、本番環境B、トライアル環境Cがある場合。
　　A:50、B:50、C:1としたときはAかBにアクセスし、Cにはアクセスしない。Aが障害時はBにアクセスする。
　　Cのトライアルが終了し、一般公開するときはCも50にするだけでよい。
　③パフォーマンス
　　地理冗長しているような構成のとき、「ユーザから最も近いエンドポイント」を指定させるときはコレ。
　　この後の「地理的」とはちょっと違う。こちらはあくまで「ネットワーク待ち時間」が最も短いルートをいく。
　④Geographic(地理的)
　　DNS クエリの発信元の地理的な場所に基づいて分散させるときはコレ。
　　アメリカ本社はUSリージョン、日本支社は東日本リージョンへアクセス！という使い方かな。
　⑤複数値
　　エンドポイントがオンプレしかない(IPv4、v6のアドレス指定しかない)場合につかう。
　　この場合、正常なエンドポイントのアドレスを全て返答してくる。
　⑥サブネット
　　クライアントのIPレンジによってアクセス先を変更したい場合はコレ。
　　x.y.a.0/24はA環境、x.y.b.0/24はB環境へ行け、ということができる。
・Azure（IaaS、PaaS）以外にオンプレミスのエンドポイントも指定できる。
・Traffic Managerのネスト（入れ子）もできる。
　この場合エンドポイントにTraffic Managerを指定する。
　→複雑。
・イントラ内では使えないのではないか？

「Traffic Manager のしくみ」で説明したとおり、Traffic Manager エンドポイントとして、Azure の内部または外部でホストされているインターネット接続サービスを指定することができます。したがって、Traffic Manager は、インターネットに接続されている一連のエンドポイントにパブリックインターネットからのトラフィックをルーティングすることができます。エンドポイントがプライベートネットワーク内にある場合 (内部バージョンの Azure Load Balancer など)、またはユーザーが内部ネットワークから DNS 要求を行う場合、Traffic Manager をこのトラフックのルーティングに使用することはできません。　

引用元

6. 所感

・「軽くさらっておこう」くらいの気持ちで始めたら、大分奥が深い。
・ApplicationGatewayとTrafficManagerの概要が理解できたのは良かった。（何にも分かってなかった）

Azure Administratorへの道（4回：仮想マシン）

2020-12-26T12:59:58+09:00

Qrunchからお引越しした記事です : created_at: 2019-08-31 10:56:03 +0900

仮想マシン周りは概ね理解しているので、微妙に知識が足りないところだけ補足学習。

0. スキルの評価対応

仮想マシン（VM）のデプロイと管理

1. 仮想マシンの複数展開

1.1 イメージからの作成

イメージを作成するVMはSysprepを使う。
Linuxの場合waagent -deprovision+userでAzureのエージェントを初期化する。

1.2 ARMテンプレートでの展開

CopyオブジェクトやCopyIndexを利用するとよい。
複数の名前や値を生成できる。
例）次の場合、storage0、storage1、storage2の名前が生成される。
　名前
　"name": "[concat('storage', copyIndex())]",
　Copyオブジェクト
　　 "copy": { "name": "storagecopy", "count": 3 } 　
なお、ARMテンプレートの編集はVisual Studioで実施するとやりやすいらしい。

1.3 仮想マシンスケールセット

可用性セットとは別物。
この機能でVMを作成すると

すべての VM インスタンスが同一のベース OS イメージと構成から作成されます。
　というようにVMとして同一内容を保持した状態で自動スケールが実行できる。

基本、LoadBalancerを通してアクセスすることになる。
スケール方法は３つ
①手動
②スケジュール指定（スケールアウトするVM数も指定可能）
③メトリクス（CPU利用率など）の数値で自動スケールアウト

「え、すごい便利じゃん」と思ったが、下記情報あり。

※仮想マシン内にデータの保存はできますが、スケールインされるため、大切なデータは保存しない方が良いです。また、仮想マシン間でデータを共有する事もありません。

参考：https://www.cloudou.net/virtual-machine-scale-sets/vmss001/

…使えるケースが限られますね。（ログファイルとか消失するじゃん）
保存が必要なファイル（ログファイルなど）は別場所保管に設計すればいけるか。

2. 仮想マシン移行（オンプレミス to Azure）

2.1 Azure Site Rocovery

・実施前にDeploy Planner Toolを実行して情報収集をした方が良い。
　⇒ASR利用にあたるオンプレミスの情報がEXCELで出力される。
　　移行に必要な帯域幅や時間の情報を把握できる。
・構成サーバ、および移行元ホストはそれぞれHTTPSでAzureと通信し移行する。
　⇒443ポートで行うが、データ転送は9443ポートで行う。注意。
・Azure側ではリカバリーサービスコンテナ、ストレージアカウントが必要。

2.1.1 From Hyper-V

Hyper-VがSystem Center VMMで管理されている場合VMMが必要なケースあり。
移行元ホストにはAgentを導入する。
　

2.1.2 From Physical Server　

・構成サーバが必要。構成サーバがレプリケーション調整などを実施。
　⇒ちなみに構成サーバはSQL ServerでなくMySQLで稼動するらしい。
　⇒データ転送ポートを9443から変更することもできる模様。
・レプリケーション対象のサーバにはモビリティサービスエージェントを導入する。
・ASR自体はフェールバックも考慮したサービスだが、P2C移行になると
　フェールバックは難しい。物理サーバからの移行についてはP⇒Cへの一方向で考えたほうがよい。
　⇒ドキュメントを参照するかぎりできなくはないと思うが、あまり推奨しないということだろう。

2.1.3 From VMware

構成サーバーが必要。⇒OVFファイルがあるため、VMware上にデプロイするとよい。

2.2 Azure Migrate

・オンプレミスで稼働しているVMware上の仮想マシンを、Azureに移行した場合の
　「構成」や「費用」の確認ができるサービス（らしい）
・あくまでレポート情報を作成するだけであり、移行はASRで行う。
・VMware環境の情報収集に利用できる。（現在はHyper-Vも利用できる？）
　OVAファイル経由で収集用VMをデプロイし、収集結果をAzureへ送信し、その結果をレポートにまとめる、という流れか。
　（参考）https://www.cloudou.net/azure-migrate/mig001/

2.3 Data Migration Assistant

SQL Serverの移行などに利用。割愛。（おそらくAZ-103の範囲外）

2.4 ASRを利用しない移行

長期間のダウンタイムが許されるのであれば、下記方法もある。
①Hypre-VのVHDファイルをアップロードして使う
②Azure DataBoxでVHDファイルを移送して使う

3. カスタムスクリプト拡張、PowerShell DSC

Azureのカスタムスクリプト拡張機能と、DSCを使って、
デプロイした直後のVM 構成（エージェントやアプリ導入）を整理しましょう、という話のはず…（自信ない）

3.1 カスタムスクリプト拡張

・仮想マシンを作成したタイミングで、スクリプトを流せる機能。
・Win2008R2以上で利用可能。

3.2 PowerShell DSC拡張

・（Azureは直接関係ない）
・構成管理用の拡張機能。
・役割の有効化や環境変数の設定、ソフトウェアインストールなど構成に関することが色々できる。
・参考サイト：https://www.slideshare.net/kazukitakai/dsc-88799528

3.3 組み合わせてできること

・VMを作成した直後にウィルスソフトウェアインストール
・VM作成後のエージェント導入状態を同じくなるように管理
・その他いろいろ

4. 所感

・カスタムスクリプト拡張、PowerShell DSC あたりがPlurasightになかったので独学。
　⇒内容および範囲があっているのかどうか不安。
・ASRは業務で抑えていたのでおさらいレベル。
・スケールセットは可用性セットのことかな、と完全に勘違いをしていたので、把握できてよかった。

Azure Administratorへの道（３回：ストレージ関連）

2020-12-26T12:58:15+09:00

Qrunchからお引越しした記事です : created_at: 2019-08-24 15:55:30 +0900

備忘録的に覚えておきたい箇所を列挙メモ。

スキルの評価対応

ストレージの作成と管理

Azure バックアップの実装

・Recovery Service Vault ⇒　日本語だとリカバリーサービス「コンテナ」になる。
　（日本語もボルトに統一してくれよ…最初Valutって書かれていてピンとこなかったよ…）
・File単位のリストア
　⇒リストア結果をディスクとして一時マウントする仕組み。
・Azure Backup Agent（MARS：Microsoft Azure Recovery Services）
　オンプレ側のマシンに導入。ファイルなどのバックアップができる。
　こちらもリストア時は一時マウントになる。
・Azure Backup Server （MABS：Microsoft Azure Backup Server）
　MARSでカバーできない範囲をバックアップしたいときに導入が必要。
　マシン全体のバックアップやアプリケーションのバックアップなど。

ストレージアカウント

・レプリケーション
　LRS（ローカル冗長）、ZRS（ゾーン冗長）、GRS（地理冗長）に加えて、「RA-GRS」（読み取り可能な地理冗長）がある。
　GRSは通常、レプリケート先のサイトの情報はMSしかアクセスできない（MSが復旧処理するまで使えない）が、
　RA-GRSは平常時でもアクセス可能。
・アカウントの種類
　BLOB、Storage（V1）、StorageV2がある。
　①BLOB：BLOBしか使えない。
　②V1：ページ、キュー、テーブル、BLOB全部使える。クラシックのリソース管理用。
　③V2：ページ、キュー、テーブル、BLOB全部使える。リソースマネージャでの管理。
　通常、V2一択。
・アクセスキー
　このキーを渡すとストレージに対してフルアクセスできる。
　（何でもできるので取り扱い注意）
　キーの値はリフレッシュ（更新）でき、定期的な更新が推奨される。
・SAS：Shared Access Signature
　アクセスキーとは違い、アクセス内容を制限できるアクセス署名。
　読み取りのみ許可、アクセス元IPレンジの制限、プロトコルの制限、期間の制限、などなど。
・Stored Access Policy
　期間を決めてアクセス許可を設定できるポリシー。
　SASより大雑把なサービス（BLOB、キュー、テーブル、Files）レベルの制御。
・Azure Key Vault
　日本語だと「キーコンテナ」。
　色々なキーを管理するサービスだが、ストレージアカウントキーの自動管理もやろうと思えばできるらしい。
・AzureAD&RBACを利用したアクセス制御
　BLOBとキューのみ制御可能。
　AureAppServiceからストレージコンテナへのログファイル書き出し、などに有効。
　IAM制御にてAppServiceに対して必要なロールを割り当ててやればいい。
　（IAM制御でユーザだけでなくAppにも権限を割り当てできるのは初耳だった）
・暗号化
　デフォルトでMSのキーによって暗号化されている。
　独自のキーで暗号化することも可能。その場合、暗号化のキーをAzure Key Vaultで管理する必要がある。
・ネットワークアクセス
　デフォルトでインターネット上のどこからでも接近できる。
　設定変更によりアクセス可能なバプリックIPを指定したり、VNet内からアクセス可能にできる。
　⇒Vnet側のほうにもサービスエンドポイントの設定が必要。
・StorageExplorer
　ストレージの中身を参照するツール。Desktop版とWeb版があり、Web版はPortalから使える。
・診断ログ
　診断設定をオンにしている場合は「$logs」というBLOBコンテナにログが格納される。
　StorageExplorerでファイルを取得できるらしい（が、WEB版のStorageExplorerで参照しても該当コンテナが無かった）
　取得したログはMicrosoft Message Analyzerで解析すると見やすい。
・メトリック
　メトリックも診断設定をオンにしているとテーブルに出力される模様。
　メトリック情報からアラートを作成したりできる。

BLOB Storage

・ストレージアカウントのうち、「BLOB」に該当する箇所の補足追記。
・BLOBの形式は３種類。
　①Block Blob
　　複数ブロックに分けられたBLOB。ファイル追加、削除など普通に使う場合はこれ。4.7TBまで。
　②Append Blob
　　追加のみのBLOB。ログ保管など、ファイルの変更や削除をしない場合に使う。
　③Page Blob
　　VMのディスク（VHD）を置く。最大8TBまで。
・ストレージ層
　StorageV2のアカウントでのみサポート。次の３種類。
　①ホット：データ保存のコストが高く、データアクセスのコストが低い（頻繁に更新する場合に推奨）
　②クール：データ保存のコストが低く、データアクセスのコストが高い（保管メインの場合に推奨）
　③アーカイブ：最もデータ保存のコストが低いが、データ取り出しに数時間単位でかかる（長期保管用）
　※注意：ストレージ層を変更（移動）するとその移動量に対して課金される。（データアクセス分の課金がかかる）
　既定でホットにするかクールにするかをストレージアカウントで設定できる。
・コンテナ
　BLOBサービス内に無制限に作成できる。
　外部からのアクセスレベルを設定できる。
　①Private Access Level（デフォルト）
　　認証が必要。匿名アクセス不可。
　②Blob Access Level
　　BLOBへ読み取りアクセスはできるが、コンテナの内容をリスト化して閲覧することはできない。
　　⇒URLを知っている特定ファイルにしかアクセスできない
　③Container Access Level
　　指定のコンテナの内容をリスト化して閲覧できる。
・コンテナには不変ストレージの設定ができる。(WORM：Write Once Read Many　ともいう）
　この設定をするとアップロードしたデータの更新・削除ができない。
　⇒更新してはならないケース（金融、医療、法律、保険分野など）で利用する。
　一定期間は削除不可、またはホールド（Legal Hold）解除するまでは削除不可のどちらかを指定できる。
・Lifecycle Management
　ファイルのライフサイクルを指定できる。
　N日経過後にクール層へ移動、M日経過後にアーカイブ層へ移動、X日経過後に削除、のような指定ができる。
　⇒削除のポリシーはBLOBスナップショットごと削除してくれる。
・静的Webサイトホスティング
　有効にし、HTMLやCSS、Javascript、画像ファイルなどをアップロードするとWEBサイトとして使える。
　カスタムドメインの設定も可能。
・AzCopy
　BLOBにファイルをアップロードするコマンドラインツール。バッチ処理向き。
　どことなくrobocopyチック。指定オプションも沢山ある。
・ストレージ操作の.NETのライブラリもあるため、PGに組み込みで使える。
・Azure Search
　Azure Searchでストレージ内検索ができる。
　Azure Search自体はAzureのクラウド検索システム。
　前文検索的な動きをして、呼び出しもとに結果を返してくれる。
　プログラムに組み込んで使う。コグニティブのオプションで画像内検索とかもできるらしい。
　BLOB内のファイルにメタデータをつけていればメタデータでの検索も可能。

Azure CDN

・ユーザにコンテンツを分散して配信するサービス。（書いててもよく分からない…）
・BLOBストレージに置いて展開したいファイルへのアクセスについて、
　ユーザは世界中に存在するエッジサーバからファイルを取得できるようになる。
・なので「ゲームの新作トレーラーを0時に世界同時公開！」とかそういう時に利用することで、
　ユーザがすばやくアクセスできたり、中央サーバへの負荷やトラフィックが抑えられる、という感じか。
　（現状、業務で使うことはなさそうだな…）
・製品（価格帯）が４つある。
　Azure CDN Standard from Microsoft
　Azure CDN Standard from Akamai
　Azure CDN Standard from Verizon
　Azure CDN Premium from Verizon
・プロファイルを作成し、ストレージアカウントに割り当てる。
　その際にエンドポイント名称（グローバルで一意）を決める。
・CDNには次のURLでアクセスする。
　http://(EndpointName).azureedge.net/(myPublicContainer)/(BlobName)
・基本、CDNを使うときBLOBストレージのアクセスレベルはBLOBかContainer（外部アクセス可）である。
　これをPrivateのままにしたい場合はSASトークンを利用してアクセスする。
　この場合、URLの後ろにSASトークンを付与する。
・「URLの後ろにSASトークンつけると結局SASトークンが公開されていることになる！困る！」と言うときは
　「Premium from Verizon」であればURL書き換え機能で対応できる。
　これで、指定のURLにアクセスした際に自動でURL末尾にSASトークンを付与するようにできる。
・利用の際、CORS（クロスオリジンリソース共有）を考慮する必要があるらしい。（何だそれは…）
　通常下記の通りらしい。

クロスサイトスクリプティング攻撃の可能性を低減させるために、すべての最新の Web ブラウザーには
同一オリジンポリシーと呼ばれるセキュリティ制限が実装されています。
これにより、Web ページは他のドメイン内の API を呼び出すことができません。

　これをなんとかするための話らしい。

CORS (クロスオリジンリソース共有) は、あるドメインで実行されている Web アプリケーションが
別のドメイン内にあるリソースにアクセスできるようにする HTTP 機能です。

　CSNのCORSの欄で設定可能。

Azure Files

・ストレージアカウントのうち、「File」に該当する箇所の補足追記。
・SMBプロトコルを介してアクセスできるのがBLOBとの最大の違い。
　⇒ファイル共有をクライアントPCでマウントできる。
・ファイル共有で利用する場合、SMB（2.1 or 3.0）でやりとりする。3.0は通信が暗号化されている。
・クライアントが445ポート(SMB)が空いていてインターネットと疎通できないと使えない。
　⇒REST API経由でやりとりする分にはHTTPS(443)で通信できればよい。
　　なのでPowershell経由やCLI経由であれば443でいける。
・クライアントのOSがSMB3.0をサポートしていないと使えない。（Win8.1以降）
　⇒ストレージアカウントと同一リージョン内のAzure VMならWin2008R2でも接近できる模様。
　　（おそらく：同一リージョン内の通信はイントラ扱いになっているから○という感じか）
・AzureAD認証をサポート。
　…しているが、アクセスするにはクライアントマシンがAzureAD DomainService（AADDS）に参加している必要がある。
　また、ADDSドメイン（オンプレやVMのドメコン）に参加しているマシンはAADDSに参加できないため使えない。
　AADDSに参加できるのはAzureのマシンなので、オンプレにいるクライアントPCでも使えない。（使える範囲が狭すぎるよ…）
　⇒後述のAzure File Syncを使え、とのこと。
　⇒また、完全な管理者権限が必要な場合はアクセスキーでアクセスする。（AADDSで管理者権限を割り振っても完全でない）
・ファイル共有の最大割り当てサイズは5TBまで。（ストレージアカウント全体では500TB）
　最大ファイルサイズは1TB。
・スナップショットバックアップの取得が可能。
　取得している場合、ファイル共有でファイルのプロパティ「以前のバージョン」より過去ファイルの閲覧・取得が可能。
・AzureBackupを利用した定期的なスナップショット取得もできる。
　⇒1日1個までらしい。

Azure File Sync

・以下、参考サイト。
　https://cloud.nissho-ele.co.jp/blog/azure-file-sharing/
・Azure Filesとファイルサーバの内容を同期するサービス。
　ファイルサーバは複数台立てることができるため、複数のファイルサーバがAzure Filesを通してファイル内容を同期することができる。
・ファイルサーバを「サーバエンドポイント」、Azure Fileを「クラウドエンドポイント」と呼ぶ。
　１つの同期グループにおいて、クラウンドエンドポイントとサーバエンドポイントは1:Nの関係。
・Azure FilesのバックアップがAzureBackupでできるため、それをもってファイルバックアップとすることができる。
・障害発生時もAzure Filesからファイル復旧できる。
・実ファイルはFilesに保持させ、ファイルサーバ上ではポインタ（ショートカットのようなもの）のみ配置することもできる。
　これをすることによりファイルサーバのディスク容量を節約できる。
・ファイルサーバにエージェントを導入する必要がある。
・Azure File Syncはストレージアカウントと同一リージョンにデプロイする必要がある。
・同期で帯域を食う場合にはQoSをかけられる。（powershell経由）
・ファイルサーバはAzure Filesのファイル共有の要件（SMBのバージョン、ポート445解放）を満たす必要がある。
・ファイルサーバ側にファイルを置くと速やかにAzure Filesに連携される。
　が、Azure Filesに直接ファイルを置くとファイルサーバへの連携に1日かかることもある。（らしい）
・DFS名前空間と組み合わせて使うことができる。

インポートジョブ

・HDDの内容をBLOBコンテナに移動することができる。
・最初に、対象HDDをNTFSフォーマットした後、BitLockerで暗号化する。
・その後、waimportexportツールを使用し、インポート準備ファイル(jrnファイル)を作成する。
　⇒V1とV2がある。ストレージアカウントがStorageV1、V2の時はV2ツール、BLOBストレージの時はV1を使う。
　⇒V2では定義（対象ファイルやドライブ情報）などをCSVに記載して管理する。
　　Dataset用CSVに対象ファイルを列挙すれば、自動で対象HDDにファイルを収集してくれる。
・その後、AzurePortalからインポートジョブを作成。
　この際、作成したjrnファイルやインポート先のストレージアカウントを指定する。また、配送に関する情報もあわせて入力する。
・ジョブ作成後、ディスクを指定の住所に発送する。だいたいMSの準備が済むまで7～10日くらいかかる。（SLAはない）
　⇒すぐインポートしなければならない、という要件がある場合はマッチしない。
・発送後、追跡情報の更新（おそらく発送連絡）をする必要がある。
　これを2週間以内に実施しないと自動的にジョブがキャンセルになってしまう。
・到着後、自動的にストレージアカウント内にファイルが追加されている。

エクスポートジョブ

・Azureストレージの内容をHDDに移すことができる。
・まず、エクスポートジョブを作成する。（配送会社や住所の設定、対象ストレージアカウントの設定）
・NTFSフォーマットしたHDDを発送。
　⇒返送時はBitLockerで暗号化された状態で帰ってくる。
・インポートと同様に配送状況の更新は必須。
・届いたディスクを接続し、BitLockerのキーを入力しデータにアクセスできることを確認。

Azure Data Box

・こちらはAzure側でデータ格納デバイスを用意してくれるデータインポートサービス。
・注文⇒デバイスが届く⇒データを入れる⇒返送⇒データが反映される

所感

・全然業務で使わないような箇所も勉強できて、いい機会にはなった。
・ストレージアカウント周辺は「なんとなく」から「ややしっかり」の理解になった。よかった。
・インポート、エクスポート、DataBoxは仕組みを把握しておくと将来役に立つ日がくるかもしれない。
・Filesは便利だけど使う日がくるかな…
・CDNはたぶう使う日はこない。（転職か異動がないかぎり）

Azure Administratorへの道（２回：Azure MFA）

2020-12-26T12:56:04+09:00

Qrunchからお引越しした記事です : created_at: 2019-07-13 16:30:22 +0900

スキルの評価対応

アイデンティティの管理
　> Multi-Factor Authentication (MFA) の実装

MFAとは

Multi-Factor Authentication
多要素認証のこと。

「アカウント + パスワード」より強固なセキュリティを担保しないといけない時に使う。

適用範囲

AzureのSaaS
AzureのPaaS
AzureのIaaS上に構築したアプリケーション
Azureとつながっているオンプレミス上のアプリケーション
Office 365

などなど

認証方法

電話
電話がかかってくるので、それに出て「#」をプッシュ。
PINの入力を要求するモードもあり。
SMS
1Way：SMSで通知したパスワードを画面に入力。
2Way：SMSでパスワードが通知されるので、同じ番号をSMSで返答する。
どちらもPINコードの追記を要求するモードあり。
アプリ認証
MSのアプリを起動して、アプリから認証する。
PINコードの追記を要求するモードあり。
OATH
MSのアプリから発行されるセキュリティトークン（6桁数字）を求められる。
MSのアプリでないOATHトークンアプリ（Googleのやつとか）でも利用できる。

認証情報の保管

Azure Active Directoryに保管。なのでAADがある環境が前提。

MFA Server

・認証方法によっては必要。
・オンプレミス上のアプリからMFAを利用する際に必要？
・オンプレミス上のサーバに構築する。
・オンプレミスのADやLDAPなどとユーザ情報を同期できる。
　AzureMFA⇔MFA Server⇔オンプレのドメコン
・複数台構築し、内容を同期することが可能。
　⇒冗長性担保。
・ドメコンにインストールするのは不可。

所感、感想

・多要素認証。7 Payの事件で一躍有名になったね。
・今の仕事だと使わなそうだなー。
・銀行系（ネットバンキング）とかだと必須ですね。

Azure Administratorへの道（１回：Azure Policy）

2020-12-26T12:53:17+09:00

Qrunchからお引越しした記事です : created_at: 2019-07-03 22:35:48 +0900

スキルの評価対応

Azure サブスクリプションおよびリソースを管理する。
タグでできることはなんとなくわかるので、使ったことの無いAzure Policyを勉強。

Azure Policyとは

・Azureの利用者にできることを制限する統制の仕組み。
・RBACによる権限制御はあくまでリソースへのアクセスレベルの話だが、Policyはもっと細かい制御ができる。
　⇒たとえば、「タグ付けのルール」、「LinuxのVMはデプロイさせない」、「Win2008R2は使わせない」などなど。
・制御する以外にも、ルールが守られているかのチェックにも使える。
　⇒「ルール」に大して「守られているかチェックする」、「ルールを強制する」などのレベルが選べる。

定義と割り当て

・イニシアチブ定義とポリシー定義がある。
・ポリシー定義は１つのルール。イニシアチブ定義はポリシー定義を束ねたもの。グループみたいなものか。
・割り当てのスコープも指定できる。
　⇒リソースグループ単位や、サブスクリプション単位、管理グループ（サブスクリプションの集まり）単位、など。
・割り当てたスコープについて、ある特定リソースやリソースグループは除外することができる。

ポリシーの作り方

・デフォルトで使えるビルトインの定義がある。
・ビルトインの定義でやりたいことができない場合は自分で定義を作成する。
・定義はJSON形式で記述。
・GitHubに色々ポリシーが公開されている。
・定めたルールが守られない場合に実施される効果を次の中から選べる。

Deny はアクティビティログでイベントを生成し、要求は失敗します
Audit: アクティビティログ内に警告イベントを生成しますが、要求は失敗しません。
append は定義済みのフィールドセットを要求に追加します。
AuditIfNotExists: リソースが存在しない場合に監査を有効にします。
DeployIfNotExists: リソースが存在しない場合にリソースをデプロイします。
Disabled: リソースがポリシー規則に準拠しているかどうかを評価しません。

引用元

実践

デプロイしたリソースにタグ付けをするPolicyを作ってみる。

・ビルトインポリシー「タグとその既定値の追加」の割り当てを実行。
　リソースグループに対して割り当て。
・タグ「env:test」を付与するように設定。
・VNetをデプロイ。
・デプロイされたVNetにタグ「env:test」が付与されていることを確認。

所感

・タグの強制は便利。タグでのコスト管理を実施する際に活かしたい。
・大きい組織でAzureの利用者が沢山いるときにはとても有用そうな機能。

Azure Administratorへの道（０回：受験申し込み）

2020-12-26T12:52:04+09:00

Qrunchからお引越しした記事です : created_at: 2019-06-27 22:52:22 +0900

経緯

遠まわしにAzureの資格を取るように上司に言われたので頑張って取る。

取得する資格の選定

とりあえず基礎知識はある（はず）なので、Azure Administratorの取得を目指す。
AZ-103

参考にした情報

こちらの方のSlideshare
https://www.slideshare.net/AkiraMidouchi/azure-142750519

申し込み

Microsoftの資格試験初申し込み。

ExamReplayという落ちても１回だけ再受験できる制度があるらしい。
mindhubでバウチャーを購入し、そのコードで申し込み。
⇒最初良く制度が分からなく、バウチャーなしで申し込みしてしまった。
　１回で受かる自身がないので、キャンセルしてバウチャー購入⇒再申し込みした。

今後の勉強方針

Pluralsightでスキルチェック⇒動画視聴⇒再スキルチェック
azure環境で実際に操作してみる
Qrunchで学習内容をまとめる。（アウトプット）

所感（と言う名の愚痴）

・Azureの試験は頻繁に更新されていて、正直あまり取る気がしない…
　⇒取得してもまた資格体系が更新されたりするのでは
・9月までに合格するように目標をたてたが、正直受かる気がしない。がんばろ。
・ベンダ資格は費用が高いなぁ…自腹はきつい。

AzureFirewall [SNI TLS extension was missing]の理由

2020-12-26T12:13:58+09:00

前提

この記事は2019/6/4時点の内容です。（かつ、Qrunchからの移管記事です）
筆者の知識不足が著しいため、内容に誤り等ありましたらコメント欄にて指摘お願いします。

記事の目的

AzureFirewallのログを参照して
「[SNI TLS extension was missing]のメッセージとともに通信が拒否されている！
だけど何のことだかよくわからない！」という感じになっている人向けの内容です。
「メッセージの通りじゃん」となる有知識者はお帰りください。

結論

AzureFirewallを介するTLSで暗号された通信については、
Client Hello時にTLS拡張「server_name」が存在しない場合、通信が許可されない。
これはAzureFirewallの意図的な動作であり、仕様である。

経緯

Azure上のVMにソフトウェアをインストールし、そのソフトウェアのライセンス認証を
オンラインで実施しようとしたところ失敗した。
↓
VMがインターネットへでる際は
「VM⇒AzureFirewall⇒インターネット」の経路を通るため、AzureFirewallのログを確認。
↓
ライセンスサーバとの通信が拒否されたログを確認。
そこに[SNI TLS extension was missing]のメッセージが出力されているが、よくわからない。
（意味もよく分からないし、何で出ているのかもよく分からない）
↓
問い合わせした結果、上述の通り仕様であることが判明。
解決策としては「ライセンス認証に関するクライアント⇔サーバ間の通信内容の設定を変える」か、
「AzureFirewallを介さないで通信する」かのどちらかになる、とのこと。

ソフトウェアのサポートと話をしたところ、
「IPアドレス単位でFirewallの許可設定をしても同事象が発生するか確認してほしい」
といわれたのでNetworkRuleコレクションのほうで認証サーバのIPアドレスを許可したところ、
事象が解消しました。
（ApplicationRuleのみ発生する事象なのだろうか）

SNI、TLS拡張「server_name」とは

SNI（Server Name Indication）
1つのグローバルIPアドレスで、複数の証明書を利用できるようにする仕組み。
server_name
SNIを実現するためにのTLS拡張。
TLS通信を行う際のクライアント⇔サーバ間の手続き（TLSハンドシェイク）において、
最初にクライアント⇒サーバへ「Client Hello」の要求をした際、クライアントが希望するドメイン名を平文で伝える。
それによってサーバがドメインに対応する証明書を使えるようになる。
今回AzureFirewallは、クライアントからのリクエストについて、宛先ドメイン名をTLS拡張「server_name」で指定していない場合、その通信はAzureFirewallで破棄します、と言っているわけですね。
詳細はWikipedia参照
https://ja.wikipedia.org/wiki/Server_Name_Indication

所感

そもそもSSL/TLS周りの知識が無さすぎて、何のことだか全然分からなかった。
問い合わせまでしてしまった。
知識がある人ならログを見ただけで「そういうことね」となる事象なのでしょう・・・
勉強が足りないなぁ・・・

Azure プライベートエンドポイント

2020-11-22T15:15:09+09:00

プライベートエンドポイント

プライベートエンドポイントは、作成した仮想ネットワーク内のプライベートDNSゾーンと統合可能な、プライベートIPアドレス。
作成すると、対象仮想ネットワークのアドレス範囲内でIPアドレスが付与され、対象仮想ネットワーク内のリソースは、プライベートエンドポイントが指すリソースへ、DNS名で接続が可能となる。
サービスエンドポイントの場合は許可されたサブネット範囲となっていたが、プライベートエンドポイントはNSGなどの設定も無視して、対象仮想ネットワーク内全般からアクセスが可能。

以下のような構成を考える。

仮想ネットワーク：vnet-main
- サブネット：subnet-001
  - 仮想マシン：vm-001
  - NIC：nic-001
  - NSG：nsg-001 ※storage-Aへのアウトバウンドを拒否
- サブネット：subnet-002
  - 仮想マシン：vm-002
  - NIC：nic-002
  - NSG：nsg-002
ストレージアカウント：storage-A

storage-Aのプライベートエンドポイントをvnet-mainに作成すると、vm-001、vm-002はstorage-Aにアクセスができる。
vm-001はNSGで拒否となっているが、プライベートエンドポイントでは無効となる。
プライベートエンドポイントを設定したリソースがパブリックアクセスを拒否するかは、そのリソースの接続しだいとなる点はサービスエンドポイントと同じ。

サービスエンドポイントとの違いは、対象の仮想ネットワーク内のリソースに対してアクセス制御を行えない点。

不明点

上記のvnet-mainの他に、仮想ネットワークvnet-subが存在し、storage-Aがパブリックアクセスを拒否していた場合、vnet-sub内のリソースがstorage-Aにアクセスするためには、vnet-sub内にもプライベートエンドポイントを作成する必要があるのか？もしくは、プライベートリンクサービスを使用するのか？

「Azure プライベートエンドポイントとは」
https://docs.microsoft.com/ja-jp/azure/private-link/private-endpoint-overview

プライベートエンドポイントの利点と使いどころがいまいち...。オンプレとの接続か、プライベートリンクサービスを使うとき以外はあまり使わないものなのか？

Azure サービスエンドポイント

2020-11-22T14:50:02+09:00

サービスエンドポイント

サービスエンドポイントは、ストレージアカウント、SQL Databaseなどのサービスに対して、接続を制限するための機能。
サブネットに統合される。
サービスタグ（Microsoft.SQLなど）があらかじめ設定されていて、サブネットやネットワークインターフェースに対して設定が可能。

以下のような環境を考える。

仮想ネットワーク：vnet-main
- サブネット001：subnet-001
  - 仮想マシン：vm-001
  - NIC：nic-001
  - NSG：nsg-001
- サブネット002：subnet-002
  - 仮想マシン：vm-002
  - NIC：nic-002
  - NSG：nsg-002
- サブネット003：subnet-003
  - 仮想マシン：vm-003
  - NIC：nic-003
  - NSG：nsg-003
ストレージアカウント：storage-A

subnet-001、subnet--002のサービスエンドポイントに「Microsoft.Storage」と設定する。

　1. storage-Aが何も接続設定をしていない場合
　　仮想マシンvm-001、vm-002、vm-003はstorage-Aに接続できる
　　ストレージアカウントは基本的に仮想ネットワーク内、およびインターネットからのアクセスを拒否しないため
　　このとき、vm-001とvm-002はプライベートアクセス、vm-003はパブリックアクセスとなっている

　2. storage-Aがsubnet-002にのみ接続可にしていた場合
　　仮想マシンvm-001、vm-003は接続できず、vm-002は接続ができる
　　vm-001はstorage-Aの接続設定で接続が拒否される
　　vm-003はサービスタグが設定されていないため、パブリックアクセスを行おうとして拒否される

サービスエンドポイントを使用した接続は、プライベートIPを使用したプライベートアクセスとなる。
対象の仮想ネットワーク内のアドレス範囲で決定されたプライベートIPアドレスを使用して接続が行われる。
それ以外のアクセスはパブリックアクセスとなる。

サービスエンドポイントの利点としては以下。

インターネットや関係のないサブネット内のリソースからのアクセスを制御できる
プライベート接続になるので、セキュリティ面で安全

「仮想ネットワークサービスエンドポイント」
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-service-endpoints-overview

Power BI初心者にお役たちリンク集

2019-07-26T23:48:54+09:00

PowerBI Desktopのダウンロードはこちら
Power BI Desktop

様々なサンプルデータ
Power BIのサンプルデータ

Microsoft Power BI のガイド付き学習
ガイド付き学習

カスタムビジュアル
Microsoftが製作した既定以外のビジュアルがダウンロードできます
Power BI カスタムビジュアル

レポートサンプル
Themes Gallery

PowerBI Community
Power Bi Community

VPNデモ用環境構成概要

2019-07-18T06:23:05+09:00

VPNデモ用環境構成概要

クラウドとの接続形態の比較

2019-06-04T10:29:16+09:00

クラウドとの接続形態はインターネットVPNを使う方法と閉域網を使う方法があります。

接続形態	インターネットVPN		閉域接続
セキュリティー	暗号化技術により実現	○	インターネットを経由しない	◎
信頼性	アクセス回線やISP網の信頼	△	閉域網で直接接続するため、比較的信頼性は高い	◎
品質	遅延や揺らぎがある　帯域は保証されていない	〇	遅延や揺らぎが少ない　パケット損失が少ない　帯域が安定している	◎
コスト	安価	◎	比較的高価であるが、	△