Инфраструктура SaltStack: создание состояний соли для веб-серверов Nginx

Вступление

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

В нашем previous мы расширили возможности нашего главного сервера Salt, настроив провайдер DigitalOcean для + salt-cloud +. Мы создали файлы, необходимые для раскрутки новых серверов для каждой из наших сред. В этой статье мы начнем погружаться в управление конфигурацией, создав файлы состояния соли для Nginx. Nginx будет использоваться на узлах нашего веб-сервера во всех трех средах для обработки веб-запросов.

Создайте основной файл состояния Nginx

Соль управляет конфигурацией через свою систему состояний. В простейшем случае они управляются файлами, расположенными в корневом каталоге файлового сервера Salt (который мы настроили как + / srv / salt +). Чтобы начать настройку Nginx, в этом месте мы создадим каталог, соответствующий программному обеспечению, которое мы настраиваем:

sudo mkdir /srv/salt/nginx

Файлы состояний имеют суффикс + .sls +. Файл + init.sls + в каталоге функционирует как основной файл конфигурации для этого конкретного состояния соли или формулы. Мы ссылаемся на имя родительского каталога, чтобы выполнить функции, содержащиеся в связанном файле + init.sls +.

Имея это в виду, создайте и откройте файл + init.sls + в этом каталоге, чтобы начать:

sudo nano /srv/salt/nginx/init.sls

Пакет Nginx и состояния обслуживания

Мы начнем с создания состояния с использованием идентификатора + nginx +. Это будет служить уникальным названием для этого конкретного государства в системе соленых государств. Поскольку мы не будем включать атрибут «name» для наших модулей состояния, он также будет служить целью для установки (для функции + pkg.installed +) и службы, которая будет запущена (для службы `+ .running + `function).

Мы хотим, чтобы Nginx автоматически перезагружался при определенных условиях: при обновлении пакета, при изменении основного файла конфигурации или при изменении файла блока сервера по умолчанию. Мы можем сказать Salt перезапустить службу Nginx, когда эти условия возникают, используя + watch +:

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

Клавиши + pkg: + и + file: + под клавишей + watch: + представляют модули состояния, связанные с ресурсами для наблюдения. Ресурс + pkg + рассматривается в первой части этого же определения. Нам нужно будет создать состояния, чтобы они соответствовали ресурсам + file.

Состояния файла конфигурации Nginx

Мы можем начать с файла + / etc / nginx / nginx.conf. Мы хотели бы сделать этот файл управляемым. В терминологии Salt это просто означает, что мы определим содержимое файла на главном сервере и загрузим его каждому миньону, который в этом нуждается. Мы установим довольно типичные права доступа и права доступа к файлу. Источник ссылается на местоположение на файловом сервере Salt (наш текущий файл также находится внутри этой структуры). Мы будем создавать этот путь и файл на мгновение:

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

Мы также хотим контролировать содержимое файла + / etc / nginx / sites-available / default +. Это определяет блок сервера, который контролирует, как будет обслуживаться наш контент. Государственный блок довольно похож на последний. Основное отличие состоит в том, что этот файл будет шаблоном Jinja.

Шаблоны Jinja позволяют Salt настраивать часть содержимого файла с подробностями, специфичными для каждого из миньонов, где он будет размещен. Это означает, что мы можем получать информацию с каждого хоста и создавать соответствующую, настроенную версию файла для каждого из наших веб-серверов. Мы указываем, что этот файл будет использовать Jinja с опцией + template +. Мы также будем использовать суффикс + .jinja + в исходном файле, чтобы сразу увидеть, что файл является шаблоном:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/nginx.conf:
 file.managed:
   - source: salt://nginx/files/etc/nginx/nginx.conf
   - user: root
   - group: root
   - mode: 640

У нас есть файл блока сервера по умолчанию, который будет помещен в каталог + sites-available + на хостах миньонов. Однако нам все еще нужно связать файл с каталогом + sites-enabled +, чтобы активировать его. Мы можем сделать это с помощью функции + file.symlink +. Нам просто нужно указать исходное местоположение файла как + target. Нам также необходимо «потребовать» этот файл, чтобы это состояние выполнялось только после успешного завершения предыдущего состояния:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-available/default:
 file.managed:
   - source: salt://nginx/files/etc/nginx/sites-available/default.jinja
   - template: jinja
   - user: root
   - group: root
   - mode: 640

Состояние содержимого сайта по умолчанию

У нас написаны состояния установки и настройки Nginx. Теперь нам просто нужно создать состояние для нашего файла + index.html, которое будет фактическим контентом для нашего сайта.

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

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-enabled/default:
 file.symlink:
   - target: /etc/nginx/sites-available/default
   - require:
     - file: /etc/nginx/sites-available/default

Когда вы закончите, сохраните и закройте этот файл. На данный момент мы закончили с информацией о состоянии Nginx.

Установите Nginx и перенесите оригинальные файлы в Salt Master

Мы создали наш основной файл состояния соли Nginx. Однако некоторые состояния, которые мы создали, ссылаются на файлы на файловом сервере мастера Salt, которые еще не существуют.

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

Если у вас еще не запущена одна из ваших сред, выберите один из файлов карты вашей среды для развертывания. В этой серии мы будем использовать среду «stage», потому что это самая маленькая среда, в которой есть все типы серверов, которые нам понадобятся.

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map

Как только ваши серверы будут запущены, выберите один из ваших веб-серверов для установки Nginx. Сейчас мы просто будем использовать исполняющий модуль + pkg +, поскольку наши состояния еще не полностью функциональны:

sudo salt stage-www1 pkg.install nginx

Когда мы настраивали нашу основную конфигурацию Salt, мы включили опцию + file_recv +. Это позволяет нам запрашивать миньонов для отправки определенных файлов обратно на мастер. Мы можем использовать это для получения версий файлов по умолчанию, которыми мы будем управлять:

sudo salt stage-www1 cp.push /etc/nginx/nginx.conf
sudo salt stage-www1 cp.push /etc/nginx/sites-available/default
sudo salt stage-www1 cp.push /usr/share/nginx/html/index.html

Эти файлы теперь должны быть доступны на мастере. Путь к этим файлам создается в каталоге + / var / cache / salt / master / minion // files`. В нашем случае идентификатор миньона будет + stage-www1 +. Мы можем скопировать каталоги под этим местоположением, которое представляет пути к файлам в миньоне, в наш каталог состояния соли, набрав:

sudo cp -r /var/cache/salt/master/minions/stage-www1/files /srv/salt/nginx

Если вы посмотрите на содержимое вашего каталога состояний, вы увидите новый каталог с именем «files». Под этим каталогом находятся соответствующие каталоги в файловой системе миньона и три файла, которые мы скопировали:

find /srv/salt/nginx -printf "%P\n"
Outputfiles
files/usr
files/usr/share
files/usr/share/nginx
files/usr/share/nginx/html
files/usr/share/nginx/html/index.html
files/etc
files/etc/nginx
files/etc/nginx/sites-available
files/etc/nginx/sites-available/default
files/etc/nginx/nginx.conf
init.sls

Здесь будут храниться все наши управляемые файлы. Это соответствует расположению «источника», которое мы установили в нашем файле состояния Nginx.

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

sudo salt-cloud -d stage-www1

Дождавшись обработки события, мы можем перестроить миньона.

Обычно мы используем для этого файл карты, но поскольку мы перестраиваем только один сервер, на самом деле предпочтительно использовать профиль + stage-web + напрямую. Затем мы можем использовать + cloud.profile + функцию выполнения Salt вместо + salt-cloud +, что позволяет нам добавлять флаг + - async +. По сути, это позволяет нам перестраивать наш сервер + stage-www1 + в фоновом режиме, пока мы продолжаем работать. Нам нужно настроить таргетинг на нашего Salt master в этой команде, поскольку это сервер с облачными профилями, которые нам нужны:

sudo salt --async  cloud.profile stage-web stage-www1

Пока наш узел + stage-www1 + перестраивается в фоновом режиме, мы можем продолжить.

Настройте файл /etc/nginx/nginx.conf

Давайте сначала посмотрим на основной файл конфигурации Nginx, который будет помещен в + / etc / nginx / nginx.conf + на наших миньонах. Мы можем найти этот путь в каталоге + files in без каталога состояния Nginx:

cd /srv/salt/nginx/files/etc/nginx

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

sudo cp nginx.conf nginx.conf.orig

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

diff nginx.conf nginx.conf.orig

В будущем, если мы обнаружим, что нам нужно настроить конфигурацию Nginx в наших различных средах (например, мы можем захотеть сопоставить + worker_processes + с числом процессоров на наших производственных серверах позже), мы можем захотеть перейти к используя файл шаблона. В данный момент нам это не нужно, поэтому, как файл без шаблона, наши изменения будут жестко запрограммированы.

Как мы уже говорили ранее, в настоящее время нам не нужны никакие модификации. Давайте двигаться дальше.

Сконфигурируйте шаблон / etc / nginx / sites-available / default

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

cd /srv/salt/nginx/files/etc/nginx/sites-available

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

sudo cp default default.orig

Затем мы можем переименовать файл, чтобы он имел расширение + .jinja +. Это наглядно напомнит нам, что этот файл является шаблоном, а не используемым файлом сам по себе:

sudo mv default default.jinja

Теперь мы можем открыть файл шаблона, чтобы внести некоторые изменения:

sudo nano default.jinja

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

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

Мы создадим переменную с именем + interface +, которая должна содержать интерфейс, адрес которого мы хотим. Мы проверим, установлена ​​ли среда minion на «dev», и в этом случае мы будем использовать интерфейс «+ eth0 ». В противном случае мы установим для него ` eth1 `, частный интерфейс сервера. Затем мы будем использовать функцию исполнительного модуля ` grains.get `, чтобы получить адрес, связанный с выбранным интерфейсом, и использовать его в качестве значения для переменной ` addr +`. Мы добавим это в самый верх файла:

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}
# You may add here your
# server {
#       ...
# }

. . .

Затем мы можем отредактировать блок + server + ниже в файле. Мы можем использовать переменную + addr +, которую мы установили сверху в директивах + listen + и + server_name +. Мы удалили IPv6 и части сервера по умолчанию, чтобы ограничить работу этого блока:

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}

. . .

server {
   listen :80;

   root /usr/share/nginx/html;
   index index.html index.htm;

   server_name ;

   location / {
       try_files $uri $uri/ =404;
   }
}

Сохраните и закройте файл, когда вы закончите.

Настройте /usr/share/nginx/html/index.html Шаблон

Теперь мы можем перейти к файлу + index.html. Перейдите в каталог на мастере соли, который содержит файл:

cd /srv/salt/nginx/files/usr/share/nginx/html

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

sudo cp index.html index.html.orig
sudo mv index.html index.html.jinja

Откройте файл шаблона, чтобы мы могли внести необходимые изменения:

sudo nano index.html.jinja

Вверху мы установим другую переменную, используя Jinja. Мы будем использовать функцию исполнительного модуля + grains.get +, чтобы получить имя хоста миньона. Мы будем хранить это в переменной + host +:

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>

. . .

Затем мы будем использовать это значение во всем файле, чтобы мы могли легко определить, какой веб-сервер обслуживает наши запросы. Сначала измените значение + <title> +:

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>
<head>
<title>Welcome </title>
. . .

Давайте изменим основной текст на это:

. . .

<body>
<h1>Welcome to nginx!</h1>




</body>
</html>

Сохраните и закройте файл, когда вы закончите.

Тестирование файла состояния Nginx

Теперь мы завершили нашу настройку Nginx. Мы можем проверить некоторые аспекты состояния, чтобы убедиться, что оно работает должным образом.

Во-первых, мы можем использовать функцию исполнительного модуля + state.show_sls +, чтобы посмотреть, как Salt будет интерпретировать наш файл состояния Nginx. Мы можем использовать наш сервер + stage-www1 + в качестве цели. На этом этапе на сервере ничего не будет выполняться:

sudo salt stage-www1 state.show_sls nginx

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

Outputstage-www1:
   ----------
   /etc/nginx/nginx.conf:
       ----------
       __env__:
           base
       __sls__:
           nginx
       file:
           |_
             ----------
             source:
                 salt://nginx/files/etc/nginx/nginx.conf
           |_
             ----------
             user:
                 root
           |_
             ----------
             group:
                 root
           |_
             ----------
             mode:
                 640
           - managed
           |_
             ----------
             order:
                 10002

. . .

Он в основном отображает информацию из нашего файла + / srv / salt / nginx / init.sls + с некоторыми интересными дополнениями. Убедитесь, что нет ошибок интерпретации, когда Солт не знал, как читать команды. «Заказ» каждой части - еще один хороший элемент для проверки. Это определяет, когда будет выполняться каждое из отдельных состояний в файле. Первое состояние будет иметь номер заказа «10000». Каждое дополнительное состояние будет отсчитываться оттуда. Обратите внимание, что + env + отличается от + env +, который мы устанавливаем с помощью зерен. Мы не используем концепцию среды Salt в этом руководстве.

Далее мы можем выполнить пробный прогон применения нашего файла состояния. Мы можем сделать это с помощью функции + state.apply + с опцией + test = True +. Команда выглядит так:

sudo salt stage-www1 state.apply nginx test=True

Это покажет вам изменения, которые будут сделаны, если опция + test = True + будет удалена. Посмотрите, чтобы убедиться, что изменения имеют смысл и что Salt может правильно интерпретировать все ваши файлы. Поле «Комментарий» особенно важно, поскольку оно может выявить проблемы даже в тех случаях, когда Солт не помечает состояние как несостоявшееся.

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

sudo salt -G 'role:webserver' state.apply nginx

Если вы применили состояние Nginx к промежуточным или рабочим веб-серверам, вы захотите получить их внутренние IP-адреса. Страницы не будут доступны через открытый интерфейс:

sudo salt-call mine.get 'role:webserver' internal_ip expr_form=grain
Outputlocal:
   ----------
   stage-www1:

   stage-www2:

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

sudo salt-call mine.get 'role:webserver' external_ip expr_form=grain

Вы можете проверить свои серверы используя + curl:

curl

Вы должны увидеть страницу + index.html, которую мы изменили:

Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from </title>
<style>
   body {
       width: 35em;
       margin: 0 auto;
       font-family: Tahoma, Verdana, Arial, sans-serif;
   }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hello!  This is being served from:</p>

<h2></h2>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Как вы можете видеть, имя хоста миньона было помещено в файл при рендеринге Jinja. Наше состояние Nginx завершено.

Заключение

Теперь у вас должно быть полностью функциональное состояние Nginx. Это позволит вам быстро и легко превратить любую машину, контролируемую Salt, в веб-сервер с вашими спецификациями. Мы будем использовать это как часть нашей более широкой стратегии управления инфраструктурой, чтобы легко создавать веб-серверы в наших средах.

В next Гид мы будем двигаться вперед и создадим состояние для балансировщиков нагрузки это будет направлять трафик перед нашими веб-серверами. Мы будем использовать некоторые из тех методов, которые мы использовали в этом руководстве, чтобы сделать наши балансировщики нагрузки гибкими.

Related