浅草橋青空市場

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

ネットワークセキュリティグループ(NSG)をPowerShellからまとめて設定する

Azure 仮想マシンのアクセス制限にネットワークセキュリティグループを設定することが多いと思います。 ポータルからも設定出来るのですが、ルールの更新中(プログレスバーが動いている間)に次のルールを登録することが出来ないため、結構面倒で時間もかかってしまいます。

とういことで、数が多いときはPowerShellでまとめて登録してしまいましょう。

# ログイン及びサブスクリプションの選択
Login-AzureRmAccount
$subscriptionId = (Get-AzureRmSubscription | Out-GridView -PassThru).SubscriptionId 
Select-AzureRmSubscription -SubscriptionId $subscriptionId

# ネットワークセキュリティグループを新規に作成する
New-AzureRmNetworkSecurityGroup -Location [ロケーション] -Name [NSG名] -ResourceGroupName [リソースグループ名]

# 変更するネットワークセキュリティグループを取得
$nsg = Get-AzureRmNetworkSecurityGroup -Name [NSG名] -ResourceGroupName [リソースグループ名]

# ルールを指定

# VNET内の通信を許可する
$rule = Add-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg -Name 'localnet' -Access Allow -Protocol * -Direction Inbound -Priority 110 -SourceAddressPrefix VirtualNetwork -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange *

# 外部からの通信は、指定したIPアドレス(レンジ)のみ接続する。
$rule = Add-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg -Name 'ssh' -Access Allow -Protocol * -Direction Inbound -Priority 210 -SourceAddressPrefix [IPアドレス(CIDR)] -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 22
$rule = Add-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg -Name 'http' -Access Allow -Protocol * -Direction Inbound -Priority 220 -SourceAddressPrefix [IPアドレス(CIDR)] -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 80
$rule = Add-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg -Name 'https' -Access Allow -Protocol * -Direction Inbound -Priority 230 -SourceAddressPrefix [IPアドレス(CIDR)] -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 443

# ルールをNSGに反映する
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $rule

「-SourceAddressPrefix」は、タグで指定することが出来るようです。 * Internet * VirtualNetwork * AzureLoadBalancer のいずれかがビルドインで指定できるようです。

登録できるルールの数は、セキュリティグループ当たり200個までとのことなので、IPアドレスを範囲で指定するなどして、ルールが増えすぎないように注意ですね。

Azure仮想マシンのパブリックIPアドレスに独自の逆引きFQDNを設定する

Azureの仮想マシンなどに固定のIPアドレスを割り当て(予約)していて、独自の逆引きFQDNを設定したくなったので調べてみました。 ASMの場合はクラウドサービスに対して設定、ARMの場合はパブリックIPアドレスリソースの属性を設定、となるようです。

固定IPアドレスじゃなかったり、正引きが登録されていなかったりするとエラーになるかと思います。

サービスマネージャー(ASM)の場合はこちら。

# 逆引きを設定する
Set-AzureService -ServiceName [(クラウドサービスの)サービス名]  -ReverseDnsFqdn '[設定したいFQDN]'

# 逆引きを削除する
Set-AzureService -ServiceName [(クラウドサービスの)サービス名] -ReverseDnsFqdn ''

リソースマネージャー(ARM)の場合はこんな感じです。

# 逆引きを設定する
$pip = Get-AzureRmPublicIpAddress -Name [パブリックIPアドレス名] -ResourceGroupName [リソースグループ名]
$pip.DnsSettings.ReverseFqdn = '[設定したいFQDN].'
Set-AzureRmPublicIpAddress -PublicIpAddress $pip

# 逆引きを削除する
$pip = Get-AzureRmPublicIpAddress -Name [パブリックIPアドレス名] -ResourceGroupName [リソースグループ名]
$pip.DnsSettings.ReverseFqdn = ''
Set-AzureRmPublicIpAddress -PublicIpAddress $pip

ARMの場合、Azure Resource Explorer から publicIpAddresses リソースを直接書き換えても構わないとは思いますが未検証です。

何か問題があると以下のようなエラーが出ますので、いろいろと見直してみて下さい。

ReverseFqdn [FQDN名] that PublicIPAddress [IPアドレス名] is trying to use does not belong to subscription [サブスクリプションID].
One of the following conditions need to be met to establish ownership:

1) ReverseFqdn matches fqdn of any public ip resource under the subscription;
2) ReverseFqdn resolves to the fqdn (through CName records chain) of any public ip resource under the subcription;
3) It resolves to the ip address (through CName and A records chain) of a static public ip resource under the subscription.

Azure仮想マシンでUnixBenchを取ってみた

わりと微妙なベンチマークが身内で話題になっていたので、せっかくなので実測してみました。 1コアのインスタンスでUnixBenchを走らせてみた結果です。 OSは Ubuntu Server 14.04 LTS です。

テスト項目 Standard_A1 Standard_DS1 Standard_DS1v2
Dhrystone 2 using register variables 1224.4 2047.9 2752.8
Double-Precision Whetstone 312.4 521.4 763.4
Execl Throughput 535.4 898.9 1448.1
File Copy 1024 bufsize 2000 maxblocks 1215.2 2071 3084.7
File Copy 256 bufsize 500 maxblocks 802.1 1335.3 1951
File Copy 4096 bufsize 8000 maxblocks 2107.6 3948.9 6319.2
Pipe Throughput 671.9 1112.8 1680.3
Pipe-based Context Switching 403.4 615 914.1
Process Creation 512.9 848.2 1399
Shell Scripts (1 concurrent) 923.3 1566.8 2420
Shell Scripts (8 concurrent) 874.4 1457.4 2239.1
System Call Overhead 1210.1 2114.3 2930.2
System Benchmarks Index Score: 787.8 1325.4 1993.9

一応書いておくと、各インスタンスのスペックはこんな感じです。売り文句より実測値の方がちょっと速めですね。

  • A1・・・1コア、1.75GBメモリ
  • DS1・・・1コア、3GBメモリ(Aシリーズより60%早いのが売り)
  • DS1v2・・・1コア、3GBメモリ(Dシリーズより35%早いのが売り)

DSのv2シリーズ、早く日本に来ませんかねー。Dシリーズより早い上に安いんですよね。

Azure PowerShellで仮想マシンV2を作成する (SysprepしたVHDから)

qiita.com

という記事を読みましたので、Sysprepした方のVHDからv2仮想マシンを生成するPowerShellスクリプトも置いておきます。

VM本体を構成するだけのスクリプトなので、各種コンポーネントはあらかじめ作っておいて下さい。 以下のものがあらかじめ用意されている前提のスクリプトになっています。 * リソースグループ * ストレージアカウント * 仮想ネットワークとサブネット * NIC * 可用性セット * （必要に応じて）ロードバランサーとパブリックIPアドレス * Sysprep されたVHDファイル

特殊化VHD（Sysprepしていない）との大きく違うところは、置いてあるVHDをそのまま仮想マシンに接続するのではないというところでしょうか。 「-VhdUri」で指定したところに新たなVHDファイルが作られます。

# Azureアカウントへログイン
Login-AzureRmAccount

# サブスクリプションの指定
$SubscriptionId = '[Subscription ID]'
Get-AzureRmSubscription -SubscriptionId $SubscriptionId | Select-AzureRmSubscription

# リソースグループの指定
$ResourceGroupName = '[Resource Group Name]'

# OSディスク情報の指定（Syspreped / Generalized VHDから生成する場合）
$StorageAccountName = '[Storage Account Name]'
$Caching = '[Disk Cache Mode]'
$CreateOption = 'fromimage'
$osDiskSourceImageUri = '[Source VHD Uri]'
$vhdUri = "[OS Disk VHD Uri]"

# 仮想マシンの構成情報
$vmName = '[VM Name]'
$vmSize = '[VM Size]'
$cred = Get-Credential
$Location = (Get-AzureRmStorageAccount -Name $StorageAccountName -ResourceGroupName $ResourceGroupName).Location

# 可用性セットの構成情報
$AvailabilitySetName = '[Availability Set Name]'
$vmAs = Get-AzureRmAvailabilitySet -ResourceGroupName $ResourceGroupName -Name $AvailabilitySetName

# NICの指定
$NicName = '[NIC Name]'
$nic = Get-AzureRmNetworkInterface -Name $NicName -ResourceGroupName $ResourceGroupName

# VM構成情報の組立
$vm = New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $vmAs.Id
$vm = Set-AzureRmVMOperatingSystem -ComputerName $vmName -Credential $cred -VM $vm -Windows
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.id
$vm = Set-AzureRmVMOSDisk -VM $vm -SourceImageUri $osDiskSourceImageUri -VhdUri $vhdUri -Name $vmName -CreateOption $CreateOption -Caching $Caching -Windows

# VMのデプロイ
New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $Location -VM $vm

ちなみに、Sysprepしてない手順でSysprepしたVHDから仮想マシンを作ると、「国または地域」などを指定する画面で止まってしまって悲しいことになります。

おまけで、仮想マシンのキャプチャを行うPowerShellスクリプトはこちらです。Sysprepだったり、Linuxの場合は sudo waagent -deprovision+user だったりは事前に各自で行って下さい。

$ResourceGroupName = '[Resource Group name]'
$vmName = '[VM Name]'
$DestinationContainerName = '[Destination Blob Container Name]'
$VHDNamePrefix = '[Vhd Prefix]'

# 仮想マシンの汎用化
Set-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $vmName -Generalized

# キャプチャの実行
Save-AzureRmVMImage -DestinationContainerName $DestinationContainerName -Name $vmName -ResourceGroupName $ResourceGroupName -VHDNamePrefix $VHDNamePrefix

JSONテンプレートを触った方が楽なケースが多いとは思いますが、用途によってはということで。

Azure Cool Blob storage を触ってみました

Azure Cool Blob storage が GA しましたので、軽く触ってみました。

General availability: Azure Cool Blob storage

AWSの「Glacier」やGoogleの「Nearline」相当のサービスになるかと思います。 パフォーマンスが同じ、というのが特徴でしょうか。

(2016/07/15 追記) って書いたんですが、AWSGlacierというよりStandard-IAの方ですね：

ストレージクラス - Amazon S3 | AWS

特徴

  • 互換性： 100%同じAPI。
  • パフォーマンス： レイテンシ、スループットとも同じ。
  • 可用性： Coolは99%、Hotは99.9% (RA-GRSは別）。
  • 既存ストレージアカウントからの移行は出来ない。
  • 対象はBLOBのみ。BLOBのみのストレージアカウントを新たに作る。
  • あらかじめHOT/COOLを指定して作ったストレージアカウントであれば、後から変更可能。
  • LRS,GRSなども後から変更可能。
  • 当然ですが、Premium Storage は対象外。
  • 今のところ、Azure Backup の保存先には選べないようです。

料金について

azure.microsoft.com

  • 容量当たりの単価は安い（東日本、100Tまでで約37%off）。
  • 割引率はLRS, GRS, RA-GRS ともほぼ同じ。
  • 容量が増えると割引率が低くなる（100Tまで 37% → 900TBまで 35% → 4,000TBまで 33%） f:id:yhara90:20160502115045p:plain
  • トランザクション課金はCOOLの方が高い（倍）。

作り方

  • 新規にストレージアカウントを作るのと同じ
  • Classic モデルでは作成出来ない。ARMのみ。
  • Account kind (アカウントの種類)から「Blob storage」を指定して作成。

用途によってはしばらく割高感のあったAzureのストレージでしたが、これでまた値頃感が出てきましたね。 Azure Backup が対応してくれると更に嬉しいところです。

Azure Hybrid Use Benefit(HUB) の使い方

ライセンス周りのネタですが、Azure Hybrid Use Benefit(HUB) の具体的な使い方が日本語で公開されていました。 Windows OSのSAを持っていれば、Azure VM利用時にWindowsライセンスの利用料が削減できるというアレですね。

Azure Hybrid Use Benefit の使用方法 | Cloud and Server Product Japan Blog blogs.technet.microsoft.com

が、いま見たら、Cloud and Server Product Japan Blog がひととおり文字化けしているようなので英語の方も貼っておきます。 How can I use the Hybrid Use Benefit in Azure? | Azure in Education

具体的には、デプロイ時にLicenseTypeを「Windows_Server」を指定するということのようです。 既存の Azure VM からコンバートする場合、VHDから作り直しになるなど細かい点は注意が必要ですね。

▼PowerShellの例

New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $LocationName –LicenseType “Windows_Server” -VM $VirtualMachine -Verbose

▼JSONテンプレートの例

“properties”: {
  “licenseType”: “Windows_Server”,

Web Appsにデプロイしたnode.jsアプリが500エラーになる時の対処

いつも通りにGitHubからnode.jsのアプリをデプロイしたら500エラーになってしまってしばらくあたふたしたのでメモしておきます。

症状

  • Web Apps のステージング用スロットに GitHub からデプロイしたら500エラーが発生。
  • 別のスロットにデプロイした同じソースはちゃんと動いている。
  • Kudu からログを見ると「Error: Cannot find module 'debug'」といった感じで、モジュールが足りない模様。

対処

  • Kudu から node_modules ディレクトリを消す。
  • npm install

今回はこれで無事復活しました。

（参考URL） stackoverflow.com