Зачем запускать сервисы в контейнере?

Контейнеризация ― это актуальный тренд на протяжении вот уже многих лет (первая версия Docker вышла в 2013 году).  Самое главное преимущество контейнеров заключается в сведении к минимуму возни с установкой и запуском. Все проблемы с зависимости снимаются раз и навсегда. В контейнере мы получаем готовое приложение, которое достаточно просто загрузить на хост и запустить. Собственно, контейнеризованное приложение не будет установлено в систему в буквальном смысле слова: оно будет запущено в изолированном окружении и может быть в любой момент убрано из системы.

Зачем управлять контейнерами через графический интерфейс?

Вопрос, вынесенный в название параграфа, может возникнуть у многих читателей: управлять Docker-контейнерами через командную строку несложно; в свободном доступе опубликованы тысячи, если не сотни тысяч, руководств и обучающих материалов. Тем не менее, за 8 лет существования Docker было создано немало решений для работы с контейнерами через веб-интерфейс.  Какие преимущества даёт веб-интерфейс?

Первое преимущество ― это наглядность. Пользователь может видеть, какие приложения работают в контейнерах и как контейнеры взаимосвязаны между собой. Это актуально, например, для больших (десятки и сотни контейнеров) инсталляций Docker.

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

Третье преимущество заключается в упрощении многих операций, что полезно как для начинающих, так и для опытных (особенно при работе с большими инсталляциями) пользователей. Управлять через GUI сетями, томами, образами значительно проще, чем через командную строку.

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

Как это сделано в Roxy-WI

В Roxy-WI мы стремились сделать работу с контейнерами максимально простой и удобной: по сути управление сервисом в контейнере не должно ничем отличаться от управлением тем же сервисом в неконтейнеризованном виде.

Для экземпляров сервисов, работающих в контейнерах, у нас предусмотрена визуализация: на странице HAProxy => Overview (или Nginx => Overview) они помечены значком “коробки”, то есть контейнер. Для них доступны те же функции, что и для всех обычных сервисов.

Начиная с текущей версии (5.3.0)  могут установить HAProxy и Nginx в контейнерах непосредственно через Roxy-WI. Всё очень просто: идём на страницу Servers page и нажимаем на кнопку Proxy installation.  В открывшемся окне выбираем чекбокс Install as a Docker container. После этого всё, начнётся установка.

По умолчанию контейнеры получают имена haproxy и nginx.  Если эти имена требуется изменить, нужно перейти на страницу Settings и отредактировать значения параметров haproxy_container_name и/или nginx_container_name. 

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

Заключение

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

https://roxy-wi.org  - официальный сайт и документация проекта;

https://github.com/hap-wi/roxy-wi - репозиторий проекта (можно не только высказывать своё мнение, но и присылать пулл-реквесты);

https://t.me/haproxy_wi  - наш телеграм-канал; подписывайтесь и будьте в курсе всех новостей.

Саурон приказал своему орккомнадзору фильтровать эти запросы, записывать их и, в некоторых случаях, подменять. То есть Саурон не видит, что хоббит делал на сайте, ведь там протокол HTTPS, но вот какие сайты хоббит запрашивал — он видит. А если хоббит захотел открыть эльфийский сайт, то можно в DNS запросе подменить ответ и хоббит вместо эльфийского сайта увидит злобную картинку от орккомнадзора. Или просто обвинить хоббита в сочувствии и поддержке эльфов, признать его эльфоагентом. Тогда мудрые эльфы придумали протокол DNS-over-HTTPS (сокращенно DOH). Это когда DNS-сервер прикидывается обычным веб-сервером, работающим по протоколу HTTPS, и интернет-браузер хоббита запрашивает у этого сервера IP-адреса сайтов по зашифрованному протоколу.

Саурон сначала приуныл, но потом до него дошло, что DNS сервера эльфов, поддерживающие протокол DOH, это те же сервера, что и работающие по обычному DNS протоколу. Да и серверов таких совсем не много. Тогда Саурон приказал своим оркам блокировать любые запросы хоббитов к известным серверам, поддерживающим DOH. Это заставит хоббита пользоваться мордорскими DNS серверами и можно и дальше фильтровать/записывать/подменять его запросы. Что ж делать хоббиту? Ну, например, использовать личный VPN, как написано в начале статьи. Но у хоббита есть потребность обойтись без VPN. Хоббит хитрый и он подумал: обращения к серверу DOH всё равно выглядят как обычный HTTPS, выдаёт их в основном только то, что они идут к известным Саурону DNS-серверам. Что если сделать свой web-сервер, такой же, как тысячи других, работающий по HTTPS, но при этом способный выступать посредником между хоббитом и публичным DNS-сервером. Т.е. сервер хоббита будет принимать зашифрованные DNS запросы, пересылать их публичному эльфийскому DNS-серверу, принимать ответы, зашифровывать и отправлять обратно хоббиту. Получится реверс-прокси сервер для DOH. Расположить его конечно нужно там, куда не дотянуться беспредельничающие орки.

Для Саурона это будет выглядеть так, как будто хоббит ходит на очередной web-сайт. Конечно, если он начнёт вглядываться очень пристально в конкретного хоббита, то через некоторое время поймет что к чему. Но хобиттов в Мордоре миллионы и Саурон предпочитает бить по площадям. Кроме того DOH реверс-прокси лишит Саурона списка эльфийских сайтов, которые запрашивал хоббит. А это может помочь хоббиту в его не простой жизни.

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

Ниже будут конфиги. Их форматирование будет безбожно убито. Они всё равно останутся рабочими, но будут некрасивенькими. Конфиги в нормальном виде можно найти в оригинале статьи.

Для начала хоббиту нужно заблаговременно озаботится арендой доменного имени. Как это сделать примерно описано в начале этой статьи. Предположим хоббит арендовал доменное имя theshire.ru. В принципе он мог его и использовать для реверс-прокси. Но можно добавить имя третьего уровня. Тогда сам домен можно будет потом использовать для чего-то ещё. Так больше гибкости. Хоббит решил сделать имя третьего уровня ns1.theshire.ru. У него получились такие записи домена:

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

Как видно, на сервере установлена операционная система CentOS 7. Далее нужно настроить защищённый вход на сервер, как описано здесь, и файрволл сервера, как описано здесь. Только при настройке файрволла нужно в ipt-set записать другое содержимое:

#!/bin/sh

IF_EXT="venet0"

IPT="/sbin/iptables"

IPT6="/sbin/ip6tables"

# flush

$IPT --flush

$IPT -t nat --flush

$IPT -t mangle --flush

$IPT -X

$IPT6 --flush

# loopback

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

# default

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

$IPT -P FORWARD DROP

$IPT6 -P INPUT DROP

$IPT6 -P OUTPUT DROP

$IPT6 -P FORWARD DROP

# allow forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

# NAT

# #########################################

# SNAT - local users to out internet

$IPT -t nat -A POSTROUTING -o $IF_EXT -j MASQUERADE

# INPUT chain

# #########################################

$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ssh

$IPT -A INPUT -i $IF_EXT -p tcp --dport 22 -j ACCEPT

# nginx

$IPT -A INPUT -i $IF_EXT -p udp --dport 53 -j ACCEPT

$IPT -A INPUT -i $IF_EXT -p tcp --dport 80 -j ACCEPT

$IPT -A INPUT -i $IF_EXT -p tcp --dport 443 -j ACCEPT

$IPT -A INPUT -i $IF_EXT -p tcp --dport 853 -j ACCEPT

# OUTPUT chain

# #########################################

$IPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Не забудьте про правильное имя внешнего интерфейса в переменной IF_EXT (вторая строчка), как описано в этой статье.

Обновим сервер и установим необходимые утилиты:

yum -y update

yum -y install net-tools wget

Проверим, не сидит ли какая-то дефолтная http служба на нужном нам 80-ом порту:

netstat -tulnp | grep 80

Сидит, собака

Убиваем её

systemctl stop httpd

systemctl disable httpd

yum -y remove httpd

Теперь сервер готов. Реверс-прокси сделаем конечно же на nginx. Ранее уже была статья про использование его в такой роли. Ретранслировать DOH запросы не на столько простая задача, как кажется. Дабы не изобретать велосипед, используем уже готовый проект NGINX-DNS. Благодаря скриптам этого проекта мы не только сделает DOH между хоббитом и его реверс прокси, но и обмен по протоколу DOT между реверс-прокси и публичным DNS. Т.е даже хостинг VPS не сможет заглянуть в трафик хоббита! Кстати, для этого проекта подойдёт не каждый nginx. Тот, который в epel-release, НЕ подойдёт. Поэтому epel-release ни в коем случае не устанавливаем, он всё поломает. Накатим репозиторий с правильным nginx:

cd /tmp

wget http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release...

rpm -ivh nginx-release-centos-7-0.el7.ngx.noarch.rpm

Проверим, что операционная система теперь знает, где брать nginx и модули к нему:

yum list | grep nginx

Отлично. Устанавливаем nginx и нужный модуль:

yum -y install nginx.x86_64 nginx-module-njs.x86_64

Еще раз проверьте, что файрволл настроен и открытые порты выглядят так:

iptables -L -n

Теперь любым удобным способом откроем для редактирования файл /etc/nginx/conf.d/default.conf (хоббитам с лапаками рекомендую использовать WinSCP и Notepad++). В этом файле сразу после строчки

server {

нужно найти строчку

server_name localhost;

и вместо localhost вписать своё доменное имя. У хоббита это так (не удалите случайно точку с запятой!):

server_name ns1.theshire.ru;

Файл можно сохранить и закрыть. Запускаем nginx и смотрим, что всё в порядке:

systemctl start nginx

systemctl status nginx

Дальше в браузере на компьютере переходим по доменному адресу сервера. У хоббита это http://ns1.theshire.ru

Оно живое! Но только по протоколу HTTP, а нам надо по HTTPS. Для этого нужно сделать SSL сертификаты от letsencryp. Сертификаты весь прогрессивный эльфийский мир делает с помощью Certbot. Поскольку epel-release мы не используем, то ставить certbot хоббиту придётся через жопу Pip.

Накатим питона с либами:

yum -y install python3 augeas-libs

и подготовим виртуальную среду:

python3 -m venv /opt/certbot/

/opt/certbot/bin/pip install --upgrade pip

Отлично. Можно и накатить сам certbot:

/opt/certbot/bin/pip install certbot certbot-nginx

ln -s /opt/certbot/bin/certbot /usr/bin/certbot

Теперь сделаем сертификаты:

certbot --nginx

Соглашаемся с условиями использования, указываем почту (желательно настоящую, туда, если что, будут спамить о проблемах с сертификатами) и отказываемся от спама. На запрос доменного имени нужно выбрать своё. У хоббита получилось так:

Если на этом этапе не удаётся создать сертификаты, появляются ошибки, то:

--  ещё раз проверить настройки файрволла и доступность страницы приветствия по (у хоббита это http://ns1.theshire.ru);

--  возможно домен арендован и/или его записи внесены менее 24 часов назад и не все DNS серверы успели их синхронизировать. Тогда придётся подождать.

Современный certbot настолько преисполненный, что он сам вписал настройки HTTPS в nginx и сам применил их. Хоббитам остаётся только открыть свой доменный адрес по HTTPS:

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

echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | tee -a /var/spool/cron/root > /dev/null

и проверяем результат:

crontab -l

Теперь превратим наш безобидный nginx в боевой DOH сервер. Для начала остановим его:

systemctl stop nginx

Теперь из проекта NGINX-DNS с гитхаба скопируем нужные нам файлы и засунем в папку nginx. При этом старые конфиги nginx удалять не будем, а просто добавим к имени приставку .old:

cd /tmp

wget https://github.com/TuxInvader/nginx-dns/archive/refs/heads/m...

unzip master.zip

cp -r nginx-dns-master/njs.d /etc/nginx/

cd /etc/nginx/

mv nginx.conf nginx.conf.old

mv ./conf.d/default.conf default.conf.old

В папке /etc/nginx/ создадим файл nginx.conf с вот таким содержимым:

user nginx;

worker_processes auto;

load_module modules/ngx_stream_js_module.so;

error_log /var/log/nginx/error.log error;

#error_log off;

pid /var/run/nginx.pid;

events {

worker_connections 1024;

}

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

# logging directives

log_format doh '$remote_addr - $remote_user [$time_local] "$request" '

'[ $msec, $request_time, $upstream_response_time $pipe ] '

'$status $body_bytes_sent "$http_x_forwarded_for" '

'$upstream_http_x_dns_question $upstream_http_x_dns_type '

'$upstream_http_x_dns_result '

'$upstream_http_x_dns_ttl $upstream_http_x_dns_answers '

'$upstream_cache_status';

access_log /var/log/nginx/doh-access.log doh;

#access_log off;

resolver 1.1.1.1 valid=10s;

# This upstream connects to a local Stream service which converts HTTP -> DNS

upstream dohloop {

zone dohloop 64k;

server 127.0.0.1:8053;

keepalive_timeout 60s;

keepalive_requests 100;

keepalive 10;

}

# Proxy Cache storage - so we can cache the DoH response from the upstream

proxy_cache_path /var/cache/nginx/doh_cache levels=1:2 keys_zone=doh_cache:10m;

# The DoH server block

server {

server_name ns1.theshire.ru;

root /usr/share/nginx/html;

# Listen on standard HTTPS port, and accept HTTP2, with SSL termination

listen 443 ssl http2 default_server;

ssl_certificate /etc/letsencrypt/live/ns1.theshire.ru/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/ns1.theshire.ru/privkey.pem; # managed by Certbot

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

ssl_session_cache shared:ssl_cache:10m;

ssl_session_timeout 10m;

# DoH may use GET or POST requests, Cache both

proxy_cache_methods GET POST;

# Return 404 to all responses, except for those using our published DoH URI

location / {

return 404 "404 Not Found\n";

}

# This is our published DoH URI

location /dns-query {

# Proxy HTTP/1.1, clear the connection header to enable Keep-Alive

proxy_http_version 1.1;

proxy_set_header Connection "";

# Enable Cache, and set the cache_key to include the request_body

proxy_cache doh_cache;

proxy_cache_key $scheme$proxy_host$uri$is_args$args$request_body;

# proxy pass to the dohloop upstream

proxy_pass http://dohloop;

}

}

server {

if ($host = ns1.theshire.ru) {

return 301 https://$host$request_uri;

} # managed by Certbot

listen 80;

listen [::]:80;

server_name ns1.theshire.ru;

return 404; # managed by Certbot

}

}

# DNS Stream Services

stream {

# DNS logging

log_format dns '$remote_addr [$time_local] $protocol "$dns_qname"';

access_log /var/log/nginx/dns-access.log dns;

#access_log off;

# Include the NJS module

js_include /etc/nginx/njs.d/nginx_stream.js;

# The $dns_qname variable can be populated by preread calls, and can be used for DNS routing

js_set $dns_qname dns_get_qname;

#DNS upstream pool.

upstream dns {

zone dns 64k;

server 1.1.1.1:53;

}

# DNS over TLS upstream pool

upstream dot {

zone dot 64k;

server 1.1.1.1:853;

}

# DNS(TCP) and DNS over TLS (DoT) Server

# Upstream can be either DNS(TCP) or DoT. If upstream is DNS, proxy_ssl should be off.

server {

# DNS TCP

listen 53;

# DNS DoT

listen 853 ssl;

ssl_certificate /etc/letsencrypt/live/ns1.theshire.ru/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/ns1.theshire.ru/privkey.pem; # managed by Certbot

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

# This is used to pull out question for logging

js_preread dns_preread_dns_request;

# Enable SSL re-encryption for DoT connection upstream

proxy_ssl on;

proxy_pass dot;

}

# DNS over HTTPS (gateway) Service

# Upstream can be either DNS(TCP) or DoT. If upstream is DNS, proxy_ssl should be off.

server {

listen 127.0.0.1:8053;

js_filter dns_filter_doh_request;

proxy_ssl on;

proxy_pass dot;

}

# DNS(UDP) Server

# DNS UDP proxy onto DNS UDP

server {

listen 53 udp;

proxy_responses 1;

js_preread dns_preread_dns_request;

proxy_pass dns;

}

}

Указанный выше конфиг сделан для нашего хоббита и его доменного имени ns1.theshire.ru. Чтобы переделать файл под другого хоббита и другое доменное имя:

Найти строчки, начинающиеся на «server_name», и заменить в них доменное имя ns1.theshire.ru на своё.

Найти строчки, начинающиеся на «ssl_certificate», и заменить в них путь на сертификат своим. Свой путь можно найти в аналогичных строчках файла /etc/nginx/default.conf.old

Сохраните и закройте файл. Выполните тест корректности конфига командой:

nginx -t

У хоббита хоть и лапки, но прямые. У него получилось с первого раза:

Если есть ошибки, то будут написаны номера строк с ними. Смотрим в эти строки и исправляем. Чаще всего хоббиты нечаяно удаляют «;» в конце строк.

Теперь nginx можно запустить и добавить в автозагрузку.

systemctl start nginx

systemctl enable nginx

Собственно всё. Хоббит сделал сервер который:

1. Может работать как обычный DNS сервер по порту 53/UDP. Если добавить его IP в настройки DNS, например, сетевой карты компьютера, то всё взлетит. Обратите внимание, что это не шифрованный обмен. Обычный DNS. Если этот функционал не нужен, то просто закомментируйте/удалите строку с портом 53 в файле /root/ipt-set и перезагрузите сервер.

2. Принимает запросы по протоколу DOH (по порту 443), расшифровывает их, разбирает, перенаправляет запросы на публичный DNS сервер по зашифрованному протоколу DOT, полученные ответы зашифровывает и отправляет хоббиту.

3. Принимает запросы по протоколу DOТ, расшифровывает их, разбирает, перенаправляет запросы на публичный DNS сервер по, опять же, протоколу DOT, полученные ответы зашифровывает и отправляет хоббиту. Протокол DOT на сегодня не особо распространён в браузерах. Если этот функционал не нужен, то просто закомментируйте/удалите строку с портом 853 в файле /root/ipt-set и перезагрузите сервер.

Хоббиту осталось настроить браузер.

В Mozilla Firefox нужно открыть Настройки -> Параметры сети -> Настроить, в самом низу поставить галочку «Включить DNS через HTTPS» и вписать свой DNS адрес. У нашего хоббита он такой:

https://ns1.theshire.ru/dns-query

Другим хоббитам вместо ns1.theshire.ru нужно вписать свой домен.

В Google Chrome открыть Настройки -> Конфиденциальность и безопасность -> Безопасность -> Использовать безопасный DNS-сервер вписать сервер также, как это указано выше для Firefox. У нашего хоббита это получилось так:

Для других браузеров хоббиту предлагается напрячь лапки и погуглить.

В качестве домашнего задания также предлагается нагуглить, как настроить Windows 10 для использования DOH. Необязательный пункт. Браузеры не зависят от этого и используют настройку, показанную выше.

Дальше хоббит пользуется браузером как обычно. Сайты должны без проблем открываться. Убедится, что сервер работает как надо, можно сходив в файл лога /var/log/nginx/doh-access.log. Там будут логгированы все DNS запросы хоббита по протоколу DOH.

Посмотрев логи умненький хоббит должен подумать, а нужны ли ему эти следы? Если нет, то он в файле /etc/nginx/nginx.conf:

-- находит строчку, начинающуюся на «error_log» и ставит в ее начале #. А вот из строчки «#error_log off;» наоборот символ # убирает.

-- находит строчки, начинающиеся на «access_log» и ставит в их начале #. Во всех строчках «#access_log off;» символ # убирает.

Дальше нужно сохранить файл. Остановить сервер командой:

systemctl stop nginx

удалить все файлы из папки /var/log/nginx/ и запустить сервер обратно:

systemctl start nginx

Теперь никаких следов.

За сим эта часть саги про хоббита заканчивается. Обсуждение в https://t.me/SecFAll_chat

Утаскивать в сообщества запрещаю.

С помощью Roxy-WI можно работать с конфигурационными файлами для трёх сервисов: HAProxy, Nginx и Keepalived. Через веб-интерфейс пользователи могут выполнять следующие операции:

1. редактировать конфигурационные файлы;

2. визуализировать структуру сети;

3. сравнивать текущую версию конфигурационного файла с предыдущей;

4. сохранять все предыдущие версии конфигурационных файлов и откатываться на старую версию в случае необходимости;

Рассмотрим каждую из этих функций подробнее.

Зачем вообще редактировать конфигурационные файлы через веб-интерфейс?

Такой вопрос может возникнуть у многих читателей. Действительно, многие из нас привыкли работать с конфигурационными файлами в текстовом редакторе, и никаких сложностей в этом на первый взгляд нет. Но есть нюансы. Начнём с того, что конфигурационный файл может иметь очень сложную структуру. Сориентироваться в нём бывает сложно, особенно начинающему пользователю. В графическом интерфейсе Roxy-WI всё просто и наглядно. Возьмём в качестве примера конфигурационный файл для HAProxy. Итак, выбираем в главном меню HAProxy => Configs, в выпадающем меню выбираем нужный сервер и нажимаем на кнопку Open. После этого видим такую картину (приводим небольшой фрагмент конфига, секции global и defaults):

Всё вполне понятно; если кликнуть по ссылке Edit, откроется форма для редактирования:

После внесения изменений можно нажать на кнопку Check config и проверить конфигурационный файл на наличие синтаксических ошибок.

Для начинающего пользователя HAProxy (а также Nginx и Keepalived) на таком интерфейсе очень хорошо учиться. Опытному пользователю графический интерфейс поможет не запутаться в сложных конфигах и тем самым снизить вероятность ошибок из-за человеческого фактора.

Ещё Roxy-WI может существенно упростить жизнь, если серверов много: все конфиги можно редактировать в одном месте. Если вы изменили конфиг на master-сервере и применили одно из указанных на кнопках со скриншота выше действий, аналогичные изменения произойдут и на slave-сервере.

Визуализация

Просто читая конфигурационный файл HAProxy, не всегда можно сразу представить, а как именно всё устроено. Именно для этого в Roxy-WI предусмотрена функция визуализации. Выбираем нужный сервер, нажимаем на кнопку Map и видим:

Такая возможность очень полезна для всех, кто только учится работать с HAProxy.

Кроме того, она может очень пригодится в ситуации, когда нужно что-то наглядно объяснить коллегам, которые с HAProxy вообще дела не имели или имели, но очень мало (менеджерам, тестировщикам. техническим писателям и многим другим — здесь возможны варианты).

Работа с версиями

Представьте себе такую гипотетическую ситуацию: вы что-то изменили в конфиге, и нужный вам сервис (тот же HAProxy или Nginx) не запускается. Для таких случаев в Roxy-WI предусмотрена возможность сравнения конфигурационных файлов.

Выбираем нужные версии, нажимаем на кнопку Compare — и на видим diff двух конфигов. Выглядит он так же, как дифф файлов на GitHub:

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

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

Набор функций по работе с версиями мы планируем расширять. В Roxy-WI серверы могут получать статус protected. Для этих серверов мы планируем сделать следующее:, полноценное редактирование будет доступно только администраторам, а остальные пользователи смогут только предагать изменения. После проверки админом эти изменения могут быть или приняты, или отклонены — принцип такой же, как при работе с мердж-реквестами на GitHub.

Заключение

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

https://roxy-wi.org/ - официальный сайт проекта (здесь же документация);

https://github.com/hap-wi/roxy-wi - официальный репозиторий проекта.

Любые пожелания по улучшению работы с конфигурами приветствуются - добро пожаловать в комментарии.

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

В комментариях к предыдущему посту мне несколько раз говорили что использование bash скриптов для установки сервисов — это стреляние себе в ногу. Я с ними согласен и по этому 95% всех установок сейчас проходят через Ansible. Действительно удобно, да к тому же надежнее. Одни плюсы вокруг!

Как можно не изобрести велосипед в велосипеде? Ребенок велосипеда, так сказать… Маленький такой велосепедик, трех колесный пожалуй: возможность простого мониторинга портов на предмет доступности порта, ответа HTTP и проверка ответа по ключевому слову. Да, не много функций, но зато ставить и админить легко :)

Очень крутая работа с HAProxy RunTime API. Почему очень крутая? Такая есть только у нас и… пожалуй все. Конечно звучит немного претенциозно, но мне правда нравится как это работает. Как например выглядит работа со многими любимыми и ненавидимыми в тоже время stick-table:

А с версии 5.0.0.0 можно развернуть сервера в AWS и в DigitalOcean!

Т.к. для этого используется Terraform, то сервер можно редактировать и даже удалить!

А ну и сайт стал значительно красивей, на нем появились "Хоутушки" и более детально описаны разделы.