Развертывание на Google Cloud Platform¶

Развертывание ноды Вебмониторэкс на Google Cloud Platform (GCP) включает в себя следующие шаги:

1. Вход в учетную запись Google Cloud Platform.

2. Запуск инстанса с нодой Вебмониторэкс.

3. Настройка инстанса с нодой.

4. Подключение по SSH к инстансу с нодой.

5. Подключение ноды к Вычислительному кластеру Вебмониторэкс.

6. Настройка ноды для использования прокси‑сервера.

7. Настройка правил проксирования и фильтрации.

8. Настройка выделения оперативной памяти для ноды.

9. Настройка логирования.

10. Перезапуск NGINX.

1. Вход в учетную запись Google Cloud Platform¶

Войдите в console.cloud.google.com.

2. Запуск инстанса с нодой Вебмониторэкс¶

apt list wallarm-node

Запуск через интерфейс Google Cloud Platform¶

Чтобы запустить инстанс с нодой Вебмониторэкс через интерфейс Google Cloud Platform, откройте образ ноды и нажмите LAUNCH.

Инстанс запустится с предустановленной нодой. Более подробная информация о запуске инстансов на Google Cloud Platform приведена в официальной документации Google Cloud Platform.

Запуск через Terraform или другой инструмент¶

При запуске инстанса с нодой Вебмониторэкс с помощью Terraform или другого инструмента вам может потребоваться указать название образа.

• Название образа имеет формат:

  wallarm-node-195710/wallarm-node-<IMAGE_VERSION>-build
  

• Чтобы запустить инстанс с нодой Вебмониторэкс версии 4.4, используйте название образа:

  wallarm-node-195710/wallarm-node-4-4-20221122-092419
  

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

1. Установить Google Cloud SDK.

2. Выполнить команду gcloud compute images list со следующими параметрами:

   gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-4-*'" --no-standard-images
   

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

   wallarm-node-195710/wallarm-node-4-4-20221122-092419
   

3. Настройка инстанса с нодой¶

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

1. Перейдите на страницу VM instances в разделе Compute Engine навигационного меню.

2. Нажмите на запущенный вами инстанс с нодой и нажмите на кнопку Edit.

3. Разрешите необходимые типы входящего трафика к ноде, установив требуемые галочки в пункте Firewalls.

4. При необходимости вы можете запретить подключение к инстансу с использованием SSH-ключей проекта и задействовать собственную пару SSH-ключей для подключения к этому инстансу. Для этого выполните следующие действия:

   1. Поставьте галочку Block project-wide в пункте SSH Keys.

   2. Нажмите на кнопку Show and edit в пункте SSH Keys, чтобы развернуть поле для ввода SSH-ключа.

   3. Сгенерируйте пару из открытого и закрытого SSH-ключей. Например, вы можете использовать утилиты ssh-keygen или PuTTYgen;

      

   4. Скопируйте открытый ключ в формате OpenSSH из интерфейса используемой утилиты для генерации SSH-ключей (в этом примере с генерацией ключей в PuTTYgen необходимо скопировать открытый ключ из поля Public key for pasting into OpenSSH authorized_keys file) и вставьте его в поле, содержащее подсказку Enter entire key data.

   5. Сохраните закрытый ключ. В будущем он будет необходим для подключения к настроенному инстансу.

5. Нажмите на кнопку Save внизу страницы, чтобы сохранить внесенные изменения.

4. Подключение по SSH к инстансу с нодой¶

Информация о способах подключения к инстансам доступна по ссылке Google Cloud Platform: Connecting to Instances.

5. Подключение ноды к Вычислительному кластеру Вебмониторэкс¶

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

1. Убедитесь, что роль вашего пользователя в Консоли управления Вебмониторэкс — Администратор.

   Для этого перейдите к списку пользователей в Консоли управления и проверьте столбец Роль:

   

2. Перейдите в Консоль управления → Ноды и создайте ноду.

   

3. Скопируйте сгенерированный токен.

4. В системе с установленной нодой запустите скрипт register-node:

   sudo /usr/share/wallarm-common/register-node -t <WALLARM_API_TOKEN> -H api.wallarm.ru
   

   Где <WALLARM_API_TOKEN> — скопированный токен.

6. Настройка ноды для использования прокси‑сервера¶

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

Добавьте в файл /etc/environment новые значения переменных окружения:

• https_proxy — прокси для протокола HTTPS

• http_proxy — прокси для протокола HTTP

• no_proxy — ресурсы, для запросов к которым необходимо отключить проксирование

Присвойте переменным https_proxy и http_proxy строки вида <scheme>://<proxy_user>:<proxy_pass>@<host>:<port>, где:

• <scheme> — используемый протокол (должен совпадать с протоколом, для которого настраивается прокси в текущей переменной окружения)

• <proxy_user> — имя пользователя для авторизации на прокси‑сервере

• <proxy_pass> — пароль для авторизации на прокси‑сервере

• <host> — хост используемого прокси‑сервера

• <port> — порт используемого прокси‑сервера

Присвойте переменной no_proxy значение в виде массива IP‑адресов и/или доменов, к которым нужно обращаться без использования прокси: "<res_1>, <res_2>, <res_3>, <res_4>, ...", где <res_1>, <res_2>, <res_3> и <res_4> — IP‑адреса и/или домены.

Пример корректного содержимого файла /etc/environment ниже демонстрирует следующую конфигурацию:

• HTTPS‑ и HTTP‑запросы проксируются на хост 1.2.3.4 с портом 1234, используя для авторизации на прокси‑сервере имя пользователя admin и пароль 01234.

• Для запросов к 127.0.0.1, 127.0.0.8, 127.0.0.9 и localhost проксирование отключено.

https_proxy=http://admin:01234@1.2.3.4:1234
http_proxy=http://admin:01234@1.2.3.4:1234
no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost"

7. Настройка правил проксирования и фильтрации¶

Для обработки HTTP‑запросов Вебмониторэкс использует веб‑ и прокси‑сервер NGINX с дополнительными модулями анализа трафика.

Для настройки правил проксирования и фильтрации необходимо отредактировать файлы конфигурации NGINX и ноды Вебмониторэкс:

• /etc/nginx/nginx.conf с настройками NGINX

• /etc/nginx/conf.d/wallarm.conf с глобальными настройками ноды Вебмониторэкс

• /etc/nginx/conf.d/wallarm-status.conf с настройками сервиса мониторинга ноды Вебмониторэкс

Вы можете создавать свои файлы конфигурации для настройки работы NGINX и Вебмониторэкс. Для каждой группы доменов, которые должны обрабатываться однотипно, принято создавать отдельный файл конфигурации, в котором присутствует блок server.

Подробную информацию о работе с конфигурационными файлами NGINX вы можете найти в официальной документации NGINX.

Логика работы ноды Вебмониторэкс настраивается при помощи директив Вебмониторэкс. Список доступных директив Вебмониторэкс доступен по ссылке.

Пример файла конфигурации

Предположим, что вам необходимо настроить сервер для работы по следующим принципам:

• Обработка HTTPS‑трафика не настроена

• Запросы осуществляются к двум доменам: example.com и www.example.com

• Все запросы нужно передавать на сервер 10.80.0.5

• Все входящие запросы меньше 1 МБ (значение по умолчанию)

• Нет запросов, которые обрабатываются дольше 60 секунд (значение по умолчанию)

• Система должна работать в режиме мониторинга

• Клиенты обращаются к ноде напрямую, не через промежуточный HTTP‑балансировщик

Файл конфигурации в этом случае будет выглядеть следующим образом:

    server {
      listen 80;
      listen [::]:80 ipv6only=on;

      # the domains for which traffic is processed
      server_name example.com; 
      server_name www.example.com;

      # turn on the monitoring mode of traffic processing
      wallarm_mode monitoring; 

      location / {
        # setting the address for request forwarding
        proxy_pass http://10.80.0.5; 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      }
    }

8. Настройка оперативной памяти для ноды¶

Нода Вебмониторэкс использует находящееся в памяти хранилище Tarantool.

По умолчанию развернутый образ ноды Вебмониторэкс выделяет под Tarantool 40% от общей памяти инстанса.

Вы можете изменить объем оперативной памяти для Tarantool:

1. Откройте для редактирования конфигурационный файл Tarantool:

   sudo vim /etc/default/wallarm-tarantool
   

2. Укажите размер выделенной памяти в директиве SLAB_ALLOC_ARENA в ГБ. Значение может быть целым или дробным (разделитель целой и дробной части — точка).

   В боевой среде мы рекомендуем выделять для модуля постаналитики 75% от общей памяти виртуальной машины. Для тестирования ноды вы можете выделить меньшее количество памяти (например, 25% от общего объема).

   Например:

   Для тестирования нодыДля установки ноды в боевой среде

   SLAB_ALLOC_ARENA=0.5
   

   SLAB_ALLOC_ARENA=24
   

3. Чтобы применить сделанные изменения, перезапустите Tarantool:

   sudo systemctl restart wallarm-tarantool
   

9. Настройка логирования¶

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

10. Перезапуск NGINX¶

Перезапустите NGINX, используя следующую команду:

sudo systemctl restart nginx

Установка завершена¶

На этом установка завершена.

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

Дополнительные настройки¶

После установки нода Вебмониторэкс может потребовать дополнительной настройки.

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

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

Настройка отображения реального IP‑адреса клиента¶

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

В этом случае, если вы хотите, чтобы на ноду передавался IP‑адрес клиента в качестве адреса источника, то требуется дополнительная настройка прокси‑сервера или балансировщика.

Ограничение времени обработки единичного запроса¶

Используйте директиву Вебмониторэкс wallarm_process_time_limit, чтобы задать ограничение времени обработки единичного запроса нодой.

Если запрос обрабатывается за большее время, чем указано в директиве, то в лог‑файл заносится информация об ошибке, а запрос помечается как атака overlimit_res.

Ограничение времени ожидания ответа сервера¶

Используйте директиву NGINX proxy_read_timeout, чтобы задать таймаут чтения ответа проксированного сервера.

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

Ограничение максимального размера запроса¶

Используйте директиву NGINX client_max_body_size, чтобы задать ограничение на максимальный размер тела запроса клиента.

В случае превышения этого ограничения NGINX вернет клиенту ответ с кодом 413 (Payload Too Large, также известный как Request Entity Too Large).