2025年までには楽になろう…
Ansible/Terraform を使って NSX-T を楽々自動運転
自堕落な性格なので、頬って置くと先延ばしの仕事を放置しがちです。なので年間の活動プランなどの線表が引かれて、作業の締め切りを強制してもらわないとやり残しの仕事があるのではないかと(というか絶対にあるので)少し不安になってきます。我々VMware は 2 月からが新年度なのでいまは新年度が始まって1Qが経過しQ2真っ只中な感じでして、Q1で決められた年間のプランニングが様々実行フェーズに入ってきました。よって各種もろもろのマーケティングイベント対応への締め切りに追われつつもちょっとだけ安心な今日この頃でございます。ところで昨年、ご好評をいただいた Virtual Cloud Network Day Live は今年も実施します!ハイライトしてご紹介したい製品やサービスも目白押しなので、昨年とは少し日程をずらして今の所夏くらいに開催予定です。お楽しみに!
さてそこで、昨年の Virtual Cloud Day Live 開催から早いものでもう一年かぁ、と思い返してみて、ふとやり残していた仕事を思い出してしまいました…すっかり忘れていたのですが、とあるお客さまから VMware NSX Data Center の自動化コンセプトについて概念をまとめて解説してほしい、というご要望でした。そのお客さまのサポートという観点では時既に遅しですが、懺悔と供養の意味合いを含めつつやり残していた解説を以下にさせていただきます…
How to Manage ネットワーク
昨年の Virtual Cloud Network Day Live にて取得したアンケートで少しだけ予想を上回っていて面白かったのは、「これからのネットワーク、主にどんなインターフェイスで管理運用を行っていきたいですか?」という設問に対する回答比率でした。VMware 主催のネットワークイベントに参加頂いているお客さまが対象なので、おそらく世の中の平均と比べると少し感度高めなお客さまに集まっていただけたかな、と思ってはいるものの回答結果から見えてきたのは、我々が思っていた以上にレガシーな CLI でのネットワーク運用に対する限界が見えつつある、という傾向でした。
一昔前と違って、ネットワーク担当者は L2 から L7 まであらゆるネットワーク要素の管理を求められることが多くなってきていると思いますし、加えて、セキュリティの高度化やクラウドネットワークの管理運用という新しい仕事領域も追加になってきているので、特定の「機器ごとに設定」を行ったり、「ラック前でトラブルシュート」する、といった旧態依然の運用方法では日々の業務が追いつかなくなってきているのではないでしょうか。
そこでデータセンター内の L2 から L7 までのネットワーク要素すべてを一つのコンソールで動作させる事が可能な NSX-T Data Center のようなソリューションに対するお客さまからの注目度がますます高まってきています。
How to Manage “New” ネットワーク
一方でパブリッククラウドのネットワークに目を向けてみます。クラウドの領域でもネットワークの設定は当然必要ですが、人が立ち入ることの出来ないクラウド上でのコントロールに物理ネットワークを意識する余地はありません。すべてのネットワーク要素に対する設定が簡略化された UI で制御することができるようになっているため、誰でも簡単に制御することができるようになっています。
このコンセプトをオンプレミスのデータセンターに提供しつつ、さらに復数のクラウドまで含めて一つの UI で管理することをご提供するのが製品としての VMware NSX-T Data Center の役目となっています。これによりパブリッククラウドと同様にデータセンターに必要なあらゆるネットワーク要素を一つの UI から提供することが可能になります。
※ちなみに ver.2.5 からは UI のマルチ言語対応も行っており、既に日本語での UI 表記もサポートされています。
How to Manage New ネットワーク “with Automation”
さて、前置きが長くなりましたがここからが今回の本題です。NSX-T を使えば一つの簡素化されたUIで L2 から L7 までデータセンターのネットワーク要素をすべて容易にコントロールできるようになりますが、実際の運用に入られるお客さまの気持ちになると、それをさらに自動化の力で定型化・省力化したい、というご要望につながっていきます。もちろん NSX-T ではそのようなご要望にも対応することができる仕組みをご用意しています(というか、本質的にはそちらが本命かもしれません)。それが宣言型ポリシー API と呼ばれる機構になります。NSX-T はブラウザによる UI アクセスに加えて、この宣言型ポリシー API を介した自動化オペレーションという2つの方法を状況に応じて使い分けてもらってコントロールしてもらうことを前提としたソリューションになっていると言えます。
API はともかく“宣言型”ってなんですか?とよくご質問を受けますが、これは「一つ一つの設定」を API Call で流し込むスタイルではなくて、「システム全体として最終的にどのような状態になっていてほしいか?」という帰着するデザインの形を表現するスタイルだと思ってください。
例えば、
- アプリケーションの階層を分離させたい
(3階層アプリ用の L2 セグメントをそれぞれ作成し、Tier-1 Gateway に接続する) - VM のアプリケーション種別を管理したい
(各アプリをグルーピングし、不必要なグループ間通信をファイアウォールで抑制する) - 外部ネットワークへ接続させたい
(外部アクセス用の境界ファイアウォール、NAT機能を有効化)
と言った具合です。
様々な自動化ツールからこのような希望とする最終形をこの宣言型ポリシー API に対して 1 Call するだけで必要なネットワークオペレーションを圧倒的に簡素化することができるようになっており、特にテナントの払い出しなどの定型業務には威力を発揮します。ここでいう様々な自動化ツールとは、我々の製品で言えば vRealize Automation や VMware Integrated OpenStack などが挙げられますが、今回は代表的な OSS ツールである Ansible と Terraform についてご紹介したいと思います。
Ansible と NSX-T
日本では人気の OSS なためご存知な方も多いと思いますが、Ansible とは以下の特徴をもった自動化構成ツールになります。
- RedHat が開発する OSS
- 初期セットアップでも、日頃の管理でも、アドホックの実行タスクを行う用途にも使える、オールインワンの便利な自動化構成ツール
- ツールからのプッシュ型アプローチ
- エージェントレスで動作
- YAML スタイルの設定ファイル
- 管理ノード側に Python さえインストールされていれば動作可能
- 設定ファイル内のタスクをシーケンシャルに実行
- インフラを指定した一定の状態に維持することが可能(冪等性の担保)
Ansible 管理ノードがサーバーやネットワーク機器に接続し、Module と呼ばれる小さなプログラムをプッシュします。その際に Playbook と呼ばれる Yaml 形式で記載された設定ファイルに応じて各種デバイスの制御を行います。
NSX-T の Ansible Module は Ansible 管理ノードのローカルで動作するので、Inventory ファイルでの指定に必要なホストは localhost だけでよく、対象への SSH 接続も必要ありません。NSX-T module が NSX-T Manager に対する REST API call を Ansible 管理ノードから要求させることで各種自動化による作業を実行します。
公式なセットアップガイドや各種モジュール、Playbook のサンプル情報などはこちらから参照できますが、
https://github.com/vmware/ansible-for-nsxt/tree/v3.0.0
日本語による How to Use の設定サンプルや手順などもこちらにまとめてありますので、興味を持っていただいた方はぜひ参照ください。
→【資料】Policy API を利用した NSX-T Data Center の自動化
また、動態デモビデオもご用意していますのでよろしかったらこちらもどうぞ。
→【ビデオ】 VMware NSX-T Data Center デモンストレーション : Ansible連携による仮想ネットワーク/セキュリティの自動構築と削除
Terraform と NSX-T
つづいては、Terraform です。日本では Ansible のほうが知名度と人気が高そうですが、海外では Ansible に負けず劣らずな人気で、特に NSX-T のコントロールに関しては現状 Ansible 以上に豊富な設定項目をサポートしています。
- HashiCorp が開発する OSS
- インフラの構築、変更、バージョン管理、などを安全かつ効率的に行うことが可能なオールインワンの便利な自動化構成ツール
- Infrastructure as a code を宣言的なアプローチで実行
- インフラの展開、変更と消去のためのワークフローを定義
- ワークフローで指定したリソース間の関連性を可視化し表示することが可能
- 様々な Cloud やインフラに対応した Provider を提供することでアクセス
- 多数の API 言語に対応
利用の際にはインストールは必要なく、管理ノードにダウロードしてきた実行ファイルがあれば利用可能で、用意するのはどのような状態を構成するのかを定義した設定ファイル(.tf)と、各種参照パラメータをまとめるVariable file (.tfvars) だけでOKというシンプルな構成です。
また個人的には、投入設定の差分を追加は(+)で、削除は(ー)で表現しつつ差分確認をした後に Apply を行うというコンセプトがなんとなく懐しくも私の身体と脳には馴染みやすいインターフェイスになっていて好印象です。
Provider と呼ばれる対象プラットフォーム毎の設定モジュールや記載サンプルなどの各種情報は HashiCorp のサイトにまとめられており、NSX-T の Provider 情報はこちらから参照可能ですが、
https://registry.terraform.io/providers/vmware/nsxt/latest/docs
日本語による How to Use の設定サンプルや手順がご要望の方はやはり先程のファイルの後半部分にまとめてありますので、こちらもご参照ください。
→【資料】Policy API を利用した NSX-T Data Center の自動化
まとめ
多くのお客さまにとっては、おそらくいまは移行期。旧来型のネットワーク運用と新しいマルチクラウドを踏まえた時代のネットワーク運用、どちらも並行で運用しながら徐々に新時代の運用に移行していかなくてはいけないタイミングなのではないかな、と推測します。そんな時こそ旧来環境の運用と新基盤の運用差分を抽象化することのできる OSS ベースの自動化ツールをご検討頂いてみては如何でしょうか? VMware では、今回ご紹介した Ansible/Terraform に関しては公式にサポートすることが可能な体制を整えております。
また、本日ご紹介した Ansible/Terraform 以外にも製品として様々な自動化ツールをご用意してもおります。よって皆さまのネットワーク運用の次世代化に向けて何らかお手伝いできるのではと思っておりますので、ご要望あればお気軽にお問い合わせください。
ちなみに我々のチームには、やりたい意図はあるものの指示が雑だったり細かな点に誤りや不備がある場合であっても、その意図を勝手に汲み取っていい感じに構成や設定を修正してくれる超優秀な若者エンジニアがおりまして(本 Blog ポストでは役者としても登場・活躍し、そのマルチな才能を遺憾なく発揮)、これぞ究極の Automation だなぁ、、、などと不埒にも思ったりもします…
Yさんいつもラボ管理ありがとうございます。早く AI による自動実装が追いついてくると良いですね…
(あとがき)
※ちょうど昨日 Terraform がめでたく正式版の GA1.0 になりましたね。祝!
https://www.hashicorp.com/blog/announcing-hashicorp-terraform-1-0-general-availability