AzureAD Domain Services がGA
AzureAD Domain Services がようやくGAしましたね。
▼#AzureAD Domain Services is now GA! Lift and shift to the cloud just got WAY easier! – Enterprise Mobility and Security Blog blogs.technet.microsoft.com
プレビューから比べて
といったあたりが大きな変更点でしょうか。だいぶ実用的になりましたね。
ただ、残念ながらまだクラシックポータルからの管理になるようです。
GAしたのでSLAも適用(99.9%)、価格は12月からGA料金になるようです。まだリージョンが限定されていて、アジア圏では
- 東南アジア
- 東アジア
- オーストラリア東部
- オーストラリア南東部
ということで、日本はまだでした(残念)。
▼SLA https://azure.microsoft.com/ja-jp/support/legal/sla/active-directory-ds/v1_0/
▼価格 https://azure.microsoft.com/ja-jp/pricing/details/active-directory-ds/
Visual Studio CodeのMarkdownプレビューをカスタマイズする
(追記有り： 2016/10/20)
そろそろWindows環境でも文章を書く環境を整えようと思ったのですが、Markdownが快適に書ければ十分かなということでVisual Studio Codeに落ち着きました。
標準でMarkdownのプレビューに対応しているのがありがたいですね。ファイルの拡張子を.mdとすると、プレビューボタンが押せるようになります。
http://changesworlds.com/2015/05/how-to-use-the-visual-studio-code-as-markdown-editor/
標準状態だと見た目がちょっと寂しいので、こちらのブログを参考にしながらCSSのフォント周りを少し修正します。
http://kiyokura.hateblo.jp/entry/2016/04/20/150648
markdown.css の置き場所が変わっているようで、手元のバージョン(1.5.3)ではここに置いてありました。
C:\Program Files (x86)\Microsoft VS Code\resources\app\extensions\markdown\media
これを %USERPROFILE%\.vscode にコピーして以下のあたりを書き換えました。
body { font-family: "Meiryo"; font-size: 18px; padding-left: 12px; line-height: 24px; } code { font-family: "Source Han Code JP"; font-size: 16px; line-height: 19px; }
最後に Preference -> User Settings から "markdown.styles" にmarkdown.cssのパスを指定しておしまいです。
(おまけ1： MarkdownからWordファイルを出力する)
こちらもありがたいことに先人の知恵がありました。
http://qiita.com/tsujimitsu/items/907d7a2fae2057d0fb1f
全ユーザー向けにインストールすれば特にパスを通す必要もなく、こんな感じで使えました。
pandoc input.md -o output.docx
いくつかのファイルで試してみたところ、書式が厳しめに判定されるようですね。
(おまけ2： キーバインドのカスタマイズ)
メニューから「File -> Preferences -> Keyboard Shortcuts」と選択して、keybindings.json に書き換えたいキーバインドを書き込んでいくだけです。
とりあえずカーソルまわりを快適にしたかったので、デフォルト定義からカーソルの上下左右、行頭、行末の移動とBackspace、Deleteあたりをコピーしてきて一段落。
ということで、こんな感じの keybindings.json になりました。
[ // カーソルを右に { "key": "ctrl+f", "command": "cursorRight", "when": "editorTextFocus && !editorReadonly" }, // カーソルを左に { "key": "ctrl+b", "command": "cursorLeft", "when": "editorTextFocus" }, // カーソルを上に { "key": "ctrl+p", "command": "cursorUp", "when": "editorTextFocus" }, // カーソルを下に { "key": "ctrl+n", "command": "cursorDown", "when": "editorTextFocus" }, // カーソルを行頭に { "key": "ctrl+a", "command": "cursorHome", "when": "editorTextFocus && !editorReadonly" }, // カーソルを行末に { "key": "ctrl+e", "command": "cursorEnd", "when": "editorTextFocus" }, // Backspace { "key": "ctrl+h", "command": "deleteLeft", "when": "editorTextFocus && !editorReadonly" }, // Delete { "key": "ctrl+d", "command": "deleteRight", "when": "editorTextFocus && !editorReadonly" } ]
(追記： 2016/10/20)
表を作るときにとても便利そうなツールがリリースされていました。
Ignite 2016 で発表されたAzureネタの個人的なまとめ
Igniteで大量のアップデートがあったようですね。個人的に気になった発表を、このあたりのURLからいくつか抜粋してみました。
▼Cloud innovations empowering IT for business transformation | Blog | Microsoft Azure
https://azure.microsoft.com/en-us/blog/cloud-innovations-empowering-it-for-business-transformation/
仮想マシン関連のアップデート
- 新しいインスタンスシリーズが登場しましたね(H、L)
- HはHPC向けインスタンス、高速なCPUと高速なI/O。現時点で利用可能です。
- Lは大きなローカルストレージを搭載(とはいえ揮発するのでは？)。間もなく登場とのこと。
- Nシリーズ(GPUインスタンス)も申請無しで選べるようなのでパブリックプレビューということでしょうか。
- SAP HANA on AzureがGAしたそうです。
- 単一インスタンスでメモリ3TB。他の用途でも使いたいのですがHANA専用のようですね。
- Azure Disk Encryption がLinux向け、Premium Storage向けにもGAしました。
- 1つのNICに複数のIPアドレス(パブリック、プライベートとも)を割り当てられるようになりました。
- 複数NICの接続についても、パブリックIPアドレスが割り当てられる等の向上があったようです。
- 「Accelerated Networking」としてVM向けのネットワーク高速化が進められているようです。
ネットワーク関連のアップデート
- Azure DNSがGAしました。SLA99.99%。Route53のためだけにAWSを使う必要はなくなりそうです。
- 内部ロードバランサーに複数のIPアドレスを割り当てられるようになりました(確か外部LBは以前から)。
- VNet PeeringがGAし、料金も設定されました(1.02円/GB、送受信とも)。
- VPN Gatewayがアクティブ-アクティブ構成をサポートしました。
- VNet間、VNet-オンプレミス間のどちらでも構成できるようです。
- 可用性のためだけにExpressRouteを敷く必要は無くなりそうですね(要High Performance SKUっぽいのでそれなりに値が張りますが)。
セキュリティ関連
- Application GatewayにWAF機能が追加されたようです。
- Security Centerにいろいろと機能追加されたようです。
- パートナーのセキュリティソリューション(WAFや脆弱性診断など)がポータル上から導入できるようになったとのこと。
- ストレージアカウントに対するセキュリティ診断機能が導入されるようです。
- 他にも、レポート系の機能がいろいろと強化されつつあるようですね。
Igniteのセッションをオンデマンドで見られます。
- MyIgnite - On Demand
- https://myignite.microsoft.com/videos
- いまの時点で全718セッション、Azureでフィルタしても149セッションありますね(見切れない)。
「App Service On Linux」がプレビューで提供され始めたようですね
「App Service On Linux」がプレビューで提供され始めたようですね。 …と思ったら、当初のドキュメントが消えていてGitHubにも見あたらなかったので、マーケットプレイスのリンクを貼っておきます。 (で、こっちはこっちで名称が「Web App On Linux」と微妙に違ってますね)
▼Web App On Linux on Microsoft Azure Marketplace
どういう状態か気になるところですが、マーケットプレイスのリンクから、もしくはポータル内で検索することでサービスの作成はできました。 Kuduも動いていて、Environmentを除くと結構面白いですね。 Debug console ではbashが動きます。 というところでお約束のコマンド実行結果。特に面白みのない結果(と言う状況自体が面白いのですが)。
/home>uname -a Linux f12e154155a0 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 GNU/Linux
/home>cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=debian HOME_URL="http://www.debian.org/" SUPPORT_URL="http://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
apacheの設定ファイル等は /etc/apache2 以下に置いてありました。 このあたりも標準的な感じになっていて扱いやすそうですね。
当初はデフォルトドキュメントも無くディレクトリが見える状態だったようですが、いまデプロイしたらいつものが設定されるようになっていました。エラーページも同様のようでした。
Azure VMのMACアドレスが固定化されるようになってました
各方面で「待望の」とつぶやかれているとおり、みんな待ち望んでいたMACアドレス固定化が実現されたようです。
feedback.azure.com
625 votes
44 commentsというわけで、どこまでちゃんと固定化されるのか試してみました。
まずは元のVMでifconfig。
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0D:3A:40:92:37
VMをSTOP->STARTします。
Stop-AzureRmVM -Name [VM名] -ResourceGroupName [リソースグループ名] Start-AzureRmVM -Name [VM名] -ResourceGroupName [リソースグループ名]
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0D:3A:40:92:37
ちゃんと維持されていますね。
次にVMを再デプロイしてみましょう。ポータルからポチッと「再デプロイ」です。
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0D:3A:40:92:37
VM(だけ)を削除したうえで同じVHDから再度生成、元のNICを割り当ててみます。
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0D:3A:40:92:37
これでも維持されます。
駄目だとは思いますが、新しいNICを作って付け替えてみましょう。
$vm = Get-AzureRmVM -ResourceGroupName '[リソースグループ名]' -Name '[VM名]' $nic_1 = Get-AzureRmNetworkInterface -ResourceGroupName '[リソースグループ名]' -Name '[NIC名(取り外す方)]' $nic_2 = Get-AzureRmNetworkInterface -ResourceGroupName '[リソースグループ名]' -Name '[NIC名(取り付ける方)]' $vm = Remove-AzureRmVMNetworkInterface -NetworkInterfaceIDs $nic_1.id -VM $vm $vm = Add-AzureRmVMNetworkInterface -Id $nic_2.id -VM $vm Update-AzureRmVM -ResourceGroupName '[リソースグループ名]' -VM $vm
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0D:3A:40:9C:E1
当然ですが変わりますね。
元のNICに戻してみます。
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0D:3A:40:92:37
ちゃんともとのMACアドレスが維持されています。
ということで、ごく普通の感覚でNICを取り扱っても大丈夫そうです。
(追記： Windows でもやってみました) ゴーストNICができなくなるということで改めて確認してみました。
元のMACアドレス。
STOP/START後のMACアドレス。維持されてますね。
ゴーストNICありません。
Azure VNet Peering でクラシックVNetとピアリングする(PowerShell)
いろいろ試していて、そういえばPowerShellでクラシックVNetとピアリングする方法が見あたらない気がしたのでメモ。
$vnet1 = Get-AzureRmVirtualNetwork -ResourceGroupName '[リソースグループ名]' -Name '[VNet名]' $vnet2 = '[リソースID]' Add-AzureRmVirtualNetworkPeering -name '[ピアリング名]' -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $vnet2
試した限りでは、ARM → クラシック方向のピアリングだけ設定すれば疎通するようです。 ポータルから設定するときも同じ手順なので、たぶんこれで大丈夫かなと。
リソースIDは、ポータルからだとVNetのブレードを開いたあとの「プロパティ」ブレードで確認できます。
普通にARMのVNet間をピアリングする場合は、@yuiashikagaさんの記事をどうぞ。
Azure VNet Peering が構成できたので軽く性能測定
親切な方のおかげでVNet Peeringが構成できたので軽く性能測定してみました。
用意したもの
手順
- VNetのピアリングをすませておく → (参考) VNet Peering を試してみる - Qiita
- 仮想マシンのWindows Firewall設定を変更して疎通できるようにしておく。対向のプライベートIPアドレスで許可設定するのが手軽かと思います。
- それぞれの仮想マシンにiperfのWindows版をダウンロードして入れておく。
- コマンドプロンプトから送受信側それぞれにiperfを立ち上げる。
- 受信側： iperf3.exe -s
- 送信側： iperf3.exe -c [受信側のIPアドレス]
- 送信側のコマンドを実行すると勝手に測定が始まります。
結果
だいたい2Gbps程度出ているようです(F8sのスペックで)。 VPN Gateway 経由だと、Gateway のスペック的に100Mbpsか200Mbpsが上限なので、だいぶ早いですね。
Connecting to host 172.19.0.4, port 5201 [ 4] local 172.18.0.4 port 49262 connected to 172.19.0.4 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 212 MBytes 1.78 Gbits/sec [ 4] 1.00-2.00 sec 244 MBytes 2.04 Gbits/sec [ 4] 2.00-3.00 sec 239 MBytes 2.01 Gbits/sec [ 4] 3.00-4.00 sec 251 MBytes 2.11 Gbits/sec [ 4] 4.00-5.00 sec 233 MBytes 1.95 Gbits/sec [ 4] 5.00-6.00 sec 233 MBytes 1.95 Gbits/sec [ 4] 6.00-7.00 sec 223 MBytes 1.88 Gbits/sec [ 4] 7.00-8.00 sec 222 MBytes 1.86 Gbits/sec [ 4] 8.00-9.00 sec 244 MBytes 2.04 Gbits/sec [ 4] 9.00-10.00 sec 246 MBytes 2.06 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 2.29 GBytes 1.97 Gbits/sec sender [ 4] 0.00-10.00 sec 2.29 GBytes 1.97 Gbits/sec receiver iperf Done.
結果(追記)
VMのサイズによってネットワークのパフォーマンスが違うわけですが、「中」とか「非常に高」といった非常にざっくりした表現なので、どれくらい違うのか測ってみました。ピアリング前提です。
Windows VM のサイズ |Microsoft Azure
▼F1sサイズ： パフォーマンス「中」 如実に低いですね。500Mbps程度というところ。
Connecting to host 172.19.0.4, port 5201 [ 4] local 172.18.0.4 port 49178 connected to 172.19.0.4 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.01 sec 59.8 MBytes 499 Mbits/sec [ 4] 1.01-2.01 sec 59.9 MBytes 500 Mbits/sec [ 4] 2.01-3.00 sec 59.0 MBytes 498 Mbits/sec [ 4] 3.00-4.00 sec 60.1 MBytes 506 Mbits/sec [ 4] 4.00-5.01 sec 59.4 MBytes 495 Mbits/sec [ 4] 5.01-6.00 sec 59.6 MBytes 503 Mbits/sec [ 4] 6.00-7.01 sec 59.5 MBytes 497 Mbits/sec [ 4] 7.01-8.00 sec 59.6 MBytes 503 Mbits/sec [ 4] 8.00-9.01 sec 59.2 MBytes 495 Mbits/sec [ 4] 9.01-10.00 sec 59.9 MBytes 505 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 596 MBytes 500 Mbits/sec sender [ 4] 0.00-10.00 sec 596 MBytes 500 Mbits/sec receiver iperf Done.
▼F16sサイズ： パフォーマンス「非常に高」 非常に、かどうかはともかく、2.5Gbps弱まで上がりますね。
Connecting to host 10.110.0.4, port 5201 [ 4] local 10.10.0.4 port 49182 connected to 10.110.0.4 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 290 MBytes 2.43 Gbits/sec [ 4] 1.00-2.00 sec 279 MBytes 2.34 Gbits/sec [ 4] 2.00-3.00 sec 293 MBytes 2.46 Gbits/sec [ 4] 3.00-4.00 sec 288 MBytes 2.42 Gbits/sec [ 4] 4.00-5.00 sec 299 MBytes 2.51 Gbits/sec [ 4] 5.00-6.00 sec 293 MBytes 2.46 Gbits/sec [ 4] 6.00-7.00 sec 293 MBytes 2.46 Gbits/sec [ 4] 7.00-8.00 sec 316 MBytes 2.65 Gbits/sec [ 4] 8.00-9.00 sec 289 MBytes 2.43 Gbits/sec [ 4] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 2.85 GBytes 2.45 Gbits/sec sender [ 4] 0.00-10.00 sec 2.85 GBytes 2.45 Gbits/sec receiver iperf Done.
