目標

• IAM およびリソース・グループを使用してインフラストラクチャーを分離する方法を学習します。
• VPC および関連するリソース (サブネット、ネットワーク ACL、セキュリティー・グループ、インスタンスなど) を作成します。
• DNS Servicesを使用したDNS名前解決によってマイクロサービスをアドレス指定する。
• Transit Gateway を使用して各 VPC を接続します。
• アプリケーションに対して透過的に Load Balancer を構成します。

具体的なアーキテクチャー

以下のアーキテクチャーは、この企業が設定した分離要件と接続要件を実装したものです。 application1、shared、および application2 がそれぞれに VPC であることに注目してください。 どの VPC も単一ゾーン、単一サブネットですが、より細かいマルチゾーンの実装環境に徐々に拡張していくことができます。

開始前に

このチュートリアルでは、以下が必要です。

• IBM Cloud CLI (以下のプラグインを使用):
  • Transit Gateway (tg)
  • IBM Cloud VPC (vpc-infrastructure)
  • DNS Services (dns)
• git: ソース・コード・リポジトリーを複製します。
• terraform: Terraform コマンドを実行します。

ソリューション・チュートリアルを始める ためのガイドに、お使いのオペレーティング環境にこれらのツールをダウンロードしてインストールする手順が記載されています。

さらに、以下を行います。

• ユーザー許可があるか確認してください。 VPC リソースの作成および管理、IBM Cloud® Transit Gateway の作成、および IBM Cloud® Transit Gateway サービスの作成を行えるだけの十分な許可が、使用するユーザーのアカウントにあることを確認してください。 VPC のための必要な許可のリストを参照してください。 また、アクセス・グループ、ポリシー、サービス ID などのリソース・グループおよび IAM リソースを作成する機能も必要です。
• 仮想サーバーに接続するには、SSH 鍵が必要です。 SSH 鍵がない場合は、VPC 用の鍵の作成についての指示を参照してください。

ID およびアクセス管理 (IAM) 環境の計画

管理チームは、他のチームがそれぞれに自チームのリソースを可能な限り自チームで管理できるようにします。 管理チームは、ユーザーの管理とアクセスの制御を行いますが、アーキテクチャー図に示しているリソースの作成と破棄は行いません。

「エディター」、「オペレーター」、「ビューアー」、および「管理者」は、IAM のアクセス役割です。 各役割の正確な意味および各役割に関連付けられるアクションは、サービスごとに定義されています。

チーム:

• 管理 (Admin) - アカウントの構造 (リソース・グループ、アクセス・グループ、ユーザー、役割など) を定義します。
• ネットワーク - ネットワークのリソース (DNS Services、Transit Gateway サービス、VPC、サブネットなど) を作成します。
• 共有 (Shared) - shared VPC に VSI およびブロック・デバイスを作成します。 共有サービスの DNS レコードを作成します。
• アプリケーション 1 (Application1) - application1 VPC に VSI およびブロック・デバイスを作成します。
• アプリケーション 2 (Application2) - application2 VPC に VSI およびブロック・デバイスを作成します。

IAM の概念

ネットワーク・チーム

概念的なチーム別のオーナーシップ・モデルは実装されました。 ネットワーク ・チームは、すべてのネットワーク・リソースを管理するため、図に示されているほとんどのリソースを管理します。

共有チーム

共有 チームは、共有チーム用の分離された VPC 内に VSI を作成します。 さらに、VSIのIPアドレスは作成時に決定されるため、チームはDNSサービスにレコードを書き込む必要がある。 VSI を作成するには、VPC、サブネット、およびセキュリティー・グループに対するオペレーター権限が必要です。

アプリケーション ・チームには、 DNS Servicesに対する管理者権限を除き、 共有 チームと同じアクセス権限が必要です。

アプリケーション・チームのアクセス権限:

IAM アーキテクチャー

リソース・グループと IAM アクセス・グループについて十分に理解している場合は、このセクションは軽く目を通すだけにしてリソースの作成手順を開始してかまいません。

アクセス・グループ

チームごとにアクセス・グループを 1 つ作成します。 アクセス・グループにアクセス・ポリシーを追加してから、ユーザー (チーム・メンバー) をアクセス・グループに追加することで、アクセス権限を付与します。

Transit Gateway サービス・インスタンスは、ネットワーク・チームが単独で管理します。 作成するには、エディター権限が必要です。 作成されたインスタンスに対する管理者権限があれば、VPC を Transit Gateway に接続することができます。

この例では、単一のDNSゾーン widgets.example.com が作成され、そのDNSゾーンへのアクセスがすべてのVPCに許可されます。 DNS Services インスタンスは、ネットワーク・チーム (エディター役割) が作成します。ゾーンを許可するには、管理者役割が必要です。 VPC 上のインスタンスにおける実行時の DNS 解決には、IAM アクセス権限は必要ありません。 共有 チームは、DNS インスタンスのリストを表示 (ビューアー役割) して、A レコードまたは CNAME レコードを追加 (管理者役割) する必要があります。

VPC のインフラストラクチャー・サービス (IS) は、約 15 タイプのサービスで構成されています。 ネットワークACL（アクセス制御リスト）のように、ネットワークチームだけが関心を持つものもある。 また、VSIインスタンスのように、マイクロサービスチームだけが関心を持つものもある。 しかし、サブネットのようにネットワークチームが編集し、マイクロサービスチームが運用するものもある。 ネットワークチームがサブネットを作成し、マイクロサービスチームがサブネットにインスタンスを作成する。 以下の表に、このチュートリアルのための VPC の IS サービスのタイプ、 Transit Gateway、および DNS をアクセス・グループごとにまとめます。 この表の内容が、必要な役割です。

チームの責任に基づいてチームに割り当てられる必要な役割

サービス	ネットワーク	共有	アプリケーション
Transit Gateway	エディター、管理者
DNS	エディター、管理者	ビューアー、管理者
IS: ネットワーク ACL	エディター
IS: インスタンス、ボリューム、浮動 IP、SSH 鍵、イメージ、ロード・バランサー		エディター	エディター
IS: VPC、サブネット、セキュリティー・グループ	エディター	オペレーター	オペレーター

リソース・グループ

共有 チームと ネットワーク・チームは十分に分離されました。 しかし、アプリケーション 1 と、共有およびアプリケーション 2 の分離はどうでしょうか? どれも同じタイプのサービスのエディターです。

ここで役に立つのが、リソース・グループです。 各サービスインスタンス（つまりリソース）は、作成時に初期化され、変更できないリソースグループ属性を持っています。 つまり、各リソースは1つのリソースグループに属している。

リソース・グループの図:

各マイクロサービスチームには、対応するリソースグループでのアクセスが許可される。 ネットワーク ・チームには、それらのすべてのリソース・グループに対する権限が付与されます。

ネットワーク・リソース・グループには、Transit Gateway と DNS サービスが含まれます。 ネットワーク・チームには、これらのリソースに対するアクセス権限があります。 共有チームは、DNSサービスへのマネージャーアクセス権を持つ。 共有チームは、共有サービスの DNS エントリーを作成する必要があります。

チュートリアルの後半で、すべてのリソースが作成された後、IBM Cloudコンソールで リソースリストを開くことは有益です。 リソース・グループをフィルター処理することができます。

ローカルの作業環境を作成する

すべての操作はシェル bash 内で行われ、terraform と ibmcloud コマンドを使用する。 ソリューション・チュートリアルを始める ためのガイドに、お使いのオペレーティング環境にこれらのツールをダウンロードしてインストールする手順が記載されています。

1. Git 以下の リポジトリーを複製します。

   git clone https://github.com/IBM-Cloud/vpc-tg-dns-iam
   cd vpc-tg-dns-iam
   

   各チーム用のディレクトリーが存在することを確認します (ここでは、「application2」はスキップします)。

   • 管理者/
   • network/
   • 共用/
   • application1/

2. terraform.tfvars ファイルを作成します。

   cp terraform.tfvars.template terraform.tfvars
   

   次に、 terraform.tfvars を編集して、以下の変数を設定します。

   • ssh_key_name- it is 必須 to specify an existing SSH key in the ibm_region as specified in the 始める前に section above.
   • ibm_region -必要に応じて、デフォルト値 us-south を置き換えます。 cli コマンド ibmcloud regions を実行すると、すべてのリージョンが表示されます。
   • basename -デフォルト値 widget0 を、必要な場合は 7 文字以下の名前に置き換えます。 作成されるリソースのほとんどに、これが名前の接頭語として使用されます。
   • この時点では、transit_gateway または shared_lb のコメントを外さないでください。

3. Windows ユーザーのみ：git が Windows コンピューター上でシンボリックリンクを作成しない場合は、ファイルの内容をチームフォルダーにコピーする必要があります：

   cp variables.tf terraform.tfvars admin
   cp variables.tf terraform.tfvars network
   cp variables.tf terraform.tfvars shared
   cp variables.tf terraform.tfvars application1
   

export TF_VAR_ibmcloud_api_key=0thisIsNotARealKeyALX0vkLNSUFC7rMLEWYpVtyZaS9

provider ibm {
 ibmcloud_api_key = var.ibmcloud_api_key # initialized with the TF_VAR_ibmcloud_api_key
}

ibmcloud login --apikey $TF_VAR_ibmcloud_api_key

IAM 対応リソースを作成する (管理チーム)

管理チームには、このチュートリアルで使用するアカウントの IAM 対応リソースに対する管理権限が必要です。 ユーザーをアカウント管理者に指定して全アクセス権限を割り当てる方法を教えてくださいを参照してください。 管理チームは、IAM リソースの作成を担当します。 以下の手順では、ibmcloud iam api-key-create コマンドを使用して、管理者用の API キーを作成します。 API キーは、Terraform でユーザーの代わりにタスクを実行するために使用されます。

PIキーはアカウントのパスワードと同じです。 この API キーは安全に保管してください。

1. シェル変数 basename を初期化して確認します。 terraform.tfvars ファイルの basename と一致することを確認します。

   eval $(grep basename terraform.tfvars | sed -e 's/  *//g' -e 's/#.*//')
   echo basename=$basename
   

2. ディレクトリーを変更し、個人用の API キーを local.env 内に生成し、source を実行して読み込みます。 呼び出された Terraform は、呼び出したユーザーになります。 ここでは、Terraform は管理者になります。

   cd admin
   echo export TF_VAR_ibmcloud_api_key=$(ibmcloud iam api-key-create $basename-admin --output json | jq .apikey) > local.env
   cat local.env
   source local.env
   

3. Terraformの設定ファイルを適用すると、以下のリソースが作成される main.tf

   • 各チームのリソース・グループ
   • 各チームのアクセス・グループと各アクセス・グループのサービス ID
   • リソース・グループのアクセス・グループ・ポリシー
   • リソースのアクセス・グループ・ポリシー

   terraform init
   terraform apply
   

4. リソースが作成されたことを確認します。

   ibmcloud resource groups | grep $basename
   

   ibmcloud iam access-groups | grep $basename
   

   ibmcloud iam service-ids | grep $basename
   

   ibmcloud iam access-group-policies $basename-network
   

   出力は以下のようになります。

   $ ibmcloud resource groups | grep $basename
   widget0-application2   36b06a303f224f28ad42aebbb491cc44   false           ACTIVE
   widget0-shared         91518c45e47a427fa4f63edb58e4f227   false           ACTIVE
   widget0-network        bf6e75cd71854576a31056abced2abf0   false           ACTIVE
   widget0-application1   db2f3dc8aacf4a6aa2d2fa07e795cb57   false           ACTIVE
   $ ibmcloud iam access-groups | grep $basename
   widget0-application1   AccessGroupId-26b7ef37-78db-4a2c-a2af-7f6591e73c15   application1 administrators
   widget0-application2   AccessGroupId-8afdec20-f760-4a15-8f3e-296d81818028   application2 administrators
   widget0-network        AccessGroupId-d50b129d-9adc-4fc4-b297-487b3f938ec5   network administrators
   widget0-shared         AccessGroupId-30d73f44-5602-47a7-846e-e6480c9dceff   shared administrators
   $ ibmcloud iam service-ids | grep $basename
   ServiceId-5e919b97-380c-4343-a337-3901cafbd956   widget0-application2                                                                                                       2020-07-15T21:25+0000   2020-07-15T22:03+0000   application 2 service id                                                                                                                                              false
   ServiceId-307df062-f4b7-45f8-8ec8-94ad1ed61730   widget0-network                                                                                                            2020-07-15T21:49+0000   2020-07-15T22:03+0000   network service id                                                                                                                                                    false
   $ ibmcloud iam access-group-policies $basename-network
   Retrieving all policies of access group widget0-network under account 8675309 as jenny@example.com
   OK
   
   Policy ID:   00ceb354-7360-4ad5-9fda-5c03e462c5c0
   Roles:       Editor
   Resources:
                Resource Group ID     91518c45e47a427fa4f63edb58e4f227
                Resource Group Name   widget0-shared
                Service Name          is
                flowLogCollectorId    *
                Memo                  Policy applies to the resource(s) within the resource group
   
   Policy ID:   115ebe9f-eea0-4308-9e7f-bb887d64426b
   Roles:       Editor
   Resources:
                Resource Group ID     db2f3dc8aacf4a6aa2d2fa07e795cb57
                Resource Group Name   widget0-application1
                Service Name          is
                vpnGatewayId          *
                Memo                  Policy applies to the resource(s) within the resource group
   ...
   

5. オプションで、アカウント Resource groupsに移動し、リソースグループを見つける。

6. アクセス・グループを表示するには、「アクセス・グループ」に移動し、アクセス・グループをクリックしてから、上部にある「サービスID」 パネルをクリックして、作成されたサービスIDを確認します。

VPC および DNS を作成する (ネットワーク・チーム)

ネットワーク・チームは、接続目標を満たして各チームがそれぞれのチームの VPC に分離されるように、アーキテクチャーに合致したネットワーク・リソースを作成します。 VPC インスタンスの詳細を制御する必要はありません。 アプリケーションの数、コンピュータのサイズ、マイクロサービスのDNSレコードなどは常に流動的で、*ネットワーク・*チームの関心事ではないだろう。

管理チームは、VPC の IS リソース、DNS Services 、および Transit Gateway サービスを作成できるだけの適切な権限をネットワーク・チームに提供しておきます。

1. ディレクトリを変更し、local.env でAPIキーを生成し、ネットワーク・アクセス・グループのメンバーになる：

   team=network
   cd ../$team
   echo export TF_VAR_ibmcloud_api_key=$(ibmcloud iam service-api-key-create $team $basename-$team --output json | jq .apikey) > local.env
   cat local.env
   source local.env
   

2. オプションで、variables_network.tf ファイルを開き、CIDRブロック指定とゾーンレイアウトに注目する。 以下のスニペットでは、sharedと application1がIPアドレスを重複させずに指定されていることに注目してほしい：

   variable network_architecture {
     default = {
       shared = {
         cidr        = "10.0.0.0/16"
         cidr_remote = "10.0.0.0/8"
         zones = {
           z1 = {
             zone_id = "1",
             cidr    = "10.0.0.0/24",
           }
           z2 = {
             zone_id = "2",
             cidr    = "10.0.1.0/24",
       ...
       application1 = {
         cidr        = "10.1.0.0/16"
         cidr_remote = "0.0.0.0"
         zones = {
           z1 = {
             zone_id = "1",
             cidr    = "10.1.0.0/24",
           }
           z2 = {
             zone_id = "2",
             cidr    = "10.1.1.0/24",
        ...
   

   Transit Gateway は、各 VPC に接続し、CIDR 範囲に基づいてトラフィックをルーティングします。 そのため、重複を回避することで成功が保証されます。

3. リソースを作成します。

   terraform init
   terraform apply
   

4. VPC リソースのリストを表示します。

   作成された VPC リソースが、以下に示すように、subnets コマンドの出力 (簡潔に示すために編集しています) にまとめて表示されます。 3つのVPC、重複しないCIDRブロック、リソースグループのメンバーシップに注目してください：

   ibmcloud target -r $(grep ibm_region terraform.tfvars | sed -e 's/  *//g' -e 's/#.*//' -e 's/.*=//' -e 's/"//g')
   ibmcloud is subnets --all-resource-groups | grep $basename
   

   出力は次のようになります。

   $ ibmcloud is subnets --all-resource-groups | grep $basename
   widget0-shared-z1           available   10.0.0.0/24    widget0-shared           us-south-1   widget0-shared
   widget0-shared-z2           available   10.0.1.0/24    widget0-shared           us-south-2   widget0-shared
   widget0-shared-z3           available   10.0.2.0/24    widget0-shared           us-south-3   widget0-shared
   widget0-application1-z1     available   10.1.0.0/24    widget0-application1     us-south-1   widget0-application1
   widget0-application1-z2     available   10.1.1.0/24    widget0-application1     us-south-2   widget0-application1
   widget0-application1-z3     available   10.1.2.0/24    widget0-application1     us-south-3   widget0-application1
   widget0-application2-z1     available   10.2.0.0/24    widget0-application2     us-south-1   widget0-application2
   widget0-application2-z2     available   10.2.1.0/24    widget0-application2     us-south-2   widget0-application2
   widget0-application2-z3     available   10.2.2.0/24    widget0-application2     us-south-3   widget0-application2
   

5. オプションで、Virtual Private Cloudsに移動し、上記で作成したVPC、サブネット、その他すべてのリソースを見つけます。

6. オプションとして、DNS Servicesの初期化を理解するためにTerraformの設定を main.tf 調査する。 DNS Services のインスタンスおよびゾーンは、次の Terraform スニペットを使用して作成されました。

   resource "ibm_resource_instance" "dns" {
     name              = "${var.basename}-dns"
     resource_group_id = data.ibm_resource_group.shared.id
     location          = "global"
     service           = "dns-svcs"
     plan              = "standard-dns"
   }
   
   resource "ibm_dns_zone" "widgets_example_com" {
     name        = "widgets.example.com"
     instance_id = ibm_resource_instance.dns.guid
     description = "this is a description"
     label       = "this-is-a-label"
   }
   

   その後、許可されるネットワークとして、ゾーンが VPC に追加されました。

   resource "ibm_dns_permitted_network" "shared" {
     instance_id = ibm_resource_instance.dns.guid
     zone_id     = ibm_dns_zone.widgets_example_com.zone_id
     vpc_crn     = module.vpc_shared.vpc.crn
     type        = "vpc"
   }
   
   

7. DNS 構成のリストを表示します。 DNS Services インスタンスが作成されています。 widgets.example.com ゾーンが作成されました。 最後に、ゾーンをすべてのVPCに追加した。

   ibmcloud dns instances
   

   ibmcloud dns zones -i $basename-dns
   

   zone_id=$(ibmcloud dns zones -i $basename-dns --output json | jq -r '.[] | .id')
   ibmcloud dns permitted-networks $zone_id -i $basename-dns
   

   出力はこのようになる：

   $ ibmcloud dns instances
   Retrieving service instances for service 'dns-svcs' ...
   OK
   Name          ID                                     Location   State    Service Name   
   widget0-dns   3b0d5546-5999-4c7e-a757-f5fd21dd44ed   global     active   dns-svcs   
   $ ibmcloud dns zones -i $basename-dns
   Listing zones for service instance 'widget0-dns' ...
   OK
   ID                                               Name                  Status   
   5a1a2295-1c38-49dd-9809-aaaf5a127e79c1b          widgets.example.com   ACTIVE   
   $ zone_id=$(ibmcloud dns zones -i $basename-dns --output json | jq -r '.[] | .id')
   $ ibmcloud dns permitted-networks $zone_id -i $basename-dns
   Listing permitted networks for zone '5a1a2295-1c38-49dd-9809-f5a127e79c1b' ...
   OK
   Name                   ID                                          Type   VPC_CRN                                                                                                               State   
   widget0-shared         r006-353208ab-4e95-46fb-934b-b5566cde8975   vpc    crn:v1:bluemix:public:is:us-south:a/713c783d9a507a53135fe6793c37cc74::vpc:r006-353208ab-4e95-46fb-934b-b5566cde8975   ACTIVE   
   widget0-application1   r006-287258c6-2eb3-4908-b326-6f03c3e47aa6   vpc    crn:v1:bluemix:public:is:us-south:a/713c783d9a507a53135fe6793c37cc74::vpc:r006-287258c6-2eb3-4908-b326-6f03c3e47aa6   ACTIVE   
   widget0-application2   r006-fa51e99e-bd93-4451-a4eb-76eed9939d3c   vpc    crn:v1:bluemix:public:is:us-south:a/713c783d9a507a53135fe6793c37cc74::vpc:r006-fa51e99e-bd93-4451-a4eb-76eed9939d3c   ACTIVE   
   

8. オプションとして、リソースリストに移動し、DNS Services を見つけ、それをクリックして調査する。

共有マイクロサービスと関連するDNSレコードを作成する(共有チーム)

1. ディレクトリを変更し、local.env でAPIキーを生成し、共有アクセスグループのメンバーになる：

   team=shared
   cd ../$team
   echo export TF_VAR_ibmcloud_api_key=$(ibmcloud iam service-api-key-create $team $basename-$team --output json | jq .apikey) > local.env
   cat local.env
   source local.env
   

2. オプションとして、この時点でTerraformのソースコードを深く掘り下げる。 共有チームはマイクロサービスを提供する。 ネットワーク・チームが既に Shared VPC および一部のネットワーク・リソースを作成しましたが、Shared チームはこれからインスタンスを作成し、インスタンス・プロファイルを選択します。 Linux 構成スクリプトと単純なデモ・アプリケーションを user_data 属性で指定します。これについては、後で 『アプリケーション・チーム』 セクションで説明します。

   main.tf で、以下の 2 つのリソースを確認してください。

   locals {
     network_context = data.terraform_remote_state.network.outputs.shared
   }
   
   resource ibm_is_instance "vsishared" {
     name           = "${var.basename}-shared-vsi"
     vpc            = local.network_context.vpc.id
     resource_group = data.ibm_resource_group.shared.id
     zone           = local.network_context.subnets["z1"].zone
     keys           = [data.ibm_is_ssh_key.ssh_key.id]
     image          = data.ibm_is_image.image.id
     profile        = var.profile[var.generation]
   
     primary_network_interface {
       subnet = local.network_context.subnets["z1"].id
       security_groups = [
         local.network_context.security_group_outbound_all.id, # nodejs is not available on an IBM mirror
         local.network_context.security_group_ibm_dns.id,
         local.network_context.security_group_data_inbound.id,
       ]
     }
     user_data = module.user_data_app.user_data_centos
   }
   
   resource ibm_dns_resource_record "shared" {
     count = var.shared_lb ? 0 : 1 # shared load balancer?
     instance_id = local.network_context.dns.guid
     zone_id     = local.network_context.dns.zone_id
     type        = "A"
     name        = "shared"
     rdata       = ibm_is_instance.vsishared.primary_network_interface[0].primary_ip.address
     ttl         = 3600
   }
   

   上記の local.network_context は、ネットワーク・チームが Shared チームのためだけに作成した出力です。

3. 共有のリソースを作成します。

   terraform init
   terraform apply
   

4. オプションで、Virtual server instances for VPCに移動し、共有インスタンスを見つけます。 インスタンスをクリックして以下を確認します。

   • インスタンスにパブリック・インターネットからの着信接続がない (「セキュリティー・グループ」を確認してください)
   • プライベート IP アドレス

5. オプションとして、リソースリストに移動し、DNS Services を見つけ、それをクリックし、共有された名前のDNSレコードを見つける。 「値」は、インスタンスのプライベート IP アドレスです。

あるアプリケーションApplication1Team)に対して、一般公開されるマイクロサービスを作成する

1. ディレクトリーを変更し、API キーを local.env 内に生成し、Application1 アクセス・グループのメンバーになります。

   team=application1
   cd ../$team
   echo export TF_VAR_ibmcloud_api_key=$(ibmcloud iam service-api-key-create $team $basename-$team --output json | jq .apikey) > local.env
   cat local.env
   source local.env
   

   Application1 チームのリソースは、Shared チームのリソースと非常によく似ています。 実際には、DNS Servicesにレコードを入れる必要はないので、もう少し単純です。 アプリケーションはアドレス http://shared.widgets.example.com て共有マイクロサービスにアクセスする。

2. オプションとして、CentOSインスタンスを初期化するソースコードを調査する。 この探索段階では、全チームが共有するTerraformモジュールに取り込まれている。

   ../common/user_data_app/main.tf:

   locals {
     shared_app_user_data_centos = <<EOS
   #!/bin/sh
   curl -sL https://rpm.nodesource.com/setup_20.x | sudo bash -
   yum install nodejs -y
   cat > /app.js << 'EOF'
   ${file("${path.module}/app.js")}
   EOF
   cat > /lib/systemd/system/a-app.service << 'EOF'
   ${file("${path.module}/a-app.service")}
   EOF
   systemctl daemon-reload
   systemctl start a-app
   EOS
   }
   
   output user_data_centos {
     value = replace(local.shared_app_user_data_centos, "REMOTE_IP", var.remote_ip)
   }
   

   詳しい説明:

   • curl コマンドと yum コマンドを使用して Nodejs をインストールしています
   • nodejs アプリケーションを /app.js に配置しています
   • app.js 用の systemctl サービスを作成しています
   • サービスを始動しています

3. オプションで、app.js の内容を確認します。 特に興味深いセクションが 2 つあります。 まず、アプリを実行しているインスタンスの説明を返す/infoリンクがある。 ../common/user_data_app/app.js:

   const server = http.createServer((req, res) => {
     switch(req.url) {
     case '/info':
       res.statusCode = 200;
       res.setHeader('Content-Type', 'application/json');
       res.end(JSON.stringify({
         req_url:  req.url,
         os_hostname:  os.hostname(),
         ipArrays: ips()
       }, null, 3));
       break
     case '/remote':
       getRemote(req, res)
       break
   

   次に、/remoteリンクはリモートサーバーのIPを呼び出し、リモートへのアクセスに使用されるremote_urlとremote_ipアドレスとともに、そのリモートの説明を返します。

   const IP='REMOTE_IP'
   
   function getRemote(req, res) {
     path = '/info'
     remote_url = 'http://' + IP + ':3000' + path
     http.get(remote_url, (resp) => {
       let rawData = '';
       resp.on('data', (chunk) => { rawData += chunk; });
       resp.on('end', () => {
         try {
           console.log(rawData)
           rawObj = JSON.parse(rawData)
           res.statusCode = 200;
           res.end(JSON.stringify({remote_url: remote_url, remote_ip: resp.connection.remoteAddress, remote_info: rawObj}, null, 3))
   

   In our case the REMOTE_IP will be shared.widgets.example.com because of the following in common/user_data_app/main.tf:

   output user_data_centos {
     value = replace(local.shared_app_user_data_centos, "REMOTE_IP", var.remote_ip)
   }
   

   また、application1/main.tf にも以下が指定されています。

   module user_data_app {
     source    = "../common/user_data_app"
     remote_ip = "shared.widgets.example.com"
   }
   

4. リソースを作成します。

   terraform init
   terraform apply
   

   次のような結果になります。

   $ terraform apply
   ...
   Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
   
   Outputs:
   
   ibm1_private_ip = "10.1.0.4"
   ibm1_public_ip = "52.116.140.202"
   test_info = "curl 52.116.140.202:3000/info"
   test_remote = "curl 52.116.140.202:3000/remote"
   

   上記の 2 つの curl コマンド (test_info、 test_remote) を試してください。 出力からステートメントをコピーします。

   curl 52.116.140.202:3000/info
   

   最初の結果は、以下のようなものになります。

   {
      "req_url": "/info",
      "os_hostname": "widget0-application1-vsi",
      "ipArrays": [
         [
            "10.1.0.4"
         ]
      ]
   }
   

   次に、2 番目のコマンド (出力から) を試行します。

   curl 52.116.140.202:3000/remote
   

   2 つ目の curl コマンドが機能しなかったはずです。 次のステップで修正します。 これらのcurlコマンドは覚えておこう。

Transit Gateway の作成

IBM Cloud Transit Gatewayは IBM Cloudを相互接続するためのネットワークサービスです。VPCリソースを相互接続するために使用されるネットワークサービスで、動的なスケーラビリティ、高可用性、データが公共のインターネットを経由していないという安心感を提供します。 先ほど、Transit Gateway で IP アドレスに基づいてパケットをルーティングするために、各 VPC の CIDR ブロックをオーバーラップしないように選択しました。

1. ディレクトリーを変更し、ネットワーク・グループのメンバーになります (既存の API キーを使用します)。

   cd ../network
   source local.env
   

2. オプションで、terraform ファイルを確認します。 main.tf ファイルを開き、Transit Gateway リソース (ibm_tg) を見つけます。 それぞれ count = var.transit_gateway ? 1 : 0 と指定されています。 これは、transit_gateway の値に基づいて、長さ 1 または 0 のリソースの配列を作成する Terraform のコンストラクトです。 長さ 0 の配列の場合、リソースは作成されません。 以下に例を示します。

   resource "ibm_tg_gateway" "tgw"{
     count = var.transit_gateway ? 1 : 0
     name              = "${var.basename}-tgw"
     location          = var.ibm_region
     global            = false
     resource_group    = data.ibm_resource_group.network.id
   }
   

3. ファイルを terraform.tfvars 編集し、Transit Gatewayのプロビジョニングを有効にする行の transit_gateway = true コメントを解除する。

4. 変更を適用します。

   terraform apply
   

5. 以下のコマンドを使用して Transit Gateway を出力します。

   ibmcloud tg gateways
   GATEWAY_ID=$(ibmcloud tg gateways --output json | sed -e '/^OK$/d' | jq -r '.[]|select(.name=="'$basename-tgw'")|.id')
   ibmcloud tg connections $GATEWAY_ID
   

   出力に 3 つの VPC 接続が含まれていることを確認します。 次のような出力になります。

   $ ibmcloud tg gateways
   Listing gateways under account
   OK
   
   GatewayID           e2801c16-1a6d-4d47-9c58-1a3b3c1d9b1b
   CRN                 crn:v1:bluemix:public:transit:us-south:a/86785309::gateway:e2801c16-1a6d-4d47-9c58-1a3b3c1d9b1b
   Name                widget0-tgw
   Routing             local
   Location            us-south
   Created             2020-07-16T09:09:38.048-07:00
   Resource group ID   bf6e75cd71854576a31056abced2abf0
   Status              available
   
   $ GATEWAY_ID=$(ibmcloud tg gateways --output json | sed -e '/^OK$/d' | jq -r '.[]|select(.name=="'$basename-tgw'")|.id')
   $ ibmcloud tg connections $GATEWAY_ID
   Listing connections for gateway e2801c16-1a6d-4d47-9c58-1a3b3c1d9b1b under account
   OK
   
   Name                    widget0-shared
   Network Type            vpc
   Connection ID           dff6ecfd-388d-471a-908a-98880426fbee
   Status                  attached
   Default Prefix Filter   permit
   NetworkID               crn:v1:bluemix:public:is:us-south:a/86785309::vpc:r006-b08a7c2c-c0ea-4908-b0ab-b96cd8ba221a
   
   Name                    widget0-application1
   Network Type            vpc
   Connection ID           bbce29f9-9ce4-47d4-911d-5341601cea07
   Status                  attached
   Default Prefix Filter   permit
   NetworkID               crn:v1:bluemix:public:is:us-south:a/86785309::vpc:r006-8fdc0e7e-3a98-4f6b-93e0-505c61e3faac
   
   Name                    widget0-application2
   Network Type            vpc
   Connection ID           208c00cc-aee2-498e-8b1c-37ddc276f200
   Status                  attached
   Default Prefix Filter   permit
   NetworkID               crn:v1:bluemix:public:is:us-south:a/86785309::vpc:r006-fa80afa7-b16b-4db7-95dd-69a558db4285
   

6. オプションで Transit Gatewayをナビゲートし、上記で作成したゲートウェイを見つけます。

7. 上で失敗した curl コマンドを実行し、application1VPC から共有 VPC へのパスがあることを確認します。 出力は、次のようになります。

   $ curl 169.48.152.220:3000/remote
   
   {
      "remote_url": "http://shared.widgets.example.com:3000/info",
      "remote_ip": "10.0.0.4",
      "remote_info": {
         "req_url": "/info",
         "os_hostname": "widget0-shared-vsi",
         "ipArrays": [
            [
               "10.0.0.4"
            ]
         ]
      }
   }
   

Load Balancer を挿入して DNS レコードを置き換える

1. ディレクトリーを変更し、Shared アクセス・グループのメンバーになります (既存の API キーを使用します)。

   cd ../shared
   source local.env
   

2. オプションで、terraform 構成ファイルを確認します。 Load Balancer for VPC サービスは、VPC の同一リージョン内の複数のサーバー・インスタンス間にトラフィックを分散させます。 Shared チームは、複数のインスタンス間に負荷を分散させることができます。 現時点では、ロード・バランサー・プールには、先ほど作成した単一のインスタンスしかありません。 実装については lb.tf を参照のこと。 ibm_is_lb リソースで、dns 節を使用して、ロード・バランサーの DNS アドレスを配置するプライベート DNS ゾーンを識別します。

   resource "ibm_is_lb" "shared_lb" {
     ...
     dns {
       instance_crn = local.network_context.dns.crn
       zone_id      = local.network_context.dns.zone_id
     }
   }
   

3. ロード・バランサーを識別する DNS CNAME レコード shared.widgets.example.com を指定して、ソース・コードを変更せずにアプリケーションが引き続き機能するようにします。

   # shared.widgets.example.com
   resource ibm_dns_resource_record "shared_lb" {
     count = var.shared_lb ? 1 : 0 # shared load balancer?
     instance_id = local.network_context.dns.guid
     zone_id     = local.network_context.dns.zone_id
     type        = "CNAME"
     name        = "shared"
     rdata       = ibm_is_lb.shared_lb[0].hostname
     ttl         = 3600
   }
   

   同じ count = var.shared_lb ? 1 : 0 が使われている。 ロード・バランサーのホスト名は、 b7911a41-us-south.widgets.example.com のようになります。 CNAME レコードはアプリケーションによって使用されます。

4. Edit the terraform.tfvars file and uncomment shared_lb = true. 次に、変更を適用します。

   terraform apply
   

5. 前のapplication1セクションの curl .../remote コマンドを実行します（共有マイクロサービス用に生成された出力は無視します）。 remote_ip はロードバランサーの10.0.1.4で、remote_info はインスタンスの10.0.0.4であることに注意してください。 さらに数回Curlを行い、ロードバランサーの remote_ip が変更される可能性があることに注意してください。

   $ curl 169.48.152.220:3000/remote
   
   {
      "remote_url": "http://shared.widgets.example.com:3000/info",
      "remote_ip": "10.0.1.4",
      "remote_info": {
         "req_url": "/info",
         "os_hostname": "widget0-shared-vsi",
         "ipArrays": [
            [
               "10.0.0.4"
            ]
         ]
      }
   }
   

アプリケーションの一般向けマイクロサービスを作成するApplication2Team)

2 つ目のアプリケーション・チーム環境は、1 つ目のものと同じです。 オプションで 、 application1を変更して application2 を作成します。

1. ./application1 ディレクトリーに入り、application2 ディレクトリーを作成します。

   cd ../application1
   mkdir ../application2
   sed -e 's/application1/application2/g' main.tf > ../application2/main.tf
   cp terraform.tfvars variables.tf versions.tf ../application2
   

2. ディレクトリを変更し、local.env でAPIキーを生成し、application2 アクセスグループのメンバーになる：

   team=application2
   cd ../$team
   echo export TF_VAR_ibmcloud_api_key=$(ibmcloud iam service-api-key-create $team $basename-$team --output json | jq .apikey) > local.env
   cat local.env
   source local.env
   

3. リソースを作成します。

   terraform init
   terraform apply
   

4. curl コマンドをテストします。

リソースを削除する

1. リソースの破棄 チーム・ディレクトリを順番に cd)に変更し、source local.env; terraform destroy を実行することができる。 application2、application1、shared、network、admin の順に実行します。 これを自動的に実行するスクリプトもあります。

   cd ..
   ./bin/destroy.sh
   

チュートリアルを発展させる

まとめ

システムのアーキテクチャーは、クラウドのリソースの区画および所有権によって制御されます。 システムのあらゆる側面の設計者が、アーキテクチャーに設計に寄与することが重要です。 各チームが、自チームで生成してリリースするリソースを制御できなければなりません。 分離することで、問題が発生する可能性が低くなり、問題が発生した場合の影響範囲を抑えることができます。

関連コンテンツ

• チュートリアル 仮想プライベートクラウドにおけるパブリックフロントエンドとプライベートバックエンド、
• チュートリアル: Terraform を使用した LAMP スタックのデプロイ