(連載) HashiCorp活用例4: 動的ロードバランサの構築
東京エレクトロンデバイスではHashiCorp社製品とその他各社製品とのマルチベンダー連携を通じて、お客様のWebアプリやクラウド、ITインフラなどの展開から運用までを効率化できるソリューション開発に取り組んでいます。さまざまな活用例をご紹介することで、HashiCorp社製品の提供する価値や可能性を発信していきたいと思っております。
はじめに
本記事で取り扱うのは動的ロードバランサの構築となります。
初回の記事で取り上げたユースケースに基づいて記載しておりますので、ユースケースの詳細につきましては過去の記事も併せてご参照ください。
連載記事一覧：
- Webアプリ用マルチベンダーインフラの自動構築
- 動的なバックエンドSSL証明書の管理
- 動的なDNSレコード管理
- 動的なロードバランサの構築 ←本記事
- プライベートネットワークでのIaC
- 一連のWebアプリ用のマルチベンダーインフラ展開を効率化
動的なロードバランサの構築
本ユースケースの構成では、F5 BIG-IPを用いて動的ロードバランサを実現しています。
バックエンドで稼働するアプリケーションVM群は負荷状況に応じて増減（スケールアウト/イン）することを考えなければなりません。前回の記事では増減に伴う動的なDNSレコードの追加について解説しましたが、アクセスの分散を行うロードバランシングも動的に更新が行われるべきです。
クラウド環境においては各ベンダーが用意したロードバランシングを利用することも可能ですが、今回はBIG-IP VE(Virtual Edition)という製品を使用することにより、動的なロードバランシングが可能な構成を実現しています。
参考サイト：
F5 BIG-IP VE 仮想アプライアンスの構築と設定
以下の流れで環境を構築していきます
- BIG-IP VE 仮想アプライアンスの構築
- バランシングの設定
BIG-IP VE 仮想アプライアンスの構築
今回のデプロイ環境(Microsoft Azure)では、クラウド版のイメージがマーケットプレイスから提供されているため、そちらを利用して仮想アプライアンスを構築していきます。
仮想アプライアンスの構築は、前回記事のWebアプリケーション用VMを構築する際に利用したterraform-azurerm-linux-vmモジュールを利用しています。
※マーケットプレイスのVMイメージを使用する際、初めて利用するVMイメージの場合、Agreementへの同意を求められる場合があります。その際はAgreementの設定も記載が必要です。（前回記事参照）
※Terraform構成ファイルの記述サンプル
module "f5" {
source = "./modules/terraform-azurerm-linux-vm" ←モジュールの参照先
resource_group_name = リソースグループ名
ssh_pub_key = ""
subnet_name = 所属するサブネット名
network_name = 所属するネットワーク名
tags = タグ
vm_size = インスタンスサイズ
admin_username = 初期ユーザー名
admin_password = 初期ユーザーパスワード
disable_password_authentication = false ←パスワードを用いた認証拒否の設定
marketplace = true ←マーケットプレイスの利用
accept_marketplace_agreement = true ←マーケットプレイス利用に伴うAgreement
vm_name = "VM名"
prefix = "ted-f5"
image_offer = "f5-big-ip-good" ←VMイメージのオファー
image_publisher = "f5-networks" ←VMイメージの発行元
image_sku = "f5-bigip-virtual-edition-25m-good-hourly" ←SKUの指定
image_version = "16.1.304000" ←イメージのバージョン指定
create_storage_account = true ←ストレージアカウントの作成可否
# 以下、セキュリティグループの設定
rules = [
{
name = "https"
priority = "101"
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "443"
source_address_prefix = "*"
destination_address_prefix = "*"
description = "Allow HTTPS from the Internet to all VMs"
},
{
name = "https-8443"
priority = "102"
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "8443"
source_address_prefix = "x.x.x.x" ←BIG-IPへの管理アクセス用に特定のパブリックIPを指定
destination_address_prefix = "*"
description = "Allow https-8443 from specific address to all VMs"
},
{
name = "ssh"
priority = "103"
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "22"
source_address_prefix = "x.x.x.x" ←BIG-IPへの管理アクセス用に特定のパブリックIPを指定
destination_address_prefix = "*"
description = "Allow ssh from specific address to all VMs"
}
]
}
バランシングの設定
次にバランシングの設定内容を記述したサンプルを示します。上記仮想アプライアンスの構築と下記バランシングの設定は同じワークスペースで管理されています。
※Terraform構成ファイルの記述サンプル ◆DNS設定 resource "bigip_sys_dns" "dns" { description = "DNS Servers, Infoblox and Azure built-in dns server." name_servers = ["InfobloxサーバーのIP", "Azureの公開DNSサーバー"] search = [対象ドメイン] } ※Infoblox は前回記事で構築したDNSサーバー ◆サーバー証明書の登録 resource "bigip_ssl_certificate" "sslcert" { name = "証明書名" content = サーバー証明書の内容(PEM) partition = パーティション設定 } ◆サーバー証明書秘密鍵設定 resource "bigip_ssl_key" "sslkey" { name = "秘密鍵名" content = サーバー証明書の秘密鍵の内容(PEM) partition = パーティション設定 } ◆クライアントSSLプロファイル設定 resource "bigip_ltm_profile_client_ssl" "ClientSsl" { name = "プロファイル名（フルパス）" cert = "使用する証明書名" key = "使用する秘密鍵名" depends_on = [bigip_ssl_certificate.sslcert, bigip_ssl_key.sslkey] ←依存リソースの指定 } ◆サーバープール設定 resource "bigip_ltm_pool" "pool" { name = "プール名（フルパス）" load_balancing_mode = "round-robin" ←負荷分散方法。デフォルトはラウンドロビンです monitors = ["プールに関連付けるモニター名（リスト形式）"] } ◆サーバープール内のノード設定 resource "bigip_ltm_pool_attachment" "attach_nodes" { for_each = var.pool_members pool = プール名 node = each.value ←プールメンバーのサービス ポートを含むアドレス/FQDN depends_on = [bigip_ltm_pool.pool] ←依存リソースの指定 } ※for_eachを使うことでvariable: pool_membersにmap形式で格納した値をnodeで呼び出しています。 ◆バーチャルサーバーを作成 resource "bigip_ltm_virtual_server" "virtualserver" { name = "バーチャルサーバー名（フルパス）" description = "説明文" destination = 宛先IP port = リッスンポート pool = デフォルトのプール名 client_profiles = [利用するクライアントSSLプロファイル] server_profiles = [利用するサーバーSSLプロファイル] source_address_translation = "automap" ←送信元アドレス変換(Source NAT)のルール depends_on = [bigip_ltm_profile_client_ssl.ClientSsl, bigip_ltm_pool.pool] ←依存リソースの指定 } ◆実行コマンド resource "bigip_command" "command" { commands = ["save sys config"] ←コマンド内容（ここでは現設定の保存） depends_on = [bigip_ltm_virtual_server.virtualserver] ←依存リソースの指定 } ※このコマンドを実行しないと先のTerraformで行った(BIG-IP iControl API経由の)設定が保存されず、BIG-IPの再起動で初期化されてしまいます。
上記の設定内では依存リソースの指定(depends_on)をよく使用しています。
通常はTerraformがリソース同士の依存関係を自動で理解するので特別に定義することは不要なのですが、depends_on定義することでリソース同士の依存関連を管理者が明示化できることに加え、リソースが作られる順番/削除される順番を明示的にコントロールできます。depends_onで指定したリソースが先に作成されなければ、そのリソースは作成されません。また、depends_onで指定したリソースよりも先にこのリソースを削除しなければならない場合にも利用します。先に存在すべき別のリソースがあるリソース、または先に別のリソースを削除しなければ削除できないリソース、などの依存関係を解決するために使う重要な機能になります。
そして今回はBIG-IPの仕様として、設定後に設定を保存するCLIコマンドを実行しています。取り扱う製品によってはこういった処理が必要となりますので、お気をつけください。
次回案内
今回は動的なロードバランサの構築と設定についてご紹介しました。
今回取り上げたロードバランサF5 BIG-IPでは、提供されているBIG-IP Providerを使ってサービス稼働までの設定をコード化することができました。各クラウドベンダーが提供するロードバランシングのサービスよりもより詳細できめ細かい設定が可能なのがBIG-IPの特徴ですが、BIG-IP Providerを使うことでそれら詳細設定まで含めてコード化が可能です。
BIG-IPは多くの範囲をコード化できるProviderが提供されていますが、サービスや製品によってコード化できる範囲はProviderによって変わります。そういった場合は別製品と連携することで回避できる場合もありますのでそれはまたどこかで記事にできたらと考えております。
次回は、プライベートネットワークでのIaCについてご紹介します。
ここまで読んでいただきありがとうございました。
この記事の投稿者A.Sakamoto
技術担当です。Azure、AWSなどクラウド技術に触れるのが好きです。
この記事をシェア
