Руководство по эксплуатации

Сервер Chef Infra Server служит центром для данных конфигурации. Сервер Chef Infra Server хранит кулинарии, политики, применяемые к узлам, и метаданные, описывающие каждый зарегистрированный узел, управляемый клиентом Chef Infra Client. Узлы используют клиент Chef Infra Client для запроса у сервера Chef Infra Server информации о конфигурации, такой как рецепты, шаблоны и распределение файлов. Клиент Chef Infra Client выполняет как можно больше работы по конфигурации на самих узлах (а не на сервере Chef Infra Server). Такой масштабируемый подход распределяет усилия по конфигурации по всей организации.

Фронтенд для сервера Chef Infra Server написан на языке программирования Erlang, который впервые появился в 1986 году, был выпущен с открытым исходным кодом в 1998 году и отлично подходит для критически важных задач корпоративного уровня, таких как конкурентность, отказоустойчивость и распределённые среды. Сервер Chef Infra Server может масштабироваться до размеров любой корпорации и иногда называется Erchef.

На следующей схеме показаны различные компоненты, входящие в развертывание сервера Chef Infra Server, и их взаимосвязь.

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

Отслеживание

Отслеживание сервера Chef Infra Server включает два типа проверок: приложения и системы. Кроме того, рекомендуется отслеживать HTTP-запросы, которые рабочие станции и узлы отправляют серверу Chef Infra Server, и объёмы хранилища данных на каждом диске.

Приоритеты мониторинга

В следующих разделах описаны приоритеты мониторинга сервера Chef Infra Server. В частности, недостаток дискового пространства является основной причиной отказов.

Диски

Со временем, и с достаточным количеством данных, диски заполнятся или превысят установленные для них квоты на диск и не смогут записывать данные. Диск, который не может записывать данные, не сможет поддерживать определённые компоненты сервера Chef Infra Server, такие как PostgreSQL, логи служб и обработанные файлы. Мониторинг использования дискового пространства — лучший способ гарантировать, что диски не заполняются и не превышают свою квоту.

Используйте следующие команды для мониторинга общего использования дискового пространства на сервере Chef Infra Server с типичной установкой:

du -sh /var/opt/opscode

и:

du -sh /var/log/opscode

Для поддержания работоспособности сервера Chef Infra Server оба /var/opt/opscode и /var/log/opscode не должны превышать 80% использования. В ситуациях, когда объём дискового пространства растёт быстрыми темпами, может быть предпочтительнее выключить сервер Chef Infra Server и обратиться в службу поддержки Chef.

Следующие компоненты следует отслеживать на наличие признаков быстрого заполнения дисков:

• PostgreSQL PostgreSQL — хранилище данных для сервера Chef Infra Server.
• Лог-файлы Если /var/log/opscode занимает много дискового пространства, убедитесь, что задача cron для ротации логов сервера Chef Infra Server выполняется без ошибок. Эти ошибки могут быть найдены в /var/log/messages, /var/log/syslog и/или локальной почте пользователя root.
• Обработанные файлы Запущенные процессы с файловыми дескрипторами, связанные с одним (или несколькими) удалёнными файлами, будут препятствовать освобождению дискового пространства, используемого удалёнными файлами. Используйте команду sudo lsof | grep '(deleted)' для поиска всех удалённых файловых дескрипторов.

Проверки приложений

Периодически следует проводить проверки на уровне приложения, чтобы убедиться в достаточном объёме дискового пространства, оперативной памяти и в том, что службы фронтенда и бэкенда обмениваются данными.

Erlang

Многие компоненты сервера Chef Infra Server написаны на Erlang и выполняются в виртуальной машине BEAM. Одна из особенностей Erlang и BEAM — возможность взаимодействия с работающей службой с помощью командной оболочки. Например:

cd /opt/opscode/embedded
  export PATH=$PATH:/opt/opscode/bin:/opt/opscode/embedded/bin
  bin/erl -setcookie service_name -name me@127.0.0.1 -remsh service_name@127.0.0.1

где service_name это bifrost или erchef. Эта команда откроет оболочку, подключенную к процессам Erchef:

Erlang R15B02 (erts-5.9.2) [source] [64-bit] ...

Для подключения к службе oc_bifrost используйте следующую команду:

erl -setcookie oc_bifrost -name me@127.0.0.1 -remsh oc_bifrost@127.0.0.1

Для подключения к службе opscode-erchef используйте следующую команду:

erl -setcookie erchef -name me@127.0.0.1 -remsh erchef@127.0.0.1

Для отключения от оболочки используйте следующую последовательность нажатий клавиш CTRL-g, q, и затем ENTER.

Вывод из оболочки после CTRL-g похож на:

(erchef@127.0.0.1)1>
User switch command

затем введите q, и нажмите ENTER для выхода из оболочки.

Некоторые команды не следует вводить при взаимодействии с работающей службой с помощью командной оболочки, включая:

• q() убивает узел Erlang
• init:stop()
• exit или exit() ничего не делает

В качестве пользователя root на сервере Chef Infra Server обратитесь к включённому пакету инструментов отладки eper. Замените 2-й и 5-й пути и значение X.XX.X в следующем пути элементами, присутствующими в системе.

export ERL_LIB=:/opt/{chef-server,opscode}/embedded/service/{erchef,opscode-erchef}/lib/eper-X.XX.X/ebin/

Откройте командную оболочку Erlang, чтобы начать диагностику проблем служб на сервере Chef Infra Server:

Eshell V5.10.4  (abort with ^G)
(erchef@127.0.0.1)1>

Инструмент dtop предоставляет представление виртуальной машины Erlang, аналогичное команде linuxdagnostic. Точка в конце команды dtop требуется для её выполнения.

(erchef@127.0.0.1)1> dtop:start().

Чтобы остановить команду dtop, выполните:

(erchef@127.0.0.1)1> dtop:stop().

Для отключения от оболочки используйте следующую последовательность нажатий клавиш CTRL-g, q, и затем ENTER.

Вывод из оболочки после CTRL-g похож на:

(erchef@127.0.0.1)1>
User switch command

затем введите q, и нажмите ENTER для выхода из оболочки.

Nginx

Используйте Nginx для мониторинга служб, которые могут возвращать ошибки 504. Используйте следующую команду на машине фронтенда:

grep 'HTTP/1.1" 504' /var/log/opscode/nginx/access.log

а затем извлеките URL-адреса и отсортируйте их по количеству uniq:

grep 'HTTP/1.1" 504' nginx-access.log | cut -d' ' -f8 | sort | uniq -c | sort

В больших установках может потребоваться ограничить результаты подмножеством результатов:

tail -10000 nginx-access.log | grep 'HTTP/1.1" 504' | cut -d' ' -f8 | sort | uniq -c | sort

PostgreSQL

psql — инструмент управления для PostgreSQL. Он может использоваться для получения информации о данных, хранящихся в PostgreSQL. Для получения дополнительной информации о psql, см. http://www.postgresql.org/docs/manuals/, а затем набор документов, соответствующий используемой версии PostgreSQL.

Для подключения к базе данных PostgreSQL выполните следующую команду:

cd /opt/opscode/embedded/service/postgresql/
  export PATH=$PATH:/opt/opscode/bin:/opt/opscode/embedded/bin
  bin/psql -U opscode_chef

Redis

Служба redis_lb, расположенная на машине бэкенда, обрабатывает запросы, которые поступают от службы Nginx, расположенной на всех машинах фронтенда в кластере серверов Chef Infra Server.

В случае заполнения диска для хранилища данных Redis, dump.rdb (основное хранилище данных .rdb используемое Redis) может быть повреждено и сохранено как файл с размером 0 байт.

Когда это происходит, после запуска службы redis_lb в её логах будет показано сообщение, подобное следующему:

2015-03-23_16:11:31.44256 [11529] 23 Mar 16:10:09.624 # Server started, Redis version 2.8.2
2015-03-23_16:11:31.44256 [11529] 23 Mar 16:10:09.624 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
2015-03-23_16:11:31.44257 [11529] 23 Mar 16:11:31.438 # Short read or OOM loading DB. Unrecoverable error, aborting now.

Файл dump.rdb будет пустым:

ls -al /var/opt/opscode/redis_lb/data/
total 20
drwxr-x--- 2 opscode opscode 4096 Mar 23 15:58 .
drwxr-x--- 4 opscode opscode 4096 Dec 22 18:59 ..
-rw-r--r-- 1 opscode opscode    0 Mar 23 15:58 dump.rdb

Эта ситуация вызвана ошибкой в Redis, где сохранения разрешено производить даже когда диск был заполнен в течение некоторого времени, а не только в критических ситуациях, когда диск заполняется по мере записи в Redis. Для решения этой проблемы выполните следующие действия:

1. Остановить службу redis_lb:

   chef-server-ctl stop redis_lb
   

2. Удалить поврежденные файлы:

   cd /var/opt/opscode/redis_lb/data
   rm -fr *rdb
   

3. Запустить службу redis_lb:

   chef-server-ctl start redis_lb
   
   less /var/log/opscode/redis_lb/current
   2015-03-23_17:05:18.82516 [28676] 23 Mar 17:05:18.825 * The server is now ready to accept connections on port 16379
   

4. Переконфигурировать сервер Chef Infra для повторной загрузки Redis:

   chef-server-ctl reconfigure
   

5. Проверить, что Redis повторно загружен, по ключу dl_default:

   /opt/opscode/embedded/bin/redis-cli -p 16379 keys \*
   1) "dl_default"
   

Проверки системы

Необходимо выполнять проверки на уровне системы для статуса портов и служб.

chef-backend-ctl status

Подкоманда chef-backend-ctl status используется для проверки статуса служб, работающих в топологии сервера Chef Backend. Эта команда проверит статус следующих служб на узле, на котором она выполняется:

• leaderl
• postgresql
• etcd
• epmd
• elasticsearch

Она также проверит статус других узлов в кластере с точки зрения текущего узла. Например:

chef-backend-ctl status
Service Local Status Time in State Distributed Node Status
leaderl running (pid 1191) 53d 15h 11m 12s leader: 1; waiting: 0; follower: 2;    total: 3
epmd running (pid 1195) 53d 15h 11m 12s status: local-only
etcd running (pid 1189) 53d 15h 11m 12s health: green; healthy nodes: 3/3
postgresql running (pid 40686) 0d 12h 36m 23s leader: 1; offline: 0; syncing: 0;    synced: 2
elasticsearch running (pid 47423) 0d 12h 18m 6s state: green; nodes online: 3/3

System Local Status Distributed Node Status
disks /var/log/chef-backend: OK; /var/opt/chef-backend: OK health: green; healthy    nodes: 3/3

Дополнительную информацию о каждой службе можно найти в отдельных логах служб в /var/opt/chef-backend/.

opscode-authz

API authz предоставляет общий обзор состояния службы opscode-authz с помощью простого конечной точки: _ping. К этой конечной точке можно получить доступ с помощью cURL и GNU Wget. Например:

curl http://localhost:9463/_ping

Эта команда обычно выводит много информации. Используйте Python для красивого вывода:

curl http://localhost:9463/_ping | python -mjson.tool

opscode-erchef

API статуса предоставляет общий обзор состояния системы с помощью простого конечной точки: _status. К этой конечной точке можно получить доступ с помощью cURL и GNU Wget. Например:

curl http://localhost:8000/_status

что вернёт что-то подобное:

{
  "status":"pong",
  "upstreams":{"upstream_service":"pong","upstream_service":"fail",...},
}

Для каждой из upstream-служб возвращается pong или fail. Возможные названия upstream-служб:

• chef_sql (для службы postgresql)
• oc_chef_authz (для службы opscode-authz)

Если любое из значений статуса вернёт fail, это обычно означает, что сервер Chef Infra недоступен для этой службы.

Узлы, рабочие станции

Если клиент отправляет HTTP-запрос на сервер, который возвращает сообщение об ошибке общего характера, это обычно проблема со службами opscode-chef или opscode-erchef. Просмотрите полное сообщение об ошибке для этих служб в соответствующих файлах журналов. Ошибка чаще всего представляет собой стек вызовов из ошибки приложения. В некоторых случаях сообщение об ошибке явно указывает на проблему с другой службой, которую можно далее исследовать. При неочевидных ошибках обратитесь в службу поддержки Chef.

Файлы журналов

Все журналы, сгенерированные сервером Chef Infra, можно найти в /var/log/opscode. Каждая служба, включённая в систему, также имеет подкаталог, в котором находятся журналы, относящиеся к этой службе, обычно в /var/log/opscode/service_name.

Просмотр файлов журналов

Сервер Chef Infra имеет встроенную поддержку для удобного просмотра журналов. Чтобы просмотреть все генерируемые журналы на сервере Chef Infra, введите следующую команду:

chef-server-ctl tail

Чтобы просмотреть журналы для определённой службы:

chef-server-ctl tail SERVICENAME

где SERVICENAME следует заменить именем службы, журналы которой нужно просмотреть.

Просмотр журналов

Подкоманда tail используется для просмотра всех журналов сервера Chef Infra для всех служб. Эту команду также можно запустить для отдельной службы, указав имя службы в команде.

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl tail SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая перечислена после запуска подкоманды service-list.

Ещё один распространённый подход к просмотру журналов службы — использовать системную утилиту tail. Например:

tail -50f /var/log/opscode/opscode-erchef/current

Supervisor

Журналы Supervisor создаются и управляются непосредственно службой supervisor, и автоматически вращаются, когда текущий файл журнала достигает 1 000 000 байт. Сохраняется 10 файлов журналов. Последний журнал supervisor всегда находится в /var/log/service_name/current , а вращающиеся журналы имеют имя файла, начинающееся с @ , за которым следует точный tai64n временной отметки, основанной на том, когда файл был отсортирован.

Журналы Supervisor доступны для следующих служб:

• bifrost
• bookshelf
• elasticsearch
• nginx
• opscode-erchef
• postgresql
• redis

nginx, доступ

Nginx является важным входным точкой для данных на сервере Chef Infra, поэтому отладка часто начинается с анализа файла access.log службы nginx. Этот журнал содержит каждый HTTP-запрос, сделанный на фронтенд-машину, и может быть очень полезен при исследовании скорости запросов и паттернов использования. Следующее — пример записи журнала:

175.185.9.6 - - [12/Jul/2013:15:56:54 +0000] "GET
/organizations/exampleorg/data/firewall/nova_api HTTP/1.1" 200
"0.850" 452 "-" "Chef Client/0.10.2 (ruby-1.8.7-p302; ohai-0.6.4;
x86_64-linux; +https://chef.io)" "127.0.0.1:9460" "200"
"0.849" "0.10.2" "version=1.0" "some_node.example.com"
"2013-07-12T15:56:40Z" "2jmj7l5rSw0yVb/vlWAYkK/YBwk=" 985

где важные поля в этом журнале включают:

• Код HTTP-статуса (200)
• IP-адрес клиента, который сделал запрос (175.185.9.6)
• Временная метка ([12/Jul/2013:15:56:54 +0000])
• Общее время запроса ("0.850")
• Метод запроса (GET)
• URL запроса (/organizations/exampleorg/data/firewall/nova_api)

opscode-erchef, текущий

Файл current.log службы opscode-erchef содержит историю стеков вызовов при крупных сбоях приложения.

opscode-erchef, erchef

Файл erchef.log службы opscode-erchef содержит историю обработанных запросов API Erchef. Эти журналы могут быстро вращаться, поэтому обычно лучше сортировать их по дате и найти последний обновлённый файл журнала:

ls -lrt /var/log/opscode/opscode-erchef/erchef.log.*

Следующее — пример записи журнала:

2013-08-06T08:54:32Z erchef@127.0.0.1 INFO org_name=srwjedoqqoypgmvafmoi; req_id=g3IAA2QAEGVyY2hlZkAx

где важные поля в этом журнале включают:

• Метод HTTP (POST)
• Путь HTTP (/organizations/srwjedoqqoypgmvafmoi/environments)
• Сообщение ({created,<<"_default">>})
• Имя организации (org_name=srwjedoqqoypgmvafmoi)
• Временная метка (2013-08-06T08:54:32Z)
• Имя пользователя и/или клиента Chef Infra, который сделал запрос (pivotal)

Кроме того, файл журнала может содержать дополнительные записи, которые детально описывают затраченное время на взаимодействие с другими службами:

• rdbms_time (время взаимодействия со службой postgresql)
• req_time (время запроса)
• solr_time (время взаимодействия со службой opscode-solr)

Приложение

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

nginx

Служба nginx создаёт как supervisor-журналы, так и административные журналы. Административные журналы содержат журналы доступа и ошибок для каждого виртуального хоста, используемого сервером Chef Infra. Каждый из следующих журналов требует внешнего вращения журналов.

Чтобы просмотреть журналы службы:

chef-server-ctl tail nginx

Формат журнала доступа nginx:

log_format opscode '$remote_addr - $remote_user [$time_local]  '
  '"$request" $status "$request_time" $body_bytes_sent '
  '"$http_referrer" "$http_user_agent" "$upstream_addr" '
  '"$upstream_status" "$upstream_response_time" "$http_x_chef_version" '
  '"$http_x_ops_sign" "$http_x_ops_userid" "$http_x_ops_timestamp" '
   '"$http_x_ops_content_hash" $request_length';

Пример записи журнала:

192.0.2.0 - - [17/Feb/2012:16:02:42 -0800]
  "GET /organizations/nginx/cookbooks HTTP/1.1" 200
  "0.346" 12 "-"
  "Chef Knife/0.10.4 (ruby-1.9.3-p0;
                      ohai-0.6.10;
                      x86_64-darwin11.2.0;
                      +http://opscode.com
                      )"
  "127.0.0.1:9460" "200" "0.339" "0.10.4"
  "version=1.0" "adam" "2012-02-18T00:02:42Z"
  "2jmj7l5rSw0yVb/vlWAYkK/YBwk=" 871

Описание полей:

Брандмауэры и порты

Все порты, используемые сервером Chef Infra Server, являются портами TCP. Обратитесь к руководству по эксплуатации операционной системы или к системным администраторам сайта за инструкциями по включению необходимых изменений портов.

Все службы должны прослушивать соответствующие порты. Большинство систем мониторинга предоставляют средства проверки того, принимает ли данный порт подключения, а также могут быть доступны инструменты, специфичные для конкретной службы. Кроме того, для инициации подключения можно использовать общий системный инструмент Telnet:

telnet HOST_NAME PORT

Standalone

В следующих разделах описываются порты, необходимые для сервера Chef Infra Server в конфигурации standalone:

Должен быть настроен единственный интерфейс обратной связи с использованием адреса 127.0.0.1. Это гарантирует доступность всех служб серверу Chef Infra Server в случае, если сервер Chef Infra Server попытается связаться с собой из машины переднего или заднего плана. Все порты должны быть доступны через интерфейс обратной связи соответствующих хостов.

Для автономной установки убедитесь, что порты, помеченные как внешние (отмеченные как yes в столбце Внешний), открыты и доступны через любые используемые брандмауэры:

Многоуровневый

В следующих разделах описываются порты, необходимые для сервера Chef Infra Server в многоуровневой конфигурации:

Должен быть настроен единственный интерфейс обратной связи с использованием адреса 127.0.0.1. Это гарантирует доступность всех служб серверу Chef Infra Server в случае, если сервер Chef Infra Server попытается связаться с собой из машины переднего или заднего плана. Все порты должны быть доступны через интерфейс обратной связи соответствующих хостов.

Фронтенд

Для серверов фронтенда убедитесь, что порты, отмеченные как внешние (отмеченные как yes в столбце Внешний), открыты и доступны через любые используемые брандмауэры:

Бэкенд

Для серверов бэкенда в многоуровневой установке сервера Chef Infra Server убедитесь, что порты, помеченные как внешние (отмеченные как yes в столбце Внешний), открыты и доступны через любые используемые брандмауэры:

Задачи Chef Push

Порты протокола TCP 10000, 10002 и 10003. 10000 — это порт по умолчанию для проверки состояния, 10002 — порт по умолчанию для команд, 10003 — порт по умолчанию для API. Эти значения могут быть настроены в файле конфигурации задач Chef Push Jobs. Порт команд позволяет клиентам задач Chef Push Jobs взаимодействовать с сервером задач Chef Push Jobs, а также позволяет компонентам сервера Chef взаимодействовать с сервером задач push-jobs. В конфигурации с передним и задним концами этот порт должен быть открыт только на серверах заднего конца. Сервер задач Chef Push Jobs ожидает подключения от клиента задач Chef Push Jobs и никогда не инициирует подключение к клиенту задач Chef Push Jobs. В ситуациях, когда сервер Chef имеет общедоступный адрес, не назначенный локально (например, развертывание в облаке / или за NAT), порт API следует добавить в конфигурацию сетевой безопасности для подключения сервера Chef к самому себе по общедоступному IP-адресу, если это то, что указывает имя хоста сервера Chef.

Услуги

Сервер Chef Infra Server имеет встроенный супервайзор процессов, который гарантирует, что все необходимые службы находятся в соответствующем состоянии в любой момент времени. Супервайзор запускает два процесса на каждую службу.

Подкоманды служб

Эта команда имеет встроенный супервайзор процессов, который гарантирует, что все необходимые службы находятся в соответствующем состоянии в любой момент времени. Супервайзор запускает два процесса на каждую службу и предоставляет следующие подкоманды для управления службами: hup, int, kill, once, restart, service-list, start, status, stop, tail, и term.

hup

Подкоманда hup используется для отправки SIGHUP всем службам. Эту команду также можно выполнить для отдельной службы, указав имя службы в команде.

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl hup SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая указана после выполнения подкоманды service-list.

int

Подкоманда int используется для отправки SIGINT всем службам. Эту команду также можно выполнить для отдельной службы, указав имя службы в команде.

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl int SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая указана после выполнения подкоманды service-list.

kill

Подкоманда kill используется для отправки SIGKILL всем службам. Эту команду также можно выполнить для отдельной службы, указав имя службы в команде.

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl kill SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая указана после выполнения подкоманды service-list.

once

Супервайзор сервера Chef Infra Server настроен на перезапуск любой службы, которая завершается ошибкой, если только эта служба не была попрошена изменить своё состояние. Подкоманда once используется для того, чтобы сообщить супервайзору не пытаться перезапускать службы, которые завершились ошибкой.

Эта команда полезна при устранении неполадок в конфигурации, которые препятствуют запуску службы. Выполните подкоманду once с последующей подкомандой status для поиска служб в состоянии «выключено» и/или для определения того, какие службы испытывают проблемы. Эту команду также можно выполнить для отдельной службы, указав имя службы в команде.

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl once SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая указана после выполнения подкоманды service-list.

restart

Подкоманда restart используется для перезапуска всех служб, включённых на сервере Chef Infra Server, или для перезапуска отдельной службы, указав имя этой службы в команде.

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl restart SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая указана после выполнения подкоманды service-list. После успешного перезапуска службы вывод должен быть похожим на:

ok: run: service_name: (pid 12345) 1s

service-list

Подкоманда service-list используется для отображения списка всех доступных служб. Включённая служба помечена звёздочкой (*).

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl service-list

start

Подкоманда start используется для запуска всех включённых служб на сервере Chef Infra Server. Эту команду также можно выполнить для отдельной службы, указав имя службы в команде.

Эта подкоманда имеет следующий синтаксис:

chef-server-ctl start SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая указана после выполнения подкоманды service-list . После успешного запуска службы вывод должен быть похожим на:

ok: run: service_name: (pid 12345) 1s

Супервайзор сервера Chef Infra Server настроен на ожидание семь секунд, чтобы служба ответила на команду от супервайзора. Если вы видите вывод, содержащий ссылку на таймаут, это означает, что сигнал был отправлен процессу, но сам процесс ещё не выполнил его. В целом, процессы с таймаутами обычно не представляют серьёзной проблемы, если они вообще не реагируют на сигналы. Если процесс не отвечает, используйте команду, такую как подкоманда kill для остановки процесса, расследуйте причину (по необходимости), а затем используйте подкоманду start для повторного включения.

status

Подкоманда status используется для отображения статуса всех служб, доступных серверу Chef Infra Server. Результаты будут различаться в зависимости от конфигурации конкретного сервера. Эта подкоманда имеет следующий синтаксис:

chef-server-ctl status

и вернёт статус всех служб. Статус может быть возвращён для отдельных служб, указав имя службы как часть команды:

chef-server-ctl status SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, указанной после выполнения подкоманды service-list.

При запросе статуса службы вывод должен быть похожим на:

run: service_name: (pid 12345) 12345s; run: log: (pid 1234) 67890s

где

• run: — состояние службы (run: или down:)
• service_name: — имя службы, для которой возвращён статус
• (pid 12345) — идентификатор процесса
• 12345s — время работы службы в секундах

Например:

down: opscode-erchef: (pid 35546) 10s

По умолчанию runit автоматически перезапустит службы при их сбое. Поэтому runit может отобразить статус службы как run:, даже если есть проблема с этой службой. При расследовании причин, по которым определённая служба не работает должным образом, обратите внимание на службы с наименьшим временем работы. Например, список ниже указывает, что службу opscode-erchef следует дополнительно исследовать:

run: oc-id
run: opscode-chef: (pid 4327) 13671s; run: log: (pid 4326) 13671s
run: opscode-erchef: (pid 5383) 5s; run: log: (pid 4382) 13669s

Типичная строка статуса службы, выполняющей любую из служб переднего плана сервера Chef Infra Server, похожа на следующую:

run: name_of_service: (pid 1486) 7819s; run: log: (pid 1485) 7819s

где:

• run описывает состояние, в котором супервайзер пытается поддерживать процессы. Это состояние может быть либо run, либо down. Если служба находится в состоянии down, её следует остановить
• name_of_service — это имя службы, например: opscode-erchef
• (pid 1486) 7819s; — это идентификатор процесса, за которым следует время работы службы в секундах
• run: log: (pid 1485) 7819s — это процесс ведения журнала. Для процесса ведения журнала характерно более длительное время работы, чем для службы; это связано с тем, что супервайзеру не нужно перезапускать процесс ведения журнала для подключения контролируемого процесса

Если служба не работает, строка состояния будет выглядеть примерно так:

down: opscode-erchef: 3s, normally up; run: log: (pid 1485) 8526s

где

• down указывает, что служба находится в нерабочем состоянии
• 3s, normally up; указывает, что служба обычно находится в рабочем состоянии и что супервайзер попытается перезапустить эту службу после перезагрузки

stop

Подкоманда stop используется для остановки всех служб, включенных на сервере Chef Infra Server. Эта команда также может быть выполнена для отдельной службы, указав её имя в команде.

Синтаксис этой подкоманды следующий:

chef-server-ctl stop SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая отображается после выполнения подкоманды service-list. После успешной остановки службы результат должен быть похож на:

ok: down: service_name: 0s, normally up

Например:

chef-server-ctl stop

вернет что-то подобное:

ok: down: nginx: 393s, normally up
ok: down: opscode-chef: 391s, normally up
ok: down: opscode-erchef: 391s, normally up
ok: down: opscode-solr4: 389s, normally up
ok: down: postgresql: 388s, normally up
ok: down: redis_lb: 387s, normally up

tail

Подкоманда tail используется для отслеживания всех журналов сервера Chef Infra Server для всех служб. Эта команда также может быть выполнена для отдельной службы, указав её имя в команде.

Синтаксис этой подкоманды следующий:

chef-server-ctl tail SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая отображается после выполнения подкоманды service-list.

term

Подкоманда term используется для отправки SIGTERM всем службам. Эта команда также может быть выполнена для отдельной службы, указав её имя в команде.

Синтаксис этой подкоманды следующий:

chef-server-ctl term SERVICE_NAME

где SERVICE_NAME представляет имя любой службы, которая отображается после выполнения подкоманды service-list.

Список служб

Следующие службы являются частью сервера Chef Infra Server:

• bifrost
• bookshelf
• elasticsearch
• nginx
• opscode-erchef
• postgresql
• redis-lb

bifrost

Служба oc_bifrost обеспечивает авторизацию каждого запроса на просмотр или управление объектами, хранящимися на сервере Chef Infra Server.

Чтобы просмотреть состояние службы:

chef-server-ctl status bifrost

чтобы получить что-то вроде:

run: bifrost: (pid 1234) 123456s; run: log: (pid 5678) 789012s

Чтобы запустить службу:

chef-server-ctl start bifrost

Чтобы остановить службу:

chef-server-ctl stop bifrost

Чтобы перезапустить службу:

chef-server-ctl restart bifrost

чтобы получить что-то вроде:

ok: run: bifrost: (pid 1234) 1234s

Чтобы завершить службу (отправить команду SIGKILL) :

chef-server-ctl kill bifrost

Запустить службу, но не перезапускать её (если служба выйдет из строя):

chef-server-ctl once bifrost

Чтобы следить за журналами службы:

chef-server-ctl tail bifrost

bookshelf

Служба bookshelf — это совместимая с Amazon Simple Storage Service (S3) служба, которая используется для хранения поваренных книг, включая все файлы — рецепты, шаблоны и так далее — связанные с каждой поваренной книгой.

Чтобы просмотреть состояние службы:

chef-server-ctl status bookshelf

чтобы получить что-то вроде:

run: bookshelf: (pid 1234) 123456s; run: log: (pid 5678) 789012s

Чтобы запустить службу:

chef-server-ctl start bookshelf

Чтобы остановить службу:

chef-server-ctl stop bookshelf

Чтобы перезапустить службу:

chef-server-ctl restart bookshelf

чтобы получить что-то вроде:

ok: run: bookshelf: (pid 1234) 1234s

Чтобы завершить службу (отправить команду SIGKILL) :

chef-server-ctl kill bookshelf

Запустить службу, но не перезапускать её (если служба выйдет из строя):

chef-server-ctl once bookshelf

Чтобы следить за журналами службы:

chef-server-ctl tail bookshelf

Elasticsearch

Чтобы просмотреть состояние службы:

chef-server-ctl status elasticsearch

чтобы получить что-то вроде:

elasticsearch: (pid 12345) 1s; run: log: (pid 5678) 123456s

Чтобы запустить службу:

chef-server-ctl start elasticsearch

чтобы получить что-то вроде:

ok: run: elasticsearch: (pid 5678) 0s

Чтобы остановить службу:

chef-server-ctl stop elasticsearch

чтобы получить что-то вроде:

ok: down: elasticsearch: 123456s, normally up

Чтобы перезапустить службу:

chef-server-ctl restart elasticsearch

чтобы получить что-то вроде:

ok: run: elasticsearch: (pid 56789) 1s

Чтобы завершить службу (отправить команду SIGKILL) :

chef-server-ctl kill elasticsearch

chef-server-ctl once elasticsearch

Чтобы следить за журналами службы:

chef-server-ctl tail elasticsearch

nginx

Служба nginx используется для управления трафиком на сервере Chef Infra Server, включая виртуальные хосты для маршрутизации внутренних и внешних запросов/ответов API, маршрутизации внешних запросов надстроек и маршрутизации между компонентами переднего и заднего плана.

Чтобы просмотреть состояние службы:

chef-server-ctl status nginx

чтобы получить что-то вроде:

run: nginx: (pid 1234) 123456s; run: log: (pid 5678) 789012s

Чтобы запустить службу:

chef-server-ctl start nginx

Чтобы остановить службу:

chef-server-ctl stop nginx

Чтобы перезапустить службу:

chef-server-ctl restart nginx

чтобы получить что-то вроде:

ok: run: nginx: (pid 1234) 1234s

Чтобы завершить службу (отправить команду SIGKILL) :

chef-server-ctl kill nginx

Запустить службу, но не перезапускать её (если служба выйдет из строя):

chef-server-ctl once nginx

Чтобы следить за журналами службы:

chef-server-ctl tail nginx

opscode-erchef

Служба opscode-erchef — это служба на основе Erlang, которая используется для обработки запросов API сервера Chef Infra Server в следующие области в пределах сервера Chef Infra Server:

• Поваренные книги
• Наборы данных
• Среды
• Узлы
• Роли
• Песочницы
• Поиск

Чтобы просмотреть состояние службы:

chef-server-ctl status opscode-erchef

чтобы получить что-то вроде:

run: opscode-erchefs: (pid 1234) 123456s; run: log: (pid 5678) 789012s

Чтобы запустить службу:

chef-server-ctl start opscode-erchef

Чтобы остановить службу:

chef-server-ctl stop opscode-erchef

Чтобы перезапустить службу:

chef-server-ctl restart opscode-erchef

чтобы получить что-то вроде:

ok: run: opscode-erchef: (pid 1234) 1234s

Чтобы завершить службу (отправить команду SIGKILL) :

chef-server-ctl kill opscode-erchef

Запустить службу, но не перезапускать её (если служба выйдет из строя):

chef-server-ctl once opscode-erchef

Чтобы следить за журналами службы:

chef-server-ctl tail opscode-erchef

postgresql

Служба postgresql используется для хранения данных узлов, объектов и пользователей.

Чтобы просмотреть состояние службы:

chef-server-ctl status postgresql

чтобы получить что-то вроде:

run: postgresql: (pid 1234) 123456s; run: log: (pid 5678) 789012s

Чтобы запустить службу:

chef-server-ctl start postgresql

Чтобы остановить службу:

chef-server-ctl stop postgresql

Чтобы перезапустить службу:

chef-server-ctl restart postgresql

чтобы получить что-то вроде:

ok: run: postgresql: (pid 1234) 1234s

Чтобы завершить службу (отправить команду SIGKILL) :

chef-server-ctl kill postgresql

Запустить службу, но не перезапускать её (если служба выйдет из строя):

chef-server-ctl once postgresqls

Чтобы следить за журналами службы:

chef-server-ctl tail postgresql

redis

Хранилище «ключ-значение», используемое совместно с Nginx для маршрутизации запросов и заполнения данных запроса, используемых сервером Chef Infra Server.

Чтобы просмотреть состояние службы:

chef-server-ctl status redis

чтобы получить что-то вроде:

run: redis: (pid 1234) 123456s; run: log: (pid 5678) 789012s

Для запуска службы:

chef-server-ctl start redis

Для остановки службы:

chef-server-ctl stop redis

Для перезапуска службы:

chef-server-ctl restart redis

чтобы вернуть что-то вроде:

ok: run: redis: (pid 1234) 1234s

Для завершения службы (отправка команды SIGKILL):

chef-server-ctl kill name_of_service

Для запуска службы, но без перезапуска (если служба завершится с ошибкой):

chef-server-ctl once redis

Для просмотра логов службы:

chef-server-ctl tail name_of_service

Безопасность

Это руководство охватывает функции безопасности, доступные в Chef Infra Server.

Сертификаты SSL

Начальная настройка Chef Infra Server выполняется автоматически с использованием самозаверяющего сертификата для создания файлов сертификата и закрытого ключа для Nginx. Этот раздел описывает процесс обновления сертификата SSL Chef Infra Server.

Автоматическая установка (рекомендуется)

Chef Infra Server можно настроить на использование сертификатов SSL, добавив следующие настройки в файл конфигурации сервера:

а затем задать их значения, чтобы определить пути к сертификату и ключу.

Например:

nginx['ssl_certificate'] = '/etc/pki/tls/certs/your-host.crt'
nginx['ssl_certificate_key'] = '/etc/pki/tls/private/your-host.key'

Сохраните файл и выполните следующую команду:

sudo chef-server-ctl reconfigure

Дополнительную информацию о файле конфигурации сервера см. в chef-server.rb.

Установка вручную

Сертификаты SSL можно обновить вручную, поместив файл сертификата и закрытого ключа, полученный из удостоверяющего центра, в соответствующие файлы после начальной настройки Chef Infra Server.

Расположение файлов сертификата и закрытого ключа:

• /var/opt/opscode/nginx/ca/FQDN.crt
• /var/opt/opscode/nginx/ca/FQDN.key

Так как FQDN уже настроен, выполните следующие действия:

1. Замените содержимое /var/opt/opscode/nginx/ca/FQDN.crt и /var/opt/opscode/nginx/ca/FQDN.key файлами удостоверяющего центра.

2. Перенастройте Chef Infra Server:

   chef-server-ctl reconfigure
   

3. Перезапустите службу Nginx для загрузки нового ключа и сертификата:

   chef-server-ctl restart nginx
   

Протоколы SSL

Следующие настройки часто изменяются от значений по умолчанию в процессе настройки службы nginx и для настройки Chef Infra Server на использование сертификатов SSL:

nginx['ssl_certificate']

Сертификат SSL, используемый для проверки связи по протоколу HTTPS. Значение по умолчанию: nil.

nginx['ssl_certificate_key']

Ключ сертификата, используемый для связи SSL. Значение по умолчанию: nil.

nginx['ssl_ciphers']

Список поддерживаемых наборов шифров, используемых для установления защищённого соединения. Для выбора AES256 с ECDHE forward security, удалите префикс RC4-SHA:RC4-MD5:RC4:RSA . Например:

nginx['ssl_ciphers'] =  "HIGH:MEDIUM:!LOW:!kEDH: \
                         !aNULL:!ADH:!eNULL:!EXP: \
                         !SSLv2:!SEED:!CAMELLIA: \
                         !PSK"

nginx['ssl_protocols']

Версии протокола SSL, которые включены. SSL 3.0 поддерживается Chef Infra Server; однако, SSL 3.0 является устаревшим и небезопасным протоколом. Протокол Transport Layer Security (TLS) — TLS 1.0, TLS 1.1 и TLS 1.2 — эффективно заменил SSL 3.0, что обеспечивает аутентифицированное согласование версии между Chef Infra Client и Chef Infra Server, которое гарантирует использование последней версии протокола TLS. Для наибольшей безопасности рекомендуется отключить SSL 3.0 и разрешить все версии протокола TLS. Например:

nginx['ssl_protocols'] = 'TLSv1 TLSv1.1 TLSv1.2'

Например, после копирования файлов сертификатов SSL в Chef Infra Server, обновите настройки nginx['ssl_certificate'] и nginx['ssl_certificate_key'] для указания путей к этим файлам, а затем (необязательно) обновите настройки nginx['ssl_ciphers'] и nginx['ssl_protocols'] для указания желаемого уровня безопасности Chef Infra Server:

nginx['ssl_certificate'] = '/etc/pki/tls/private/name.of.pem'
nginx['ssl_certificate_key'] = '/etc/pki/tls/private/name.of.key'
nginx['ssl_ciphers'] = 'HIGH:MEDIUM:!LOW:!kEDH:!aNULL:!ADH:!eNULL:!EXP:!SSLv2:!SEED:!CAMELLIA:!PSK'
nginx['ssl_protocols'] = 'TLSv1 TLSv1.1 TLSv1.2'

Пример: Настройка ключей SSL для Nginx

Следующий пример демонстрирует, как Chef Infra Server настраивает и конфигурирует сертификаты SSL для Nginx. Набор шифров, используемый Nginx, настраивается с помощью настроек ssl_protocols и ssl_ciphers.

ssl_keyfile = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}.key")
ssl_crtfile = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}.crt")
ssl_signing_conf = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}-ssl.conf")

unless ::File.exist?(ssl_keyfile) && ::File.exist?(ssl_crtfile) && ::File.exist?(ssl_signing_conf)
  file ssl_keyfile do
    owner 'root'
    group 'root'
    mode '0755'
    content '/opt/opscode/embedded/bin/openssl genrsa 2048'
    not_if { ::File.exist?(ssl_keyfile) }
  end

  file ssl_signing_conf do
    owner 'root'
    group 'root'
    mode '0755'
    not_if { ::File.exist?(ssl_signing_conf) }
    content <<-EOH
  [ req ]
  distinguished_name = req_distinguished_name
  prompt = no
  [ req_distinguished_name ]
  C                      = #{node['private_chef']['nginx']['ssl_country_name']}
  ST                     = #{node['private_chef']['nginx']['ssl_state_name']}
  L                      = #{node['private_chef']['nginx']['ssl_locality_name']}
  O                      = #{node['private_chef']['nginx']['ssl_company_name']}
  OU                     = #{node['private_chef']['nginx']['ssl_organizational_unit_name']}
  CN                     = #{node['private_chef']['nginx']['server_name']}
  emailAddress           = #{node['private_chef']['nginx']['ssl_email_address']}
  EOH
  end

  ruby_block 'create crtfile' do
    block do
      r = Chef::Resource::File.new(ssl_crtfile, run_context)
      r.owner 'root'
      r.group 'root'
      r.mode '0755'
      r.content "/opt/opscode/embedded/bin/openssl req -config '#{ssl_signing_conf}' -new -x509 -nodes -sha1 -days 3650 -key '#{ssl_keyfile}'"
      r.not_if { ::File.exist?(ssl_crtfile) }
      r.run_action(:create)
    end
  end
end

Knife, Chef Infra Client

Chef Server 12 и более поздние версии по умолчанию включают проверку SSL для всех запросов к серверу, таких как запросы от knife и Chef Infra Client. Сертификат, созданный во время установки Chef Infra Server, является самозаверяющим, что означает, что сертификат не подписан доверенным центром сертификации (ЦС), поставляемым с Chef Infra Client. Сертификат, созданный Chef Infra Server, должен быть загружен на любой компьютер, с которого knife и/или Chef Infra Client будут отправлять запросы на Chef Infra Server.

Например, без загрузки сертификата SSL следующая команда knife:

knife client list

возвращает ошибку, похожую на:

ERROR: SSL Validation failure connecting to host: chef-server.example.com ...
ERROR: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 ...

Это сделано по умолчанию и произойдёт, пока верифицируемый сертификат не будет добавлен на компьютер, с которого отправляется запрос.

См. Сертификаты SSL Chef Infra Client для получения дополнительной информации о том, как knife и Chef Infra Client используют сертификаты SSL, созданные Chef Infra Server.

Частный центр сертификации

Если организация использует внутренний центр сертификации, то корневой сертификат не будет отображаться в любом файле cacerts.pem поставляемом по умолчанию с операционными системами и веб-браузерами. Вследствие этого, ни одно из развернутых систем не сможет проверить сертификаты, выпущенные таким образом. Для того, чтобы другие системы могли доверять сертификатам, выпущенным внутренним центром сертификации, этот корневой сертификат должен быть сконфигурирован, чтобы другие системы могли следовать цепочке авторитета до корневого сертификата. (Промежуточный сертификат недостаточен, потому что корневой сертификат не является глобально известным.)

Для использования внутреннего центра сертификации добавьте сертификаты сервера (необязательно, а также любые промежуточные сертификаты) и корневой сертификат в один файл .crt. Например:

cat server.crt [intermediate.crt] root.crt >> /var/opt/opscode/nginx/ca/FQDN.crt

Проверьте корректность объединенного сертификата на Chef Infra Server:

openssl verify -verbose -purpose sslserver -CAfile cacert.pem  /var/opt/opscode/nginx/ca/FQDN.crt

Файл cacert.pem должен содержать только файл сертификата вашего корневого ЦС. Это не стандартный подход, но он имитирует поведение Chef Workstation после knife ssl fetch и knife ssl verify.

Промежуточные сертификаты

Для использования с провайдерами сертификатов сторонних организаций, например Verisign.

Для использования промежуточного сертификата добавьте как серверный, так и промежуточный сертификаты в один файл .crt. Например:

cat server.crt intermediate.crt >> /var/opt/opscode/nginx/ca/FQDN.crt

Проверка, что сертификат был подписан соответствующим ключом

Возможна несоответствие сертификата/ключа во время процесса создания запроса на подпись сертификата (CSR). Во время CSR всегда должен использоваться исходный ключ для сервера. Если вывод следующих команд не совпадает, возможно, CSR для нового ключа для этого хоста был сгенерирован с использованием случайного ключа или нового сгенерированного ключа. Симптомы этой проблемы будут похожи на следующее в логах nginx:

nginx: [emerg] SSL_CTX_use_PrivateKey_file("/var/opt/opscode/nginx/ca/YOUR_HOSTNAME.key") failed (SSL: error:0B080074:x509    certificate routines:X509_check_private_key:key values mismatch)

Вот как точно узнать, когда сконфигурированный сертификат не соответствует ключу:

## openssl x509 -in /var/opt/opscode/nginx/ca/chef-432.lxc.crt -noout -modulus | openssl sha1
(stdin)= 05b4f62e52fe7ce2351ff81d3e1060c0cdf1fa24

## openssl rsa -in /var/opt/opscode/nginx/ca/chef-432.lxc.key -noout -modulus | openssl sha1
(stdin)= 05b4f62e52fe7ce2351ff81d3e1060c0cdf1fa24

Для исправления этой проблемы необходимо сгенерировать новый CSR, используя оригинальный ключ сервера, тот же ключ, который использовался для создания CSR для предыдущих сертификатов. Установите эти новые сертификаты вместе с исходным ключом, и ошибка несоответствия должна исчезнуть.

Перегенерировать сертификаты

Сертификаты SSL должны периодически перегенерироваться. Это важная часть защиты Chef Infra Server от уязвимостей и помогает предотвратить компрометацию информации, хранящейся в Chef Infra Server.

Для перегенерации сертификатов SSL:

1. Выполните следующую команду:

   chef-server-ctl stop
   

2. Chef Infra Server сможет перегенерировать их. Эти сертификаты будут расположены в /var/opt/opscode/nginx/ca/ и будут именованы в соответствии с FQDN Chef Infra Server. Для определения FQDN сервера выполните следующую команду:

   hostname -f
   

   Пожалуйста, удалите файлы, найденные в каталоге ca с именами, подобными $FQDN.crt и $FQDN.key.

3. Если ваша организация предоставила пользовательские сертификаты SSL для Chef Infra Server, расположение пользовательского сертификата и закрытого ключа определено в /etc/opscode/chef-server.rb в качестве значений для настроек nginx['ssl_certificate'] и nginx['ssl_certificate_key']. Удалите файлы, указанные в этих двух настройках, и перегенерируйте новые ключи с использованием того же органа.

4. Выполните следующую команду; автоматически будут созданы сгенерированные сервером сертификаты SSL, если необходимо:

   chef-server-ctl reconfigure
   

5. Выполните следующую команду:

   chef-server-ctl start
   

Управление учетными данными Chef Infra Server

Новое в Chef Server 12.14: Chef Infra Server ограничивает места, куда записываются пароли и ключи служб на диск. В конфигурации по умолчанию данные учетных данных записываются только в файлы в /etc/opscode.

По умолчанию Chef Infra Server всё ещё записывает данные учетных записей служб в несколько мест внутри /etc/opscode. Это сделано для сохранения совместимости с плагинами. Chef Server 12.14 добавляет параметр конфигурации insecure_addon_compat в /etc/opscode/chef-server.rb, который позволяет дополнительно ограничить места записи учетных данных. insecure_addon_compat может быть использован, если вы не используете плагины или используете последние версии плагинов. Установка insecure_addon_compat на false записывает учетные данные только в одно место: /etc/opscode/private-chef-secrets.json.

Пользовательские секреты (например, пароль для внешнего экземпляра PostgreSQL) по-прежнему можно задать в /etc/opscode/chef-server.rb или через команды Управление секретами. Эти команды позволяют предоставить внешние пароли без их включения в файл конфигурации.

Совместимость с плагинами

В следующей таблице перечислены версии плагинов, которые поддерживают более ограниченное значение insecure_addon_compat false. Эти версии также теперь требуют Chef Server 12.14.0 или выше:

Эти новые плагины также будут записывать все свои секреты в /etc/opscode/private-chef-secrets.json. Более старые версии плагинов по-прежнему будут записывать свою конфигурацию в места в /etc и /var/opt.

/etc/opscode/private-chef-secrets.json

По умолчанию разрешения файла /etc/opscode/private-chef-secrets.json позволяют только пользователю root читать или писать в файл. Этот файл содержит все секреты для доступа к основным хранилищам данных сервера Chef, поэтому доступ к нему должен быть ограничен доверенными пользователями.

Хотя файл не содержит паролей в открытом виде, его не следует делиться с недоверенными пользователями. Формат файла секретов позволяет развертываниям Chef Infra Server соответствовать правилам, которые запрещают появление конфиденциальных данных в открытом виде в файлах конфигурации; однако, это не делает файл существенно более защищенным.

Шифрование SSL между Chef Infra Server и внешним PostgreSQL

Новое в Chef Infra Server 13.1.13: Chef Infra Server 13.1.13 добавляет возможность шифровать трафик между Chef Infra Server и внешним сервером PostgreSQL с помощью SSL. Данные инструкции не являются исчерпывающими и предполагают некоторую осведомленность в администрировании, конфигурировании и устранении неполадок PostgreSQL. Для получения дополнительной информации обратитесь к документации PostgreSQL.

Ниже приведен типичный сценарий включения шифрования между машиной, на которой работает Chef Infra Server, и внешней машиной, на которой работает PostgreSQL. Обе машины должны быть подключены к сети и доступны пользователю.

1. Выполните следующую команду на обеих машинах, чтобы получить права root:

   sudo -i
   

2. Убедитесь, что OpenSSL установлен на машине PostgreSQL.

3. Убедитесь, что поддержка SSL скомпилирована в PostgreSQL. Это относится как к компиляции из исходного кода, так и к использованию предварительно скомпилированного двоичного файла.

4. Разместите сертификаты SSL в соответствующих каталогах на машине PostgreSQL и убедитесь, что у них правильные имена файлов, права собственности и разрешения.

5. Включите SSL в PostgreSQL, отредактировав файл postgresql.conf. Установите ssl = on и укажите пути к сертификатам SSL:

   ssl=on
   
   ssl_cert_file='/path/to/cert/file'
   ssl_key_file='/path/to/key/file'
   

6. Чтобы предотвратить прием PostgreSQL соединений без SSL, отредактируйте файл pg_hba.conf на машине PostgreSQL и измените соответствующие соединения Chef Infra Server на hostssl.

   Вот пример файла pg_hba.conf с подключениями hostssl для Chef Infra Server (содержимое вашего pg_hba.conf будет отличаться):

   # "local" is for Unix domain socket connections only
   local      all             all                                     peer
   
   # IPv4 local connections:
   hostssl    all             all             127.0.0.1/32            md5
   
   # IPv6 local connections:
   hostssl    all             all             ::1/128                 md5
   
   # nonlocal connections
   hostssl    all             all            192.168.33.100/32        md5
   

7. Перезапустите PostgreSQL. Обычно это можно сделать с помощью следующей команды на машине PostgreSQL:

   /path/to/postgresql/postgresql restart
   

8. Отредактируйте /etc/opscode/chef-server.rb на сервере Chef Infra Server и добавьте следующую строку:

   postgresql['sslmode'] = 'require'
   

9. Запустите переконфигурацию на сервере Chef Infra Server:

   chef-server-ctl reconfigure
   

10. Проверьте, что SSL включен и что подключения SSL установлены между Chef Infra Server и работающим экземпляром PostgreSQL. Один из способов сделать это — войти в базу данных PostgreSQL с сервера Chef Infra Server, выполнив chef-server-ctl psql, а затем изучить состояние SSL с помощью запросов SQL.

    Запустите сеанс psql:

    chef-server-ctl psql opscode_chef
    

    В сеансе psql введите postgres=# show ssl; для отображения, включен ли ssl:

    postgres=# show ssl;
    
     ssl
    -----
     on
    (1 row)
    

    Затем введите postgres=# select * from pg_stat_ssl; для получения true (t) в строках с подключениями SSL:

    postgres=# select * from pg_stat_ssl;
    
      pid  | ssl | version |           cipher            | bits | compression | clientdn
    -------+-----+---------+-----------------------------+------+-------------+----------
     16083 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16084 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16085 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16086 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16087 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16088 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16089 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16090 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16091 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16092 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16093 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16094 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16095 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16096 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16097 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16098 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16099 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16100 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16101 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16102 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
     16119 | f   |         |                             |      |             |
    (21 rows)
    

Ротация ключей

См. команды ротации ключей chef-server-ctl для получения дополнительной информации о управлении ключами пользователей.

Настройка сервера

Файл конфигурации сервера содержит список всех доступных параметров конфигурации для Chef Infra Server. Некоторые из этих значений необходимо изменить для масштабных установок.

Настройка файла конфигурации

Файл /etc/opscode/chef-server.rb содержит все нестандартные параметры конфигурации, используемые сервером Chef Infra Server. Значения по умолчанию встроены в конфигурацию Chef Infra Server и должны добавляться в файл chef-server.rb только для применения нестандартных значений. Эти параметры конфигурации обрабатываются при выполнении команды chef-server-ctl reconfigure. Файл chef-server.rb — это Ruby-файл, что означает, что в нём можно использовать условные операторы.

Использование условий

Используйте оператор case для применения разных значений в зависимости от того, находится ли параметр на серверах фронта или бэкенда. Добавьте код в файл конфигурации сервера, подобный следующему:

role_name = ChefServer['servers'][node['fqdn']]['role']
case role_name
when 'backend'
  # backend-specific configuration here
when 'frontend'
  # frontend-specific configuration here
end

Рекомендуемые настройки

Следующие параметры обычно добавляются в файл конфигурации сервера (знак равенства не нужен для установки значения):

api_fqdn

FQDN сервера Chef Infra Server. Этот параметр по умолчанию не включен в файл конфигурации сервера. При добавлении его значение должно совпадать с FQDN URI службы, используемой сервером Chef Infra Server. Например: api_fqdn "chef.example.com".

bootstrap

Значение по умолчанию: true.

ip_version

Используется для установки версии IP: "ipv4" или "ipv6". При установке на "ipv6", API прослушивает IPv6, и службы фронта и бэкенда общаются по IPv6 при использовании конфигурации высокой доступности. При настройке IPv6 в конфигурации высокой доступности обязательно установите маску сети для атрибута IPv6 backend_vip. Значение по умолчанию: "ipv4".

notification_email

Значение по умолчанию: info@example.com.

Протоколы SSL

Следующие настройки часто изменяются из значений по умолчанию в рамках оптимизации службы nginx и настройки сервера Chef Infra Server для использования сертификатов SSL:

nginx['ssl_certificate']

Сертификат SSL, используемый для проверки связи по HTTPS. Значение по умолчанию: nil.

nginx['ssl_certificate_key']

Ключ сертификата, используемый для связи SSL. Значение по умолчанию: nil.

nginx['ssl_ciphers']

Список поддерживаемых наборов шифров, используемых для установления безопасного соединения. Для того чтобы отдать предпочтение AES256 с ECDHE forward security, удалите префикс RC4-SHA:RC4-MD5:RC4:RSA . Например:

nginx['ssl_ciphers'] =  "HIGH:MEDIUM:!LOW:!kEDH: \
                         !aNULL:!ADH:!eNULL:!EXP: \
                         !SSLv2:!SEED:!CAMELLIA: \
                         !PSK"

nginx['ssl_protocols']

Версии протоколов SSL, которые включены. SSL 3.0 поддерживается сервером Chef Infra Server; однако, SSL 3.0 — устаревший и небезопасный протокол. Протокол Transport Layer Security (TLS) — TLS 1.0, TLS 1.1 и TLS 1.2 — эффективно заменил SSL 3.0, предоставляя возможность аутентифицированной версии переговоров между Chef Infra Client и Chef Infra Server, что гарантирует использование последней версии протокола TLS. Для максимальной безопасности рекомендуется отключить SSL 3.0 и разрешить все версии протокола TLS. Например:

nginx['ssl_protocols'] = 'TLSv1 TLSv1.1 TLSv1.2'

Например, после копирования файлов сертификатов SSL на сервер Chef Infra Server, обновите параметры nginx['ssl_certificate'] и nginx['ssl_certificate_key'] для указания путей к этим файлам, а затем (необязательно) обновите nginx['ssl_ciphers'] и nginx['ssl_protocols'] для отражения желаемого уровня безопасности для Chef Infra Server:

nginx['ssl_certificate'] = '/etc/pki/tls/private/name.of.pem'
nginx['ssl_certificate_key'] = '/etc/pki/tls/private/name.of.key'
nginx['ssl_ciphers'] = 'HIGH:MEDIUM:!LOW:!kEDH:!aNULL:!ADH:!eNULL:!EXP:!SSLv2:!SEED:!CAMELLIA:!PSK'
nginx['ssl_protocols'] = 'TLSv1 TLSv1.1 TLSv1.2'

Настройка дополнительных служб

Следующие параметры часто используются для оптимизации производительности сервера Chef Infra Server в крупных установках.

chef-server-ctl reconfigure

bookshelf

Следующее значение часто изменяется от значения по умолчанию в процессе настройки службы bookshelf:

bookshelf['vip']

Виртуальный IP-адрес. Значение по умолчанию: node['fqdn'].

opscode-erchef

Следующие значения часто изменяются от значения по умолчанию в процессе настройки службы opscode-erchef:

opscode_erchef['db_pool_size']

Количество открытых подключений к PostgreSQL, поддерживаемых службой. Если ошибки указывают на то, что служба opscode-erchef исчерпала подключения, попробуйте увеличить значение postgresql['max_connections']. Если ошибки сохраняются, увеличьте это значение (постепенно) и также увеличьте значение postgresql['max_connections']. Значение по умолчанию: 20.

opscode_erchef['s3_url_ttl']

Время (в секундах), после которого подключения к серверу истекают. Если операции Chef Infra Client завершаются с ошибкой по таймауту, увеличьте это значение до 3600, а затем скорректируйте снова при необходимости. Значение по умолчанию: 900.

opscode_erchef['strict_search_result_acls']

Используется для указания того, что результаты поиска возвращают только те объекты, к которым у исполнителя

(пользователя, клиента и т.д.) есть доступ на чтение, как определено параметрами ACL. Это влияет на все поиски. Когда true, производительность консоли управления Chef может повыситься, потому что она позволяет консоли управления Chef пропускать избыточные проверки ACL. Для правильной настройки консоли управления Chef после применения этого параметра выполните chef-server-ctl reconfigure запуск chef-manage-ctl reconfigure, чтобы убедиться, что консоль управления Chef также учитывает это значение. Значение по умолчанию: false.

postgresql

Следующее значение часто изменяется от значения по умолчанию в процессе настройки службы postgresql:

postgresql['max_connections']

Максимальное количество разрешенных одновременных подключений. Это значение следует настраивать только при изменении значения opscode_erchef['db_pool_size'] используемой службой opscode-erchef. Значение по умолчанию: 350. Если в кластере более двух фронтенд-машин, следует увеличить значение postgresql['max_connections']. Увеличенное значение зависит от количества машин фронтенда, а также от количества служб, работающих на каждой из этих машин.

• Каждая фронтенд-машина всегда запускает службы oc_bifrost и opscode-erchef.
• Дополнение Reporting добавляет службу reporting.
• Служба Chef Push Jobs добавляет службу push_jobs.

Каждая из этих служб требует 25 подключений помимо значения по умолчанию.

Для определения необходимого увеличенного значения воспользуйтесь следующей формулой:

new_value = current_value + [
            (# of front end machines - 2) * (25 * # of services)
         ]

Например, если текущее значение равно 350, есть четыре фронтенд-машины и установлены все дополнения, то формула выглядит так:

550 = 350 + [(4 - 2) * (25 * 4)]

Резервное копирование и восстановление автономной или фронтенд-установки

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

chef-server-ctl

Для большинства случаев использования chef-server-ctl backup является рекомендуемым способом создания резервных копий Chef Infra Server. Используйте следующие команды для управления резервными копиями данных Chef Infra Server и для восстановления этих резервных копий.

backup

Подкоманда backup используется для резервного копирования всех данных Chef Infra Server. Эта подкоманда:

• Требует установки rsync на Chef Infra Server перед выполнением команды
• Требует chef-server-ctl reconfigure перед выполнением команды
• Не должна выполняться в конфигурации Chef Infra Server с внешней базой данных PostgreSQL; используйте knife ec backup вместо этого
• Помещает начальную резервную копию в каталог /var/opt/chef-backup в формате tar.gz; переместите эту резервную копию в новое место для сохранности

Параметры

У этой подкоманды есть следующие параметры:

-y, --yes

Используется для указания возможности выключения Chef Infra Server во время резервного копирования в формате tar.gz.

Синтаксис

У этой подкоманды следующий синтаксис:

chef-server-ctl backup

restore

Подкоманда restore используется для восстановления данных Chef Infra Server из резервной копии, созданной подкомандой backup. Эту подкоманду также можно использовать для добавления данных Chef Infra Server в недавно установленный сервер. Эта подкоманда:

• Требует установки rsync на Chef Infra Server перед выполнением команды
• Требует chef-server-ctl reconfigure перед выполнением команды
• Не должна выполняться в конфигурации Chef Infra Server с внешней базой данных PostgreSQL; используйте knife ec backup вместо этого

Параметры

У этой подкоманды есть следующие параметры:

-c, --cleanse

Используется для удаления всех существующих данных на Chef Infra Server; они будут заменены данными из резервной копии.

-d DIRECTORY, --staging-dir DIRECTORY

Используется для указания пути к пустому каталогу, который будет использоваться во время процесса восстановления. Этот каталог должен иметь достаточное количество дискового пространства для расширения всех данных из резервной копии.

Синтаксис

У этой подкоманды следующий синтаксис:

chef-server-ctl restore PATH_TO_BACKUP (options)

Примеры

chef-server-ctl restore /path/to/tar/archive.tar.gz

Резервное копирование и восстановление установки Chef Backend

В сценарии аварийного восстановления процессы резервного копирования и восстановления позволяют восстановить резервную копию данных в новый кластер. Он не предназначен для восстановления отдельной машины в кластере chef-backend или для отката существующего кластера в определенный момент времени.

Резервное копирование

Восстановление данных в случае чрезвычайной ситуации зависит от наличия предварительно сделанных резервных копий:

• данных в вашем кластере Chef Backend
• конфигурации вашего сервера Chef

Для создания резервных копий на будущее в сценариях катастроф:

1. На узле-ведомом chef-backend выполните chef-backend-ctl backup
2. На узле Chef Infra Server выполните: chef-server-ctl backup --config-only
3. Переместите архивы tar, созданные на шагах (1) и (2), в долгосрочное хранилище.

Восстановление

Для восстановления кластера Chef Infra Server, основанного на Chef Backend:

1. Восстановите узел и IP-адрес, который может быть использован для доступа к узлу на первой машине, которую вы хотите использовать в вашем новом кластере Chef Backend. Аргумент для опции --publish_address должен быть IP-адресом для доступа к узлу, который вы восстанавливаете.

   chef-backend-ctl restore --publish_address X.Y.Z.W /path/to/backup.tar.gz
   

2. Присоедините дополнительные узлы к вашему кластеру Chef Backend. (Если вы только тестируете и проверяете процесс восстановления, вы можете протестировать его на одном узле Chef Backend и одном узле Chef Infra Server.)

   chef-backend-ctl join-cluster IP_OF_FIRST_NODE --publish_address IP_OF_THIS_NODE
   

3. Восстановите Chef Infra Server из вашей резервной копии конфигурации Infra Server (см. шаг 2 в инструкции по резервному копированию выше). В качестве альтернативы вы можете сгенерировать новую конфигурацию для этого узла и перенастроить его, используя шаги, описанные в инструкциях по установке.

   chef-server-ctl restore /path/to/chef-server-backup.tar.gz
   

4. Выполните команду reindex для повторного заполнения индекса поиска

   chef-server-ctl reindex --all
   

Проверка

Рекомендуется периодически проверять вашу резервную копию, восстанавливая отдельный узел Chef Backend, отдельный узел Chef Infra Server и убеждаясь, что различные команды knife и операции Chef Infra Client успешно выполняются по вашей резервной копии.