Використання CasC з F5 дозволить забезпечити оптимізовану та необов'язково динамічну конфігурацію мережі, заощаджуючи час та зменшуючи ризики.
Чи підтримує цей інструмент це? Чи єдині файли конфігурації (термін SCF, F5) транспортний засіб для цього?
Використання CasC з F5 дозволить забезпечити оптимізовану та необов'язково динамічну конфігурацію мережі, заощаджуючи час та зменшуючи ризики.
Чи підтримує цей інструмент це? Чи єдині файли конфігурації (термін SCF, F5) транспортний засіб для цього?
Відповіді:
Так, F5 підтримують конфігурацію як код. Історично F5 створив пристрій для управління конфігурацією як кодом під назвою "Enterprise Manager", який прагматично керував кінцевою точкою клієнта F5 (LTM та ін.) За допомогою API XML iControl.
Вони досить швидко виявили, що цей пристрій управління був жахливим, і додали більш надійний REST API до клієнтських пристроїв для управління пристроями (LTM та ін .; також отримали назву iControl), що набагато простіше у використанні та гнучкіше, а потім почали створювати заміну на Enterprise Manager фірмовий BIG-IQ.
Справа в тому, що ви можете керувати тим самим API за допомогою цього інтерфейсу REST. Дивіться їх навчальний посібник на DevCentral . Зазвичай ви можете знайти точний синтаксис REST та дзвінки на сайті DevCentral на основі версії, як ця для TMOS 12.1.0 .
Взагалі кажучи, НЕ рекомендується використовувати SCF (єдиний файл конфігурації) майже ніколи з кількох причин. По-перше, у ньому відсутні будь-які підтримуючі файли, такі як сертифікати та ключі для ваших SSL-профілів чи сценарії (так звані "зовнішні" монітори здоров'я) тощо. По-друге, вона погано відтворюється, якщо ви використовуєте розділення, оскільки розділи розподіляються по декількох файлах у складена структура. Вони не добре консолідуються у файл SCF. Вам насправді було б краще писати сценарії TMOS. Однією з причин, через яку F5 перейшов з команди bigpipe на оболонку TMOS, є те, що вона могла бути скриптована там, де bigpipe неможливо було легко прописати. Але знову ж таки, перевагу надає API REST. SCF - це наслідок версії 9 TMOS і не визріли і погано працюють у версії 12. Вагомою причиною цього є зміна HA, яка переглядається між V10 та V11, коли вони змінюються на кластерну архітектуру. Це справді спричинило зручність використання SCF.
Лялька фактично має модуль для управління F5, якщо ви використовуєте цей інструмент управління конфігурацією, а сіль має бігун для цього - обидва використовують API REST, якщо ви використовуєте будь-який із цих інструментів управління конфігурацією.
Джеймсе, ви праві, що BIG-IQ замінив Enterprise Manager. Однак, як і Enterprise Manager, BIG-IQ призначений для управління пристроєм / функціями. Для інтеграції через API REST безпосередньо або до сторонніх інструментів автоматизації / ланцюжків інструментів слід переглянути F5 iWorkflow (програмований / розширюваний шлюз API).
Команда, що стоїть за iWorkflow, орієнтована на «шаблони послуг» та «каталоги послуг». Це чудові способи швидкого створення «декларативних інтерфейсів», на які можна звертатися за допомогою одиночних викликів REST, а не викликати сотні «імперативних інтерфейсів» (окремих кінцевих точок REST) для виконання того ж завдання.
Перехід до декларативної моделі позбавить вас від МНОГО головних болів у майбутньому та покращить підтримку автоматизації та інтеграції з трубопроводами CI / CD. Останнє, що вам потрібно, - це перемістити всі нюанси вашої інфраструктури в саму трубопровід автоматизації !! Абстракція через декларативний інтерфейс захистить вас від тієї ями відчаю.
З інтерпретаційними інтерфейсами REST + у вас є набагато простіша інфраструктура як модель Code, оскільки ви підтримуєте лише краплі JSON для сервісних шаблонів, а не монолітні конфігураційні файли. Подвійний ВІН!
Погляньте на виклик iApps (шаблони служб F5) з API REST. Ось безкоштовний онлайн-курс навчання:
http://f5-automation-labs.readthedocs.io/en/latest/
Погоня = Правильно! ВІДПОВІДАЙТЕ до кінця!