-
Notifications
You must be signed in to change notification settings - Fork 2
/
introduction.tex
63 lines (45 loc) · 15.7 KB
/
introduction.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
\chapter{Введение}
\section{Системы автоматизации управления серверами}
Работа системного администратора в большинстве случаев связана с многократным выполнением однотипных и повторяющихся задач, например установка программ, создание пользователей, управление демонами и службами. Выполнение и повторное выполнение этих задач вручную очень неэффективно, занимает много времени и часто приводит к ошибкам, особенно при увеличении количества управляемых систем и усложнении задач.
В большинстве случаев системные администраторы начинают создавать свои инструменты, которые могли бы помочь им автоматизировать такие рутинные задачи. Чаще всего это бывают скрипты на Shell, Python, Perl или других языках программирования, которые, хотя и могут быть очень полезными, подходят только для применения их автором и только в его окружении, потому что практически никогда не документируются и не публикуются. Повторное использование таких инструментов тоже крайне затруднено, и при изменении окружения или после прихода новых людей их обычно просто бросают, потому что либо не могут адаптировать их под новые задачи, либо вообще понять как они работают. Но, поскольку появляются те же проблемы, что и раньше, создание таких инструментов начинается снова и снова.
Одним из путей решения проблем автоматизации и стандартизации начальных настроек систем можно назвать различные системы развертывания, такие как Red Hat Kickstart, Solaris Jumpstart, Debian Preseed/FAI, Windows Deployment Services и другие. Обычно они представляют из себя сетевой сервис, позволяющий быстро установить большое количество серверов и рабочих станций с заданными начальными настройками и сразу, без дополнительной работы, ввести их в эксплуатацию. Но после начала использования установленные системы остаются без обслуживания, и, в случае необходимости внесения изменений в конфигурацию уже установленных систем, приходится делать это либо вручную, либо путём переустановки с применением новых настроек, либо при помощи другой системы управления конфигурацией.
Многие крупные компании используют такие системы управления конфигурацией как Microsoft System Center или IBM Tivoli, но их использование влечёт за собой появление ряда новых проблем:
\begin{description}
\item[Цена] Хотя для крупных компаний это может быть и незначительный фактор, но при увеличении серверного парка расходы могут всё более и более увеличиваться.
\item[Гибкость] Коммерческие системы обычно очень хорошо реализуют требуемый набор функционала, но, если требуется решение нестандартной задачи, могут не давать возможностей для этого.
\item[Привязка к поставщику] Использование инструментов одного поставщика вынуждает работать только с его решениями, которые могут не взаимодействовать с компонентами другого поставщика или собственными разработками.
\end{description}
Системы управления конфигурацией с открытым исходным кодом зачастую могут решать те же самые задачи, но имеют следующие преимущества:
\begin{description}
\item[Бесплатность] Инструменты с открытым исходным кодом обычно можно использовать бесплатно и без ограничений, хотя часто могут быть доступны услуги коммерческой поддержки.
\item[Открытость] Человека, знакомый с языком программирования, на котором написана данная система, на должном уровне может изучить принципы работы такой системы и участвовать в её разработке.
\item[Расширяемость] Большинство подобных систем позволяют описывать решаемые задачи при помощи специального языка и создавать расширения и плагины для более нестандартных задач или задач, решение которых не входит в стандартный функционал системы.
\end{description}
За все время развития IT индустрии было разработано довольно много систем управления конфигурацией, как открытых, так и коммерческих и поддерживающих различные операционные системы и архитектуры. Некоторые более специализированны для решения определённой задачи, например управление кластером, а некоторые более универсальны.
К наиболее известным универсальным системам управления конфигурацией относятся:
\begin{enumerate}
\item Cfengine (http://cfengine.com) — старейший проект в этой области, существующий с 1993 года и написанный на C. Система использует клиент-серверную модель, основана на научных теориях и популярна в академической среде и образовательных учреждениях, хотя последняя версия уже имеет весь необходимый функционал для работы в корпоративной среде и коммерческую поддержку, она не получила популярности.
\item LCFG (http://www.lcfg.org/) — тоже старый проект разработанный в Эдинбургском университете и использующий XML для описания конфигурации систем.
\item Bcfg2 (http://trac.mcs.anl.gov/projects/bcfg2) — система управления конфигурацией созданная Аргоннской Национальной лабораторией на языке Python. Использует клиент-серверную архитектуру.
\item Puppet (http://puppetlabs.com) — самая популярная система управления конфигурацией как Unix, так и Windows систем, разрабатываемая с 2005 года Puppet Labs на языке программирования Ruby. Сейчас она используется или поддерживается такими крупными корпорациями как Google, Twitter, eBay, Disney, Citrix, Oracle, VMware и Cisco. Puppet Labs предоставляет как корпоративную версию с коммерческой поддержкой, так и открытую версию для сообщества с открытым исходным кодом под лицензией Apache 2.0. К основным особенностям Puppet можно отнести использование специального проблемно-ориентированного языка для описания конфигурации систем, код на котором может быть использован на всех платформах, декларативный принцип описания конфигурации, возможность работы как в клиент-серверном режиме, так и локально. Кроме специального языка, хорошо подходящего для решения типичных проблем, Puppet может быть легко расширен при помощи плагинов.
\item Chef (http://www.opscode.com/chef/) — самая молодая из систем управления конфигурацией промышленного уровня. Chef разрабатывается с 2009 года компанией Opscode на языке Ruby. Идеи, положенные в основу этой системы, во многом схожи с Puppet и Chef не уступает ей по функционалу и тоже имеет как версию для сообщества под лицензией Apache 2.0, так и коммерческую поддержку. Из основных отличий от Puppet можно назвать более близкий к чистому Ruby и более свободный проблемно-ориентированный язык, который, хоть и не ограничивает разработчика в нестандартных ситуациях, но и не настолько удобен для решения типичных задач, и императивный стиль описания конфигурации, а не декларативный, как у Puppet.
\end{enumerate}
Хотя все эти системы и работают по схожим принципам, позволяя как распространять файлы по управляемым системам, так и устанавливать программы и выполнять другие задачи, только Puppet и Chef позволяют системным администраторам описывать конфигурацию систем при помощи специального языка, который одинаково работает на всех платформах. Управление разными операционными операционными системами отличается только именами устанавливаемых пакетов и расположением конфигурационных файлов, которые могут быть выбраны автоматически по заданным правилам. Обе эти системы обладают отличной расширяемостью, как при помощи плагинов и дополнительных источников информации о целевой системе, так и путём использования шаблонов, которые позволяют адаптировать конфигурационные файлы и распространяемые скрипты в соответствии с требованиями операционной системы или задачи сервера.
\section{Преимущества и недостатки Puppet}
Сейчас Puppet является наиболее популярной системой управления конфигурацией, практически став промышленным стандартом. Большинство компаний предпочитает Puppet по следующим причинам:
\begin{itemize}
\item Puppet более зрелый проект, чем, например, Chef.
\item Puppet разрабатыватся коммерческой компанией, предоставляющей поддержку для предприятий.
\item Puppet поддерживается и используется большим количеством крупных корпораций.
\item Puppet имеет большее сообщество разработчиков и пользователей.
\item Puppet хорошо документирован и про него написано несколько книг.
\item Декларативный язык Puppet позволяет как проще решать типичные задачи, и удобен для системных администраторов, которые не всега являются хорошими программистами.
\item Модульность Puppet позволяет легко повторно использовать код и делиться им с сообществом.
\item Архитектура Puppet позволяет легко расширять его дополнительными компонентами и распространять их.
\end{itemize}
Тем не менее у Puppet есть несколько недостатков.
\begin{itemize}
\item Puppet написан на языке Ruby, который требует установки всего своего окружения и работает медленнее и потребляет больше ресурсов системы, чем, например, программы, написанные на языке C. Это усложняет использование Puppet на маленьких компьютерах встроенных систем.
\item Декларативный подход к написанию манифестов, хотя и значительно упрощает стандартные задачи, может очень затруднить решение сложных и нестандартных проблем, которые можно было бы легко решить, используя императивный подход.
\end{itemize}
Chef --- наиболее близкий конкурент Puppet среди открытых систем, пытающийся решить проблемы Puppet, но, хотя и тоже разрабатывается коммерческой компанией, предоставляющей как корпоративную версию, так и версию для сообщества, значительно уступает Puppet в популярности.