nixp.ru v3.0

28 мая 2017,
воскресенье,
07:53:57 MSK

DevOps с компанией «Флант»
Аватар пользователя fhunter
fhunter написал 30 июля 2014 года в 00:25 (2523 просмотра) Ведет себя неопределенно; открыл 1 тему в форуме, оставил 474 комментария на сайте.

Ситуация: есть порядка 50 компьютеров под Debian Linux (университетская кафедра, то есть три лаборатории + преподавательские компьютеры).

Так как администрирование централизованное — есть задача держать это всё более менее одинаковым по набору софта и настроек. Пока администрирует один человек, это ещё держится в более менее одинаковом состоянии, но когда за софт и состояние отвечают несколько человек, начинается просто хаос (административные меры не помогли по причине нежелания руководства проводить их, а технического решения у меня под руками нет. Иногда «проблемы» устранялись так, что лучше бы их не трогали, меньше последствий потом).

К сожалению, хоть я там и числюсь главным админом, я не могу присутствовать и реагировать на проблемы постоянно (ну нельзя жить на те деньги что там платят).

Поэтому назрело решение — нужна система централизованного управления конфигурацией/списком пакетов.

Хотелки:

  1. Обязательно возможность работать без постоянно включенных машин (то есть при включении клиентской машины она приводится к тому же виду, что сохранено на сервере).
  2. Платформа — linux. В идеале Debian, хотя собрать свой пакет и положить в кафедральный репозиторий — смогу.
  3. В идеале — наличие web-интерфейса, хотя не сильно критично
  4. Минимум внешних зависимостей
  5. Только не на java.

Сам смотрел в сторону puppet, cfengine и LCFG (http://www.lcfg.org/). В крайнем случае буду делать собственный велосипед на скриптах и https://packages.debian.org/pkgsync

PS. Интересует личный опыт использования

PPS. Сетевую загрузку не предлагать. Имеется фобия «а что если сеть упадёт». На разумные доводы реакции нет.

Дмитрий Шурупов

Сейчас для таких (и более сложных) задач в моде Puppet и Chef, в меньшем тренде — Ansible. Мы для себя выбрали Chef (но это вопрос субъективный), однако с внедрением пока не очень по разным причинам и личного опыта конкретно у меня еще нет.

fhunter

А по каким критериям был выбор?

Дмитрий Шурупов

Перспективность/активность развития/популярность, удобство, знакомство — примерно так. По формальным признакам (технические возможности и т.п.), да и по популярности, они с Puppet очень близки.

Вообще, начинали кое-что делать с Ansible, но потом ушел человек, который этим занимался, и забили. А рецепты переделали на Chef.

fhunter

Итог — был взят ansible, как оказалось — довольно приятная штука. Работает в pull конфигурации.

Теперь переучиваю себя и неторопливо пишу playbook для подъёма эталонной машины с голой операционки.