CentOSからAzureをREST-APIで操作したい
最近ARM templateの記事ばかりですので、たまには少し違う目線で記事を書いてみます。
Azure Portalをご利用されている方は多いと思いますが、Linuxな人は基本的にCUIから全て操作したい（古臭いですかね）、という方が多いと思います。かくいう私もその一人ではありますが、Azureを操作する上でCUIから全ての操作をするのは意外に大変な部分もあります。
そんな多くの方が最初にアプローチするのはAzure CLIでしょうかね。そのAzure CLIでは最初に認証の設定をします。「azure login」から認証する際に必要なコード（ランダムな文字列）とURLが表示されますので、そのURLをブラウザで開き、アカウントとパスワードでログインした後このコードを入力して認証します。
プロンプトが返ってきますので、その後「azure account list」から、Subscription idを表示させ、最後に「azure account set <subscription id>」とすることで、次回からOSへログインすると自動的にこれが設定された状態でログインすることができます。つまりログイン後すぐにazureコマンドが打てるようになります。
（これはARMのモードでの話です。「azure config mode arm」）
※見るとわかりますがホームディレクトリ配下に「.azure」という隠しディレクトリ
が作成されており、暗号化して記憶されています。
こうやってAzure CLIを触っていくわけですが、利用したいサービスや機能が全て揃っているわけではないため、歯がゆい気持ちになる時もあります。
利用できるサービスのカバレッジで言えば（C#やPowershellを除いて）SDK Javaをダウンロードしてきてライブラリからメソッドを呼んで操作する、ということもできますが、もっと単純にHTTP(S)リクエストを投げて操作できないものか、と思います。
ということで、今回の記事は「だったらAzureのREST-APIをcurlで直接叩けないんかな」ということを少し紹介します。
まず押さえておくサイトとしてはAzureのAPI referenceです。
https://docs.microsoft.com/en-us/rest/api/index
左ペインに各サービス毎にアクセスするためのHTTP request/header/bodyの仕様が記載されています。
ただし全てに共有して必要なものがあり、それがAPI認証です。HTTPリクエストの実態を見るとこんなリクエストをかけているようです。
GET /subscriptions?api-version=2014-04-01-preview HTTP/1.1
Authorization: Bearer <bearer-token>
Host: management.azure.com<body>
既にAWSのAPIを利用したことがある方はピンとくると思いますが、間違いなく「Authorization: Bearer <bearer-token>」 という行の<bearer-token>にしか目にいかないですよね、ワクワク（笑）
はい、ご察しの通りAWSで言うところの以下の行に当てはまります。予想通り、「直接実装するとあのクソだるいやつかー」です。
「Authorization: AWS AWSAccessKeyId:Signature」
※もちろん言語で隠蔽されたcredentialライブラリでしか組み立てたことがない方は
このダルさは共有できないので、スルーしてください。
AWSではDIGEST認証と呼ばれる認証方式を採用されていますが、AzureではBearerトークンを採用しています。これはOauth 2.0の認証機構に準じているようです。（RFC6750）
なぜOauth 2.0なのか。Microsoftの認証基盤はActive Directoryなのは有名な話ですね。そしてAzure Active Directory(AAD)はOpenID Connect 以外にもOauth 2.0の業界標準プロトコルにも対応しているから、でしょうか。
ということは、Oauth 2.0の通信に必要なトークンを生成するためには、AADからキー情報をもってこないといけないんだろうな、という想像がつきます。はい、Active Directoryという言葉を聞いただけで脳内がフリーズするLinuxな人は多いと思いますが、最初少しだけ我慢しましょうか。
では、早速AADでキー情報を持ってくるための設定をAzure Portalでやってみましょう。
左側のアイコンでAzure Active Directoryをクリックし、「アプリの登録」から「追加」でアプリを登録します。
アプリ名はなんでもよいです。WEBアプリ/APIを選択し、サインオンURLもhttp://localhostと適当に入れておきましょう。
作成したアプリの表示名（アプリ名）とアプリケーションIDをどこかにメモしておきましょう。後で使います。（画面の赤丸でかこった部分）
次に作成したアプリの「キー」から、適当な名前のキー名と有効期限を設定します。1年か2年か無期限っとオトコな設定ですがとりあえず無期限で。
保存するとキーIDが表示されますので、それを同じくメモっておきます。
ちなみにキーIDは保存した時に出力されるだけで、以降は取得できなくなる機密性の高いモノになりますので、ここで確実にメモっておく必要がありそうです。
最後にAADのディレクトリIDを持ってきます。
このディレクトリID（テナントIDとも呼ばれている！？）もメモっておきます。
ここまでがAADの操作です。
次に先ほど作成したAADのアプリを、どこかのリソースに権限を付与して紐づけなければいけません。ここではリソースグループに紐づけてみます。（単一ＶＭにも紐づけ可能です）
適用したいリソースグループから 「アクセス制御IAM｝を選び「追加」から、どの役割（ロールですよね）を追加するかを選びます。いろんなAPIを触りたいので共同作成者にしておきましょう。（VMの操作だけなら、仮想マシン作成協力者がよいと思います）
次は「ユーザーの追加」にて先ほどAADに作ったアプリ名を検索して選択しましょう。最後にＯＫボタンをクリックしてポータルからの操作は終わりです。
以下のcrulコマンドを打ちましょう。
★印に先ほどメモったものをあてはめます。全て1行です。
curl -X POST -H "Content-Type: application/x-www-form-urlencoded"
-d "grant_type=client_credentials"
-d "resource=https://management.azure.com/"
-d "client_id=★メモったアプリケーションID★"
--data-urlencode "client_secret=★アプリケーションのキーID★" https
://login.windows.net/★ディレクトリID★/oauth2/token?api-version=1.0
実行するとaccess_token（こいつがbearer token）が手に入ります。
とても長いトークンですが、最後にこれをメモっておきます。
では簡単な例として、冒頭で紹介したAzure REST API referenceに戻り、Conpute->Virutual MachinesのページにあるRestartを見てみましょう。
仮想マシンを再起動するリクエストフォーマットが書かれていますね。
curlで組み立てるとこんな感じです。
curl -v -X POST -H "Content-Type: application/json"
-H "Authorization: Bearer ★コピーしたaccess_token★"
-H "Host: management.azure.com"
-d "" https://management.azure.com/subscriptions/
★Subscription ID★/resourceGroups/★権限付与したResrouceGroup名★/providers/Microsoft.Compute/virtualMachines/★VM名★/restart?api-version=2016-03-30
※Subscription IDは冒頭で紹介したAzure CLIの「azure account list」から取得してください。
打つと同時にターミナルが落ちましたが、再度ログインしてwho -rすると再起動されたことがわかると思います。
ARM template 大量のNSG/ルールをCSVから一括登録する
今回は(NSG)Network Security GroupのARM templateに関する記事です。
NSGはMicrosoft Azureが提供するファイアウォールちっくなサービスです。
基本仕様はとりあえずおいておいて、ポイントとなる以下の点をまず押さえておきましょう。
〇NSGの適用対象
サブネットかNiCのどちらかになります。
vNETに対して適用はできませんので注意してください。
〇Quota（制限）
NSG名は１サブスクリプション内のリージョン毎に100個が上限
1個のNSG内は200個のルールが適用可能
※足らない場合はSR(Support Requestを上げてSubscription Idを伝えることで
上記個数の倍の制限値上げることができるようです。
さて、このようなNSGですが１つ２つぐらいならAzure Portalから手作業でやることも苦にはなりません。でも一括で１００個も５００個も必要になってくるとそういうわけにはいかなくなります。
お試しやPoCならよいですが、エンタープライズなお客様は既にオンプレで秘伝のタレ的なFW定義といったひな型があると思いますので、その規模のものをどうやって効率よくAzureへ適用し管理できるか、というのが課題になります。
また、多くの方々は100個以上のNSGを登録する際に、パラメータシート（大抵Excel）で管理されていると思いますので、CSV形式に落とし込んでからPowerShellやAzure CLIを使って１行ずつ読み込んで対応することが一般的かと思います。
ここではARM templateを使った「あえて違うやり方」を紹介します。コマンドレットやコマンドラインから１つずつ実行（おそらく再帰的に処理される）することと何が違うのか、そこを最後に記載したいと思います。
ではARM templateで行うやり方について記載します。
〇必要な環境
CentOS 7.2の仮想マシンでAzure CLIがインストール済であること。
ない場合はこのブログの前の記事を見て作成してみてください。
〇用意するもの
１）インプットファイルとなるCSV形式のファイル
⇒ インプットファイルのひな型とスクリプトは以下からwget/curl等でダウンロード
してください。
・インプットファイルのひな型
〇事前準備
上記インプットファイルのサンプル記載を参考に100行でも200行でも適用したい
数だけ自社用・自分用に全て埋めましょう。
〇開始
事前準備が終わった後の確認画面です。（azureコマンドを打てる状態で）
more input.csvで中身を確認してみてください。
※項目と順序、記載文字列が合っていれば、先ほど記載してもらったエクセル
ファイルを上記形式を変えずにCSVへエクスポートし、Linux側へSCPして
ください。
次にmakeNSGjson.shをvi/vimで開きます。
下にあるように作業するPATHを自分のローカルパスに変更してwqしてください。
⇒BASE_DIR_PATHの場所を自分の環境に合わせて修正
ではコマンドを実行します。
特にエラーもなく終われば、実行したその配下にoutput.jsonというファイルが１つ作成されています。
中身を見るとわかりますが、CSV形式をNSGのARM template用に変換かけたJSONファイルとなっています。
JSON形式ですので、合っているようで合ってないないような、よくわからない状況かと思いますので、templateのvalidationとdeployを試してみましょう。
まずはmany-nsg-rgという名前のResource Groupを作成します。（お試し用として）
[azure01@centostest01 blog-sample]$ azure group create many-nsg-rg japaneast
info: Executing command group create
+ Getting resource group many-nsg-rg
+ Updating resource group many-nsg-rg
info: Updated resource group many-nsg-rg
data: Id: /subscriptions/***/resourceGroups/many-nsg-rg
data: Name: many-nsg-rg
data: Location: japaneast
data: Provisioning State: Succeeded
data: Tags: null
data:
info: group create command OK
[azure01@centostest01 blog-sample]$
作成できたので、このmany-nsg-rgへデプロイする前のvalidationをかけてみます。
ちゃんとOKって返ってきていますが、このvalidateion、過度の期待は禁物です。。
デプロイしてPortalから確認してみましょう。
info:でRunningからSucceedがバラバラ出てきたと思います。
Runningは既存リソースと確認してプロビジョニング対象を探しているようですね。また、Succeedの部分は既にポータルで部分的にデプロイが確認できていることから、デプロイステータスを指しているようです。
こんな画面で終わっていれば成功です。
ではポータルで確認してみましょう。
ちゃんと作成されていますね。
ではもう１つ。
test-nsgの宛先アドレスをJSONファイル内を変更して、再度テンプレートデプロイしました。引数を指定しないデプロイは全て増分デプロイになります。
はい、既存のリソースはそのままで、修正した部分だけがプロビジョニングされていることがわかりました。
以上がテンプレートからNSGを一括登録するやり方です。
既にお気づきの方もいるかもしれませんが、コマンドラインやコマンドレットから操作するやり方と比べて、結果は同じだと思います。注目したいのはその管理の主体と履歴です。
shellでもpowershellでもperlでもjavaでもC#でも、実行した時のプログラムやログ等は保管・バージョン管理されていると思いますが、その時にどの定義を当てはめて、現状との差異を追うのは大変です。結局今回の例でいうExcelかCSVで管理する、というやり方が徹底されてしまいます。つまり人が安易に触れる媒体が管理の主体になる、ということはミスが起きやすくなるということです。
ARM templateを使うことで、JSONファイルそのものを履歴で管理すればよい、というお手軽さがわかったでしょうか。今回適用したJSONファイルと既存のResource GroupからエクスポートしたJSONファイルの突合・diffをすれば、何が変わったかは簡単にわかります。既存リソースからCSVを起こす、とか、過去のCSVのバージョン管理方法で既存リソースは「これのハズ」という運用からより確実なやり方に変わると思います。
また、今回紹介していませんが、JSONファイルそのものをgithubで管理することでJSONファイルそのものの更新管理がより楽になります。
1000行のNSGや2000行のNSGといった大規模な環境になると、整形するスクリプトが必要にはなりますが、このようなやり方で新たな運用方法をお試し頂くのもアリではないでしょうか。
ARM template (CentOS with カスタムスクリプト編)
前回に引き続きARM templateを使った自動構築のひな型、といいますか自作版を紹介します。
今回紹介するテンプレートはMicrosoft Azure上にCentOSをボタン一発（正確にはssh-keyのコピペがありますが）で作成するというものです。
では早速紹介に入ります。JSONの実物は以下です。
上記のテンプレートを任意なResource Groupにテンプレートデプロイすると以下が作成されます。
ログインユーザー: azure01
SSHkey形式:RSA形式
パブリックIPアドレス: Static設定で１つ
仮想ネットワーク: 172.10.0.0/16を１つ
サブネット; 172.10.1.0/24を１つ
ストレージアカウント: １つ
ストレージアカウント冗長方式: Standard_LRS
カスタムスクリプト：任意なshellを指定
CentOSを毎回試験用に１台立てるのがめんどい方、CentOSが起動した後に自分で作成したshellスクリプトをOS起動時に埋め込みたい方へのひな型としてご自由にご利用ください。デフォルト設定のままでよければ、RSA形式のssh-keyを張り付けるだけでデプロイできるようにしています。
以下JSONファイル内で行っている詳細です。ご参考に。
※変更可と選択可があります。
〇OS
(固定）
〇OSのバージョン
7.2
(デフォルト：parametersで選択可）
〇仮想マシンの名前
centostest01
（デフォルト：parametersで変更可）
〇仮想マシンのログインユーザ
azure01
（デフォルト：parametersで変更可）
〇SSH-key
★RSA形式のものをベタっと張り付けてください。
（ここは入力必須）※詳細は以下で。
〇仮想マシンのサイズ
Standard_A1
（デフォルト：parametersで選択可）
〇可用性セットの名前
centostest01-avail
（デフォルト：parametersで変更可）
〇ストレージアカウントの冗長方式
Standard_LRS
（デフォルト：parametersで選択可）
〇ネットワークセキュリティグループの名前
centostest01-nsg
（デフォルト：parametersで変更可）
〇仮想ネットワークの名前
cent-vnet
（デフォルト：parametersで変更可）
〇仮想ネットワークのアドレス帯
172.10.0.0/16
（デフォルト：parametersで変更可）※変更する場合はサブネットも要修正
〇仮想ネットワークのアドレス帯
172.10.1.0/24
（デフォルト：parametersで変更可）※変更する場合はvNetのアドレス帯に注意
〇カスタムスクリプトの配置先URL
https://raw.githubusercontent.com/akkoike/ARMtemplate/master/parts/VirtualMachine/script.sh
（デフォルト：ご自分で用意したスクリプトを指定ください。
上記のscript.shはTimezoneを日本時間に変更するだけのお試しshellです）
script.sh
（デフォルト：上記配置先URLで指定したスクリプト名のみを記載ください。
このファイルはCentOSが立ち上がった後、/var/lib配下に配置されます）
その他補足。
・可用性セットでは障害ドメイン、更新ドメインそれぞれデフォルトの3と5を指定しています。
・プライベートアドレス(NiC)は自動取得（Dynamic）の設定にしています。
・NSGのinbound許可ポートは22port(SSH）のみにしています。outboundは無し。
・パブリックIPアドレスは静的（Static）にしています。
・shellスクリプトはインターネットアクセスできる場所に配置されていることが前提
※カスタムスクリプトが実行されるタイミングはOSが起動した後になるため、
先にOSへログインするとTimeZoneの変更がまだされていない状態になっています。ご注意を。
・CentOS内でカスタムスクリプトの実行状況を確認するログファイルは以下です。
/var/log/azure/Microsoft.OSTCExtensions.CustomScriptForLinux/1.5.2.1/extension.log
中身を見るとわかりますが、上記GitHubのURLから持ってきたスクリプトは以下に
格納されていることがわかります。
/var/lib/waagent/Microsoft.OSTCExtensions.CustomScriptForLinux-1.5.2.1/download/0/script.sh
以上となりますが、これをひな型にscript.shの内容を変更することでInfrastructure as CodeとConfiguration as Codeを一括で体験することができます。
是非お試しください。
はじめてのARM template（storageaccount編）
多忙にかまかけて更新が途切れておりました。。。反省。
今回はAzure Resource Manager template（略してARMテンプレート）と呼ばれるものを紹介したいと思います。
ちなみにTechSummit 2016で発表した資料は以下になります。
なにそれ？なにができるの？という基本的な部分は下記を参考にしてください。
ここでは実践的な利用説明をしていきます。
まず以下のGithubをご覧ください。
今後deploy確認が取れたものを順次上げていく＆ここで日本語の説明をしていくつもりです。commitは随時やってるのでupdate日時を参考に適当にご利用ください。
README.txtにも記載していますが、ディレクトリ構成は以下としています。
- HowToUseOnCentOS
CentOS7.2にAzure-CLiをインストールしてTemplateデプロイやエクスポートなど
操作する際のあんちょこメモを記載しています。
Azure Portalからの操作に不慣れな方やVisual Studio Codeよりvimだよね、という
方はこちらをご参考に。
- README.txt
肝心の部分だけを言うとparts配下がAzureサービス単体でデプロイするひな型を
用意しています。customize配下がAzureサービスを複合的に利用してデプロイ
するものを用意します。
では実践編にうつります。
■storageaccount.json
〇場所：
parts/storageaccount.json
〇概要：
単一storageaccountを１つ作成するテンプレートです。
〇parameters（変更可能個所）：
ストレージアカウントの名前、冗長方式の選択。
〇注意点：
ストレージアカウントの名前は「storaccount01」をデフォルトにしています。
冗長方式のデフォルトはLRSにしています。
API-Versionは「2015-06-15」を利用しています。
■loop-create-storageaccount.json
〇場所
parts/loop-create-storageaccount.json
〇概要：
任意の数だけstorageaccountを作成するテンプレートです。
〇parameters（変更可能個所）：
ストレージアカウントの名前、冗長方式の選択、作成する個数。
〇注意点：
ストレージアカウントの名前は「strloop0」をデフォルトにしており、この後
ろに指定した個数の数値（int）を繋げています。
例）個数を10とした場合、strloop01~strloop010まで作成されます。
冗長方式で選択したものは作成されるストレージアカウント全てに同一の冗長
方式がセットされます。1個はLRSで2個目はGRSで3個目以降はRA-GRSで、
といった利用はできません。希望があれば作りますが。
今回紹介するテンプレートは上記２つだけですが、記載時・修正時にハマること
を避けるため、２つほどポイントを記載します。
１：api versionと利用できるtype。
あれ？記事に記載されているものをコピペしたけどデプロイできない、とか
ハマるケースが多いです。それもそのはずで、account typeなどは指定できる
値がapi versionによって動作しないものもあるからです。
簡単に言えば利用するバージョンのAPIで対応されていない指定方法はエラー
になる、です。なので以下のAPIバージョンと記載方法のひな型を参考に組み
立てましょう。
２、関数について。
JSONファイルの容量制限は1MB以内とあります。
※.parametersファイルは64KB以内。
全てべた書きで記載するのもありですが、効率よく記載することで容量の壁に
当たらない＆修正範囲を少なくするといった「かしこい」書き方は少しずつ覚えて
いきましょう。参考とするサイトは以下です。
はい、すみません、英語なのと全て覚えるのかおい！という状況になってしまう
ので、その中でもよく利用される関数について以下補足します。
concat
⇒ 文字列を連結します。()内にある「,」カンマ区切りのものを
連結させます。
例：concat("テンプレート","は","便利ですね") みたいな感じで
つかります。
parameters('')
⇒ parameters('変数名') として、指定された値を呼び出してます。
上のconcatと繋げてconcat(parameters('変数名'),"便利ですね")みたいに
毎回固定の文字列を記載せずに記載するやり方が一般的、というか
コードを修正する際に修正範囲を少なくするやり方です。
同じようにvaliables('変数名')といった利用もできます。
resourceGroup().ほげほげ
⇒ ここではresourceGroup().locationを使っています。
resourceGroupの関数を呼び出して、locationの値を取ってきています。
東日本リージョンの場合はjapaneastという文字列と同義です。
copyindexとcopy
⇒ この２つはセットで覚えます。よく使う記載パターンはresourcesの中で
nameの中にcopyindex()をconcatで文字列連結させ、copy関数の中で
countの数を指定し、作成する個数を指定するやり方です。
for文のように{}内で記載した部分だけをループさせる、といった記載
方法ではないため、とっつきづらいですが、１つのパターンを覚えて
あとは流用・展開すれば勝手はわかると思います。
長くなったので、storageaccountのテンプレート作成はこの辺で終わります。
次回はまた別のAzureサービスをtemplateでどう記載するか、といった点
でいくつか紹介します。
Azure Media Serviceでライブストリーミングしてみる
これまでLinuxユーザーの観点でMicrosoft AzureのIaaS側を主に見てきましたが
少しブレイクしてMicrosoftのPaaSサービスについて少し見てみようかと思います。
この記事をご覧になられている方々はLinuxユーザーが多いと思いますが、「MicrosoftのPaaSサービス」と聞いてどのようなイメージを持っているでしょうか？
Platform as a Servicesなので、プラットフォームなんだよね、認証基盤？解析基盤？それともOSS的な何か？っとおぼろげなイメージを持たれている方々も少なくないと思いますし、昔からMicrosoft Azure(昔はWindows Azure）を見てきた方々は最新の動向もキャッチアップされていると思うので、cognitive servicesとかapplication Insights、webjobs、batchなど、いろいろあるけど、、という答えを持っていると思います。
今回はあえて、Linuxユーザーが、あまり知らない or あえて手を出さないであろう領域について例をあげて紹介をします。RHELやCentOS、Java/php/pythonなどのLinuxな方々に精通したキーワードはほとんど登場しませんが、知っておくことで今まで手を付けなかった技術の幅が広がるため、知って損はないと思います。
今回紹介するのはAzure Media Service、略してAMSと呼ばれるPaaSサービスです。
サービスの概要は一言で言うと、動画が再生/提供できるPaaSサービスです。
概要レベルの説明はオフィシャルサイトにも他の記事でも多くのってますので、他の記事を読みあさってもよいですが、Dynamic PackagingやIngest、DRM、Smooth Streamingなどなど、この世界の専門用語を知らないとさっぱりイメージできないものも多いので、まずは触ってできることからイメージするとよいかもしれません。
では早速触ります。
全体の流れは以下の流れです。
・Azure ポータルにログインしてAMSアカウントとchannelを作る。
・Wirecastをインストール
・channelを起動してパソコンに搭載されているカメラ動画をWirecastからストリーミングする
・Azure Media Playerからストリーミング動画を閲覧する
上記をやります。個々で細かい説明と補足を入れます。
ではまずAzureポータルからAzure Media Serviceアカウントを作り、channelと
呼ばれるものを作成しましょう。
ストレージアカウントが必要になりますが、ストリーミングのデータは複数個用意されますので、ここでは新規にストレージアカウントを作成して分けて管理します。冗長はLRSで用意しました。
メディアサービスアカウントとストレージアカウントの準備ができれば、リソースグループから今回用意したmediatest-rgをクリックします。右にメニュが流れきますが「ライブストリーミング」と記載されている項目をクリックし、新規でチャネルを作成します。
ライブストリーミングやチャネルという言葉が出てきたので補足します。
AMSは２つの利用形態があり、ライブストリーミングとVideo on Demand（VoD）があります。ライブストリーミングはその名の通り映像を取ると共にそのままストリームで動画を公開する時に使います。VoDはmpeg4やwmvなどの動画ファイルが事前に用意し、動画ファイルをAMSにアップロードして動画を公開する用途で利用します。次にチャネル（channel）ですが、今回試すライブストリーミングでは必要なものになります。チャネルはテレビでいうチャンネルに該当します。4チャンネルや8チャンネルなど、チャネルを用意することで１つのチャンネルができる、と考えるとしっくりします。（今回触れませんが、チャネルの中でprogramという名前の機能を用意する場合があります。programは番組表です。テレビでいう4チャンネルには朝09:00-10:00まで○○な番組を流す、という概念がありますが、ここでも同じです。チャネル内にprogramを用意することで、チャンネルと番組表を管理する、っと覚えるとよいでしょう）
上の画像ではチャネルが既に「実行中」になっています。チャネルは割り当て解除の停止になっていないと常に課金され続けますので注意が必要です。また、「取り込みＵＲＬ」と記載されている個所に今回用意したチャネルの取り込みＵＲＬが新規で払い出されています。
rtmp://aklivechannel001-akmediatest001.channel.mediaservices.windows.net:1935/live/1d4371b723914732824eaaabebeead58
このＵＲＬが、AMS側で今回用意したチャネルの「ストリーミングを取り込むＵＲＬ」になります。このＵＲＬへクライアントからRTMP通信して動画を流すことで、用意したチャネルへ動画が入っていきます。
チャネル名の行をクリックすると、より詳細な設定情報が見れますが、取り込みURLにはプライマリとセカンダリの２つのＵＲＬが払い出されます。これは大型のビデオカメラを想像してほしいのですが、１台のハードウェアが故障しても２台目のハードウェアで冗長する必要も出てくるためプライマリとセカンダリと別れています。今回のお試しライブでは特に気にする必要はありません。
次にストリーミングユニットの設定をしておきます。
上記画像の下にあるバーがデフォルトでは0になっていますので、1に設定します。
ストリーミングユニットとは、専用の送信容量を 200 Mbps 単位で購入できるほか、ダイナミックパッケージングと呼ばれる追加機能が利用できるようになります。ダイナミックパッケージングは、ライブで流している動画を設定した時間分VoDとして自動的にAMS側に動画コンテンツとして保管してくれ、様々なエンコード方式でマルチデバイスで再生できる状態にしてくれる、というとてもうれしい機能です。
Azureポータルでは最後にライブイベントの作成を行います。
チャネル名が表示されている行をクリックし、「ライブイベント」をクリックします。名前は適当につけてあげてください。
アーカイブウィンドウの個所はデフォルト8時間となっていますが、今回のお試しでは5分と設定しました。つまりライブで流している動画を5分間だけVoDとしてアーカイブしておく、という意味になります。このVoDファイルの暗号化はDRMにしてみましょう。Microsoftが提供する暗号化技術ですね。最後にＯＫボタンを押してライブイベントの作成が始まります。
では次にクライアントの準備に入ります。今回利用するクライアントはTelestream社が提供するwirecastです。
http://www.telestream.net/wirecast/overview.htm
上記サイトにあるDownload Free Trialから無料版をダウンロードしてインストールします。(Windows OSへインストールします）
Wirecastを起動し、クライアント側の設定をします。
左下に小さな窓が縦にいくつかありますが、左下の１番上のモニターの右にある「＋」をクリックし、ビデオカメラっぽいアイコンから「integrated camera ショットの追加」をします。そうするとモニターの右側にＰＣの小型カメラから映っている映像が出てきますのでその画面をクリックし、真ん中にある大きなモニターの左側に表示させます。表示されたら２画面ある大型モニターの真下にある「→」ボタンをクリックし、右側のモニターに左側と同じ映像を表示させます。
上記のような状態になっていればＯＫです。
上記画面の左上に「ストリーム」というボタンを押します。出力先をプルダウンで指定するポップアップが出てきますので、プルダウンメニューから「Azure Media Service」を選択します。
上記画面では「アドレス」の個所に適当なＵＲＬが入っていますが、こちらを先ほど取得した「取り込みＵＲＬ」に上書きしてＯＫボタンを押します。つまりWireCastで撮影した動画はAzure Media Serviceの取り込みURLへ送る、という設定です。エンコードの個所は任意で変更できます。希望ビットレートを設定したりエンコード方式や解像度を変更することもできるようです。今回はデフォルトのH.264 720p(プログレッシブ)で送信します。
OKボタンを押すとモニター画面に戻りますが、上記は設定完了のＯＫですので、もう一度左上にある「ストリーム」ボタンを押します。ストリームボタンのボタン枠が赤くなっていれば動画をAMSへストリーム配信している、という状態を表します。
ではAzure ポータルに戻ります。プレビューで映像が流れてきているかを確認しましょう。
ちゃんと流れてきていますね。１点注意ですが、プレビューはあくまでも映像が流れてきているかどうかを確認するだけにすぎません。映像がスムーズに流れているかどうかはプレビューではなく、上記画面の「再生ＵＲＬ」を閲覧して確認します。
※メディアの世界ではビットレートやフレームレートと呼ばれる画像をどの単位/粒度で細切れに送信するか、つまり映像がストレスなくスムーズに流れるかにこだわる領域があります。映像はつまるところ画像を順番に流し続けることで動く映像として見せているため、このビットレートやフレームレートを調整することで映像をストレスなく見せることができます。
では最後に上記画面の「再生ＵＲＬ」をコピーし、Azure Media Playerで確認してみましょう。
http://ampdemo.azureedge.net/azuremediaplayer.html
上記ＵＲＬを開きます。
上記のような画面が表示されたら、右下にあるＵＲＬの個所を先ほどコピーした再生ＵＲＬに上書きし、下段にある「Update Player」ボタンを押します。いかがでしょうか、ちゃんとPCカメラで撮っている映像が流れてきているでしょうか。
実際に撮影している映像とAzure Media Playerで流れて来る動画にはタイムラグがあります。（視聴者にはわかりませんが）
また、HTML5ですが、Codeのタグをクリックすることで自分の任意なサイトへHTML5の記載で張り付けることもできそうです。
せっかくなのでWireCastのストリームボタンを押してストリーミングを止めてみましょう。
先ほど5分で設定したライブイベントの行をクリックし、ストリーミング中と書かれたＵＲＬをコピーします。先ほど見たAzure Media PlayerのURLにコピーしたＵＲＬを張り付けてupdateしてみましょう。5分間だけですが、ライブでとった映像がちゃんとVoDとして再生されることが確認できます。
以上でAMSを使ったライブストリーミングの操作は終わりますが、VoDの流れも基本的にIngest部分（最初に映像を取り込んで送る）が異なるだけで取り込んだ後は同じです。ブラウザからは200MBを上限とした動画サイズしかアップロードできませんが、最大200GBまでの動画をAPIやAzure Media Service Explorerからアップロードすることができます。また、CDN(Akamai/EdgeCast）と連携して動画コンテンツをマルチリージョンでストレスなく流す、といったこともできます。
Azure Media Servies Expolorer
https://github.com/Azure/Azure-Media-Services-Explorer
※AMSが提供するAPIのほぼすべてが上記ツールから利用できます。
（このツールはMS純正製品ではないのでサポート対象外）
LinuxサーバーでRTMPサーバーを構築して、、CDNのエッジサーバーへpurgeするコマンド作って、、とかめんどくさいことをしなくとも、Microsoft Azureが提供するPaaSを上記のように利用するだけで、簡単に今まで避けてきた・できなかった・時間がかかったことができるようになります。便利ですので、是非お試しください。
Microsoft Azure CentOS7.2の実態
これまでMicrosoft Azureの利用方法や仮想マシンの作成、ディスク増設、ロードバランサの作成などを中心に記事化してきました。
本記事ではもう少しOSの中身に触れていこうと思います。
Microsoft Azureが提供するCentOSにはどういったバージョンが用意されており、中身がどうなっているかの実態についてメスを入れたいと思います。作成してログインして初めて知った、というクラウドサービスも多いと思いますので、利用する前に少しでも参考になればと思います。
では最初にMicrosoft Azureが提供しているCentOSについて。
CentOSだけで見てもラインナップが多いな、という感触ですが、いわゆる仮想アプライアンスっぽいものを除くとCentOS-based *.*なるものが一般標準的なCentOSに見えます。CentOSはRHELディストリビューション互換のOSですので、RHELをご利用されているLinuxユーザーであれば親しみやすいバージョン表記と言えます。
Linuxユーザーが利用しているCentOSの多くは、centos.orgにあるISOイメージから展開したものだと思いますので、それに適合するものを選択しましょう。
CentOS-based 6.5
CentOS-based 6.6
CentOS-based 6.7
CentOS-based 7.0
CentOS-based 7.1
CentOS-based 7.2
CentOS5.xはないですが、6.xから最新の7.2までカバーされていることがわかります。
実はもう１つ気になる要素があります。公開元がOpenLogicとなっています。centos.orgではない点が長く利用されている人から見ると気持ち悪く見えるかもしれません。
OpenLogic（米）は各種オープンソース技術の商用サービスを提供しています。centos.orgのISOとの違いは中身を見るとわかりますが、waagentと呼ばれる Azureが管理するために必要なエージェントとwaagentがリポジトリに登録されている点だけですので、今まで慣れ親しんだCentOSと基本的なディストリビューションに変わりはありません。
では、早速最新版であるCentOS7.2の中身を覗いてみましょう。
今回作成したのはA2サイズのCentOS7.2です。
まずはCPUから。
[root@startuptest ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
stepping : 2
microcode : 0xffffffff
cpu MHz : 2397.183
cache size : 30720 KB
・・以下省略
XeonのE5-2673 v3 2.4GHzが使われているようですね。いいの使ってますね。
次にメモリ。
[root@startuptest ~]# cat /proc/meminfo
MemTotal: 3523796 kB
MemFree: 2916784 kB
MemAvailable: 3102256 kB・
・以下省略
3.36GBほど搭載されています。
次はディスク。
[root@startuptest ~]# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 31440900 1327716 30113184 5% /
devtmpfs 1751956 0 1751956 0% /dev
tmpfs 1761896 0 1761896 0% /dev/shm
tmpfs 1761896 8480 1753416 1% /run
tmpfs 1761896 0 1761896 0% /sys/fs/cgroup
/dev/sdb1 139203080 61468 132047444 1% /mnt/resource
tmpfs 352380 0 352380 0% /run/user/1000
tmpfs 352380 0 352380 0% /run/user/0
[root@startuptest ~]#
これは以前の記事でも触れましたね。ローカルディスクとして利用できる容量は約30GBほどです。/mnt/resourceはテンポラリ用途で使う、でしたね。
もっといろいろ見ていきましょう。
hostsの初期設定。
[root@startuptest ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
[root@startuptest ~]#
localhost localhost.localdomainはループバックアドレスに対するお約束です。
localhost4、localhost6、これはIPv6とIPv4が混在する環境で明示的にIPv4のループバックアドレスを指し示さなければならない場合にreservedされているホスト名ですね。
まぁ、特に意識する必要はなくIPaddress hostnameと今後追記していけばよさそうです。
次はネットワーク設定
[root@startuptest ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.4 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::20d:3aff:fe50:65cc prefixlen 64 scopeid 0x20<link>
ether 00:0d:3a:50:65:cc txqueuelen 1000 (Ethernet)
RX packets 41562 bytes 57325350 (54.6 MiB)
RX errors 0 dropped 51 overruns 0 frame 0
TX packets 8697 bytes 2911582 (2.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 193 bytes 33850 (33.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 193 bytes 33850 (33.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ここで？？？っと思われた方もいると思います。eth0のNICに割り振られているアドレスは192.18.0.0/24で切ったsubnet内のアドレス(192.168.0.4)です。イメージしていたのはeth0がAzureポータルで設定した静的なグローバルアドレス、eth1が192.168.0.4かと思わたのではないでしょうか。そうなんです、Azureではグローバルアドレスは別に管理されている、ということがわかります。これ結構、しっかりしているなぁと思う個所で、OSのネットワーク操作に慣れている方だと簡単にOS内でIPaddressを変更することだってできてしまいます。
パブリッククラウドで管理されているアドレスの多くはDHCPサーバーから取得する方式（Azureもそう）をとるため、既に誰かに払い出されているグローバルアドレスを任意にOS側で書き換える行為ができないように設計されている、ということがわかります。
次はeth0の設定をもう少し。
[root@startuptest network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DHCP_HOSTNAME=startuptest
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no
[root@startuptest network-scripts]#
BOOTPROTOにdhcpとありますね。ps -efで見ると/sbin/dhclientのプロセスが起動していることもわかります。
次DNS。
[root@startuptest etc]# cat resolv.conf
; generated by /usr/sbin/dhclient-script
search dkmaz4wqi3oebdscr1r11xwogc.lx.internal.cloudapp.net
nameserver 168.63.129.16
[root@startuptest etc]#
どこだこれ、というnameserverが記載されていますが、whois情報で調べるとMicrosoft Corpと出ますので、マイクロソフトが管理しているネームサーバーが初期設定で登録されていることがわかります。nslookupで外部ドメインを検索するとIPアドレスが表示され正しく正引きできていることがわかります。
念のためnsswitch.confも。
[root@startuptest etc]# grep "^hosts" /etc/nsswitch.conf
hosts: files dns
[root@startuptest etc]#
filesの次にdnsとなってますね。ですので/etc/hostsを最初に名前解決として探しにいき、なければ/etc/resolv.confに記載したネームサーバーを上から順に聞きに行く、という経路になってます。
次は時刻。
[root@startuptest etc]# date
Thu Jun 23 06:57:16 UTC 2016
[root@startuptest etc]#
ただいま6月23日15:57 JST。。。。泣きそうです。
東日本リージョンで作成したのにー、とか野暮なことは言わず、サクッと以下のコマンドでタイムゾーンを変更して現在時刻にしましょう。
timedatectl set-timezone Asia/Tokyo
次はuptimeとsar。
[root@startuptest etc]# uptime
16:01:37 up 1:14, 1 user, load average: 0.02, 0.02, 0.05
[root@startuptest etc]#
[root@startuptest etc]# sar
Linux 3.10.0-327.18.2.el7.x86_64 (localhost.localdomain) 06/23/2016 _x86_64_ (2 CPU)02:48:04 PM LINUX RESTART
02:50:01 PM CPU %user %nice %system %iowait %steal %idle
03:00:01 PM all 2.58 0.00 0.40 2.64 0.00 94.37
03:10:01 PM all 0.34 0.00 0.08 1.54 0.00 98.04
03:20:01 PM all 0.31 0.00 0.06 1.59 0.00 98.04
03:30:01 PM all 0.31 0.40 1.12 3.34 0.00 94.83
03:40:01 PM all 0.32 0.00 0.07 1.02 0.00 98.59
03:50:01 PM all 0.35 0.00 0.10 0.03 0.00 99.52
04:00:01 PM all 0.31 0.00 0.08 0.03 0.00 99.58
Average: all 0.64 0.06 0.27 1.45 0.00 97.58
[root@startuptest etc]#
uptimeはともかくsarが標準で効く(sysstatが入っている）のは少し驚きです。
ちなみにtopコマンドも利用できますね。
top - 16:04:35 up 1:17, 1 user, load average: 0.12, 0.04, 0.05
Tasks: 235 total, 2 running, 233 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.6 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 3523796 total, 2806272 free, 214012 used, 503512 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 3057176 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29421 root 20 0 157804 2316 1536 R 1.3 0.1 0:00.06 top
1 root 20 0 126472 7284 2632 S 0.0 0.2 0:05.09 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.13 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root rt 0 0 0 0 S 0.0 0.0 0:00.10 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
次はiptables。
[root@startuptest ~]# systemctl status iptables
● iptables.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
[root@startuptest ~]#
はう！っと雄たけびを上げそうになりましたが、CentOS7からiptablesではなくfirewalldを使うようになります。といってもfirewalldはiptablesをラップしたもののようですので、実態はiptablesですが、今ままで慣れ親しんだ小難しいルール設定をぶち込むことができなくなります。iptablesとfirewalldは併用できないので、どうしてもiptablesを使いたい場合はyum install iptables.serviceから個別でインストールし、firewalldをsystemctlでdisableする必要がありそうです。
さて、だいぶ記事が長くなってきたので本記事はこの辺で一旦終わり、続きは次の記事でアプリケーションよりの情報を見てみましょう。
はじめてのMicrosoft Azure(ロードバランサ#3)
前回までの記事はこちら
はじめてのMicrosoft Azure(ロードバランサ#2) - LinuxユーザーがイジるはじめてのAzure
それでは前回からの続きです。
既にCentOS7.2の仮想マシンが２台、publicip、vNET、subnet、NSGなどがTemplate Deployから作成済だと思います。
まずは２台の仮想マシンへsshログインしHTTPポートを受け付ける設定を入れましょう。
ログインしたらsudo su - でルートアカウントになります。
[root@templatecent2 ~]# yum list httpd
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Available Packages
httpd.x86_64 2.4.6-40.el7.centos.1 updates
[root@templatecent2 ~]#
httpdは既にリポジトリに入っているようですので、こちらを利用してみましょう。
※apacheの最新verがいいんだ！という方はwgetでもってきてrpmインストールしましょう。wgetはインストールする必要はありません。
[root@templatecent2 ~]# yum install httpd.x86_64
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-40.el7.centos.1 will be installed
--> Processing Dependency: httpd-tools = 2.4.6-40.el7.centos.1 for package: httpd-2.4.6-40.el7.centos.1.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.centos.1.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.1.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.1.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-3.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-40.el7.centos.1 will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
--> Finished Dependency ResolutionDependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
httpd x86_64 2.4.6-40.el7.centos.1 updates 2.7 M
Installing for dependencies:
apr x86_64 1.4.8-3.el7 base 103 k
apr-util x86_64 1.5.2-6.el7 base 92 k
httpd-tools x86_64 2.4.6-40.el7.centos.1 updates 82 k
mailcap noarch 2.1.41-2.el7 base 31 kTransaction Summary
================================================================================
Install 1 Package (+4 Dependent packages)Total download size: 3.0 M
Installed size: 10 M
Is this ok [y/d/N]: y
Downloading packages:
(1/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00
(2/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:00
(3/5): httpd-2.4.6-40.el7.centos.1.x86_64.rpm | 2.7 MB 00:00
(4/5): httpd-tools-2.4.6-40.el7.centos.1.x86_64.rpm | 82 kB 00:00
(5/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00
--------------------------------------------------------------------------------
Total 5.1 MB/s | 3.0 MB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : apr-1.4.8-3.el7.x86_64 1/5
Installing : apr-util-1.5.2-6.el7.x86_64 2/5
Installing : httpd-tools-2.4.6-40.el7.centos.1.x86_64 3/5
Installing : mailcap-2.1.41-2.el7.noarch 4/5
Installing : httpd-2.4.6-40.el7.centos.1.x86_64 5/5
Verifying : mailcap-2.1.41-2.el7.noarch 1/5
Verifying : httpd-2.4.6-40.el7.centos.1.x86_64 2/5
Verifying : apr-util-1.5.2-6.el7.x86_64 3/5
Verifying : apr-1.4.8-3.el7.x86_64 4/5
Verifying : httpd-tools-2.4.6-40.el7.centos.1.x86_64 5/5Installed:
httpd.x86_64 0:2.4.6-40.el7.centos.1Dependency Installed:
apr.x86_64 0:1.4.8-3.el7 apr-util.x86_64 0:1.5.2-6.el7
httpd-tools.x86_64 0:2.4.6-40.el7.centos.1 mailcap.noarch 0:2.1.41-2.el7Complete!
[root@templatecent2 ~]#
インストールはうまくできましたので、起動させましょう。
[root@templatecent2 ~]# service httpd start
Redirecting to /bin/systemctl start httpd.service
[root@templatecent2 ~]# ps -ef | grep http
root 1331 1 6 03:17 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1332 1331 0 03:17 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1333 1331 0 03:17 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1334 1331 0 03:17 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1335 1331 0 03:17 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1336 1331 0 03:17 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
root 1338 1238 0 03:17 pts/0 00:00:00 grep --color=auto http
[root@templatecent2 ~]#
うまく起動できました。確認は「service httpd status」や「netstat -an | grep ":80"」などで確認できます。
このままではデフォルトページが表示されるだけです。この後のLBのアクセスが分散されているか確認しづらいため、「/var/www/html」配下にindex.htmlを配置しておきましょう。
[root@templatecent html]# cd /var/www/html
[root@templatecent html]# ls -l
total 4
-rwxr-xr-x. 1 root root 80 May 31 03:15 index.html
[root@templatecent html]# cat index.html
<html>
<head></head>
<body>
<font size=20>Hello Azure !!</font>
</body>
</html>
[root@templatecent html]#
これで１台目の設定は終了です。
２台目の設定も同じでやっておきましょう。２台目はindex.htmlの中身の文字列をHello AzureではなくHello Azure 2 とか、違いがわかるようにしておくとよいです。
さて、お膳立ては整いましたので、ロードバランサーを作成します。
Azureポータルへログインします。
左ペインのメニュー「参照>」から「ロード バランサー」を選択します。
「追加」から、以下の設定を入れて作成ボタンを押します。
「名前」は適当にわかりやすい名前をいれましょう。
「スキーム」の個所はExternalかInternalかの選択です。今回はインターネットから80portでアクセスを受け付け、配下に振り分けた２台の仮想マシンへ分散するためExternal LoadBalancerとして使います。パブリックを選択しましょう。
「パブリックIPアドレス」の部分は今作成しようとしているLBのVIPになります。新規に静的アドレスとして１つ用意しましょう。
リソースグループは２台の仮想マシンがいるリソースグループを選択します。一通り設定が終われば作成ボタンを押して待ちます。
作成されたら左ペインのリソースグループからtemplatetest-rgを覗いてみましょう。
先ほど作成したロードバランサーが新たに加わっていることがわかります。
クリックして設定を入れていきます。
作成時に新規で用意したVIPがちゃんとついていますね。
では「設定」ボタンから右側に表示されている以下の設定を入れていきます。
１、プローブ
名前が？？？だと思いますが、ここでは「どのプロトコルとポートに対して」「何秒間アクセスできなければ異常とし」「何回リトライ回数とするか」の設定を入れます。
平たく言えば「分散対象に対して異常判定する閾値を設定する」です。
今回はHTTPですので、80と設定し、閾値はデフォルトのままでいきます。
２、バックエンドプール
これまた何のこと？という名前ですが、分散対象の仮想マシンを選ぶ設定です。
２台用意した仮想マシン（templatecent、templatecent2）を選択し分散対象としま
しょう。
３、負荷分散規則
LBが受け付けるポート（80）と分散対象の仮想マシンへ通信するポート（80）を
入れます。また、先ほど設定準備したプローブの設定名とバックエンドプールの
設定名を入れます。セッション永続化やアイドルタイムアウトはお好みで設定し
ましょう。
ここまで準備できれば完了です。
LBのVIPに対してブラウザか表示させてみましょう。何度かブラウザの更新をするとhello azureとhello azure2が表示されると思います。うまく分散されている証拠です。
service httpd stop で落ちます。
同じようにLBのVIPをブラウザから何度か更新すると、片方のhello azure 2しか表示されなくなります。うまく切り離されていることがわかります。
以上でロードバランサーの記事は終わりとします。
以下参考ですが、今回用意したVIP・DNS名に対してHTTPのサービス監視を入れることもできます。現在はまだプレビュー版となっていますが、「参照>」からapplication Insightsというものがあります。
WEBサイトの解析等が細かく設定できるものですが、以下のようにURLに対して監視設定を入れ、エラーとなったら任意のメールアドレスへメール送信する、といったこともできます。興味がある方は是非やってみてください。
ご参考まで。
