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

Вступление

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

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

Давайте начнем.

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

Наши балансировщики нагрузки будут использовать HAProxy для распределения трафика для нашего приложения между всеми доступными веб-серверами в среде. Как и в случае с файлом состояния Nginx, мы создадим каталог для этого состояния в каталоге + / srv / salt +:

sudo mkdir /srv/salt/haproxy

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

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

Внутри мы можем использовать тот же шаблон, который мы использовали для Nginx, чтобы установить пакет + haproxy + и убедиться, что он работает. Мы позаботимся о том, чтобы служба была перезагружена при наличии изменений в пакете или в файле «+ / etc / default / haproxy » или в файле « / etc / haproxy / haproxy.cfg +». Опять же, будьте очень осторожны с пробелами, чтобы избежать ошибок YAML:

/srv/salt/haproxy/init.sls

haproxy:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: haproxy
     - file: /etc/haproxy/haproxy.cfg
     - file: /etc/default/haproxy

Нам нужно управлять обоими файлами, которые отслеживает сервис + haproxy +. Мы можем создавать состояния для каждого.

Файл + / etc / haproxy / haproxy.cfg + будет шаблоном. Этот файл должен будет извлекать информацию об окружающей среде, чтобы заполнить список веб-серверов для передачи трафика. Наши веб-серверы не будут иметь одинаковые IP-адреса каждый раз, когда они создаются. Нам нужно будет динамически создавать список каждый раз, когда это состояние применяется.

Файл + / etc / default / haproxy + - это обычный файл. Мы управляем этим, потому что хотим убедиться, что HAProxy запускается при загрузке. Это не динамическая информация, поэтому нам не нужно делать этот шаблон:

/srv/salt/haproxy/init.sls

haproxy:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: haproxy
     - file: /etc/haproxy/haproxy.cfg
     - file: /etc/default/haproxy

Это фактически все, что нам нужно для самого файла состояния. Сохраните и закройте файл, когда вы закончите.

Установите HAProxy и перенесите файлы пакета в Salt Master

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

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

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

Когда ваши серверы станут доступны, вы можете установить пакет + haproxy + на сервер + stage-lb +, набрав:

sudo salt stage-lb pkg.install haproxy

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

sudo salt stage-lb cp.push /etc/default/haproxy
sudo salt stage-lb cp.push /etc/haproxy/haproxy.cfg

Соответствующие части файловой системы minion будут воссозданы в каталоге + / var / cache / salt / master / minions // files +. В этом случае идентификатор миньона равен + stage-lb +. Скопируйте всю структуру файла minion в наш каталог состояний HAProxy:

sudo cp -r /var/cache/salt/master/minions/stage-lb/files /srv/salt/haproxy

Мы можем увидеть структуру файла, набрав:

find /srv/salt/haproxy -printf "%P\n"
Outputfiles
files/etc
files/etc/default
files/etc/default/haproxy
files/etc/haproxy
files/etc/haproxy/haproxy.cfg
init.sls

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

sudo salt-cloud -d stage-lb

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

sudo salt --async  cloud.profile stage-lb stage-lb

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

Настройте файл / etc / default / haproxy

Мы можем начать с файла + / etc / default / haproxy +. В нашем каталоге состояний HAProxy на мастер-уровне Salt перейдите в каталог, в котором находится файл по умолчанию:

cd /srv/salt/haproxy/files/etc/default

Скопируйте файл в + haproxy.orig +, чтобы мы могли сохранить файл так, как он был изначально упакован:

sudo cp haproxy haproxy.orig

Теперь откройте файл для редактирования:

sudo nano haproxy

Измените + ENABLED + на «1». Это скажет системе инициализации Ubuntu, Upstart, запустить службу HAProxy при загрузке сервера:

/ SRV / соль / HAProxy / файлы / и т.д. / по умолчанию / HAProxy

# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

Это единственное изменение, которое нам нужно сделать. Сохраните и закройте файл.

Настройте файл шаблона /etc/haproxy/haproxy.cfg

Теперь давайте поработаем с основным файлом конфигурации HAProxy. Переместитесь в соответствующий каталог на главном сервере Salt:

cd /srv/salt/haproxy/files/etc/haproxy

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

sudo cp haproxy.cfg haproxy.cfg.orig

Затем переименуйте файл, чтобы отразить, что это файл шаблона Jinja:

sudo mv haproxy.cfg haproxy.cfg.jinja

Откройте файл шаблона в вашем текстовом редакторе:

sudo nano haproxy.cfg.jinja

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

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

global
       log /dev/log    local0
       log /dev/log    local1 notice
       chroot /var/lib/haproxy
       . . .

Перейдите к разделу «по умолчанию» файла. Нам нужно изменить + mode на« tcp », а первый« + option »на« tcplog »:

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

. . .

defaults
   . . .
   mode
   option
   . . .

В нижней части файла нам нужно создать нашу фактическую конфигурацию. Нам нужно создать раздел «frontend», в котором будет описано, как HAProxy будет принимать соединения. Мы будем обозначать этот раздел как «www».

Мы хотим связать это с публичным IP-адресом сервера. Мы можем получить это используя функцию исполнительного модуля + network.interface_ip + с аргументом + eth0 +. Веб-запросы будут поступать через порт 80. Мы можем указать бэкэнд по умолчанию для передачи с помощью опции + default_backend +. Мы будем называть наш бэкэнд + nginx_pool +:

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

. . .

frontend www
   bind {{ salt['network.interface_ip']('eth0') }}:80
   default_backend nginx_pool

Далее нам нужно добавить бэкэнд + nginx_pool +. Мы будем использовать обычную модель балансировки по кругу и снова установим режим «tcp».

После этого нам нужно заполнить список серверных веб-серверов из нашей среды. Мы можем сделать это с помощью цикла for в Jinja. Мы можем использовать функцию исполняющего модуля + mine.get +, чтобы получить значение моей функции + internal_ip +. Мы будем соответствовать роли веб-сервера и окружающей среды. + ~ Env + объединит значение переменной + env +, которую мы установили ранее, в строку соответствия, которая предшествует ему.

Результаты этого поиска будут храниться в переменных + server + и + addr + для каждой итерации цикла. В цикле мы добавим детали сервера, используя эти переменные цикла. Конечный результат выглядит так:

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

. . .

frontend www
   bind {{ salt['network.interface_ip']('eth0') }}:80
   default_backend nginx_pool

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

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

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

Во-первых, давайте используем + state.show_sls + для отображения порядка файлов:

sudo salt stage-lb state.show_sls haproxy

Мы можем определить последовательность в различных значениях «порядка» в выходных данных, что пакет будет установлен, служба будет запущена, а затем будут применены два файла. Это то, что мы ожидали. Изменения файла приведут к перезагрузке службы из-за настройки «watch», которую мы настроили.

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

sudo salt stage-lb state.apply haproxy test=True

Проверьте, что все состояния прошли бы. Независимо от количества ошибок в нижней части или на выходе, прокрутите вверх и посмотрите строку «Комментарий» для каждого из состояний. Иногда это будет включать дополнительную информацию о потенциальных проблемах, даже если тест был помечен как успешный.

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

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map
sudo salt -G 'role:webserver' state.apply nginx

Когда ваши веб-серверы работают, примените состояние + haproxy +:

sudo salt -G 'role:lbserver' state.apply haproxy

Теперь вы сможете получить доступ к одному из двух ваших внутренних веб-серверов по общедоступному IP-адресу вашего балансировщика нагрузки. Вы можете отобразить публичный IP-адрес своего балансировщика нагрузки с помощью этой команды:

sudo salt -G 'role:lbserver' network.interface_ip eth0

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

изображение: https: //assets.digitalocean.com/articles/saltstack_haproxy/example_page.png [страница балансировки нагрузки]

Проще увидеть, как балансировщик нагрузки передает трафик между внутренними серверами с помощью + curl +:

curl
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>

</body>
</html>

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

curl
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>

</body>
</html>

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

Заключение

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

В next[ мы сосредоточимся на том, чтобы MySQL был запущен и работал как наш бэкэнд система баз данных. Это будет использоваться для хранения данных приложения в наших различных средах.

Related