Архив автора: admin

Балансировка нагрузки с помощью HAProxy

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




Рассмотрим решение по балансировке нескольких веб-серверов при помощи сервиса HAProxy.







Технические требования




  • Сервер под балансировщик с двумя сетевыми интерфейсами (Рекомендация. Внешний адрес для связи с внешним миром и локальный для общения между узлами кластера);
  • Два и более серверов под распределение запросов/трафика;




В примере будет использоваться дистрибутив Linux CentOS 7.




Установка и настройка backend-серверов




В качестве backend-серверов я буду использовать несколько веб-серверов с NGINX и настроенным SSL.




Прежде всего установим NGINX




yum install nginx




Выполним настройку веб-сервера




server {
    listen 80;
    server_name devservers.network;
    rewrite ^(.*)$ https://devservers.network$1 permanent;
}
 
server {
    server_name devservers.network;
    access_log /srv/www/devservers.network/logs/access.log;
    error_log /srv/www/devservers.network/logs/error.log;
    root /srv/www/devservers.network/public_html;
 
    ssl on;
    ssl_session_timeout 24h;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    listen 443 ssl http2 proxy_protocol;
 
    set_real_ip_from 10.0.1.10/32;
    real_ip_header proxy_protocol;
 
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
 
    location / {
   try_files $uri $uri/ /index.html;
    }
 
    location ~ .(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
        try_files $uri =404;
    }
 
}




Конфигурацию SSL можно выполнить и на самом балансировщике, а бэкенд сервера оставить работать на 80 порту, но в моем случае я буду использовать режим SSL Pass-Through. Не забываем поместить SSL-сертификаты в директорию /etc/nginx/ssl.




Для того, чтобы принимать реальные IP-адреса клиентов на веб-сервере от HAProxy необходимо добавить proxy_protocol в параметр listen, а также указать реальный адрес откуда разрешить принимать запросы:




set_real_ip_from 10.0.1.10/32;
real_ip_header proxy_protocol;




Создадим приветственную страницу на обоих веб-серверах touch /srv/www/devservers.network/public_html со следующим содержимым, изменив только номер сервера для его дальнейшего определения:




<!DOCTYPE html>
<html>
<head>
<title>Server #1</title>
</head>
<body>
<h1>This is server #1</h1>
</body>
</html>




Добавляем NGINX в автозагрузку и запускаем сервис.




systemctl enable nginx
systemctl start nginx




И не забываем выполнить настройку Firewalld




firewall-cmd --permanent --add-service=https
firewall-cmd --reload




Установка и настройка балансировщика




В качестве сервера балансировки я буду использовать VDS сервер с ресурсами 1 vCPU и 1Gb RAM. При правильной настройке, данных мощностей хватит для обслуживания 10-15к одновременных сессий, чего вполне достаточно для среднестатистического интернет-ресурса.




Установим HAProxy




Пакет HAProxy доступен в базовой репозитории CentOS.




yum install haproxy




Настройка HAProxy




HAProxy обладает очень гибкими настройками и конфигурация может содержать большое количество директив и условий. Конфигурационный файл состоит из нескольких секций. Директивы frontend, backend, listen должны иметь своё имя, к примеру defaults — может, но не обязательно, а такие как global — не должны.




Выполняем конфигурацию HAProxy в файле /etc/haproxy/haproxy.cfg. Рекомендую использовать свой конфигурационный файл, а представленный по умолчанию оставить как резерв.




Секция global




global
    log   /dev/log  local0
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    stats    timeout 30s
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon




Рассмотрим настройки в директиве global:




  • log — вести лог в /dev/log сохраняя в local0;
  • chroot — настройки безопасности, позволяющие работать HAProxy только в указанной директории;
  • maxconn — максимальное количество соединений на один процесс;
  • daemon — запуск процесса как демона.




Секция defaults




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




В нашем примере указаны следующие параметры:




defaults
    log global
    mode http
    retries 3
    option httplog
    option redispatch
    maxconn 2000
    contimeout 2000
    timeout http-request    10s
    timeout queue   1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s




  • log — указывает в какой лог вести запись (global в данном случае означает, что используются параметры, заданные в секции global);
  • mode — устанавливает протокол взаимодействия, принимает одно из значений: tcp, http, health;
  • retries — количество попыток соединения с сервером в случае отказа;
  • option httplog — формат лога, в случае использования HAProxy для проксирования HTTP-запросов (рекомендуется включить данную настройку);
  • option redispatch — разрешает программе разорвать и переназначить сессию в случае отказа сервера;
  • contimeout — максимальное время ожидания успешного соединения с сервером.




В примере я использую параметры timeout, которые позволяют более гибко настроить поведение балансировщика. Подробно с доступными параметрами можно ознакомиться в документации к HAProxy




Секция frontend




Укажем HAProxy какие запросы он должен обрабатывать, для этого задаем секцию frontend с именем https-in:




frontend https-in
    log /dev/log local0
    mode tcp
    option tcplog
    bind *:443
    default_backend backend-https-servers




Параметр bind со значением *:443 говорит о том, что HAProxy должен принимать все запросы на 443-й порт. Ещё раз напомню, что в данном примере я использую режим SSL Pass-Through, поэтому настройка SSL на самом HAProxy не выполняется.




Параметр default_backend указывает, какие сервера будут обрабатывать эти запросы. В данном случае — backend-https-servers, именно так необходимо назвать секцию backend.




Секция backend




В этой секции мы задаем алгоритм балансировки (параметр balance) и список серверов-обработчиков (server). В качестве алгоритма балансировки указываем roundrobin.




HAProxy имеет несколько алгоритмов балансировки:




  • roundrobin — каждый сервер получает запросы пропорционально своему весу, при этом веса серверов могут меняться на лету;
  • static-rr — то же, что и roundrobin, только изменение весов на лету не даст никакого эффекта;
  • leastconn — выбирает сервер с наименьшим количеством активных соединений;
  • first — выбирает первый сервер с доступными слотами для соединения source — на основе хэша IP-адреса отправителя запроса и весов серверов назначается сервер для соединения;
  • uri — сервер выбирается на основе адреса (без параметров) страницы;
  • url_param — сервер выбирается на основе GET-параметров запроса;
  • hdr — сервер выбирается на основе заголовков запроса;
  • rdp-cookie — сервер выбирается на основе cookie (если они не установлены, то применяется обычный roundrobin);




При перечислении серверов используется следующий формат: ключевое слово server, имя сервера, IP-адрес, дополнительные параметры (в данном случае — проверка статуса хоста и Proxy Protocol, которые позволяет перенаправлять реальные IP-адреса клиента с HAProxy на веб-сервер).




backend backend-https-servers
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server nginx01 10.0.1.3:443 check send-proxy
    server nginx02 10.0.1.4:443 check send-proxy




Просмотр статистики HAProxy




Для включения расширенной статистики HAProxy необходимо в конфигурационный файл добавить секцию:




listen stats
    bind :10001
    stats enable
    stats uri /haproxy_stats
    stats auth admin:password




  • bind :10001 — HAProxy будет ожидать запросы к порту 10001;
  • stats enable — включить отчёты со статистикой;
  • stats uri — установка адреса страницы с отчётом;
  • stats auth — логин и пароль для авторизации на странице со статистикой;




В секции listen указываем HAProxy, что он должен показывать статистику на странице /haproxy_stats на порту 10001 после ввода логина admin и пароля password.




Проверяем.




Переходим по адресу HAProxy (IP-адрес или хостнйем) и просто обновляем страницу. В зависимости от выбранного балансировщиком сервера будем получать ответ This is server #1 либо This is server #2.




Проверяем статистику. Переходим по адресу SITE_NAME:10001/haproxy_stats







На этом всё. Выше рассмотрен самый простой метод балансировки. Более сложная настройка требует грамотно составленного ТЗ и технических данных проекта. HAProxy очень удобный и гибкий в настройке инструмент с помощью которого можно выполнить балансировку и других сервисов, к примеру почтовый сервер, Memcached, Redis и пр.



2022-04-14T17:49:53
Software

Как проверить использование дискового пространства образов, контейнеров и томов Docker

Интересно, сколько места занимает Docker в вашей системе Linux?




В основном, все образы Docker, контейнеры и другие связанные с ними сущности находятся в каталоге /var/lib/docker.




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




$ sudo du -sh /var/lib/docker
4.9G	/var/lib/docker




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




К счастью, Docker предоставил инструменты для получения этой информации в более полезном виде.




Проверка использования дискового пространства Docker




Самый простой, “докеровский” способ узнать, сколько места занимают образы, контейнеры, локальные тома или кэш сборки:




docker system df




При выполнении этой команды (при необходимости используйте sudo) вы получите всю информацию об использовании диска, сгруппированную по компонентам Docker.




$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          4         4         1.065GB   0B (0%)
Containers      4         4         5.705kB   0B (0%)
Local Volumes   7         7         1.108GB   0B (0%)
Build Cache     0         0         0B        0B







Это определенно лучше, чем смотреть на общий размер /var/lib/docker.




Вы можете увидеть, сколько места занимают образы, контейнеры и тома.




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




На самом деле, это так.




Команда df системы docker имеет опцию verbose -v, которая предоставляет все эти детали.




docker system df -v




Вот подробный вывод:




$ docker system df -v
Images space usage:

REPOSITORY                               TAG       IMAGE ID       CREATED         SIZE      SHARED SIZE   UNIQUE SIZE   CONTAINERS
ghost                                    4.32.0    b40265427368   8 weeks ago     468.8MB   0B            468.8MB       1
jrcs/letsencrypt-nginx-proxy-companion   latest    037cc4751b5a   13 months ago   24.35MB   0B            24.35MB       1
jwilder/nginx-proxy                      latest    509ff2fb81dd   15 months ago   165MB     0B            165MB         1
mariadb                                  10.5.3    f5d2bcaf057b   20 months ago   407MB     0B            407MB         1

Containers space usage:

CONTAINER ID   IMAGE                                    COMMAND                  LOCAL VOLUMES   SIZE      CREATED        STATUS        NAMES
899cc90e85d9   ghost:4.32.0                             "docker-entrypoint.s…"   1               0B        8 weeks ago    Up 8 weeks    ghost_ghost_6
17b58fdafbce   jrcs/letsencrypt-nginx-proxy-companion   "/bin/bash /app/entr…"   4               571B      3 months ago   Up 2 months   letsencrypt-proxy-companion
58f99f46ee03   jwilder/nginx-proxy                      "/app/docker-entrypo…"   5               5.13kB    3 months ago   Up 2 months   jwilder-nginx-proxy
fb907286b60e   mariadb:10.5.3                           "docker-entrypoint.s…"   1               2B        3 months ago   Up 2 months   ghost_db_1

Local Volumes space usage:

VOLUME NAME                      LINKS     SIZE
ghostdb                          1         434.7MB
jwilder-nginx-with-ssl_acme      2         36.09kB
jwilder-nginx-with-ssl_certs     2         25.12kB
jwilder-nginx-with-ssl_dhparam   1         1.525kB
jwilder-nginx-with-ssl_html      2         1.106kB
jwilder-nginx-with-ssl_vhost     2         556B
ghost                            1         674MB

Build cache usage: 0B

CACHE ID   CACHE TYPE   SIZE      CREATED   LAST USED   USAGE     SHARED




Проверка размеров образов docker




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




docker ps --size




Вы должны увидеть столбец SIZE, добавленный к выводу команды:




$ docker ps --size
CONTAINER ID   IMAGE     COMMAND      CREATED         STATUS         PORTS     NAMES           SIZE
1171dcfb7e06   alpine    "sleep 10"   10 months ago   Up 9 seconds             always-policy   0B (virtual 5.61MB)




Проверка размеров запущенных контейнеров




Аналогично, если вы хотите узнать размер запущенных контейнеров Docker, вы можете использовать команду docker ps:




docker ps --size




Вы должны увидеть столбец SIZE, добавленный к выводу команды:




$ docker ps --size
CONTAINER ID   IMAGE     COMMAND      CREATED         STATUS         PORTS     NAMES           SIZE
1171dcfb7e06   alpine    "sleep 10"   10 months ago   Up 9 seconds             always-policy   0B (virtual 5.61MB)




Вы заметили, как вывод говорит 0B, а затем показывает виртуальный размер 5,61 МБ?




Виртуальный размер включает общий базовый образ.




Давайте вернемся к подходу к Linux более конкретно, на примере образа и контейнера Alpine в качестве практического примера.




Использование стандартных команд Linux для анализа использования дискового пространства Docker




Всякий раз, когда вы используете команду docker pull или запускаете команду docker-compose up -d для подготовки запуска приложений, вот как вы смотрите на использование пространства образа, фактически хранящегося на сервере Ubuntu 20.04:




sudo du -sh /var/lib/docker/overlay2/<hash-named-directory>/




Здесь Overlay2 является драйвером хранилища Docker по умолчанию в Ubuntu.




Вы можете подтвердить это, выполнив команду docker info и поискав Storage Driver:




Storage Driver: overlay2




Если оно отличается от вашего, значит, вы используете другой драйвер хранения для Docker.




Аналогично, расположение каталога будет названо в соответствии с тем же драйвером хранения.




Доступность драйвера хранилища зависит от поддержки ядра.




Использование диска конкретного образа




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




Например, я извлек образ alpine с помощью команды docker pull alpine.




Выполните следующую команду для его проверки:




$ docker inspect alpine




После выполнения команды вы заметите три поля в подразделе Data в разделе GraphDriver:




...
        "GraphDriver": {
            "Data": {
                "MergedDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/merged",
                "UpperDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "WorkDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/work"
            },

...




Исходя из вышеприведенной информации, вы можете видеть, что (упомянутый ранее в синтаксисе команды du) в данном случае равен 64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a525ab9e365e.




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




$ sudo du -sh /var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e
6.0M	/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e




Подобно образам, контейнеры также хранятся в одном каталоге на базе драйвера хранилища.




/var/lib/docker/overlay2




Использование диска конкретным контейнером




Если вы ищете местоположение конкретных контейнеров, вы можете снова использовать команду inspect в Docker для запущенного контейнера.




Например, я запустил контейнер alpine с помощью команды docker run -ti -d alpine.




Запустив команду docker ps, вы увидите, что он запущен:




$ docker ps
CONTAINER ID   IMAGE     COMMAND     CREATED         STATUS         PORTS     NAMES
cb341d6a28fa   alpine    "/bin/sh"   6 seconds ago   Up 5 seconds             confident_banzai




Здесь контейнер был произвольно назван confident_banzai.




Давайте проверим его:




$ docker inspect confident_banzai




После выполнения вышеуказанной команды вы заметите все четыре поля, упомянутые ранее в подразделе Data в разделе GraphDriver.




В этих местах данные контейнера физически хранятся на хост-системе, как и в случае с образами:




...
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3-init/diff:/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "MergedDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/merged",
                "UpperDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/diff",
                "WorkDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/work"
            },
            "Name": "overlay2"
        },
...




Теперь вы можете снова использовать команду du:




$ sudo du -sh /var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3
32K	/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3




Использование диска конкретного тома




В данном случае существует два типа томов.




Первый – это обычные тома Docker, а второй – bind mounts.




Тома Docker




Если вы ищете местоположение определенных томов, вы можете сначала использовать команду docker volume ls и проверить имя или ID тома.




Скажем, например, я запустил контейнер alpine следующей командой с томом:




docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine




Теперь автоматически будет создан том с именем test-data.




Теперь давайте создадим файл test.md в этом месте:




$ docker exec alpine-container sh -c "touch /var/lib/app/content/test.md"




Убедитесь, что файл действительно был создан:




$ docker exec -ti alpine-container sh
/ # ls /var/lib/app/content/
test.md
/ # exit




Когда вы запустите docker volume ls, в списке появится том с именем test-data:




$ docker volume ls
DRIVER    VOLUME NAME
local     d502589845f7ae7775474bc01d8295d9492a6c26db2ee2c941c27f3cac4449d1
local     e71ee3960cfef0a133d323d146a1382f3e25856480a727c037b5c81b5022cb1b
local     test-data




Наконец, вы можете подтвердить фактическое расположение файла на вашей хост-системе:




$ sudo ls -l /var/lib/docker/volumes/test-data/_data
total 0
-rw-r--r-- 1 root root 0 Oct  6 23:20 test.md




Поэтому путь для смонтированного тома всегда находится в каталоге с именем _data внутри соответствующего каталога тома.




Таким образом, вы можете использовать команду du здесь снова для определенных томов!




$ sudo du -sh /var/lib/docker/volumes/test-data/_data
4.0K	/var/lib/docker/volumes/test-data/_data




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




Bind Mounts




Это единственное исключение в Docker, где необходимо использовать подход Linux для мониторинга использования дискового пространства.




В то же время, всегда предпочтительнее сначала остановить работающие контейнеры.




$ mkdir /home/avimanyu/test-data
$ docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine




В этом случае смонтированный том с именем test-data станет доступен на стороне контейнера как /var/lib/app/content.




$ sudo du -sh /home/avimanyu/test-data
4.0K	/home/avimanyu/test-data




То же самое можно проверить и внутри контейнера:




$ sudo docker exec -ti alpine-container sh
/ # du -sh /var/lib/app/content
4.0K	/var/lib/app/content




Как вы можете видеть, оба указанных выше размера одинаковы!




Логи Docker на хосте всегда хранятся в томах.




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




Это зависит от приложения и расположения файлов логов в томах приложения.




Бонусные советы




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




sudo du -sh /var/lib/docker/overlay2




Логи Docker на хосте всегда хранятся в томах.




Обычно большой объем Docker, скорее всего, указывает на то, что логи накапливаются и управляются неэффективно.




Используя способ, описанный в разделе “Тома” этой статьи, пользователи также могут сориентироваться и смягчить ситуацию, посмотрев на использование дискового пространства в томах docker.




Это зависит от приложения и расположения файлов журналов в томах приложения.




Резюме




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




Вы также узнали, как сделать это предпочтительным (Docker) способом.




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




Источник: https://itisgood.ru/2022/02/24/kak-proverit-ispolzovanie-diskovogo-prostranstva-obrazov-kontejnerov-i-tomov-docker/



2022-04-14T17:45:17
DevOps

Принудительное удаление зависших подов в Kubernetes

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




kubectl get pods -n namespace | egrep -i 'Terminated|Evicted'




Как удалить поды в Kubernetes




Вы можете удалить эти поды разными способами.




Использование собственных команд kubectl и Bash




Это команды bash с фильтрацией, которые вы можете запустить для принудительного удаления подов в пространстве имен, которые застряли в завершенном состоянии.




# Определение неймспейса
namespace="mynamespace"

# Получаем поды
epods=$(kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted' | awk '{print $1 }')

# Удаляем их
for i in ${epods[@]}; do
  kubectl delete pod --force=true --wait=false --grace-period=0 $i -n ${namespace}
done




Подтвердите, есть ли еще контейнеры в этом состоянии.




kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted'




Удаление всех исключенных и завершенных модулей из всех пространств имен:




kubectl get pods --all-namespaces | egrep -i  'Evicted|Terminated' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod --force=true --wait=false --grace-period=0




Удалите все контейнеры в состоянии ImagePullBackOff из всех пространств имен – Бонус:




kubectl get pods --all-namespaces | grep -E 'ImagePullBackOff|ErrImagePull|Evicted' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod




Использование фильтров kubectl и jq




Вы также можете отфильтровать вывод команды kubectl и перенаправить в jq для получения определенных столбцов.




Сначала установите команду jq:




--- Ubuntu / Debian ---
$ sudo apt update && sudo apt install jq

--- CentOS/Fedora ---
$ sudo yum -y install epel-release
$ sudo yum -y install jq

--- RHEL ---
wget https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 -O jq
chmod +x jq
sudo mv jq /usr/local/bin




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




kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.reason!=null) | select(.status.reason | contains("Evicted")) | "kubectl delete pods (.metadata.name) -n (.metadata.namespace)"' | xargs -n 1 bash -c




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



2022-04-14T17:43:08
DevOps

Блокировка доступа к NGINX

Способы ограничения доступа к ресурсу в NGINX




Блокировка по User Agent`у




Я использую эту технику, прежде всего, для защиты от роботов, которые игнорируют настройки в моем файле robots.txt.




if ($http_user_agent ~ "Windows 95|Windows 98|xpymep|TurnitinBot|sindice|Purebot|libwww-perl")  {
  return 403;
  break;
}




Я выбрал для блокирования libwww-Perl, потому что в последние несколько лет, я не видел ни GET или POST по libwww-Perl, вероятно пробовали использовать какую-то уязвимость ПО.




Блокировка по IP-адресу




deny 85.17.26.68;     # spam
deny 85.17.230.23;    # spam
deny 173.234.11.105;  # junk referrers
deny 173.234.31.9;    # junk referrers
deny 173.234.38.25;   # spam
deny 173.234.153.30;  # junk referrers
deny 173.234.153.106; # spam
deny 173.234.175.68;  # spam
deny 190.152.223.27;  # junk referrers
deny 195.191.54.90;   # odd behaviour, Mozilla, doesnt fetch js/css. Ended up doing a POST, prob a spambot
deny 195.229.241.174; # spammy comments
deny 210.212.194.60;  # junk referrers + spam




Блокировка по запросу




Кроме того, можно заблокировать доступ на основе информации которая отправляется в заголовках HTTP.




if ($http_referer ~* (viagra|sex|porn|) ) {
  return 403;
}




Я использую ключ ~* для того чтобы предотвратить запрос GET по указанным словам во всей строке.




Блокировка по подсети




deny 69.28.58.0/24;   # spam
deny 79.142.64.0/20;  # spam
deny 80.67.0.0/20;    # spam




Блокировка по геолокации




Мы можем заблокировать целые страны, основанные на данных GeoIP предоставляемых MaxMind. Необходимо, чтобы NGINX имел модуль GeoIP. Во-первых, вы должны обозначить NGINX где база данных GeoIP находится в файловой системе. Вы можете сделать это внутри HTTP {}; Конфигурация блока:




geoip_country /etc/nginx/GeoIP.dat;




Теперь сообщаем NGINX страны которые необходимо заблокировать:




if ($geoip_country_code ~ (BR|CN|KR|RU) ) {
  return 403;
}




Блокировка по паролю




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




location ^~ /codes/ {
   root   /path/to/server;
          autoindex    on;
          autoindex_exact_size  off;
          auth_basic "Hello, please login";
          auth_basic_user_file /usr/nginx/passwords;
          access_log   /usr/nginx/logs/codes.log   download;
      }




либо админки с ограничением по IP-адресу:




location ^~ /admin/ {
   fastcgi_pass unix:/home/project/server.sock;
            include  conf/fastcgi.conf;
            allow 11.11.0.0/16;
            allow 22.22.22.22;
            deny all;
            auth_basic "Hello, Admin, please login";
            auth_basic_user_file /usr/nginx/adminpassword;
            access_log   /usr/nginx/logs/admin.log  main;
}




Добавить пользователя можно с помощью стандартной утилиты от apache:




htpasswd -b passwords NewUser NewPassword




В файле запись с зашифрованным паролем имеет вид NewUser:P47ghZ4kloG78: #Your Can Comment Here




Защиту от перебора паролей можно организовать одновременно двумя методами, основанными на использовании iptables:




  • Блокирование IP на время, если количество запросов в секунду превышает какое-либо разумное количество
  • Вести лог неудачных попыток подбора пароля и скриптом раз в минуту проверять лог и заносить IP адреса в iptables




Для первого варианта достаточно создать правила:




iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
   -m recent --name bhttp --set
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
            -m recent --name bhttp --update --seconds 120
            --hitcount 360 -j DROP
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -j ACCEPT




Можно вместо DROP использовать TARPIT, чтобы усложнить жизнь ломателям.




Для второго варианта надо добавить в конфиг:




location /401.html {
   root   /usr/nginx;
            access_log   /usr/nginx/logs/denied.log  error401;
        }




Формат error401, у меня например такой:




log_format error401  '$remote_addr - $remote_user [$time_local] '
   '$status "$request"';



2022-04-14T17:32:32
Software

Деректива Nginx — location с примерами

Директива location служит для установки конфигурации в зависимости от URI-запроса.

Синтаксис location в общем виде следующий:

Syntax:   location [=|~|~*|^~] uri { ... }
   location @name { ... }
Context:  server, location

Перед тем, как перейти к более детальному изучению, нужно заметить, что location определяется в контексте server (или в location в случае вложенной директивы), и в одном настраиваемом виртуальном хосте могут использоваться разные конфигурации в зависимости от обрабатываемого сервером URI. Читать →

Ошибка NGINX — Число имен серверов или их длине — could not build the server_names_hash

Исправление ошибки в числе имен серверов или их длине




Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив
server_names_hash_max_size и server_names_hash_bucket_size на уровне http.
Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 32, 64, либо другой величине, в зависимости от размера строки кэша процессора.
Если значение по умолчанию равно 32 и имя сервера задано как “too.long.server.name.example.org”, то nginx откажется запускаться и выдаст сообщение об ошибке:




could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32




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




http {
    server_names_hash_bucket_size  64;
    ...




Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:




could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32




В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.




Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта).




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



2022-04-14T17:28:47
Software