ISconf
 | В этой статье есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
В вычислительной технике ISconf представляет собой программный инструмент для управления сетью серверов .
ISconf работает по модели извлечения, что означает, что даже серверы, которые не работают на момент внесения изменений, получат изменения после их повторного включения. Начиная с версии 4, ISconf не требует центрального сервера, хотя он ожидает, что все серверы будут запускаться одинаково, что проще всего выполнить с помощью той или иной формы автоматической установки, для которой может потребоваться центральный сервер.
Теория
[ редактировать ]ISconf возник из движения «Администрирование инфраструктуры», которое создало и определило большую часть основ ОС (теоретически) того, что сейчас составляет сферу DevOps . Он основан на идее, что лучший способ предотвратить расхождение серверов — это применять один и тот же набор операций в одном и том же порядке.
Это контрастирует с теорией «конвергенции» системной автоматизации, которая пытается «привести» серверы к известным состояниям из произвольных состояний, используя наборы правил, таких как «если установлен пакет за пределами этого набора, удалите его», «если пакет X не установлен, установите его» или «если демон X не запущен, запустите его». По мнению Стива Трауготта, невозможно гарантировать, что данный набор правил действительно сможет сходиться из любого данного состояния.
ISconf обеспечивает соблюдение порядка операций, предполагая, что только команды, выдаваемые через него, изменяют состояние системы. В результате, если пакет или файл устанавливается в систему вручную, он останется там, что в конечном итоге может вызвать такие проблемы, как конфликт версий. ISconf предназначен для сред, где конфигурации должны оставаться идентичными. В таких средах обычно лишь нескольким системным администраторам предоставляется root-доступ к хостам. Это сводит к минимуму риск внесения изменений вручную, поскольку можно легко обучить небольшую группу людей вносить изменения только через ISconf.
ISconf был вдохновлен и первоначально реализован как Makefile. Однако файлы Makefile определяют зависимости, а не общий порядок операций. ISconf версии 1 решил эту проблему, сделав каждую операцию зависимой от предыдущей, но это было утомительно и плохо подходило для Make. В более поздних версиях ISconf используется простой журнал, доступный только для добавления.
Основные версии
[ редактировать ]Основными широко используемыми версиями, по-видимому, были ISconf2 и ISconf3, тогда как ISconf4 оставался в очень длительном периоде бета-тестирования. Фактически он был завершен и использовался в более крупных средах, но из-за задержки его принятие сообществом было ограничено.
- ISconf 1 (Makefiles)
- ISconf 2 (начало 200x?), написанный Стивом Трауготтом
- ISconf 3 (2002 г.) представлял собой переписанную версию 2 Люка Каниеса.
- ISconf 4 был в основном написан первоначальным автором Стивом Трауготтом.
Пустяки
[ редактировать ]Люк Канис позже переключился на CFengine2 , пока, наконец, не написал и не выпустил Puppet . В результате можно считать ISconf предком Puppet, хотя и CFengine, и Puppet реализуют модель «конвергенции» управления конфигурацией, по сути противоположную модели «порядка операций», реализованной как минимум в ISconf версий 1, 2 и 1. 4.
См. также
[ редактировать ]Внешние ссылки
[ редактировать ]- веб-сайт ISconf
- Начальная загрузка инфраструктуры , статья Стива Трауготта и Джоэла Хаддлстона LISA '98 об идеях, которые привели к ISconf (предшествует самому ISconf)
- Описание Люка теоретической основы и целей ISconf 3
- Раздел теории и архивы списков рассылки для автоматизации управления системой
- Репозиторий Github для ISconf4