IBM Cloud Virtual Private Cloud (VPC) 構築実践チュートリアル

はじめに

IBM Cloud には従来の Classic と仮想化環境の Virtual Private Cloud (VPC) の二つのプラットフォームが存在します。

Classic の場合はインスタンスのオーダーだけを行えば、 必要に応じて Classic インフラストラクチャーから VLAN が切り出されます。さらに、パブリック接続を指定しておけば、デプロイ後、すぐに外部からアクセスできます。
初期構築の体験が非常に容易です。
(もちろん、オンプレ接続やセキュリティなどには十分な設計が必要ですが)

一方、VPC の場合、仮想化環境を作るところ、つまり仮想化環境を理解するところから始めなければなりません。また、インスタンスがデプロイされてもすぐに外部からアクセスできるわけではありません。
今回 IBM Cloud の VPC 環境を紹介するセミナーを開催する機会があり、デモシナリオを考えました。
そして、ステップ・バイ・ステップチュートリアルとして公開することにしました。
IBM Cloud VPC の体験に役に立てていただければと思います。

全体イメージ

今回のチュートリアルで目指す全体のイメージは下記のとおりです。

作業内容は下記になります。

• 特定のリージョンに VPC を作成します。
• VPC を 3 つのゾーンに展開します。
• 各ゾーンにはサブネットを一つ作成します。
• 最初のサブネットにはふたつのVSIを配置します。
  そのうち、一つ目のVSIはフローティングIPを使って外部からのアクセスを可能にします。
  2つ目のVSIはパブリック・ゲートウェイを使って外部へのアクセスを可能にします。
• 2つ目め、3つ目のサブネットには各々ひとつ、Web サーバーに利用する VSI を配置します。
  Web サーバーの構築はスクリプトを使って自動化します。
• 別々のゾーンにある Web サーバーをアプリケーション・ロード・バランサーで外部公開します。
  稼働できるようにセキュリティー・グループの調整も行います。

クライアント側の準備

図の左上の「USER」が自分の作業用クライアントです。
今回の例では Windows 10 を利用していますが Mac や Linux でも大きな違いはないはずです。

sshキーの作成

今回構築する VSI は すべて CentOS 7 を利用します。
自動ログインを可能にするために作業用クライアントで ssh キーを生成します。

現在の Windows 10 では標準で OpenSSH が利用できます。
標準コマンドの ssh-keygen で鍵ペアを作成します。

ssh-keygen

2023/09/20 追記
Mac での作成方法はこちらなどを確認してください。

VPC、ゾーン、サブネットの作成

最初にリージョンを選び、VPC、ゾーン、サブネットを作成します。

VPC は「東京」や「大阪」といった特定のリージョンに構築する自分の仮想ネットワーク環境です。
VPC は特定のリージョン内の複数のデータセンター (DC) にまたがって構築できます。「東京」も「大阪」も 3つの DC から構築されます。各々の DC の資源のうち自分の VPC で利用する部分をゾーンと呼び、各ゾーンで利用するアドレス範囲を決定します。
サブネットは実際にインスタンスを配置する先です。各ゾーンで利用するアドレス範囲から一部を切り出して作成します。アドレス範囲であれば、複数のサブネットが作成できます。

VPC の作成

VPC 関連リソースにアクセスするアイコンは、こちらです。

VPC をクリックします。

リージョンを選びます。今回は「大阪」を選びました。

「作成」します。

作成先のロケーションを確認し、名前を設定します。
デフォルトで、ロケーション毎に設定されたサブネットが用意されますが、オンプレミス環境や他のVPCとの接続のために、単純に受け入れるのではなく、自分で設計したものに置き換えるべきでしょう。

「デフォルトのアドレスの接頭部」のチェックをはずし、VPC を作成します。

VPC が作成されました。

アドレス接頭部(ゾーン毎のIPの範囲)の指定

VPC で各ゾーンに割り当てる IP の範囲を指定します。
各ゾーンのサブネットは、このアドレス接頭部から切り出します。

今回は下記のように設定しましょう。

ロケーション	IP範囲
大阪1	10.10.0.0/18
大阪2	10.20.0.0/18
大阪3	10.30.0.0/18

作成した PVC を開き「アドレス接頭部」のタブで「作成」します。

IP 範囲とロケーションを指定します。
まず、10.10.0.0/18 を大阪 1 に作成します。

同様に大阪 2、大阪 3のアドレス接頭部を作成します。

アドレス接頭部が作成されました。

サブネットの作成

下記のようにサブネットを作成しましょう。

ロケーション	IP範囲	サブネット名	サブネットの範囲
大阪1	10.10.0.0/18	sn-osa-1	10.10.0.0/24
大阪2	10.20.0.0/18	sn-osa-2	10.20.0.0/24
大阪3	10.30.0.0/18	sn-osa-3	10.30.0.0/24

左メニューから「サブネット」を選び「作成」します。

ロケーションを選択します。
サブネットに名前を付けます。
接続先の VPC を選択します。
サブネットを設定します。
アドレス接頭部を選びアドレスの数を選べば、アドレス接頭部の範囲から、サブネットを切り出してくれます。
アドレス接頭部内の任意の場所にサブネットを作成したい場合はIP範囲にCIDR を直接指定します。
「サブネットの作成」を行います。

同様にsn-osa-2 sn-osa-3 も作成します。

サブネットが作成されました。

仮想インスタンスの作成とフローティング IP での公開

ここでは、仮想インスタンスを作成し、フローティング IPを割り振ります。
フローティング IPを利用すると、外部から直接、インスタンスにアクセスできるようになります。
このインスタンスは VPC への外部ネットワークからの踏み台サーバーに利用します

仮想インスタンスを sn-osa-1 に作成

仮想インスタンスをsn-osa-1 に作成します。

サーバータイプは Intel のパブリックを選択します。
ロケーションを指定し、名前を付けます。
利用する OS を選択します。今回は CentOS を選択しました。
プロファイルで仮想インスタンスの特性やサイズを選択します。
SSH 鍵は後ほど指定しましょう。
ネットワーキングで VPC を選択し、ネットワーク・インターフェースでサブネットを確認します。

チュートリアルの最初で作業用ワークステーションに ssh の鍵ペアを作成しました。
ユーザーのホームディレクトリの中の「.ssh」に「id_rsa.pub」の名前で公開鍵が作成されていますので、この内容で SSH 鍵を登録します。

notepad .ssh\id_rsa.pub

「鍵の作成」をクリックします。

リージョンを確認し、名前を付け、公開鍵に id_rsa.pubの内容を貼り付け「作成」します。

2023/09/02 追記
既存の公開キーの貼り付けだけではなく、キーの生成や公開鍵のアップロードが選択できるようになっていました。

作成した公開鍵を選択し「仮想サーバーの作成」をクリックします。

作成されました。

フローティング IP の割り当て

現在、このインスタンスには VPC 内のプライベートアドレスしか割り当てられていません。
そこで、パブリック IP を付けて外部よりアクセスできるようにしましょう。
「概要」タブでネットワーク・インターフェースの鉛筆アイコンをクリックします。

フローティング IP アドレスを選択するか新規に予約します。
選択後、保存します。

フローティング IP が割り振られました。

フローティング IP への ssh でのアクセス

フローティング IP に対して ssh でアクセスします。

ssh root@[浮動 IP]

鍵ペアで認証され、ssh で接続できました。

外部からの VPC 内のインスタンスへの接続が確認できました。

パブリック・ゲートウェイによる外部への接続

先ほどのインスタンスにはフローティング IP が直接、割り当てられているので、外部からの接続だけではなく外部へのアクセスも可能です。
しかし、外部へはアクセスしたいが外部からはアクセスさせたくない状況も存在します。
すべてのインスタンスに外部から直接接続できるフローティングIP を付けるわけにもいきません。

VPC では サブネットにパブリック・ゲートウェイを接続することで、この要件を実現します。
サブネット内のインスタンスは、パブリック・ゲートウェイ経由で外部にアクセス可能になります。
しかし、外部からは直接アクセスできません。

ここではフローティング IP を持たないインスタンスを作成し、サブネットにパブリック・ゲートウェイを接続することで外部への接続を確認します。

フローティング IP を持たないインスタンスの作成

サブネット sn-osa-1 に、同じ SSH 鍵でもう一つインスタンスを作成します。

先ほどの踏み台サーバーから、このインスタンスへアクセスできるように、作業用クライアントから踏み台サーバーに ssh の秘密鍵をコピーします。

scp .ssh\id_rsa root@[浮動 IP]:/root/.ssh

踏み台サーバーから新規に作成したインスタンスに ssh で接続します。

ssh root@10.x.x.x

新規に作成したインスタンス上で外部への接続を試みます。

ping www.ibm.com

ping に応答がありません。
フローティング IP を持っていないインスタンスから、現時点では外部へのアクセスができないことが確認できます。

パブリック・ゲートウェイの作成

パブリック・ゲートウェイを作成しましょう。

ロケーションを指定します。

名前と PVC を指定し「作成」します。

「切り離し済み」として作成されました。

接続したいサブネットを開きます。パブリックゲートウェイが「切り離し済み」になっているので、クリックします。

接続を選びます。

「接続済み」になりました。

動的に接続が行われました。先ほどの ping 画面に戻ると応答が確認できます。

パブリック・ゲートウェイによる外部への接続が確認できました。

スクリプトを利用したインスタンスの作成

同じ構成で複数のインスタンスを作成したい場合があります。
手動で構築し、次回用のテンプレートとして「カスタム・イメージ」を作成してもよいのですが、構築内容を Infrastructure as Code として再現可能なスクリプトにしておくのも有効です。
今回は Web サーバーを2台、別々のサブネットにスクリプトで構築しましょう。

インスタンスの作成時のユーザー・データの指定

下記は、自分の 10.x.x.x の IPアドレスの情報を index.html に設定した http サーバーを構築するスクリプトです。

#!/bin/sh
yum -y update
yum -y install httpd
ip a | grep '10\.' | echo `cat` | cut -f 2 -d ' ' > /var/www/html/index.html
chmod 644 /var/www/html/index.html
systemctl enable httpd
systemctl start httpd

インスタンスの構築時に、このスクリプトを自動実行させてみましょう。
sn-osa-2 と sn-osa-3 に一つずつ構築します。

下記は sn-osa-2 に作成したイメージです。

大事なのは、詳細オプションのユーザー・データに先ほどのスクリプトが入力されていることです。

同様に sn-osa-3 にも詳細オプションのユーザー・データに先ほどのスクリプトを指定したインスタンスを作成します。

作成されました。プライベート IP アドレスが確認できます。

踏み台サーバーから curl で Web サーバーの稼働を確認しましょう。

curl http://[プライベート IP アドレス]/

同じ VPC 内のため別のゾーン、サブネットであっても接続が可能になっています。
index.html に設定したプライベート IP アドレスが応答として返されます。

※ ポータル上インスタンスが利用可能になっていても、スクリプトの実行が完了しておらず、crul への応答が得られないことがあります。その場合、しばらく待って再度実行してください。

Web サーバーが正しく構築されたのが確認できました。
ただし、このままでは Web サーバーにアクセルできるのは VPC 内のインスタンスに限られます。

ロード・バランサーによる Web サーバーの外部公開

作成した 2 台の Web サーバーをロード・バランサーで外部公開します。

ロード・バランサーの作成

ロード・バランサーを作成します。

ロケーションを確認し、名前を付けます。
ロードバランサーには L7 のアプリケーション・ロード・バランサーと L3 のネットワーク・ロード・バランサーが用意されています。
今回は http に特化した機能を持つ L7 のアプリケーション・ロードバランサーを指定します。
外部公開するロード・バランサーなのでタイプは「パブリック」を選びます。
接続先サブネットは Web サーバーのある sn-osa-2 と sn-osa-3 を指定します。

サブネットの指定は、実際はチェックボックスです。

転送先を指定するバックエンド・プールを作成します。

名前を付け、プロトコルに HTTP を選択します。
セッションは維持せずに、ラウンドロビンでの割り振りとします。

ポート80の「/」へのアクセスをヘルス・チェックとして指定し「作成」します。

バックエンド・プールが作成されましたので、サーバーの接続を行います。

サブネットを選択するとインスタンスが表示されます。

サーバーを選択し、ポートの構成を行います。

サーバーで Listen しているポートである 80 を指定し「接続」します。

「ｖ」をクリックして「＾」にすると接続が確認できます。
作成します。

これで割り振り先が構成できました。

次に。フロントエンド・リスナーを作成します。
フロントエンド・リスナーではロードバランサーが接続要求を受け入れるために Listen するポートを指定します。

転送先であるバックエンド・プールを確認し、ロードバランサーが Listen するポートを指定して作成します。
今回は、通常の HTTP 接続を受け付けるためにポート 80 を指定し「作成」します。

「ロードバランサーの作成」を実行します。

作成されました。

アクセス出来ないことの確認

今回ホスト名に「d0d03595-jp-osa.lb.appdomain.cloud」がアサインされました。
http://d0d03595-jp-osa.lb.appdomain.cloud にアクセスしてみます。
しかし、まだアクセスできません。

バックエンド・プールは正常です。

実はこれは Web サーバーのインスタンスにデフォルトで接続されているセキュリティー・グループが原因です。

セキュリティー・グループのインバウンド・ルールを確認すると同じセキュリティー・グループは全ての接続を許可していますが、それ以外からの TCP 接続はポート 22 に対するものしか許可していません。

先ほど踏み台サーバーから Web サーバーに curl で Web サーバーの応答を確認したときは確かに応答がありました。
これが、踏み台サーバーと Web サーバー が同じセキュリティー・グループに所属していたのでポート 80 への接続も許可されていた結果です。

一方、ロードバランサーはデフォルトのセキュリティー・グループに所属していません。そのためデフォルトのセキュリティー・グループのままではアクセスできません。

セキュリティー・グループの設定

ロードバランサーからのアクセスを許可するためにセキュリティー・グループにルールを追加しましょう。

新しいルールを作成します。

すべてのソースからのポート 80 への接続を許可します。

ルールが追加されました。

ロードバランサーへアクセスするページに戻って、再表示します。
今度は Web サーバーにアクセスできました。

2023/09/02 追記
再表示してもアクセスできない場合、http://... でアクセスしてください。ブラウザーが http:// のアクセスを https:// に自動書き換えしている場合があります。
ブラウザーからではなく「curl -v http://...」でアクセスした方が混乱がないかもしれません。

もう一度、再表示します。
表示されるアドレスが変わりました。正しくラウンドロビンで割り振っているようです。

再表示する度に、表示アドレスが変わります。

まとめ

VPC は Classic 環境に比べ入門の敷居が少し高いかもしれません。
しかし、一度体験して理解してしまえば、モダンな今時の Cloud 環境を利用できるようになります。任意の IP アドレスを指定できますので、オンプレ環境との接続親和性も高くなっています。

ぜひ VPC 環境をお試しいただき。要件に合わせて Classic と使い分けていただければと思います。