前回はスイッチ/ルーター/ブリッジなどのネットワーク関連のリソースを中心に扱いました。今回は前回の続きとしてVPCルータを扱い、その後DNSやGSLB、監視といったサービスそのものを提供するリソースを扱います。応用編としてこれまでの連載で扱ってきたリソースやテクニックを駆使して複数リージョンにまたがる冗長構成を構築してみます。仮想プライベートクラウド構築まずは仮想プライベートクラウド構築のためのリソースであるVPCルータについて扱います。Cloud)環境を構築するための、仮想ルータアプライアンスです。VPCとは?クラウド上に仮想的なネットワークを構築し、手元のプライベートネットワーク(いわゆる社内LANなど)とVPN接続を行うことで、クラウド上の資源をあたかもプライベートネットワーク上にあるものとして扱うための技術です。以下のような機能を持っています。PPTP)サイト間VPN(Cisco,Juniper,ヤマハなどのハードウェアVPNアプライアンスとも相互接続可能)ルータ+スイッチがグローバルIPアドレスの確保に重点が置かれているのに対し、VPCルータはルータ機能+VPN機能に重点が置かれています。両方を組み合わせて利用することも可能です(プレミアム/ハイスペックプランではルータ+スイッチが必須です)。冗長化の有無や性能の違いにより3つのプラン(スタンダード/プレミアム/ハイスペック)が用意されています。詳細は以下のページなどを参照ください。VPCルータ今回は簡単な例として、VPCルータ配下にプライベートネットワークを構築し、L2TP/IPSecへVPN接続可能な構成を行ってみます。以下のような構成となります。VPCルータの上流ネットワークは共有セグメント(インターネット)に接続VPCルータ配下にプライベートネットワーク用のスイッチを接続(192.168.15.0/24とする)L2TP/IPSecでプライベートネットワークへVPN接続可能にするtfファイルは以下のようになります。今回のVPCルータの定義は以下のリソースから構成されています。パスワード}前回のロードバランサの場合と同じく、より下流(子供側)のリソースが上流(親)のIDを持つという形になっています各リソースに指定できる値などの詳細は以下のドキュメントを参照してください。VPCルータリソースが細かく分割されていますが全て使う必要はなく、必要に応じてチョイスすればOKです。(実質的には今回の例に出てくる各リソースは必須だと思います。)サービス提供のためのリソース続いてサービス提供のためのリソースを扱います。さくらのクラウドには、IaaS(計算リソースやディスク、ネットワークといったインフラストラクチャの提供)以外にも、監視やバックアップといったサービスそのものを提供するためのリソースとして以下のようなものが提供されています。今回はこの中からシンプル監視を扱ってみます。(なお、DNSとGSLBについては後ほど応用編で登場します)シンプル監視シンプル監視とは、サーバーの外部からネットワーク疎通性やアプリケーションの死活を監視できる、いわゆる外部監視(外形監視)を行うためのリソースです。pingやhttpといった様々な監視方法が用意されています。通知方法としてはメールとslackでの通知が用意されています。シンプル監視についての詳細は以下のページなどを参照ください。今回は例としてサーバへのping監視を行い、通知をメールで行うようにしてみます。tfファイルは以下のようになります。}}シンプル監視の定義シンプル監視は以下のように定義します。}}監視対象のIPアドレス(またはFQDN)と監視方法を指定するだけでOKです。通知はデフォルトでメールが利用されます。Slack通知への切り替え/併用も可能です。指定できる値の詳細は以下のドキュメントを参照ください。シンプル監視なお、監視対象はさくらのクラウド以外の外部のリソースでもOKです。以下の例ではArukas上のコンテナの監視を行っています。}}複数のプロバイダをまたぐ定義というTerraformらしいサンプルとなっています。さくらのクラウドがサポートするリソースを一通り扱ってきました。一部扱っていないリソースについては設定リファレンスなどのドキュメントを参考にしてみてください。さくらのクラウドで実用的な構成を組む例を紹介します。さくらのクラウドのドキュメントを参考しながら読み解いてみてください。さくらのクラウドで構築してみます。構成要素は以下の通りです。管理アクセスのためにVPCルータも利用するようにしています。管理作業用にL2TP/IPSecでのVPN接続を行うなお、今回はWebアプリケーションのデプロイなどのサーバ内部のプロビジョニングについては本筋から外れるため簡略化/省略しています。実運用環境を構築する際は各自の環境に合わせたプロビジョニングをご検討ください。今回は構成要素が多くtfファイルが肥大化してきたため、tfファイルをいくつかに分割することにしました。以下のリポジトリでtfファイルを公開しています。https://github.com/yamamoto-febc/terraform_for_sakuracloud_start_guide/tree/master/example5-advanced分割後のtfファイルは以下のような構成になります。アウトプットポイントごとに解説していきます。変数の設定(variables.tfとterraform.tfvars)まずは変数の定義部分と、変数への値設定部分を見てみましょう。変数の定義はvariables.tfで行なっています。以下のような内容となっています。}ここでは変数の定義のみ行いました。実際に投入する値はterraform.tfvarsファイルで指定しています。このファイルにはパスワードなどが直接記載されていますので各自で適切に置き換えてください。"tk1a"]特徴的なのはWeb/DBサーバ用の値を定義している部分でリスト型変数の値としてマップ型を利用している部分です。},[...省略...]関連のある定義はなるべく一箇所にあった方がわかりやすいですので、今回は各サーバーで固有の値についてはここにまとめています。して定義した値は以下のようにlookup関数との組み合わせなどで利用可能です。"name")}"リスト型変数の要素にマップ型を利用する方法は、count属性を利用するリソースとの相性が良いです。先ほどの例のようにcount.index番目の要素を参照するという形にするとtfファイルがシンプルになります。ネットワークの定義(network.tf)次にネットワーク用のリソース定義を見てみます。ここでは各ゾーンにスイッチを配置し、それぞれをブリッジで繋ぐようにしています。tfファイルは以下の通りです。"bridge"}各ゾーンにスイッチをひとつ、今回は東京(tk1a)と石狩(is1b)を利用しますので、スイッチのcountには2を指定しました。GSLBの定義(gslb.tf)続いて広域負荷分散用のGSLBの定義を見てみます。tfファイルは以下のようになっています。"${sakuracloud_server.web_servers.*.base_nw_ipaddress[count.index]}"}注目はGSLB配下のサーバ定義でのcountの書き方です。"${length(var.web_servers)}"length関数は引数で指定されたリスト型変数の要素数を返すものです。length関数を利用しておくことで、Webサーバの定義を増やすだけでGSLBの設定も動的に変更されることになります。汎用性の高い関数ですので利用方法をしっかり押さえておくのがオススメです。続いてはサーバに登録するSSH公開鍵の定義を見てみます。さくらのクラウドの最新版(v0.8.1)においてSSH公開鍵をさくらのクラウド上で生成する機能がリリースされましたので早速利用しています。}}今回はパスフレーズなしの公開鍵を生成し、local-execプロビジョナを利用してローカルマシンに秘密鍵を保存するようにしました。サーバにSSH接続する際はこの秘密鍵を利用するようにします。Webサーバの定義(web.tf)いよいよWebサーバの定義です。これまで定義した各種リソースとの接続やWebサーバのプロビジョニングを含んでいます。tfファイルは以下の通りです。"zone")}"}ちょっと大きめの定義ですので、ポイントごとに解説します。各リソースとも共通して以下のようにcountとzoneを指定しています。"zone")}前述のlength関数でのcount指定とlookup関数の合わせ技です。アーカイブ/ディスク/サーバはゾーンをまたいでお互いに接続できない(例えば石狩ゾーンのディスクを東京のサーバに接続することができない)ため、各リソースから共通の変数定義(web_servers変数)を参照することで同一ゾーンにリソースが作成されるようにしています。スイッチIDの参照方法ちょっと手の込んだテクニックを利用しているのがスイッチIDを参照する部分です。)}"]ここでは、各サーバが属するゾーンに作成したスイッチIDを参照するようにしています。サーバのゾーン名を利用してlookup関数で検索という方法をとりました。1)のマップ型変数を作成するためにzipmap関数を利用しています。),この関数は、2つのリスト型変数を引数に受け取り、各引数の各要素から第1引数(の要素)をキーに、第2引数(の要素)を値にしたマップ型変数を作成してくれます。引数に指定したリスト型変数のそれぞれの要素数が異なる場合はエラーとなります。lookup関数で検索することでスイッチIDを検索することが出来ます。プロビジョニング(SSH接続設定)SSHで接続してプロビジョニングを行うための設定が以下の部分です。}${self}はその名の通り自分自身を参照するための構文です。ここでのselfはサーバリソース(sakuracloud_server)をさしています。今回はSSH接続先となるホストのグローバルIPアドレスを参照するためにselfを利用しています。次に、SSH接続時に利用する秘密鍵を“${sakuracloud_ssh_key_gen.key.private_key}”で指定しています。これらの設定でSSH接続でプロビジョニングを行えるようになります。ヒアドキュメントの利用SSH接続後にプロビジョニングで実行される内容はremote_execプロビジョナに記述されています。ここでは長い文字列をtfファイル上で扱うためにヒアドキュメントを利用しています。}remote-execプロビジョナで実行するスクリプトを指定するためにinline属性を指定しています。inline属性は実行したいコマンドを文字列の配列で指定することでそれぞれのコマンドを実行するようになっているのですが、ここではヒアドキュメントを用いて記述した文字列を配列のただ一つの要素として指定しています。実際にはnmcliコマンドを2回実行する内容となっていますので、それぞれのコマンドを個別に配列の要素としても問題ありません。DBサーバの定義(db.tf)続いてDBサーバの定義です。Webサーバとの違いとして、VPN接続後でないとSSH接続できないため、プロビジョニングにはスタートアップスクリプトを利用しています。プロビジョニングの内容もDBに特化したものとなります(ただし今回は省略しています)。tfファイルは以下の通りです。<Master/Slaveでのプロビジョニング処理の切り替えプロビジョニング用のスタートアップスクリプトを指定している部分は以下の通りです。]ここでは2つのスタートアップスクリプトを実行するようにしています。最初にDB自体のインストールなどを行うためのスタートアップスクリプトを実行し、次にMaster/Slaveそれぞれの役割に応じたスタートアップスクリプトを実行するようにしています。MasterなのかSlaveなのかで分岐するために以下のように3項演算子を利用しています。}"変数定義時にis_masterという値を用意しておきました。この値を3項演算子での判定に利用しています。その他の定義(vpc_router.tf、output.tf)後はVPCルータの定義とアウトプットの定義です。tfファイルは以下のようになっています。"${sakuracloud_gslb.gslb.FQDN}"}特筆すべき点はなく、これまで扱ったテクニックで十分読み解けるはずです。今回の構成で動作確認を行うためにGSLBで発行されるFQDNをアウトプットとして定義しています。"${sakuracloud_gslb.gslb.FQDN}"}コメントアウト部分にも記載していますが、本来はこの値を実際にサービスを提供するホスト名のCNAMEレコードとしてDNS登録する必要があります。GSLBで発行されたFQDNに直接アクセスすることで動作確認は出来ますので今回はDNSレコードの登録部分は扱っていません。GSLBで発行されたFQDNをDNS登録する例もしさくらのクラウドDNSを利用する場合、以下のようなtfファイルでCNAMEレコードの登録が可能です。ゾーン登録後にネームサーバの設定が必要です。詳しくは以下を参照してください。applyしたら、アウトプット”gslb_fqdn”へブラウザでHTTPアクセスしてみましょう。いずれかのWebサーバに振り分けられているのが確認できるはずです。OSやブラウザでのDNSキャッシュをクリアして再度HTTPアクセスすることで別のホストに振り分けられることも確認できるはずです。(同じホストに振り分けられることもあるため数回試してみてください。)終わりに全5回にわたりTerraformの基本からさくらのクラウドでの環境構築までを扱ってきました。本連載で扱ったサンプルは以下のリポジトリで公開しています。https://github.com/yamamoto-febc/terraform_for_sakuracloud_start_guide/本連載などを活用しインフラのコード化を行なっておくことで、インフラ構築の速度/精度の向上や環境の再現/複製の容易化など様々なメリットを享受することができると思います。これらを通じインフラの使い捨てやオンデマンドな調達といった使い方も可能になってきます。さくらのクラウドが、クラウドをよりクラウドらしく使うための一助となれば幸いです。さくらのクラウドは現在も活発に開発中です。さくらのクラウド使い方についての質問やバグ報告、機能要望などがございましたら、いつでも大歓迎しておりますのでお気軽にGitHubのIssueを登録ください。