Вступление
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 был запущен и работал как наш бэкэнд система баз данных. Это будет использоваться для хранения данных приложения в наших различных средах.