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

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

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つ作成しましょう。

 

f:id:akazure:20170807163441j:plain

 

作成したファイル共有(ここではlinuxshareという名前)をクリックし、接続を

押下するとLinux環境からマウントするコマンドサンプルが表示されます。便利!

 

f:id:akazure:20170807163758j:plain

 

注記にもありますが、Azure Filesは暗号化対応がまだ未対応のため、異なる

リージョン間でマウント共有することは2017年8月時点ではできません。

 

ちなみにこの東日本で作成したAzure Filesに対して西日本で用意した仮想マシンから

マウントしようとすると以下のエラーがでます。

f:id:akazure:20170807164100j:plain

 

大人しく東日本で作成した仮想マシンから、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で削除した時に非同期的なな感じになったので共有しておきます。

 

f:id:akazure:20170807164201j:plain

 

見てわかる通りrmコマンドでOS側はプロンプトで返ってきてるが、Azure Files側

ではまだ削除中ステータスのように残っています。5分程放置して見てみると

綺麗になくなっていました。若干Eventually Consistencyな見え方になりますねw

ちなみにmvでファイル移動する際はこのような現象はおきません。

OS内のinodeが変更されるシステムコールは整合性が強いですが、Files内の

ファイルハンドリングだけだとこのような見え方になりそうですね。ま、

結果おーらい。

 

あとリンクファイルの扱いについても注意です。

以下はrsyncで/etc配下を/mnt/azurefilesに同期させた時の結果です。

f:id:akazure:20170807165323j:plain

 

/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の容量では足らないんじゃー、ワンエフエスにこだわりたいんじゃー

という方への参考情報です。

 

f:id:akazure:20170808113709j:plain

 

とりあえず5TB以上なのでDataDiskを4TBx2本、仮想マシンにアタッチしま

しょうか。

ちなみに仮想マシンのサイズ(スペック)によってアタッチできるDataDiskの

本数に制限があります。以下から「Microsoft Azure IaaS リファレンス アーキ

テクチャ ガイド」のPDFをダウンロードして、ご利用されているサイズから

アタッチ可能ディスク本数の制限を確認しておきましょう。

 

Microsoft Azure でシステムを構築する際に参照すべきドキュメント【3/13 更新】 – Microsoft Partner Network ブログ

 

今回試しているサイズはD1ですので2本です。ディスク追加はホットアタッチ

できるので仮想マシンの停止や再起動は不要で楽ですね。

f:id:akazure:20170808135426j:plain

 

はい、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

print

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/

 

こんな感じに見えたでしょうかね。

f:id:akazure:20170808164701j:plain

※今回は手抜きでブロックサイズを指定しませんでしたが、これだけ容量が

 大きいとちゃんと計算してブロックサイズ指定したほうがパフォーマンスは

 出ると思います。

 

永続化は適当に/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を対象とするよう設定しておきます。

 

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でどう記載するか、といった点

でいくつか紹介します。