「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.
Azure VNet Peering が来たけど使えないのでドキュメントを読む
期待のVNET Peeringなんですが、ドキュメントも公開されて早速やってみようとしたところで「SubscriptionNotRegisteredForFeature」ということでお預け状態です。
既に試せている人もいるようでうらやましい限りですね。 いつの間にかポータルからブレードも消えてしまってますが、このあとどうなるんでしょうね。
ということで、出遅れ組としてはやることもないのでドキュメントをかいつまんでまとめるなどして予習に励むことにします。
まず全体像についてはこちら。
ハウツー的なのはこちら。リンク先はとりあえずポータル上での操作方法ですが、PowerShellでもARMテンプレートでも設定出来るようです(CLIはまだかな？)。
VNET Peering の特徴
- VNet間を低遅延、広帯域でつなぐことができます。
- Gatewayを挟む必要が無いので、余分な費用もかからず、Gatewayのスループットにも左右されないのが良いですね。
- 料金は「プレビュー中なので無料」「GAしたら通常のチャージが発生する」って書いてありますが、リージョンまたげないのでやっぱり無料では？
- ARMのVNetからクラシックVNetに接続できます(ちなみにクラシックVNet同士は駄目)。新しいVMからARMで、という対応もできそうですね。
- ユーザー定義ルート(UDR)を上手く使って、仮想アプライアンス(F5とかですかね)を挟み込むことができるようです。
VNet Peering の制約など
- リージョンまたぎはできません。同じリージョンのVNet同士だけです。ただし、サブスクリプションはまたげるようです。
- VNet同士でIPアドレスが被ってはいけません。
- カスケードはできません(A-B-C みたいなトラフィックは流せない模様)。
- Azureから提供される内部向けの名前解決はVNetをまたがないようです。
- VNetあたりのピアリング数に限りがあるような記載があるのですが、ちょっと見あたりませんでした。
といったところでしょうか。 だいぶ実用的な仕様になった気がしますのでGAが楽しみですね。
App Service Environment がILB対応 / Azure Backup の仕組みについて
アナウンス1件、ドキュメント1件ありました。
App Service Environment(ASE)が内部ロードバランサーとVNETをサポートしたとのアナウンス
なのですが、特にPreviewとの記載はないですが、GAでしょうか？
▼Announcing Internal Load Balancer and Resource Manager VNet support | ブログ | Microsoft Azure
https://azure.microsoft.com/ja-jp/blog/ilb-and-arm-support-for-ase/
ドキュメント内では「ILB ASE」という呼び方になっていますね。 「ARM VNET」とあるので、ASM VNETはサポートしないと言うことでしょうかね。
イントラ等の内部向けシステム用途ということになるかと思いますが、S2S VPNやExpressRouteでオンプレミスと接続したときに外部向けのエンドポイントが一切無しで構築できるようになります、ということのようですね。 これまでもNSGで制限をかければ問題ないですよという説明をしてきましたが、よりすっきりします。
実際の構成については、DNSとSSL用の証明書が必要になる点が外向けASEとの違いのようです。 既に日本語のドキュメントもありますので安心ですね。
▼App Service 環境での内部ロード バランサーの作成と使用 | Microsoft Azure
Azure Backup における増分バックアップ
新機能ではなくドキュメントですが、Azure Backup の仕組みについて。
よくバックアップストレージの使用量をえいやっと見積もってしまいがちですが、仕組みが分かっているとより安心ですね。 こういうドキュメントが出てくるのはとてもありがたいです。
▼Incremental backups on Microsoft Azure Backup: Save on long term storage | ブログ | Microsoft Azure
https://azure.microsoft.com/ja-jp/blog/microsoft-azure-backup-save-on-long-term-storage/
Azure AD B2CがGA(北米) / 仮想マシンのメンテナンス対策 / VNET Peeringがパブリック
「Azure の料金とサービスの更新に関するお知らせ」が届いたので、気になったものをいくつかピックアップしてみました。
Azure AD B2C が北米でGAしてました
実際に米国でテナントを作ってみると「Production-scale tenant」となりますね。
「北米」の範囲は以下の通りとのこと。結構広いです。 United States, Canada, Costa Rica, Dominican Republic, El Salvador, Guatemala, Mexico, Panama, Puerto Rico and Trinidad and Tobago.
他のリージョンは「over the next few months」とのこと。
Azure Active Directory B2C is now generally available in North America | Blog | Microsoft Azure
仮想マシンのメンテナンス対策
「Azure の料金とサービスの更新に関するお知らせ」というメールが届いた中に「Azure のインプレース仮想マシン移行による、ホスト OS 用の重要なセキュリティ更新実行時における仮想マシンの再起動の排除」とあって何かと思ったんですが、これのことですかね。
Planned maintenance for Linux VMs | Microsoft Azure
前からあったドキュメントのような…と思ったら日本語と記述が違っているので、最近更新されたんでしょうか(ちょうどGitHubが落ちていて差分が追えませんが…)。 メモリの内容を維持したまま30秒以内にライブマイグレーションするようになりつつあるようですね。 メールの方にはテンポラリディスクの内容も保持するように書いてありますが、ほんとでしょうか。
VNET Peering がパブリックプレビューとなったようです
「link two Virtual Networks in the same geo region directly」ということで、VNET間をゲートウェイ無しで接続できたり、ARM(v2)とASM(v1)の間で接続できたりするので、まずはARMへのマイグレーション用ですかね。
あとは、小さく作りすぎたサブネットを広げたり、ExpressRoute のゲートウェイを置くセグメントを作ってクラウド側の複数のサブネットをまとめてオンプレに繋ぎ込んだり、といった用途にも使えるんでしょうか。
Cloud Platform Release Announcements for July 27, 2016 | Cloud Platform News Bytes Blog
とここまで書いておいて、まだどうやって使うのか分かっていません…
