Представьте, что вы собираетесь управлять несколькими серверами с несколькими различными службами, которые используются несколькими людьми. Теперь предположим, что вы хотите перенастроить или заменить какое-то программное обеспечение на одном из этих серверов. Очевидно, что вы не хотите работать на действующих серверах.
Если бы это было изменение кода, как разработчик, я бы внес изменение на своей локальной машине разработки, протестировал его локально и зафиксировал изменение в системе контроля версий. Затем изменения могут быть развернуты в промежуточной среде, протестированы и, наконец, развернуты в производственной среде. При необходимости мне было бы легко откатиться.
В целом или в частности, как вы этого добиваетесь в системном администрировании?
(Первое, что приходит в голову, - это использовать виртуальные машины и помещать образы виртуальных машин в систему контроля версий, но я уверен, что есть много литературы и умных решений, о которых я сейчас не знаю.)
Отказ от ответственности: я один из разработчиков Puppet.
Очевидный способ - просто применить концепции: определить цикл разработки / тестирования / производства и продвигать изменения через них. Используйте контроль версий для отслеживания систем.
Вкратце, начав этот путь, вы обнаружите, что вам действительно нужны инструменты, которые автоматизируют эти вещи - по сути, вы хотите автоматизировать системное администрирование, чтобы вы не использовали эти методы на машинах, вы использовали их в системе, которая управляет машинами.
Такие инструменты, как Повар, Кукольный, Поваренная соль, и CFEngine все это популярные инструменты для решения этой второй потребности. Они работают в общем направлении превращения системного администрирования в центральное решение, которое вы можете контролировать и тестировать.
В DevOps движение - еще один источник хорошей информации о том, как это сделать. Хотя наставление заключается в лучшем сотрудничестве между разработчиками и операционным персоналом, оно также имеет тенденцию к тому же.
Краткий ответ: «Управление развертыванием ОС», «Управление конфигурацией» и «Пакетирование программного обеспечения». Далее следует длинный ответ.
Я хотел бы добавить к ответу Дэниела Питтмана подробное описание того, что образует «систему» в системном администрировании.
Система или среда будет включать:
Их охватят такие процессы, как:
И вы хотели бы, чтобы они были объединены вместе, чтобы помочь вам в достижении нефункциональных целей, таких как:
Это быстрая свалка мозгов. Я уверен, что во все списки можно было бы добавить больше.
Ваш вопрос касается некоторых из них без использования конкретных слов. Например, вы хотите иметь возможность легко развернуть и вернуться назад, т.е. хотите ремонтопригодности; вы хотите сделать это в тестовой среде и тестировать до тех пор, пока он не пройдет, т.е. повторяемость, тестируемость и измеримость; вы думаете о включении образов vm в систему контроля версий, потому что вам нужна повторяемость развертываний ОС и конфигурации.
Есть множество инструментов, которые помогут вам в этом, некоторые из них упомянуты Дэниелом. Некоторые другие:
Опять же, это не полный список, это то, что я держу в голове, чтобы направлять меня, и, надеюсь, это поможет и вам.
В мире Windows эти проблемы, связанные с управлением жизненным циклом приложений, решаются с помощью System Center 2012.
В System Center Virtual Machine Manager (SCVMM) службы определяются с помощью «шаблонов служб» (например, классическая трехуровневая служба), а среды выполнения определяются как «облака» (например, разработка, постановка, производство). Шаблоны служб могут быть версированы и развернуты (автоматическим способом) в различных облаках. По сути, SCVMM выполняет работу по предоставлению, развертыванию и настройке виртуализированного оборудования (виртуальные машины и т. Д.) И программного обеспечения (ОС, компоненты приложений и т. Д.).
System Center Service Manager - это то, что связывает воедино с точки зрения процесса. Например, управление проблемами и контроль изменений.