Terraform を利用した Cisco ACI の管理概要 – パート 5
この記事は、Data Centre の Technical Solutions Architect である Conor Murphy によるブログ「Introduction to Terraform with Cisco ACI, Part 5
」（2021/2/18）の抄訳です。
「Terraform の概要」などの前回までの投稿をまだ読まれていない場合は、ぜひお読みください。最初の 4 つの投稿へのリンクを以下に示します。
- Terraform の概要
- Terraform と ACI
- Terraform 設定ファイルの説明
- Terraform リモート状態管理とチームでのコラボレーション
- Terraform プロバイダーの構築方法
これまでに、Terraform の仕組み、ACI との統合、リモート状態管理について見てきました。今回は、プロバイダーの仕組みについて取り上げます。理解しておく必要は必ずしもありませんが、問題のトラブルシューティングが必要になった際に役立つ場合があります。ACI プロバイダーを例に、Terraform プロバイダーの構築方法を簡単に説明します。
コード例
https://github.com/conmurphy/intro-to-terraform-and-aci-remote-backend.git
Terraform の各ファイルについては、今回のシリーズのパート 3 をご覧ください。backend.tf ファイルについては、今回の投稿で説明します。
ラボのインフラストラクチャ
利用している独自の ACI ラボがすでにあるかもしれませんが、ない場合は、DevNet サンドボックスで ACI Simulator を使用できます。
Terraform ファイルの構造
すでに説明したように、Terraform は、コアとプラグインという 2 つの主要なコンポーネントで構成されています。Terraform の設定で使用されるプロバイダーとプロビジョナーは、すべてプラグインです。
データソースとリソースはプロバイダー内に存在し、特定のエンドポイントのライフサイクルを管理します。たとえば、ブリッジドメインの作成と管理を担うリソース「aci_bridge_domain」を見てみましょう。
Terraform ACI プロバイダーのコードについては Github を参照してください。
https://github.com/CiscoDevNet/terraform-provider-aci
この Github リポジトリのルートディレクトリには、「main.go」ファイル、「vendor」フォルダ、「aci」フォルダなど、さまざまなファイルやフォルダがあります。
- main.go：このファイルは、Terraform コアが使用できる、有効な実行可能 Go バイナリを作成します。
- vendor：このフォルダには、プロバイダープラグインによってインポートされて使用されるすべての Go モジュールが含まれています。このプロバイダーの主要モジュールは ACI Go SDK で、APIC に HTTP リクエストを送信し、応答を返す役割を担っています。
- aci：プロバイダーのすべてのリソースが存在する重要なディレクトリです。
ACI フォルダには、「provider.go」というファイルがあります。このファイルは、Terraform プロバイダーの標準的なファイルで、ACI の場合は、APIC のユーザ名、パスワード、URL などのプロパティを設定するものです。
また、Terraform ファイルで設定可能なリソースを定義し、作成、読み取り、更新、削除（CRUD）機能を実装する関数とリンクする役割も担っています。
aci フォルダには、このプロバイダーで利用可能なすべてのデータソースとリソースも含まれています。Terraform のファイル名は特別な形式になっていて、「data_source_」または「resource_」で始まる必要があります。
次に、ブリッジドメインの作成に使用されるリソース「resource_aci_fvbd」を見てみましょう。
- 10 行目と 11 行目で、ACI Go SDK がインポートされています。
- メインの関数は 16 行目から始まり、標準的な Terraform の設定が続きます。
- 18 〜 21 行目で、このリソースで使用可能な操作と、それぞれで呼び出す関数が定義されています。この 4 つの関数に関する記述はページのさらに下にあります。
- スクリーンショットの 29 〜 59 行目では、Terraform 設定ファイルのリソースで使用できるプロパティが設定されています。
トラブルシューティングのヒント：このようにファイルを確認すれば、プロバイダーに関するドキュメントに誤りがあるか、不完全であると思われる場合に、正確なサポート対象/設定対象を簡単に確認できます。
これで、ファイル内の主要な関数を確認できました。これらの関数が変更を適用しているのです。今回の例では、ブリッジドメインの作成、読み取り、更新、破棄を行います。
上にスクロールすると、関数名が、18 〜 21 行目で設定されている名前と一致していることを確認できます。
コマンド（terraform destroy など）を実行するたびに、Terraform は、これらの中から該当する関数を呼び出します。
次に、これらの関数によって何が発生しているかを見て行きましょう。
まず 419 行目で ACI Go SDK をセットアップする必要があります。
その後、Terraform が適切なアクションを実施できるように、設定ファイルの値が取得されます。たとえば、このスクリーンショットでは、設定した名前「bd_for_subnet」が、変数「name」に格納されます。
description、TenantDn、および、設定したその他すべてのブリッジドメインプロパティについても同様です。
ファイルのさらに下の方では、ACI Go SDK が呼び出され、NewBridgeDomain が作成されています。このオブジェクトは SDK の Save 関数に渡されます。その結果、APIC が呼び出されてブリッジドメインが作成されます。
create 関数の最後まで見ていくと、726 行目で ID が設定されています。Terraform がリソースを管理する際に、リソースの状態を terraform.tfstate ファイルに保持することはすでにご説明しました。Terraform は、ID を使用して該当のリソースをトラッキングします。ACI の場合、ID は DistinguishedName です。
ID は Terraform がトラッキングするだけでなく、リソースに関する他のすべてのプロパティも、状態管理ファイル内で使用できるようになっています。プロパティのデータを保存するために、setBridgeDomainAttributes という別の関数があります。この関数は、リソースを作成/更新した後に返された値を使用して、状態管理ファイルの各プロパティを設定します。
そのため、Terraform がブリッジドメインを作成すると、プロパティに関して返された値が、この関数によって状態管理ファイルに保存されます。
トラブルシューティングのヒント：設定を変更していないのに、terraform apply コマンドを実行するとリソースが常に作成/更新される場合は、状態管理ファイルをチェックし、すべてのプロパティが正しく設定されていることを確認します。
Tags:
