【お試し】Azure blob storageへvNETアドレスからのみ許可する
めずらしく連続更新です。
今回はBlob storageへのアクセスを仮想ネットワーク(vNET)からのみ
接続させる、というセキュアな経路を設定する機能紹介です。
先日アナウンスされた記事は以下です。
Announcing Preview of Azure Storage Firewalls and Virtual Networks | Blog | Microsoft Azure
概要は以下の日本語サイトを見て把握しましょう。
Azure Storage ファイアウォールおよび仮想ネットワークの構成 (プレビュー) | Microsoft Docs
残念ながらこちらもまだ日本リージョン（東西）へ展開されていませんので
展開されるまで待ちましょう。むむむむ。
では早速いきましょう。以下試したリソースは米国東部リージョンです。
違いを区別するために仮想マシン作成時に作ったストレージアカウントは
今まで通りファイアウォール設定を入れていない「nonaclblob001」とし、
後で作成した「blobacl002」はファイアウォール設定を入れるストレージ
アカウントとして用意しました。
また、仮想ネットワーク（vNET）のアドレスは192.168.0.0/16とし
１つ192.168.0.0/24のサブネットを切っています。仮想マシンはそこに配してあります。
以下はblobacl002作成時にファイアウォール設定を入れる画面です。
注目すべきは下段にある仮想ネットワーク（プレビュー）の個所ですね。
既に作成済のvNETをプルダウンで選択できる状態になっています。
また、サブネットもvNET作成時に用意したものを選択します。
ですので正確にはvNET ACLというよりSubnet ACLですかね。
設定したストレージアカウントのダッシュボードは以下です。
ちゃんと設定したvNETからアクセスするように見えています。
あと、個別にIPaddressかCIDRを入れて許可させることもできそうです。
※ここ重要。この後ハマるんでｗ
さらに「信頼されたMicrosoftサービスによるこのストレージアカウント
へのアクセスを許可する」なるものにデフォルトでチェックされています。
し、、、信頼された？？と懐疑的な方はこの記事の冒頭に入れた日本語概要
のURLをもう一度読みましょう。下の方にどこからを許可してる、というのが
記載されていますので。
blobacl002が作成できたので、早速Azureポータルから見てみ。。。
はう！！
んじゃAzure Storage Explorerで覗いてみるかぁ。
あわわ！
既にお気づきの方も多いと思いますが、blob storageのファイアウォール
設定でvNETからと信頼されたMicrosoftサービスからのみアクセスを許可
していますよね。つまりAzureポータルやStorage Explorerの接続元と
なっている「あなたが」利用しているインターネットに出てるソースIP
を許可していないのでアクセスできない状態です。そりゃそうだ、な話。
ということでご自分の環境で利用しているアドレスをファイアウォール
設定で許可してあげましょう。
以下のサイトへ行くと利用しているソースIPがわかります。
他にもLinuxターミナルだと以下のコマンドでわかります。
curl inet-ip.info
さて、アドレスがわかればblob storageのファイアウォール機能を
もう一度開き、そのアドレスからの許可を入れておきます。
最後に、「本当にvNETアドレスからのみ受け付けてんだよね？」という
確認をしておきましょ。
まずストレージアカウントの「診断」をONにします。
ご自分のソースIPがわからず、ワタワタする方にはAzure CLI(2.0)では
以下のコマンドで診断設定が有効となります。
az storage logging update --log r --retention 30 --services b
※logはr(readの時）、30日分のログ保存期間、対象はb(blob)サービス、
という意味の引数です。
診断設定を入れ、storage explorerで覗くと、$logsというコンテナの下に
blob storageへのアクセスログが自動的に配置されていることがわかります。
中身を見てみましょう。
説明を端折ってますが、何度かvNET内に作成した仮想マシンから
Azure CLIでblobacl002のblobへファイルをアップロードしたりリスト
出力したりしています。もちろんスマホからも覗こうと何度か試してます。
うむ、ちゃんとvNETで切った仮想マシンのアドレス（192.168.0.4)から
受け付けたログだけが見えていますね。ステキ♪
余談ですが、このストレージアカウントへ診断機能を付けてアクセスログ
を出す仕掛けは、利用しているAPIのバージョンを確認する時にも利用
できます。APIバージョンのサポート切れ、みたいなアナウンスがあった
時に、いま自分が利用しているblob storageへアクセスしているAPI
バージョンって、なんだっけ？という時にアプリや設定ファイルを１つ
ずつ虱潰しに確認する手間は避け、この診断ログを３０日分ためて
このテキストログから利用バージョンだけをくり貫いて確認する、と
いった便利な使い方もできます。（1か月稼働しないバッチとかだと
モレるので40日保存の解析がいいですかね）
以上でっす。
【お試し】Azure Availability Zoneをいじる
ども。ちょっとLinuxネタから外れますが、Microsoft Igniteでも話題と
なった可用性ゾーン、Availability Zone(Public Preview)なるものを少し
見てみました。
はじめて触ろうとされる方の参考までにー。
以下参考となるサイトの一覧ですので、まずはどういうものか理解
しておきましょう。
まだプレビューですので、利用できるゾーンやVMサイズに制限が
あり、利用しているサブスクリプションに対して利用申請しないと
使えなさそうです。
※2017/10/16現在、残念ながら日本リージョン（東西）ではまだ利用
できないようです。むむむ。
ということで米国東部2のリージョンを使い、D1v2 Standardで軽く
CentOSを作成してみました。
まずは可用性ゾーンを利用するために以下から申請します。
自動的にAzureポータルへ遷移し、可用性ゾーンを有効とするサブスク
リプションをチェックし有効化を押します。
１５分ほどすると無効の個所が有効となりますが、１時間ほど放置して
おきましょう。
※見た目有効になってますが、いきなり使おうとしても使えなかったので。
少し時間を置いたあと、新規作成から以下を選択しました。
リージョン：米国東部 2
VMサイズ：DS1v2 Standard
OS：CentOS7.3
仮想マシン作成時の「設定」を見ると、可用性ゾーンが1,2,3と選べる
ようになっていますね。
米国東部 2のリージョンには３つのデータセンターが存在している
というのがなんとなく想像できます。あと、可用性ゾーンを選択すると
可用性セットは選べなくなります。
とりあえず１を選んでみました。
Azure ポータルのダッシュボードで作成した仮想マシンを見てみます。
可用性ゾーンと記載された項目が「１」になっているのがわかります。
折角なので、CloudShell（Azureポータル上で開くターミナル）で同じく
プレビューとなったPowerShellから設定情報を覗いてみましょ。
Bashと違って青い背景のあたりPowerShellっぽいですね、そそられ
ませんがｗ
以下のコマンドレットを叩くとゾーンが１になっていることがわかります。
Get-AzureRmPublicIpAddress -ResourceGroupName {Resource Group Name}
ちなみにbash(Azure CLi2.0)だと以下で確認できます。
az vm show -n {VM Name} --show-details --resource-group {Resource Group Name}
最後に、作成したResource GroupのARM templateをみてみます。
記載されているのはResourcesの中の３か所ですね。
Microsoft.Compute/disksの定義に１か所。（zonesのところ）
次はMicrosoft.Compute/virtualMachinesの定義。
最後にMicrosoft.Network/publicIPAddressesの定義。
可用性ゾーンをARM templateから設定することも簡単にできそうですね。
日本リージョンでの展開が楽しみですねー。日本で展開されたら
データセンターをどうやって１から２や３へ切り替えるのか、など
試したいところです。
あと、Azure LoadBalancer Standard SKUなるものも同じくプレビュー
となっていますが、このデータセンター間にまたがるバランシング機能
が拡充されています。Availability Zoneを意識したL4LBのバランシング
機能、といったところでしょうか。これも楽しみですね。
ということで今回はこの辺で。
カスタムイメージを基にスケールするVMSSと２種類のロードバランサを一括構築
ども、最近更新が、、、さぁAzureブログがんばるぞー！！
今回のテーマはVirtual Machine Scale Set！略してVMSS。
といってもVMSSをデプロイして自動スケールスゲー！！な話はするつもり
はなく、もちっと実用的なもの（？））を用意してみました。
VMSSをベースにL4LBであるALBとL7LBであるApplication Gateway
(以下AppGW)の２つを上段に構え、Inbound通信はAppGW経由、Outbound
通信はALB経由にし、VMSSの各ノードはカスタムイメージから持ってきた
nginx(CentOS7)が起動している状態のものを展開しつつ、なおかつ
AutoscalesettingsでCPU60%以上になったらVM数を増やす、50%以下
になったら1VMずつ減らす、という環境をARM templateで一括作成
しちゃえというものです。
・・・。
文章で記載するとさっぱり伝わらないですね（はぅ
どんな要件だとこれに行きつくのか、、という話をしたほうがよさげですね。
〇サーバー負荷に応じて自動でVMを増やしたいし減らしたい
〇セッションアフィニティの管理やWAFの機能も併用したい
〇外向けのOutbound通信はStaticなIPとして固定化し、受け皿側では
StaticなIPで許可設定をいれたい。
〇スケールする度に毎回WEBサーバーの構築とかだるいからヤダ
なんとなく初めてクラウドを利用される方が描く期待の構成っぽく
聞こえますが、そんなご要望に応える環境を試してみました。
とりあえずブツは以下のgithubに配置しておきました。
手っ取りばやく試したい方はこれをテンプレートデプロイで
azureにぶち込むとわかります。
ちなみにARM templateは便利ですが、中身を理解していない状態で
利用すると応用もきかずエラーが出た時にアタフタしますので
軽くポイントだけ説明しておきます。
まずparametersの個所から。
sshKeyData変数の部分はssh-rsaの文字列の後ろに半角スペースを入れた後、
公開キーの文字列をベタっと張り付けてください。
このsshKeyData変数はresourcesの個所で処理していますが、CentOSに
作成したユーザー（ここではazure01ユーザ）の/home/.ssh/ディレクトリ配下
にauthorized_keysというファイル名で格納しています。公開鍵認証する際に
照合する場所ですね。
addressPrefix = vNETのアドレスセグメント
subnetPrefix = 上記vNET配下のサブネットを１つ
appGwSubnetPrefix = application gateway用サブネット（上記vNET内）
defaultvalueでは192.168.0.0/16のvNET配下に/24を２つ指定していますが
間違えても異なるvNETアドレスセグメントの範囲をサブネットに入れない
でください。（デプロイ検証は成功しますが、デプロイ開始後にエラーに
なります）
imageNameにカスタムイメージで保管してあるresource idをベタっと
はりつけます。
defaultvalueで指定した文字列の中で'-'で括った大文字部分は利用する人
の状況に合わせて差し替えてください。
SubscriptionIDやイメージが保管されているResourceGroupやイメージ名です。
カスタムイメージの作成方法は以下がわかりやすくて良いと思います。
CentOSだとOS内のコマンド一発とAzure Portalの操作だけで完結します。
Check! Azure 仮想マシンで、Linux ベースのカスタムイメージを作成する - Qiita
また、カスタムイメージのresource idはAzure Portalの概要から文字列が確認
できますので、それをコピペすると楽ちんです。
次にvariablesです。
こちらは固定定義となる部分ですが、必要に応じてparametersへ移動して
ください。ここでは様々なコンポーネントの名前を全て固定で入れてます。
AppGWに付けるPublicIPは80port/tcpのみ許可する設定を入れてます。
InstanceCountは2にしていますので、VMSSの初期ノード数は2VMです。
こちらは変更しないでください。任意な初期台数で指定できるresourcesの
書き方にはしていませんので。（VMSSでネットワーク定義している
NiCの数は２本固定で入れてますから）
最後resourcesです。
利用しているtypeとAPI versionは以下です。
Microsoft.Network/virtualNetworks 2017-04-01
Microsoft.Network/publicIPAddresses 2017-04-01
Microsoft.Network/applicationGateways 2017-04-01
Microsoft.Network/loadBalancers 2017-04-01
Microsoft.Compute/virtualMachineScaleSets 2017-03-30
Microsoft.Insights/autoscaleSettings 2015-04-01
Public IPのみ2か所定義しています。ALB用とAppGW用の2本です。
AppGWに付けるPublic IPはDynamic（動的アドレス）しか付けられない仕様ですが
ALBに付けるPublic IPはStatic（固定アドレス）で定義しています。
これでVMSSから見たoutbound通信は固定のグローバルアドレスとします。
AppGWではフロントエンドのポートを定義し、バックエンドプール（VMSS側へ
振り分ける対象ノードを定義しています。
大丈夫ですよ、後で確認画面見せますが、３台目、4台目とスケールアウトしても
ちゃんとAppGWから振り分け対象に自動的に入りますし、sshログインも増加した
サーバーへ入ることができますから。
VMSS側では以下のようにイメージのresource idを指定します。
イメージを一般化（Generalize）する前に、systemctl enable nginx(CentOS7.x)を
しておかないとOS起動時にnginxは起動されませんので注意ください。
冒頭でも触れた公開キーの埋め込み方法です。
公開キーはAzureから発行することは現状できませんので、puttyGenなどで自作
してくださいね。
autoscalesettingsは閾値や台数のスケール管理をする部分です。
VMSSノードは最低２台、最大５台としてます。また、CPUの平均値（5分だった
かな）が60%以上続く場合は1台ずつ増加させ、50%以下平均になると1台ずつ
減少させるように記載しています。
全てのデプロイは15分程度で終わります。ちなみにARM templateは40分で
タイムアウトしますので全ての処理は40分以内に終わる処理でなければ
いけません。もちろん各コンポーネントは非同期で処理実行されるため、タイム
アウトした後はできたところまでで切り離され、ロールバックする概念は
ありません。そこんとこ厳しいある。
デプロイが終わると各リソースはこんな風に見えます。
ではVMSS側にsshログインするので、ALB(上ではLoad balancer)を開きます。
※今回はsandbox環境を用意していないので、直接ALBにつけたPublic IPから
SSHログインします。（22ではなく50000ポートでログインします）
英語表記になっちゃってますが、受信NAT規則なるタブから２台のVMのPublic IPと
ポート番号が確認できます。
TeraTermでログインしてみます。
ちゃんとnginxが起動した状態になっていますね。カスタムイメージから
展開されていることがわかります。
ちなみに省略しますが、このVMSSノードからcurlやwgetで他のグローバル
アドレスへ通信した場合、受け側のWebエンジンのaccess_logからSource IP
がALBにつけたPublic IP（static）になっていることがわかります。
これで受け側での許可フィルタリングも問題なくできます。
では次にAppGWのリソースを覗き、AppGWについたPublicIP(+ domain)を
確認します。
軽くマスクしておきましたが、このドメイン or IPアドレスをブラウザで確認
してみましょう。
はい、ちゃんとnginxの初期ページが表示されていますね。
念のためVMSSノード側の/var/log/nginx/access_logを見てみましょう。
192.168.1.11 - - [13/Sep/2017:10:52:09 +0000] "GET / HTTP/1.1" 304 0
"-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0)
like Gecko" "106.73.2.64:5436"
はい、何度かブラウザアクセスするとわかりますが、２台のどちらにも
上記ログが振り分けられて吐き出されていることがわかります。
VMSS側から見るとAppGWに付けたSubnetのプライベートアドレス
から振り分けられていることがわかりますね。
では最後に意図的にCPU負荷をかけてVMSSがスケールするか、
スケールしたノードへログインでき、AppGWから振り分けされる
状態になっているか、を確認してみましょう。
まずはVMSSの現状を見ておきます。
CPU負荷もまったくかかっていない状態ですので、初期ノード数の２台が
いることがわかります。
負荷かけてみましょう。
cd /var/tmp
wget http://ftp.tu-chemnitz.de/pub/linux/dag/redhat/el7/en/x86_64/rpmforge/RPMS/stress-1.0.2-1.el7.rf.x86_64.rpm
rpm -ivh stress-1.0.2-1.el7.rf.x86_64.rpm
stress -c 1
stressコマンドはCentOS7.xにプリインストールされていないため
盛ってきました。また、今回のVMサイズはStandard_A1でやってますので
vCPUは１つです。なのでstressコマンドの引数に -c 1を指定しています。
CPU Percentageのグラフが追い付いていませんが（笑）、ちゃんと
CPUの負荷を検知し３台目を追加しようと動き始めていますね。ステキ。
ちなみにこの状態で焦って３台目にログインしようとしてはいけません。
まだデプロイ中なのでsshログインできません。もう少し待ちましょう。
ALBの受信NAT規則を見ると３台目（どころか4台目まできてますねｗ）の
振り分け先が追加され、ポートも50003番で追加されているのがわかります。
はい、増加した３台目にログインでき、nginxが起動している状態が確認
できました。
ちゃんと/var/log/nginx/access_logをtailで見ながらブラウザでnginxの初期
画面を更新していると、振り分けられているログを確認することができ
ました。
192.168.1.7 - - [13/Sep/2017:11:27:34 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko" "106.73.2.64:62770"
以上になりますが、いかがでしょうかね。
そもそもステートレスな環境にステートフルなものを組み合わせていること
事態に違和感を覚えなくもないですが（笑）、割とエンタープライズな
お客様を相手にしていると、こういった構成じゃないと要件を満たすことが
難しい場合もあります。ご参考まで。
CentOS7からAzure FileストレージとLVMをいじる
ちょこちょこといろいろな方面から割と聞かれるため記事にしておきます。
Linuxユーザーにとってクラウドだろうがオンプレだろうが自宅のPCだろう
が、データの種別やアクセス頻度に応じてディスクレイアウトを定めるのは、
もはや常識ですよね。
今回の記事はそんなディスクレイアウトの常識をAzure上のCentOSを使って
どうレイアウトするかについて少し触れていきたいと思います。
まず前提として、Azure内でディスクと呼ばれるものがいくつかありますが
1番わかりやすいものはOSdiskとDataDiskです。
OSdiskはその名の通り仮想マシンを払い出した際にデフォで付いているOS
領域のディスクです。CentOS7.xで言うとデフォで30GB割り当てられており
/dev/sdaのデバイスで管理されています。(Azureポータルからこのディスクサイズ
を拡張することもできます：再起動が必要）
DataDiskは追加ディスク領域の部分です。１ディスクあたり最大容量4TBまで指定
でき、/dev/sdc以降のデバイスを基本領域として管理していきます。
単に追加分の１ディスクを別マウントポイントとして利用したい場合は以下の記事
を参考にしてください。（ちなみに下の記事ではfdiskを利用していますが、2TB
以上のディスクをフォーマットする際はpartedコマンドでやらないといけません）
はじめてのMicrosoft Azure（ディスクアタッチ） - LinuxユーザーがイジるはじめてのAzure
もう１つクライアントOSからのマウント、として便利そうなものがAzure File
ストレージ（Azure Files）ですね。
OS内のSMBクライアントから接続することでLinux環境でもマウントして利用
できる共有ストレージです。
ここまではおさらいというか基本情報です。やりたいのはここからもう少し
踏み込んだ部分です。
上記３つに共通することは、「１つのマウントポイント領域でAzureのディスクを
扱いたい」という点です。ワンエフエス（One File System)は開発者にとっては
楽ちんですからね。いろいろ落とし穴はありそうですが、やってみましょう。
では早速Azure Filesからやっていきましょう。
まずAzureポータルからStorage AccountのFILEサービスからエンドポイントを確認
し、「＋ファイル共有」から１つ作成しましょう。
作成したファイル共有（ここではlinuxshareという名前）をクリックし、接続を
押下するとLinux環境からマウントするコマンドサンプルが表示されます。便利！
注記にもありますが、Azure Filesは暗号化対応がまだ未対応のため、異なる
リージョン間でマウント共有することは2017年8月時点ではできません。
ちなみにこの東日本で作成したAzure Filesに対して西日本で用意した仮想マシンから
マウントしようとすると以下のエラーがでます。
大人しく東日本で作成した仮想マシンから、root権限でマウントしましょう。
また、Azureポータルで表示されているマウント方法はmountコマンドからマウント
するやり方なので、/etc/fstabには以下のように記載しました。
※パスワード部分はマスクしているので利用者の環境に合わせてください。
# /etc/fstabの追加行（１行）
//centf01stor01.file.core.windows.net/linuxshare /mnt/azurefiles cifs vers=3.0,username=centf01stor01,password
=D6v*****Ngtcq/J2s****joeFlkC13qTx/3xqlkaCWF****diseQ==,dir_mode=0777,file_mode=0777,s
ec=ntlmssp
ちなみにマウントする前に以下のSMBクライアントを入れておく必要があります。
yum install -y cifs-utils
※CentOS7.3ではデフォで入ってますね
これでmount /mnt/azurefilesとやればきれいにマウントできます。
折角なので少し大きめのファイル（2GB程度）のものを作成して配置して
みましたが、rmで削除した時に非同期的なな感じになったので共有しておきます。
見てわかる通りrmコマンドでOS側はプロンプトで返ってきてるが、Azure Files側
ではまだ削除中ステータスのように残っています。5分程放置して見てみると
綺麗になくなっていました。若干Eventually Consistencyな見え方になりますねｗ
ちなみにmvでファイル移動する際はこのような現象はおきません。
OS内のinodeが変更されるシステムコールは整合性が強いですが、Files内の
ファイルハンドリングだけだとこのような見え方になりそうですね。ま、
結果おーらい。
あとリンクファイルの扱いについても注意です。
以下はrsyncで/etc配下を/mnt/azurefilesに同期させた時の結果です。
/etc/favicon.pngをコピーする個所でエラーになっています。/etc/favicon.pngは
シンボリックリンクファイルです。
以下がAzure FilesのREST API referenceになりますが、リンクファイルに対応
するAPIが存在しないため、このようなエラーが出ています。
File Service REST API | Microsoft Docs
ラージファイルに対する非同期的な動作はまぁよいとして、リンクファイルは
そのままデータ退避・バックアップできない、という点を押さえておくと
よいと思います。もちろんrsyncのオプションに--copy-linksを付けてlink先まで
辿ってリンク元をコピーする、というやり方で回避できますが、あまり実態
ファイルは複数のPATHで持ちたくない場合もありますのでお好みで。
また、Azure Filesにファイル数制限はありませんが、全体の容量は5TBまでと
制限があります。同一リージョン内であり、5TB未満の容量でリンクファイル
は扱わない共有ストレージとしての条件であれば超絶便利ですね。
はい、Azure Filesはこのへんにしておきます。
以下は5TBの容量では足らないんじゃー、ワンエフエスにこだわりたいんじゃー
という方への参考情報です。
とりあえず5TB以上なのでDataDiskを4TBx2本、仮想マシンにアタッチしま
しょうか。
ちなみに仮想マシンのサイズ（スペック）によってアタッチできるDataDiskの
本数に制限があります。以下から「Microsoft Azure IaaS リファレンス アーキ
テクチャ ガイド」のPDFをダウンロードして、ご利用されているサイズから
アタッチ可能ディスク本数の制限を確認しておきましょう。
Microsoft Azure でシステムを構築する際に参照すべきドキュメント【3/13 更新】 – Microsoft Partner Network ブログ
今回試しているサイズはD1ですので2本です。ディスク追加はホットアタッチ
できるので仮想マシンの停止や再起動は不要で楽ですね。
はい、OS上でも/dev/sdcと/dev/sddの２つのデバイスが見えました。
ではこの２つの領域をLVMで束ねます。
（mdadmの方が若干性能はでますが、LVMでも大差はないので使い慣れた
ほうでよいと思います）
とりあえずpartedでフォーマットしましょう。
※fdiskは2TB未満のパーティションのみ作成可能なので、今回のように
2TB以上のパーティション作成にはpartedを利用します。
parted /dev/sdc
mklabel gpt
mkpart primary 0 4396000
set 1 lvm on
quit
上記は/dev/sdcですが/dev/sddも同様にやります。
次にpvcreate/vgcreate/lvcreateと続けて、１つの論理パーティション
をxfsのファイルシステムとして最大容量の設定します。
ext4でもよいですがCentOS7から標準がxfsになっていますので
それにならいます。
pvcreate /dev/sdc1 /dev/sdd1
Physical volume "/dev/sdc1" successfully created.
Physical volume "/dev/sdd1" successfully created.
vgcreate vg01 /dev/sdc1 /dev/sdd1
Volume group "vg01" successfully created
lvcreate -l 100%FREE -n lv01 vg01
Logical volume "lv01" created.
mkfs.xfs /dev/vg01/lv01
mkdir -p /mnt/lvm
mount -t xfs /dev/vg01/lv01 /mnt/lvm/
こんな感じに見えたでしょうかね。
※今回は手抜きでブロックサイズを指定しませんでしたが、これだけ容量が
大きいとちゃんと計算してブロックサイズ指定したほうがパフォーマンスは
出ると思います。
永続化は適当に/etc/fstabにUUID登録しといてください。
以上ですが、同一リージョン内の同一vNET内でのNFS接続は確認できているので
次回以降どこかの記事で別vNET間のNFSやリージョンまたぎのNFS(お薦めしま
せんがｗ）なんかを書ければと思いますー。
Log Analyticsを使いCentOS7のrsyslog経由で特定の文字列を検知しアラートメールを飛ばす
どこぞの知人から強く希望されたので記事にしておきます:)
システムの健康状態を管理するやり方として、よく監視ツールといったシステムの異常を検知してアラートを飛ばす、または検知した情報を基に一次復旧のスクリプトを流す、なんて話はよくある話ですね。
これはクラウド化したところでやりたい要件や見たい要望が大きく変わるものではないのが現状かと思います。むしろクラウドのメリットとしてスケールでカバーする世界になってくれば来るほど、ちまちまと１台ずつ管理するほうがめんどくさいぐらいです。
そこにはスケールでカバーできる規模の監視・管理サービスを追及するか、そもそも監視・管理の必要のない世界を目指すか、で分岐されそうですね。個人的には監視で夜間たたき起こされた悪夢が多い自分としては監視不要のアーキテクチャな世界を選びたいものですｗ
さて、前置きはそのあたりにしておき、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を対象とするよう設定しておきます。
Azure ポータルからLog Analyticsを開くとこんな感じに見えます。
では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のボードを開いた時に「
ここまでできれば、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で飛ばしたログが見えるか確認してみましょう。
検索フィールドに「* (Type=Perf)」とすると、storage acccountに入ったログが全て一覧出力することができます。ちゃんと飛んできているようですね。
ちょっとstorage account内ではどのように管理されているか覗いてみましょう。
storage accountの中身を確認するのなら、azure storage explorerというツールを使うと便利です。(for Windows)
フリーのダウンロードは以下からできます。
Microsoft Azure Storage Explorer
rsyslogのログはstorage accountの「tables」で管理されていることがわかります。
ちなみにちょっと横道にそれますが、起動しているprocessのCPU消費率が高い順、なんかも以下のように見えました。
CentOS7のOS内で見たものが以下です。
特に何も処理されていないからだと思いますが、python(omsagent)やsystemdなんかがtopの上位に来ていますので、Log Analytics側もちゃんと拾えているな、という所感です。
では早速、特定の文字列をrsyslogに飛ばしてLog Analytics側の対象に入るかを確認してみましょう。
loggerコマンドを使ってlocal7のfacilityにerrorレベルでログ出力させてみました。
OS内ではちゃんと出力されていることが確認できます。
Log Analytics側ではどうでしょうか。
10秒～15秒ほど待つとちゃんと引っかかってくれましたね。
つまりCentOS内のアプリがrsyslogへのログ出力を設定すれば、storage account内に連動しLog Analytics側でもログ検索として拾える、ということがわかります。
では最後にこのsample messageという特定の文字列を検知したらアラートメールを飛ばす設定を入れましょう。
上記画面ショット（sample messageがHITされている画面）の左上に「アラート」と記載されている個所を押下します。
設定はこんな感じに入れてみました。
15分間隔で「sample message」というキーワードのログがないかをチェックし、チェックしたら記載したメールアドレスへアラートメールを飛ばします。
また、1度検知した後、１時間は多重検知してもメールは飛ばさない、という設定も入れています。
今回設定は入れていませんが、webhook、runbookの指定個所もあるので、特定のメッセージを検知したらwebhookのhttp要求を実行してrunbookを走らせる、みたいなこともできそうですね。一次対応としてVM再起動する、とか簡単にできそうです。
もう一度loggerコマンドでCentOS内でログを出してみましょう。
はい、先ほどの1行だけでなく2行目が出てきており、ちゃんと拾えているようです。
しばらくすると以下のようなアラートメールが指定したメールアドレスに届きました。
メールのSubjectもちゃんと日本語で来ていますね。
※中身の検知時間がUTCになっているので+09:00で日本時間として把握しましょうｗ
また、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が管理しているメールサーバーが死なない限り、ちゃんとアラートメールが飛んでくると捉えてよいでしょう。
アラート設定を止めたい場合は以下から操作します。
ごちゃごちゃパネルを追加したので見栄えが変ですが、「設定」を押下します。
先ほど登録したアラート設定が１つありますので、ここでオフすればアラートは止まります。また、鉛筆マークを押すことで中身を修正し保存することもできます。
以上ですが、いかがでしたか。
Log AnalyticsはOMSポータルではなくAzureポータルからも操作できるようになっているようですので、OMSポータルとの併用で管理しなくても今はよさげです。
また、2017年6月現在、１日分のログが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内のウィンドウマネージャーを呼び出した、という状態です。
●事前準備
CentOS 7.3を1台、Azure環境で用意してください。
特に特別な設定は不要ですが、NetworkSecurityGroup(NSG)のみ、3389/tcpの
ポートを受け付ける設定（受信セキュリティ規則）を入れておいてください。
接続元であるWindowsクライアントのIPアドレスが固定の場合や、NATされた
アドレス帯として接続元が絞れる場合はNSGの設定で接続元を絞ると、より
セキュアかと思います。（ここではAnyにしています）
●注意事項
ディストリビューションが異なる環境や、バージョンが異なる場合はうまく動か
ない可能性があります。都度構築環境に合わせてググって補足してください。
RHELのBuggillaにもいくつか投稿されていますので結構闇に入る場合も多いです。
●開始
０）以下の手順は全てrootで実施します。
sudo su -
１）必要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
２）xrdp、tigervnc-server、GNOME Desktopグループ全てのインストール
※GNOME Desktopのインストールに２０分ぐらい時間かかります。
yum install -y xrdp tigervnc-server
yum -y groupinstall "GNOME Desktop"
３）xrdpとxrdp-sesmanのSELinux ラベル付け
※ここが抜けるとsystemctl start xrdpが失敗するので注意。
chcon -t bin_t /usr/sbin/xrdp
chcon -t bin_t /usr/sbin/xrdp-sesman
４）xrdpの日本語設定
※やってもやらなくてよいです。お好みで。
cd /etc/xrdp
wget http://www.mail-archive.com/xrdp-devel@lists.sourceforge.net/msg00263/km-e0010411.inicp km-e0010411.ini km-0411.ini
cp km-e0010411.ini km-e0200411.ini
cp km-e0010411.ini km-e0210411.ini
vi startwm.sh
以下の場所に１行追加
#. /etc/environment
#export PATH=$PATH
#export LANG=$LANG
export LANG=ja_JP.UTF-8
５）xrdpの設定
vi /etc/xrdp/xrdp.ini
色を24bitに変更（defaultの32bitだと接続できない場合がある模様）
以下の行を32から24へ変更
max_bpp=24
さらに以下の場所に８行を追加
;
; Session types
;
[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=ask5910
xserverbpp=24
６）xrdpの起動
※バージョンによってはservie xrdp.servie startですが、以下は7.x系の手順
systemctl start xrdp.service
７）LISTENポートの確認
※以下２つのポートがLISTENしていること
3389 1088/xrdp
3350 1087/xrdp-sesman
８）xrdpの自動起動設定
systemctl enable xrdp.service
９）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
１０）サーバー再起動
Azureポータルから再起動でもshutdown -r nowでもどちらでも可。
１１）vncの設定
vncpasswd
※2回 rootのパスワードと合わせる
vncserver :10
※5910ポートでxrdpからvncアクセスする
※間違えた場合は「vncserver -kill :10」でプロセスを落とす
netstat -atuanp
（以下のポートがLISTENしていることを確認）
5910 1520/Xvnc
１２）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 &
１３）rootパスワードの設定
sudo su -
passwd
※2回
１３）Windowsクライアントから接続
Windows10 Aniversaryから、接続先はCentOSにターミナルログインする
際に使ったPublic-IPのIPアドレスを指定してリモートデスクトップアクセス
します。IP直打ちなのでセキュリティが、、的なポップアップは無視して
継続します。
以下を選択・入力してOKします。
Session sesman-Xvnc
username root
password rootのパスワード
port 5910
画面が表示され、言語設定の画面になればＯＫです。
補足：
この手順はまだ不完全な面もあります。
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-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すると再起動されたことがわかると思います。
