概要
AWSでウェブサーバーを建てるの巻き
ネットワーク全体の構造図
よく使うAWSのサービスメニュー
VPC(VIRTUAL PRIVATE CLOUD)
VPCをひとつしか使わない小規模構成ではあまり使わないメニュー。サブネットの設定など。
EC2(Amazon Elastic Compute Cloud)
インスタンス、ロードバランサーなど、必要なものはおおよそこちら。Elasticとは柔軟に融通が利くということらしいです。
Route 53
SSL証明書、DNS設定などはこちらから
Billing
請求の確認
AWSネットワークの概念的理解
リージョンとは
AWSサーバーの物理的な置き場所。アフリカ、北米、東京など世界中にあり。リージョンをまたがって同じサブネット(同一ネットワーク)にすることはできない。
アベイラビリティーゾーンとは
リージョン内でさらに分かれている区画。東京リージョンの中の東京第1サーバー群、東京第2サーバー群、みたいなもの。アベイラビリティーゾーンをまたがって同じサブネットにすることはできない。
VPC(VIRTUAL PRIVATE CLOUD)とは
仮想マシンやネットワークを作成する契約単位のようなもの。実際には契約単位ではないのでディスクなどのリソースはVPCをまたいで共有できる。
複数のVPCとは、ひとつの家にBフレッツを2回線引いてきているような状態と思う。
VPC1とVPC2では同じPrivate IPアドレスを設定できる(まったく別物なので)という点では別の契約みたいな考え方で良かろう。
プライベートサブネット
企業内の192.168.1.1~192.168.1.255のようなプライベートネットワーク。この中に部品を置いていけば相互につながる。
ネットワークにつなぐ部品の説明
インスタンスとは
WindowsやLinuxなどの稼働する仮想PCのようなもの。Hyper-Vのインスタンスと同じ。マザーボードのような部品。
ネットワークインターフェイスとは
ここはクラウドやSoftware Defined Networkingならではのポイントと言える。最初、意味不明で混乱した。
オンプレミスだとNIC(LANカード)はPCやWindowsと一体だが、AWSではNIC自体がPCなしでIPアドレスを持って単独でローカルサブネットに所属する。すでにIPアドレスを持って動作しているLANカードを、好きなデバイスにあとから接続。みたいな考え方。
従い、いくら入口のファイアーウォールを厚くしても、Windows Serverなど(インスタンス)に接続されているネットワークインターフェイスがPublic IPを持っていて、それが外部から開ける設定だと直接入られてしまうので意味がない。
オンプレミスだと外部からのアクセスは必ずヤマハルーターなどの入口から一元的に入ってくるが、AWSのネットワークでは、いろんなデバイスがPublic IPを持っており、いろいろなところから入れてしまう点に注意。きちんとふさぐ設定が必要。
ELB(Elastic Block Store)とは
つまりはサーバーにつながっているディスク。用語がわかりにくい。ディスクはディスクと呼んでほしいです。
ロードバランサーとは
今回はALB(Application Load Balancer)を使う。NLB, CLBについては未調査。負荷分散や落ちているサーバーにはつながない的な基本処理以外にもいろいろ使える。この3つロードバランサーを総称してELB(Elastic Load Balancing)と呼んでいる。どれがどれなのか分かりにくい。
ELB(ALB)では、いろいろな処理ができる。たとえば、特定のドメインから来たリクエストだけは違うサーバーに流す。クッキーの内容によりつなぐサーバーを変える。ランダムにサーバーを選ぶ(ABテストなど) つまりは、相手により返す結果を変えることができる。
今回のALBの用途は2つ
独自ドメインを取得してSSL証明書を与える
つまりはhttpsでアクセスしたい。ALB経由にしないとできないらしい。
リスナー設定>httpヘッダーの判定
というのを使って、当方のドメインを開いて来た接続以外(ロードバランサーのパブリックDNSやIPなどによりアクセス)は通さない設定をしている
利用料金について
インスタンスタイプと値段
最初はt2.microの無料枠を使うのが安い。無料なのはt2.microだけである。無料は永年無料ではなく12 か月間無料に過ぎないので注意。t2 microと無料枠対象のWindowsイメージならセットで12ヶ月間はともに無料の様子。
無料期間を過ぎるとt3a.microのほうが安くて2vCPU/メモリ1Gと性能が良さそうなのだが、こちらは12ヶ月無料がないので、あとから変更するのが良かろう。有料でもUSD 0.0214/h(Windows OS代金込み)なので、USD 15/月 程度。
インスタンスの稼働状況と課金
インスタンスを停止(サーバーの電源OFF)にしておけばインスタンス代金はかからない。ただし、ディスク(t2.micro だとgp2という種類のSSDがデフォルト設定となっており30GB)のディスク保管料はかかる。
GB/月につき 0.1 USD とかなので、30GB程度のバードディスクなら300円/月くらいで安いかなと思うが、100GBで1,000円/月と考えると安くない。
Elastic IP(Public IP)も開放しないと使っていなくても課金されるようです。
具体的な設定手順
1.インスタンスを作る、消す(仮想マシンの作成)
インスタンス>インスタンスを起動 で新規作成する
「インスタンスを終了」とするとインスタンスを削除することになる。インスタンス自体は仮想マシンの構成のようなものなので、作り直しできるが消えてもいいが、これをやると起動ディスクも一緒に消されるので注意。「EBS-Backed インスタンスでは、インスタンスが終了されたときにルート EBS ボリュームも削除されることがデフォルトアクションです。」とのこと。電源offにして課金を避けたいだけなら「インスタンスを停止」とする。
2.インスタンスタイプの変更方法
インスタンスの電源をOFFにする>アクション>インスタンスの設定
グレーアウトしている時はインスタンスの電源を切って1分くらい待つ。
OSが対応していないアーキテクチャーは当たり前だが選べない。
Microsoft Windows is not supported for the instance type ‘t4g.micro’.
これはarm64アーキテクチャーなのでx64のOSでは選べない。
高いインスタンスは448スレッドのCPU、6TBメモリで時間あたりUSD 50とのこと。お試しで使って消し忘れると大変。
3.OSのイメージを選択する
AMI(Amazon Machine Image)からWindows Serverを選択する。Windows Server 2022 など検索するといろいろ出てくるが、無料枠の対象と書かれているものを選ぶとよい。こちらも永年無料ではない。
コミュニティAMIは一般ユーザーが作ったマシンイメージだが公式も混在している。配布元ID 801119661308 は公式らしい。
コミュニティのイメージとは何か。つまりは本家以外により作られたイメージ。たとえば、Windows 2022 Server with Support by Supported Images などを選ぶと Supported Images という会社にサポートしてもらえると思うが時間ごとに有料となり、ノーマルなWindows OSのみより高いはず。
ここまででWindowsが起動する。bitnamiなどを使ってredmineなどウェブサービス(80番使用)をインストールする(もしくは後述のディスクを追加してからインストール)
4.Windowsのパスワードを取得
アクション>セキュリティ>Windowsパスワードを取得
5. Windowsが起動してからのWindows内での必須設定
時計設定
Windows時刻設定を変更。最初はUTCになっているので、UTC+9で日本にする。
ファイアーウォール開放設定
80番を開放しないとロードバランサーからWindowsにアクセスできないので注意。
6. Windowsの起動領域30Gだけでは足りないのでディスク追加
t2.micro でインスタンスを作るとWindowsの起動領域は30GBとなる。インスタンスを作ると自動的にディスクが付いてくる。
しかし、30GBでは足りないので、100GBのELB(つまりは外部SSDなどディスク)を追加してDドライブとしてマウントしたい。
Elastic Block Store>ボリューム>ボリューム作成
いろいろあるが汎用SSD gp2かgp3でよい。gp2は既製品。gp3はスループットなど各種項目をカスタマイズできる。
ディスクを追加したら、Windows上の設定>ディスク管理>ディスクを選んでオンライン>初期化>ドライブ割り当て
Dドライブのできあがり(これを作ってからアプリをインストールすべきであろう)
7.Elastic IPを取得してWindowsを固定IP化
Elastic IPとは要は固定IPアドレス。一度取得すればIPアドレスは変動しない。Elastic IPをインスタンス(厳密にはインスタンスそのものではなくてネットワークインターフェイス)と関連付けする。
なお、ALB(ロードバランサー)はPublic IPを持つがAWSが勝手に割り当てるのでElastic IPの設定は不要。つまりロードバランサーは普通に作れば外部からアクセスできる。
8.セキュリティグループの設定
グループ1 プライベートサブネット内しか通信できない&当社固定IPからのみ外部アクセス可能
すなわちインターネット経由の一般ユーザーはすべて遮断。
→Windows Serverほか基本的にすべての部品にこのセキュリティ設定をあてはめる。そうしないとネットワークインターフェイスがPublic IPを持っているのでそこから入られてしまう。
グループ2 インターネット経由の443を通過させる
今回は、外部からの通信はすべてALB経由の前提。ALBにより80は443にリダイレクトされる設定にするので理論上、80でアクセスが来ることはない。よって80を通過させる設定はしない。
→ロードバランサーにはこの設定をあてはめて外部からアクセスできるようにする。
9.ロードバランサーの設定とポイント
ALB(Application Load Balancer)の仕組み
知っておくべきは、ロードバランサーの役目
複数のサーバー(ひとつでもよい=振り分け対象となるサーバー群はターゲットグループと呼ばれる)に対して指定された条件で外部からのアクセスを振り分ける
1.まずは死活監視する条件を指定する
2.ターゲットグループに属するインスタンスを(複数またはひとつ)指定する
3.指定された条件でターゲット(Windows等のインスタンス)を死活監視する
4.死活監視した結果(ping通るか否かなど)を200など番号で返す
5.OKな番号を返した(≒死活監視して生きている)サーバーにだけトラフィックを振り分ける
ロードバランサーの設置してあるアベイラビリティーゾーン、同じサブネットにインスタンスが存在しないと同じネットワーク内にあると認識されないため、pingが届かずヘルスチェックで失敗(unhealthy)となる。
pingで死活を確認するのでWindowsファイアーウォールで外部遮断(初期値)になっているとpingのヘルスチェックで失敗する。
死んでいるサーバーにはリダイレクトしない仕組みなので、ロードバランサーの下にあるサーバーは最初にすべてhealthyになるように設定しないと動かない。
ロードバランサーのリスナー設定
このあたりは正直よく分からない。
ホストヘッダーを設定
ホストヘッダー=サブドメインを含むドメイン名(redmine.cpx.co.jpなど)
として、一致したらALBに転送とすればよいらしい。これをすると、xxx.ap-northeast-1.elb.amazonaws.comなどALBのDNS名などを開いてもアクセスできなくなり、外部からの入口はredmine.cpx.co.jpだけになる。セキュリティ上の施策。
ロードバランサーのリスナー設定はリダイレクトのエラーに注意
ロードバランサーのリスナー設定でヘルスチェックのエラー Health checks failed with these codes [302] が出たということは、http://127.0.0.1/xxx/ を開いたらhttp://127.0.0.1/xxx/login?back_url= などにリダイレクトされてしまった。ということである。これでも生きていることには変わらないので戻り値302もOKという設定にすれば話は早い。
極論、Success codesに200-302など、何が来ても全部OKと設定すればエラーがあっても無理矢理にhealthyにすることができる。だがこのやり方自体がhealthyではない。
ヘルスチェックの設定を変更してもデフォルトでは2回連続チェック成功、チェックインターバル30秒、つまりは1分くらい待たないとヘルシーにならない
制作中
SSL証明書の設定
追記予定
DNSの設定
追記予定
アクセスログの確認
追記予定
ディスクのスナップショットをとってバックアップ
追記予定



