ロードバランサーF5はCasC（コードとしての構成）をサポートしていますか？

CasCとF5を併用すると、バージョン管理されたオプションの動的ネットワークエンドポイント構成が可能になり、時間を節約してリスクを軽減できます。

このツールはこれをサポートしていますか？単一構成ファイル（SCF、F5用語）はそれを行う手段ですか？

はい、F5はConfiguration as Codeをサポートしています。歴史的に、F5はiEnterprise XML APIを使用してクライアントエンドポイントF5（LTMなど）を実用的に管理する「Enterprise Manager」と呼ばれるコードとして構成を管理するアプライアンスを作成してきました。

彼らはこの管理アプライアンスがひどいことにすぐに気づき、デバイス（LTMなど）を管理するためのより堅牢なREST APIを追加しました（これはiControlとしてもブランド化されています）。 Enterprise ManagerはBIG-IQとブランド化されています。

つまり、このRESTインターフェースを使用して同じAPIを管理できます。DevCentralに関するチュートリアルをご覧ください。通常、TMOS 12.1.0の場合のように、バージョンごとにDevCentralサイトで正確なREST構文と呼び出しを見つけることができます。

一般的に、いくつかの理由により、SCF（単一構成ファイル）を使用することはほとんどお勧めできません。1つ目は、SSLプロファイルやスクリプト（いわゆる「外部」ヘルスモニター）の証明書やキーなどのサポートファイルが不足していることです。フォルダ構造。これらは、SCFファイルにうまく統合できません。実際には、TMOSスクリプトを記述した方がよいでしょう。F5がbigpipeコマンドからTMOSシェルに切り替わった理由の1つは、bigpipeを簡単にスクリプト化できない場所でスクリプト化できることです。ただし、REST APIが推奨されます。SCFは実際にはTMOSのバージョン9のレガシーであり、バージョン12では適切に古くならず、うまく機能しません。これの主な理由は、クラスター化されたアーキテクチャーに変更されたときの、V10とV11間のHAピアリングの変更によるものです。これは、SCFのユーザビリティに大混乱をもたらしました。

この構成管理ツールを使用する場合、Puppetには実際にF5を管理するためのモジュールがあり、saltにはランナーがあります。これらの構成管理ツールのいずれかを使用する場合は、どちらもREST APIを使用します。

ジェームズ、あなたはBIG-IQがEnterprise Managerを置き換えたという点で正しいです。ただし、Enterprise Managerと同様に、BIG-IQは「デバイス/機能」管理用です。REST APIを介して直接、またはサードパーティの自動化ツール/ツールチェーンに統合する場合は、F5 iWorkflow（プログラム可能/拡張可能なAPIゲートウェイ）を確認する必要があります。

iWorkflowの背後にあるチームは、「サービステンプレート」と「サービスカタログ」に焦点を当てています。これらは、何百もの「命令型インターフェース」（個々のRESTエンドポイント）を呼び出して同じタスクを実行するのではなく、単一のREST呼び出しでヒットできる「宣言型インターフェース」を迅速に作成する優れた方法です。

宣言型モデルに移行すると、将来、多くの頭痛の種からあなたを救い、自動化とCI / CDパイプラインとの統合をより適切にサポートします。最後にしたいことは、インフラストラクチャのすべてのニュアンスを自動化パイプライン自体に移動することです!! 宣言型インターフェースによる抽象化は、その絶望の穴からあなたを守ります。

REST +宣言型インターフェースを使用すると、サービステンプレートのJSONブロブのみを維持し、モノリシック構成ファイルを維持しないという点で、コードモデルとしてのインフラストラクチャがはるかにシンプルになります。ダブルウィン！

REST APIからのiApps（F5サービステンプレート）の呼び出しを見てください。これは無料のオンライントレーニングコースです。

http://f5-automation-labs.readthedocs.io/en/latest/

追跡=正解です。ずっとREST！