LinuxユーザーがイジるはじめてのAzure

LinuxユーザーがMicrosoft Azureを使いこなせるように応援するブログです

Log Analyticsを使いCentOS7のrsyslog経由で特定の文字列を検知しアラートメールを飛ばす

どこぞの知人から強く希望されたので記事にしておきます:)

 

システムの健康状態を管理するやり方として、よく監視ツールといったシステムの異常を検知してアラートを飛ばす、または検知した情報を基に一次復旧のスクリプトを流す、なんて話はよくある話ですね。

 

これはクラウド化したところでやりたい要件や見たい要望が大きく変わるものではないのが現状かと思います。むしろクラウドのメリットとしてスケールでカバーする世界になってくれば来るほど、ちまちまと1台ずつ管理するほうがめんどくさいぐらいです。

 

そこにはスケールでカバーできる規模の監視・管理サービスを追及するか、そもそも監視・管理の必要のない世界を目指すか、で分岐されそうですね。個人的には監視で夜間たたき起こされた悪夢が多い自分としては監視不要のアーキテクチャな世界を選びたいものですw

 

さて、前置きはそのあたりにしておき、Linuxユーザーのクラウド利用と限定した場合の多くは、ベンダーが提供する監視ツールやサービスを使うか、on IaaSでzabbixやnagiosなどを導入する、というのが一般的かと思います。

 

今回の記事はMicrosoft Azureが提供するOMS Log Analyticsでこんなことできます、というのを一例としてだしておきます。ご参考に。

 

やりたいことは、CentOS7内で吐き出されるログの中で、特定の文字列が吐き出されたものを監視しアラートメールを飛ばす、というものです。CPUやMEM、Diskといったリソースの監視についてはAzure Monitorをポータル上からポチポチ選べばできそうですが、アプリ特有のメッセージを拾う、となるとちょっと難しい監視要件となります。

 

早速やりましょう。

 

●前提

 とりあえずCentOS7の仮想マシンを準備しておきましょう。また、その仮想マシン

 vhdを保管しているstorage account名をメモっておいてください。

 Azure Portalの+ボタンからLog Analyticsを選択し、お好みのResource Groupに

 デプロイしておきましょう。

 

●開始

Log Analyticsをデプロイする際に解析対象とするStorageAccountを選ぶ画面があります。ここではLinuxのsyslogを対象とするよう設定しておきます。

 

f:id:akazure:20170605133827j:plain

 

 

Azure ポータルからLog Analyticsを開くとこんな感じに見えます。

f:id:akazure:20170605133540j:plain

 

ではCentOS7にOMS用のエージェントをインストールします。インストール方法のサイトは以下です。

 

Connect Linux computers to Azure Log Analytics | Microsoft Docs

 

丁寧に書かれていますが、簡単に書くと以下の2行でインストール完了します。

 

 

wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh

 

sh onboard_agent.sh -w <YOUR OMS WORKSPACE ID> -s <YOUR OMS WORKSPACE PRIMARY KEY>

 

ここで軽く迷子になりそうですが、<YOUR OMS WORKSPACE ID>はAzureポータルのLog Analyticsのボードを開いた時に「

 

f:id:akazure:20170605135201j:plain

ここまでできれば、ps -ef | grep -i agentで見ると何やらphthonがキックしているomsagentなるものが起動していることがわかります。

 

また、omsagentが管理しているメトリックスの定義ファイルは以下になります。

/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf

 

/etc/rsyslogの設定を見ると、omsagentの追加定義が以下に配置されています。

 

/etc/rsyslog.d/95-omsagent.conf

 

 

中身を見るとdefaultでほとんどのfacilityとlog levelが定義されていますね。

ちなみにCentOS7では/etc/rsyslog.confを見るとlocalのfacilityはlocal7だけ利用されています。

 

結論として、rsyslog.confに記載されているログは全てomsagentによって対象のstorage accountへrawdataを飛ばす設定になっている、という点ですね。

 

ではOMSポータルのログ検索から該当のrsyslogで飛ばしたログが見えるか確認してみましょう。

 

f:id:akazure:20170605151243j:plain

 

検索フィールドに「* (Type=Perf)」とすると、storage acccountに入ったログが全て一覧出力することができます。ちゃんと飛んできているようですね。

 

ちょっとstorage account内ではどのように管理されているか覗いてみましょう。

f:id:akazure:20170605151517j:plain

 

 storage accountの中身を確認するのなら、azure storage explorerというツールを使うと便利です。(for Windows)

フリーのダウンロードは以下からできます。

Microsoft Azure Storage Explorer

 

rsyslogのログはstorage accountの「tables」で管理されていることがわかります。

 

ちなみにちょっと横道にそれますが、起動しているprocessのCPU消費率が高い順、なんかも以下のように見えました。

 

f:id:akazure:20170605152009j:plain

 

CentOS7のOS内で見たものが以下です。

f:id:akazure:20170605152111j:plain

 

特に何も処理されていないからだと思いますが、python(omsagent)やsystemdなんかがtopの上位に来ていますので、Log Analytics側もちゃんと拾えているな、という所感です。

 

では早速、特定の文字列をrsyslogに飛ばしてLog Analytics側の対象に入るかを確認してみましょう。

 

f:id:akazure:20170605152433j:plain

 

loggerコマンドを使ってlocal7のfacilityにerrorレベルでログ出力させてみました。

OS内ではちゃんと出力されていることが確認できます。

 

Log Analytics側ではどうでしょうか。

 

f:id:akazure:20170605152618j:plain

 

10秒~15秒ほど待つとちゃんと引っかかってくれましたね。

つまりCentOS内のアプリがrsyslogへのログ出力を設定すれば、storage account内に連動しLog Analytics側でもログ検索として拾える、ということがわかります。

 

では最後にこのsample messageという特定の文字列を検知したらアラートメールを飛ばす設定を入れましょう。

 

上記画面ショット(sample messageがHITされている画面)の左上に「アラート」と記載されている個所を押下します。

f:id:akazure:20170605152957j:plain

 

 設定はこんな感じに入れてみました。

15分間隔で「sample message」というキーワードのログがないかをチェックし、チェックしたら記載したメールアドレスへアラートメールを飛ばします。

また、1度検知した後、1時間は多重検知してもメールは飛ばさない、という設定も入れています。

今回設定は入れていませんが、webhook、runbookの指定個所もあるので、特定のメッセージを検知したらwebhookのhttp要求を実行してrunbookを走らせる、みたいなこともできそうですね。一次対応としてVM再起動する、とか簡単にできそうです。

 

もう一度loggerコマンドでCentOS内でログを出してみましょう。

f:id:akazure:20170605153331j:plain

 

はい、先ほどの1行だけでなく2行目が出てきており、ちゃんと拾えているようです。

 

しばらくすると以下のようなアラートメールが指定したメールアドレスに届きました。

f:id:akazure:20170605153417j:plain

 

メールのSubjectもちゃんと日本語で来ていますね。

※中身の検知時間がUTCになっているので+09:00で日本時間として把握しましょうw

 

また、1時間後にまた同様のメールが飛んできました。そう設定しましたからね。

 

念のためアラートメールのヘッダを見てみました。

 

Received: from ***************** (207.46.225.185) by SMTPi.msn.com

(207.46.200.12) with Microsoft SMTP Server (TLS) id **.3.**.2; Sun, 4 Jun

2017 19:02:03 -0700

 

SMTPi.msn.comというメールサーバーにSMTP発信されているようです。Microsoftが管理しているメールサーバーが死なない限り、ちゃんとアラートメールが飛んでくると捉えてよいでしょう。

 

アラート設定を止めたい場合は以下から操作します。

f:id:akazure:20170605153937j:plain

 

ごちゃごちゃパネルを追加したので見栄えが変ですが、「設定」を押下します。

 

f:id:akazure:20170605154023j:plain

 

先ほど登録したアラート設定が1つありますので、ここでオフすればアラートは止まります。また、鉛筆マークを押すことで中身を修正し保存することもできます。

 

 

以上ですが、いかがでしたか。

Log AnalyticsはOMSポータルではなくAzureポータルからも操作できるようになっているようですので、OMSポータルとの併用で管理しなくても今はよさげです。

また、2017年6月現在、1日分のログが500MBを超えなければ無料で本機能は利用できます。(保存日数が最大7日間の制限あり)

 

今回のように特定の文字列からアラートメールを飛ばす、といった要件を優先度高く監視システムを検討される場合は、on IaaSでzabbixやsplunkを構築してVM代と管理費を維持するよりも、はるかにお安く簡単に設定できるんだ、ということがおわかりいただけたでしょうか。

また、例えばですが、とあるマウントポイントのディスク使用量を定期的にcrontab上のshell scriptで見ておき、90%以上になればloggerでrsyslogでログを飛ばす、といった応用もできそうです。

 

zabbixやnagiosにはそれぞれの良さもありますが、それが全てではない、ということが理解いただけだけでも充分かと思います。

AzureのCentOS7.3でwrdpを使ったGUI環境を作ってみる

完全に手つかずでいましたが、そろそろ更新します。。ふぅ。

 

今回のお題はAuzre上のLinuxOSをGUIで操作できるようにしてみよう、というテーマです。CUI以外は邪道だー、コマンドラインなめんな、なんて声も軽く聞こえてきますが、まぁたまにはこういったものにも触れてみるのも面白いかなと。

 

では早速はじめますが、ゴールは以下の状態です。WindowsクライアントについているリモートデスクトップでRDP(3389/tcp)でアクセスし、CentOS内のウィンドウマネージャーを呼び出した、という状態です。

 

f:id:akazure:20170316160843j:plain

 

●事前準備

 CentOS 7.3を1台、Azure環境で用意してください。

 特に特別な設定は不要ですが、NetworkSecurityGroup(NSG)のみ、3389/tcp

 ポートを受け付ける設定(受信セキュリティ規則)を入れておいてください。

 接続元であるWindowsクライアントのIPアドレスが固定の場合や、NATされた

 アドレス帯として接続元が絞れる場合はNSGの設定で接続元を絞ると、より

 セキュアかと思います。(ここではAnyにしています)

 

●注意事項

 ディストリビューションが異なる環境や、バージョンが異なる場合はうまく動か

 ない可能性があります。都度構築環境に合わせてググって補足してください。

 RHELのBuggillaにもいくつか投稿されていますので結構闇に入る場合も多いです。

 

●開始

 0)以下の手順は全てrootで実施します。

 

sudo su -

 

 1)必要RPMの準備

   ※epel-releaseのrpm名はOSのバージョンによってURLが異なります。

 

rpm -Uvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm

 

 2)xrdp、tigervnc-server、GNOME Desktopグループ全てのインストール

   ※GNOME Desktopのインストールに20分ぐらい時間かかります。

yum install -y xrdp tigervnc-server
yum -y groupinstall "GNOME Desktop" 

 3)xrdpとxrdp-sesmanのSELinux ラベル付け

   ※ここが抜けるとsystemctl start xrdpが失敗するので注意。

 

chcon -t bin_t /usr/sbin/xrdp
chcon -t bin_t /usr/sbin/xrdp-sesman

 

 4)xrdpの日本語設定

   ※やってもやらなくてよいです。お好みで。

cd /etc/xrdp
wget http://www.mail-archive.com/xrdp-devel@lists.sourceforge.net/msg00263/km-e0010411.ini

cp km-e0010411.ini km-0411.ini
cp km-e0010411.ini km-e0200411.ini
cp km-e0010411.ini km-e0210411.ini
vi startwm.sh
 以下の場所に1行追加
 #. /etc/environment
 #export PATH=$PATH
 #export LANG=$LANG
 export LANG=ja_JP.UTF-8 

  5)xrdpの設定

vi /etc/xrdp/xrdp.ini 

 

色を24bitに変更(defaultの32bitだと接続できない場合がある模様)
以下の行を32から24へ変更
max_bpp=24

 

さらに以下の場所に8行を追加
;
; Session types
;

 

[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=ask5910
xserverbpp=24

  6)xrdpの起動

   ※バージョンによってはservie xrdp.servie startですが、以下は7.x系の手順

systemctl start xrdp.service 

  7)LISTENポートの確認

   ※以下2つのポートがLISTENしていること

 3389 1088/xrdp
 3350 1087/xrdp-sesman 

  8)xrdpの自動起動設定

systemctl enable xrdp.service 

  9)firewalldの起動、自動起動とxrdpの許可設定

   ※iptablesでも可。要は3389ポートを受けつける設定を入れる場所です。

systemctl status firewalld
systemctl start firewalld
systemctl enable firewalld
firewall-cmd --list-all
firewall-cmd --list-services --zone=public
firewall-cmd --add-port=3389/tcp --zone=public  --permanent
firewall-cmd --reload
firewall-cmd --list-ports --zone=public 

 10)サーバー再起動

   Azureポータルから再起動でもshutdown -r nowでもどちらでも可。

11)vncの設定

vncpasswd
 ※2回 rootのパスワードと合わせる
vncserver :10
 ※5910ポートでxrdpからvncアクセスする
 ※間違えた場合は「vncserver -kill :10」でプロセスを落とす
netstat -atuanp
(以下のポートがLISTENしていることを確認)
 5910 1520/Xvnc 

 12)vnc起動時のウィンドウマネージャを設定

vi /root/.vnc/xstartup 

    以下の内容に差し替え

#!/bin/sh

#unset SESSION_MANAGER
#unset DBUS_SESSION_BUS_ADDRESS
#exec /etc/X11/xinit/xinitrc

# Uncomment the following two lines for normal desktop:

unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
startx &

 

13)rootパスワードの設定

 

sudo su -
passwd
  ※2回

 

13)Windowsクライアントから接続

   Windows10 Aniversaryから、接続先はCentOSにターミナルログインする

   際に使ったPublic-IPのIPアドレスを指定してリモートデスクトップアクセス

   します。IP直打ちなのでセキュリティが、、的なポップアップは無視して

   継続します。

 

f:id:akazure:20170316164329j:plain

 

f:id:akazure:20170316164439j:plain

 

以下を選択・入力してOKします。

 Session  sesman-Xvnc
 username  root
 password  rootのパスワード
 port     5910 

 

画面が表示され、言語設定の画面になればOKです。

 

補足:

この手順はまだ不完全な面もあります。

vncserverを固定で5910で起動させていますが、wrdpから呼び出されるポートに

合わせてvncserverを呼び出す方法が見当たりませんでした。ご存じの方が

いらっしゃればレスいただければと。

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-APIcurlで直接叩けないんかな」ということを少し紹介します。

 

まず押さえておくサイトとしては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>

 

既にAWSAPIを利用したことがある方はピンとくると思いますが、間違いなく「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をクリックし、「アプリの登録」から「追加」でアプリを登録します。

 

f:id:akazure:20161222115805j:plain

 

アプリ名はなんでもよいです。WEBアプリ/APIを選択し、サインオンURLもhttp://localhostと適当に入れておきましょう。

 

f:id:akazure:20161222120425j:plain

 

作成したアプリの表示名(アプリ名)とアプリケーションIDをどこかにメモしておきましょう。後で使います。(画面の赤丸でかこった部分)

 

次に作成したアプリの「キー」から、適当な名前のキー名と有効期限を設定します。1年か2年か無期限っとオトコな設定ですがとりあえず無期限で。

 

f:id:akazure:20161222121529j:plain

 

保存するとキーIDが表示されますので、それを同じくメモっておきます。

ちなみにキーIDは保存した時に出力されるだけで、以降は取得できなくなる機密性の高いモノになりますので、ここで確実にメモっておく必要がありそうです。 

 

最後にAADのディレクトリIDを持ってきます。

f:id:akazure:20161222145655j:plain

 

このディレクトリID(テナントIDとも呼ばれている!?)もメモっておきます。

ここまでがAADの操作です。

 

次に先ほど作成したAADのアプリを、どこかのリソースに権限を付与して紐づけなければいけません。ここではリソースグループに紐づけてみます。(単一VMにも紐づけ可能です)

 

f:id:akazure:20161222122310j:plain

 

適用したいリソースグループから 「アクセス制御IAM}を選び「追加」から、どの役割(ロールですよね)を追加するかを選びます。いろんなAPIを触りたいので共同作成者にしておきましょう。(VMの操作だけなら、仮想マシン作成協力者がよいと思います)

 

次は「ユーザーの追加」にて先ほどAADに作ったアプリ名を検索して選択しましょう。最後にOKボタンをクリックしてポータルからの操作は終わりです。

 

ではオアシスCentOSCUIに戻ります。

 

以下の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)が手に入ります。

f:id:akazure:20161222151356j:plain

 

とても長いトークンですが、最後にこれをメモっておきます。

 

では簡単な例として、冒頭で紹介したAzure REST API referenceに戻り、Conpute->Virutual MachinesのページにあるRestartを見てみましょう。

 

f:id:akazure:20161222151822j:plain

 

仮想マシンを再起動するリクエストフォーマットが書かれていますね。

 

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すると再起動されたことがわかると思います。

 

こんな具合でCUIからAzureのREST APIを叩いていくとおもしろい発見があるかもしれませんね。

ARM template 大量のNSG/ルールをCSVから一括登録する

今回は(NSG)Network Security GroupのARM templateに関する記事です。

 

NSGMicrosoft Azureが提供するファイアウォールちっくなサービスです。

基本仕様はとりあえずおいておいて、ポイントとなる以下の点をまず押さえておきましょう。

 

 

NSGの適用対象

 サブネットかNiCのどちらかになります。

 vNETに対して適用はできませんので注意してください。

〇Quota(制限)

 NSG名は1サブスクリプション内のリージョン毎に100個が上限

 1個のNSG内は200個のルールが適用可能

 ※足らない場合はSR(Support Requestを上げてSubscription Idを伝えることで

  上記個数の倍の制限値上げることができるようです。

 

 

さて、このようなNSGですが1つ2つぐらいならAzure Portalから手作業でやることも苦にはなりません。でも一括で100個も500個も必要になってくるとそういうわけにはいかなくなります。

 

お試しやPoCならよいですが、エンタープライズなお客様は既にオンプレで秘伝のタレ的なFW定義といったひな型があると思いますので、その規模のものをどうやって効率よくAzureへ適用し管理できるか、というのが課題になります。

 

また、多くの方々は100個以上のNSGを登録する際に、パラメータシート(大抵Excel)で管理されていると思いますので、CSV形式に落とし込んでからPowerShellやAzure CLIを使って1行ずつ読み込んで対応することが一般的かと思います。

 

ここではARM templateを使った「あえて違うやり方」を紹介します。コマンドレットやコマンドラインから1つずつ実行(おそらく再帰的に処理される)することと何が違うのか、そこを最後に記載したいと思います。

 

ではARM templateで行うやり方について記載します。

 

〇必要な環境

 CentOS 7.2の仮想マシンでAzure CLIがインストール済であること。

 ない場合はこのブログの前の記事を見て作成してみてください。

 

〇用意するもの

 1)インプットファイルとなるCSV形式のファイル

 2)JSONテンプレートへ整形するスクリプト

 

 ⇒ インプットファイルのひな型とスクリプトは以下からwget/curl等でダウンロード

  してください。

 ・インプットファイルのひな型

https://raw.githubusercontent.com/akkoike/ARMtemplate/master/parts/NSG-NetworkSecurityGroup/input.csv

 

 ・jsonファイルを生成するスクリプト

https://raw.githubusercontent.com/akkoike/ARMtemplate/master/parts/NSG-NetworkSecurityGroup/makeNSGjson.sh

 

〇事前準備

 上記インプットファイルのサンプル記載を参考に100行でも200行でも適用したい

 数だけ自社用・自分用に全て埋めましょう。 

 

〇開始

事前準備が終わった後の確認画面です。(azureコマンドを打てる状態で)

 

f:id:akazure:20161219172204j:plain

 

more input.csvで中身を確認してみてください。

※項目と順序、記載文字列が合っていれば、先ほど記載してもらったエクセル

 ファイルを上記形式を変えずにCSVへエクスポートし、Linux側へSCPして

 ください。

 

次にmakeNSGjson.shをvi/vimで開きます。

下にあるように作業するPATHを自分のローカルパスに変更してwqしてください。

⇒BASE_DIR_PATHの場所を自分の環境に合わせて修正

 

f:id:akazure:20161219173323j:plain

 

ではコマンドを実行します。

 

sh makeNSGjson.sh ./input.csv ./output.json

 

特にエラーもなく終われば、実行したその配下にoutput.jsonというファイルが1つ作成されています。

中身を見るとわかりますが、CSV形式をNSGのARM template用に変換かけたJSONファイルとなっています。

 

f:id:akazure:20161219173630j:plain

 

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をかけてみます。

 

azure group template validate many-nsg-rg -f ./output.json

f:id:akazure:20161219174538j:plain

 

ちゃんとOKって返ってきていますが、このvalidateion、過度の期待は禁物です。。

デプロイしてPortalから確認してみましょう。

 

azure group deployment create many-nsg-rg -f ./output.json

 

info:でRunningからSucceedがバラバラ出てきたと思います。

Runningは既存リソースと確認してプロビジョニング対象を探しているようですね。また、Succeedの部分は既にポータルで部分的にデプロイが確認できていることから、デプロイステータスを指しているようです。

 

こんな画面で終わっていれば成功です。

f:id:akazure:20161219175022j:plain

 

ではポータルで確認してみましょう。

f:id:akazure:20161219193601j:plain

 

ちゃんと作成されていますね。

 

ではもう1つ。

test-nsgの宛先アドレスをJSONファイル内を変更して、再度テンプレートデプロイしました。引数を指定しないデプロイは全て増分デプロイになります。

 

f:id:akazure:20161219193902j:plain

 

はい、既存のリソースはそのままで、修正した部分だけがプロビジョニングされていることがわかりました。

 

以上がテンプレートからNSGを一括登録するやり方です。 

 

既にお気づきの方もいるかもしれませんが、コマンドラインやコマンドレットから操作するやり方と比べて、結果は同じだと思います。注目したいのはその管理の主体と履歴です。

 

shellでもpowershellでもperlでもjavaでもC#でも、実行した時のプログラムやログ等は保管・バージョン管理されていると思いますが、その時にどの定義を当てはめて、現状との差異を追うのは大変です。結局今回の例でいうExcelCSVで管理する、というやり方が徹底されてしまいます。つまり人が安易に触れる媒体が管理の主体になる、ということはミスが起きやすくなるということです。

 

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の実物は以下です。

 

github.com

 

 

上記のテンプレートを任意なResource Groupにテンプレートデプロイすると以下が作成されます。

仮想マシン: CentOS 7.2が1台

ログインユーザー: azure01

SSHkey形式:RSA形式

パブリックIPアドレス: Static設定で1つ

仮想ネットワーク: 172.10.0.0/16を1つ

サブネット; 172.10.1.0/24を1つ

ストレージアカウント: 1つ

ストレージアカウント冗長方式: Standard_LRS

カスタムスクリプト:任意なshellを指定

 

CentOSを毎回試験用に1台立てるのがめんどい方、CentOSが起動した後に自分で作成したshellスクリプトをOS起動時に埋め込みたい方へのひな型としてご自由にご利用ください。デフォルト設定のままでよければ、RSA形式のssh-keyを張り付けるだけでデプロイできるようにしています。

 

以下JSONファイル内で行っている詳細です。ご参考に。

 ※変更可と選択可があります。

 

〇OS

 CentOS 

 (固定)

〇OSのバージョン

 7.2

  (デフォルト:parametersで選択可)

仮想マシンの名前

 centostest01

 (デフォルト:parametersで変更可)

仮想マシンのログインユーザ

 azure01

 (デフォルト:parametersで変更可)

SSH-key

 ★RSA形式のものをベタっと張り付けてください。

  例:「rsa-ssh AABB!=******XYZ

 (ここは入力必須)※詳細は以下で。

仮想マシンのサイズ

 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で発表した資料は以下になります。

なにそれ?なにができるの?という基本的な部分は下記を参考にしてください。

 

https://docs.com/mstechsummit16/fe2736ac-b53b-47f4-a4cd-f57096aad25a/dep001-infrastructure-as-code-linux-azure

 

ここでは実践的な利用説明をしていきます。

まず以下のGithubをご覧ください。

 

 

 

今後deploy確認が取れたものを順次上げていく&ここで日本語の説明をしていくつもりです。commitは随時やってるのでupdate日時を参考に適当にご利用ください。

 

README.txtにも記載していますが、ディレクトリ構成は以下としています。

 

- HowToUseOnCentOS

  CentOS7.2にAzure-CLiをインストールしてTemplateデプロイやエクスポートなど

 操作する際のあんちょこメモを記載しています。

 Azure Portalからの操作に不慣れな方やVisual Studio Codeよりvimだよね、という

 方はこちらをご参考に。

 

- README.txt

 このGithubディレクトリ構成を記載しています。

 肝心の部分だけを言うとparts配下がAzureサービス単体でデプロイするひな型を

 用意しています。customize配下がAzureサービスを複合的に利用してデプロイ

 するものを用意します。

 

では実践編にうつります。

 

■storageaccount.json

 〇場所:

  parts/storageaccount.json

 〇概要:

  単一storageaccountを1つ作成するテンプレートです。

 〇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で、

  といった利用はできません。希望があれば作りますが。

 

今回紹介するテンプレートは上記2つだけですが、記載時・修正時にハマること

を避けるため、2つほどポイントを記載します。

 

1:api versionと利用できるtype。

  あれ?記事に記載されているものをコピペしたけどデプロイできない、とか

  ハマるケースが多いです。それもそのはずで、account typeなどは指定できる

  値がapi versionによって動作しないものもあるからです。

  簡単に言えば利用するバージョンのAPIで対応されていない指定方法はエラー

  になる、です。なので以下のAPIバージョンと記載方法のひな型を参考に組み

  立てましょう。

 

2、関数について。

JSONファイルの容量制限は1MB以内とあります。

※.parametersファイルは64KB以内。

 

全てべた書きで記載するのもありですが、効率よく記載することで容量の壁に

当たらない&修正範囲を少なくするといった「かしこい」書き方は少しずつ覚えて

いきましょう。参考とするサイトは以下です。

 

 

はい、すみません、英語なのと全て覚えるのかおい!という状況になってしまう

ので、その中でもよく利用される関数について以下補足します。

 

  concat

  ⇒ 文字列を連結します。()内にある「,」カンマ区切りのものを

    連結させます。

    例:concat("テンプレート","は","便利ですね") みたいな感じで

      つかります。

  parameters('')

  ⇒ parameters('変数名') として、指定された値を呼び出してます。

    上のconcatと繋げてconcat(parameters('変数名'),"便利ですね")みたいに

    毎回固定の文字列を記載せずに記載するやり方が一般的、というか

    コードを修正する際に修正範囲を少なくするやり方です。

    同じようにvaliables('変数名')といった利用もできます。

  resourceGroup().ほげほげ

  ⇒ ここではresourceGroup().locationを使っています。

    resourceGroupの関数を呼び出して、locationの値を取ってきています。

    東日本リージョンの場合はjapaneastという文字列と同義です。

  copyindexとcopy

  ⇒ この2つはセットで覚えます。よく使う記載パターンはresourcesの中で

    nameの中にcopyindex()をconcatで文字列連結させ、copy関数の中で

    countの数を指定し、作成する個数を指定するやり方です。

    for文のように{}内で記載した部分だけをループさせる、といった記載

    方法ではないため、とっつきづらいですが、1つのパターンを覚えて

    あとは流用・展開すれば勝手はわかると思います。

 

長くなったので、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 あえて手を出さないであろう領域について例をあげて紹介をします。RHELCentOSJava/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と

呼ばれるものを作成しましょう。

 

f:id:akazure:20160816150135j:plain

 

 

ストレージアカウントが必要になりますが、ストリーミングのデータは複数個用意されますので、ここでは新規にストレージアカウントを作成して分けて管理します。冗長はLRSで用意しました。

 

メディアサービスアカウントとストレージアカウントの準備ができれば、リソースグループから今回用意したmediatest-rgをクリックします。右にメニュが流れきますが「ライブストリーミング」と記載されている項目をクリックし、新規でチャネルを作成します。

f:id:akazure:20160816151103j:plain

 

ライブストリーミングやチャネルという言葉が出てきたので補足します。

AMSは2つの利用形態があり、ライブストリーミングとVideo on Demand(VoD)があります。ライブストリーミングはその名の通り映像を取ると共にそのままストリームで動画を公開する時に使います。VoDはmpeg4やwmvなどの動画ファイルが事前に用意し、動画ファイルをAMSにアップロードして動画を公開する用途で利用します。次にチャネル(channel)ですが、今回試すライブストリーミングでは必要なものになります。チャネルはテレビでいうチャンネルに該当します。4チャンネルや8チャンネルなど、チャネルを用意することで1つのチャンネルができる、と考えるとしっくりします。(今回触れませんが、チャネルの中でprogramという名前の機能を用意する場合があります。programは番組表です。テレビでいう4チャンネルには朝09:00-10:00まで○○な番組を流す、という概念がありますが、ここでも同じです。チャネル内にprogramを用意することで、チャンネルと番組表を管理する、っと覚えるとよいでしょう)

 

上の画像ではチャネルが既に「実行中」になっています。チャネルは割り当て解除の停止になっていないと常に課金され続けますので注意が必要です。また、「取り込みURL」と記載されている個所に今回用意したチャネルの取り込みURLが新規で払い出されています。

 

rtmp://aklivechannel001-akmediatest001.channel.mediaservices.windows.net:1935/live/1d4371b723914732824eaaabebeead58

 

このURLが、AMS側で今回用意したチャネルの「ストリーミングを取り込むURL」になります。このURLへクライアントからRTMP通信して動画を流すことで、用意したチャネルへ動画が入っていきます。

チャネル名の行をクリックすると、より詳細な設定情報が見れますが、取り込みURLにはプライマリとセカンダリの2つのURLが払い出されます。これは大型のビデオカメラを想像してほしいのですが、1台のハードウェアが故障しても2台目のハードウェアで冗長する必要も出てくるためプライマリとセカンダリと別れています。今回のお試しライブでは特に気にする必要はありません。

 

次にストリーミングユニットの設定をしておきます。

 

f:id:akazure:20160817104316j:plain

上記画像の下にあるバーがデフォルトでは0になっていますので、1に設定します。

ストリーミングユニットとは、専用の送信容量を 200 Mbps 単位で購入できるほか、ダイナミックパッケージングと呼ばれる追加機能が利用できるようになります。ダイナミックパッケージングは、ライブで流している動画を設定した時間分VoDとして自動的にAMS側に動画コンテンツとして保管してくれ、様々なエンコード方式でマルチデバイスで再生できる状態にしてくれる、というとてもうれしい機能です。

 

Azureポータルでは最後にライブイベントの作成を行います。

f:id:akazure:20160817110434j:plain

チャネル名が表示されている行をクリックし、「ライブイベント」をクリックします。名前は適当につけてあげてください。

アーカイブウィンドウの個所はデフォルト8時間となっていますが、今回のお試しでは5分と設定しました。つまりライブで流している動画を5分間だけVoDとしてアーカイブしておく、という意味になります。このVoDファイルの暗号化はDRMにしてみましょう。Microsoftが提供する暗号化技術ですね。最後にOKボタンを押してライブイベントの作成が始まります。

 

 では次にクライアントの準備に入ります。今回利用するクライアントはTelestream社が提供するwirecastです。

 

http://www.telestream.net/wirecast/overview.htm

 

上記サイトにあるDownload Free Trialから無料版をダウンロードしてインストールします。(Windows OSへインストールします)

 

Wirecastを起動し、クライアント側の設定をします。

f:id:akazure:20160816163514j:plain

 

左下に小さな窓が縦にいくつかありますが、左下の1番上のモニターの右にある「+」をクリックし、ビデオカメラっぽいアイコンから「integrated camera ショットの追加」をします。そうするとモニターの右側にPCの小型カメラから映っている映像が出てきますのでその画面をクリックし、真ん中にある大きなモニターの左側に表示させます。表示されたら2画面ある大型モニターの真下にある「→」ボタンをクリックし、右側のモニターに左側と同じ映像を表示させます。

 

f:id:akazure:20160817094005j:plain

 

上記のような状態になっていればOKです。

上記画面の左上に「ストリーム」というボタンを押します。出力先をプルダウンで指定するポップアップが出てきますので、プルダウンメニューから「Azure Media Service」を選択します。

 

f:id:akazure:20160817100213j:plain

 

上記画面では「アドレス」の個所に適当なURLが入っていますが、こちらを先ほど取得した「取り込みURL」に上書きしてOKボタンを押します。つまりWireCastで撮影した動画はAzure Media Serviceの取り込みURLへ送る、という設定です。エンコードの個所は任意で変更できます。希望ビットレートを設定したりエンコード方式や解像度を変更することもできるようです。今回はデフォルトのH.264 720p(プログレッシブ)で送信します。

 

OKボタンを押すとモニター画面に戻りますが、上記は設定完了のOKですので、もう一度左上にある「ストリーム」ボタンを押します。ストリームボタンのボタン枠が赤くなっていれば動画をAMSへストリーム配信している、という状態を表します。

 

ではAzure ポータルに戻ります。プレビューで映像が流れてきているかを確認しましょう。

f:id:akazure:20160817101153j:plain

ちゃんと流れてきていますね。1点注意ですが、プレビューはあくまでも映像が流れてきているかどうかを確認するだけにすぎません。映像がスムーズに流れているかどうかはプレビューではなく、上記画面の「再生URL」を閲覧して確認します。

※メディアの世界ではビットレートやフレームレートと呼ばれる画像をどの単位/粒度で細切れに送信するか、つまり映像がストレスなくスムーズに流れるかにこだわる領域があります。映像はつまるところ画像を順番に流し続けることで動く映像として見せているため、このビットレートやフレームレートを調整することで映像をストレスなく見せることができます。

 

では最後に上記画面の「再生URL」をコピーし、Azure Media Playerで確認してみましょう。

 

http://ampdemo.azureedge.net/azuremediaplayer.html

上記URLを開きます。

 

f:id:akazure:20160817102544j:plain

 

上記のような画面が表示されたら、右下にあるURLの個所を先ほどコピーした再生URLに上書きし、下段にある「Update Player」ボタンを押します。いかがでしょうか、ちゃんとPCカメラで撮っている映像が流れてきているでしょうか。

f:id:akazure:20160817112702j:plain

 

実際に撮影している映像とAzure Media Playerで流れて来る動画にはタイムラグがあります。(視聴者にはわかりませんが)

また、HTML5ですが、Codeのタグをクリックすることで自分の任意なサイトへHTML5の記載で張り付けることもできそうです。

 

せっかくなのでWireCastのストリームボタンを押してストリーミングを止めてみましょう。

f:id:akazure:20160817113145j:plain

 

先ほど5分で設定したライブイベントの行をクリックし、ストリーミング中と書かれたURLをコピーします。先ほど見たAzure Media PlayerのURLにコピーした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を上記のように利用するだけで、簡単に今まで避けてきた・できなかった・時間がかかったことができるようになります。便利ですので、是非お試しください。