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

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

【お試し】Azure blob storageへvNETアドレスからのみ許可する

めずらしく連続更新です。

 

今回はBlob storageへのアクセスを仮想ネットワーク(vNET)からのみ

接続させる、というセキュアな経路を設定する機能紹介です。

 

先日アナウンスされた記事は以下です。

Announcing Preview of Azure Storage Firewalls and Virtual Networks | Blog | Microsoft Azure

 

 

概要は以下の日本語サイトを見て把握しましょう。

Azure Storage ファイアウォールおよび仮想ネットワークの構成 (プレビュー) | Microsoft Docs

 

残念ながらこちらもまだ日本リージョン(東西)へ展開されていませんので

展開されるまで待ちましょう。むむむむ。

 

では早速いきましょう。以下試したリソースは米国東部リージョンです。

f:id:akazure:20171017094711j:plain

 

違いを区別するために仮想マシン作成時に作ったストレージアカウントは

今まで通りファイアウォール設定を入れていない「nonaclblob001」とし、

後で作成した「blobacl002」はファイアウォール設定を入れるストレージ

アカウントとして用意しました。

また、仮想ネットワーク(vNET)のアドレスは192.168.0.0/16とし

1つ192.168.0.0/24のサブネットを切っています。仮想マシンはそこに配してあります。

 

以下はblobacl002作成時にファイアウォール設定を入れる画面です。

f:id:akazure:20171017094548j:plain

 

注目すべきは下段にある仮想ネットワーク(プレビュー)の個所ですね。

既に作成済のvNETをプルダウンで選択できる状態になっています。

また、サブネットもvNET作成時に用意したものを選択します。

ですので正確にはvNET ACLというよりSubnet ACLですかね。

 

設定したストレージアカウントのダッシュボードは以下です。

f:id:akazure:20171017095327j:plain

 

ちゃんと設定したvNETからアクセスするように見えています。

あと、個別にIPaddressかCIDRを入れて許可させることもできそうです。

※ここ重要。この後ハマるんでw

 

さらに「信頼されたMicrosoftサービスによるこのストレージアカウント

へのアクセスを許可する」なるものにデフォルトでチェックされています。

 

し、、、信頼された??と懐疑的な方はこの記事の冒頭に入れた日本語概要

のURLをもう一度読みましょう。下の方にどこからを許可してる、というのが

記載されていますので。

 

blobacl002が作成できたので、早速Azureポータルから見てみ。。。

f:id:akazure:20171017100033j:plain

 

はう!!

 

んじゃAzure Storage Explorerで覗いてみるかぁ。

f:id:akazure:20171017100320j:plain

 

あわわ!

 

既にお気づきの方も多いと思いますが、blob storageのファイアウォール

設定でvNETからと信頼されたMicrosoftサービスからのみアクセスを許可

していますよね。つまりAzureポータルやStorage Explorerの接続元と

なっている「あなたが」利用しているインターネットに出てるソースIP

を許可していないのでアクセスできない状態です。そりゃそうだ、な話。

 

ということでご自分の環境で利用しているアドレスをファイアウォール

設定で許可してあげましょう。

 

以下のサイトへ行くと利用しているソースIPがわかります。

アクセス情報【使用中のIPアドレス確認】

 

他にもLinuxターミナルだと以下のコマンドでわかります。

 

curl inet-ip.info

 

 

さて、アドレスがわかればblob storageのファイアウォール機能を

もう一度開き、そのアドレスからの許可を入れておきます。

 

最後に、「本当にvNETアドレスからのみ受け付けてんだよね?」という

確認をしておきましょ。

 

まずストレージアカウントの「診断」をONにします。

f:id:akazure:20171017100955j:plain

 

ご自分のソース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へのアクセスログが自動的に配置されていることがわかります。

f:id:akazure:20171017101304j:plain

 

 

 

 

中身を見てみましょう。

f:id:akazure:20171017101410j:plain

 

説明を端折ってますが、何度かvNET内に作成した仮想マシンから

Azure CLIでblobacl002のblobへファイルをアップロードしたりリスト

出力したりしています。もちろんスマホからも覗こうと何度か試してます。

 

うむ、ちゃんとvNETで切った仮想マシンのアドレス(192.168.0.4)から

受け付けたログだけが見えていますね。ステキ♪

 

余談ですが、このストレージアカウントへ診断機能を付けてアクセスログ

を出す仕掛けは、利用しているAPIのバージョンを確認する時にも利用

できます。APIバージョンのサポート切れ、みたいなアナウンスがあった

時に、いま自分が利用しているblob storageへアクセスしているAPI

バージョンって、なんだっけ?という時にアプリや設定ファイルを1つ

ずつ虱潰しに確認する手間は避け、この診断ログを30日分ためて

このテキストログから利用バージョンだけをくり貫いて確認する、と

いった便利な使い方もできます。(1か月稼働しないバッチとかだと

モレるので40日保存の解析がいいですかね)

 

以上でっす。 

【お試し】Azure Availability Zoneをいじる

ども。ちょっとLinuxネタから外れますが、Microsoft Igniteでも話題と

なった可用性ゾーン、Availability Zone(Public Preview)なるものを少し

見てみました。

 

はじめて触ろうとされる方の参考までにー。 

 

以下参考となるサイトの一覧ですので、まずはどういうものか理解

しておきましょう。

 

可用性ゾーンの概要 | Microsoft Docs

 

まだプレビューですので、利用できるゾーンやVMサイズに制限が

あり、利用しているサブスクリプションに対して利用申請しないと

使えなさそうです。

※2017/10/16現在、残念ながら日本リージョン(東西)ではまだ利用

 できないようです。むむむ。

 

ということで米国東部2のリージョンを使い、D1v2 Standardで軽く

CentOSを作成してみました。

 

まずは可用性ゾーンを利用するために以下から申請します。

 

http://aka.ms/azenroll

f:id:akazure:20171016121917j:plain

自動的にAzureポータルへ遷移し、可用性ゾーンを有効とするサブスク

リプションをチェックし有効化を押します。

 

f:id:akazure:20171016122440j:plain

15分ほどすると無効の個所が有効となりますが、1時間ほど放置して

おきましょう。

※見た目有効になってますが、いきなり使おうとしても使えなかったので。

 

少し時間を置いたあと、新規作成から以下を選択しました。

リージョン:米国東部 2

VMサイズ:DS1v2 Standard

OS:CentOS7.3

 

仮想マシン作成時の「設定」を見ると、可用性ゾーンが1,2,3と選べる

ようになっていますね。

f:id:akazure:20171016122617j:plain

 

米国東部 2のリージョンには3つのデータセンターが存在している

というのがなんとなく想像できます。あと、可用性ゾーンを選択すると

可用性セットは選べなくなります。

 

とりあえず1を選んでみました。

 

Azure ポータルのダッシュボードで作成した仮想マシンを見てみます。f:id:akazure:20171016123221j:plain

 

可用性ゾーンと記載された項目が「1」になっているのがわかります。

折角なので、CloudShell(Azureポータル上で開くターミナル)で同じく

プレビューとなったPowerShellから設定情報を覗いてみましょ。

 

f:id:akazure:20171016123515j:plain

 

Bashと違って青い背景のあたりPowerShellっぽいですね、そそられ

ませんがw

 

以下のコマンドレットを叩くとゾーンが1になっていることがわかります。

 

 

Get-AzureRmPublicIpAddress -ResourceGroupName {Resource Group Name}

 

 

ちなみにbash(Azure CLi2.0)だと以下で確認できます。

 

 

az vm show -n {VM Name} --show-details --resource-group {Resource Group Name}

f:id:akazure:20171016123938j:plain

 

最後に、作成したResource GroupのARM templateをみてみます。

記載されているのはResourcesの中の3か所ですね。

 

Microsoft.Compute/disksの定義に1か所。(zonesのところ)

f:id:akazure:20171016124425j:plain

 

次はMicrosoft.Compute/virtualMachinesの定義。

f:id:akazure:20171016124519j:plain

 

最後にMicrosoft.Network/publicIPAddressesの定義。

f:id:akazure:20171016124553j:plain

 

可用性ゾーンをARM templateから設定することも簡単にできそうですね。

日本リージョンでの展開が楽しみですねー。日本で展開されたら

データセンターをどうやって1から2や3へ切り替えるのか、など

試したいところです。

 

あと、Azure LoadBalancer Standard SKUなるものも同じくプレビュー

となっていますが、このデータセンター間にまたがるバランシング機能

が拡充されています。Availability Zoneを意識したL4LBのバランシング

機能、といったところでしょうか。これも楽しみですね。

 

ということで今回はこの辺で。

カスタムイメージを基にスケールする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の文字列の後ろに半角スペースを入れた後、

公開キーの文字列をベタっと張り付けてください。

f:id:akazure:20170912194103j:plain

 

この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をベタっと

はりつけます。

f:id:akazure:20170912194704j:plain

 

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本です。

f:id:akazure:20170913114825j:plain

 

AppGWに付けるPublic IPはDynamic(動的アドレス)しか付けられない仕様ですが

ALBに付けるPublic IPはStatic(固定アドレス)で定義しています。

これでVMSSから見たoutbound通信は固定のグローバルアドレスとします。

 

AppGWではフロントエンドのポートを定義し、バックエンドプール(VMSS側へ

振り分ける対象ノードを定義しています。

f:id:akazure:20170913115153j:plain

大丈夫ですよ、後で確認画面見せますが、3台目、4台目とスケールアウトしても

ちゃんとAppGWから振り分け対象に自動的に入りますし、sshログインも増加した

サーバーへ入ることができますから。

 

VMSS側では以下のようにイメージのresource idを指定します。

f:id:akazure:20170913115521j:plain

イメージを一般化(Generalize)する前に、systemctl enable nginx(CentOS7.x)を

しておかないとOS起動時にnginxは起動されませんので注意ください。

 

冒頭でも触れた公開キーの埋め込み方法です。

f:id:akazure:20170913115832j:plain

公開キーはAzureから発行することは現状できませんので、puttyGenなどで自作

してくださいね。

 

autoscalesettingsは閾値や台数のスケール管理をする部分です。

f:id:akazure:20170913120013j:plain

 

VMSSノードは最低2台、最大5台としてます。また、CPUの平均値(5分だった

かな)が60%以上続く場合は1台ずつ増加させ、50%以下平均になると1台ずつ

減少させるように記載しています。

 

全てのデプロイは15分程度で終わります。ちなみにARM templateは40分で

タイムアウトしますので全ての処理は40分以内に終わる処理でなければ

いけません。もちろん各コンポーネントは非同期で処理実行されるため、タイム

アウトした後はできたところまでで切り離され、ロールバックする概念は

ありません。そこんとこ厳しいある。

 

デプロイが終わると各リソースはこんな風に見えます。

f:id:akazure:20170913120911j:plain

 

ではVMSS側にsshログインするので、ALB(上ではLoad balancer)を開きます。

※今回はsandbox環境を用意していないので、直接ALBにつけたPublic IPから

 SSHログインします。(22ではなく50000ポートでログインします)

 

f:id:akazure:20170913194124j:plain

 

英語表記になっちゃってますが、受信NAT規則なるタブから2台のVMのPublic IPと

ポート番号が確認できます。

 

TeraTermでログインしてみます。

f:id:akazure:20170913194312j:plain

 

f:id:akazure:20170913194417j:plain

 

ちゃんとnginxが起動した状態になっていますね。カスタムイメージから

展開されていることがわかります。

 

ちなみに省略しますが、このVMSSノードからcurlwgetで他のグローバル

アドレスへ通信した場合、受け側のWebエンジンのaccess_logからSource IP

がALBにつけたPublic IP(static)になっていることがわかります。

これで受け側での許可フィルタリングも問題なくできます。

 

では次にAppGWのリソースを覗き、AppGWについたPublicIP(+ domain)を

確認します。

f:id:akazure:20170913194955j:plain

 

軽くマスクしておきましたが、このドメイン or IPアドレスをブラウザで確認

してみましょう。

 

f:id:akazure:20170913195105j:plain

はい、ちゃんと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の現状を見ておきます。

f:id:akazure:20170913200343j:plain

 

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台目を追加しようと動き始めていますね。ステキ。

f:id:akazure:20170913200901j:plain

 

ちなみにこの状態で焦って3台目にログインしようとしてはいけません。

まだデプロイ中なのでsshログインできません。もう少し待ちましょう。

 

ALBの受信NAT規則を見ると3台目(どころか4台目まできてますねw)の

振り分け先が追加され、ポートも50003番で追加されているのがわかります。

f:id:akazure:20170913201325j:plain

 

はい、増加した3台目にログインでき、nginxが起動している状態が確認

できました。

f:id:akazure:20170913202705j:plain

 

ちゃんと/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つ作成しましょう。

 

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を叩いていくとおもしろい発見があるかもしれませんね。