Ссылка на оригинал

Эта статья является введением в архитектуру Chef. Здесь описываются основные функции сервера Chef (Chef Server), функции узлов (Node) и управляющих станций Chef (Chef Workstation) при использовании Chef, а также взаимодействие между этими компонентами.

Позволю себе сделать несколько замечаний. Однозначных русских вариантов основных понятий я скорее не нашел. Каждый пишущий про Chef, переводит по-своему. Если какие-то варианты переводов покажутся неверными или читающий может предложить свой, более адекватный, милости прошу: пишите в Twitter, G+, Jabber или на почту. Кроме того, перевод не профессиональный. Я перевожу, кроме того, далеко не все, поскольку считаю, что главное передать смысл.

Chef Server, Узлы и Управляющие станции

При использовании Chef для управления инфраструктурой придется иметь дело с тремя типами хостов: сервером Chef, узлами и управляющими станциями Chef.

Chef Server

Chef Server - это центральное хранилище конфигурационных данных инфраструктуры. Chef Server хранит данные, необходимые для настройки узлов, а также предоставляет поиск, позволяющий динамически управлять конфигурацией узлов на основе данных. REST API делает эти данные доступными для узлов и управляющих станций. Дополнительно, есть возможность использовать Chef Server’s WebUI для управления инфраструктурой через веб-интерфейс.

Узлы

Узел - любой хост, настроенный на использование клиента chef. Клиент chef работает на узле, обращаясь к Chef Server за информацией, необходимой для настройки узла. С точки зрения сервера Chef, узел - чуть больше, чем список запуска (run_list), список рецептов и ролей, которые будут применены к узлу и будут определять его конфигурацию, и аттрибуты, набор данных о самом узле. Поскольку Узел - это машина, на которой работает chef-client, узлы иногда рассматриваются как “клиенты”. (Это не относится к клиентскому API, которое аутентифицируется через Chef Server API).

В случае, если узлы рассматриваются в качестве “клиентов”, предполагается связь между исполняемым файлом chef-client, вызовом API предназначенным для аутентификации и авторизации, используя идентификационную информацию в объекте клиентского API, для сохранения объекта узла на сервере.

Управляющая станция Chef

Управляющая станция - это хост, использующийся для изменения “поваренных книг” и других конфигурационных данных - обычно, это рабочая станция системного администратора. Также управляющая станция имеет два ключевых компонента:

  1. knife - приложение. поставляемое вместе с chef
  2. репозиторий, содержащий документы конфигурации инфраструктуры

Как будет видно в дальнейшем, эти документы конфигурации включают “поваренные книги”, роли, data bags и многое другое. В идеале, эти документы находятся под управлением какой-либо системы контроля версий. При использовании knife, рабочая станция используется как для выгрузки конфигурационных данных на Chef Server, так и для взаимодействия с отдельными узлами через SSH-соединение, если это необходимо.

Клиенты, Аутентификация и Авторизация

Роль Chef Server внутри инфраструктуры проста. Он хранит информацию о конфигурации, которая загружается на него, и возвращает эту информацию, когда ее запрашивает клиент API.

Chef использует клиентский API и систему аутентификации и авторизации, чтобы быть уверенным, что данные конфигурации могут быть прочитаны и обновлены только теми, кто авторизован. Клиент Chef (работающий на узле) и knife (работающий на управляющей станции) взаимодействуют с Chef Server, используя клиентский API.

Другими словами, клиент Chef - это сам испольняемый файл ‘chef-client’. Клиентский API - объект, который представляется зашифрованной “личностью”, использующейся для аутентификации и авторизации в каждом вызове API.

Для того, чтобы быть уверенным, что запросы приходят от известного API, Chef использует шифрование публичным ключом, пользователи Hosted Chef имеют некоторые дополнительные возможности более тонкой настройки. Клиенты API обладают соответствующими приватными и публичными ключами шифрования. Каждый запрос API, сделанный исполняемым файлом chef, подписывается конкретным приватным ключом клиента API. Затем Chef Server проверяет, что запрос соответствует публичныому ключу клиента.

После этого, Chef Server должен убедиться, что клдиент, сделавший запрос, имеет права, достаточные действий, которые запрашиваются (например, выгрузка “поваренной книги” или получение run_list.) Этот процесс известен как авторизация. Open Source Chef Server и Hosted Chef используют различные системы авторизации.

Open Source Chef

В Open Source Chef определенные клиенты API могут быть помечены как “admin clients”. Авторизация для различных действий устанавливается помечен ли клиент API как “admin” или нет. Admin clients используются при создании запросов через knife и обладают всеми возможными правами. Не-“admin” клиенты обладают ограниченными правами и используются для узлов внутри инфтраструктуры.

Hosted Chef

Hosted Chef использует более комплексную систему авторизации, обеспечивающую более точный контроль на основе client-by-client (или user-by-user). В этой системе клиенты API и пользователи могут иметь права на СОЗДАНИЕ, ЧТЕНИЕ, ОБНОВЛЕНИЕ, УДАЛЕНИЕ или права на ВЫДАЧУ ПРАВ для объектов, хранящихся на Hosted Chef (данные узла, данные “поваренной книги” и т.д.). Hosted Chef должен убедиться, что делающий запрос клиент имеет соответствующие права на запрашиваемое действие. Для упрощения управления правами Hosted Chef предоставляет множество заранее созданных групп, обладающих правами в соответствие с определенными ролями. Пользователи и клиенты, входящие в группу “admin”, имеют все права на все объекты. Не относящиеся к людям клиенты API (такие, как использующиеся узлами) будут автоматически помещены в группу клиентов, которые имеют права, подобные не-административным клиентам в Open Source Chef, тогда как клиенты-люди могут быть помещены в группу “users”, которая обладает правами, подобными административным клиентам в Open Source Chef.

Когда chef-client запускается на нвоом узле, Chef спроектирован для автоматического создания нового клиента API для данного узла. По этой причине, поскольку пользователи или административные клиенты настраиваются один раз должным образом для использования knife и подключения через WebUI или Management Console, часто бывает необходимо продумать детали клиентов API, аутентификации и авторизации.

Hosted Chef

В дополнение к более точной системы авторизации у Hosted Chef есть еще две концепции, не использующихся в Open Source Chef: Пользователи и Организации.

Пользователи

Пользователи - это, что и можно представить, исходя из названия: сертифицированные сущности, используюшиеся людьми для подключения к Hosted Chef. Как и клиенты, у них есть ключи, которые используются для программного подключения к Hosted Chef, через api.opscode.com или knife. Но у них также есть пароли, которые можно использовать для входа на различные веб-страницы, которые отображает Hosted Chef.

Пользователи могут относиться к организации, которая предоставит им соответствующие права для взаимодействия и управления этой организацией. Однако, в отличие от клиентских API, Пользователи могут относиться к более, чем одной организации, например, консультант мог бы создать отдельную организацию для каждого из своих клиентов. При планировании аутентификации и авторизации проще всего рассматривать пользователя как еще одного клиента API.

Пользователи обладают единственной учетной записью для всех страниц Opscode. Одни и те имя и пароль могут использоваться для входа в Hosted Chef Management Console, the Opscode Cookbooks Site или help.opscode.com.

Организации

При регистрации в Hosted Chef создается учетная запись пользователя и организация. Организация может представлять собой всю компанию целиком, какой-то отдельный департамент или любой сгруппированный набор серверной инфраструктуры, которым планируется управлять. Организации - это сущности, которые будут оплачиваться при использовании Hosted Chef. За исключением пользователей, ничего общего между организациями не существует. Клиентский API в одной организации не может прочитать данные узла из другой организации.