とある環境に、AzureのDevTest Labsを使ってVMをいくつか作成することになりました。
準備不足・知識不足で「思ってたのと違う！」が多くて作り直し、設定し直し、の繰り返し。
また同じことを繰り返してお金と時間を無駄にしないよう、ここに書き留めておきます。
やりたかったこと
- DevTestLabsで"指定したソフトウェアをインストール済みのVM"を複数作成
- ローカルPCから作成したVMへリモート接続して中身を確認
起きた問題
問題になったのはNetworkSecurityGroup, DevTestLabs, VirtualMachineの三つ。
検証環境とVM名が重複
こちらの問題は気付いたらAzureから修正されていました
仮想マシンを作成する前に、検証用のサブスクリプションで一度同じ環境を作成したことがありました。
その際、本番用のVM名を使用して作成したのですが、本番で同じ名前を使おうとした際にAzureに怒られました。
検証用の環境で作成したVMと本番用の環境で作成したVMでFQDNが被ってしまったために怒られたようです。
検証環境のVMを削除しても名前は使えず......泣く泣くVM名を変更して構築しました。
VMにリモート接続できない...
VM作成後、作成済みのVNETにVMを割り当て、NSGとVNETを結び付けました。
一度VM内の成果物を確かめたかったので、NSGに特定のPCからインターネット経由でリモート接続できるようにNSGで受信規則を追加して穴をあけました。
リモート接続用のPCのパブリックIPと接続先のVMのパブリックIP間のRDP接続を許可すればいけるはず。
接続できません。
どうして......？
色々試した結果、リモート接続用PCのパブリックIPと接続先VMのプライベートIPで許可したら接続できました。
インターネット経由なのにプライベートIPで設定するのはちょっとイメージしづらい......
後々調べたら普通にAzure公式のNSGの概要のドキュメントに書いてありました。
Azure リソースのアドレスを指定する場合は、そのリソースに割り当てられているプライベート IP アドレスを指定します。 受信トラフィックの場合、ネットワーク セキュリティ グループが処理されるタイミングは、Azure でパブリック IP アドレスがプライベート IP アドレスに変換された後です。送信トラフィックの場合は、Azure でプライベート IP アドレスがパブリック IP アドレスに変換される前になります。
AzureのNSGの処理の順番によるもののようです。
そういうものだと受け入れるしかありませんね。
成果物は英語版
DevTest Labを使って構築するVMには、必要なアプリケーションをインストールしておくことができます。
これを使ってSSMSをインストールしておいたのですが、いざ作成してVMにログインしてみると、入っていたのは英語版でした。
DevTest Labを使って日本語版をインストールしておく方法は無さそうで、一つ一つVMに日本語版インストーラをダウンロードするしかなさそうです。
結局全てのVMで英語版をアンインストールして日本語版を入れ直し。
アンインストール時にゴミのファイルも残ってしまうので、だったらSSMSは最初に入れない方が良かったのでは......と思いました。
時間の浪費
最終的にこれらの問題は何とかして解消しましたが、恐ろしいほど時間を使ってしまいました。
前向きに考えれば学びを得たのですが、二度と繰り返したくはないので書き留めておきます。