カスタムイメージを基にスケールするVMSSと2種類のロードバランサを一括構築
ども、最近更新が、、、さぁAzureブログがんばるぞー!!
今回のテーマはVirtual Machine Scale Set!略してVMSS。
といってもVMSSをデプロイして自動スケールスゲー!!な話はするつもり
はなく、もちっと実用的なもの(?))を用意してみました。
VMSSをベースにL4LBであるALBとL7LBであるApplication Gateway
(以下AppGW)の2つを上段に構え、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配下のサブネットを1つ
appGwSubnetPrefix = application gateway用サブネット(上記vNET内)
defaultvalueでは192.168.0.0/16のvNET配下に/24を2つ指定していますが
間違えても異なる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の数は2本固定で入れてますから)
最後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側へ
振り分ける対象ノードを定義しています。
大丈夫ですよ、後で確認画面見せますが、3台目、4台目とスケールアウトしても
ちゃんとAppGWから振り分け対象に自動的に入りますし、sshログインも増加した
サーバーへ入ることができますから。
VMSS側では以下のようにイメージのresource idを指定します。
イメージを一般化(Generalize)する前に、systemctl enable nginx(CentOS7.x)を
しておかないとOS起動時にnginxは起動されませんので注意ください。
冒頭でも触れた公開キーの埋め込み方法です。
公開キーはAzureから発行することは現状できませんので、puttyGenなどで自作
してくださいね。
autoscalesettingsは閾値や台数のスケール管理をする部分です。
VMSSノードは最低2台、最大5台としてます。また、CPUの平均値(5分だった
かな)が60%以上続く場合は1台ずつ増加させ、50%以下平均になると1台ずつ
減少させるように記載しています。
全てのデプロイは15分程度で終わります。ちなみにARM templateは40分で
タイムアウトしますので全ての処理は40分以内に終わる処理でなければ
いけません。もちろん各コンポーネントは非同期で処理実行されるため、タイム
アウトした後はできたところまでで切り離され、ロールバックする概念は
ありません。そこんとこ厳しいある。
デプロイが終わると各リソースはこんな風に見えます。
ではVMSS側にsshログインするので、ALB(上ではLoad balancer)を開きます。
※今回はsandbox環境を用意していないので、直接ALBにつけたPublic IPから
SSHログインします。(22ではなく50000ポートでログインします)
英語表記になっちゃってますが、受信NAT規則なるタブから2台の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"
はい、何度かブラウザアクセスするとわかりますが、2台のどちらにも
上記ログが振り分けられて吐き出されていることがわかります。
VMSS側から見るとAppGWに付けたSubnetのプライベートアドレス
から振り分けられていることがわかりますね。
では最後に意図的にCPU負荷をかけてVMSSがスケールするか、
スケールしたノードへログインでき、AppGWから振り分けされる
状態になっているか、を確認してみましょう。
まずはVMSSの現状を見ておきます。
CPU負荷もまったくかかっていない状態ですので、初期ノード数の2台が
いることがわかります。
負荷かけてみましょう。
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は1つです。なのでstressコマンドの引数に -c 1を指定しています。
CPU Percentageのグラフが追い付いていませんが(笑)、ちゃんと
CPUの負荷を検知し3台目を追加しようと動き始めていますね。ステキ。
ちなみにこの状態で焦って3台目にログインしようとしてはいけません。
まだデプロイ中なのでsshログインできません。もう少し待ちましょう。
ALBの受信NAT規則を見ると3台目(どころか4台目まできてますねw)の
振り分け先が追加され、ポートも50003番で追加されているのがわかります。
はい、増加した3台目にログインでき、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は追加ディスク領域の部分です。1ディスクあたり最大容量4TBまで指定
でき、/dev/sdc以降のデバイスを基本領域として管理していきます。
単に追加分の1ディスクを別マウントポイントとして利用したい場合は以下の記事
を参考にしてください。(ちなみに下の記事ではfdiskを利用していますが、2TB
以上のディスクをフォーマットする際はpartedコマンドでやらないといけません)
はじめてのMicrosoft Azure(ディスクアタッチ) - LinuxユーザーがイジるはじめてのAzure
もう1つクライアントOSからのマウント、として便利そうなものがAzure File
ストレージ(Azure Files)ですね。
OS内のSMBクライアントから接続することでLinux環境でもマウントして利用
できる共有ストレージです。
ここまではおさらいというか基本情報です。やりたいのはここからもう少し
踏み込んだ部分です。
上記3つに共通することは、「1つのマウントポイント領域でAzureのディスクを
扱いたい」という点です。ワンエフエス(One File System)は開発者にとっては
楽ちんですからね。いろいろ落とし穴はありそうですが、やってみましょう。
では早速Azure Filesからやっていきましょう。
まずAzureポータルからStorage AccountのFILEサービスからエンドポイントを確認
し、「+ファイル共有」から1つ作成しましょう。
作成したファイル共有(ここではlinuxshareという名前)をクリックし、接続を
押下するとLinux環境からマウントするコマンドサンプルが表示されます。便利!
注記にもありますが、Azure Filesは暗号化対応がまだ未対応のため、異なる
リージョン間でマウント共有することは2017年8月時点ではできません。
ちなみにこの東日本で作成したAzure Filesに対して西日本で用意した仮想マシンから
マウントしようとすると以下のエラーがでます。
大人しく東日本で作成した仮想マシンから、root権限でマウントしましょう。
また、Azureポータルで表示されているマウント方法はmountコマンドからマウント
するやり方なので、/etc/fstabには以下のように記載しました。
※パスワード部分はマスクしているので利用者の環境に合わせてください。
# /etc/fstabの追加行(1行)
//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な見え方になりますねw
ちなみに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の2つのデバイスが見えました。
ではこの2つの領域を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と続けて、1つの論理パーティション
を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(お薦めしま
せんがw)なんかを書ければと思いますー。
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を対象とするよう設定しておきます。
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度検知した後、1時間は多重検知してもメールは飛ばさない、という設定も入れています。
今回設定は入れていませんが、webhook、runbookの指定個所もあるので、特定のメッセージを検知したらwebhookのhttp要求を実行してrunbookを走らせる、みたいなこともできそうですね。一次対応としてVM再起動する、とか簡単にできそうです。
もう一度loggerコマンドでCentOS内でログを出してみましょう。
はい、先ほどの1行だけでなく2行目が出てきており、ちゃんと拾えているようです。
しばらくすると以下のようなアラートメールが指定したメールアドレスに届きました。
メールの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が管理しているメールサーバーが死なない限り、ちゃんとアラートメールが飛んでくると捉えてよいでしょう。
アラート設定を止めたい場合は以下から操作します。
ごちゃごちゃパネルを追加したので見栄えが変ですが、「設定」を押下します。
先ほど登録したアラート設定が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内のウィンドウマネージャーを呼び出した、という状態です。
●事前準備
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.inicp 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直打ちなのでセキュリティが、、的なポップアップは無視して
継続します。
以下を選択・入力して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-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のアプリを、どこかのリソースに権限を付与して紐づけなければいけません。ここではリソースグループに紐づけてみます。(単一VMにも紐づけ可能です)
適用したいリソースグループから 「アクセス制御IAM}を選び「追加」から、どの役割(ロールですよね)を追加するかを選びます。いろんなAPIを触りたいので共同作成者にしておきましょう。(VMの操作だけなら、仮想マシン作成協力者がよいと思います)
次は「ユーザーの追加」にて先ほどAADに作ったアプリ名を検索して選択しましょう。最後にOKボタンをクリックしてポータルからの操作は終わりです。
以下の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名は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形式のファイル
⇒ インプットファイルのひな型とスクリプトは以下からwget/curl等でダウンロード
してください。
・インプットファイルのひな型
〇事前準備
上記インプットファイルのサンプル記載を参考に100行でも200行でも適用したい
数だけ自社用・自分用に全て埋めましょう。
〇開始
事前準備が終わった後の確認画面です。(azureコマンドを打てる状態で)
more input.csvで中身を確認してみてください。
※項目と順序、記載文字列が合っていれば、先ほど記載してもらったエクセル
ファイルを上記形式を変えずにCSVへエクスポートし、Linux側へSCPして
ください。
次にmakeNSGjson.shをvi/vimで開きます。
下にあるように作業するPATHを自分のローカルパスに変更してwqしてください。
⇒BASE_DIR_PATHの場所を自分の環境に合わせて修正
ではコマンドを実行します。
特にエラーもなく終われば、実行したその配下にoutput.jsonというファイルが1つ作成されています。
中身を見るとわかりますが、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の部分は既にポータルで部分的にデプロイが確認できていることから、デプロイステータスを指しているようです。
こんな画面で終わっていれば成功です。
ではポータルで確認してみましょう。
ちゃんと作成されていますね。
ではもう1つ。
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設定で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
(固定)
〇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を一括で体験することができます。
是非お試しください。