浅草橋青空市場

Microsoft Azure のニュースや情報を中心にあれこれと

AzureのサービスプリンシパルをCLI2.0から発行する

AzureをTerraformやAnsibleから制御したかったり、Azure Container Services から Kubernetes のクラスをデプロイするときなんかに必要となるのが「サービスプリンシパル」。 言葉が分かりづらいですが、SaaSでよくある「アプリケーションパスワード」みたいなものですね。

以前はこれの発行がわりと面倒だったのですが、Azure CLI 2.0 になって劇的に楽になりました。 Azure Cloud Shell から実行する前提で、ログイン等は省略してあります。

サービスプリンシパルの発行(CLI2.0対応版)

az account set --subscription "[サブスクリプションID]"
az ad sp create-for-rbac --name "[アプリケーション名]" --role Contributor

これだけです。

(追記: 2017/06/02)

「–role」オプションでRBACベースのロールを指定します。
例では、Ansible等を想定してリソースの読み書きなどが可能な「Contributor(=共同作業者)」としてありますが、こちらを参考に適切なロールを指定して下さい。情報の取得のみであれば「Reader」あたりでも間に合いますね。

docs.microsoft.com

(追記以上)

こんな感じのレスポンスが返ってきます。パスワードはあとから照会できませんので控えておきましょう。 パスワード以外の項目は、ポータルの「Azure Active Directory → アプリの登録」から確認できます。

{
    "appId": "[アプリケーションID]",
    "displayName": "[表示名]",
    "name": "[アプリケーションID/URI]",
    "password": "[パスワード]",
    "tenant": "[テナントID]"
}

発行したサービスプリンシパルCLIからログインしてみる

az login --service-principal --username "[アプリケーションID/URI]" --password "[パスワード]" --tenant "[テナントID]"

公式のドキュメントはこちらからどうぞ。

docs.microsoft.com

(追記: 2017/06/01)

パスワードが分からなくなった場合は、ポータルからキーを新たに発行すれば良さそうです。 手順はこのあたりから。

docs.microsoft.com

Azure仮想マシン用ディスクが最大4TBまで拡張されたようです

build 2017 の発表に続いてリリースが出ました。

azure.microsoft.com

さっそく検証記事が上がっていました。

qiita.com

記事がPowerShellだったので、CLIでもやってみました。 …といっても、単にCLIからManaged Diskを作っているだけですね。 Azure Cloud Shell でできるので楽ですね。

アナウンスには「West US Central Region」と書いてありますが、Japan Eastでも大きなディスクを作るだけならできました。仮想マシンにアタッチするところでエラーになるようですね。

CLIからディスクを作成する

$ az disk create --resource-group [リソースグループ名] --name [ディスク名] --sku [Standard_LRS or Premium_LRS] --location [リージョン] --size-gb [ディスクサイズ]

ディスクサイズの最大は、リリースにもあるように4,095GBです。 –sku は、Premium Disk(SSD相当)の場合は「Premium_LRS」、Standard Disk(HDD相当)の場合は「Standard_LRS」です。

既存のディスクのサイズを変更する

$ az disk update --resource-group [リソースグループ名] --name [ディスク名] --size-gb [ディスクサイズ]

Azure Lシリーズ仮想マシンのストレージベンチマーク

3月に登場したLシリーズの仮想マシンですが、低遅延なワークロード向けに最適化されたストレージが接続されているということで、実際にベンチマークしてみました。 比較対象は、L4s(4core, 32GBメモリ)とDS12v2(4 core, 28GBメモリ)、いずれも東日本です。

azure.microsoft.com

Linux上でのベンチマーク

OracleのORIONを使います。Oracle DatabaseのようなI/Oを再現させるということで、現実的なベンチマークが取れます。バイナリ1つというのも楽でいいですね。

ダウンロードはこちらから。ライセンス規約への同意が必要なのでブラウザでアクセスして下さい。

http://www.oracle.com/technetwork/jp/topics/index-096484-ja.html

準備

$ gunzip orion_linux_x86-64.gz
$ chmod 755 orion_linux_x86-64

計測用ディレクトリとファイルの作成

$ sudo mkdir /datadrive/iotest
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-010.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-020.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-030.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-040.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-050.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-060.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-070.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-080.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-090.dbf bs=1M count=1024
$ sudo dd if=/dev/zero of=/datadrive/iotest/testfile-100.dbf bs=1M count=1024

設定ファイルの作成

ORIONを配置したディレクトリで。

$ vi orion-test.lun
$ cat orion-test.lun
/datadrive/iotest/testfile-010.dbf
/datadrive/iotest/testfile-020.dbf
/datadrive/iotest/testfile-030.dbf
/datadrive/iotest/testfile-040.dbf
/datadrive/iotest/testfile-050.dbf
/datadrive/iotest/testfile-060.dbf
/datadrive/iotest/testfile-070.dbf
/datadrive/iotest/testfile-080.dbf
/datadrive/iotest/testfile-090.dbf
/datadrive/iotest/testfile-100.dbf

ベンチマークの実行(simpleモード: readのみ)

$ sudo ./orion_linux_x86-64 -run simple -testname orion-test -num_disks 1

ベンチマークの実行(advancedモード: read/write)

Writeの比率を20%に設定。

$ sudo ./orion_linux_x86-64 -run advanced -testname orion-test -write 20 -num_disks 1

結果のまとめ(IOPS)

#1 #2 #3 #4 #5 average
Resource Disk simple DS12v2 265,240 295,247 307,868 312,623 314,806 299,157
L4s 260,160 294,480 300,374 315,354 317,482 297,570
advanced DS12v2 4,902 105,021 150,353 151,570 151,631 112,695
L4s 15,867 231,738 250,393 251,296 256,432 201,145
Persistent Disk simple DS12v2 275,935 303,187 316,342 326,228 327,368 309,812
L4s 277,109 306,821 319,787 324,359 329,075 311,430
advanced DS12v2 73,683 84,010 89,240 86,708 84,707 83,670
L4s 177,048 199,667 251,055 252,527 250,629 226,185

「Resource Disk」がいわゆる揮発する方(/mnt/resources)、「Persistent Disk」が永続的なディスク(/)です。
「simple」と「advanced」が実行モードの違いで、simpleが読み取りのみ、advancedが読み書き混在で、今回はwrite20%で計測しました。
writeが入るとだいぶ性能差が出るようですね。

結果のまとめ(Latency)

#1 (ms) #2 (ms) #3 (ms) #4 (ms) #5 (ms) average
Resource Disk simple DS12v2 0.000 0.010 0.010 0.010 0.020 0.010
L4s 0.000 0.010 0.010 0.010 0.020 0.010
advanced DS12v2 0.200 0.020 0.020 0.030 0.030 0.060
L4s 0.060 0.010 0.010 0.020 0.020 0.024
Persistent Disk simple DS12v2 0.000 0.010 0.010 0.010 0.010 0.008
L4s 0.000 0.010 0.010 0.010 0.010 0.008
advanced DS12v2 0.010 0.020 0.030 0.050 0.060 0.034
L4s 0.010 0.010 0.010 0.020 0.020 0.014

こちらはレイテンシの測定結果です(ミリ秒)。
こちらも同様の傾向が見られますね。

Windows上でのベンチマーク

ついでにWindowsでも計測しました。CrystalDiskMarkでさらっと。
Windowsの場合はCドライブが永続的なディスク、Dドライブが揮発する方ですね。 Linuxと同じ傾向なので、やはりLシリーズのストレージは早いということになりそうです。

Cドライブでの比較

▼DS12v2
f:id:yhara90:20170428213126p:plain

▼L4s
f:id:yhara90:20170428213135p:plain

Dドライブでの比較

▼DS12v2
f:id:yhara90:20170428213144p:plain

▼L4s
f:id:yhara90:20170428213151p:plain

BASIC認証の代わりにOTPのトークンで認証してみる

せっかくなので、BASIC認証の代わりにOTPのトークンで認証できるように設定してみましょう。

昨日の続きと言えば続き。

asazure.hatenablog.jp

前準備

$ sudo yum install -y httpd httpd-devel
$ sudo yum install -y openssl-devel
$ git clone https://github.com/archiecobbs/mod-authn-otp
$ cd mod-authn-otp
$ ./autogen.sh -c
$ make
$ sudo make install

Apacheにモジュール読み込み

$ sudo vi /etc/httpd/conf.modules.d/00-authn_otp.conf
$ sudo diff /etc/httpd/conf.modules.d/00-authn_otp.conf /etc/httpd/conf.modules.d/00-authn_otp.conf.bak
1,2d0
< LoadModule authn_otp_module   modules/mod_authn_otp.so
$ service httpd configtest
$ sudo systemctl restart httpd

ユーザーファイルを作る

$ vi ~/create_otp_userfile_sh
$ cat ~/create_otp_userfile_sh
#!/bin/bash -e
user=${1:?Usage: $0 username}
issuer=${2:-your_company_name}
secret=$(cat /dev/urandom | tr -dc 'a-z0-9' | fold -w 15 | head -n 1)
secret_base16=$(python -c "import base64; print base64.b16encode('${secret}')")
secret_base32=$(python -c "import base64; print base64.b32encode('${secret}')")
otpauth_uri="otpauth://totp/${issuer}:${user}?secret=${secret_base32}&issuer=${issuer}"
otpauth_uri=$(python -c "import urllib; print urllib.quote('${otpauth_uri}')")
qrcode_url="https://chart.googleapis.com/chart?chs=300x300&cht=qr&chl=${otpauth_uri}"

file="/var/www/otp/users"
if [ ! -f "${file}" ]; then
  [ -d $(dirname "$file") ] || mkdir -p $(dirname "$file")
  touch ${file}
  chown -R apache:apache $(dirname "$file")
fi
[ -w "${file}" ] || (echo "${file}: Permission denied" && exit 1)

count=$(awk "\$2 ~ /^$user}\$/" ${file} | wc -l)
if [ $count -le 0 ]; then
  echo "HOTP/T30 $(printf '%-12s' $user) - ${secret_base16}" >> ${file}
  echo "$qrcode_url"
else
  echo "User '$user' already exists"
fi
$ sudo ./create_otp_userfile_sh haray2 isaotestweb

出力されたURLにアクセスして、表示されたQRコードをアプリでスキャンして登録。

※ユーザーファイルの生成はこちらからスクリプトを借りました。

qiita.com

「引数にUsernameを指定して実行すると、必要な項目を埋めた行が /var/www/otp/users に追記され、標準出力にGoogle Authenticator登録用のQRコードが表示されるURLが出力されます。」という優しい仕様。ありがとうございます。

BASIC認証の設定

$ sudo vi /etc/httpd/conf/httpd.conf
$ diff /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
159,170d158
< <Location />
<     AuthType Basic
<     AuthName "Mamoru OTP"
<     AuthBasicProvider OTP
<     Require valid-user
<     OTPAuthUsersFile /var/www/otp/users
<     OTPAuthMaxLinger 3600
<     OTPAuthMaxOTPFailure 20
<     OTPAuthPINAuthProvider file
<     OTPAuthLogoutOnIPChange On
< </Location>
$ service httpd configtest
$ sudo systemctl restart httpd

これで設定終わりです。 ブラウザからアクセスするとBASIC認証のダイアログが表示されるので、「ユーザー名」にはスクリプトで作成したユーザー名を、「パスワード」にはアプリに表示されているOTPを、それぞれ入力します。

f:id:yhara90:20170427211508p:plain

CentOSの認証にTOTPを使う

個人的なメモを残しておきます。

前準備

$ sudo yum -y groupinstall "Development Tools"
$ sudo yum -y install pam-devel

Google Authenticatorのpamモジュールをインストールする

github.com

$ git clone https://github.com/google/google-authenticator-libpam.git
$ cd google-authenticator-libpam/
$ ./bootstrap.sh
$ ./configure
$ make
$ sudo make install

sshdとpamの設定

$ sudo cp /usr/local/lib/security/pam_google_authenticator.so /usr/lib64/security/
$ sudo cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
$ sudo vi /etc/ssh/sshd_config
$ sudo diff /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
82,83c82,83
< ChallengeResponseAuthentication yes
< #ChallengeResponseAuthentication no
---
> #ChallengeResponseAuthentication yes
> ChallengeResponseAuthentication no
$ sudo sshd -t
$ sudo systemctl restart sshd
$ sudo vi /etc/pam.d/google-auth
$ cat /etc/pam.d/google-auth
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_google_authenticator.so try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
$ sudo cp -p /etc/pam.d/sshd /etc/pam.d/sshd.bak
$ sudo vi /etc/pam.d/sshd
$ sudo diff /etc/pam.d/sshd /etc/pam.d/sshd.bak
3c3
< #auth       substack     password-auth
---
> auth       substack     password-auth
21,22d20
< auth substack google-auth

OTPの設定(このときにQRコードも表示されるのでアプリを設定する)

$ google-authenticator

sudoにも適用してみよう

$ sudo cp /etc/pam.d/sudo /etc/pam.d/sudo.bak
$ sudo vi /etc/pam.d/sudo
$ diff /etc/pam.d/sudo /etc/pam.d/sudo.bak
2d1
< auth       substack     google-auth

Azureの東日本から近い海外リージョンは?

「Azureの日本リージョンに何かあったときに東アジアに逃がす」という話の流れから、「香港より韓国の方が近いのでは?」という指摘を見かけたので実測してみました。

各リージョンにCentOSVMを立てて、東日本のVMからnpingを100回ずつ飛ばしました。

sudo nping --tcp -c 100 -p 22 (宛先IPアドレス)

▼結果

東日本(japaneast)
Max rtt: 9.026ms | Min rtt: 0.629ms | Avg rtt: 1.179ms

西日本(japanwest)
Max rtt: 15.846ms | Min rtt: 8.869ms | Avg rtt: 9.298ms

東アジア(eastasia)
Max rtt: 55.422ms | Min rtt: 51.305ms | Avg rtt: 51.707ms

韓国中部(koreacentral)
Max rtt: 36.775ms | Min rtt: 34.438ms | Avg rtt: 34.722ms

韓国南部(koreasouth)
Max rtt: 44.547ms | Min rtt: 40.182ms | Avg rtt: 40.558ms

ということで、今のところ韓国中部(koreacentral)が近いようです。

(追記)

VM消す前に /proc/cpuinfo を見てみたら、韓国リージョンの方がCPUがちょっと新しくて早いようです。やっぱり新しいDCいいですね。

Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz

東日本、西日本、東アジアはこんな感じ。

Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz

SQL Database のアップデート

Announcing Azure SQL Database Premium RS, 4TB storage options, and enhanced portal experience | Blog | Microsoft Azure azure.microsoft.com

こちらも少し古くなってしまいましたが、SQL Databaseについて2件。
いずれもパブリックプレビューです。

1つめは価格階層の新設。
「Premium RS」が設けられたようで、Premiumから性能は変えずに信頼性を落として(冗長度を下げて)安くしたということのようです。 ストレージの最大容量も500GBまで、となっていますね。 障害発生時には最大5分間分巻き戻る可能性があるということなので、テスト用や検証環境用にちょうど良さそうですね。 本番用でも、アクティブgeoレプリケーションを設定しておけば使えるような気はします。

2つめは、P11とP15でストレージの4TBオプションが追加されました。
追加費用無しで拡張できます。 おそらくプレビューゆえのようですが、現時点では次のような制約があります。

  • いったん4TBに設定するとダウングレードできない
  • 容量縮小できない
  • アクティブgeoレプリケーションもP11かP15が必要
  • Elastic Poolに追加できない

これに合わせてだと思いますが、ポータル上からスケール操作をする際のUIも変わりました。 価格階層(StandardとかPremiumとか)をタブで選んで、DTUとストレージサイズをスライダーで指定する形になっています。