Azureニューポータルに仮想マシンをたてる基本

初めての方の場合、仮想マシンを立ち上げる前に、割り当てるリソースグループの有無、ネットワークの有無、ファイヤーウォールのネットワークセキュリティグループの有無や構成を事前に考えておいたほうがいいです。

リソースグループは、「ダッシュボード」でメニューの非表示（ハンバーガーの三本線）をクリックして、「リソースグループ」⇒「+追加」より作ります。ネットワークは、「ダッシュボード」でメニューの非表示（ハンバーガーの三本線）をクリックして、「+新規」⇒「ネットワーキング」⇒「仮想ネットワーク」から作ります。「デプロイモデルの選択」は旧ポータルからクラシックの仮想マシンを使っている場合など、Azure内でレガシーな構成を背負ってる様な場合でなければ、新規のアーキテクトを行う場合、全て「Resource Manger」を選択してください。

仮想ネットワークでサブネットも作成した後、VirtualMachines⇒リソースグループを選ぶ⇒該当するネットワークセキュリティグループを選ぶ⇒概要。

受信セキュリティ規則　と　送信セキュリティ規則　に別れる。ここで各種通信プロトコルを設定する。必要に応じて穴をあけていく。デフォルトで、HTTP,HTTPS,SSHの3つの穴が空いている仮想マシンもある。

ネットワークセキュリティーグループ(NSG) は、Azure内のファイヤーウォール、設置できる箇所についての確認は必須。

リソースグループは、Azure内のVirtualMachinesやAppServiceやSQLデーターベースやAzureActiveDirectoryや監視など、各種サービスリソース単位ではなく、任意の様々なリソースを組合せて作る1つのグループ。

ストレージアカウントの作成

仮想マシン1台に、1ストレージアカウント（汎用ストレージやBLOBストレージなど）を割り当ててください。レプリケーションはゾーン冗長、ローカル冗長、地理冗長などの中から選びます。ストレージアカウントを作らないと、同一リージョンのAzureポータル内で2台目の仮想マシンを立ち上げる際、1台目の仮想マシンのストレージアカウントを2台目に一緒に割り当ててしまう様な事が起こります（実体験）。別々の仮想マシンなのにストレージアカウントが同じで可用性の設定やBackup and Site Recovery（OMS）などを実行する時に問題が発生します。混ぜるな危険ってやつです。

仮想マシンの作成

設定で監視のブート診断は、仮想マシン起動（boot）の際のログ。ゲストOSの診断は、仮想マシンのステータスログ。仮想マシンサイズは、Basic A2などで可用性等が必要ない段階であれば、そのまま「OK」でいい。

そして、いくつか進んだ後に概要の画面で「OK」の右「テンプレートとパラメーターのダウンロード」がAzure CLIで一覧の設定を自動化して立ち上げる際に役立つので、ダウンロードしておくと良い。マシンイメージをAzure内に保管しておくのが嫌な人は特におすすめ。テンプレート自体はjsonベース、デプロイファイルはRuby、その他シェルスクリプトやCSファイルやパワーシェルスクリプトのps1など一式がzipでダウンロードされる。

bootで待ち時間が発生する。マシンのスペックにもよると思いますが5分くらいだったと思う。

念のために、「仮想ネットワーク」は仮想マシンを立てるときにリソースグループの中に勝手に設定される。

仮想マシンのデプロイが終わったら、仮想マシンのネットワークセキュリティグループに進み「サブネット」⇒「+関連付け」より、仮想ネットワークとサブネットを関連付ける。

Azureニューポータルは初期ドメインが自動で割り当てられない

VirtualMachinesで該当の仮想マシンを選択⇒「概要（Overview）」⇒「パブリック IP アドレス/DNS 名ラベル（数字の部分）」をクリック、すると、DNS 名ラベル (オプション)　というのが出てくる。

そのなかにhogehogeなどを入力して保存すると、初期ドメインが割り当てられる。

//設定後、Azureから与えられる初期ドメインはこんな感じになる
hogehoge.japanwest.cloudapp.azure.com

仮想マシンへのSSH接続/プロビジョ二ングの前に設定しておいた方がいい。

旧ポータルでは自動で初期ドメインが割り当てられたが、新ポータルでは割り当てられないので要注意！

独自ドメインの場合、外部DNSネームサーバーを書き換える

「新規」⇒「ネットワーキング」⇒「DNSゾーン」にて独自ドメインのDNSゾーンを作ると、「NSレコード」とゾーンファイルの「SOAレコード」が自動で作られます。

「新規」⇒「ネットワーキング」⇒「DNSゾーン」⇒「+レコードセット」にて、仮想マシンのパブリックIPアドレスなどを調べて「Aレコード」やら「CNAME」やら「MXレコード」やらTTLも必要に応じて設定。仮想マシンへのSSH接続/プロヴィジョ二ングの前に設定しておいた方がいい。仮想マシンを固定IPにしていないと、停止、起動でAレコードのIPアドレスがズレます。再起動であればズレないです。

※仮想マシンのスケールアップ/ダウンを該当の「仮想マシン」⇒「サイズ」にて手動で変更すると、再起動されてサイズ変更されますが、その時もIPアドレスは変わりません。スケールアップ/ダウンを手動で1インスタンス（仮想マシン）で行う場合、サーバー非稼働時間帯が出来てしまうので要注意です。策としては、Azure Linux VM のコピーによって2インスタンス構成に変更し、Azure Load Balancerの向きを2ndインスタンスに変えてから、1stインスタンスに対してスケールアウトを行ってください。完了したら1stインスタンスにAzure Load Balancerの向きを戻し、2ndインスタンスは停止するなり、削除するなり、Azure Backupサービスやらを使ってください。停止しても「ディスク」が存在する限り課金対象です。

尚、Azureでスナップショットを行いたい場合、LinuxのVMか？WindowsのVMか？旧ポータルのクラシックのVMか？コピーか？キャプチャか？バックアップか？など、要件をしっかり見定めて的確な操作を行う必要が有ります。

その後、ポータル「すべてのリソース」の一覧画面へ、その中でDNSゾーンが追加されたことを確認、「概要」に進んでいくと、ネームサーバー1からネームサーバー4まで表示された画面にいける。

独自ドメインをリソースグループ単位で割り当てる事になる、リソースグループの選択をミスるとアウトなので気を付けて！

こちらもDNSゾーンを構成するだけで待ち時間が発生する。

出来上がると、ここでも「テンプレート リンク」ができます。ダウンロードしておくと、以降Azure CLIを使って時間泥棒の削減ができるかも。

出来上がった後に該当のDNSゾーンに進むと、概ね、以下のような感じでネームサーバーの値を得られる。お名前ドットコムなどで書き換えましょう。

//Azure仮想マシンのネームサーバーパターン目安。ニューポータルでは最後尾にドット付きで表示されるので要注意！
ns1-01.azure-dns.com
ns2-01.azure-dns.net
ns3-01.azure-dns.org
ns4-01.azure-dns.info

ご参考までに、旧ポータルでは機能名は「カスタムドメイン」あたり。おそらく、01の数字部分が個別に設定するたびに変動する。

AレコードやCNAMEやMXレコードなど、DNSレコード設定もおそらくできます。必要に応じて追記します。

もう一つ参考に、「すべてのリソース」⇒「ネットワークインターフェイス」で該当のものを選ぶ⇒「DNSサーバー」で、DNSサーバーを『仮想ネットワークから継承する』か『カスタム』にするか選択も出来る。

仮想マシンの固定IPアドレス

該当する仮想マシンを選ぶ⇒「パブリック IP アドレス/DNS 名ラベル」⇒「構成」⇒割り当て「静的」⇒「保存」でOKです。多少、料金が発生するはずですので気を付けてください。

Azureから与えられる初期ドメインも使う場合は、「DNS 名ラベル (オプション)」にも入力されている状態で「保存」してください。

プライベートIPアドレスについて

仮想マシンを立ち上げたときに、ネットワークインターフェイスが一緒に作られる。ネットワーク内におけるプライベートIPアドレスは、ネットワークインターフェイスで確認出来る。尚、仮想マシンを停止してもプライベートIPアドレスは変わらないです。

色々な工程で待ち時間が発生

見積や開発環境の構築や検証において、超重要。時間泥棒は売上利益泥棒なり。時は金なり。特に先が見えない検証作業地獄。

クラウドでものすごく便利になったのかもしれないが、工程の至る箇所で待ち時間発生する点は厄介。インフラ系は待ちが長くて多くて困る・・・。

検証作業時は細かい待ち時間が納期に悪影響を与える。待ち時間が大きな足枷。

大量のアカウント管理も発生する

SSHの接続アカウントやら、Linuxユーザーのアカウントやら、DBのアカウントやら・・・、これまた億劫。

セキュリティ対策別途必要

IPS/IDS、仮想マシンのファイヤーウォール(iptables/firewalld)、やWAFのシグネチャの品質を調べながらサードパーティーを入れる人も多いと思います。複雑な環境でなければ、攻撃遮断くんでWAF/IPSの両方を抑えてしまう方が簡単でいいと思います。

Azureセキュリティセンターで、仮想マシンからデータ収集、Storage サービスの暗号化、セキュリティ連絡先の詳細情報の指定（メールアドレスや電話）等々もあり、ドキュメントがたくさんあるので時間かかります。

売りっぱなしの商売っていいなぁ。勝手に読め、勝手にやれ、使ったら金払え！ってうらやましい。ちきしょー

その他

ヘルプとサポートにStackoverflow入ってる・・・。AWSは各種のサービスが独自の名称で発達し過ぎて学習しないと使いにくい。

Azureが旧ポータルだった2～3年前はAWSの方が使いやすかったけど、逆転してる気がする。Azureニューポータルになってから、Azureの方が学習コスト低い様な気がする。

Azure Power Shell ログイン

AzureのニューポータルGUIで操作してきましたが、念のためPowerShellのログイン方法です。

管理者権限でPower Shellを開き、次のコマンドを実行し、Azure Power Shellを入手します。

//PowerShellで次のコマンドを実行
Get-AzureRMSubscription

確認を求められるのでyで2回返事します。環境にもよるかもしれませんが少し待たないとダメです。

セキュリティポリシーの確認

//セキュリティポリシーの確認
Get-ExecutionPolicy

確認でRestrictedとなっていると、PowerShellスクリプトの実行が出来ないので以下のコマンドを実行します。

//セキュリティポリシーの設定
Set-ExecutionPolicy RemoteSigned

改めてセキュリティポリシーがRemoteSignedになったことを確認してください。

Azureへのログイン

//Azureへのログイン
Login-AzureRmAccount

このあと、画面の指示に従ってPowerShellでAzureにログインできます。