sidetech

インフラエンジニアの寄り道メモ。

Azureと戯れる準備。

久々にAzureに触ってみます。何か月ぶりだろう…約6か月ぶりですかね・・・。

Azureとかawsとかとっつきにくかった方々や、アプリケーションサーバー立てた後、どうしようと悩まれる方、結局VPN張りたいんだよという方。目的はないけどもやってみたけどイマイチ何しようか立ち止まってしまう方・・・
そんな方達(?)向けになるのかわかりませんが・・・

残念ながら『10分でアプリが使えるぐらいクラウドは簡単』をかるーく覆す程、クラウドの作法に振り回される将来が待ち受けており、私も「あーしておけばよかった」とか「もう後戻りできない」とか「何度も反復できない要素ですぐ忘れてしまう」等など、触る方々の苦しみは少しは分かっております。そして、この手にはよくある、「理解はしていないけど手順に沿って頑張る」事をやっても、その先に手を出そうとすると仕様が合わずに行き詰まったり・・・。そして、そんな中、クラウドの仕様変更やUIの変更に振り回され、何が何だかとなっていく(私もですが)。そんな苦労の入り口に立たれている方々へ、なるべく手戻りをなるべく減らしながらも失敗しても致命傷を負わせずにAzureと戯れる方法があればなぁ・・・と思う次第です。

ちなみにAzureに関しては、私はAzureの心の師匠として

「くらう道」のうしがみさんの記事を大変参考にしております。企業系のAzureブログもちらっとは見ますが、古いネタだったり、ちょっとそれじゃないというのが多く、うしがみさんのAzureネタがなければMicrosoftの日本語として読みにくいナレッジを自己MicrosoftDocumentsUnZIPをフル回転させながら読解していかねばならず、この読解でかなり疲弊します・・・。うしがみさんが居なかったら日本のAzureエンジニアは入口に立たずにawsに行くでしょう(笑)。もっとAzureのナレッジが増えると良いのだけども…。

さて、前置きが長くなりましたが、Azureと上手に戯れるには、分かっていてもわかっていなくても、以下の要素の準備をしておけば、ある程度汎用性が保てます。

・最初からvNETは2つ用意する
・vNETのCIDRはケチらず「/16」で作っておこう

一つは、「SubnetGateway」を使うvNET
もう一つは、「RouteTables」を使うvNET
もちろん、目的や拡張性が分かっている方々は絞って狙うvNETでよいかと思います。
でも、恐らくは目的の為の設計に専念してしまい拡張性考慮がされなかったりしていると思います。そんな部分にもあらかた拡張性の都合を残すには「使用予定がないvNETも作る」のが実は後々自分の退路を確保できます。
なんでかというと・・・

例えばの例ですが、恐らくこの想定を初めからするのは不可能でしょう。
(以下MSのナレッジから画像拝借)
接続アーキテクチャ図
高可用性

まず・・この接続図までは「ふんふんなるほど・・・」でよいかと思うんです。
PaaSを活かすのにこういったデザインがあるんだと。

しかしですね・・・

f:id:hunter1014:20210117205058p:plain

f:id:hunter1014:20210117205204p:plain

ここで、ExpressRouteを使う場合は・・・という例で、それまでの構成では組めない絵に突然押し付けられるんです。後出し仕様に感じるかもですね。。。これがクラウドインフラに関わる方々の恐怖です。私も「Azure virtual WAN」とかやったことないので、どうやるんだか・・・(^^;awsでも「AWS Transit Gateway」なるものが後から登場し困らせてくれました。

わたくし、SQL-MIとExpressRouteどちらも使うケースに遭遇し「突然終了のお知らせ」を突き付けられました。この後の設計変更を苦労したのは言うまでもありません。
最初からどこかで注意書きがあればよいのですが、大抵はやろうとした時です。
なので、「vNETを二つ用意する」だけでも超えられない仕様はあるにはあります。
ただ、上記の図のようにAzureのインフラではピアリングデザインが当たり前のように使われる事に注意しなければならないんです。あとからあれこれサーバーレスをやりたいと思ったときに気をつけねばなりません。
そして、「RouteTables」ですが、SQLマネージドインスタンスや、3rdパーティ製の仮想ルーターなどは「RouteTalbes」を使います。「RouteTables」を使った方がよい場面と使わない方がよい場面もあり、これらの状況を鑑みると、vNETは最初から2つあった方が振り回しやすいのではないかなと思った次第です。

えーと、ここまで何言っているのか分からなくてもとりあえずvNETは2つ作っておくと幸せですよという話です。グローバルも意識されている方は、こんなブログを参考にはしていないと思いますので・・・(笑)

 

まぁ話は長くなりましたが、サクサクとやっつけましょう。

f:id:hunter1014:20210117211238p:plain

私はMicrosoft365の契約があるので、そこから「portal.azure.com」へアプローチして、ここにきています。開始すると、クレジットカードが人質になりますので無料の範囲を超えそうな場合とかちゃんとアラート設定とかも考えたり、その前にAzureカリキュレーターで予備計算してから登録してくださいませ。

f:id:hunter1014:20210117211509p:plain

最初のTOP画面はUIがコロコロ変わるので、同じ画面じゃないかもですが、とりあえず「VirtualMachine」じゃなくて、「仮想ネットワーク」に行きましょう。
awsではよくデフォルトの[172.31.0.0/16」をそのまま使われているケースがよくあるなぁと思ってましたが、Azureでも10.0.0.0/16を使わせる感じの流れだったかな?
オンプレや個人宅でいうと192.168.0.0/24とか192.168.1.0/24をそのまま使っていくパターンと変わりませんが、オンプレだって、そのルーターがいなかったらサーバーを立ててもどこにも行けないネットワークになってしまうわけですから、ちゃんとネットワークから作ってあげましょう。

f:id:hunter1014:20210117211951p:plain

はい、私は上記のような感じで起こしました。

f:id:hunter1014:20210117212025p:plain

「vNET_10_0」のCIDRは「10.0.0.0/16」とし、「GatewaySubnet」と他2つのサブネットを作っておきました。作っただけです。何に使うか考えてません(笑)
ルーターでSubnetバンバンつくるというたら、そりゃちょっとだけ大変ですがAzureでは簡単ですね。「GatewaySubnet」はawsでは出てこない作法のある特殊なSubnetです。作法上必要であると理解すればOKです。

f:id:hunter1014:20210117212344p:plain

そしてもう一つ、「10.1.0.0/16のCIDR」のvNETを作っても/24のサブネットをとりあえず2つ作っています。使い道は決まっていない。
名前の付け方は人それぞれだと思います。わたくし目的用途向けにSubnetの名前を付けていたことがあるのですが(たとえばSystem-Subnet、Management-Subnet、App-Subnetなど)、どっちつかずなサーバが居る時に困ったんですよねぇ。
Azureではリソースグループでまとめる方法もあるので、Subnetに意味をあまり持たせない方がいいのかなと思ってきた次第です。

と、言うことで、vNETを2つ準備するだけなのに、長い眠くなる説明に終始してしまいました。でもここを乗り越えればあとは好きに(お金が許す限る)色々なサービスを立てまくるだけです。
過去記事でも似たこと書いていました。

今回は経験談を踏まえての説明ということで、大目に見てくださいませ。

Azure初心者向け?初級向け?になっているのかわかりませんが・・・(汗)
難しいですよね・・・クラウドの仕様や作法をやる前にすべて把握するのは。
勉強している速度よりも機能追加の方が早いと思います・・・(悲)

さて、次はAzureとEdgeRouterXとでS2S(Site-to-Site)VPNをします。
世間にネタが落ちてはいますが、私も載せておこうと思った次第です・・・。