LINUX.ORG.RU
ФорумTalks

Авторазвёртка инфраструктуры

 ,


0

1

Хочу поговорить за тему авторазвёртки.

Представим такую ситуацию: есть площадка с n-ым количеством linux-машин. На каждой из них вертится какой-то набор софта - самописного или из репозиториев. Машины обновляются редко - система по мере появления новых релизов (читать - раз в несколько лет), софт по мере обновления функций площадки.

Ну то бишь нет цели всё время быть на current версиях, обновления только по мере прироста задач. На первый взгляд всё классно - развернулись, забыли, по мере необходимости обновляем ручками.

Усложняем. На площадке компьютеры периодически умирают - это раз. Конфигурацию площадки хочется разворачивать на других площадках - при этом, ненадолго, ну типа такой я пришёл, компы раскидал, запустил, оно само развернулось, потом свернул.

Олсо, оператор всего этого хозяйства не должен быть слишком умный - ибо зачем, если можно автоматизировать.

Первая идея - заскриптовать развёртку каждого набора софта. Опционально распихать всё это по гит-репозиториям, написать cli на whiptail, сократить работу оператора до установки ОС и вызова нужного скрипта.

Потом приходит в голову идея прибить софт к hostname и сократить работу оператора до установки ОС, указания hostname и пусть дальше работает какой-нибудь ansible.

Чё вообще хотел сказать: так законно делать, или нормальные ребята идут ещё дальше?

Всё зависит от уровня твоего оператора, если он умеет проконтролировать инсталяцию ОС и запустить написанный и протестированный плейбук на ансибле - то твоя задача уже решена на этом этапе, дальше нет смысла что-то накручивать.

v9lij ★★★★★
()

Terraform в помощь, если я правильно понял твою задачу. В совокупности с Docker/Kubernates.

Deleted
()
Последнее исправление: ifelse (всего исправлений: 1)

Просто скажу тебе два слова: «proxmox» и/или «ansible» (или аналоги)

SunDoc
()

Традиционно, продать n-ное число машин и продаться в рабство гуглю или амазону может быть проще (но при нагрузке — дороже). Но поскольку операторы зачастую дороже железа — вполне имеет смысл. Тот же fargate — вполне для домохозяек.

x3al ★★★★★
()

Потом приходит в голову идея прибить софт к hostname

Не надо так делать - когда возникнет необходимость поднять еще одну копию "вон того ПК" то такая привязка добавит проблем. Делить сервера (и это разделение использовать в скриптах) лучше по ролям, а что за хосты к какой роли привязаны (и сколько их) - это пусть админ на месте решает.

micronekodesu ★★★
()

или нормальные ребята идут ещё дальше?

АТО! У пацанов же AD+WDS+GPO и всё чётенько!

Deleted
()
Ответ на: комментарий от x3al

Здесь задачи чуть иного уровня. Грубо говоря, поехали ребята на проект - там раскидались, потому уехали, железо поехало на другой.

Dispetcher14 ★★★★★
() автор топика

Идея минимум идиотская....

dem ★★
()

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

Например, хостнеймы систематически выдаются в зависимости от порта на коммутаторе (option 82 или как-нибудь иначе), каждому хостнейму заранее задается нужная ОС и набор софта. После загрузки по TFTP в правильный образ с местным вариантом preseed/unattended installation, на сервере появляется базово настроенная (хостнейм, сеть) операционная система, которая дальше доводится до необходимого состояния системой конфигурации а-ля Ansible.

Альтернативная ветка развития — загружать серверы по сети в гипервизор, и гонять софт в нужных виртуальных машинах, которые рулятся либо решениями от вендоров, либо опен-сурсом, тысячи их.

Arrest
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.