Присоединяюсь к вопросу про практическое применение. Менеджмент обычно создаётся всерьёз и надолго, для чего писать шаблоны автоматизации для него?

я пока просто пытаюсь понять, как передать в него параметры ОС, то есть он создается один раз и дальше его никто не трогает, одако, что если ему нужно добавить интерфейс ? поменять DNS ? внести еще какие-то изменения, то есть не просто удалить/создать. Можно просто описать его как часть инфраструктуры и управлять им через терраформ

В реальной жизни это будет выполняться вручную под чутким контролем безопасника

Я "баловался" через capistrano, т.к. терраформ\анзибль больше подходят именно для первоначальной "раскатки" инфраструктуры, в качестве деплоя там идеология "снести старое, развернуть новое". Capistrano - удобная штука именно для управления имеющимся зоопарком, когда "рецепты" можно выполнять на определённой группе хостов. Там все сводится к выполнению обычных bash-скриптов\команд. Если надо clish, то clish -c 'command' Таким образом получается быстро и удобно что-то сделать сразу на большом количестве железок. Этот метод гораздо удобнее, приятнее и быстрее, чем использование того же cprid. Недостатки: на машине управления, откуда запускается capistrano, должен быть интерпретатор ruby, доступ до управляемых машин должен быть по ssh (хоть логин\пароль, хоть ключ). cprid надо меньше сторонних зависимостей, но скорость проигрывает в сотни раз.

Использование ansible\terraform\kubernetes в плане применения с CP вообще для себя не смог придумать. Возможно, кто-нибудь сможет рассказать, какие практические задачи удаётся решать данными инструментами

Вот тут как раз кажется реальность меняется

А как быть с изменениями мощности добавить core/RAM

Зачем для этого применять терраформ\etc?

Есть такая интересная концепция - Infrastructure as a code.  То есть вся или часть инфраструктуры описывается в виде конфига терраформа, далее любые изменения делаются не руками в сотнях консолей, а в конфиге. Таким образом,  можно верифицировать любые изменения,не допускать неавторизованных машин / настроек/ПО, не забывать удалять ненужные машины, снизить человеческий фактор,  который случайно настроит что-то не так. Еще что важно,  вести журнал всех изменений и состояний инфраструктуры.

Это понятно, когда инфраструктура деплоится, и мне понятен общий принцип терраформа, его идеология. Мне не понятно, как это связано с ср на практике) я не могу представить себе кейс, когда мне надо развернуть хотя бы 10 подобных однотипных железок, потом их снести, и делать это с некоторой периодичностью. Я и говорю, может ли кто-то привести конкретные практические примеры применения? Пока для меня это выглядит как троллейбус из буханки хлеба - можно сделать, но зачем, не понятно.

Когда нет лицензии, и надо переинсталлировать каждые 2 недели)))

sounds like a plan

Я только Ансибл видел для развертывания тестовой среды для программеров на Амазоне, но
- среда временная - день/два/неделя потом все сносилось
- политики безопасности были заранее оговорены и больше по типу Any Any, и никаких изменений после не вносилось
Как уже сказали - это хорошо там где каждый день создаются/сносятся фаеволы, пока для on-premises сетей/фаерволов я таких сценариев не представляю.  
ИМО - агрессивный маркетинг и базз этих технологий (которые сами по себе абослютно прикольные) совсем не значит что они приживутся в реальных условиях.

как вариант, может быть актуально какому-нибудь mssp. Появился новый клиент, заполнил карточку сервиса, на стороне инфраструктуры поднялся готовенький cp обслуживать его сервис

Коллеги, приветствую. Есть задача, подобрать СP который будет использоваться исключительно для удаленного доступа сотрудников. Количество пользователей будет около 1500. Вопрос сколько ядер нужно закладывать под такие потребности. Нашел SK где приведена таблица для подобных расчетов, но там указаны только физические апплайнсы, нас же интересует виртуальное решение. Согласно этой таблице, 2000 пользователей загрузит апплайнс SG 3600 на 100%. Как эту информацию использовать в подборе виртуального решения? Может у кого были подобные кейсы, поделитесь информацией плз.

SG 3600  разорвет от 2000 пользователей )

мне кажется, при виртуальном шлюзе идеальный вариант возникает благодаря тому, что его параметры можно динамически менять - это не физическая железка, которую придется заменять целиком. Я бы взял некие средние параметры навскидку, скажем, 8 ядер ЦПУ и 16Гб оперативки, и постепенно давал доступ большему и большему кол-ву пользователей. Ну и мониторил. Будет загрузка подбираться к 60% - планируем сервисное окно и немного добавляем ЦПУ. Возможен такой вариант?

вирутальный шлюз на 1000 пользователей это  8 - ядер

Я так понимаю, вопрос сайзинга по количеству пользователей VPN - весьма частый, но так заранее на 100% ответ не дашь, потому что зависит от многих факторов. Поэтому лучший вариант в случае с виртуальным шлюзом - это пробовать и смотреть.